Redirect 303 See Other

TL;DR — Un 303 See Other è un redirect che invia il browser a una pagina diversa e la recupera con una richiesta GET (o HEAD). Serve soprattutto al pattern Post/Redirect/Get: dopo l’invio di un modulo, il server porta a una pagina dei risultati; aggiornandola si ripete il GET invece del POST originale. Non è quasi mai una scelta SEO: riguarda moduli e applicazioni, non una pagina che «si è spostata». Google e Bing non pubblicano indicazioni SEO specifiche sul 303, perché c’è poco da aggiungere.

Che cos’è un redirect 303

Quando un browser chiede una pagina, il server risponde con un codice di stato HTTP a tre cifre. 200 significa «ecco la pagina»; 404 significa «non trovata». Un 303 significa «See Other»: non visualizzare direttamente ciò che hai richiesto; recupera invece un URL diverso con una richiesta GET o HEAD.

Il passaggio a GET o HEAD è il motivo stesso per cui esiste il 303 e ciò che lo distingue dai codici affini.

L’unico scopo reale dei 303

Immagina di inviare un modulo: un ordine, un commento o un pagamento. Il browser lo invia con una richiesta POST. Se il server restituisce direttamente la pagina di conferma nella risposta POST, nasce un problema: premendo refresh il browser chiede se vuoi reinviare il modulo; ricaricando senza pensarci, potresti effettuare l’ordine due volte.

Un 303 risolve questo problema. Il flusso è il seguente:

1. Invii il modulo → il browser invia un POST.
2. Il server lo elabora e risponde con un 303 che punta a una pagina dei risultati.
3. Il browser segue il 303 con un nuovo GET verso quella pagina.

Ora ti trovi su una normale pagina di conferma raggiungibile con GET. Aggiornandola o tornando indietro, recuperi di nuovo quella pagina invece di reinviare il POST originale. Gli sviluppatori chiamano questo il pattern Post/Redirect/Get (PRG), con il 303 nel mezzo. È importante chiarire il vantaggio reale: PRG blocca la ripetizione causata dal refresh del browser, ma non garantisce l’elaborazione una sola volta. Ritentativi, timeout, doppi clic e richieste concorrenti possono ancora creare ordini o addebiti duplicati, a meno che l’applicazione non disponga di proprie protezioni (chiavi di idempotenza e controlli transazionali) sulla scrittura.

Perché il 303 conta raramente per la SEO

Un 303 è un comportamento di applicazione web, non uno strumento per migrare pagine. Usa un 301 quando un URL si sposta definitivamente e un 302 quando lo spostamento è temporaneo; quasi mai si sceglie un 303 per trasferire una pagina, perché non è progettato per questo. Come ho scritto nella guida Ahrefs: «In genere non vedrai usare redirect 303 per la SEO; se li vedi, saranno trattati come 302/307».

La realtà, detta con franchezza, è questa: Google e Bing non pubblicano indicazioni SEO dedicate ai 303. Google lo cita una sola volta, nel gruppo dei redirect «temporanei» insieme a 302 e 307. Il redirect non è di per sé un segnale che renda canonica la destinazione come farebbe un 301 permanente, anche se altri segnali possono portare all’indicizzazione. Non esiste un comportamento segreto del 303 da imparare. Se un crawler segnala un 303 sul sito, quasi sempre è un pattern applicativo intenzionale (un flusso di moduli), non un errore da «correggere».

Non confonderlo con una pagina rotta o spostata

Alcuni siti descrivono il 303 come ciò che accade quando «la pagina è stata spostata» o «il browser non trova l’URL». È una confusione con un 301/302 o con un errore. Un 303 non indica che qualcosa sia andato storto: è una risposta deliberata dell’applicazione, di solito subito dopo l’invio di un modulo.

Vuoi il confronto tecnico con 302 e 307, ciò che dicono davvero i documenti Google (e la frase diretta di John Mueller) e il punto di vista dello sviluppatore su quando restituirli? Passa alla scheda Advanced.

