Redirect temporaneo 307

In breve — Un 307 è un redirect temporaneo, proprio come un 302: per ora manda persone e motori di ricerca a un nuovo URL senza dire a Google di trasferire il posizionamento dell’URL precedente a quello nuovo. L’unica differenza sostanziale rispetto a un 302 è questa: un 307 promette di non cambiare il tipo di richiesta. Se qualcuno invia un modulo (un POST), resta un POST. Per i normali link tra pagine è invisibile; conta solo per moduli e applicazioni. E il «307» che a volte compare nel browser durante un aggiornamento a https non è affatto un redirect reale.

Cos’è un redirect 307

Quando un URL si è spostato altrove per ora — non in modo permanente — il server può rispondere con un redirect temporaneo 307 e indicare al browser la nuova destinazione. È la stessa idea di base di un 302: essendo temporaneo, Google non lo tratta come un segnale per trasferire il posizionamento dell’URL originale al nuovo, come fa con un redirect permanente. È un segnale debole che non cambia la canonicalizzazione, non una garanzia che l’URL originale mantenga il ranking o resti indicizzato per sempre. Useresti un redirect temporaneo per una pagina indisponibile durante la manutenzione, una campagna stagionale o qualsiasi cosa preveda di ripristinare in seguito.

Cosa distingue un 307 da un 302

In realtà c’è una sola differenza, e la maggior parte delle persone non la incontra. Una richiesta web ha un metodo: di solito GET (recuperare una pagina), ma a volte POST (inviare dati, per esempio un modulo). Un 307 garantisce che il browser mantenga lo stesso metodo quando segue il redirect. I browser più vecchi a volte trasformavano un POST in GET con un 302, rischiando di interrompere l’invio del modulo. Il 307 elimina quel rischio per regola. Evidence for this claim RFC 9110 defines 307 Temporary Redirect as a temporary move and requires clients not to change the request method when following it automatically. Scope: HTTP semantics for real server 307 responses, not browser-internal HSTS displays. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.4.8 — 307 Temporary Redirect

Per la stragrande maggioranza dei redirect — qualcuno fa clic su un link verso una pagina — non cambia assolutamente nulla, perché in entrambi i casi si tratta di richieste GET.

Un 307 danneggia la SEO?

No. La documentazione di Google dice che un 307 è «equivalente a» un 302. Entrambi sono temporanei, quindi nessuno dei due trasferisce il posizionamento della vecchia pagina alla nuova come farebbe un redirect permanente (un 301). Non c’è una penalità segreta né un vantaggio segreto: un 307 viene trattato esattamente come un 302.

Il «307» che non è un redirect

Ecco il punto che confonde più persone. Se il sito forza https (una funzione di sicurezza chiamata HSTS), il browser a volte mostra un «307» negli strumenti per sviluppatori quando visiti la versione http di una pagina. Il server non l’ha mai inviato: il browser lo crea per spiegare che è passato direttamente alla versione sicura. Mostra anche una risposta da 0 byte, l’indizio decisivo.

Quindi, se uno strumento di audit o il browser segnala un 307 inatteso, non pensare subito che il server sia configurato male. Una nuova finestra in incognito di solito cancella la memoria HSTS appresa dal browser e mostra il vero codice di stato, ma non sempre: alcuni domini sono nella lista HSTS preload integrata nel browser, che l’incognito non cancella. Un redirect checker o una richiesta curl è un modo più affidabile per vedere cosa restituisce davvero il server.

Vuoi il linguaggio della specifica, ciò che ha detto John Mueller, la meccanica completa di HSTS e il modo concreto di restituire un 307? Passa alla scheda Advanced.

In breve — Un 307 è un redirect temporaneo che, secondo RFC 9110, non deve cambiare il metodo della richiesta: è la garanzia forte che un 302 non offre. Per la SEO è un non-evento: la documentazione di Google lo elenca come “Equivalent to 302” (traduzione) «equivalente a 302» (un segnale debole e temporaneo), e Mueller ha detto che la scelta tra 307 e 302 «non importa davvero» per la ricerca: conta se il redirect deve funzionare per traffico POST/API. Il 307 che confonde davvero le persone è l’artefatto HSTS: un «redirect» solo del browser, da 0 byte, che il server non ha mai inviato e che compare quando il browser aggiorna da http a https da solo. Ha due casi funzionalmente non correlati; distinguerli è tutto il lavoro.

Un 307 ha due casi completamente diversi

Questa è l’idea che organizza tutto ciò che segue e viene direttamente dalla mia guida sui codici di stato, dove il 307 ha due voci separate: “307 Temporary Redirect – Has the same functionality as a 302 redirect, except you can’t switch between POST and GET” (traduzione) «Redirect temporaneo 307: ha la stessa funzionalità di un redirect 302, salvo che non puoi passare da POST a GET» e “307 HSTS Policy – Forces the client to use HTTPS when making requests instead of HTTP.” (traduzione) «Policy HSTS 307: obbliga il client a usare HTTPS invece di HTTP nelle richieste». Condividono un numero e quasi nient’altro:

