Redirect 301 e 302: quale usare e quanti passaggi segue Google

Risposta breve: nella scelta tra redirect 301 e 302, usa un 301 (o il suo gemello 308) quando il vecchio indirizzo non esiste più in modo definitivo, e un 302 (o 307) solo se lo spostamento è temporaneo e il vecchio indirizzo deve restare nella ricerca. Google tratta un reindirizzamento permanente come un segnale forte di elaborare la destinazione e uno temporaneo come un segnale debole. Per impostazione predefinita segue fino a 10 passaggi, ma conviene mandare ogni vecchio indirizzo alla destinazione finale in un solo passaggio.

Redirect 301 e 302: qual è la differenza?

Un reindirizzamento è una risposta del server che dice «qui non c’è, vai là» e indica il nuovo indirizzo nell’header Location. Il codice di stato spiega il motivo. Nello standard HTTP (RFC 9110), 301 significa che la pagina ha un nuovo indirizzo permanente, mentre 302 significa che si trova altrove solo temporaneamente, quindi il client deve continuare a usare l’indirizzo originale. Google legge la stessa differenza e si comporta di conseguenza:

La tabella viene dalla pagina di Google sui codici di stato HTTP (ultimo aggiornamento 2026-02-04). Che cosa significhi nella ricerca è scritto nella pagina di Google sui reindirizzamenti (ultimo aggiornamento 2026-04-14): i reindirizzamenti permanenti mostrano la nuova destinazione nei risultati, quelli temporanei mostrano la pagina di partenza. Le pagine di Google collegate qui le abbiamo lette il 4 novembre 2026.

Perché esistono anche 307 e 308? Google li tratta come 302 e 301, ma osserva che sono semanticamente diversi, quindi scegli il codice adatto. La differenza sta nel metodo della richiesta: dopo un 301 o un 302 un client può trasformare un POST in un GET, dopo un 307 o un 308 deve mantenere il metodo (RFC 9110, sezione 15.4). Nella normale visualizzazione di una pagina non te ne accorgi; per i moduli e le API che ricevono richieste POST usa 308 o 307.

Quale reindirizzamento usare?

Una domanda risolve la maggior parte dei casi. La pagina di Google sui reindirizzamenti dice: «Use permanent redirects when you’re sure that the redirect won’t be reverted», cioè usa i reindirizzamenti permanenti quando sei sicuro che non verranno annullati. Se il vecchio indirizzo non tornerà mai, usa un 301. Se tornerà, usa un 302.

L’ultima riga viene dalla guida di Google al trasferimento di sito (ultimo aggiornamento 2026-08-20), e il nostro articolo sugli errori soft 404 mostra come trovarli. La guida riguarda lo spostamento di un intero sito su un nuovo dominio, un lavoro più grande di quello che copre questo articolo.

Quanto costa la scelta sbagliata? Un 302 su una pagina che si è spostata per sempre dice a Google qualcosa di non vero. Un reindirizzamento temporaneo lascia la pagina di partenza nei risultati, e «the target page might still be indexed if other canonicalization signals are present», cioè la destinazione potrebbe comunque essere indicizzata se ci sono altri segnali di canonicalizzazione. È un forse, e non abbiamo trovato nessuna pagina di Google che prometta che un 302 di lunga durata diventi più avanti un 301. Quindi non aspettarlo.

Quanti reindirizzamenti segue Google?

La pagina di Google sui codici di stato dice: «By default, Google’s crawlers follow up to 10 redirect hops», cioè per impostazione predefinita i crawler di Google seguono fino a 10 passaggi. Googlebot in genere segue 10 passaggi per i contenuti web, altri prodotti di Google possono usare limiti diversi, e ciò che restituisce l’indirizzo che reindirizza viene ignorato: si elabora invece il contenuto della destinazione finale.

Dieci è un tetto, non un obiettivo. La guida al trasferimento di sito consiglia di reindirizzare direttamente alla destinazione finale e, se non è possibile, di tenere la catena corta, idealmente non oltre 3 e comunque sotto i 5 passaggi. Il motivo: «Chaining redirects adds latency for users, and not all user agents and browsers support long redirect chains», cioè concatenare i reindirizzamenti aggiunge latenza per gli utenti e non tutti gli user agent e i browser supportano catene lunghe. La pagina di Google sugli errori di scansione (ultimo aggiornamento 2025-12-18) aggiunge che le catene lunghe hanno un effetto negativo sulla scansione.

