Migrare da WordPress a un CMS headless senza perdere traffico

Se stai ancora decidendo se fare il passaggio, leggi prima corpusctl vs WordPress — sostiene, onestamente, che la maggior parte dei siti WordPress dovrebbe restare dov'è.

Questo articolo presuppone che la decisione sia presa. Riguarda il farlo senza svegliarti davanti a un grafico del traffico a forma di dirupo.

#Passo 1 — Fai l'inventario di cosa fanno davvero i plugin

Fallo prima di tutto il resto, perché è qui che le migrazioni prendono il loro vero budget.

Scorri l'elenco dei plugin e classificane ciascuno in uno di tre gruppi:

Il terzo gruppo è il progetto. Un plugin per i form diventa un servizio per i form. Un plugin di membership diventa auth più gating nel tuo front end. Nessuno esporta questo, ed è il motivo per cui le migrazioni vanno per le lunghe.

Il secondo gruppo ha una trappola specifica: i page builder. Se i tuoi post sono costruiti con Elementor, WPBakery o simili, il corpo esportato è una zuppa di shortcode e markup wrapper, non HTML pulito. Metti in conto di pulirlo, o di riscrivere le pagine interessate a mano. Contale adesso.

#Passo 2 — Esporta

Strumenti → Esporta → Tutti i contenuti produce un file WXR: XML contenente post, pagine, tipi di post personalizzati, tassonomie, commenti e riferimenti ai media.

Riferimenti, non file. Le immagini stanno ancora in wp-content/uploads e devono essere spostate separatamente.

Due cose che vale la pena controllare prima di fidarti del file:

• Dimensione. I siti molto grandi raggiungono i limiti PHP a metà export e producono un file troncato che sembra comunque valido. Confronta il numero di post nell'XML con wp_posts.
• Codifica. Controlla un post con caratteri non ASCII dall'inizio alla fine. I bug di codifica scoperti dopo l'import sono penosi da districare.

#Passo 3 — Progetta prima il modello di contenuto

L'istinto è importare e poi riordinare. Fallo al contrario.

Un post WordPress con otto campi personalizzati è di solito due o tre tipi appropriati in un CMS strutturato. Decidi quella forma prima dell'import, altrimenti porterai il modello di WordPress in un sistema che hai scelto proprio per sfuggirgli.

In corpusctl non ci sono tipi di contenuto integrati; li definisci dal pannello o dall'API, e i campi portano ruoli — title, slug, body. Il ruolo è come il sistema sa quale campo è il titolo a prescindere da come l'hai chiamato, il che è ciò che fa funzionare campi calcolati come il tempo di lettura e l'indice senza configurazione.

Una mappatura tipica:

La localizzazione è una proprietà del campo, non un sito duplicato. Se stavi usando WPML o Polylang, questo è il passo in cui quella struttura diventa più semplice.

#Passo 4 — Prova a secco l'import

Il modulo di import di corpusctl legge il WXR e ha una modalità dry-run: produce un piano senza scrivere nulla.

La risposta contiene le voci che creerebbe, più skipped con un motivo per ciascuna e warnings. Leggi entrambi. Il salto silenzioso è come scopri al secondo mese che 400 post non sono mai arrivati.

I limiti di import esistono per un motivo — il parser rifiuta categoricamente l'XML contenente dichiarazioni DOCTYPE/ENTITY, perché quello è il vettore della XML-bomb, e i file oltre il tetto di dimensione vengono rifiutati anziché caricati in memoria in streaming. Se il tuo export inciampa in uno dei due, dividilo.

Poi eseguilo per davvero e riconcilia i conteggi: post in ingresso, post in uscita, per tipo.

#Passo 5 — Ricostruisci il front end

Questo è il compito più grande ed è un normale progetto web, quindi l'unico consiglio specifico della migrazione riguarda gli URL.