1. 307 come redirect temporaneo reale emesso dal server — scelto deliberatamente (o impostato come default da un framework) per preservare metodo HTTP e corpo in una richiesta non-GET.
2. 307 come artefatto HSTS del browser — non è affatto una risposta del server. Il browser aggiorna internamente http a https e etichetta quell’aggiornamento come 307.

Confondere questi due casi è la fonte più comune di confusione sui 307. Li esaminerò uno alla volta.

Caso 1: il 307 reale — cosa richiede davvero la specifica

RFC 9110 (l’attuale specifica sulla semantica HTTP) è inequivocabile al §15.4.8:

“The 307 (Temporary Redirect) status code indicates that the target resource resides temporarily under a different URI and the user agent MUST NOT change the request method if it performs an automatic redirection to that URI.” (traduzione) «Il codice di stato 307 (redirect temporaneo) indica che la risorsa di destinazione risiede temporaneamente sotto un URI diverso e che l’user agent NON DEVE cambiare il metodo della richiesta se esegue un redirect automatico verso quell’URI.»

Quel «MUST NOT» è un requisito vincolante, non un suggerimento. Confrontalo con la sezione sul 302 (§15.4.3), che documenta apertamente il caos storico che il 307 è nato per risolvere: “For historical reasons, a user agent MAY change the request method from POST to GET for the subsequent request. If this behavior is undesired, the 307 (Temporary Redirect) status code can be used instead.” (traduzione) «Per ragioni storiche, un user agent PUÒ cambiare il metodo della richiesta da POST a GET per la richiesta successiva. Se questo comportamento è indesiderato, si può usare invece il codice di stato 307 (redirect temporaneo).» In altre parole, il 307 esiste proprio per eliminare l’ambiguità POST→GET che i client più vecchi avevano con 302.

MDN esprime in termini pratici la stessa distinzione:

“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. 307 and 302 responses are identical when the request method is GET.” (traduzione) «La differenza tra 307 e 302 è che 307 garantisce che il client non cambi metodo e corpo della richiesta quando esegue la richiesta reindirizzata. Con 302, i client più vecchi cambiavano erroneamente il metodo in GET. Le risposte 307 e 302 sono identiche quando il metodo della richiesta è GET.»

È l’ultima frase a contare di più per la SEO. Quasi ogni redirect che interessa a chi si occupa di SEO — da una vecchia pagina a una nuova — è una richiesta GET, e per le La garanzia di preservazione del metodo entra in gioco solo quando il metodo non è GET: reinvio di moduli, endpoint API, destinazioni webhook, passaggi POST di checkout o autenticazione. La specifica garantisce metodo e corpo, ma non fissa da sola il comportamento esatto di ogni client per header, credenziali o richieste cross-origin durante il replay: verificalo con il client reale invece di presumere un comportamento byte per byte. Se confronti i due codici per lo spostamento di una pagina normale, il confronto è trattato in dettaglio nell’articolo dedicato a 302 vs. 307; qui si presuppone che tu conosca già il concetto base di redirect temporaneo e ci si concentra su ciò che è specifico del 307.

302 vs. 303 vs. 307 in una tabella

Tutti e tre rientrano nella categoria «temporanea» della RFC, ma non si comportano allo stesso modo sui due assi che contano davvero: preservazione del metodo e cache:

Nessuno dei tre è memorizzabile euristicamente per impostazione predefinita: un 307 (come 302 e 303) ha bisogno di un segnale esplicito di freschezza (Cache-Control, Expires ecc.) prima che una cache lo conservi senza richiederlo di nuovo.

Caso 1, continua: come Google tratta un 307 reale per la SEO

In breve: esattamente come un 302. La documentazione di Google sui codici di stato HTTP elenca la riga del 307 come “Equivalent to 302” (traduzione) «equivalente a 302» e la riga del 302 da cui eredita il comportamento spiega cosa significa:

“By default, Google’s crawlers follow the redirect, and Google systems use the redirect as a weak signal that the redirect target should be processed.” (traduzione) «Per impostazione predefinita, i crawler di Google seguono il redirect e i sistemi Google lo usano come segnale debole per elaborare la destinazione del redirect.»

«Debole» è la parola operativa: un redirect temporaneo non consolida la canonicalizzazione sulla destinazione come fa uno permanente. La guida Google Redirect e Google Search raggruppa 302, 303 e 307 sotto la categoria “temporary” (traduzione) «temporanei» e descrive direttamente il comportamento: “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.» La stessa pagina inquadra così l’intento: “If you just want to send users to a different page temporarily, use a temporary redirect.” (traduzione) «Se vuoi solo mandare temporaneamente gli utenti a una pagina diversa, usa un redirect temporaneo.»

