Dopo una migrazione URL, usa un’unica mappa dai vecchi ai nuovi URL per aggiornare i link pubblici, le dichiarazioni canonical, i reindirizzamenti e le voci della sitemap. Questo flusso di lavoro su Mac mostra come far concordare queste modifiche e verificare il risultato pubblicato.

In questo caso, una piccola raccolta di documenti HTML pubblici viene spostata in nuovi percorsi sullo stesso sito web. Tutti gli indirizzi e i nomi delle pagine usati negli esempi sono fittizi. Per completare l’intero flusso di lavoro, devi avere accesso al sistema di pubblicazione, alle relative impostazioni dei reindirizzamenti e alla proprietà pertinente di Search Console.

Cosa deve essere coerente dopo la migrazione?

Per ogni documento spostato, scegli una destinazione finale. I link che controlli devono puntare direttamente a questa destinazione, la destinazione deve dichiararsi canonical e la sitemap corrente deve elencare tale indirizzo. Il vecchio indirizzo deve reindirizzare a quello nuovo. Google descrive i reindirizzamenti e le annotazioni canonical come segnali di canonicalizzazione forti, mentre l’inclusione nella sitemap è un segnale più debole. Questi metodi possono rafforzarsi a vicenda, ma alla fine è Google a scegliere l’URL canonical. Indicazioni di Google sulla canonicalizzazione.

Questi meccanismi svolgono funzioni diverse. Un reindirizzamento gestisce una richiesta per un vecchio indirizzo. Un link pubblico determina dove andrà il lettore. Una dichiarazione canonical identifica l’URL preferito per un documento; WHATWG definisce questo significato per il tipo di link canonical. Una sitemap fornisce un elenco di URL preferiti per agevolarne la scoperta. Aggiornare uno di questi elementi non modifica gli altri. Standard HTML WHATWG: tipo di link canonical, Indicazioni di Google sulle sitemap.

Usa questa tabella di coerenza come verifica pratica di accettazione. È un flusso di lavoro derivato dalla documentazione, non un sistema di valutazione di Google.

Elemento Risultato atteso per il documento Colori fittizio
Vecchio indirizzo https://example.com/notes/colors.html reindirizza in modo permanente alla destinazione
Destinazione https://example.com/library/colors/ fornisce il documento Colori
Navigazione e link ai documenti Puntano direttamente a https://example.com/library/colors/
Canonical della destinazione Indica https://example.com/library/colors/
Voce nella sitemap corrente Elenca https://example.com/library/colors/

Crea un’unica mappa prima di modificare le singole impostazioni

Sul Mac, apri un foglio di calcolo o un editor di testo semplice e annota ogni vecchio indirizzo accanto alla destinazione prevista. Google consiglia di preparare una mappatura dai vecchi ai nuovi URL nell’ambito di uno spostamento. Conserva una copia dell’elenco originale, così la sostituzione delle voci della sitemap non cancellerà il promemoria degli indirizzi che devono ancora essere reindirizzati. Indicazioni di Google sullo spostamento di un sito.

Documento Vecchio percorso Percorso finale
Colori /notes/colors.html /library/colors/
Palette /notes/palette.html /library/palette/
Forme /notes/shapes.html /library/shapes/

Per ogni riga, annota dove devi apportare le modifiche: editor delle pagine, navigazione condivisa, impostazione canonical, impostazione dei reindirizzamenti e generatore della sitemap. Aggiungi colonne separate per verificare la risposta pubblica e l’ispezione in Search Console. In questo modo, l’indicazione vaga «aggiornare gli URL» diventa un insieme finito di modifiche e verifiche.

Controlla il contenuto della destinazione prima di accettare una mappatura. Se due vecchi documenti sono confluiti in un unico documento più utile, entrambi possono reindirizzare a quest’ultimo. Evita di inviare documenti non correlati a una pagina iniziale generica: Google avverte che i reindirizzamenti non pertinenti possono essere trattati come soft 404. Consigli di Google per la mappatura dei reindirizzamenti.

Aggiorna i link pubblici e controlla i percorsi relativi

Nell’editor di pubblicazione, usa la mappa per aggiornare la navigazione, gli indici dei documenti, i link ai documenti correlati e i link nel testo degli articoli. Se il sistema genera la navigazione dai record delle pagine, modifica i record di origine o il modello, invece di correggere ripetutamente il contenuto generato. Esamina ogni sostituzione prima di salvare, soprattutto nei casi in cui il vecchio percorso compare anche in esempi esplicativi.

