5 errori di migrazione del sito SEO da evitare con Sara Moccand

Pubblicato: 2022-06-27


Sei mai stato coinvolto in una migrazione catastrofica di un sito web? Forse sei stato coinvolto in un progetto per affrontare gli effetti di una migrazione del sito Web mal ponderata.

Oggi parleremo di cinque errori chiave da evitare durante la migrazione del tuo sito web con una signora che l'anno scorso ha ceduto e si è abbonata a Netflix e Disney Plus. È la co-conduttrice del meetup SEO Nerds Switzerland e SEO Specialist presso Liip, un'agenzia di sviluppo web e mobile con sei uffici in Svizzera. Un caloroso benvenuto al podcast In Search SEO, Sara Moccand.

Gli errori da evitare sono:
  1. Scarsa pianificazione
  2. Non testare i reindirizzamenti
  3. Non audire la messa in scena
  4. Migrazione in un periodo di forte domanda
  5. Avere lo staging indicizzato





5 suggerimenti per la migrazione del sito da tenere d'occhio


    Sara: Ciao.

    D: Ehi, Sara. Puoi trovare Sara su liip.ch. Allora Sara, perché la migrazione del sito web è un grosso problema per i SEO?

    S: Principalmente perché puoi perdere tutto il traffico organico che è la fonte di guadagno, direi. Questo è il motivo principale, quindi tutti devono prestare molta attenzione nella migrazione del proprio sito Web.

    D: Quindi oggi parliamo dei cinque errori chiave da evitare durante la migrazione del tuo sito web. A cominciare dal numero uno, scarsa pianificazione.



    1. Scarsa pianificazione



    S: Sì, uno dei più grandi errori è una cattiva pianificazione. Ho un paio di esempi. Una cattiva pianificazione può iniziare dall'inizio. Ad esempio, in un'agenzia, vendere il numero di giorni sbagliato, il che significa che devi ridiscutere il budget, il che lo rende estremamente complicato. Ci sono diversi esempi, ma iniziamo con i problemi principali. Ovviamente, le cose non vengono implementate nel modo desiderato se non si pianifica correttamente. Il secondo problema, come dicevo prima, è la perdita di traffico. Questo è lo scenario catastrofico, la perdita di traffico, e la soluzione è imparare il nome di tutte le persone coinvolte. Questo è il segreto. Scopri chi è lo sviluppatore, chi è il front-end, il back-end, il designer, ecc. Scopri tutto ciò che puoi sui loro nomi e cosa fanno in modo da poterli sempre contattare.

    Ogni migrazione di un sito web è come un nuovo progetto. Quindi hai il progetto, che poi ha un piano. Ed è lì che puoi vedere esattamente dove la SEO può interagire. Questo è importante da tenere a mente. Ad esempio, all'inizio, gli sviluppatori sanno cosa fare, sceglieranno la tecnologia con cui lavorare. Quindi è interessante per un SEO sapere quale tecnologia intende utilizzare. E forse puoi anche influenzare la tecnologia utilizzata. A volte, non molto spesso, ma a volte. Questo è solo un esempio su come apprendere la pianificazione generale e capire dove puoi interagire.

    D: Ci sono molte cose che puoi includere in un piano, ovviamente, ma ci sono elementi standard che incorporeresti all'interno di un piano? O ogni progetto è unico?

    S: Direi che ci sono tre cose standard. Sapendo quando viene scelta la tecnologia, sapendo quando il designer inizierà a progettare l'architettura del sito Web e sapendo a che punto sarà pubblicata, puoi analizzare la messa in scena per assicurarti quando andrà in diretta. Questo mi porta alla rottura della migrazione del sito web. Hai il tuo piano e poi lo scomponi in fasi. La prima è la fase di preparazione, in cui si interagisce con gli sviluppatori. E lì devi anche analizzare come sta andando il sito web, quali pagine sono importanti, ecc. E preparerai anche la tua mappa di reindirizzamento. La fase successiva prevede la fase di test in cui si testa tutto, perché qualunque cosa sia in staging andrà in diretta al 100%, quindi se c'è un problema lì, ci sarà un problema dopo.

    D: Anche lì hai menzionato gli URL. Immagino che alcune migrazioni di siti Web siano più facili di altre. Alcuni potrebbero migrare i server e mantenere la stessa tecnologia, CMS, forse anche gli stessi URL... Cosa succede se si modifica ogni singolo URL o la maggior parte degli URL perché è necessario? Forse stai passando da qualcosa che ha ASP, ad esempio, alla fine degli URL in un URL abbastanza semplice? È possibile mantenere tutte le classifiche e modificare gli URL contemporaneamente?

    S: Dato che lavoro in una società di sviluppo, le persone vengono a farlo. Non vengono solo per cambiare un po' il server. Quello che vogliono fare è esattamente questo. Vogliono cambiare tutto. Questo è il mio problema. Quindi sì, funziona. Devi fare i tuoi reindirizzamenti, devi fare la tua mappa di reindirizzamento e hai tempo in cui i motori di ricerca devono adattarsi un po'. La maggior parte delle volte funziona bene, perché quando fai la tua mappa di reindirizzamento, l'obiettivo è farlo in modo intelligente. Ad esempio, sai che se una pagina è classificata per qualcosa di specifico, la reindirizzerai allo stesso argomento. Quindi devi stare un po' attento nella tua mappa di reindirizzamento, e poi funziona. Ancora una volta, lo scenario più casistico che ho visto è esattamente dove hanno cambiato tutto.

    D: Un'altra domanda di follow-up in relazione a ciò che hai detto. Hai detto che a volte i motori di ricerca hanno bisogno di un po' di tempo per adattarsi. Quanto tempo è ragionevole dedicare ai motori di ricerca prima che tu possa vedere le stesse classifiche che avevi prima?

    S: No, intendevo prima di farti prendere dal panico. Direi che dipende, ma ho visto alcune volte in cui non cambiano tutto, ma cambiano un po' e si adattano abbastanza velocemente. Direi al massimo un mese, un mese e mezzo. E se dopo non si adatta, allora c'è qualche problema da qualche parte.

    D: Passiamo al numero due, non testare i reindirizzamenti.



    2. Non testare i reindirizzamenti



    S: Sì. Facciamo un paio di esempi sul muro della vergogna dove ho fatto male. Ricordo che all'inizio ho organizzato la mia mappa di reindirizzamento e ogni singolo file andava bene. Quindi l'ho dato allo sviluppatore per preparare tutto ciò che ho testato. E ho detto che va tutto bene. Poi è andato in diretta. E quando siamo andati in diretta, mi chiedevo cosa stesse succedendo. E poi mi sono reso conto che stava generando una catena di reindirizzamento, cosa di cui sono rimasto un po' sorpreso. Quindi sono stato abbastanza fortunato da avere un ottimo rapporto con gli sviluppatori, che sono stati in grado di risolvere il problema all'istante. Questo è stato uno scenario in cui ho testato ma non ho testato abbastanza bene, perché non me ne rendevo conto prima di andare in diretta.

    Un'altra volta sul muro della vergogna ed essere consapevoli di quanto sia importante testare tutto alla perfezione. Ricordo che c'era un sito web con molti paesi, ma c'era un ruolo specifico per l'URL. Quindi ho chiesto allo sviluppatore di aiutarmi a fare uno script per me, così andremo più veloci. Ha fatto la sceneggiatura e poi ho prenotato mezza giornata con lo sviluppatore per fare il test, ma poi ha detto: "Ehi, Sara, l'ho testato". Fantastico. Se l'hai già fatto, fantastico. Ma fammi provare un paese. Quindi l'ho testato negli Stati Uniti e ho detto: "Tutto funziona. Grande. Grazie. Addio. Dammi il cinque!" Poi siamo andati in diretta. Ho controllato tutto e quando ho controllato ero: "Cosa sta succedendo? Cos'è il salto? Dove sono il Giappone e il Kuwait?" Quindi vedo che abbiamo migrato tutto, ma ci mancavano il Giappone e il Kuwait, cosa che non mi rendevo conto prima che andassero in diretta. E ancora, sono stato fortunato perché mi hanno aiutato a recuperarlo immediatamente quindi non ci sono state vere ripercussioni perché è successo il giorno in cui abbiamo corretto tutto. Ma questo è un problema. Devi testare.

    D: Immagino che si riferisca anche al punto tre perché il punto tre non è l'auditing della messa in scena.



    3. Non controllare la messa in scena



    S: Sì, questo fa parte del punto tre. All'inizio avevo i miei biglietti, li stavo controllando e tutto andava bene nella messa in scena. Fantastico. I biglietti sono implementati. Ma poi ho capito che non stavo controllando come farei normalmente per controllare un sito web. Ad esempio, inizi a vedere cose strane. Ricordo questo sito Web, che è successo di recente e sul lato server il rendering era perfetto. Ho potuto vedere tutto nel codice nella console. Quindi ero felice. Ma ho un problema con gli elementi nascosti, controllo sempre gli elementi nascosti. Quello che è successo è che JavaScript si stava comportando in modo super strano. Stava rimuovendo tutti i testi dall'elemento nascosto. Quindi potresti vederlo ma non nel codice. Questo è un esempio di quanto sia importante controllare la messa in scena del sito web e verificarne tutta l'implementazione.

    L'altra cosa che devi fare è avere la tua lista di controllo, riparare la lista di controllo, con tutte le attività, esattamente come un audit, e poi puoi sempre aggiungere una colonna. Ad esempio se usi un foglio Google, metti una colonna che per questa attività ho un ticket, per queste attività non è richiesto, potrei prenderlo. Ad esempio, per il caso JavaScript che ho fornito, non apri un ticket, lo apri solo se c'è un problema. E poi dai il tuo elenco di priorità su un'altra colonna, lo stato. Quale URL di stato eseguire in corso, quindi commenti. I commenti sono molto importanti, tutti li portano via, ma i commenti sono importanti perché devi sapere perché qualcosa viene bloccato. Ad esempio, se una persona sta bloccando o un altro biglietto sta bloccando, devi sapere per bloccarlo. Questo riguarda un po' l'auditing della messa in scena e la sua importanza. Dipende, ma alcuni sviluppatori utilizzeranno anche, ad esempio, il noindex su tutte le pagine, nel codice. E poi si dimenticheranno di rimuoverlo quando andranno in diretta. Il problema è che devi essere consapevole che lo stanno usando in modo da poter chiedere loro di ricordarsi di rimuovere il noindex prima di andare in diretta, per favore.

    D: E il punto numero quattro da evitare è la migrazione in un periodo di forte domanda.



    4. Migrazione in un periodo di forte richiesta



    S: Sì. Questo dovrebbe essere ovvio perché hai questo problema di perdere traffico, o almeno per un breve periodo di tempo, non è sempre così. Anche in questo caso, dipende dalla migrazione del sito Web, ma c'è il rischio di tempo di adattamento. E poi se hai tempo per altre attività... Diciamo che sei in eCommerce. Probabilmente tra ottobre e la fine di dicembre, non vuoi migrare il tuo sito Web perché il Natale sta arrivando e molte persone compreranno tramite il tuo negozio eCommerce. Il cliente normalmente sa che in quel periodo ha una forte domanda. In questo modo puoi verificare con il cliente le sue analisi per evitare problemi.

    D: Hai menzionato in precedenza che alcuni sviluppatori potrebbero persino inserire noindex su ogni pagina per cercare effettivamente di evitare che le pagine vengano indicizzate. L'errore numero cinque è avere la messa in scena indicizzata. Consiglieresti quel tag noindex su ogni pagina nell'ambiente di staging per evitare questo genere di cose?



    5. Avere lo Staging indicizzato



    S: No, la protezione con password è sempre la soluzione. Puoi fare noindex ma, come nel mio esempio, potresti dimenticare quando vai in diretta. Alla fine, la soluzione migliore che funziona sempre è quella di essere protetti da password, punto e basta. Ricordo una volta che la messa in scena è stata indicizzata alcuni anni fa, e quella è stata probabilmente l'esperienza più scioccante che ho avuto. La messa in scena è stata indicizzata e il problema era... si potevano acquistare i biglietti sul sito web e il problema era che le persone che stavano cercando di acquistare i biglietti sul sito di messa in scena erano un po' catastrofiche. Riesci a immaginare le persone che cercano di acquistare sul sito Web di staging? Quindi mi hanno contattato dicendo che hanno questo problema. E siamo stati in grado di risolverlo perché è relativamente facile da risolvere. Questo è probabilmente uno dei punti principali per me. Una volta che gli sviluppatori hanno inserito la protezione con password e inserito noindex. Quindi devo stare attento non solo a controllare che sia protetto da password, ma anche a controllare il noindex.

    D: Sono sicuro che avresti potuto espandere questa conversazione a 101 errori da evitare durante la migrazione del nostro sito Web, ma si spera che abbiamo i tuoi primi cinque lì. Come sempre, sono cose fantastiche da parte di Sara. Chiudiamo con il Pareto Pickle. Pareto dice che puoi ottenere l'80% dei tuoi risultati dal 20% dei tuoi sforzi. Qual è un'attività SEO che consiglieresti che fornisce risultati incredibili per livelli di impegno modesti?





    The Pareto Pickle - Pianificazione della migrazione del sito web



    S: Per me in una migrazione di un sito web è la pianificazione. Prenditi un po' di tempo nella pianificazione. Non è un'enorme quantità di tempo rispetto al lavoro che devi fare. Se hai una struttura, allora non commetti errori, e quindi ti risparmi un sacco di tempo perché per ogni errore, devi chiedere tempo per riprenderti dagli errori, quindi pianificando definitivamente.

    D: Pianifica correttamente. Sono stato il tuo ospite, David Bain. Puoi trovare Sara su liip.ch. Sara, grazie mille per essere presente nel podcast SEO di The In Search.

    S: Grazie.

    D: E grazie per l'ascolto.