Subito dopo le righe del 307 e del 308, Google aggiunge la cautela da ricordare:

“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) «Anche se Google tratta questi codici allo stesso modo, ricorda che sono semanticamente diversi. Usa il codice appropriato per il redirect, così altri client, per esempio lettori elettronici e altri motori di ricerca, possono trarne vantaggio.»

Google quindi mette 307 e 302 nello stesso bucket ai fini del ranking, ma ti dice comunque di scegliere il codice semanticamente corretto. Questa è tutta la risposta SEO. Evidence for this claim Google treats 307 as equivalent to 302 for Search while noting that the HTTP semantics differ. Scope: Google Search redirect handling; clients still need the semantically appropriate status code. Confidence: high · Verified: 2026-07-14 Google: HTTP status codes and Search John Mueller lo ha detto in modo ancora più diretto nell’episodio 51 del podcast «Parliamo di redirect», spiegando che “with 307, 308, it also forwards POST requests” (traduzione) «con 307 e 308 vengono inoltrate anche richieste POST», a differenza di 301/302, che inoltrano richieste GET, e poi arrivando al punto:

“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) «Penso che per la SEO non importi davvero. È più una questione del tipo: funziona per le API oppure no? E di solito le API non sono qualcosa che devi indicizzare direttamente nella Ricerca.»

Non c’è alcun vantaggio di ranking nel convertire i redirect temporanei in 307. L’unico motivo valido per sceglierlo è preservare metodo e corpo, oppure adottarlo come preferenza generale per rendere il sistema più resistente al futuro: ci tornerò alla fine.

Caso 1, continua: default di framework e CDN

Sempre più domande del tipo «perché questo è un 307?» non riguardano scelte deliberate: sono default del framework. La funzione redirect() di Next.js usa 307 per default e la documentazione spiega chiaramente perché, sotto il titolo «Perché redirect usa 307 e 308?»: “The redirect() method uses a 307 by default, instead of a 302 temporary redirect, meaning your requests will always be preserved as POST requests.” (traduzione) «Il metodo redirect() usa 307 per default invece di un redirect temporaneo 302, quindi le richieste vengono sempre preservate come richieste POST». (Next.js usa specificamente 303 nelle Server Actions e offre permanentRedirect() per il caso 308.) Se vedi 307 che non hai scritto a mano, controlla se il framework o la piattaforma edge li usa come default per i redirect non-GET: di solito è la risposta, ed è spesso quella corretta.

Caso 2: il «307 fantasma» HSTS che il server non ha mai inviato

Questo è il territorio davvero poco trattato e il motivo per cui un articolo dedicato ai 307 è utile. Quando un sito invia un header Strict-Transport-Security (HSTS), dice al browser di caricarsi da quel momento solo via https. Alla prossima richiesta alla versione http, il browser passa a https da solo, senza parlare con il server, e mostra quell’aggiornamento interno come «307» negli strumenti di sviluppo e nei crawler.

John Mueller ha spiegato il meccanismo sul suo sito personale:

“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. 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) «Dopo aver visto l’URL HTTPS con l’header HSTS, Chrome si comporterà come se vedesse un redirect 307 la prossima volta che provi ad accedere alla pagina HTTP. Il server non sta restituendo un 307: Chrome te lo mostra così per spiegare che sta eseguendo lui il redirect.»

Il corpo da 0 byte è l’indizio: come aggiunge Mueller, “the 307 isn’t actually a redirect at all, it’s just a placeholder.” (traduzione) «il 307 non è davvero un redirect, è solo un segnaposto». La mia guida sui redirect spiega così la conseguenza pratica per gli audit: “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. The initial hit (without cache) will have a server response code that’s likely a 301 or a 302. But your browser will show you a 307 for subsequent requests which makes it more difficult to troubleshoot. You will need to use a fresh Incognito session to see the returned status code.” (traduzione) «Quando i server richiedono ai client solo connessioni HTTPS (policy HSTS), Google non vedrà il 307 perché è memorizzato nel browser. Il primo accesso senza cache avrà probabilmente una risposta 301 o 302, mentre il browser mostrerà 307 nelle richieste successive. Per vedere il codice restituito devi usare una nuova sessione in incognito.»

Cosa vede davvero Googlebot con HSTS (e come è cambiata la storia)

