302 vs. 307: redirect temporanei

TL;DR — Un 302 e un 307 sono entrambi redirect «temporanei»: per ora mandano i visitatori altrove, lasciando l’URL originale come quello che conta. Google li elabora allo stesso modo, quindi non c’è una differenza SEO significativa. La vera differenza tecnica è questa: un 307 deve mantenere la richiesta dello stesso tipo (quindi un invio di modulo resta un invio di modulo invece di trasformarsi nel semplice caricamento di una pagina), mentre storicamente un 302 lasciava che venisse sostituito. Usa 302 per i redirect normali; usa 307 quando reindirizzi qualcosa come un modulo o un’API che invia dati, e non presumere che «usare sempre 307» sia automaticamente gratuito.

Cosa significano davvero 302 e 307

Sia 302 sia 307 sono redirect: chiedi un URL e atterri su un altro. Il numero è il codice di stato HTTP che il server restituisce e contiene un messaggio per browser e motori di ricerca.

• 302 — «Found» (temporaneo). Il redirect temporaneo originale. Dice «vai qui per ora, ma il vecchio indirizzo è ancora quello reale: tornerò».
• 307 — «Temporary Redirect». Lo stesso messaggio — temporaneo, il vecchio URL continua a contare — ma con una promessa in più: il browser deve ripetere esattamente la tua richiesta, incluso il fatto che fosse un GET (recuperare una pagina) o un POST (inviare dati, come quelli di un modulo).

Sono quindi fratelli. Un modo utile per dirlo è: un 307 è un 302 che garantisce anche che il browser non sostituisca silenziosamente l’invio del modulo con una normale richiesta di pagina.

Conta per la SEO?

Non nel modo che preoccupa la maggior parte dei proprietari di siti. La documentazione di Google indica 307 come “equivalent to 302” (traduzione) «equivalente a 302» per il modo in in cui i suoi crawler elaborano e seguono il redirect. Entrambi sono segnali «temporanei», quindi per impostazione predefinita Google non tratta la destinazione come pagina canonica solo perché è stata reindirizzata. La documentazione di Google non chiarisce se 302 e 307 trasferiscano una quantità identica o diversa di valore dei link: dice chiaramente che nessuno dei due codici consegna alla destinazione i segnali della sorgente come fa un redirect permanente. Se qualcuno ti dice che 307 «passa meno valore» di 302, chiedi la fonte: Google non ne ha pubblicata una.

Quando uso l’uno o l’altro?

• Usa un 302 semplice per i redirect temporanei quotidiani: una pagina di saldi stagionali, un test A/B, una pagina di manutenzione o l’invio a una homepage specifica per paese.
• Usa un 307 quando ciò che reindirizzi sta inviando dati: invio di un modulo, chiamata API, login o POST di checkout. Qui la promessa di 307 (mantenere esattamente metodo e dati) conta davvero, perché un 302 semplice potrebbe permettere a un browser più vecchio di trasformare un POST in GET e perdere i dati.

Un dettaglio che trae in inganno

A volte apri gli strumenti per sviluppatori del browser e vedi un 307 che non hai mai configurato. Di solito non è un vero redirect del server: il browser sta trasformando da solo un link http:// in https:// (una funzione di sicurezza chiamata HSTS) e te lo mostra come 307. Il server non l’ha inviato. Ne parliamo meglio nella scheda Advanced.

Vuoi il quadro completo — storia della specifica, cosa dicono esattamente Google e Mueller, il «307 fantasma» di HSTS e i default dei framework che sorprendono gli sviluppatori? Passa alla scheda Advanced.

TL;DR — 302 e 307 sono entrambi redirect temporanei e Google li elabora nello stesso modo: la sua documentazione dice che 307 è “equivalent to 302,” (traduzione) «equivalente a 302,» e Mueller ha detto “for SEO, it doesn’t really matter” (traduzione) «per la SEO non importa davvero» tra le coppie temporanee e permanenti. Nessuno dei due codici segnala che la destinazione debba diventare canonica e Google non ha pubblicato una ripartizione dichiarata di PageRank o valore dei link tra loro. La differenza reale è la preservazione del metodo: un follow automatico di 307 deve mantenere lo stesso metodo (un POST resta un POST), mentre 302 lascia che il client converta POST in GET; byte esatti del corpo, credenziali e comportamento cross-origin dipendono ancora dal client, quindi verifica invece di presumere. Scegli 307 quando perdere il metodo rompe qualcosa — API, moduli, flussi POST/webhook/checkout/autenticazione — ma fai attenzione alla ripetizione non idempotente (un pagamento o ordine reindirizzato può essere inviato di nuovo). Un 302 semplice va bene per i normali redirect GET, inclusa la raccomandazione esplicita di Google per i test A/B. Attenzione al «307 fantasma» di HSTS (un’etichetta dell’interfaccia Chrome, non una garanzia del protocollo), alle specificità dei framework (Next.js documenta 303 per Server Actions e 307 altrove: controlla la tua versione invece di generalizzare ad altre piattaforme) e al fatto che Bing non ha indicazioni distinte sul confronto 302-vs-307. Il mio ordine preferito per i redirect temporanei è 307 / 302 / 303 prima di meta/HTTP refresh; tuttavia usare 307 come default non è gratuito, quindi controlla header di cache, supporto dei client legacy e salvaguardie di idempotenza.