TL;DR — Un 303 (HTTP «303 See Other») è un redirect temporaneo il cui comportamento caratteristico è indirizzare il client a recuperare un’altra risorsa con GET o HEAD, qualunque fosse il metodo della richiesta originale. È ciò che abilita il pattern Post/Redirect/Get (PRG): POST → 303 → pagina dei risultati GET, così l’aggiornamento recupera la pagina invece di reinviare il modulo. A differenza del 307, che preserva sempre il metodo, il 303 lo cambia; rispetto al 302, la gestione del metodo è esplicita. È raro come redirect SEO tra pagine: è un meccanismo delle applicazioni web, non uno strumento di migrazione degli URL. Google documenta il 303 solo nel gruppo generico dei 3xx «temporanei» con 302 e 307, come segnale debole di canonicalizzazione, e non pubblica indicazioni specifiche; non ne risultano neppure di Bing. Non attribuire autorità che non esiste: qui c’è poco da dire.

Che cos’è davvero un 303

Un 303 è un codice di stato HTTP restituito negli header della risposta, prima di qualsiasi body, con un header Location che indica l’URL da recuperare. La semantica è stretta: la risposta alla richiesta si trova altrove e va recuperata con GET o HEAD.

Il recupero con GET o HEAD è l’intero motivo per cui il 303 esiste come codice distinto e l’asse su cui differiscono i tre redirect quasi temporanei.

303, 302 e 307: la questione del metodo

Dal punto di vista SEO, tutti e tre sono redirect «temporanei» e Google li raggruppa come segnali deboli. Tecnicamente, però, rispondono in modo diverso alla domanda: quale metodo HTTP usa il client quando segue il redirect?

I codici 303 e 307 furono introdotti anche per disambiguare la confusione del 302. Se vuoi forzare il metodo a GET dopo l’invio di un modulo, usa un 303. Se devi mantenere il metodo originale (per esempio ripetere un POST verso un nuovo endpoint), usa un 307. Il 302 è il punto intermedio storico e poco definito.

Un’altra differenza pratica: per impostazione predefinita le risposte 303 non sono memorizzabili in cache, mentre un 301 lo è. È importante se temi che browser o CDN memorizzino in modo errato la destinazione del redirect; con un 303 questo rischio specifico non si presenta.

Il pattern Post/Redirect/Get, con precisione

PRG è l’uso canonico del 303 ed è un pattern di progettazione deliberato e corretto, non uno stato di errore:

1. Il client invia un modulo come POST (crea un ordine, pubblica un commento o avvia un pagamento).
2. Il server elabora l’effetto collaterale e restituisce 303 See Other con un header Location che punta a un URL dei risultati raggiungibile con GET (una ricevuta, una conferma o una vista aggiornata della risorsa).
3. Il client segue con un GET (o HEAD) verso quell’URL. La cronologia e il pulsante per aggiornare il browser puntano ora a un recupero sicuro e idempotente: ricaricare o tornare indietro recupera la pagina dei risultati invece di ripetere il POST.

Il vantaggio è che un semplice refresh del browser non reinvia più il modulo e non mostra il dialogo «conferma reinvio modulo». Sii preciso: PRG impedisce quel percorso di ripetizione, non ogni scrittura duplicata, e non garantisce un’elaborazione eseguita una sola volta. Ritentativi, timeout, doppi clic e richieste concorrenti possono ancora inviare due volte il POST originale; operazioni che cambiano lo stato (ordini, pagamenti, commenti) richiedono controlli applicativi propri, come chiavi di idempotenza, confini transazionali e rilevamento delle richieste duplicate. Nelle API RESTful puoi vedere un 303 anche dopo un PUT o un DELETE, per portare il client alla rappresentazione della risorsa interessata.

Come tratta Google il 303 (e perché c’è così poco da trattare)