Vale la pena leggere insieme due dichiarazioni di Google distanti cinque anni. Nel dicembre 2015 Zineb Ait Bahajji (allora in Google) disse, secondo Search Engine Roundtable, “With HSTS implemented, Googlebot sees a 301 redirect (try it with Fetch as Google). The 307 is just an ‘internal redirect’.” (traduzione) «Con HSTS attivo, Googlebot vede un redirect 301 (prova con Fetch as Google). Il 307 è solo un “redirect interno”.» Nell’ottobre 2020 l’inquadramento di Mueller in un video Ask Google Webmasters, riportato da Search Engine Journal, era leggermente diverso: “In short, [Googlebot] doesn’t interact with them. 307 redirects are generally not real redirects.” (traduzione) «In breve, [Googlebot] non interagisce con loro. I redirect 307 in genere non sono redirect reali.» In entrambi i casi il crawler non vede lo stesso «307» che una persona vede negli strumenti di sviluppo: gli strumenti e l’infrastruttura di crawling sono cambiati (Fetch as Google è stato ritirato a favore di URL Inspection), ma il punto di fondo vale da almeno un decennio: nel caso HSTS non c’è un vero 307 emesso dal server. Considera la frase del 2020 come indicazione corrente e quella del 2015 come contesto storico.

La conseguenza operativa importante è questa: HSTS è una comodità del browser, non un meccanismo per far scoprire URL ai crawler. I proprietari dei siti hanno comunque bisogno di un vero redirect lato server (un 301 autentico) da http a https se vogliono che quel percorso funzioni per i crawler.

Come tratta Bing un 307

Onestamente? C’è una lacuna documentale. Non ho trovato alcuna dichiarazione pubblica di Bing che nomini il 307 o, nello specifico, il 307 prodotto da HSTS. Le indicazioni di Bing sui redirect (il post del 2011 Gestire i redirect – 301, 302 e canonical e quello del 2020 Migrazione di siti con Bing) coprono solo la distinzione permanente- temporaneo 301/302: nessun riferimento a 307, 308 o HSTS. Invece di presumere la parità con Google, diciamolo chiaramente: Bing non ha pubblicato nulla di specifico sui 307. Il fenomeno resta reale e rilevante per i crawler indipendentemente dal motore — lo Spider SEO di Screaming Frog offre l’opzione «Respect HSTS Policy» proprio perché HSTS influisce sul crawling — ma questa è documentazione di uno strumento, non una dichiarazione di Bing.

Quando scegliere deliberatamente un 307

Scegli un 307 (invece di un 302) ogni volta che perdere il metodo o il corpo originale romperebbe qualcosa:

• Endpoint API e destinazioni webhook che ricevono POST/PUT/PATCH.
• Flussi di invio moduli (POST) che fanno redirect dopo l’elaborazione.
• Passaggi POST di checkout o login tra host diversi.
• Qualsiasi caso in cui la richiesta trasporta un corpo che non puoi permetterti di perdere.

Per un normale spostamento da pagina a pagina, per Google 302 e 307 sono indistinguibili, quindi entrambi vanno bene sul piano SEO. Se stai gestendo la versione permanente della stessa logica di preservazione del metodo, il rapporto è 301-vs-308: 308 sta a 301 come 307 sta a 302.

La mia preferenza dichiarata, espressa nella guida sui redirect, è più netta del solito «non importa»: *“my preferred order would be: 307 / 302 / 303

Meta refresh 0 / HTTP refresh 0.”* (traduzione) «il mio ordine preferito sarebbe: 307 / 302 / 303 > Meta refresh 0 / HTTP refresh 0». Metto 307 prima tra le opzioni temporanee: usarlo in modo coerente protegge sempre il metodo, che è più o meno l’argomento della «completezza» sollevato anche da Mueller. E qualunque codice tu scelga, controlla che un 307 reale (o l’artefatto HSTS) non diventi un hop in una catena di redirect più lunga: ogni hop aggiunge latenza e riduce l’efficienza.

Riepilogo AI

Una sintesi della versione Advanced:

• Un 307 ha due casi non correlati. (1) Un redirect temporaneo reale emesso dal server che preserva metodo e corpo HTTP; (2) un artefatto del browser HSTS: un «307» da 0 byte che il server non ha inviato, prodotto quando il browser aggiorna http→https da solo. Distinguerli è tutto il lavoro.
• Caso 1 — la garanzia della specifica: RFC 9110 dice che un 307 “MUST NOT change the request method.” (traduzione) «NON DEVE cambiare il metodo della richiesta». MDN aggiunge che “307 and 302 responses are identical when the request method is GET” (traduzione) «le risposte 307 e 302 sono identiche quando il metodo è GET»: conta quindi solo per traffico POST/PUT/PATCH (moduli, API). La garanzia copre metodo e corpo; header, credenziali e richieste cross-origin nel replay dipendono comunque dal client.
• 302 vs. 303 vs. 307: 302 può (storicamente) cambiare POST in GET, 303 recupera deliberatamente la destinazione con GET/HEAD, 307 non deve cambiare il metodo e nessuno dei tre è memorizzabile euristicamente per default.
• Risposta SEO: la documentazione di Google elenca 307 come “Equivalent to 302” (traduzione) «equivalente a 302»: un segnale debole e temporaneo che non consolida la destinazione. Mueller dice che per la SEO «non importa davvero»; la domanda reale è se «funziona per le API».
• Default dei framework: redirect() di Next.js usa 307 (303 nelle Server Actions, permanentRedirect() per 308) per preservare POST: una fonte comune di 307 «accidentali» che di solito sono corretti.
• Caso 2 — HSTS: il browser mostra un 307 con corpo da 0 byte; il vero codice del server è di solito 301/302. Googlebot non vede quel 307 (Mueller 2020: “doesn’t interact with them” (traduzione) «non interagisce con loro»; Zineb 2015: “sees a 301” (traduzione) «vede un 301»). Serve comunque un vero 301 lato server da http a https. Fai l’audit con un redirect checker o curl semplice: l’incognito di solito funziona, ma non per i domini nella lista HSTS preload integrata nel browser.
• Bing: nessuna dichiarazione pubblica specifica sui 307: una lacuna documentale, non una prova di parità.
• Preferenza: non c’è un motivo di ranking per passare a 307; l’ordine personale di Patrick lo mette al primo posto tra le opzioni temporanee per prepararsi al futuro.