Sono entrambi temporanei: da qui si parte

Prima di tutto: 302 e 307 appartengono alla stessa categoria. Google raggruppa 302 (Found), 303 (See Other) e 307 (Temporary Redirect) come «redirect temporanei» e il suo comportamento per tutti e tre è lo stesso: “Googlebot follows the redirect, but the indexing pipeline doesn’t use the redirect as a signal that the redirect target should be canonical.” (traduzione) «Googlebot segue il redirect, ma la pipeline di indicizzazione non usa il redirect come segnale che la destinazione debba essere canonica.» In parole semplici, un redirect temporaneo mantiene per default canonico l’URL sorgente: non consegna alla destinazione i segnali della sorgente come fa un redirect permanente (301/308).

È esattamente il confronto della fascia permanente spostato di un livello: 301/308 sono la coppia permanente, 302/307 quella temporanea e la logica «il numero più alto preserva il metodo» è identica in entrambe.

L’unica differenza reale: preservazione di metodo e corpo

Ecco la distinzione che conta davvero, in una frase: quando un client segue automaticamente un 307, la specifica HTTP corrente (RFC 9110) gli impone di mantenere lo stesso metodo della richiesta; 302 lascia al client la libertà di cambiare POST in GET. È una garanzia a livello di specifica sul metodo, non una garanzia assoluta su ogni byte del corpo, sulle credenziali o su un comportamento cross-origin: questi aspetti dipendono dal client specifico che implementa il redirect. Verificali con una richiesta reale invece di presumere che 307 ripeta ogni cosa in modo identico in ogni caso.

Il motivo dell’ambiguità è una storia di specifiche che vale la pena raccontare, perché molti articoli affermano il fatto senza spiegare il perché. Nell’epoca HTTP/1.0, il testo della specifica di 302 diceva tecnicamente che i client non avrebbero dovuto cambiare il metodo quando seguivano il redirect; i primi browser (Netscape, poi tutti gli altri) lo ignorarono e convertirono silenziosamente i metodi diversi da GET, soprattutto POST, in GET su un 302. Quel comportamento incoerente ma universale divenne lo standard di fatto. HTTP/1.1 (RFC 2616, 1999, poi confluita in RFC 7231 e nell’attuale RFC 9110) formalizzò la separazione in due codici espliciti per chiudere la confusione:

• 303 (See Other) — recupera la destinazione del redirect con GET o HEAD (non semplicemente «sempre GET»: RFC 9110 permette entrambi i metodi sicuri), il comportamento voluto per «POST, poi redirect a una pagina risultato che si può ricaricare senza rischi».
• 307 (Temporary Redirect) — metodo preservato rigorosamente in un follow automatico, per specifica; RFC 9110 non obbliga però ogni client a seguire il redirect.

MDN riassume bene la conseguenza pratica: “The difference between 307 and 302 is that 307 guarantees that the client will not change the request method and body when the redirected request is made. With 302, older clients incorrectly changed the method to GET.” (traduzione) «La differenza tra 307 e 302 è che 307 garantisce che il client non cambi metodo e corpo della richiesta quando effettua la richiesta reindirizzata. Con 302, i client più vecchi cambiavano erroneamente il metodo in GET.» Quindi 307 non ha aggiunto tanto una nuova capacità, quanto eliminato un’ambiguità: è la versione garantita dalla specifica di ciò che un 302 ben comportato avrebbe dovuto fare da sempre. I browser moderni sono molto più coerenti del caos dell’epoca Netscape, ma 307 elimina l’ambiguità per specifica invece che per convenzione.

Affiancati:

Due note di precisione da tenere a mente: la possibilità di conversione della RFC per 302 nomina POST, non ogni metodo — non trasformarla in “302 always breaks PUT/DELETE” (traduzione) «302 rompe sempre PUT/DELETE» senza controllare il client specifico. Inoltre nessuno dei due codici è memorizzabile per default solo per il suo status: RFC 9111 non elenca 302 o 307 tra i codici memorizzabili euristicamente dal solo status; la cache dipende ancora dagli header espliciti Cache-Control/Expires, non dal codice di redirect scelto.

La mia definizione su Ahrefs è coerente con il punto sulla preservazione del metodo: “A 307 redirect is the same as a 302 redirect, except it retains the HTTP method (POST, GET) of the original request when performing the redirect.” (traduzione) «Un redirect 307 è uguale a un redirect 302, ma conserva il metodo HTTP (POST, GET) della richiesta originale quando esegue il redirect.»

Google tratta 302 e 307 in modo diverso per la SEO?

No, e Google è insolitamente esplicita. È un argomento consolidato e poco controverso, proprio come 301-vs-308.

Nella documentazione di Google sui codici di stato HTTP, la riga di 302 dice che i crawler di Google seguono il redirect e lo usano come segnale debole che la destinazione debba essere elaborata, mentre la riga di 307 dice, testualmente, “Equivalent to 302.” (traduzione) «Equivalente a 302.» Google aggiunge poi la cautela che vale allo stesso modo per le coppie 302/307 e 301/308: “While Google treats these status codes the same way, keep in mind that they’re semantically different. Use the status code that’s appropriate for the redirect so other clients (for example, e-readers, other search engines) may benefit from it.” (traduzione) «Google tratta questi codici allo stesso modo, ma ricorda che sono semanticamente diversi. Usa il codice appropriato per il redirect, così anche altri client, come lettori elettronici e altri motori di ricerca, possono trarne vantaggio.»