Il punto centrale, senza sovrainterpretare, è questo: Google non ha indicazioni SEO specifiche per il 303. Nella documentazione sui redirect compare come una riga della tabella dei redirect «temporanei», accanto a 302 e 307. Google dice che il crawler segue il redirect, ma la pipeline di indicizzazione non lo usa come segnale che la destinazione debba diventare canonica; altri segnali possono comunque portare Google a indicizzare la destinazione. È un’indicazione più limitata della canonicalizzazione forte offerta da un 301 permanente.

Il testo informale di John Mueller sui redirect è ancora più chiaro. Dopo aver illustrato 301, 302 e 307, liquida il 303 in una breve parentesi: «E il 303? E il 304.5? Se hai preferenze forti per uno degli altri redirect, sentiti libero di usarlo». Aggiunge: «Dovremo stabilire sotto quale URL indicizzare il contenuto; se ti importa anche questo, usa ulteriori segnali di canonicalizzazione». Se usi un 303 e ti importa quale URL venga indicizzato, non affidarti al solo tipo di redirect: affiancalo a rel="canonical", link interni e sitemap.

La documentazione Google aggiunge una nota utile per tutti questi codici: “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.” (traduzione) «Anche se Google tratta questi codici allo stesso modo, ricorda che sono semanticamente diversi: usa il codice appropriato per il redirect». Il fatto che la SEO li raggruppi non autorizza a usare un 303 per uno spostamento permanente: scegli il codice coerente con l’intento, così anche gli altri client si comportano correttamente.

Come tratta Bing il 303

In parole semplici: non ho trovato indicazioni pubbliche specifiche di Bing sul 303, oltre ai riferimenti generici ai codici HTTP nell’aiuto di Bing Webmaster Tools. Non c’è una dichiarazione verificata di Fabrice Canel o di altri esponenti Microsoft che citi il 303. È un dato legittimo («non abbiamo documentazione»), non una lacuna da colmare: non si può presumere che Bing replichi il comportamento dichiarato da Google. L’assenza di documentazione non dimostra che il trattamento sia identico; per una risposta definitiva su Bing, la questione resta aperta.

Il 303 conta per la SEO? Raramente.

Questa è la conclusione pratica, coerente con ciò che ho scritto pubblicamente. Un 303 non è uno strumento di migrazione delle pagine. In 11 tipi di redirect e il loro impatto SEO ho scritto: «Un redirect 303 porta l’utente a una risorsa simile a quella richiesta ed è una forma temporanea di redirect; serve soprattutto a evitare il reinvio dei moduli. Di norma non si usa per la SEO e, se compare, viene trattato come un 302/307».

Segnalo una tensione onesta nei miei contenuti precedenti. In Codici di stato HTTP e loro impatto SEO descrivevo il trattamento del 303 come «non definito… può essere trattato come 301 o 302, a seconda del funzionamento». Oggi lo formulerei più precisamente: la documentazione Google colloca il 303 nel gruppo temporaneo/debole con 302 e 307. Il termine «non definito» sembrava plausibile perché i 303 sono rari e Google non ha avuto motivo di chiarire i casi limite, non perché nascondano un comportamento più forte. Parti dal valore documentato (debole/temporaneo) e considera le sorprese conseguenza della rarità, non una regola segreta.

Quando può avere importanza? Soprattutto su siti con flussi intensivi di moduli o checkout e su applicazioni guidate da API, dove un crawl dei codici mostra 303. Anche lì, di solito, la risposta è «funziona come previsto: lascialo così». Se stai spostando deliberatamente un URL, non usare un 303: usa un 301 permanente o un 302 temporaneo; usa 308/307 quando devi preservare il metodo.

303 contro 201, 202 e 204: scegliere lo stato giusto per una scrittura

Il 303 non è l’unica opzione dopo una richiesta che modifica lo stato, ed è facile sceglierlo per abitudine. In un’API, a differenza di un flusso di moduli nel browser, spesso sono più adatti tre codici 2xx:

• 201 Created — la richiesta ha creato una o più risorse in modo sincrono; la risposta dovrebbe identificare quella principale, nell’header Location se presente o nell’URI di destinazione. Usalo quando la creazione è conclusa e vuoi consegnare subito la nuova risorsa, senza un ulteriore GET.
• 202 Accepted — la richiesta è stata accettata ma l’elaborazione non è ancora terminata (lavoro in coda o job asincroni). La risposta dovrebbe descrivere lo stato e, idealmente, indicare un monitor interrogabile dal client.
• 204 No Content — l’azione è riuscita e non c’è altro da inviare: nessun body e nessun redirect; la risposta termina negli header.

Il 303 serve a uno scenario diverso: il client deve recuperare, dopo la scrittura, una risorsa risultato identificata separatamente, soprattutto nel pattern PRG del browser. Non sostituisce la creazione sincrona (201), l’accettazione asincrona (202) o un successo senza contenuto (204): ciascuno comunica un esito distinto che un redirect non può sostituire.

Miti comuni

• «Un 303 significa che la pagina è stata spostata o si è rotta». No: è una risposta deliberata che cambia il metodo, di solito dopo POST/PUT/DELETE, non un segnale di contenuto trasferito o di errore.
• «Un 303 trasferisce il valore SEO di un 301». No: è temporaneo/debole, nello stesso gruppo di 302 e 307 secondo Google.
• «Gli esperti SEO dovrebbero usare 303 come redirect generico». Non è progettato per questo: è uno schema ristretto per moduli e API, non per migrazioni ordinarie.
• «Google ha regole dettagliate e specifiche per il 303». No: esiste solo una menzione raggruppata e la frase di Mueller «sentiti libero di usarli».
• «302 e 303 sono tecnicamente identici». Sono accomunati nella SEO, ma non tecnicamente: il 303 forza il recupero successivo con GET o HEAD, mentre la gestione del metodo nel 302 è stata storicamente incoerente; proprio per questo sono stati introdotti 303 e 307.

Dove si colloca

Il 303 appartiene al gruppo dei redirect temporanei. I parenti più vicini sono il 302, redirect temporaneo flessibile con cui viene spesso raggruppato, e il 307, che preserva il metodo mentre il 303 passa a GET o HEAD. È diverso dal 301, redirect permanente che consolida i segnali di ranking e svolge il lavoro di migrazione per cui il 303 non è stato progettato. Per la famiglia completa — 301/308 permanenti, 302/303/307 temporanei, 404/410 per risorse scomparse e errori 5xx — consulta il gruppo dei codici di stato HTTP.

Convalidare in sicurezza un flusso 303

Prima di fidarti di un 303 in produzione, controllalo senza seguirlo automaticamente alla cieca: esamina il valore di Location (assoluto, relativo e risolvibile), cerca loop o catene inutili, verifica che la richiesta successiva usi GET o HEAD e controlla stato e contenuto della risposta finale. In un flusso di moduli o API, esamina anche i log dell’applicazione per assicurarti che la scrittura originale non venga ripetuta.

Una cautela: non trasformare il comportamento di un singolo client in una regola universale. Browser, client HTTP e framework variano per prodotto, versione e configurazione; un report su una versione specifica non è prova per tutti. Un checker a livello URL può confermare redirect e destinazione, ma non può verificare al posto tuo idempotenza, gestione delle credenziali o sicurezza cross-origin: serve testare il flusso reale di invio.

Riepilogo IA

Una sintesi della versione avanzata:

• 303 = HTTP «303 See Other» — redirect temporaneo che indirizza il client a recuperare un’altra risorsa con GET o HEAD, qualunque fosse il metodo originale.
• Pattern Post/Redirect/Get (PRG): POST (invio del modulo) → 303 → pagina risultato GET/HEAD; aggiornando o tornando indietro si recupera la pagina invece di reinviare il POST. Questo blocca la ripetizione da refresh, ma non garantisce un’esecuzione una sola volta: ritentativi, timeout, doppi clic e richieste concorrenti possono duplicare una scrittura senza controlli applicativi (chiavi di idempotenza e controlli transazionali).
• Il metodo è la differenza: 303 passa a GET/HEAD, 307 conserva sempre il metodo e 302 era storicamente ambiguo; 303 e 307 sono nati per disambiguarlo.
• Cache: il solo stato 303 non rende la risposta memorizzabile per euristica, a differenza del 301; la risorsa risultato ha una propria politica di cache.
• Non sostituisce 201/202/204: il 303 serve quando il client deve recuperare una risorsa risultato separata, non per creazione sincrona, accettazione asincrona o successo senza contenuto.
• Realtà SEO: Google documenta il 303 solo nella riga dei redirect «temporanei» con 302 e 307; il redirect non rende canonica la destinazione, anche se altri segnali possono farla indicizzare. Non esiste una guida dedicata Google o Bing.
• Raramente è rilevante per la SEO: è un pattern applicativo, non uno strumento di migrazione URL. Per spostare un URL usa 301 o 302, non 303.

Documentazione ufficiale

La documentazione SEO di fonti primarie sul 303 è scarsa: il codice viene citato solo di passaggio, insieme agli altri redirect temporanei. Queste sono le fonti pertinenti.

Google

• Redirect e Ricerca Google — elenca HTTP 303 (see other) nel gruppo dei redirect «temporanei» con 302 e 307, senza note specifiche sul 303.
• Come i codici di stato HTTP influenzano la Ricerca Google — include 303 (see other) nella sezione 3xx e descrive questi codici temporanei come segnali deboli, ricordando che sono «semanticamente diversi».

Bing / Microsoft

• Non è stata individuata una guida specifica sul 303. L’aiuto di Bing Webmaster Tools tratta i codici HTTP in generale, senza una sezione dedicata al 303.

Riferimento tecnico (non fonte SEO)

• MDN — 303 See Other — riferimento rapido per i casi PUT/POST/DELETE e PRG; la formula «always GET» è più ampia della specifica attuale.
• RFC 9110 — Semantica HTTP, §15.4.4 — definizione tecnica vincolante: la destinazione di Location non è equivalente a quella originale e l’user agent la recupera con GET o HEAD, non sempre con GET.

Citazioni dalla fonte

Le dichiarazioni pubbliche sul 303 sono poche: questa scarsità è parte della storia del tema. Le citazioni riportate sono quindi l’estensione onesta della documentazione, non un elenco gonfiato; ogni link porta al passaggio citato.

Google / John Mueller — il registro (molto breve) suo 303

• “What about 303? 304.5? If you have strong feelings about one of the other kinds of redirects, feel free to use them. We’ll have to figure out which URL to index the content under, so if you have strong feelings about that too, make sure to follow up with other canonicalization signals.” (traduzione) «E il 303? Se hai preferenze forti per uno degli altri redirect, sentiti libero di usarlo. Dovremo stabilire sotto quale URL indicizzare il contenuto; se ti importa anche questo, usa ulteriori segnali di canonicalizzazione». — John Mueller, blog personale, A search-engine guide to 301, 302, 307…. È la dichiarazione più diretta sul 303 da parte di una persona di Google, e ha il tono deliberatamente non prescrittivo. Fonte

Google — il trattamento del «gruppo temporaneo» ereditato dal 303

• “By default, Google’s crawlers follow the redirect… 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; i sistemi Google lo usano come segnale debole per elaborare la destinazione». — Google Search Central, How HTTP status codes… affect Google Search.
• «Anche se Google tratta questi codici allo stesso modo, ricorda che sono semanticamente diversi: usa il codice appropriato per il redirect». (Traduzione italiana dell’originale citato nella sezione avanzata.) Fonte Fonte

MDN — una formulazione comune da correggere