Documentazione ufficiale

Documentazione e specifiche di fonte primaria.

Google

• Codici di stato HTTP, errori di rete e DNS e Google Search — la riga «307 (redirect temporaneo) — Equivalent to 302», il linguaggio del «segnale debole» per 302 e la cautela che sono «semanticamente diversi».
• Redirect e Google Search — raggruppa 302/303/307 tra i redirect «temporanei» e spiega che «la pipeline di indicizzazione non usa il redirect come segnale che la destinazione debba essere canonica».

Bing / Microsoft

• Gestire i redirect – 301, 302 e canonical — indicazioni di Bing sui redirect (solo 301/302; nessun riferimento a 307/HSTS).
• Migrazione di siti con Bing — indicazioni sulla migrazione, ancora limitate a 301/302.

Specifiche HTTP

• RFC 9110 §15.4.8 — redirect temporaneo 307 — “MUST NOT change the request method.” (traduzione) «non deve cambiare il metodo della richiesta».
• RFC 9110 §15.4.3 — 302 Found — la nota storica sul passaggio POST→GET che rimanda al 307.

Riferimento tecnico

• MDN — redirect temporaneo 307 — preservazione di metodo/corpo; «identiche quando il metodo della richiesta è GET».

Framework

• Next.js — riferimento alla funzione redirect() — la FAQ «Perché redirect usa 307 e 308?»; default 307 (303 nelle Server Actions).

Strumenti per crawler

• Screaming Frog — guida SEO al crawling di HSTS e redirect 307 — la configurazione «Respect HSTS Policy» e la meccanica di HSTS.

Citazioni dalla fonte

Dichiarazioni pubbliche. Ogni link porta al passaggio citato o lo documenta.

Documentazione Google — il trattamento SEO

• “307 (temporary redirect) — Equivalent to 302.” (traduzione) «307 (redirect temporaneo) — equivalente a 302» — Google Search Central, Codici di stato HTTP, errori di rete e DNS e Google Search. Vai alla citazione
• “By default, Google’s crawlers follow the redirect, and Google systems use the redirect as a weak signal that the redirect target should be processed.” (traduzione) «Per impostazione predefinita, i crawler di Google seguono il redirect e i sistemi Google lo usano come segnale debole per elaborare la destinazione.» (la riga del 302 da cui il 307 eredita il comportamento) 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 tratta questi codici allo stesso modo, ma ricorda che sono semanticamente diversi. Usa il codice appropriato per il redirect, così 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» — Google Search Central, Redirect e Google Search. Vai alla citazione

Specifiche HTTP / MDN — la garanzia tecnica

• “The 307 (Temporary Redirect) status code indicates that the target resource resides temporarily under a different URI and the user agent MUST NOT change the request method if it performs an automatic redirection to that URI.” (traduzione) «Il codice di stato 307 indica che la risorsa risiede temporaneamente sotto un URI diverso e l’user agent non deve cambiare il metodo durante un redirect automatico» — RFC 9110, §15.4.8. Leggi la sezione
• “For historical reasons, a user agent MAY change the request method from POST to GET for the subsequent request. If this behavior is undesired, the 307 (Temporary Redirect) status code can be used instead.” (traduzione) «Per ragioni storiche, un user agent può cambiare il metodo da POST a GET nella richiesta successiva; se è indesiderato, si può usare 307» — RFC 9110, §15.4.3 (la sezione sul 302). Leggi la sezione
• “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… 307 and 302 responses are identical when the request method is GET.” (traduzione) «La differenza è che 307 garantisce di non cambiare metodo e corpo; le risposte 307 e 302 sono identiche quando il metodo è GET» — MDN, redirect temporaneo 307. Vai alla citazione