Questa è la risposta sul trattamento dei crawler. Google tratta i due codici allo stesso modo per come Googlebot recupera e segue il redirect e chiede soltanto di scegliere il codice semanticamente corretto affinché i client non Google si comportino bene. Evidence for this claim Google treats 307 as equivalent to 302 for Search while noting that the two status codes are semantically different. Scope: Google Search redirect handling; HTTP clients still need the appropriate status code. Confidence: high · Verified: 2026-07-14 Google: HTTP status codes and Search

Una precisazione importante, perché manca in molti articoli: l’equivalenza nel trattamento dei crawler è un’affermazione diversa dal risultato di indicizzazione. La guida di Google su redirect e Ricerca Google raggruppa 302, 303 e 307 come «redirect temporanei» e afferma che “the indexing pipeline doesn’t use the redirect as a signal that the redirect target should be canonical.” (traduzione) «la pipeline di indicizzazione non usa il redirect come segnale che la destinazione debba essere canonica.» È una garanzia reale e utile, ma non promette che l’URL sorgente continui a posizionarsi o che la destinazione non possa mai essere indicizzata attraverso altri segnali. Tratta «302 e 307 sono elaborati allo stesso modo» e «nessuno dei due è un segnale canonico per la destinazione» come due affermazioni separate, entrambe vere; non come una dichiarazione che i due codici trasferiscano PageRank o valore dei link in modo identico, cosa che la documentazione di Google non afferma in nessuna direzione.

John Mueller dice la stessa cosa con parole sue. Nell’episodio del podcast «Parliamo di redirect», Martin Splitt chiese direttamente perché 307 e 308 esistano accanto a 301 e 302. Mueller: “I had to look this up recently. And usually, with a 301 and 302, what is forwarded are GET requests.” (traduzione) «Ho dovuto verificare questa cosa di recente. Di solito, con 301 e 302 vengono inoltrate richieste GET» … “And with 307, 308, it also forwards POST requests.” (traduzione) «Con 307 e 308 vengono inoltrate anche richieste POST.» Poi arriva la citazione che chiude la questione SEO con una conclusione pratica: per la SEO non importa davvero; la domanda è se il redirect funziona per le API, che di solito non sono contenuti da indicizzare direttamente nella Ricerca.

La cornice è importante: l’intero motivo per preferire 307 a 302 è una domanda di funzionalità («funziona per le API?»), non di ranking. Non esiste una fonte primaria credibile che rivendichi un vantaggio SEO nell’uno o nell’altro senso.

Bing tratta 302 e 307 in modo diverso?

Sinceramente: Bing non lo ha dichiarato. Le sue indicazioni pubbliche sui redirect (il post del 2011 «Gestire i redirect – 301, 302 e canonical» e quello del 2020 «Migrazione di siti con Bing») discutono solo della separazione permanente-vs-temporaneo 301-vs-302 e non nominano mai 307 o 308. Diversamente dal tema 301-vs-308, per il quale Fabrice Canel ha rilasciato una dichiarazione diretta, non ho trovato una dichiarazione di un rappresentante Bing specifica su 302-vs-307.

Lo dico chiaramente invece di presumere la parità: non esiste una dichiarazione Bing che differenzi specificamente 302 e 307. Esiste un comportamento documentato di Bing da conoscere per i redirect temporanei in generale: se Bingbot vede lo stesso 302 abbastanza volte di seguito, inizia a trattarlo come 301 e a consolidare in avanti, ma Bing non ha confermato pubblicamente che questo comportamento valga anche per 307 ripetuti. Trattalo come una vera lacuna documentale, non come un fatto su 307.

Quando 307 è la scelta tecnicamente corretta

Qualsiasi redirect in cui perdere il metodo o il corpo originali romperebbe qualcosa:

• API ed endpoint webhook — un POST/PUT/DELETE che deve arrivare al nuovo URL con metodo e payload intatti.
• Invii di moduli (flussi POST) — come ha detto Mueller, “if you have a— I’d almost say like a broken setup, that you have a form on one domain and the results are forwarded to a different one, then you would use the 307, 308.” (traduzione) «se hai, direi quasi, una configurazione difettosa in cui hai un modulo su un dominio e i risultati vengono inoltrati a un altro, useresti 307 o 308.»
• Passaggi di checkout, pagamento e login/autenticazione POST — ovunque perdere silenziosamente il corpo faccia fallire la transazione.

Una nota di sicurezza: la garanzia di 307 sulla preservazione del metodo vale in entrambe le direzioni. Se la richiesta originale non era idempotente — un addebito, un ordine o qualsiasi azione con effetti collaterali — un follow automatico di 307 ripete quella richiesta esatta al nuovo URL. Di solito è ciò che vuoi, ma significa anche che un retry del client o una catena di redirect può inviare più volte la stessa chiamata non idempotente. Inserisci controlli di idempotenza (una chiave di idempotenza o un controllo dei duplicati) sull’endpoint che riceve, anziché presumere che il redirect renda sicuro il replay.