• “The method used to display this redirected page is always GET.” (traduzione) «Il metodo usato per visualizzare questa pagina reindirizzata è sempre GET». — MDN, 303 See Other. Vale la pena segnalarlo invece di ripeterlo senza analisi: la specifica attuale è più permissiva di «always GET». RFC 9110 §15.4.4 definisce il recupero successivo come GET o HEAD e la destinazione Location come risorsa diversa e non equivalente; è questo il fatto tecnico che distingue 303 da 307 (preserva il metodo) e 302 (storicamente ambiguo). Fonte

Patrick (Ahrefs) — la conclusione pratica per la SEO

• “A 303 redirect forwards the user to a resource similar to the one requested and is a temporary form of redirect. It’s typically used for things like preventing form resubmissions when a user hits the ‘back’ button in their browser. You won’t typically see 303 redirects used for SEO purposes, but if you do then it will be treated just like a 302/307.” (traduzione) «Un redirect 303 porta l’utente a una risorsa simile a quella richiesta ed è una forma temporanea di redirect. Serve soprattutto a evitare il reinvio dei moduli; in genere non si usa per la SEO e, se compare, viene trattato come 302/307». — Patrick Stox, 11 tipi di redirect e il loro impatto SEO (Ahrefs). Fonte

Uso improprio di 303 See Other

Trattare 303 come un codice generico di «pagina spostata»

Un 303 serve a inviare il client a un’altra risorsa con GET o HEAD, di solito dopo una richiesta che modifica lo stato. Usa 301 per lo spostamento permanente di una pagina e 302 per un redirect temporaneo normale.

Usare 303 quando il metodo originale deve essere conservato

Il codice scarta deliberatamente il metodo originale nella richiesta successiva. Se il metodo di una richiesta POST, PUT o DELETE, un webhook o un payload API deve arrivare intatto alla destinazione, usa 307 (temporaneo) o 308 (permanente).

Descrivere 303 come un forte segnale SEO permanente

Google raggruppa 303 con i redirect temporanei, non con 301/308. Non usarlo per consolidare una migrazione di URL né sostenere che si comporti come uno spostamento permanente.

Presumere che Google o Bing pubblichino regole dettagliate sul 303

Google offre solo un trattamento raggruppato dei redirect temporanei e Bing non ha una guida pubblica dedicata individuata in questo articolo. Mantieni le conclusioni circoscritte invece di riempire il vuoto documentale con certezze.

Dire che 302 e 303 sono tecnicamente identici

Il trattamento nella Ricerca può essere raggruppato, ma la semantica dei metodi è diversa. Un 303 prosegue con GET o HEAD; il 302 ha storicamente consentito un comportamento ambiguo da POST a GET.

Affermare un comportamento universale del client, delle credenziali o tra origini

Non presentare come fatto il modo in cui «browser» o «client» gestiscono body, header, cookie e credenziali attraverso un 303 senza indicare client, versione e configurazione. Il comportamento di follow automatico e inoltro delle credenziali varia; un singolo thread o aneddoto non è prova per tutti e non sostituisce la tua revisione di sicurezza del flusso reale.

Post/Redirect/Get nell’HTTP grezzo

Questo flusso semplificato mostra il compito ristretto che un 303 svolge bene.

1. Il browser invia un modulo

POST /orders HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded

item=book&quantity=1

2. Il server ciò elabora e punta al risultato

HTTP/1.1 303 See Other
Location: /orders/confirmation

Il 303 non ripete il POST sul nuovo URL: dice esplicitamente al client di recuperare l’altra risorsa con GET (o HEAD). Un browser che segue il link lo fa con GET.

3. Il browser recupera una pagina di risultato sicura

GET /orders/confirmation HTTP/1.1
Host: example.com

HTTP/1.1 200 OK
Content-Type: text/html

<h1>Order received</h1>

Ricaricando si ripete il GET, non il POST che crea l’ordine. Al contrario, un 307 conserverebbe POST e body: è utile per spostare una richiesta API, ma sbagliato per questo risultato PRG.

Verifica le tue conoscenze: 303 See Other

Cinque domande rapide sul redirect 303. Scegli una risposta per ciascuna e poi controlla.

Cronologia modifiche