Verifica i backlink per una pagina prima di finalizzare la mappa dei redirect

Il fascicolo del caso (inventato, a scopo illustrativo)

Immagina un piccolo negozio che passa da un vecchio sito PHP a un nuovo framework. Il negozio, i suoi URL e ogni numero qui sono inventati.

Il vecchio sito aveva 400 URL e il team ha scritto redirect per i 120 che riteneva importanti, per poi puntare un catch-all alla homepage per il resto. Il lancio è andato online senza problemi e, entro una settimana, le impressioni sono diminuite su pagine di cui nessuno aveva tenuto conto.

Niente era sbagliato nei redirect che avevano scritto. La perdita era nei 280 che non avevano gestito.

Un'ipotesi come questa non è prova di nulla. È una prova generale e il rapporto di copertura di Search Console e la routine di valutazione gratuita sono ciò che useresti sul caso reale.

Perché una regola di pattern non è una mappa

Un'unica regola che invia tutto ciò che si trova sotto una cartella alla homepage è allettante. Richiede una riga di configurazione. Sembra finita. Scarta anche l'unica cosa che i vecchi URL stavano trasportando, ovvero l'elenco dei luoghi a cui le persone linkavano.

Un catch-all nasconde la perdita

Immagina che il tuo vecchio sito avesse 400 URL e che un catch-all invii i 280 non mappati alla homepage. Ognuno di quegli indirizzi vecchi restituisce ora la stessa pagina. Un crawler di ricerca legge questo pattern come un insieme di soft 404, quindi i link che puntano a loro non hanno una destinazione chiara.

Il catch-all è silenzioso. Nessun errore il giorno del lancio e i dashboard mostrano ancora un sito sano finché qualcuno non chiede quali pagine guadagnavano link in passato.

I pattern si adattano alla coda lunga, non ai contenuti principali

Un pattern va bene una volta che gli URL importanti sono gestiti uno per uno. Inserisci manualmente i top twenty per domini di riferimento nella mappa, un salto alla volta, e solo allora lascia che una regola copra le pagine a cui nessuno linka.

Questo ordine è importante perché un pattern non può distinguere una pagina di valore da una vuota. Vede un percorso, non un conteggio di domini di riferimento.

Mantieni il file breve e il test rigoroso

Lunghe liste di redirect su un server statico possono diventare difficili da leggere. Gestisci gli URL importanti con righe esplicite e la coda lunga con una regola, in modo che il file rimanga abbastanza breve da revisionare.

Che la regola risieda in un file del web server, in una configurazione del framework o in un plugin, il test è lo stesso. Richiedi ogni vecchio URL e controlla lo status e la destinazione. Se testi dieci URL campione e otto restituiscono un 301 verso la pagina corretta, mentre gli altri due restituiscono un 200 su una pagina che non è quella vecchia, quello è l'errore da individuare prima del lancio.

Canonical, sitemap e hreflang: i segnali silenziosi

Prima di verificare i backlink per una pagina, controlla che i segnali siano coerenti. Un redirect è solo uno dei diversi indizi che dicono ai motori di ricerca dove si trova una pagina. Il tag canonical, la sitemap e qualsiasi impostazione hreflang devono puntare nella stessa direzione. Altrimenti si annullano a vicenda. Il riferimento tecnico mostra quale chiamata restituisce l'elenco delle fonti da controllare.

I canonical devono corrispondere al redirect

Se il vecchio URL reindirizza alla pagina X, ma la pagina X canonizza verso la pagina Y, i segnali ora discordano su quale pagina sia quella reale. Un redirect sposta i visitatori, mentre un canonical è un suggerimento sulla versione preferita, quindi una discrepanza rende difficile prevedere l'esito.

Controlla i canonical sui top twenty delle destinazioni dopo il lancio. Ogni pagina indica se stessa o la pagina che ha sostituito? Qualcuna indica per errore la homepage?

Una sitemap dovrebbe elencare ciò che è attivo