John Mueller, Google — SEO e preservazione del metodo

• “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) «Penso che per la SEO non importi davvero: la domanda è se funziona per le API, che di solito non devi indicizzare direttamente nella Ricerca.» — podcast Parliamo di redirect, episodio 51 (17 novembre 2022). PDF della trascrizione
• “And with 307, 308, it also forwards POST requests” (traduzione) «con 307 e 308 vengono inoltrate anche richieste POST» (rispetto a 301/302, che inoltrano richieste GET) — stesso episodio.

John Mueller, Google — il «307 fantasma» HSTS

• “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… the 307 isn’t actually a redirect at all, it’s just a placeholder.” (traduzione) «Il server non sta restituendo un 307: Chrome te lo mostra così per spiegare che sta eseguendo lui il redirect; il 307 non è affatto un redirect, è solo un segnaposto» — John Mueller, HTTPS & HSTS: 301, 302 o 307? (giugno 2016). Vai alla citazione
• “In short, [Googlebot] doesn’t interact with them. 307 redirects are generally not real redirects.” (traduzione) «In sintesi, [Googlebot] non interagisce con loro: i redirect 307 in genere non sono reali.» — John Mueller, Ask Google Webmasters (ottobre 2020), tramite Search Engine Journal. Vai alla citazione

Zineb Ait Bahajji, Google — HSTS, 2015 (riportato)

• “With HSTS implemented, Googlebot sees a 301 redirect (try it with Fetch as Google). The 307 is just an ‘internal redirect’.” (traduzione) «Con HSTS attivo, Googlebot visualizza un redirect 301 (prova con Fetch as Google); il 307 è soltanto un “redirect interno”.» — Zineb Ait Bahajji (Google), via Twitter, riportato da Search Engine Roundtable (dicembre 2015). Vai alla citazione

Quale 307 sto guardando davvero?

Quasi ogni domanda su un 307 si riconduce a una di due cose completamente diverse. Vediamole passo dopo passo.

Miti ed errori da evitare

«Un 307 non trasferisce autorevolezza dei link come un 302.» È falso nella formulazione «307 è peggiore di 302» e circola attivamente in molti blog SEO. La documentazione di Google tratta 307 e 302 allo stesso modo: entrambi sono redirect temporanei con «segnale debole» che non cambia la canonicalizzazione, e la documentazione sui codici di stato HTTP chiama 307 «Equivalent to 302». Non c’è alcuna base documentata per dire che 307 trasferisca meno di 302. Il punto di Google è piuttosto che i redirect temporanei in generale non devono consolidare i segnali di ranking sulla destinazione come fa un redirect permanente: non lasciare che l’affermazione «il 307 trattiene specificamente l’autorevolezza» ti spinga a modifiche inutili.

«Un 307 nella scheda Network significa che il server ha configurato male un redirect.» Spesso è falso. Se HSTS è attivo e il browser ha già visto l’header Strict-Transport-Security, mostra l’aggiornamento http→https come 307 solo per spiegare ciò che sta facendo: il server non l’ha mai restituito (il corpo da 0 byte è l’indizio). Una nuova sessione in incognito di solito mostra il codice reale, ma non per i domini nella lista HSTS preload integrata nel browser; in quei casi prova un redirect checker o curl (senza HSTS configurato) prima di cercare una configurazione errata che non esiste.

«Googlebot vede lo stesso 307 che mi mostra il browser su un sito HSTS.» Non proprio. I rappresentanti di Google hanno detto che Googlebot vede un 301 (Zineb, 2015) oppure non interagisce affatto con il meccanismo 307/HSTS (Mueller, 2020). In ogni caso non vede il «307» mostrato alla persona. Serve comunque un vero 301 lato server da http a https se quel percorso deve essere scoperto dai crawler.

«303 e 307 sono praticamente intercambiabili.» Sono opposti sull’unico asse che conta. Un 303 cambia sempre il metodo in GET (il pattern Post/Redirect/Get); un 307 garantisce che il metodo non cambi. È facile confonderli solo perché entrambi rientrano nella categoria «temporanea» accanto a 302.

«Trasforma tutti i redirect temporanei in 307 per migliorare il ranking.» Non c’è alcun vantaggio. L’unico motivo valido per preferire 307 a 302 è la reale preservazione di metodo/corpo (o una scelta generale per prepararsi al futuro). Trasformare ogni 302 in 307 non porta nulla e rischia di introdurre errori.

«I 302 trasformano sempre POST in GET, quindi 302 è intrinsecamente rotto per i moduli.» È un’esagerazione. La conversione POST→GET era un problema reale per i client più vecchi e incoerenti — proprio per questo esiste 307 come opzione garantita — ma i browser moderni sono molto più coerenti. Un 307 elimina l’ambiguità per specifica, invece di affidarsi al comportamento attuale dei client; non significa che 302 sia «rotto».

