Il 301 e il 302 possono far cambiare POST in GET. Il 307 no. Il 308 è il permanente che la RFC indica al posto del 301 quando il metodo deve restare, e può non essere riconosciuto.
Un 301 non è un 302, e non è nemmeno un 308. RFC 9110, giugno 2022, tiene i quattro status in sezioni diverse. La guida di Google Search Central sui redirect, pagina che indica «Last updated 2026-04-14 UTC», li raggruppa in un altro modo: 301 e 308 permanenti, 302, 303 e 307 temporanei. Le due pagine non si contraddicono sul verbo «permanente». Si contraddicono se le tratti come la stessa frase.
In breve: il 301 può far cambiare POST in GET. Il 307, no. Il 308 è il permanente che la nota del 301 indica quando quel cambio non va bene, e la sezione del 308 aggiunge che il codice è più giovane e può non essere riconosciuto. Google, nel testo aggiornato il 14 aprile 2026, preferisce il redirect lato server e lega il meta refresh al ritardo: zero secondi per il permanente, più lungo per il temporaneo. Il pezzo sul PUT che non è POST è lo stesso RFC, un altro status.
Cosa trovi in questo articolo
Cosa separa la RFC
RFC 9110, sezione 15.4.2: il 301 Moved Permanently dice che alla risorsa è stato assegnato un URI permanente nuovo e che i riferimenti futuri dovrebbero usare uno degli URI indicati. Il server SHOULD mandare Location. Per ragioni storiche, lo user agent MAY cambiare il metodo da POST a GET nella richiesta successiva. Se questo non va bene, la nota indica il 308.
Sezione 15.4.3, il 302 Found: la risorsa sta temporaneamente sotto un altro URI, e il client dovrebbe continuare a usare l’URI di partenza per le richieste future. Anche qui lo user agent MAY cambiare POST in GET. Se non va bene, la nota indica il 307, non il 308.
Sezione 15.4.8, il 307 Temporary Redirect: lo user agent MUST NOT cambiare il metodo se segue il redirect in automatico. Il client dovrebbe continuare a usare l’URI originale. Sezione 15.4.9, il 308 Permanent Redirect: URI permanente nuovo, come il 301, risposta heuristically cacheable come il 301. La sezione, nel testo che ho letto, non ripete la frase MUST NOT del 307. Ripete un’altra avvertenza: il 308 è molto più giovane (giugno 2014) dei codici fratelli e può non essere riconosciuto ovunque. Rimanda alla sezione 4 di RFC 7538.
Il 303 See Other, sezione 15.4.4, non è un sinonimo del 302. Il nuovo URI nel Location non è considerato equivalente all’URI di partenza. Lo user agent fa una richiesta di retrieval, GET o HEAD, su quell’URI. Google lo mette tra i temporanei. La RFC non lo chiama «il 302 con un altro numero».
Quattro codici, non due
| Status | RFC 9110, giugno 2022 | Metodo, come lo scrive la RFC |
|---|---|---|
| 301 | URI permanente nuovo. I riferimenti futuri dovrebbero cambiare. | MAY da POST a GET. Se non va bene, la nota dice 308. |
| 302 | URI temporaneo. Il client dovrebbe continuare a usare l’originale. | MAY da POST a GET. Se non va bene, la nota dice 307. |
| 307 | Temporaneo, l’originale resta quello da usare dopo. | MUST NOT cambiare il metodo. |
| 308 | Permanente, come il 301. Può non essere riconosciuto ovunque. | La sezione 15.4.9 non ripete il MUST NOT. La nota del 301 lo indica per evitare il cambio. |
301 e 308, nella RFC, sono heuristically cacheable salvo definizione del metodo o cache esplicite. Non è una frase della guida Google. Non la sposto di pagina.
Cosa raggruppa Google
La documentazione Redirects and Google Search mostra «Last updated 2026-04-14 UTC». Nel testo della pagina, i redirect permanenti segnalano a Google di mostrare nei risultati l’URL di destinazione; i temporanei mantengono nei risultati la pagina di origine. I redirect lato server sono preferiti: 301 e 308 per il permanente, 302, 303 e 307 per il temporaneo.
Se il lato server non si può fare, la stessa frase chiede un meta refresh: ritardo di 0 secondi per il permanente, ritardo più lungo per il temporaneo. JavaScript è «a last resort». Non ho letto, in quel passo, una garanzia che il redirect JavaScript venga visto: la pagina lo mette per ultimo.
La guida dice anche di usare il permanente quando si è sicuri che il redirect non verrà ritirato, e il temporaneo quando si vuole mandare le persone su un’altra pagina solo per un periodo. Non è una definizione di cache HTTP. È il criterio che Google scrive per la scelta. Un dominio nuovo non diventa, da solo, né un 301 né un 302: il codice lo sceglie chi configura il server.
Errori da evitare
Mettere un 301 su un form POST e dare per scontato che il metodo resti POST. La RFC dice che lo user agent MAY passare a GET. Per non volerlo, la nota indica il 308.
Trattare 308 e 301 come intercambiabili in ogni client. La sezione 15.4.9 dice che il 308 può non essere riconosciuto ovunque.
Usare un 302 per un trasferimento definitivo «tanto Google capisce». La guida del 14 aprile 2026 lega il temporaneo alla pagina di origine nei risultati, e il permanente alla destinazione.
Fare un meta refresh con attesa e chiamarlo permanente. La stessa guida riserva lo zero secondi al permanente e il ritardo più lungo al temporaneo.
Spostare l’URL solo con JavaScript e considerare il lavoro finito. La guida lo chiama ultima risorsa, dopo il server e dopo il meta refresh.
In sintesi
RFC 9110 separa 301, 302, 307 e 308. Il cambio POST→GET è un MAY sul 301 e sul 302, un MUST NOT sul 307, e una nota del 301 che punta al 308. Il 308 può non essere riconosciuto. Google, testo aggiornato il 14 aprile 2026, preferisce il redirect di server, mette 301/308 tra i permanenti e 302/303/307 tra i temporanei, e distingue il meta refresh in base al ritardo. Nessun link commerciale: le due destinazioni utili, qui, sono la RFC e la guida.
Foto di copertina: Mattes, cartello «Dèviation / Wegomlegging» a Bruxelles, 20 maggio 2025, Wikimedia Commons, CC BY-SA 2.0. È un cartello stradale. Non è un header Location e non è un 301.