La sitemap è l'elenco che consegni ai motori di ricerca, quindi dovrebbe contenere le destinazioni attive e non i vecchi indirizzi che ora reindirizzano. Una nuova sitemap che elenca solo URL freschi può far cadere silenziosamente le pagine che hai più bisogno di far indicizzare.

Fai attenzione con lastmod. Se ogni riga riporta la data di deploy, il campo smette di dire la verità su quali pagine sono cambiate e il file perde il suo valore come segnale di modifica.

Hreflang solo quando la lingua cambia davvero

Hreflang vale la pena aggiungerlo quando le pagine esistono in più lingue o regioni e ogni insieme deve linkare ogni altro membro. Un sito in una sola lingua che aggiunge un set hreflang genera rumore senza alcun significato aggiuntivo.

Quando aggiungi hreflang durante una migrazione, controlla che ogni URL alternativo restituisca una pagina attiva e che ogni pagina nell'elenco elenchi tutte le altre.

Cosa supporta l'evidenza e cosa no

Un 301 diretto è la base. Google ha dichiarato dal 2016 che i redirect 3xx non perdono più PageRank, quindi una mappa pulita a un salto non è dove avviene la perdita di valore.

La perdita è la discrepanza: un redirect che punta a una pagina non correlata può essere trattato come un soft 404 e un canonical che discorda dal redirect invia segnali misti. Nessuno al di fuori di Google può misurare la perdita con precisione, motivo per cui conti i domini che linkano e trattii il conteggio come l'esposizione piuttosto che come una previsione.

Prima del trasferimento, esegui toppages per il vecchio dominio (2 crediti) e refdomains sullo stesso dominio (2 crediti). Dopo il trasferimento, ripeti entrambi una volta che l'aggiornamento mensile è disponibile e confronta le due letture. Il nostro indice potrebbe richiedere un ciclo per notare il cambiamento. Non farti prendere dal panico al giorno 10. Mantieni il primo report come tua foto prima.

Un'utile precauzione pratica. Una mappa dei redirect che sembra ordinata in un foglio di calcolo può comunque fallire sul server, quindi testa i top 20 con un crawler come Screaming Frog e conferma che ciascuno restituisca un singolo 301 verso una pagina attiva.

Verificare la nuova mappa prima che vada online

Una mappa dei redirect è solo un foglio di calcolo finché un crawler non l'ha visitata. I controlli seguenti sono economici da eseguire e catturano errori che una revisione visiva non vede mai.

Leggi ogni codice di status, non solo la pagina

Richiedi ogni vecchio URL e leggi lo status che restituisce. Un singolo 301 verso una pagina attiva è ciò che vuoi. Un 302 dove dovrebbe esserci un 301, o una catena di tre salti, lascia l'esito al caso.

Screaming Frog e crawler simili possono eseguire l'intera lista ed esportare i codici in un foglio. Ordina per status e gestisci prima tutto ciò che non è un 301 o un 200.

Cerca le catene di redirect

Una catena si forma quando un redirect punta a una pagina che reindirizza di nuovo, spesso dopo un cambiamento nel trailing slash o nel prefisso lingua. Ogni salto extra è un'altra possibilità che il segnale vada perso e che la visita si rallenti.

Rimuovi le catene puntando il primo redirect direttamente all'indirizzo finale. È una piccola modifica per URL e rimuove un'intera classe di sorprese.

Confronta la sitemap con la mappa

Esporta la sitemap e l'elenco dei redirect, quindi controlla che nessuna voce della sitemap sia anche una sorgente di redirect. Ogni voce della sitemap dovrebbe essere una destinazione attiva e ogni vecchio indirizzo dovrebbe essere assente dalla sitemap.

Fai lo stesso con i link interni nel tuo template principale. Un link che punta ancora a un vecchio indirizzo aggiunge un salto per ogni visitatore e dice ai crawler che l'indirizzo vecchio conta ancora.