La modifica di un percorso può cambiare la destinazione di un link relativo anche se il testo del link rimane identico. Lo standard URL WHATWG risolve i riferimenti relativi rispetto a un URL di base. Per gli esempi illustrativi qui sotto, supponiamo che il documento non abbia un override esplicito della base. Standard URL WHATWG.

URL del documento Valore del link Destinazione risolta
https://example.com/notes/colors.html palette.html https://example.com/notes/palette.html
https://example.com/library/colors/ palette.html https://example.com/library/colors/palette.html
https://example.com/library/colors/ /library/palette/ https://example.com/library/palette/

Queste risoluzioni fittizie sono state verificate con l’API JavaScript URL. Il valore palette.html, rimasto invariato, ora punta all’interno della directory Colori: una sostituzione del testo eseguita correttamente altrove non rileverebbe il problema. Per questa piccola raccolta, usare il percorso relativo alla radice previsto rende esplicita la destinazione. Se ti sposti su un host diverso, usa l’indirizzo assoluto corretto oppure verifica che ogni link relativo alla radice rimanga sull’host previsto.

Apri nel browser del Mac il documento Colori pubblicato e segui il link alla Palette. Controlla sia il documento visualizzato sia l’indirizzo finale. Ripeti il controllo per la navigazione condivisa e per eventuali link a sezioni. Se un link usa #swatches, verifica che la destinazione contenga ancora il corrispondente identificatore di sezione: la mappa dei percorsi, da sola, non può stabilirlo.

Imposta i canonical e i reindirizzamenti permanenti alla fonte

Per ogni nuovo documento HTML, imposta il canonical sull’URL assoluto finale. Google consiglia URL canonical assoluti e accetta l’elemento canonical HTML nell’elemento head del documento. Se il sistema di pubblicazione dispone di un campo canonical, inserisci l’indirizzo lì e controlla il codice generato. Istruzioni di Google per l’implementazione dei canonical.

Per la pagina Colori, il frammento seguente è un elemento di metadati da inserire nell’elemento head già esistente del documento; non è una pagina HTML completa:

<link rel="canonical" href="https://example.com/library/colors/">

Verifica se l’host invia anche un canonical tramite un’intestazione di risposta HTTP Link. Google supporta entrambi i metodi, ma consiglia di sceglierne uno, perché mantenerli entrambi può generare destinazioni in conflitto. Correggi il modello o l’impostazione che produce il valore, così la pubblicazione successiva non ripristinerà un vecchio indirizzo. Metodi di canonicalizzazione di Google.

Configura il vecchio indirizzo affinché restituisca un reindirizzamento permanente lato server verso la destinazione. RFC 9110 definisce 301 e 308 come reindirizzamenti permanenti e descrive la destinazione nell’intestazione Location. La distinzione riguarda anche la gestione del metodo della richiesta: 308 lo preserva, mentre 301 consente il comportamento storico da POST a GET. Per il normale recupero di documenti, Google considera entrambi segnali di reindirizzamento permanente. RFC 9110: semantica HTTP, Documentazione di Google sui reindirizzamenti.

La configurazione esatta dipende dall’host o dal sistema di pubblicazione. La modifica nel browser, da sola, non può creare una regola per la risposta HTTP. Se la piattaforma non può configurare reindirizzamenti lato server, usa la configurazione di hosting documentata o chiedi al gestore dell’hosting di implementare la mappa. Google documenta il reindirizzamento istantaneo con meta refresh come soluzione di ripiego quando i reindirizzamenti lato server non sono disponibili; consiglia i reindirizzamenti JavaScript solo se non è possibile adottare gli altri approcci. Una dichiarazione canonical, da sola, non porta il visitatore al nuovo indirizzo. Approcci ai reindirizzamenti supportati da Google.

Rigenera la sitemap usando le stesse destinazioni

Aggiorna la fonte della sitemap, quindi rigenerala. È facile perdere una correzione manuale apportata a un file generato alla build successiva. Per questa migrazione, la sitemap corrente deve contenere gli URL finali di Colori, Palette e Forme, al posto dei percorsi precedenti.

Google richiede URL assoluti completi e codifica UTF-8 per le sitemap. Se devi elencare soltanto pagine web, è supportata una sitemap di testo: un URL per riga, senza titoli né commenti. L’esempio fittizio completo con tre pagine sarebbe:

https://example.com/library/colors/
https://example.com/library/palette/
https://example.com/library/shapes/

Formati e requisiti delle sitemap secondo Google.

Se il sito genera già una sitemap XML, mantieni quel formato supportato e aggiorna le voci degli URL. Usa date di modifica accurate quando fornisci lastmod: Google afferma che questo valore deve riflettere aggiornamenti significativi della pagina. Non sostituire automaticamente tutte le date solo per far sembrare recente la sitemap. Indicazioni di Google sulle sitemap XML.