Un motivo frequente per cui gli sviluppatori incontrano 307 senza sceglierlo: alcuni framework e piattaforme edge usano per default un codice che preserva il metodo per le richieste non-GET. Next.js è l’esempio documentato più chiaro: la funzione redirect() restituisce 303 quando viene chiamata da una Server Action e 307 negli altri contesti supportati, secondo il riferimento API corrente; controlla quindi la documentazione della tua versione di Next.js invece di presumere che valga un codice unico per tutto il framework. Anche altri framework, CDN e load balancer variano per prodotto e versione: verifica lo status effettivo restituito dalla piattaforma invece di presumere che corrisponda a quello di una piattaforma apparentemente simile. Vedere un 307 o 303 inatteso spesso significa che la piattaforma sta applicando consapevolmente una logica basata sul metodo, non che sia configurata male; verifica comunque il tuo ambiente specifico.

Quando 302 resta il default pragmatico

Redirect temporanei standard su richieste GET semplici: non c’è un metodo da preservare, quindi la garanzia di 307 non ti dà nulla:

• Redirect geografici o linguistici (con la consueta cautela di non bloccare completamente i contenuti in base alla regione).
• Test A/B e split test — la guida di Google sui test dei siti dice esplicitamente di usare 302, non 301, per le varianti di test reindirizzate, proprio perché il redirect è temporaneo.
• Redirect di modalità manutenzione / «torno presto» — ma solo quando esiste una risorsa reale a cui mandare i visitatori; se l’intero sito non è disponibile, la guida di Google indica 503 (service unavailable) invece di un redirect. E se ciò che reindirizzi è una richiesta non-GET, come checkout o chiamata API verso la pagina di manutenzione, 307 ripeterà la richiesta al nuovo URL: non è automaticamente sicuro se la chiamata ha effetti collaterali, quindi non usarlo per abitudine senza verificare.
• Redirect mobile↔desktop (m-dot) — l’esempio di Mueller in cui 302 è specificamente il codice giusto: “a 302 redirect would be the right one because next time someone goes there, you don’t really know if they want to go to the mobile version or the desktop version.” (traduzione) «un redirect 302 sarebbe quello giusto perché la prossima volta non sai davvero se la persona vorrà la versione mobile o quella desktop.» La destinazione corretta dipende dal visitatore, quindi non è uno spostamento permanente.

Il «307 fantasma» di HSTS: un 307 che il server non ha inviato

Questa sezione merita un titolo proprio perché è un argomento completamente diverso dalla scelta del codice di redirect e confonderli genera vera difficoltà nel debug delle catene.

Se un sito invia l’header HSTS (Strict-Transport-Security) su HTTPS, il browser lo memorizza e, al successivo tentativo di raggiungere la versione http://, aggiorna la richiesta a https:// da solo: l’URI viene riscritto prima che la richiesta tocchi la rete. Le versioni attuali di Chrome mostrano questo aggiornamento interno nei DevTools come 307, ma non lo ha emesso il server; l’etichetta esatta, il conteggio dei byte o la presentazione dell’header dipendono dalla versione di Chrome e dall’interfaccia, non sono un requisito della specifica HTTP o HSTS. Non trattare quindi «307» come un’etichetta garantita in ogni browser o versione futura. John Mueller lo ha spiegato sul suo sito: “After seeing the HTTPS URL with the HSTS header (for example, with any redirect from the HTTP version), Chrome will act like it’s seeing a 307 redirect the next time you try to access the HTTP page.” (traduzione) «Dopo aver visto l’URL HTTPS con l’header HSTS (per esempio con un qualsiasi redirect dalla versione HTTP), Chrome agirà come se vedesse un redirect 307 la prossima volta che provi ad accedere alla pagina HTTP.» E il chiarimento decisivo: “Your server’s not returning a 307, Chrome is just showing it to you as such to explain that it’s doing the redirect for you.” (traduzione) «Il tuo server non sta restituendo un 307: Chrome te lo mostra così solo per spiegare che sta eseguendo lui il redirect.»

Ho segnalato la stessa cosa nei miei contenuti sui codici di stato: esiste perfino un significato distinto, “307 HSTS Policy” (traduzione) «307 HSTS Policy» («obbliga il client a usare HTTPS»), separato da “307 Temporary Redirect.” (traduzione) «307 Temporary Redirect». La sfumatura SEO è: “When web servers require clients to only use HTTPS connections (HSTS policy), Google won’t see the 307 because it’s cached in the browser.” (traduzione) «Quando i server web richiedono ai client di usare solo connessioni HTTPS (policy HSTS), Google non vedrà il 307 perché è memorizzato nel browser.» Se noti un 307 nella scheda Network che non hai configurato, prima di cercare una regola di redirect errata controlla se è semplicemente HSTS che sta eseguendo l’upgrade HTTP→HTTPS.

Miti comuni