Vedere il vero codice di stato (non l’artefatto HSTS)

Quando HSTS è memorizzato, il browser nasconde un vero 301/302 dietro un 307 fantasma. Per default curl non applica HSTS, quindi una chiamata semplice parla direttamente con il server e mostra la verità: non eseguirla però con un file cache --hsts configurato, altrimenti reintroduci proprio la riscrittura lato client che vuoi escludere.

Tracciare la catena completa dei redirect, solo header

# -s silent, -I headers-only, -L follow redirects, cap the hops
curl -sIL --max-redirs 10 http://example.com/old-page 2>&1 \
  | grep -Ei '^(HTTP/|location:)'
# Each "HTTP/…" line is one hop's real status code; each "location:" is where it points.
# An HSTS "307" never appears here — it's browser-only.

Controllare il codice di stato di un URL senza seguire il redirect

curl -s -o /dev/null -w "%{http_code}\n" http://example.com/old-page

Console Chrome DevTools — individuare un 307 fantasma

Incolla il codice nella scheda Console. Un redirect reale del server espone un flag redirected e un URL risolto; l’aggiornamento HSTS avviene prima che la richiesta lasci il browser.

// Fetch and report what the network actually did.
fetch("http://example.com/old-page", { redirect: "manual" })
  .then(r => console.log("type:", r.type, "status:", r.status, "url:", r.url))
  .catch(e => console.log("blocked before request (often HSTS upgrade):", e.message));

Puoi anche leggere direttamente il record HSTS di Chrome in chrome://net-internals/#hsts: cerca un dominio per vedere se static_upgrade_mode/dynamic_upgrade_mode forza https (è ciò che produce il 307 visibile nella scheda Network).

Bookmarklet — lettura rapida degli header della scheda corrente

Trascina un segnalibro con questo URL, poi fai clic su di esso in qualunque pagina per registrare nella Console lo stato e il redirect dell’URL corrente:

javascript:(function(){fetch(location.href,{redirect:"manual"}).then(function(r){console.log("[status]",r.status,"[type]",r.type,"[redirected]",r.redirected,"[url]",r.url);}).catch(function(e){console.log("[error]",e.message);});})();

Nota: fetch() del browser non può leggere i corpi opachi dei redirect cross-origin; per una tracciatura autorevole di più hop, il comando curl -sIL qui sopra è la fonte di verità.

Restituire un 307 reale

Lo scopo di restituire un 307 (invece di lasciare che sia un framework a sceglierlo come default) è garantire la conservazione di metodo e corpo. Ecco alcuni modi comuni per farlo esplicitamente.

Apache (.htaccess)

# mod_rewrite with an explicit 307 (R=307). Preserves POST body.
RewriteEngine On
RewriteRule ^old-endpoint$ https://example.com/new-endpoint [R=307,L]

nginx

# 307 keeps the method; 302 would risk POST→GET on older clients.
location = /old-endpoint {
    return 307 https://example.com/new-endpoint;
}

Node / Express

app.post("/old-endpoint", (req, res) => {
  // res.redirect defaults to 302; pass 307 to preserve the POST + body.
  res.redirect(307, "https://example.com/new-endpoint");
});

Next.js (App Router) — 307 è il default, quindi spesso non devi scrivere affatto questo codice:

import { redirect } from "next/navigation";
// redirect() returns a 307 by default (303 inside a Server Action),
// preserving the request as a POST. Use permanentRedirect() for a 308.
export default function Page() {
  redirect("/new-endpoint");
}

Come appare una risposta 307 grezza

HTTP/1.1 307 Temporary Redirect
Location: https://example.com/new-endpoint
Content-Length: 0

Come appare il «307 fantasma» HSTS (solo browser)

La stessa riga di stato negli strumenti di sviluppo, ma con indizi chiari: proviene dal browser, non dal server, e ha un corpo da 0 byte:

HTTP/1.1 307 Internal Redirect
Location: https://example.com/old-page
Non-Authoritative-Reason: HSTS

Se vedi Non-Authoritative-Reason: HSTS (Chrome) o un «307» da 0 byte che scompare quando lo provi con un client che non applica HSTS, quello è l’artefatto, non un redirect inviato dal server. Il nome esatto dell’header e l’etichetta DevTools sono dettagli di implementazione specifici di Chrome, non garanzie della specifica HTTP o HSTS: trattali come esempi, non come elementi su cui basare automazioni tra browser o versioni diverse.

Metodo, durata e origine del framework

Prima di cambiarlo, valuto un 307 su tre assi:

1. Metodo: la destinazione deve ricevere il metodo e il corpo originali? Se sì, 307 è il redirect temporaneo che preserva entrambi. Un normale GET tra pagine di solito non richiede questa proprietà.
2. Durata: lo spostamento è davvero temporaneo? Mantieni 307 solo finché prevedi che l’URL originale torni disponibile. Uno spostamento permanente richiede una decisione su un redirect permanente, non uno status temporaneo indefinito.
3. Origine: il 307 è stato inviato dal server, scelto da un framework o sintetizzato dal browser come aggiornamento HSTS interno? Un «Internal Redirect» di DevTools non è una regola dell’origine da riscrivere.

Strumenti per distinguere i redirect reali dai redirect fantasma

• Redirect Checker: osserva status, destinazione e ogni hop rilevabile dal server senza affidarti allo stato HSTS di un solo browser.
• Redirect Chain Mapper: usa la vista per hop quando un 307 fa parte di un percorso di redirect più lungo.
• HTTP Header Checker: ispeziona Location e Strict-Transport-Security e confronta gli indizi dell’edge con quelli dell’origine.
• curl: esegui curl -I http://example.com/path fuori dalla visualizzazione HSTS interna del browser. Prova la preservazione POST solo su un endpoint sicuro che controlli.
• Browser DevTools: verifica se la voce dice «Internal Redirect» e mostra un trasferimento da zero byte, indizio di un aggiornamento HSTS generato dal browser.

Validare un 307 dopo il deployment

Test di status e destinazione

Test da eseguire: verifica la sorgente tramite il Redirect Checker oppure curl -I. Risultato atteso: il codice 307 con la Location prevista. Interpretazione del fallimento: uno strato diverso ha modificato regola o destinazione. Finestra di monitoraggio: immediata. Trigger di rollback: compare un loop, una destinazione rotta o un hostname inatteso.

Test di preservazione del metodo

Test da eseguire: invia POST innocuo verso una route di test controllata e controlla cosa riceve la destinazione. Risultato atteso: la destinazione riceve POST con il corpo originale. Interpretazione del fallimento: uno strato intermedio ha convertito il metodo o restituito un altro codice. Finestra di monitoraggio: immediata. Trigger di rollback: un modulo, webhook o richiesta di checkout perde metodo o corpo.

Test di separazione HSTS

Test da eseguire: confronta DevTools (o una nuova sessione in incognito) con una richiesta curl -I senza cache HSTS configurata. Risultato atteso: un «Internal Redirect» del browser è distinguibile dalla risposta reale del server, e HTTP ha ancora un redirect lato server. Interpretazione del fallimento: HSTS nasconde una regola mancante all’origine; l’incognito da solo non basta per i domini nella lista HSTS preload integrata nel browser, perché quello stato non dipende dalla cronologia. Finestra di monitoraggio: immediata. Trigger di rollback: una modifica dell’origine rimuove il redirect HTTP-to-HTTPS funzionante.

Mettiti alla prova: redirect temporaneo 307

Cinque domande rapide su cos’è un 307, come lo tratta Google e cos’è l’artefatto HSTS. Scegli una risposta per ciascuna, poi controlla.

Risorse che vale la pena consultare

I miei contenuti correlati

• 11 tipi di redirect e il loro impatto sulla SEO — da qui provengono la definizione di 307, la cautela su HSTS e il mio ordine preferito (307 / 302 / 303 al primo posto).
• Codici di stato HTTP e loro impatto sulla SEO — il mio articolo con le due voci distinte del 307: redirect temporaneo e policy HSTS.
• Guida al technical SEO per principianti — il contesto più ampio in cui si collocano i redirect.

I miei interventi

• Come funziona la ricerca (SlideShare) — il mio percorso su crawling, rendering, indicizzazione e ranking, compreso il modo in cui vengono gestiti i redirect. (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%.»)

Dal resto del settore

• John Mueller — HTTPS e HSTS: 301, 302 o 307? — la spiegazione di prima parte più chiara del «307 fantasma» HSTS (“your server’s not returning a 307” (traduzione) «il tuo server non sta restituendo un 307»).
• Podcast Parliamo di redirect, episodio 51 (PDF della trascrizione) — Mueller e Splitt spiegano perché esistono 307/308 e perché “for SEO, it doesn’t really matter” (traduzione) «per la SEO non importa davvero».
• Google sui redirect 307/HSTS (Search Engine Journal) — riepilogo del video di Mueller secondo cui “307 redirects are generally not real redirects” (traduzione) «i redirect 307 in genere non sono redirect reali».
• Googlebot tratta i redirect 307 come 301? (Search Engine Roundtable) — la dichiarazione del 2015 di Zineb Ait Bahajji su ciò che vede Googlebot con HSTS.
• MDN — redirect temporaneo 307 — il riferimento tecnico principale per la garanzia su metodo e corpo.
• Guida SEO al crawling di HSTS e redirect 307 (Screaming Frog) — il trattamento migliore della configurazione del crawler per i 307 generati da HSTS.
• Next.js — riferimento a redirect() — perché un framework importante usa 307 come default per i redirect non-GET.

Cronologia modifiche