Le catene crescono a strati, non per progetto. Una tipica ha tre passaggi prima che la pagina compaia:

http://example.com/vecchia-guida       301 -> https://example.com/vecchia-guida
https://example.com/vecchia-guida      301 -> https://www.example.com/vecchia-guida
https://www.example.com/vecchia-guida  301 -> https://www.example.com/nuova-guida
https://www.example.com/nuova-guida    200

La soluzione è un passaggio per ogni vecchio indirizzo: ogni forma del vecchio indirizzo risponde con un solo 301 che indica l’indirizzo finale. Lo stesso vale per i tuoi link: fai puntare link interni, tag canonical e voci della sitemap all’indirizzo finale. Un reindirizzamento serve ai visitatori esterni e ai vecchi segnalibri, non alla tua navigazione interna.

Come impostare un reindirizzamento 301

Usa un reindirizzamento lato server. La pagina di Google sui reindirizzamenti lo indica come il tipo che ha più probabilità di essere interpretato correttamente. Gli esempi per nginx e Node qui sotto li abbiamo eseguiti il 4 novembre 2026 (nginx 1.24.0, Node 25.9.0) e abbiamo letto le risposte con curl. Le righe per Apache sono l’esempio di Google; Apache non l’abbiamo eseguito.

Prima nginx. La regola location va nel blocco server di https://example.com. I due blocchi server mandano ogni altra forma dell’indirizzo lì in un solo passaggio, e $request_uri conserva percorso e query string:

# una pagina spostata per sempre (per uno spostamento temporaneo usa 302)
location = /vecchia-guida {
    return 301 https://example.com/nuova-guida;
}

# http:// e https://www. vanno entrambi su https://example.com
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name www.example.com;
    ssl_certificate     /etc/ssl/example.com.pem;
    ssl_certificate_key /etc/ssl/example.com.key;
    return 301 https://example.com$request_uri;
}

Node senza pacchetti. Sostituisci 301 con 308 se le richieste POST devono restare POST:

import http from 'node:http';

const spostate = new Map([['/vecchia-guida', '/nuova-guida']]); // vecchio percorso -> nuovo percorso

http.createServer((req, res) => {
  const { pathname, search } = new URL(req.url, 'http://localhost');
  const destinazione = spostate.get(pathname);
  if (destinazione) {
    res.writeHead(301, { location: `https://example.com${destinazione}${search}` });
    return res.end();
  }
  res.writeHead(200, { 'content-type': 'text/plain' });
  res.end('ok');
}).listen(3000);

Apache, dalla pagina di Google (nella configurazione del server o in un file .htaccess):

Redirect permanent "/vecchia" "https://example.com/nuova"
Redirect temp "/due-vecchia" "https://example.com/due-nuova"

Se non puoi toccare il server, controlla prima la tua piattaforma: Google cita Blogger e Shopify come esempi che possono avere strumenti di reindirizzamento integrati. Google legge anche un meta refresh (0 secondi vale come permanente, un ritardo come temporaneo) e i reindirizzamenti JavaScript, ma solo come ripiego. Con JavaScript, Google «might never see it» se il rendering fallisce, cioè potrebbe non vederlo mai.

Come controllare i reindirizzamenti e che cosa trova SEOgrinder

Bastano due comandi curl. Il primo stampa ogni passaggio con stato e destinazione, il secondo dà il numero e l’indirizzo finale. Usano GET, non HEAD, perché alcuni server rispondono in modo diverso a HEAD:

curl -s -L -o /dev/null -D - http://example.com/vecchia-guida | grep -i -E "^(HTTP|location)"
curl -s -L -o /dev/null -w "%{num_redirects} reindirizzamenti, finale: %{url_effective}\n" http://example.com/vecchia-guida

Eseguili per ogni forma con cui persone e link ti raggiungono: http e https, con e senza www. Il risultato che vuoi è un solo 301 e poi un 200.

SEOgrinder è il nostro strumento, lo costruiamo noi. L’analisi gratuita su SEOgrinder esamina i reindirizzamenti in tre punti (nomi come nell’interfaccia italiana):

