Reindirizzamento 301 vs 302: comprendere le differenze, l'impatto SEO e riuscire nella migrazione del dominio
Di CaptainDNS
Pubblicato il 16 marzo 2026
- 301 = reindirizzamento permanente, trasferisce il 100 % del ranking SEO verso la destinazione
- 302 = reindirizzamento temporaneo, Google continua a indicizzare l'URL di origine
- Una migrazione di dominio richiede 301 su ogni URL, non solo sulla radice
- I codici 307 e 308 esistono per preservare il metodo HTTP (POST, PUT)
- CaptainDNS Redirect Hosting gestisce i 301/302 con HTTPS automatico
Cambiare nome di dominio, unire due siti, passare da HTTP a HTTPS: tutte queste operazioni dipendono dai reindirizzamenti HTTP. Configurati male, causano una perdita dal 30 al 50 % del traffico organico nelle settimane successive alla migrazione. Configurati bene, trasmettono l'integralità della Sua autorità SEO verso la nuova destinazione.
La domanda "devo usare un 301 o un 302?" torna costantemente nei forum SEO e nelle discussioni tra sviluppatori. La risposta dipende dal contesto, ma le conseguenze di una scelta sbagliata sono reali: Google indicizza l'URL sbagliato, il PageRank si diluisce, i backlink perdono il loro valore. Secondo uno studio di Moz condotto su 30 000 domini, il 12 % delle migrazioni di dominio utilizza reindirizzamenti 302 al posto di 301, causando una perdita media di traffico organico due volte superiore rispetto alle migrazioni correttamente configurate.
Questa guida copre i 4 codici di reindirizzamento HTTP, spiega in dettaglio l'impatto SEO di ciascuno e fornisce una checklist completa per realizzare con successo una migrazione di dominio. Che gestisca un sito vetrina o un portale di 50 000 pagine, i principi restano gli stessi.
Ultima precisazione: questa guida tratta i reindirizzamenti lato server (codici di stato HTTP). I reindirizzamenti JavaScript o i tag meta refresh non vengono trattati qui perché presentano problemi fondamentali per il crawl e l'indicizzazione. Per i casi d'uso marketing (vanity URL, link tracking, codici QR), una guida complementare è disponibile nella sezione "Guide correlate" in fondo all'articolo.
I 4 codici di reindirizzamento HTTP
Il protocollo HTTP definisce quattro codici di reindirizzamento principali. Ciascuno comunica un'intenzione diversa al browser e ai motori di ricerca.
301 Moved Permanently
Il codice 301 significa che la risorsa è stata spostata in modo permanente verso un nuovo URL. Il server risponde con un'intestazione Location contenente la destinazione.
HTTP/1.1 301 Moved Permanently
Location: https://captaindns.com/it/tools
Comportamento del browser: il browser memorizza nella cache il reindirizzamento e reindirizza automaticamente le future richieste verso la destinazione, senza ripassare dal server di origine. Questa cache persiste anche dopo la chiusura del browser.
Definito nella RFC 7231, sezione 6.4.2, il codice 301 consente ai client HTTP di trasformare una richiesta POST in GET durante il reindirizzamento. Questo comportamento, ereditato dalle prime implementazioni HTTP, è la ragione per cui è stato creato il codice 308.
302 Found
Il codice 302 significa che la risorsa è temporaneamente disponibile a un altro URL. Il server risponde allo stesso modo:
HTTP/1.1 302 Found
Location: https://captaindns.com/it/maintenance
Comportamento del browser: il browser non memorizza nella cache il reindirizzamento. Ogni richiesta ripassa dal server di origine, che può restituire una destinazione diversa o cessare di reindirizzare.
Definito nella RFC 7231, sezione 6.4.3, il codice 302 ha una storia complicata. In HTTP/1.0, significava "Moved Temporarily". I browser hanno storicamente trasformato le richieste POST in GET durante un 302, il che non corrispondeva alla specifica. Il codice 303 (See Other) è stato creato per formalizzare questo comportamento, è il codice 307 per preservare il metodo HTTP.
307 Temporary Redirect
Il codice 307 è l'equivalente rigoroso del 302, ma con una garanzia: il metodo HTTP viene preservato. Se il client invia un POST, il reindirizzamento rinvia un POST verso la destinazione.
HTTP/1.1 307 Temporary Redirect
Location: https://captaindns.com/api/v2/submit
Questo codice è definito nella RFC 7231, sezione 6.4.7. Viene utilizzato principalmente per i moduli e le API REST dove la preservazione del metodo è critica. Per i reindirizzamenti di pagine web classiche (GET), la differenza tra 302 e 307 è nulla.
308 Permanent Redirect
Il codice 308 è l'equivalente rigoroso del 301, ma con la stessa garanzia del 307: il metodo HTTP viene preservato.
HTTP/1.1 308 Permanent Redirect
Location: https://captaindns.com/api/v2/submit
Definito nella RFC 7238, il codice 308 è la scelta corretta per i reindirizzamenti permanenti di API dove il metodo HTTP deve essere conservato. Per i reindirizzamenti di pagine web (GET), 301 e 308 sono funzionalmente identici.
Tabella comparativa dei 4 codici
| Codice | Tipo | Metodo HTTP preservato? | Cache del browser? | Trasferimento SEO? |
|---|---|---|---|---|
| 301 | Permanente | No (POST può diventare GET) | Si | Si (100 %) |
| 302 | Temporaneo | No (POST può diventare GET) | No | Parziale (Google indicizza l'origine) |
| 307 | Temporaneo | Si | No | Parziale (stesso comportamento del 302) |
| 308 | Permanente | Si | Si | Si (stesso comportamento del 301) |
In pratica, per i reindirizzamenti di pagine web (richieste GET), solo i codici 301 e 302 sono pertinenti. I codici 307 e 308 sono riservati ai contesti tecnici dove la preservazione del metodo HTTP è necessaria.
Reindirizzamenti lato server vs JavaScript
I codici 301, 302, 307 e 308 sono reindirizzamenti lato server: il server invia un'intestazione HTTP Location e il browser la segue immediatamente. Ma esistono anche reindirizzamenti lato client, implementati in JavaScript o tramite un tag meta refresh.
Reindirizzamenti lato server (HTTP): Google li rileva e li segue immediatamente durante il crawl. Il trasferimento di segnali SEO è affidabile e rapido. E il metodo raccomandato da Google Search Central per qualsiasi cambio di URL.
Reindirizzamenti JavaScript (window.location, window.location.replace): Google deve prima scaricare la pagina HTML, eseguire il JavaScript nel suo motore di rendering (basato su Chromium), poi scoprire il reindirizzamento. Questo processo aggiunge un ritardo significativo. Google classifica questo metodo come ultima risorsa, da utilizzare solo quando il reindirizzamento lato server è impossibile.
Reindirizzamenti meta refresh (<meta http-equiv="refresh" content="0;url=...">): Google può seguirli, ma li sconsiglia formalmente. Il comportamento è simile a un reindirizzamento JavaScript: la pagina deve essere scaricata e analizzata prima che il reindirizzamento venga rilevato.
| Metodo | Rilevamento da Google | Trasferimento SEO | Caso d'uso |
|---|---|---|---|
| Lato server (301/302) | Immediato | Completo (301) o parziale (302) | Migrazioni, cambi di URL |
| JavaScript | Dopo il rendering | Incerto, spesso parziale | SPA (Single Page Applications) |
| Meta refresh | Dopo il download | Sconsigliato da Google | Nessun caso raccomandato |
Il rischio principale dei reindirizzamenti JavaScript: se il rendering della pagina fallisce (errore JS, timeout, risorsa bloccata), Google semplicemente non vede il reindirizzamento. La pagina di origine resta indicizzata, la destinazione viene ignorata. Per le Single Page Applications (SPA) dove il reindirizzamento lato server e tecnicamente impossibile, JavaScript e l'unica risorsa, ma allora bisogna verificare regolarmente che Googlebot rilevi correttamente il reindirizzamento (tramite lo strumento di ispezione URL in Search Console).
Come trattano i browser i reindirizzamenti?
Quando un browser riceve un codice di reindirizzamento, effettua automaticamente una nuova richiesta verso l'URL indicato nell'intestazione Location. Questo processo è trasparente per l'utente: nota solo un leggero ritardo di caricamento.
Per i reindirizzamenti 301, il browser memorizza la corrispondenza in una cache locale. Le visite successive al vecchio URL vengono reindirizzate direttamente dal browser, senza contattare il server di origine. Questa cache è persistente: sopravvive alla chiusura del browser e viene svuotata solo con una cancellazione manuale della cache o la scadenza definita dalle intestazioni Cache-Control.
Per i reindirizzamenti 302, il browser non memorizza nella cache la corrispondenza. Ogni visita al vecchio URL attiva una richiesta verso il server di origine, che può rispondere diversamente ogni volta. E questo comportamento che rende il 302 adatto ai reindirizzamenti dinamici (geolocalizzazione, test A/B, campagne temporanee).
Questa differenza di cache ha un impatto diretto sulle prestazioni. Un 301 risparmia una richiesta di rete a ogni visita successiva. Un 302 aggiunge sistematicamente la latenza di un viaggio di andata e ritorno HTTP aggiuntivo.
Altri codici di stato HTTP da conoscere
Tre codici HTTP vengono talvolta confusi con i reindirizzamenti:
- 200 OK: la pagina esiste e restituisce contenuto. Nessun reindirizzamento. Se la pagina mostra "Stai per essere reindirizzato...", si tratta di un reindirizzamento lato client (JavaScript o meta refresh), non di un reindirizzamento HTTP.
- 404 Not Found: la pagina non esiste. Se elimina una pagina senza configurare un reindirizzamento, i visitatori e Googlebot ricevono un 404. I backlink verso questa pagina perdono tutto il loro valore.
- 410 Gone: la pagina è stata eliminata definitivamente e non sarà sostituita. Google tratta il 410 come un segnale forte per rimuovere la pagina dall'indice. Utilizzi il 410 quando non c'e una pagina di destinazione pertinente per un reindirizzamento.
301 vs 302: impatto SEO dettagliato
Questa è la sezione più importante di questa guida. La differenza tecnica tra 301 e 302 sembra minore (permanente vs temporaneo), ma le conseguenze SEO sono significative. Comprendere queste differenze è essenziale prima di configurare qualsiasi reindirizzamento.
Trasferimento di PageRank e autorità
Il PageRank è il punteggio di autorità che Google assegna a ogni pagina in base ai link in entrata. Quando un sito A linka la Sua pagina, le trasmette una frazione del proprio PageRank.
Con un 301: Google trasferisce il 100 % del PageRank dal vecchio URL al nuovo. Non è sempre stato così. Prima del 2016, Google applicava una penalità del 15 % sul PageRank trasmesso tramite un 301. Da un aggiornamento confermato da Gary Illyes del team Google Search, questa penalità è stata eliminata. Un 301 trasferisce ormai l'integralità dell'autorità.
Con un 302: Google non trasferisce il PageRank verso la destinazione. La logica è semplice: se il reindirizzamento è temporaneo, l'URL di origine è destinato a tornare. Google conserva quindi l'autorità sull'URL di origine. Il problema sorge quando un 302 resta attivo per mesi o anni. Google finisce per trattarlo come un 301 di fatto, ma il tempo è imprevedibile e il periodo di transizione causa una perdita di posizionamento.
Indicizzazione e canonicalizzazione
La scelta 301 vs 302 determina quale URL Google mostra nei suoi risultati:
Con un 301: Google rimuove il vecchio URL dal suo indice e indicizza la destinazione. I risultati di ricerca mostrano il nuovo URL. Questo processo richiede generalmente da qualche giorno a qualche settimana a seconda della frequenza di crawl.
Con un 302: Google continua a indicizzare l'URL di origine e lo mostra nei suoi risultati. La destinazione è nota a Google, ma non viene considerata come la versione canonica. Risultato: i Suoi visitatori vedono il vecchio URL in Google, cliccano, vengono reindirizzati alla nuova pagina, ma i segnali SEO (backlink, anzianità, autorità) restano associati al vecchio URL.
Cache del browser e conteggio delle visite
Il 301 viene memorizzato nella cache dal browser. Dopo la prima visita, il browser reindirizza direttamente alla destinazione senza contattare il server di origine. Conseguenza: non può tracciare il numero di reindirizzamenti, poiché le visite successive non passano più dal Suo server.
Il 302 non viene memorizzato nella cache. Ogni visita passa dal server di origine, che può contare le richieste, registrare le informazioni del visitatore e persino cambiare la destinazione al volo. Per questo le vanity URL e i link di tracking utilizzano 302.
Catene di reindirizzamento: la perdita silenziosa
Una catena di reindirizzamento si produce quando un URL reindirizza verso un secondo URL, che a sua volta reindirizza verso un terzo, e così via. Ogni salto nella catena consuma una richiesta di crawl e aggiunge latenza.
Google segue le catene di reindirizzamento, ma con limiti. John Mueller ha confermato che Googlebot segue generalmente 5 reindirizzamenti prima di abbandonare. Oltre, la pagina finale non viene ne crawlata ne indicizzata.
Anche sotto i 5 salti, ogni reindirizzamento intermedio diluisce potenzialmente il segnale SEO. La raccomandazione è limitare ogni catena a 2 salti al massimo: l'origine reindirizza verso la destinazione finale, punto.
Può verificare la presenza di catene di reindirizzamento sulle Sue pagine con il Page Crawl Checker.
Miti vs realta
Mito: il 302 penalizza la SEO. Realtà: il 302 non penalizza direttamente la SEO. Semplicemente non è progettato per trasferire l'autorità. Google non applica sanzioni, ma indicizza l'URL sbagliato e conserva l'autorità nel posto sbagliato. Il risultato assomiglia a una penalità, ma è un problema di configurazione.
Mito: un 301 fa perdere PageRank. Realtà: dal 2016, un 301 trasferisce il 100 % del PageRank. Questa informazione è stata confermata da Google in molteplici occasioni. La vecchia penalità del 15 % non esiste più.
Mito: Google tratta i 302 di lunga durata come 301. Realtà: è parzialmente vero. Google può, dopo un lungo periodo, decidere di trattare un 302 come un 301. Ma il tempo è imprevedibile (settimane, mesi) e durante la transizione, la Sua SEO ne risente. Non conti su questo comportamento. Utilizzi il codice corretto fin dall'inizio.
Mito: i reindirizzamenti lato client (JavaScript, meta refresh) sono equivalenti. Realtà: no. Google può seguire i reindirizzamenti JavaScript, ma con un ritardo aggiuntivo (il rendering della pagina deve essere effettuato dal motore di rendering). I meta refresh sono sconsigliati da Google. Solo i reindirizzamenti lato server (301, 302, 307, 308) vengono elaborati immediatamente e in modo affidabile.
Mito: i 301 sono istantanei per la SEO. Realtà: no. Dopo aver configurato un 301, Google deve ricrawlare il vecchio URL, scoprire il reindirizzamento, poi aggiornare il suo indice. Questo processo richiede da qualche giorno a diverse settimane a seconda della frequenza di crawl del Suo sito. Le pagine con molto traffico e molti backlink vengono ricrawlate più rapidamente delle pagine profonde con poche visite.
HTTPS e reindirizzamenti: un prerequisito indispensabile
Il server che ospita i reindirizzamenti deve imperativamente supportare HTTPS. Se un backlink punta a https://vecchio.captaindns.com/page è il server di reindirizzamento supporta solo HTTP, il browser mostrera un errore di certificato al posto del reindirizzamento.
Con CaptainDNS Redirect Hosting, il certificato TLS viene generato e rinnovato automaticamente tramite Let's Encrypt. Non è necessaria alcuna configurazione manuale. Il server di reindirizzamento risponde in HTTPS su tutti i domini configurati.
Per le configurazioni manuali sul proprio server (Nginx, Apache, Caddy), si assicuri che:
- Il certificato TLS copra tutti i domini di origine (vecchio dominio, varianti www, sottodomini).
- Il rinnovo del certificato sia automatizzato (Let's Encrypt con certbot o acme.sh).
- I reindirizzamenti HTTP verso HTTPS siano configurati oltre ai reindirizzamenti di dominio.
301, canonical o entrambi? Scegliere l'approccio corretto
I reindirizzamenti 301 e i tag rel=canonical sono due strumenti che servono un obiettivo simile: indicare a Google quale URL è la versione preferita. Ma funzionano in modo molto diverso e non si utilizzano nelle stesse situazioni.
Quando usare un 301 al posto di un canonical tag?
La distinzione è semplice: il 301 reindirizza fisicamente il visitatore, il canonical no.
Un reindirizzamento 301 sopprime l'accesso all'URL di origine. Il visitatore che digita il vecchio URL viene inviato automaticamente alla destinazione. La vecchia pagina non è più accessibile. E la scelta corretta quando l'URL di origine non ha più ragione di esistere.
Un canonical tag (rel=canonical) lascia entrambi gli URL accessibili. Il visitatore può ancora accedere all'URL di origine e vederne il contenuto. Il canonical è un'indicazione a Google: tra queste due pagine con contenuto identico o simile, ecco quella che devi indicizzare. Google può seguire questa indicazione o ignorarla.
| Criterio | Reindirizzamento 301 | Canonical tag |
|---|---|---|
| Il visitatore viene reindirizzato? | Si | No, entrambe le pagine sono accessibili |
| Segnale per Google | Direttiva forte (obbligatoria) | Indicazione (suggerimento, può essere ignorata) |
| Entrambi gli URL esistono? | No, solo la destinazione è accessibile | Si, entrambi restano online |
| Trasferimento di PageRank | 100 % verso la destinazione | Google consolida i segnali sull'URL canonico |
| Caso d'uso principale | URL eliminato, migrazione, cambio definitivo | Contenuto duplicato, parametri di URL, versioni paginate |
In sintesi: se il vecchio URL non serve più, utilizzi un 301. Se il vecchio URL ha una ragione d'essere (versione stampabile, pagina con parametri di ordinamento, variante regionale), utilizzi un canonical.
Combinare 301 e canonical
Dopo una migrazione di dominio, Google raccomanda di utilizzare entrambi i segnali insieme quando possibile. Il 301 reindirizza fisicamente i visitatori e i bot. Il canonical tag sulla pagina di destinazione rafforza il segnale confermando che questo URL è la versione preferita.
Concretamente, dopo aver configurato i reindirizzamenti 301 dal vecchio dominio al nuovo, aggiunga su ogni pagina di destinazione un canonical tag che punti a se stesso:
<link rel="canonical" href="https://captaindns.com/it/tools" />
Questo doppio segnale è particolarmente utile quando il contenuto è accessibile tramite percorsi multipli (vecchio dominio reindirizzato, variante www, versione HTTP). Google riceve un messaggio coerente da tutte le fonti: la destinazione è effettivamente l'URL canonico.
La combinazione 301 + canonical non è obbligatoria, ma accelera la convergenza nell'indice di Google e riduce il rischio che Google scelga l'URL sbagliato come versione canonica durante il periodo di transizione.
Quando usare un 301?
Il 301 è la scelta predefinita per ogni reindirizzamento definitivo. Ecco i casi d'uso più frequenti.
Migrazione di dominio definitiva
Cambia nome di dominio. Il vecchio dominio non sarà più utilizzato per contenuti. Ogni URL del vecchio dominio deve essere reindirizzato con 301 verso il suo equivalente sul nuovo dominio.
vecchio-sito.captaindns.com/blog/article-1
301 captaindns.com/it/blog/article-1
Consolidamento di più domini
Possiede diversi domini (varianti ortografiche, estensioni paese, domini marketing) e desidera concentrare l'autorità SEO su uno solo.
captaindns.fr 301 captaindns.com
captaindns.de 301 captaindns.com
Cambio di URL permanente
Riprogettazione del sito, cambio di CMS, nuova architettura di URL. I vecchi URL non esistono più e non torneranno.
captaindns.com/products/dns-check
301 captaindns.com/it/tools/dns/test-propagation
Passaggio da HTTP a HTTPS
Il passaggio da HTTP a HTTPS è permanente. Tutti gli URL HTTP devono essere reindirizzati con 301 verso il loro equivalente HTTPS.
http://captaindns.com/it/tools
301 https://captaindns.com/it/tools
Naked domain verso www (o viceversa)
Sceglie una versione canonica del Suo dominio. L'altra versione reindirizza con 301.
www.captaindns.com 301 captaindns.com
o viceversa:
captaindns.com 301 www.captaindns.com
Tabella riepilogativa: casi d'uso 301
| Situazione | Esempio | Perché 301? |
|---|---|---|
| Migrazione di dominio | vecchio.captaindns.com verso captaindns.com | Il dominio di origine non servira più contenuti |
| Consolidamento multi-dominio | captaindns.fr verso captaindns.com | Concentrare l'autorità SEO su un unico dominio |
| Cambio di URL (riprogettazione) | /products/ verso /it/tools/ | La vecchia struttura di URL viene abbandonata |
| HTTP verso HTTPS | http:// verso https:// | Il passaggio a HTTPS è definitivo |
| www vs senza www | www.captaindns.com verso captaindns.com | Una sola versione canonica del dominio |
Quando usare un 302?
Il 302 è la scelta corretta quando il reindirizzamento è temporaneo: prevede di ristabilire l'URL di origine al suo stato originale.
Campagne marketing temporanee
Crea un vanity URL per una campagna limitata nel tempo. Il reindirizzamento sarà disattivato alla fine della campagna.
promo.captaindns.com 302 captaindns.com/it/pricing
(durante la campagna di marzo 2026)
Test A/B
Reindirizza una frazione del traffico verso una variante di pagina per testare un nuovo design o un nuovo contenuto. Il reindirizzamento sarà rimosso una volta terminato il test.
Manutenzione pianificata
Il Suo sito è in manutenzione. Reindirizza temporaneamente il traffico verso una pagina informativa. Il sito tornera al suo stato normale dopo la manutenzione.
captaindns.com/it/tools 302 captaindns.com/it/maintenance
Geolocalizzazione e rilevamento della lingua
Reindirizza i visitatori verso una versione localizzata del Suo sito in base al loro indirizzo IP o alla lingua del browser. Il reindirizzamento è condizionale è non deve essere memorizzato nella cache, poiché lo stesso utente potrebbe visitare da un altro paese.
captaindns.com 302 captaindns.com/it/ (visitatore italiano)
captaindns.com 302 captaindns.com/en/ (visitatore inglese)
Reindirizzamenti condizionali (mobile/desktop)
Reindirizza i visitatori mobili verso una versione dedicata. Questa pratica è sempre meno comune (il design responsive l'ha ampiamente sostituita), ma esiste ancora su alcuni siti.
Tabella riepilogativa: casi d'uso 302
| Situazione | Esempio | Perché 302? |
|---|---|---|
| Campagna marketing | promo.captaindns.com verso landing page | Reindirizzamento temporaneo, sarà disattivato |
| Test A/B | 50 % del traffico verso variante B | Test limitato nel tempo |
| Manutenzione | Sito verso pagina di manutenzione | Il sito tornera |
| Geolocalizzazione | Radice verso versione locale | Condizionale, non deve essere memorizzato nella cache |
| Reindirizzamento mobile | Sito verso versione mobile | Condizionale in base al dispositivo |
Migrazione di dominio: la checklist completa
La migrazione di dominio è l'operazione più rischiosa nella SEO. Ecco la checklist completa per minimizzare le perdite.
Prima della migrazione: audit e inventario
1. Elencare tutti gli URL indicizzati
Esporti la lista completa degli URL indicizzati da Google Search Console (rapporto "Pagine"). Completi con un crawl completo del Suo sito (Screaming Frog, Sitebulb o qualsiasi altro crawler).
L'obiettivo: avere un inventario esaustivo di ogni URL che riceve traffico o backlink.
2. Identificare le pagine ad alto valore
Classifichi i Suoi URL per traffico organico (Google Analytics) e per numero di backlink (Ahrefs, Moz, Semrush). Il 20 % di pagine che genera l'80 % del traffico e la Sua priorità assoluta. Qualsiasi errore di reindirizzamento su queste pagine avrà un impatto immediato e visibile.
3. Creare il piano di reindirizzamento 1:1
Ogni URL del vecchio dominio deve corrispondere a un URL sul nuovo dominio. Nessun reindirizzamento generico verso la homepage. Una tabella semplice e sufficiente:
| URL di origine | URL di destinazione | Stato |
|---|---|---|
| vecchio.captaindns.com/ | captaindns.com/it/ | Da configurare |
| vecchio.captaindns.com/blog/article-1 | captaindns.com/it/blog/article-1 | Da configurare |
| vecchio.captaindns.com/contact | captaindns.com/it/contact | Da configurare |
Se alcune pagine non hanno equivalente sul nuovo dominio, le reindirizzi verso la pagina più pertinente (non la homepage per impostazione predefinita).
4. Verificare il contenuto del nuovo dominio
Prima di attivare i reindirizzamenti, si assicuri che ogni pagina di destinazione esista e funzioni. Un reindirizzamento 301 verso una pagina 404 è peggio che non avere reindirizzamento: Google vede una pagina di errore e declassa l'URL.
5. Eseguire il backup dei dati esistenti
Prima di qualsiasi modifica, esporti uno snapshot completo:
- Export CSV di tutti gli URL indicizzati da Search Console
- Export delle posizioni di ricerca (Semrush, Ahrefs o altro strumento di tracking)
- Export dei backlink del vecchio dominio
- Screenshot delle statistiche di traffico organico degli ultimi 90 giorni
Questi dati serviranno come riferimento per misurare l'impatto della migrazione e rilevare anomalie dopo il passaggio.
Configurare i reindirizzamenti 301
5. Implementare i reindirizzamenti su ogni URL
La regola fondamentale: ogni URL deve essere reindirizzato individualmente. Reindirizzare solo la radice (vecchio.captaindns.com verso captaindns.com) non è sufficiente. Le pagine profonde, gli articoli del blog, le schede prodotto devono avere ciascuno il proprio reindirizzamento.
Se il nuovo sito conserva la stessa struttura di URL, può utilizzare una regola di path forwarding. Il percorso del vecchio URL viene automaticamente aggiunto alla destinazione:
vecchio.captaindns.com/* 301 captaindns.com/*
Con CaptainDNS Redirect Hosting, attivi l'opzione "Path forwarding" per trasmettere automaticamente il percorso dell'URL di origine verso la destinazione.
6. Gestire le 4 varianti di ogni URL
Ogni URL esiste potenzialmente in 4 versioni:
http://vecchio.captaindns.com/pagehttps://vecchio.captaindns.com/pagehttp://www.vecchio.captaindns.com/pagehttps://www.vecchio.captaindns.com/page
Tutte e 4 le versioni devono portare alla stessa destinazione. Dimenticare una variante significa lasciare backlink senza reindirizzamento.
Verificare il DNS
7. Configurare i record DNS
Affinché i reindirizzamenti funzionino, il dominio di origine deve risolvere verso il server di reindirizzamento. Se utilizza CaptainDNS Redirect Hosting, crei un record CNAME o A/AAAA che punta al servizio di reindirizzamento.
8. Verificare la propagazione DNS
Dopo aver modificato i record DNS, verifichi che la propagazione sia effettiva in tutte le regioni con il test di propagazione DNS. La propagazione completa può richiedere da qualche minuto a 48 ore a seconda del TTL precedente.
Google Search Console: strumento Change of Address
9. Dichiarare il cambio in Google Search Console
Google fornisce uno strumento dedicato in Search Console: "Change of Address" (Impostazioni > Cambio di indirizzo). Questo strumento:
- Verifica che i reindirizzamenti 301 siano correttamente configurati
- Accelera l'aggiornamento dell'indice di Google
- Trasferisce i segnali dal vecchio dominio al nuovo
Prerequisito: entrambi i domini (vecchio e nuovo) devono essere verificati in Google Search Console.
10. Inviare la nuova sitemap
Invii la sitemap XML del nuovo dominio in Google Search Console. Verifichi che tutti gli URL della sitemap restituiscano un codice 200. Rimuova la sitemap del vecchio dominio una volta che la migrazione è terminata e l'indice è aggiornato.
Monitoraggio post-migrazione
11. Sorvegliare il traffico organico (30/60/90 giorni)
Un calo temporaneo del traffico organico (dal 10 al 20 %) è normale nelle 2-4 settimane successive a una migrazione. Oltre, c'e un problema. Sorvegli:
- Settimana 1-2: Google inizia a crawlare il nuovo dominio. Il traffico può calare dal 10 al 30 %.
- Settimana 3-4: il traffico dovrebbe stabilizzarsi e iniziare a risalire.
- Mese 2-3: il traffico dovrebbe tornare al livello pre-migrazione, o addirittura superarlo se il nuovo sito è di migliore qualità.
12. Verificare gli errori in Search Console
Consulti il rapporto "Pagine" in Google Search Console per identificare errori 404, errori di reindirizzamento e problemi di indicizzazione. Corregga immediatamente gli URL che restituiscono errori.
13. Monitorare i backlink
Verifichi che i backlink del vecchio dominio vengano correttamente reindirizzati verso il nuovo. Utilizzi Ahrefs o uno strumento simile per identificare i backlink che restituiscono un errore 404 invece di un reindirizzamento 301.
14. Verificare le posizioni di ricerca
Segua le Sue parole chiave strategiche in uno strumento di tracciamento delle posizioni (Semrush, Ahrefs, Sistrix). Confronti le posizioni prima e dopo la migrazione. Una parola chiave che perde più di 10 posizioni dopo 4 settimane indica probabilmente un errore di reindirizzamento sulla pagina corrispondente.
Crei una tabella di monitoraggio con le Sue 50 parole chiave più importanti:
| Parola chiave | Posizione prima | Posizione G+7 | Posizione G+30 | Posizione G+90 |
|---|---|---|---|---|
| reindirizzamento dns | 5 | 8 | 6 | 4 |
| test propagazione dns | 3 | 7 | 4 | 3 |
| verifica email spf | 12 | 18 | 14 | 11 |
Un rialzo progressivo e segno che la migrazione si svolge correttamente. Una stagnazione a G+30 richiede un'indagine (reindirizzamenti mancanti, contenuto modificato, problemi tecnici).
Durata di mantenimento dei reindirizzamenti
14. Per quanto tempo mantenere i reindirizzamenti?
Google raccomanda di mantenere i reindirizzamenti 301 in modo permanente se possibile. In pratica:
- Minimo 6 mesi: al di sotto, Google non ha avuto il tempo di ricrawlare tutte le Sue pagine e aggiornare il suo indice.
- Raccomandato 1 anno: la grande maggioranza dei segnali SEO sarà stata trasferita.
- Ideale: permanente: finché il vecchio dominio è attivo, i reindirizzamenti devono funzionare. I backlink su siti di terze parti continueranno a puntare verso il vecchio dominio per anni.
Se lascia scadere il vecchio dominio, i reindirizzamenti ovviamente cessano di funzionare. I backlink che puntavano verso il vecchio dominio restituiranno un errore DNS. Per questo si raccomanda di conservare il vecchio dominio e rinnovarne la registrazione il più a lungo possibile.
Un rischio supplementare esiste: se il vecchio dominio scade e un terzo lo acquista, può recuperare i backlink che ancora puntavano al vecchio dominio. Nel migliore dei casi, mostra contenuto senza relazione. Nel peggiore, sfrutta la reputazione dei vecchi backlink per ospitare contenuto malevolo o spam. Rinnovi la registrazione del vecchio dominio per almeno 3 anni dopo la migrazione.
Pianificazione settimana per settimana
Una migrazione di dominio si prepara con diverse settimane di anticipo. Ecco un calendario tipo per strutturare le fasi ed evitare dimenticanze.
| Settimana | Azione | Verifica |
|---|---|---|
| S-4 | Audit completo degli URL, inventario dei backlink | Lista esaustiva esportata |
| S-3 | Configurare i reindirizzamenti 301 sul server | Testare ogni reindirizzamento con curl |
| S-2 | Dichiarare il nuovo dominio in Search Console | Verifica di proprietà validata |
| S-1 | Ultimi test, backup della sitemap del vecchio dominio | Tutti i reindirizzamenti funzionano |
| G-0 | Attivare i reindirizzamenti, inviare il Change of Address | Verificare le prime ore in tempo reale |
| S+1 | Monitorare l'indicizzazione è il traffico quotidianamente | Search Console è Analytics consultati ogni giorno |
| S+4 | Primo bilancio a 30 giorni | Confronto del traffico prima e dopo la migrazione |
| S+8 | Secondo bilancio a 60 giorni | Stabilizzazione attesa del traffico organico |
| S+12 | Bilancio finale a 90 giorni | Decisione: conservare o adeguare i reindirizzamenti |
Questo calendario è indicativo. Per i siti voluminosi (diverse migliaia di pagine), preveda una settimana aggiuntiva per l'audit e il mapping degli URL.
Caso reale: migrazione da HTTP a HTTPS
Il passaggio da HTTP a HTTPS è la migrazione più frequente. Google considera HTTP e HTTPS come due siti distinti. Ogni URL HTTP deve essere reindirizzato con 301 verso il suo equivalente HTTPS.
Il processo è identico a un cambio di dominio classico:
- Ottenere un certificato TLS per il Suo dominio (Let's Encrypt, o qualsiasi altro fornitore)
- Configurare il server per rispondere in HTTPS
- Reindirizzare ogni URL HTTP con 301 verso HTTPS (non solo la homepage)
- Aggiornare i link interni per puntare agli URL HTTPS
- Dichiarare la versione HTTPS in Google Search Console
- Inviare la sitemap con gli URL HTTPS
Errore comune: reindirizzare solo la homepage HTTP verso HTTPS e dimenticare le pagine interne. Risultato: le pagine profonde restano accessibili in HTTP, Google le considera come duplicati, e l'autorità SEO viene frammentata tra le due versioni.
Punto importante: Google Search Console tratta HTTP e HTTPS come proprietà distinte. Deve inviare entrambe le versioni (proprietà HTTP e proprietà HTTPS) per avere una vista completa dell'indicizzazione durante la transizione. Utilizzi lo strumento Change of Address per accelerare il processo.
Impatto sul crawl budget e i Core Web Vitals
I reindirizzamenti non influiscono solo sull'indicizzazione e sul trasferimento di autorità. Hanno anche un impatto misurabile su due aspetti tecnici della SEO: il budget di crawl e le prestazioni di caricamento.
Crawl budget e reindirizzamenti
Googlebot dispone di un budget di crawl limitato per ogni sito: un numero di pagine che può esplorare in un intervallo di tempo dato. Questo budget dipende dalla dimensione del sito, dalla sua popolarità e dalla capacità del server di rispondere rapidamente.
Ogni reindirizzamento consuma un'unita di questo budget. Quando Googlebot incontra un 301, conta una richiesta per l'URL di origine (che restituisce il reindirizzamento) poi una seconda richiesta per la destinazione. Una catena di 3 reindirizzamenti consuma quindi 4 richieste per una sola pagina di contenuto.
Per i siti piccoli (qualche centinaio di pagine), l'impatto è trascurabile. Per i siti voluminosi con migliaia di reindirizzamenti attivi, il consumo di budget di crawl può diventare significativo. Googlebot passa del tempo a seguire reindirizzamenti invece di crawlare contenuto nuovo.
Raccomandazioni:
- Minimizzi il numero di reindirizzamenti sulle pagine ad alto traffico e alto valore SEO
- Elimini le catene di reindirizzamenti puntando direttamente alla destinazione finale
- Dopo una migrazione, una volta aggiornato l'indice (6-12 mesi), i reindirizzamenti consumano meno budget di crawl poiché Googlebot impara progressivamente i nuovi URL
Impatto sui Core Web Vitals
I Core Web Vitals sono le metriche di prestazione utente misurate da Google: LCP (Largest Contentful Paint), INP (Interaction to Next Paint) e CLS (Cumulative Layout Shift). Queste metriche influenzano il posizionamento dal 2021.
Ogni reindirizzamento aggiunge un viaggio di andata e ritorno nella rete (RTT) tra il browser e il server. In pratica, questo rappresenta da 100 a 300 ms aggiuntivi per salto, a seconda della latenza di rete e della posizione geografica del visitatore.
Impatto per metrica:
- LCP: direttamente influenzato. Il tempo di caricamento del contenuto principale aumenta da 100 a 300 ms per reindirizzamento. Su mobile con una connessione lenta, l'impatto può superare i 500 ms per salto.
- CLS: nessun impatto. I reindirizzamenti avvengono prima della visualizzazione della pagina, non causano spostamenti visivi.
- INP: nessun impatto. I reindirizzamenti non influiscono sulla reattività della pagina una volta caricata.
Buona notizia: i reindirizzamenti 301 memorizzati nella cache dal browser non hanno alcun impatto sui Core Web Vitals dopo la prima visita. Il browser reindirizza localmente, senza viaggio di andata e ritorno nella rete. E un argomento supplementare a favore dei 301 rispetto ai 302 per i reindirizzamenti permanenti.
Per misurare l'impatto reale dei reindirizzamenti sui Suoi Core Web Vitals, utilizzi Chrome DevTools (scheda Performance) o i dati sul campo in Google Search Console (rapporto Core Web Vitals).
Errori comuni che distruggono la SEO
Usare 302 al posto di 301 per una migrazione
E l'errore più frequente. Uno sviluppatore configura reindirizzamenti 302 "temporanei" per una migrazione definitiva. Risultato: Google continua a indicizzare il vecchio dominio, il PageRank non viene trasferito e il nuovo dominio parte da zero in termini di autorità.
La correzione è semplice: cambi tutti i reindirizzamenti 302 in 301. L'effetto non è immediato (Google deve ricrawlare gli URL), ma il trasferimento di autorità finira per effettuarsi.
Reindirizzare tutti gli URL verso la homepage
Reindirizza vecchio.captaindns.com/blog/article-1, vecchio.captaindns.com/blog/article-2 e vecchio.captaindns.com/contact verso captaindns.com. Google considera questi reindirizzamenti come soft 404: il contenuto della pagina di destinazione non corrisponde a ciò che il vecchio URL prometteva.
Risultato: Google ignora questi reindirizzamenti e declassa gli URL. I backlink che puntavano ai Suoi articoli del blog perdono il loro valore, poiché reindirizzano a una pagina senza relazione.
La soluzione: un reindirizzamento 1:1. Ogni vecchio URL reindirizza verso la pagina equivalente sul nuovo dominio. Se una pagina non ha un equivalente esatto, la reindirizzi verso la pagina tematicamente più vicina. Per esempio, un articolo del blog eliminato può essere reindirizzato verso un articolo correlato che tratta lo stesso argomento, o verso la pagina di categoria corrispondente.
Catene di reindirizzamenti
Situazione tipica: durante una prima migrazione, site-v1.captaindns.com è stato reindirizzato verso site-v2.captaindns.com. Durante una seconda migrazione, site-v2.captaindns.com è stato reindirizzato verso captaindns.com. Risultato: una catena a 3 salti.
site-v1.captaindns.com 301 site-v2.captaindns.com 301 captaindns.com
Ogni salto aggiunge latenza e consuma una richiesta di crawl. Oltre 5 salti, Googlebot abbandona. Anche con 3 salti, il segnale SEO si diluisce.
Corregga aggiornando i vecchi reindirizzamenti per puntare direttamente alla destinazione finale:
site-v1.captaindns.com 301 captaindns.com
site-v2.captaindns.com 301 captaindns.com
Cicli di reindirizzamento
Un ciclo di reindirizzamento si produce quando l'URL A reindirizza verso l'URL B, che reindirizza verso l'URL A. Il browser mostra l'errore ERR_TOO_MANY_REDIRECTS. Il crawler di Google abbandona immediatamente.
I cicli sono spesso causati da conflitti tra regole di reindirizzamento. Esempi classici:
- Il server reindirizza
httpversohttps, e un plugin reindirizzahttpsversohttp. - Il server reindirizza
wwwversosenza www, e il CDN reindirizzasenza wwwversowww. - Due regole di reindirizzamento si sovrappongono nel file
.htaccesso nella configurazione Nginx.
La soluzione: testi ogni URL in un browser in modalità incognito e verifichi le intestazioni di risposta con curl -I o il Page Crawl Checker.
Dimenticare le varianti www, senza www, HTTP, HTTPS
Un sito accessibile tramite 4 URL diversi (http://, https://, http://www., https://www.) deve reindirizzare le 3 varianti non canoniche verso la versione scelta.
Dimenticare una variante significa che i backlink che puntano a quella versione non vengono reindirizzati. Restituiscono un errore o una pagina non canonica che Google può indicizzare come duplicato.
Verifichi sistematicamente le 4 combinazioni per ogni dominio coinvolto nella migrazione.
Ecco un esempio concreto di test per un dominio:
curl -I http://captaindns.com/it/tools deve restituire 301 verso https://captaindns.com/it/tools
curl -I http://www.captaindns.com/it/tools deve restituire 301 verso https://captaindns.com/it/tools
curl -I https://www.captaindns.com/it/tools deve restituire 301 verso https://captaindns.com/it/tools
curl -I https://captaindns.com/it/tools deve restituire 200 (URL canonico)
Eliminare i reindirizzamenti troppo presto
Alcuni team eliminano i reindirizzamenti 301 dopo qualche settimana, pensando che Google abbia avuto il tempo di aggiornare il suo indice. In realta, Google non ricrawla tutte le pagine allo stesso ritmo. Le pagine profonde con pochi backlink potrebbero non essere ricrawlate prima di diversi mesi.
Inoltre, i backlink su siti di terze parti sono fuori dal Suo controllo. Un articolo di blog pubblicato nel 2020 che linka il Suo vecchio dominio continuerà a generare clic per anni. Se il reindirizzamento viene eliminato, quei visitatori atterrano su un errore 404 o, peggio, su un dominio acquistato da un terzo.
Non monitorare dopo la migrazione
La migrazione è in atto, i reindirizzamenti funzionano, la sitemap e stata inviata. Lavoro finito? No. Senza monitoraggio, non rileverebbe i problemi che appaiono nelle settimane successive:
- Pagine 404 sul nuovo dominio (contenuto eliminato o URL mal configurato)
- Reindirizzamenti rotti (certificato scaduto, server di reindirizzamento in panne)
- Indicizzazione bloccata (robots.txt troppo restrittivo sul nuovo dominio)
- Calo anomalo del traffico su alcune sezioni del sito
Consulti Google Search Console ogni settimana durante i primi 3 mesi. Configuri allarmi sui cali significativi di traffico in Google Analytics.
Ignorare le email e newsletter che contengono link al vecchio dominio
Le Sue email marketing, le newsletter archiviate e i documenti PDF contengono link al vecchio dominio. Questi link continueranno a essere cliccati per mesi, persino anni. Se i reindirizzamenti non sono in atto, i Suoi abbonati atterrano su errori.
Faccia l'inventario di tutti i canali che diffondono link verso il Suo dominio: firme email, template di newsletter, brochure PDF, presentazioni PowerPoint, profili sui social media. Aggiorni i link quando possibile, ma conti sui reindirizzamenti per tutto ciò che non può modificare (email già inviate, PDF già scaricati).
Non dimentichi i link nelle applicazioni mobili, nelle integrazioni con partner e nei widget incorporati su siti di terze parti. Queste fonti sono spesso invisibili negli audit dei backlink ma generano traffico significativo.
Usare reindirizzamenti JavaScript al posto di reindirizzamenti server
Alcuni team implementano reindirizzamenti tramite meta refresh o window.location al posto di configurare reindirizzamenti lato server. Questa scelta è problematica per la SEO.
I reindirizzamenti JavaScript richiedono che il motore di ricerca scarichi la pagina HTML, esegua il JavaScript e poi scopra il reindirizzamento. Google può farlo (il suo crawler utilizza un motore di rendering basato su Chromium), ma con un ritardo significativo. Gli altri motori di ricerca (Bing, Yandex) non seguono sempre i reindirizzamenti JavaScript.
Risultato concreto: durante il periodo di transizione, l'indicizzazione e più lenta, il trasferimento di segnali SEO e incerto e alcuni bot semplicemente non vedono il reindirizzamento. Se ha accesso alla configurazione del server (Nginx, Apache, Caddy, CDN), utilizzi sempre reindirizzamenti HTTP lato server. Riservi il JavaScript ai casi in cui il reindirizzamento server e tecnicamente impossibile, come le Single Page Applications ospitate su un CDN statico.
Non informare Google tramite Search Console
Lo strumento Change of Address in Google Search Console e progettato specificamente per accelerare le migrazioni di dominio nell'indice di Google. Tuttavia, molte migrazioni vengono effettuate senza usare questo strumento.
Senza il Change of Address, Google deve scoprire la migrazione da solo crawlando il vecchio dominio e seguendo i reindirizzamenti. Questo processo può richiedere diverse settimane, persino diversi mesi per i siti voluminosi. Nel frattempo, il vecchio dominio resta nell'indice e il nuovo dominio non eredita ancora tutta l'autorità.
Con il Change of Address, Google riceve un segnale esplicito: il vecchio dominio e migrato al nuovo. Google verifica che i reindirizzamenti 301 siano implementati e poi accelera l'aggiornamento del suo indice. Lo strumento è disponibile in Search Console, sezione Impostazioni, poi Cambio di indirizzo. Entrambi i domini (vecchio e nuovo) devono essere verificati in Search Console.
Casi d'uso concreti con CaptainDNS
Migrazione di sottodominio al dominio principale
Ospita il Suo blog su blog.captaindns.com e decide di trasferirlo su captaindns.com/it/blog per consolidare l'autorità SEO.
Configurazione:
- Crei un reindirizzamento 301 con path forwarding su
blog.captaindns.com - Destinazione:
captaindns.com/it/blog - Attivi il trasferimento del percorso affinché
blog.captaindns.com/article-1reindirizzi versocaptaindns.com/it/blog/article-1
Risultato: i backlink verso il blog, che rafforzavano unicamente il sottodominio, beneficiano ora il dominio principale. L'autorità di dominio si concentra su un'unica entita invece di essere dispersa.
Punti di attenzione:
- Aggiorni i link interni del sito principale per puntare ai nuovi URL (
/it/blog/...) e non al vecchio sottodominio. - Aggiorni la sitemap per includere gli URL del blog sotto il dominio principale.
- Se il blog aveva il proprio profilo in Search Console, dichiari il cambio di indirizzo.
Consolidamento di più sottodomini
Possiede shop.captaindns.com, docs.captaindns.com e status.captaindns.com. Decide di raggruppare tutto sotto captaindns.com.
Configurazione:
| Sottodominio | Destinazione | Path forwarding |
|---|---|---|
| shop.captaindns.com | captaindns.com/it/pricing | Si |
| docs.captaindns.com | captaindns.com/it/docs | Si |
| status.captaindns.com | captaindns.com/it/status | No (pagina unica) |
Ogni sottodominio viene configurato in 301 con CaptainDNS Redirect Hosting. Il path forwarding preserva la struttura di URL per i primi due sottodomini.
Beneficio SEO: invece di ripartire l'autorità di dominio su 4 entita distinte (dominio principale + 3 sottodomini), tutta l'autorità viene consolidata sul dominio principale. I backlink acquisiti dalla documentazione o dallo shop rafforzano ora l'intero sito.
Trappola da evitare: se i Suoi sottodomini avevano certificati TLS distinti, si assicuri che il certificato del dominio principale copra anche i percorsi di destinazione. Un certificato wildcard (*.captaindns.com) semplifica la gestione.
Riprogettazione con cambio di struttura degli URL
Passa da una struttura piatta (captaindns.com/dns-check) a una struttura gerarchica (captaindns.com/it/tools/dns/test-propagation).
Questo caso richiede un piano di reindirizzamento 1:1, poiché la struttura cambia completamente. Il path forwarding non è sufficiente.
| Vecchio URL | Nuovo URL |
|---|---|
| captaindns.com/dns-check | captaindns.com/it/tools/dns/test-propagation |
| captaindns.com/spf-check | captaindns.com/it/tools/email-authentication/spf-check |
| captaindns.com/dkim-check | captaindns.com/it/tools/email-authentication/dkim-check |
Crei un reindirizzamento 301 individuale per ogni URL. Non ci sono scorciatoie possibili.
Cambio di CMS con nuovi URL
Migra da WordPress (captaindns.com/2025/03/mon-article) a un CMS headless con URL puliti (captaindns.com/it/blog/mon-article).
Il cambio di CMS modifica spesso la struttura degli URL del blog. I permalink di WordPress includono la data, il nuovo CMS usa un slug semplice. Ogni vecchio URL di WordPress deve essere reindirizzato con 301 verso il nuovo URL.
captaindns.com/2025/03/mon-article 301 captaindns.com/it/blog/mon-article
captaindns.com/2025/04/autre-article 301 captaindns.com/it/blog/autre-article
Esporti la lista completa dei permalink di WordPress e mappi ciascuno verso il nuovo URL prima di disattivare il vecchio CMS.
Consiglio: se il Suo nuovo CMS utilizza gli stessi slug di WordPress (il titolo dell'articolo in minuscolo con trattini), può creare una regola di riscrittura che rimuove il prefisso data e aggiunge il prefisso /it/blog/. Questo riduce considerevolmente il lavoro di mapping per i siti con centinaia di articoli.
Internazionalizzazione e reindirizzamento per lingua
Lancia versioni localizzate del Suo sito. L'URL /tools/dns-check diventa /it/tools/dns-check, /en/tools/dns-check, /de/tools/dns-check, ecc.
Per i vecchi URL senza prefisso di lingua, due approcci:
Approccio 1: reindirizzamento 301 verso la locale predefinita
Reindirizzi i vecchi URL verso la versione della lingua principale:
captaindns.com/tools/dns-check 301 captaindns.com/it/tools/dns-check
Semplice da configurare, ma i visitatori anglofoni che avevano un backlink verso /tools/dns-check atterrano sulla versione italiana.
Approccio 2: reindirizzamento 302 con rilevamento della lingua
Reindirizzi i vecchi URL verso la versione localizzata in base all'intestazione Accept-Language del browser. Utilizzi un 302 perché il reindirizzamento è condizionale:
captaindns.com/tools/dns-check 302 captaindns.com/it/tools/dns-check (visitatore IT)
captaindns.com/tools/dns-check 302 captaindns.com/en/tools/dns-check (visitatore EN)
Più complesso da configurare, ma offre una migliore esperienza utente. Si assicuri di implementare i tag hreflang sulle pagine di destinazione per aiutare Google a comprendere la struttura multilingue.
🎯 Piano d'azione consigliato
-
Fare l'audit dei Suoi URL esistenti: esporti la lista delle pagine indicizzate da Google Search Console e identifichi le pagine ad alto valore (traffico, backlink).
-
Scegliere il codice di reindirizzamento corretto: migrazione permanente = 301. Campagna temporanea = 302. In caso di dubbio, si ponga la domanda: il vecchio URL tornera mai? Se no, utilizzi un 301.
-
Creare il piano di reindirizzamento 1:1: ogni vecchio URL deve corrispondere a un URL di destinazione. Nessun reindirizzamento generico verso la homepage.
-
Configurare i reindirizzamenti: utilizzi il Redirect Hosting CaptainDNS per creare i reindirizzamenti 301/302 con HTTPS automatico e trasferimento del percorso.
-
Verificare la propagazione DNS: confermi che i record DNS puntano al server di reindirizzamento con il test di propagazione DNS.
-
Dichiarare il cambio in Google Search Console: utilizzi lo strumento "Change of Address" e invii la nuova sitemap.
-
Monitorare per 90 giorni: segua il traffico organico, gli errori di crawl e le posizioni in Search Console. Corregga immediatamente i problemi rilevati.
Configuri i Suoi reindirizzamenti ora: utilizzi il Redirect Hosting CaptainDNS per creare reindirizzamenti 301/302 con HTTPS automatico e trasferimento del percorso.
FAQ
Qual è la differenza tra un reindirizzamento 301 e 302?
Il 301 è un reindirizzamento permanente: indica ai browser e ai motori di ricerca che l'URL è cambiato definitivamente. Il 302 è un reindirizzamento temporaneo: indica che l'URL attuale è temporaneamente accessibile a un altro indirizzo. La differenza principale per la SEO e che il 301 trasferisce l'autorità (PageRank) verso la destinazione, mentre il 302 conserva l'autorità sull'URL di origine.
Un reindirizzamento 302 penalizza la SEO?
No, il 302 non penalizza la SEO in senso stretto. Google non applica sanzioni. Il problema è che Google continua a indicizzare l'URL di origine e non trasferisce l'autorità. Se utilizza un 302 per una migrazione permanente, Google indicizza l'URL sbagliato e il Suo nuovo dominio non beneficia dei backlink. Non è una penalità, ma il risultato è simile: perdita di traffico organico.
Per quanto tempo bisogna mantenere i reindirizzamenti dopo una migrazione?
Minimo 6 mesi, raccomandato 1 anno, ideale permanente. Google ha bisogno di tempo per ricrawlare tutte le Sue pagine e aggiornare il suo indice. I backlink su siti di terze parti continueranno a puntare verso il vecchio dominio per anni. Finche il vecchio dominio e registrato, i reindirizzamenti dovrebbero restare attivi.
Cosa succede se uso un 302 al posto di un 301?
Google continua a indicizzare il vecchio URL e non trasferisce il PageRank verso la destinazione. Il Suo nuovo dominio non beneficia dell'autorità accumulata dal vecchio. Con il tempo, Google può finire per trattare il 302 come un 301, ma il tempo è imprevedibile. La correzione è sostituire tutti i 302 con 301. Google ricrawlerà gli URL e aggiornerà il suo indice.
Le catene di reindirizzamento influiscono sulla SEO?
Si. Ogni salto in una catena di reindirizzamento consuma una richiesta di crawl e aggiunge latenza. Googlebot segue generalmente fino a 5 reindirizzamenti prima di abbandonare. Oltre, la pagina finale non viene ne crawlata ne indicizzata. Anche sotto i 5 salti, il segnale SEO può diluirsi. Limiti ogni catena a 2 salti al massimo e corregga i vecchi reindirizzamenti per puntare direttamente alla destinazione finale.
Come verificare che un reindirizzamento funzioni correttamente?
Diversi metodi. Da riga di comando, utilizzi curl -I URL per mostrare le intestazioni di risposta HTTP e verificare il codice di stato (301 o 302) e l'intestazione Location. In un browser, apra gli strumenti sviluppatore (scheda Rete) e osservi la catena di richieste. Può anche utilizzare il Page Crawl Checker per verificare i reindirizzamenti e rilevare le catene.
Bisogna reindirizzare ogni URL individualmente?
Si, idealmente. Ogni vecchio URL deve reindirizzare verso la pagina equivalente sul nuovo dominio (reindirizzamento 1:1). Se la struttura di URL viene conservata, il path forwarding semplifica la configurazione: il percorso del vecchio URL viene trasmesso automaticamente alla destinazione. Se la struttura cambia, deve mappare ogni URL manualmente.
Google segue i reindirizzamenti JavaScript?
Google può seguire i reindirizzamenti JavaScript, ma con limitazioni. Il contenuto della pagina deve prima essere renderizzato dal motore di rendering di Google, il che aggiunge un ritardo. Inoltre, non tutti i reindirizzamenti JavaScript vengono rilevati in modo affidabile. Google raccomanda di utilizzare reindirizzamenti lato server (301, 302) per i cambi di URL importanti.
Qual è la differenza tra 301 e 308?
Entrambi sono reindirizzamenti permanenti con trasferimento completo della SEO. La differenza è tecnica: il 301 consente al browser di trasformare una richiesta POST in GET durante il reindirizzamento, mentre il 308 preserva il metodo HTTP originale (un POST resta un POST). Per le pagine web classiche (richieste GET), 301 e 308 sono funzionalmente identici. Il codice 308 viene utilizzato principalmente per le API.
Quanti reindirizzamenti segue Google prima di abbandonare?
Google segue generalmente fino a 5 reindirizzamenti in una catena prima di abbandonare. John Mueller di Google ha confermato questo comportamento. Se la pagina finale non viene raggiunta in 5 salti, non viene ne crawlata ne indicizzata. La raccomandazione è di non superare mai i 2 salti per garantire un trasferimento ottimale del segnale SEO.
Si può annullare un reindirizzamento 301?
Tecnicamente si, basta eliminare la regola di reindirizzamento sul server. Ma in pratica, i browser che hanno memorizzato nella cache il 301 continueranno a reindirizzare automaticamente fino alla scadenza della loro cache. Google ha anche bisogno di ricrawlare l'URL per constatare che il reindirizzamento non esiste più. Il tempo di ritorno alla normalita può essere di diverse settimane.
Come gestire una migrazione con migliaia di URL?
Esporti la lista completa degli URL indicizzati da Google Search Console. Utilizzi un foglio di calcolo per creare il mapping 1:1. Se la struttura viene conservata, una sola regola di reindirizzamento con path forwarding è sufficiente. Se la struttura cambia, raggruppi gli URL per pattern e crei regole di riscrittura (regex) sul Suo server o CDN. Testi un campione prima di distribuire l'insieme.
Qual è la differenza tra un reindirizzamento 301 e un canonical tag?
Il 301 reindirizza fisicamente il visitatore verso un nuovo URL: la vecchia pagina non è più accessibile. Il canonical tag (rel=canonical) lascia entrambe le pagine accessibili ma indica a Google quale indicizzare di preferenza. Utilizzi un 301 quando l'URL di origine non ha più ragione di esistere. Utilizzi un canonical quando entrambi gli URL devono restare online (contenuto duplicato, parametri di URL, versioni paginate).
Un reindirizzamento rallenta il mio sito?
Si. Ogni reindirizzamento aggiunge un viaggio di andata e ritorno nella rete (da 100 a 300 ms per salto). L'impatto si concentra sul LCP (Largest Contentful Paint), la metrica di velocità di caricamento. I reindirizzamenti 301 memorizzati nella cache dal browser non hanno più impatto dopo la prima visita, poiché il browser reindirizza localmente senza contattare il server.
Google segue i reindirizzamenti meta refresh?
Si, Google può seguire i reindirizzamenti meta refresh, ma con un ritardo. La pagina HTML deve essere scaricata e analizzata prima che Google rilevi il reindirizzamento. Google sconsiglia questo metodo e raccomanda i reindirizzamenti lato server (301, 302). I meta refresh pongono anche un problema per gli altri motori di ricerca, che non li seguono sempre.
📖 Glossario
- Reindirizzamento 301: reindirizzamento HTTP permanente. Indica che l'URL è cambiato definitivamente e trasferisce l'autorità SEO verso la destinazione.
- Reindirizzamento 302: reindirizzamento HTTP temporaneo. Indica che l'URL è temporaneamente accessibile a un altro indirizzo. L'autorità SEO resta sull'URL di origine.
- Reindirizzamento 307: reindirizzamento temporaneo che preserva il metodo HTTP. Equivalente rigoroso del 302 senza trasformazione POST a GET.
- Reindirizzamento 308: reindirizzamento permanente che preserva il metodo HTTP. Equivalente rigoroso del 301 senza trasformazione POST a GET.
- PageRank: algoritmo di Google che misura l'importanza di una pagina web in base alla quantità e alla qualità dei link in entrata.
- Canonical tag: tag HTML
rel=canonicalche indica a Google quale versione di un URL è la preferita tra diverse pagine con contenuto identico o simile. - Canonicalizzazione: processo attraverso il quale Google sceglie l'URL preferito tra diversi URL che accedono allo stesso contenuto.
- Catena di reindirizzamento: sequenza di reindirizzamenti successivi dove un URL reindirizza verso un secondo, che reindirizza verso un terzo, ecc.
- Ciclo di reindirizzamento: situazione in cui due URL si reindirizzano reciprocamente, creando un ciclo infinito.
- Path forwarding: meccanismo che trasmette il percorso dell'URL di origine verso la destinazione durante un reindirizzamento.
- Soft 404: pagina che restituisce un codice HTTP 200 ma il cui contenuto indica una pagina di errore. Google la tratta come un 404 per l'indicizzazione.
- Change of Address: strumento di Google Search Console che consente di dichiarare ufficialmente un cambio di dominio e accelerare la migrazione nell'indice di Google.
- Crawl budget: numero di pagine che Googlebot può esplorare su un sito in un tempo dato. I reindirizzamenti consumano crawl budget, in particolare le catene di reindirizzamenti.
- Core Web Vitals: insieme di metriche Google (LCP, INP, CLS) che misurano le prestazioni utente di una pagina web. I reindirizzamenti impattano principalmente il LCP aggiungendo latenza di rete.
- CNAME: tipo di record DNS che crea un alias da un dominio a un altro. Utilizzato per puntare un dominio verso un server di reindirizzamento.
📚 Guide reindirizzamento dominio correlate
- Vanity URL, link tracking e codici QR: la guida completa ai reindirizzamenti marketing: crei link di marca, tracci i clic e misuri il traffico offline-to-online
Fonti
- RFC 7231 - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content, section 6.4: definizione ufficiale dei codici di reindirizzamento HTTP 301, 302 e 307
- RFC 7238 - The Hypertext Transfer Protocol Status Code 308: definizione del codice di reindirizzamento permanente 308
- Google Search Central - Redirections et Google Search: documentazione ufficiale sul trattamento dei reindirizzamenti da parte di Google
- Google Search Central - Change of Address tool: guida ufficiale per dichiarare un cambio di dominio
- Google Search Central - Avoid creating duplicate content: buone pratiche per reindirizzamenti e contenuto duplicato