Preserva la struttura degli URL se puoi. Ogni URL che mantieni è un redirect che non devi scrivere e un segnale di ranking che non devi trasferire. Se la struttura attuale è /2019/03/some-post/ e la odi, cambiarla è un progetto separato — non impacchettare una ristrutturazione degli URL in una migrazione del CMS. Se entrambe vanno storte non saprai quale l'ha causato.

Sul lato lettura, il client di corpusctl non chiama un'API: il contenuto pubblicato viene scritto in un file immutabile indirizzato tramite hash al momento della pubblicazione, e il client risolve lo slug in uno shard del manifest localmente, poi recupera quell'indirizzo dalla cache edge nginx. Due richieste, entrambe memorizzabili nella cache, nessuna che tocca il database.

I renderer dei blocchi arrivano con zero stile predefinito, quindi il tuo lavoro di design è il tuo lavoro di design — il CMS non contribuisce con alcun CSS con cui litigare.

#Passo 6 — Redirect, compresi quelli che dimentichi

Ogni vecchio URL ha bisogno di un 301 verso la sua nuova casa. L'elenco che le persone scrivono:

• Post e pagine

L'elenco che dimenticano:

• Pagine allegato (/some-post/image-name/) — WordPress ne genera una per ogni media e Google le ha indicizzate
• Feed — /feed/, /comments/feed/, feed per categoria
• Archivi per categoria, tag, autore e data
• Archivi paginati — /page/2/, /page/3/ …
• ?p=123 e ?page_id=123 nelle forme con query-string
• Varianti maiuscole e con slash finale, se il vecchio server le accettava

Esporta l'elenco degli URL da Search Console (report Pagine) anziché dalla sitemap. La sitemap è ciò che intendevi pubblicare; Search Console è ciò che Google ha effettivamente trovato.

#Passo 7 — Fai il cutover e verifica

Vai online in un'ora di basso traffico, poi osserva per due settimane:

Search Console — Copertura per un picco di 404 o pagine "escluse"; Prestazioni segmentate per tipo di pagina per vedere se un template ha perso più degli altri.

Log del server — il log di scansione ti dice cosa Googlebot sta colpendo e cosa ottiene. Un 404 nel log è un redirect che hai mancato, e correggerlo lo stesso giorno non costa nulla mentre correggerlo tra un mese costa ranking.

Core Web Vitals — dati sul campo, non punteggi di laboratorio. È di solito qui che una migrazione headless mostra un miglioramento reale, perché il contenuto pre-compilato servito dalla cache non ha un'origine lenta da nascondere.

Non eliminare l'installazione di WordPress per almeno un mese. Tienila in funzione, scollegata e noindex, così da poter controllare com'era una pagina.

#Cosa si rompe, onestamente

Gli editor si lamenteranno dell'anteprima. WordPress fa l'anteprima dentro il CMS. L'anteprima headless passa attraverso il tuo front end via modalità bozza, e se non l'hai collegata prima del cutover, il team editoriale se ne accorgerà il primo giorno. Collegala per prima. (L'helper della modalità bozza di corpusctl valida il segreto con un confronto a tempo costante e rifiuta qualsiasi slug che non sia un percorso relativo confermato, il che chiude il buco di open-redirect che hanno la maggior parte degli endpoint di anteprima fatti a mano.)

Gli shortcode lasciano residui. Tutto ciò che un plugin stava renderizzando appare come testo grezzo nel corpo importato. Fai un grep del corpus per [ dopo l'import.

Commenti. Il WXR li esporta; la maggior parte dei CMS headless non ha dove metterli. Se i commenti contano, pianifica un servizio di terze parti prima del cutover, non dopo.

Il primo mese è più lento. Le persone sanno dov'è tutto in WordPress dopo dieci anni. Mettilo in conto, e non programmare un lancio nella stessa settimana.

Correlati: corpusctl vs WordPress · SEO per CMS headless: dove il traffico si perde · Cos'è un CMS headless?