• «307 non trasferisce lo stesso valore SEO di 302». Non supportato: la documentazione di Google dice che 307 è «Equivalent to 302» per il trattamento del redirect e nessuno dei due codici è considerato un segnale che la destinazione debba essere canonica. Google però non ha pubblicato una formula precisa di PageRank o valore dei link per nessuno dei due, quindi non affermare un trasferimento esattamente uguale (o diverso) in una delle due direzioni: la tesi corretta è che Google li elabora allo stesso modo, non che abbia quantificato il valore trasferito.
• «302 è la scelta più sicura/raccomandata perché è più chiaro come lo trattano i motori». Esagerato. Il trattamento di 307 da parte di Google è documentato allo stesso modo («Equivalent to 302»): non è un caso in cui un codice sia meglio compreso dai motori. Semmai 307 offre una garanzia funzionale (preservazione di metodo e corpo) che 302 non offre. (Alcune guide di terze parti dicono il contrario: vedi la nota nella scheda risorse.)
• «Un 307 nella scheda Network del browser significa che il server ha configurato male un redirect». Spesso falso: se HSTS è attivo e hai già caricato la versione HTTPS, quel 307 è l’upgrade HTTP→HTTPS di Chrome, non una risposta del server.
• «I 302 convertono sempre POST in GET, quindi non usarli mai per un modulo». Esagerato per i browser moderni. La conversione POST→GET era un problema reale e documentato nei client vecchi: è il motivo per cui esiste 307 come opzione garantita, non la prova che ogni 302 odierno perda i dati POST. 302 è ambiguo, non universalmente rotto.
• «Sostituisci tutti i redirect temporanei con 307 per migliorare il ranking». Falso e cambiamento inutile: non c’è alcun vantaggio di ranking. L’unico motivo valido per preferire 307 è una necessità concreta di preservare metodo/corpo (o una scelta generale di rendere il comportamento più a prova di futuro).
• «303 e 307 sono praticamente uguali». No: 303 impone esplicitamente che il follow-up usi GET (è costruito per i flussi POST-redirect-pagina-risultato), mentre 307 preserva metodo e corpo originali. Sono opposti sul piano funzionale, anche se è facile confonderli perché sono elencati insieme.

La mia raccomandazione

Per i redirect temporanei, il mio ordine di implementazione preferito è 307 / 302 / 303, prima di meta refresh (0) e HTTP refresh (0). In realtà metto 307 sopra 302, non perché aiuti la SEO (non lo fa), ma perché usando sempre il codice che preserva il metodo raramente devi ricordarti di cambiare più avanti: un redirect GET semplice funziona bene come 307 e, il giorno in cui reindirizzi un modulo o un’API, sei già coperto. È un argomento di completezza, non un’opzione senza costi: una policy 307-di-default deve comunque gestire la cache con la stessa disciplina di qualsiasi redirect, funzionare per i client legacy che supporti davvero e avere salvaguardie di idempotenza per ogni destinazione che non sia un semplice fetch GET. Mueller ha espresso la stessa idea di completezza: “if you always use them, then you’re always safe.” (traduzione) «se li usi sempre, allora sei sempre al sicuro.» Detto questo, un 302 semplice va benissimo e, per il caso specifico m-dot, 302 è tecnicamente la scelta più corretta.

Dove si colloca questo confronto

302 e 307 sono due dei codici di redirect temporanei 3xx e ciascuno ha il proprio approfondimento in questo cluster, accanto alla coppia permanente (301, 308), al fratello che usa sempre GET (303) e ai confronti tra fratelli — il 301-vs-308 della fascia permanente (stessa logica di preservazione del metodo, un livello sopra) e il 301-vs-302 permanente-vs-temporaneo — oltre ai rischi operativi, catene e loop di redirect. Per l’intera famiglia delle risposte del server, consulta l’hub dei codici di stato HTTP; il tipo di redirect è anche uno dei segnali di canonicalizzazione trattati nella canonicalizzazione.

Riepilogo AI

Una sintesi della versione Advanced:

• Entrambi sono redirect temporanei. 302 e 307 mantengono per default canonico l’URL sorgente: nessuno dei due consegna alla destinazione i segnali della sorgente come fa un redirect permanente 301/308.
• Google li elabora allo stesso modo. La sua documentazione dice che 307 è “equivalent to 302,” (traduzione) «equivalente a 302,» e Mueller dice: “for SEO, it doesn’t really matter.” (traduzione) «per la SEO non importa davvero.» Ma questa è un’affermazione sul trattamento dei crawler, non una formula dichiarata di PageRank o valore dei link: Google non ne ha pubblicata una per nessuno dei due codici, quindi non affermare un trasferimento esattamente uguale (o diverso) e non presumere che «elaborati allo stesso modo» garantisca che la sorgente continui a posizionarsi o che la destinazione non possa mai essere indicizzata attraverso altri segnali.
• L’unica differenza reale è la preservazione del metodo. Un follow automatico di 307 deve mantenere lo stesso metodo (un POST resta un POST); 302 permette al client di convertire POST in GET. 307 è stato aggiunto in HTTP/1.1 (RFC 2616 → 7231 → 9110) proprio per chiudere l’ambiguità, ma byte esatti del corpo, credenziali e comportamento cross-origin dipendono ancora dal client, e la possibilità di conversione della RFC nomina specificamente POST, non ogni metodo diverso da GET.
• Usa 307 per API, moduli e flussi POST/webhook/checkout/autenticazione, ma attenzione alla ripetizione non idempotente (un pagamento o un ordine possono essere reinviati dopo il redirect: aggiungi salvaguardie di idempotenza). Usa 302 per i redirect GET semplici: geolocalizzazione o lingua, la raccomandazione esplicita di Google per i test A/B e (nell’esempio di Mueller) il passaggio mobile↔desktop. I redirect di manutenzione dipendono dall’esistenza di una risorsa reale a cui mandare i visitatori; un’interruzione completa è spesso servita meglio da 503.
• I default dei framework dipendono da versione e contesto, non sono universali. Next.js documenta 303 per Server Actions e 307 negli altri contesti: controlla la tua versione invece di presumere che altri framework o CDN si comportino allo stesso modo.
• «307 fantasma» di HSTS: un 307 nella scheda Network del browser spesso è Chrome che aggiorna da HTTP a HTTPS autonomamente (HSTS), non una risposta del server; anche l’etichetta esatta «307» è una scelta dell’interfaccia specifica della versione di Chrome, non un requisito della specifica HTTP/HSTS. Mueller: “Your server’s not returning a 307, Chrome is just showing it to you as such.” (traduzione) «Il tuo server non sta restituendo un 307: Chrome te lo mostra così.»
• Bing: non esistono indicazioni specifiche sul confronto 302-vs-307: non presumere la parità e non presumere che il comportamento «302 ripetuto → trattato come 301» valga anche per 307.
• Nessuno dei due codici è memorizzabile per default in base al solo status (RFC 9111): la cache dipende ancora da header espliciti Cache-Control/Expires.
• Ordine preferito di Patrick per i redirect temporanei: 307 / 302 / 303 prima di meta/HTTP refresh, anche se usare 307 come default ovunque non è automaticamente gratuito: controlla header di cache, supporto dei client legacy e salvaguardie di idempotenza.