• Scheda «Tecnologia e sicurezza», riquadro «Reindirizzamenti». Elenca i passaggi dell’indirizzo che hai analizzato. Se quell’indirizzo reindirizza più di una volta, l’attività «N reindirizzamenti di seguito» mostra i passaggi e consiglia di far puntare il primo URL direttamente alla destinazione finale.
• Stessa scheda, riquadro «Unificazione del dominio». Si aspetta che http e https, con e senza www, finiscano su un unico indirizzo. L’attività «N versioni del sito in concorrenza» compare se non è così. «Reindirizzamento del dominio solo temporaneo» compare se una forma reindirizza con 302, 303 o 307.
• Scheda «Pagina su Google». L’attività «N link interni passano da una deviazione» elenca i link interni la cui destinazione reindirizza o indica un’altra pagina come canonical (fino a 60 link interni della pagina analizzata).

Due limiti. Il controllo delle catene riguarda l’indirizzo analizzato e le forme del tuo dominio, non ogni vecchio indirizzo del sito: testa i vecchi indirizzi con curl. E SEOgrinder non può giudicare se una destinazione sia un successore adatto, né come Google abbia trattato un reindirizzamento. «Passa all’IA» trasforma un’attività in un briefing per un agente di coding, e «Ricontrolla» esegue una nuova analisi dopo la tua modifica.

Errori comuni

• Un 302 per uno spostamento permanente. Il vecchio indirizzo può restare nei risultati. Usa 301 o 308.
• Un 301 per qualcosa di temporaneo. Un negozio chiuso per una settimana richiede un 302.
• Regole sovrapposte che costruiscono catene. Prima http, poi https, poi www, poi la nuova pagina: tre passaggi. Indica in ogni regola direttamente l’indirizzo finale.
• Mandare tutto sulla home page. Reindirizza verso una pagina equivalente oppure rispondi 404 o 410.
• Link interni che usano ancora il vecchio indirizzo. Aggiorna link interni, canonical e sitemap.
• Bloccare il vecchio indirizzo in robots.txt. Google allora non può richiamarlo e non vede mai il reindirizzamento. Nel post di Google del 2011 Do 404s hurt my site? il crawler «has to be able to crawl that URL» per vedere la risposta, cioè deve poter scansionare quell’URL.
• Togliere il reindirizzamento troppo presto. Per i trasferimenti di sito Google dice: «Keep the redirects for as long as possible, generally at least 1 year». Applicarlo a una singola pagina è una nostra lettura.

Domande frequenti

Un redirect 301 danneggia la SEO?

La guida di Google al trasferimento di sito dice: «301 and other permanent redirects don’t cause a loss in PageRank», cioè i reindirizzamenti 301 e gli altri permanenti non causano una perdita di PageRank. La frase sta nella guida per i trasferimenti di sito, quindi applicarla a una singola pagina è una nostra lettura. Di che cosa Google avverte invece: catene lunghe, reindirizzamenti verso pagine non pertinenti (soft 404) e, durante un trasferimento, oscillazioni di posizionamento mentre ripete la scansione.

308 è meglio di 301?

Per Google sono equivalenti. Il 308 mantiene anche il metodo della richiesta, il che conta per moduli e API. Per le pagine normali basta un 301.

Quanto ci mette Google a mostrare il nuovo indirizzo?

Per una singola pagina Google, per quanto abbiamo trovato, non indica nessun tempo. Per i trasferimenti di sito dice che per i siti di medie dimensioni «it can take a few weeks or more», cioè può volerci qualche settimana o più, prima che i nuovi URL sostituiscano gradualmente i vecchi nei risultati. Non promettere nessuna data.

Il prossimo passo

Esegui il primo comando curl sui tuoi vecchi indirizzi e su ogni forma del tuo dominio. Se una richiesta richiede più di un passaggio, fai puntare il primo indirizzo direttamente a quello finale. Poi analizza il tuo sito con SEOgrinder, apri la scheda «Tecnologia e sicurezza», guarda «Reindirizzamenti» e «Unificazione del dominio» e premi «Ricontrolla» dopo la modifica. Per altre basi tecniche, consulta la nostra checklist audit SEO.

Per approfondire

• Come rimuovere una pagina da Google: 404, 410, 301 o noindex?