Atto V: L'apparenza del completamento
La zona di pericolo delle 4-6 settimane
Quattro settimane dopo il lancio il team SEO tira fuori il report dei ranking, e la stanza fa quella cosa che le stanze fanno quando un numero è sbagliato: diventa prima silenziosissima e poi rumorosissima. Il traffico non-brand è sceso del ventotto percento. Il traffico brand sembra a posto—chi conosce già il tuo nome continua a trovarti, continua a digitarlo nella barra di ricerca, continua ad arrivare. Così la dashboard che un dirigente sbircia mentre va a una riunione sembra sopravvivibile. È l’altra dashboard, quella che nessuno sbircia mentre va da nessuna parte, a essere in fiamme.
Mancano sei giorni alla revisione mensile dei dirigenti. Qualcuno dovrà alzarsi in quella stanza e spiegare un numero, e la versione onesta della spiegazione è che il corpo ha perso un quarto del suo apporto di sangue tre settimane fa e nessuno se n’è accorto perché il paziente continuava a parlare.
Siamo stati in versioni di questa stanza più di una volta, e preferiremmo non starci di nuovo. Quindi questo è il capitolo che esiste per tenertene fuori. Non per spaventarti—il calo è prevenibile, che è una cosa molto più utile da sapere rispetto al fatto che sia comune—ma per essere onesti con te su dove vive davvero il pericolo, che non è quasi mai dove punta il panico.
Ecco la prima cosa e la più controintuitiva, e suonerà come una scappatoia finché non avrai vissuto l’alternativa. La SEO fallisce meno spesso negli editor di codice che nei piani di progetto. La mappa dei redirect è raramente la cosa che si rompe. Quello che si rompe è la decisione, presa allegramente in una riunione di pianificazione otto settimane prima, di migliorare la struttura degli URL già che ci siamo—di consolidare il blog, di rinominare la tassonomia delle categorie, di sistemare finalmente la convenzione sugli handle dei prodotti che infastidisce tutti dal 2019. Ognuna di queste è un’ottima idea. Ognuna di esse è, presa singolarmente, un miglioramento. E ognuna di esse, rilasciata lo stesso giorno della migrazione di piattaforma, è un modo di cambiare così tante cose tutte insieme che quando il traffico si muove non avrai nessun modo di sapere quale cambiamento l’ha mosso.
Quindi ecco il motto, ed è quello attorno a cui questo capitolo è costruito, e dovresti scriverlo su qualcosa che rivedrai. Cambia il meno possibile durante la migrazione. Il resto sistemalo dopo, quando i cambiamenti si possono fare in isolamento in sicurezza e puoi davvero leggere cos’hanno prodotto.
Se ti suona familiare, è giusto così. È lo stesso avvertimento che attraversava i capitoli sulla discovery e quelli sullo scoping più indietro nel libro, vestito in altri panni. Allora era il problema del già che ci siamo—la wishlist diventata un programma fedeltà, il portale-prima-o-poi diventato una voce di spesa, il modo in cui ogni migrazione si fa crescere dentro una seconda migrazione nel momento in cui qualcuno dice “già che ci siamo”. La SEO è il punto in cui l’impulso del già che ci siamo fa il suo danno più silenzioso e più costoso, perché il costo non compare nella build. Compare quattro settimane dopo, nel report che nessuno sbircia, nel ventotto percento.
La disciplina è tutto il capitolo. Tutto quello che segue è solo la disciplina, applicata ai punti specifici in cui viene violata.
Non puoi proteggere ciò che non hai misurato, e il singolo motivo più comune per cui la SEO di una migrazione va a rotoli è che il team non ha mai messo nero su bianco com’era fatto il “tutto a posto” prima di toccare qualunque cosa. Quindi prima del lancio—molto prima, mentre la vecchia piattaforma sta ancora servendo serenamente ogni pagina che abbia mai servito—costruisci la baseline. Tratta le baseline come un contratto con il business: questo è quello che avevamo, datato e firmato, ed ecco quello che abbiamo adesso, e la differenza tra quei due numeri è la conversazione, non una sensazione.
La baseline non è un numero solo. È il traffico e il fatturato scomposti per template, per canale, per mercato, per dispositivo, così che quando qualcosa si muove tu possa vedere quale qualcosa. Sono i ranking, sia head term sia long-tail, catturati per template così che un problema su una pagina di categoria non si nasconda dietro a una homepage in salute. Sono un crawl e un export di Google Search Console che insieme ti dicono cosa è indicizzabile e cosa no, dove puntano i tuoi canonical, quali duplicati vengono accorpati, quali URL parametrizzati e quali serie paginate esistono, e quanto index bloat ti stai trascinando dietro in silenzio. E—questa è la parte che trasforma un foglio di calcolo in una strategia—è il dieci-venti percento di URL che generano l’ottanta percento del tuo valore organico, nominati esplicitamente, insieme ai backlink esterni che non ti puoi permettere di rompere. Data ogni report. Una baseline senza una data è una diceria.
Il motivo per fare tutto questo prima del lancio, anziché ricostruirlo dopo a partire dai ricordi e dal dolore, è che dopo lo farai di fretta, con una revisione dei dirigenti già in calendario, cercando di dimostrare una negazione su un numero che si è già mosso.
Una volta che sai cosa stai proteggendo, la protezione stessa è per lo più una cosa sola fatta con enorme cura. La struttura dei tuoi URL è lo scheletro del tuo sito. Cambiala senza un piano di redirect preciso e il corpo collassa—e un piano di redirect è preciso solo quando è uno-a-uno. Ogni vecchio URL che ha guadagnato qualcosa punta al singolo nuovo URL che adesso svolge quel compito. La vecchia pagina prodotto va alla nuova pagina prodotto. La vecchia categoria va alla nuova categoria. Il vecchio articolo va al nuovo articolo.
Quello che non fa—quello che è, di fatto, l’ammazza-ranking che compare per nome in ogni post-mortem che abbiamo mai letto—è scaricare. Reindirizzare in blocco qualche migliaio di URL prodotto orfani verso la homepage perché era più facile che mapparli, o mandare un’intera categoria deprecata al suo genitore perché “abbastanza vicino”, non è un piano di redirect. È un modo di dire al motore di ricerca che tutte quelle pagine erano intercambiabili e nessuna di esse contava, e il motore di ricerca ti crederà. Gli scarichi verso homepage e categoria sono ammazza-ranking. La scorciatoia sembra una pulizia. A un crawler, si legge come un’estinzione di massa.
Anche i dettagli rognosi contano, e falliscono in silenzio, che è peggio che fallire rumorosamente. Normalizza gli slash finali, le maiuscole e le estensioni dei file, e scegli una forma canonica sola anziché lasciare che tre versioni di ogni URL coesistano e competano con sé stesse. Preserva i parametri UTM attraverso la catena dei redirect, così che l’attribuzione del team marketing non si spenga in silenzio nella stessa settimana in cui si spegne il traffico. Niente di tutto questo è glamour. Tutto questo è lo scheletro.
C’è una seconda categoria di danni più subdola dei redirect, perché non si annuncia nemmeno nel crawl. Il contenuto è l’ossigeno della SEO, e il contenuto è esattamente ciò che viene potato per sbaglio quando cambiano i template. Un nuovo template prodotto che si dimentica di renderizzare la descrizione lunga. Un H1 che era stato rifinito a mano sulla vecchia piattaforma e che sulla nuova viene fuori come il nudo titolo del prodotto. Alt text che viveva in un campo che lo script di migrazione non ha mappato. Meta title che vengono rigenerati da uno schema di default perché nessuno ha detto al tema di fare altrimenti. Ogni omissione è piccola. Nell’insieme sono la differenza tra una pagina che si posiziona e una pagina che è tecnicamente presente.
Ed è qui che il motto si guadagna di nuovo la pagnotta, perché l’istinto, scoprendo che le vecchie descrizioni dei prodotti erano mediocri, è di sistemarle già che ci siamo. Non farlo. Se ci sono correzioni di contenuto da fare—e ce ne sono sempre—non farle durante la migrazione. Annotale. Parcheggiale nella roadmap post-lancio dove puoi farle in modo deliberato e misurare cos’hanno prodotto. Riscrivere duemila descrizioni di prodotto nella stessa release che sposta la piattaforma non è un miglioramento; è un modo di garantirti che quando qualcosa si muove non saprai mai se è stata la piattaforma o la prosa. Cambia il meno possibile. Poi, dopo, cambia la cosa successiva, e guardala.
Una parte di ciò che sembra un vincolo quando arrivi su Shopify è in realtà un regalo, a patto che tu smetta di combatterla. Tratta i vincoli nativi della piattaforma come upgrade. La struttura degli URL di Shopify è fissa—non puoi inventarti la tua convenzione di pathing, e gli ingegneri che arrivano da uno stack su misura la piangono per circa una settimana. Ma la struttura fissa è anche una cosa in meno da sbagliare, un posto in meno in cui la mappa dei redirect possa sviluppare un’interpretazione creativa. Spendi l’energia che avresti speso a personalizzare gli URL sulla cosa che davvero si capitalizza nel tempo: solleva i tuoi Core Web Vitals. La piattaforma ti consegna una fondazione veloce e prevedibile; il lavoro non è ridecorare lo scheletro ma rendere svelto tutto il corpo.
Qualche altra cosa appartiene a questo giro, e appartiene a prima del lancio, non a dopo. Genera sitemap XML pulite e modulari anziché un unico monolite che va in timeout durante il crawl. Se vendi a livello internazionale, valida le tue annotazioni hreflang finché non sono noiosamente corrette, perché un hreflang sottilmente sbagliato è peggio di nessun hreflang—dice al motore di ricerca di servire la pagina tedesca al mercato francese con grande sicurezza. E ricrea i tuoi dati strutturati: il JSON-LD che alimentava i tuoi rich result sulla vecchia piattaforma non migra da solo, e un prodotto che perde il markup di prezzo-e-disponibilità perde la cosa che lo faceva spiccare nella pagina dei risultati.
C’è qui una trappola specifica di Shopify che ha morso abbastanza team da meritarsi un suo avvertimento, perché fa fallire la mossa più diligente di questa lista—fare l’audit del sito di staging prima del lancio—in un modo che sembra dire che il problema sia l’audit. Per molto tempo Shopify non è riuscito a distinguere in modo affidabile un crawler legittimo da uno malevolo, il che significava che gli strumenti SEO che naturalmente punteresti verso il tuo store per validarlo—i crawler, le suite di audit, i rank tracker—potevano ritrovarsi bloccati alla porta insieme ai malintenzionati. Facevi girare l’audit, ottenevi un risultato confuso o vuoto, e non avevi idea se il tuo sito fosse rotto o semplicemente difeso contro il suo stesso ispettore.
Shopify ha da allora rilasciato il supporto per Web Bot Auth, che dà ai crawler ben educati un modo di dimostrare di essere chi dicono di essere, così che gli strumenti migliori ora possano completare i loro audit. L’istruzione pratica è confermare che il tuo strumento di audit si autentichi davvero e arrivi davvero in fondo contro lo store prima di fidarti di un report pulito—un report pulito da un crawler che è stato respinto alla porta non è un report pulito, è una porta chiusa.
E fai l’audit su staging con un robots.txt simile a quello di produzione, come prova generale, prima del lancio. L’ambiente di staging sarà stato blindato per tenerlo fuori dall’indice—com’è giusto che sia—ma un crawl di staging fatto girare contro una configurazione robots permissiva o completamente bloccata non ti dice nulla su come verrà crawlato il sito live. Fa’ in modo che la prova generale somigli alla cosa vera abbastanza da vicino da rendere significativi i suoi risultati. (Questo è cugino stretto di un avvertimento che si prende presto un suo capitolo: lo store di staging che sembra produzione e non lo è. La versione SEO è semplicemente che un robots.txt che differisce tra staging e produzione trasforma il tuo crawl finale pre-lancio nella prova generale dello spettacolo sbagliato.)
Poi lanci, e il titolo del capitolo arriva. Le prime quattro-sei settimane dopo il lancio sono la zona di pericolo, e ha quel nome perché è la finestra in cui tutto ciò che andrà storto è già andato storto ma non ha ancora finito di comparire nei numeri. I motori di ricerca hanno bisogno di tempo per ricrawlare, per rivalutare, per ridistribuire l’autorità che hai preservato o sprecato. Il danno si fa il primo giorno. La prova arriva il ventottesimo.
Quindi osservi, all’inizio ogni giorno e poi ogni settimana, con una lista precisa e non con un’ansia generica. Gli errori di crawl, perché un picco significa che il motore di ricerca sta sbattendo contro muri che non sapevi di aver costruito. La salute dei redirect, perché un redirect che funzionava nella prova generale su staging può rompersi sotto traffico reale e casi limite reali. L’indicizzazione, perché il conteggio delle pagine indicizzate che cresce o crolla ti dice se il nuovo sito viene assorbito o respinto. I ranking, osservati per template così che un problema non possa nascondersi. Lo stato della sitemap. I Core Web Vitals sotto carico reale anziché sintetico.
E osserva prima di tutto il non-brand. Questa è la singola istruzione che avrebbe salvato il team del cold open. Il traffico brand—le persone che cercano il tuo nome—è fedele e lento a reagire e continuerà ad arrivare per settimane dopo che il pavimento è crollato sotto tutto il resto, il che significa che il brand spesso maschera i problemi. Un numero di traffico complessivo che mescola brand e non-brand può sembrare rassicurante mentre la metà non-brand, la metà che rappresenta le persone che ti scoprono per la prima volta, frana in silenzio. Separali il primo giorno. Poi osserva la metà che può davvero farti male.
La paranoia e la precisione proteggono la SEO. Non l’ottimismo, non un buon vendor, non una dashboard dall’aspetto pulito. La disponibilità a guardare il numero scomodo ogni giorno per un mese, e la precisione di aver impostato i redirect in modo che non ci sia nulla che la paranoia possa trovare.
Supponi, perché hai fatto il lavoro, che la zona di pericolo passi senza incidenti. Il traffico tiene. La linea non-brand è piatta o in salita. Ce l’hai fatta. Questo è il momento in cui la migrazione ti tenta di dichiarare vittoria e andartene, ed è esattamente il momento sbagliato, perché il giorno del lancio non è il traguardo—è quando comincia il lavoro vero. La piattaforma è ora abbastanza stabile da poter finalmente fare, in sicurezza e una alla volta, tutte le cose che così saggiamente ti era stato proibito fare durante la migrazione.
Questa è la roadmap SEO post-lancio, ed è dove i miglioramenti parcheggiati vanno finalmente ad accadere. La rifinitura del linking interno, ora che la nuova struttura si è assestata e puoi vedere come l’autorità fluisce attraverso di essa. La backlink reclamation, l’ultimo tedioso versetto della liturgia—scrivere mail agli esseri umani i cui link un redirect non poteva salvare. La ri-ottimizzazione dei contenuti, le duemila descrizioni di prodotto che non hai toccato il giorno del lancio, riscritte adesso in lotti deliberati che puoi davvero misurare. L’arricchimento dello schema, estendendo i dati strutturati che hai preservato nei punti in cui prima non avevi avuto tempo. L’irrobustimento tecnico, la lunga coda di piccole correzioni che si capitalizzano nel tempo. Novanta giorni a cambiare una cosa alla volta e a guardare cosa fa—che è la cosa che non potevi mai fare nel caos di un lancio, e che è, finalmente, da dove arriva davvero il salto di crescita organica.
Perché questa è la scommessa che tutto il capitolo ha descritto. Il replatforming è uno di quei momenti che possono o sbloccare un salto nella crescita organica o cancellare anni di equity SEO da un giorno all’altro, e la differenza tra questi due esiti è quasi interamente una questione di moderazione—di cambiare il meno possibile mentre il terreno si muove, e poi cambiare tutto quello che vuoi, con cura, una volta che è fermo. I team che perdono il loro traffico non sono quelli sbadati. Sono quelli ambiziosi, quelli che hanno visto una migrazione e hanno pensato già che ci siamo. Tieni la linea durante lo spostamento. Poi va’ a costruire la cosa che stavi sognando, un cambiamento misurato alla volta, su una fondazione di cui finalmente puoi fidarti.
Al lead SEO che è stato nella stanza per tutto questo e tenuto in silenzio ai margini per la maggior parte—che ha sollevato la questione della mappa dei redirect alla terza settimana e si è sentito dire che poteva aspettare, che ha chiesto la baseline e ha ottenuto un’alzata di spalle, che sta leggendo questo capitolo per scoprire se l’inquietudine era giustificata: lo era. Avevi ragione. Stampa il motto, attaccalo al muro sopra il piano di progetto, e quando qualcuno proporrà di migliorare la tassonomia il giorno del lancio, indicalo. Cambia il meno possibile durante la migrazione. Non stai facendo il timido. Sei l’unica persona nella stanza capace di leggere il report che nessuno sbircia mentre va da nessuna parte.