Documentazione ufficiale

Documentazione primaria e specifiche.

Google

• Codici di stato HTTP, errori di rete e DNS e Google Search — la riga del «segnale debole» di 302, la riga di 307 “Equivalent to 302” (traduzione) «equivalente a 302» e la cautela «semanticamente diversi: usa il codice appropriato».
• Redirect e Google Search — raggruppa 302, 303 e 307 come «redirect temporanei» e spiega l’effetto di ciascuno sulla canonicalizzazione.
• Search Off the Record, episodio 51 — «Parliamo di redirect» (John Mueller + Martin Splitt) — la discussione registrata sul perché esistano 307/308 e quando contino.
• John Mueller — Una guida dei motori di ricerca a 301, 302, 307 e altri redirect — comportamento di indicizzazione di 302 (la sorgente «R» tende a essere indicizzata; il redirect non viene memorizzato).
• John Mueller — 307 — la spiegazione del «307 fantasma» di HSTS.

Bing / Microsoft

• Gestire i redirect — 301, 302 e canonical (ottobre 2011) — la distinzione di Bing tra 301 permanente e 302 temporaneo (nessun riferimento a 307).
• Migrazione di siti con Bing (dicembre 2020) — indicazioni generali sugli spostamenti di sito (ancora nessuna indicazione specifica su 307).

Specifiche

• MDN — 307 Temporary Redirect — la definizione sulla preservazione di metodo/corpo e la nota storica sui client più vecchi che cambiavano il metodo in GET.
• RFC 9110 — HTTP Semantics — §15.4.8 «307 Temporary Redirect» e §15.4.3 «302 Found», il testo corrente della specifica per entrambi i codici.

Citazioni dalla fonte

Dichiarazioni pubbliche di Google e specifiche. Quando la pagina lo consente, ogni link è un deep link che porta direttamente al passaggio citato.

Documentazione Google — 307 è equivalente a 302

• “Equivalent to 302.” (traduzione) «Equivalente a 302.» (la riga di 307) — Google Search Central. Vai alla citazione
• “While Google treats these status codes the same way, keep in mind that they’re semantically different. Use the status code that’s appropriate for the redirect so other clients (for example, e-readers, other search engines) may benefit from it.” (traduzione) «Google considera questi codici equivalenti nel trattamento, ma ricorda che semanticamente non sono uguali. Scegli il codice adatto al redirect, così anche altri client possono trarne vantaggio.» Vai alla citazione
• “Googlebot follows the redirect, but the indexing pipeline doesn’t use the redirect as a signal that the redirect target should be canonical.” (traduzione) «Googlebot segue il redirect, ma la pipeline di indicizzazione non lo usa come segnale che la destinazione debba essere canonica.» (redirect temporanei, inclusi 302/303/307) Vai alla citazione