Verifica il risultato pubblico dal Mac

Controlla l’output distribuito, perché l’anteprima dell’editor non può stabilire quale sia la risposta HTTP all’indirizzo pubblico. Apri Terminale sul Mac. I seguenti comandi diagnostici usano indirizzi fittizi: prima di eseguirli, sostituiscili con i corrispondenti URL pubblici della tua mappa. Questi esempi non implicano alcun risultato di migrazione effettivamente verificato.

old_url='https://example.com/notes/colors.html'
new_url='https://example.com/library/colors/'

curl --silent --show-error --connect-timeout 10 --max-time 30 \
  --dump-header - --output /dev/null "$old_url"

curl --silent --show-error --connect-timeout 10 --max-time 30 \
  --location --max-redirs 5 --output /dev/null \
  --write-out 'status=%{http_code}\nfinal=%{url_effective}\nredirects=%{num_redirects}\n' \
  "$old_url"

curl --silent --show-error --connect-timeout 10 --max-time 30 \
  "$new_url"

Il primo comando mostra le intestazioni della risposta iniziale senza seguire il reindirizzamento. Il secondo segue i reindirizzamenti e indica lo stato finale, l’indirizzo e il numero di reindirizzamenti. Il terzo recupera il markup della destinazione da esaminare. Queste opzioni sono documentate nel manuale di curl.

Per una pagina mappata in modo lineare, aspettati un 301 o 308 iniziale con il Location previsto, seguito dall’indirizzo finale che fornisce correttamente il documento. Esamina il markup restituito per trovare il canonical. Leggi inoltre il documento nel browser: una risposta HTTP di successo, da sola, non dimostra che sia arrivato il contenuto giusto. Google consiglia di reindirizzare direttamente alla destinazione finale, senza creare catene. RFC 9110: codici di stato, Indicazioni di Google sullo spostamento di un sito.

Se una riga non supera la verifica, segui questo ordine diagnostico. In questo modo, le riparazioni restano legate a risultati osservabili.

Osservazione Azione successiva
Il vecchio URL reindirizza a una pagina non prevista Correggi la mappatura o la regola di reindirizzamento
Il reindirizzamento raggiunge un altro reindirizzamento Punta il vecchio indirizzo direttamente alla destinazione finale
La pagina corretta ha un vecchio canonical Correggi la fonte dei metadati e pubblica di nuovo
La navigazione porta ancora a un vecchio percorso Aggiorna il link di origine o il modello condiviso
La sitemap elenca ancora i vecchi percorsi Correggi i dati di input del generatore e rigenera la sitemap
Terminale segnala un timeout Ripeti il controllo dopo aver risolto il problema di connessione; annota la verifica come incompleta

Invia la sitemap e distingui i controlli in tempo reale dall’indicizzazione

In Search Console, seleziona la proprietà che copre i nuovi URL e usa il rapporto Sitemaps per inviare l’indirizzo pubblico della sitemap. Google documenta questo rapporto come metodo di invio che mostra anche gli errori di elaborazione. L’invio è un suggerimento per favorire la scoperta, non una garanzia di indicizzazione. Istruzioni di Google per l’invio delle sitemap.

Per ispezionare un nuovo documento, inserisci il suo URL completo nella barra di ispezione di Search Console. Usa il test in tempo reale per verificare l’accessibilità attuale e la potenziale idoneità all’indicizzazione. Per conoscere la scelta canonical di Google, consulta il risultato indicizzato e il relativo campo Canonical selezionato da Google. Il test in tempo reale non può prevedere la selezione del canonical. Strumento Controllo URL di Search Console.

Questo esempio modifica i percorsi sullo stesso host, quindi lo strumento Cambio di indirizzo non è applicabile. Google indica a chi pubblica contenuti che, per gli spostamenti dei percorsi, occorre implementare i reindirizzamenti e aggiornare le sitemap. Lo strumento è destinato agli spostamenti di dominio o sottodominio, dopo che il sito è stato trasferito e i reindirizzamenti sono attivi. Strumento Cambio di indirizzo di Search Console.

Conserva la mappa come registro di manutenzione. Segna una riga come completata solo dopo aver verificato la coerenza tra reindirizzamento pubblico, contenuto della destinazione, link, canonical e sitemap; annota separatamente le successive osservazioni sull’indicizzazione di Google. Mantieni i reindirizzamenti il più a lungo possibile: le indicazioni generali di Google sulle migrazioni consigliano almeno un anno. Usa gli indirizzi finali anche nelle modifiche future ai documenti. Indicazioni di Google sulle migrazioni.

Fonti