{"id":11244,"date":"2026-09-11T15:23:44","date_gmt":"2026-09-11T15:23:44","guid":{"rendered":"https:\/\/www.visilay.com\/?p=11244"},"modified":"2026-09-11T15:23:44","modified_gmt":"2026-09-11T15:23:44","slug":"302-redirect","status":"publish","type":"post","link":"https:\/\/www.visilay.com\/it\/blog\/302-redirect\/","title":{"rendered":"302 redirect: cos’\u00e8 e quando \u00e8 il codice giusto"},"content":{"rendered":"\n

Un 302 redirect<\/strong> \u00e8 un codice di stato HTTP che dice al browser e ai motori di ricerca che una pagina si trova temporaneamente a un altro indirizzo, e che l’URL di partenza resta quello valido. Il nome ufficiale del codice \u00e8 Found<\/em>, e la definizione sta nella RFC 9110, paragrafo 15.4.3<\/a>, la specifica IETF che dal giugno 2022 ha sostituito la RFC 7231 ancora citata da molti articoli: la risorsa risiede temporaneamente sotto un URI diverso, quindi il client dovrebbe continuare a usare l’indirizzo originale per le richieste future.<\/p>\n\n\n\n

La conseguenza pratica \u00e8 una sola, e conviene tenerla a mente prima di tutto il resto: nei risultati di ricerca continua a comparire l’URL di partenza, non quello di destinazione. Se \u00e8 quello che vuoi, il 302 \u00e8 il codice giusto. Se ti aspettavi di veder salire la pagina nuova, hai scelto il codice sbagliato e serve un 301 redirect<\/a>.<\/p>\n\n\n\n

Che cosa succede nei risultati di ricerca<\/h2>\n\n\n\n

La documentazione di Google \u00e8 esplicita su questo punto e non lascia margine di interpretazione. Nella pagina Reindirizzamenti e Ricerca Google<\/a>, aggiornata il 14 aprile 2026, i reindirizzamenti temporanei mostrano la pagina di origine nei risultati, quelli permanenti mostrano la destinazione. Google aggiunge una cosa che in italiano si legge di rado: quando reindirizzi un URL, tiene traccia sia della sorgente sia della destinazione, e decide quale delle due diventa canonica in base a segnali che includono la natura temporanea o permanente del redirect. L’altra diventa un nome alternativo dello stesso URL canonico.<\/p>\n\n\n\n

Vale la pena smontare una frase che circola su parecchi articoli italiani: il 302 non passerebbe il PageRank. La domanda \u00e8 formulata male. Il punto non \u00e8 quanto valore viene travasato da un URL all’altro, \u00e8 quale dei due URL Google tiene in indice. Con un 302 impostato bene i segnali restano dove sono sempre stati, sulla pagina di partenza, perch\u00e9 \u00e8 quella che deve continuare a posizionarsi. Non c’\u00e8 niente da recuperare, perch\u00e9 niente si \u00e8 mosso.<\/p>\n\n\n\n

I 302 che non hai configurato tu<\/h2>\n\n\n\n

Quasi nessuno arriva a cercare questo codice perch\u00e9 ha deciso di impostare un reindirizzamento temporaneo. Ci arriva perch\u00e9 ha lanciato una scansione con Screaming Frog o ha aperto un report di Search Console, ha trovato una colonna piena di 302 e vuole sapere se deve preoccuparsi. Nella maggior parte dei casi quei redirect li ha generati qualcos’altro: il CMS, un plugin, il livello di hosting, una regola di sicurezza.<\/p>\n\n\n\n

Da dove arriva<\/th>Esempio tipico<\/th>Va corretto?<\/th><\/tr><\/thead>
Area riservata e login<\/td>WordPress risponde 302 Found<\/code> su \/wp-admin\/<\/code> e manda a wp-login.php<\/code><\/td>No, \u00e8 il comportamento previsto e quelle URL non vanno indicizzate comunque<\/td><\/tr>
Plugin multilingua<\/td>Reindirizzamento dalla radice del dominio verso \/it\/<\/code> o \/en\/<\/code> in base alla lingua del browser<\/td>No, purch\u00e9 ogni lingua abbia un URL stabile e raggiungibile in modo diretto<\/td><\/tr>
E-commerce, prodotti esauriti<\/td>Il tema rimanda la scheda fuori stock alla categoria di appartenenza<\/td>Dipende: se il prodotto rientra va bene, se \u00e8 uscito di catalogo servono un 301 o un 410<\/td><\/tr>
CDN e firewall applicativi<\/td>Regole di forwarding in cui il codice si sceglie da un menu e nessuno lo rilegge<\/td>S\u00ec, se lo spostamento \u00e8 definitivo<\/td><\/tr>
Ambienti di staging<\/td>Protezione che dirotta i visitatori su una pagina di autenticazione<\/td>No, ma verifica che la stessa regola non sia finita in produzione<\/td><\/tr>
Carrello e checkout<\/td>Passaggi di sessione che rimbalzano l’utente da un passo all’altro<\/td>No, a patto che la catena non superi un paio di salti<\/td><\/tr><\/tbody><\/table>
Origini ricorrenti dei 302 non intenzionali su un sito gi\u00e0 in produzione.<\/figcaption><\/figure>\n\n\n\n

Il caso di WordPress \u00e8 verificabile in dieci secondi su qualsiasi installazione. Una richiesta a \/wp-admin\/<\/code> senza sessione attiva torna un 302 con l’header Location<\/code> puntato a wp-login.php<\/code>. La stessa installazione, invece, usa un 301 per normalizzare la barra finale mancante in fondo agli URL. Due codici diversi nello stesso software, scelti in base a quanto \u00e8 definitiva la destinazione.<\/p>\n\n\n\n

Come verificare un 302 in due minuti<\/h2>\n\n\n\n

Il browser non serve a niente, perch\u00e9 segue il reindirizzamento prima che tu possa leggerlo. Da terminale bastano quattro caratteri:<\/p>\n\n\n\n

curl -I https:\/\/esempio.it\/pagina-vecchia\/<\/code><\/pre>\n\n\n\n
La prima riga della risposta contiene il codice, la riga Location<\/code> contiene la destinazione. Se vuoi vedere l’intera catena di salti, curl -IL<\/code> li stampa uno dopo l’altro: \u00e8 il modo pi\u00f9 rapido per accorgersi che un redirect apparentemente singolo in realt\u00e0 passa da tre URL prima di arrivare a destinazione, con il costo in tempo di risposta che ne consegue.<\/p>\n\n\n\n
Dal lato Google, lo strumento \u00e8 il controllo URL di Search Console: mostra l’URL che Google considera canonico, che \u00e8 esattamente l’informazione che ti interessa quando hai il dubbio di aver usato il codice sbagliato. Se hai messo un 302 su uno spostamento definitivo, il canonico dichiarato da Google rester\u00e0 il vecchio indirizzo molto pi\u00f9 a lungo di quanto ti aspetti.<\/p>\n\n\n\n
Il dettaglio che rompe i form<\/h2>\n\n\n\n
C’\u00e8 un comportamento del 302 che non riguarda il posizionamento e che salta fuori quando meno serve. La RFC 9110 avverte che, per ragioni storiche, davanti a un 302 lo user agent pu\u00f2 cambiare il metodo della richiesta successiva da POST a GET. MDN Web Docs<\/a> conferma che \u00e8 proprio quello che prescrive il Fetch Standard: ricevuto un 302 in risposta a una POST, il browser rif\u00e0 la richiesta in GET.<\/p>\n\n\n\n
Su una pagina di contenuto non cambia niente. Su un endpoint che riceve i dati di un form di contatto, di un checkout o di un’integrazione, la richiesta arriva a destinazione senza il payload e l’invio si perde senza errori visibili. Per quei casi la specifica prevede il 307, che vieta al client di toccare il metodo. Se invece vuoi forzare il passaggio a GET, per esempio dopo un caricamento, il codice corretto \u00e8 il 303.<\/p>\n\n\n\n
Quando il 302 \u00e8 la scelta giusta<\/h2>\n\n\n\n