John Mueller, Google (episodio 51 del podcast «Parliamo di redirect»; trascrizione ufficiale PDF citata per passaggio: non esiste una pagina HTML con un’ancora corrispondente, quindi non è possibile un deep link #:~:text=)

• “I had to look this up recently. And usually, with a 301 and 302, what is forwarded are GET requests.” (traduzione) «Di recente ho dovuto controllare questo punto: con 301 e 302 normalmente vengono inoltrate richieste GET» … “And with 307, 308, it also forwards POST requests.” (traduzione) «con 307 e 308 vengono inoltrate anche richieste POST.»
• “If you have some kind of an API that uses POST requests, or if you have a— I’d almost say like a broken setup, that you have a form on one domain and the results are forwarded to a different one, then you would use the 307, 308.” (traduzione) «Se hai un’API che usa richieste POST o una configurazione quasi difettosa con un modulo su un dominio e risultati inoltrati a un altro, useresti 307 o 308.»
• “I guess from a completeness point of view, if you always use them, then you’re always safe. But that’s the difference there. I think for SEO, it doesn’t really matter. It’s more like, I don’t know… Does it work for APIs or not? And usually, APIs are not something that you need to have indexed directly in Search.” (traduzione) «Dal punto di vista della completezza, usarli sempre è sicuro. La SEO non è il criterio decisivo: conta capire se il redirect funziona per le API, che in genere non sono contenuti da indicizzare direttamente nella Ricerca.»
• “And for that kind of redirect [mobile/desktop], from a technical point of view, a 302 redirect would be the right one because next time someone goes there, you don’t really know if they want to go to the mobile version or the desktop version.” (traduzione) «Per quel tipo di redirect [mobile/desktop], dal punto di vista tecnico 302 sarebbe quello giusto, perché la prossima volta non sai davvero se la persona vorrà la versione mobile o desktop.» Trascrizione PDF

John Mueller, Google (johnmu.com — il «307 fantasma» di HSTS)

• “After seeing the HTTPS URL with the HSTS header (for example, with any redirect from the HTTP version), Chrome will act like it’s seeing a 307 redirect the next time you try to access the HTTP page.” (traduzione) «Dopo aver visto l’URL HTTPS con l’header HSTS, Chrome agirà come se vedesse un redirect 307 la prossima volta che provi ad accedere alla pagina HTTP.»
• “Your server’s not returning a 307, Chrome is just showing it to you as such to explain that it’s doing the redirect for you.” (traduzione) «Il tuo server non sta restituendo un 307: Chrome te lo mostra così per spiegare che sta eseguendo lui il redirect.» Leggi il post

MDN — la differenza sulla preservazione del metodo

• “The difference between 307 and 302 is that 307 guarantees that the client will not change the request method and body when the redirected request is made. With 302, older clients incorrectly changed the method to GET.” (traduzione) «La differenza tra 307 e 302 è che 307 garantisce che il client non cambi metodo e corpo della richiesta quando effettua la richiesta reindirizzata. Con 302, i client più vecchi cambiavano erroneamente il metodo in GET.» Vai alla citazione

Quale redirect temporaneo: 302 o 307?

Poiché entrambi sono temporanei ed equivalenti per la SEO, la decisione si riduce a una domanda: la richiesta contiene un metodo o un corpo che devi preservare?

Una nota sul percorso «non sono sicuro»: Google elabora 307 allo stesso modo di 302 e funziona bene anche per i normali redirect GET, quindi usarlo come default non è sbagliato; non è però automaticamente gratuito. Conferma gli header di cache, verifica che i client più vecchi ancora supportati gestiscano 307 in modo prevedibile e, se la richiesta reindirizzata ha effetti collaterali (una chiamata non-GET a un’API), non permettere il replay automatico senza salvaguardie di idempotenza.

Errori da evitare con i redirect temporanei

Scegliere 302 perché 307 trasferirebbe presumibilmente meno valore

Google documenta 307 come equivalente a 302 per la ricerca. Scegli tra i due in base al comportamento della richiesta, non al ranking.

Dare per scontato che 302 sia sempre più sicuro perché è più vecchio

I client più vecchi rendevano ambiguo il trattamento del metodo da parte di 302. Se un POST, PUT, DELETE, webhook o corpo API deve sopravvivere, usa 307 per la garanzia esplicita di preservazione.

Trattare ogni 307 dei DevTools come una regola del server

Chrome può mostrare un upgrade HSTS interno come 307 anche se il server non ne ha restituito uno. Riproduci la richiesta con un controllo lato server o con curl prima di modificare la configurazione dei redirect.

Afferrare che ogni 302 converta POST in GET

Il comportamento storico è consentito e ambiguo, non garantito in ogni client moderno. Usa 307 quando ti serve certezza; non descrivere tutte le implementazioni 302 come rotte.

Sostituire ogni 302 con 307 per ottenere un vantaggio SEO

Non c’è alcun vantaggio di ranking. Cambia il codice solo quando preservare metodo/corpo migliora la correttezza o quando il default più sicuro di un framework è appropriato.

Confondere 303 con 307

Sono opposti sul piano funzionale: 303 cambia deliberatamente il follow-up in GET; 307 preserva metodo e corpo originali.

Diagnosticare un 307 inatteso o un flusso 302 rotto

I DevTools mostrano Internal Redirect / 307 senza spiegazione

Sintomo: una navigazione http:// appare come 307 in Chrome, ma non esiste alcuna regola di redirect.

Probabile causa: HSTS ha aggiornato la richiesta all’interno del browser prima che arrivasse al server.

Rimedio: controlla initiator e header, poi invia una richiesta che non segua automaticamente i redirect direttamente all’URL HTTP con uno strumento lato server, non con il browser, perché anche una nuova finestra in incognito può applicare HSTS precaricato. Non trattare nemmeno curl come baseline automaticamente neutrale: può avere un proprio archivio HSTS configurato, quindi annota come lo hai invocato. Se la risposta grezza del server differisce da ciò che mostrano i DevTools, non «correggere» il 307 fantasma: verifica separatamente il redirect HTTP→HTTPS reale del server e ripeti ogni richiesta non-GET come test controllato; una richiesta HEAD che segue automaticamente i redirect non può dimostrare il comportamento POST/corpo.

Un POST perde il corpo dopo un redirect temporaneo

Sintomo: un modulo, webhook, login o chiamata API arriva alla destinazione come GET o senza payload.

Probabile causa: la sorgente usava 302, permettendo al client di cambiare metodo, oppure un intermediario ha riscritto la risposta.

Rimedio: usa 307 per lo spostamento temporaneo, poi ripeti una richiesta di test sicura e conferma nei log della destinazione che metodo, content type e corpo siano arrivati intatti.

La piattaforma emette 307 anche se hai scelto un redirect generico

Sintomo: un framework o una piattaforma edge restituisce 307 invece del 302 atteso.

Probabile causa: la piattaforma ha scelto il codice temporaneo che preserva il metodo, spesso per una richiesta non-GET.

Rimedio: verifica che lo spostamento sia davvero temporaneo e che preservare la richiesta sia corretto. Se lo è, mantienilo: Google tratta i due codici allo stesso modo. Cambialo solo quando semantica dell’applicazione o compatibilità del client richiedono una risposta diversa.

302 vs. 307 a colpo d’occhio

Regola pratica: pagina temporanea normale con GET → entrambi funzionano; richiesta temporanea non-GET che deve arrivare intatta → 307.

Strumenti per identificare il redirect realmente ricevuto

Lo strumento gratuito di Patrick

• Bulk HTTP Status Code Checker — invia richieste lato server a fino a 500 URL e permette di esaminare codici e catene reali. È particolarmente utile per distinguere le risposte del server dalla visualizzazione interna 307 dovuta solo a HSTS in Chrome.

Ispezionare il comportamento della richiesta

• Redirect Checker — traccia una singola sorgente attraverso ogni passaggio e conferma se il server inizia con 302 o 307.
• Pannello Network dei DevTools del browser — ispeziona initiator e se Chrome etichetta una voce come redirect interno; non trattarlo da solo come prova di una risposta del server.
• curl più log dell’applicazione — invia un POST sicuro allo staging e conferma che la destinazione riceva stesso metodo e corpo; se hai configurato l’archivio HSTS di curl con --hsts, consideralo nell’interpretazione. Gli strumenti che controllano solo lo status non possono dimostrare che il payload sia arrivato.

Mettiti alla prova: 302 vs. 307

Cinque domande sui due redirect temporanei e su ciò che li distingue davvero. Scegli una risposta per ciascuna domanda e poi controlla.

Risorse che vale la pena consultare

I miei contenuti correlati

• 11 tipi di redirect e il loro impatto sulla SEO (Ahrefs, con Joshua Hardwick) — è il contenuto in cui espongo il mio ordine preferito per i redirect temporanei — 307 / 302 / 303 > meta refresh 0 / HTTP refresh 0 — e formulo chiaramente il verdetto SEO: “For SEO, it’s the same, but if you have data being sent through forms that redirect, then you don’t want to be swapping between GET and POST.” (traduzione) «Per la SEO è lo stesso, ma se hai dati inviati attraverso moduli che fanno redirect non vuoi passare da GET a POST o viceversa.»
• Codici di stato HTTP e loro impatto sulla SEO (Ahrefs) — il mio riferimento per tutti i codici di stato, inclusi i due significati distinti di 307 (Temporary Redirect e HSTS Policy 307) e la nota che con HSTS “Google won’t see the 307 because it’s cached in the browser.” (traduzione) «Google non vedrà il 307 perché è memorizzato nella cache del browser.»
• Guida al technical SEO per principianti — dove i redirect si inseriscono nel quadro più ampio.

I miei interventi

• Patrick Stox su SlideShare e Speaker Deck — i miei interventi sul SEO tecnico, alcuni dei quali trattano redirect e canonicalizzazione. (Vale il mio disclaimer abituale: “This is my understanding of systems… not going to be 100% complete or accurate.” (traduzione) «Questa è la mia comprensione dei sistemi… non sarà completa o accurata al 100%.»)

Fonti ufficiali

• Google — codici di stato HTTP, errori di rete e DNS — la riga «Equivalent to 302» (traduzione) «equivalente a 302» e la cautela «semanticamente diversi, usa il codice corretto».
• Google — Redirect e Google Search — raggruppa 302/303/307 come redirect temporanei.
• Search Off the Record — «Parliamo di redirect» (Google Search Relations, episodio 51) — la discussione Mueller/Splitt da cui provengono le citazioni sopra.

Dal resto del settore

• John Mueller — 307 — la spiegazione più chiara del «307 fantasma» di HSTS: quello mostrato dal browser ma mai inviato dal server.
• MDN — 307 Temporary Redirect — la definizione chiara sulla preservazione di metodo/corpo e la nota storica sui client più vecchi.
• Guida SEO ai redirect (Search Engine Land, Helen Pollitt) — una buona panoramica generale della famiglia dei redirect.
• Redirect URL per la SEO: guida tecnica (Search Engine Journal) — un’altra panoramica tecnica utile.
• Un mito da correggere: la pagina di Conductor «302 vs 307» raccomanda 302 invece di 307 perché «è chiaro come i motori trattano il redirect 302». Questo contraddice la documentazione di Google, che definisce esplicitamente 307 “Equivalent to 302” (traduzione) «equivalente a 302»: il trattamento di 307 è documentato allo stesso modo. Non trattare “302 is the safer SEO choice” (traduzione) «302 è la scelta SEO più sicura» come autorevole: l’unico vero fattore decisionale è se devi preservare metodo e corpo.
• r/TechSEO — la community per il debugging di redirect e canonicalizzazione.

Cronologia modifiche