Come impostare un redirect 301 (e come verificare che funzioni)

Un redirect 301 è una risposta del server che dice a browser e motori: questa URL si è spostata per sempre, la roba sta di là. Sono due righe di intestazione, lo status code 301 Moved Permanently e l’header Location con la destinazione. Per Google è un voto di canonizzazione: indica quale delle due URL deve restare in indice.

La sintassi è la parte facile. Quello che si rompe sta altrove: snippet incollati male, destinazioni ancora in http://, un 302 al posto del 301 che credevi di aver scritto. L’errore non fa rumore, perché il sito funziona e i visitatori atterrano dove devono: te ne accorgi settimane dopo davanti a Search Console, con la vecchia URL ancora lì. E fra quello che scrivi e quello che risponde il server ci sono una cache, un CDN e a volte un plugin che pensa di aiutarti.

Come si scrive un 301 su Apache, nginx, WordPress, Cloudflare e Next.js, quando invece serve un 308, come si verifica con curl che sia partito davvero, e cosa fare con catene, loop e cambio dominio: l’articolo risponde a ciascuna di queste domande, con la regola pronta per ogni server.

Cos’è un redirect 301

Un redirect 301 è una risposta HTTP che unisce lo status code 301 Moved Permanently e un header Location con l’URL di destinazione. Il corpo della risposta è vuoto o quasi: tutto il lavoro lo fanno le intestazioni.

Si guarda in tre secondi.

curl -sI https://esempio.it/vecchia-pagina/ | head -3

HTTP/2 301
location: https://esempio.it/nuova-pagina/
content-type: text/html; charset=UTF-8

Per la Ricerca Google quelle due righe sono un voto di canonizzazione. La pagina di Google sui reindirizzamenti, aggiornata il 17 aprile 2026, chiude i permanenti in una riga: «Googlebot segue il reindirizzamento e la pipeline di indicizzazione lo utilizza come un indicatore del fatto che la destinazione del reindirizzamento dovrebbe essere canonica».

Canonica vuol dire che fra due URL che mostrano lo stesso contenuto Google ne sceglie una da tenere nei risultati, e l’altra diventa un nome alternativo. Il 301 è il modo più diretto che hai per dire quale delle due.

Nella stessa pagina Google elenca cosa considera permanente: 301, 308, meta refresh a 0 secondi, refresh HTTP a 0 secondi, location in JavaScript e i redirect crypto. L’elenco è ordinato per probabilità che Google li interpreti bene, e il lato server sta in cima.

Il modello mentale è il cartello «traslocato» avvitato sulla saracinesca, non il tizio all’angolo che ti fa cenno di andare dietro l’isolato. Il cartello lo legge chiunque passi, anche di notte, anche quando tu non ci sei. Il tizio all’angolo è il 302: funziona finché c’è, e nessuno ci costruisce sopra un archivio.

Una precisazione che evita mezzo malinteso: il 301 riguarda una URL alla volta. Non è un’impostazione del sito e non esiste un «redirect del dominio» che copra magicamente tutte le pagine. Quando sembra che esista, sotto c’è una regola scritta da qualcuno che cattura un pattern e ricostruisce la destinazione.

Il redirect 301 fa perdere PageRank?

No, e la frase ufficiale sta in un posto che nessuno va a cercare. Non nella pagina sui reindirizzamenti, che il PageRank non lo nomina proprio, ma nella guida di Google al cambio di sito, aggiornata il 24 giugno 2026, sotto il titolo «Non preoccuparti del merito dei link»: «301 e altri reindirizzamenti permanenti non causano una perdita in PageRank».

Il 302 sta invece fra i temporanei: «Googlebot segue il reindirizzamento, ma la pipeline di indicizzazione non lo utilizza come un indicatore del fatto che la destinazione del reindirizzamento dovrebbe essere canonica. La pagina di destinazione potrebbe comunque essere indicizzata se sono presenti altri indicatori di canonicalizzazione».

Quella definizione toglie un’ansia ricorrente: un 302 messo per sbaglio non azzera niente. Googlebot lo segue come segue gli altri, e la destinazione può finire in indice per altre strade. Quello che il 302 non fa è votare. Con un temporaneo la pagina che Google tende a lasciare nei risultati resta l’origine, che è comodo durante una manutenzione e diventa un guaio se lo spostamento era definitivo.

301, 302, 307 o 308: la differenza e come si sceglie il codice

La differenza fra 301 e 302 sta in due cose: quanto dura lo spostamento e cosa succede al metodo della richiesta. Il primo criterio lo conoscono tutti. Il secondo è quello che decide quando ti serve un 308.

La specifica HTTP è chiara nella nota al 301: «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 308 (Permanent Redirect) status code can be used instead». Cioè: per ragioni storiche uno user agent può cambiare il metodo da POST a GET, e se la cosa non ti va bene esiste il 308. Sul 307, §15.4.8, la specifica non lascia margine: «the user agent MUST NOT change the request method», lo user agent non deve cambiare il metodo.

Lato Google i quattro codici si riducono a due. Nella pagina su come Google tratta i codici 3xx il 301 è «un indicatore forte del fatto che la destinazione di reindirizzamento deve essere elaborata», il 302 «un indicatore debole»; il 303 e il 307 sono equivalenti al 302, il 308 al 301.

Il criterio pratico è secco. Stai spostando pagine che si aprono con un GET? Il 301 basta e avanza. Stai spostando un endpoint che riceve POST, un form, un webhook, una API? Metti un 308, o rischi di scoprire che le richieste arrivano a destinazione svuotate del loro contenuto.

Perché un redirect sbagliato continua a scattare anche dopo la correzione

Perché il browser se l’è tenuto. La specifica HTTP dice che «A 301 response is heuristically cacheable», cioè che la risposta è memorizzabile anche se tu non hai impostato un solo header di cache. Next.js lo scrive ancora più chiaro nella doc su permanent: true, che usa il 308 e «instructs clients/search engines to cache the redirect forever»: dice a client e motori di tenersi il reindirizzamento per sempre.

Da qui due abitudini che valgono più di qualsiasi plugin.

Testa sempre in finestra pulita o con curl. Se ricarichi e vedi ancora la vecchia destinazione, il bug potrebbe essere la cache del tuo browser, e tu stai per riscrivere una regola che era già giusta.

Metti in conto che disfare un 301 è lento. Correggi la regola sul server, ma i client che hanno già visto la risposta saltano direttamente alla vecchia destinazione senza chiedere niente a nessuno. Finché una regola nuova è in prova, un Cache-Control con max-age basso sulla risposta di redirect ti lascia una via d’uscita. Dopo, quella via non c’è più.

Redirect 301 con .htaccess su Apache

Per i casi semplici bastano Redirect e RedirectMatch, le direttive di mod_alias. RewriteRule serve quando c’è una condizione da valutare prima di decidere, tipo lo schema della richiesta, l’host o la query string.

Prima però il prerequisito che salta fuori sempre a cose fatte: .htaccess funziona su Apache e su LiteSpeed. Su nginx non esiste, e se il tuo hosting gira lì puoi scrivere il file per un pomeriggio intero senza che nessuno lo legga. Su Apache serve anche che AllowOverride consenta l’override nel contesto giusto: con AllowOverride None il file viene ignorato, senza un errore, senza una riga di log che te lo dica.

Il controllo dura quanto una richiesta: scrivi una regola qualsiasi in cima al file, chiedi l’URL con curl -sI e guarda se lo status cambia. Se non succede niente, il problema è il file, non la regola.

Due dettagli che fanno perdere tempo prima ancora di cominciare. Il file si chiama .htaccess, con il punto davanti, e parecchi client FTP i file che iniziano con il punto non li mostrano finché non glielo chiedi. Il secondo: vale per la directory in cui sta e per tutto quello che c’è sotto, quindi un .htaccess dentro /blog/ non tocca il resto del sito, quello in root tocca tutto.

Una regola sbagliata qui dentro non produce un avviso, produce un errore 500 su tutto il sito. Prima di salvare, tieni una copia del file da qualche parte: è l’unico rollback che hai.

Quando basta Redirect e quando serve RewriteRule

Sono due moduli diversi, con due sintassi che si somigliano abbastanza da farti sbagliare. Il primo argomento di Redirect è un URL-path che comincia con lo slash, non un hostname: la documentazione di mod_alias scrive «The old URL-path is a case-sensitive (%-decoded) path beginning with a slash. A relative path is not allowed», dove case-sensitive significa che maiuscole e minuscole contano. Redirect 301 https://vecchio.it/pagina/ https://nuovo.it/pagina/ sembra ragionevole e non funziona.

È Apache stessa a mettere mod_rewrite in fondo alla fila. Nella pagina su quando evitarlo scrive che «mod_rewrite should be considered a last resort, when other alternatives are found wanting», l’ultima risorsa quando le altre non bastano, e che una redirezione semplice «should be accomplished using these directives rather than RewriteRule», va fatta con quelle direttive e non con RewriteRule.

C’è poi l’ordine di esecuzione, che cambia a seconda di dove scrivi: «In server/virtual-host context, mod_rewrite runs first; in per-directory context (.htaccess), mod_alias runs first». Dentro un .htaccess gira prima Redirect. Se hai una Redirect e una RewriteRule che matchano lo stesso path e ti sembra che una delle due venga ignorata, non stai impazzendo: sta vincendo l’altra.

Gli snippet .htaccess che funzionano

Sei casi, tutti con destinazione https, tutti testabili con una richiesta.

Singolo URL, il caso più comune di tutti:

Redirect 301 /vecchia-pagina/ https://esempio.it/nuova-pagina/

Un’intera directory, con tutto quello che sta sotto. RedirectMatch fa lo stesso lavoro con le espressioni regolari, e $1 riporta a destinazione la parte catturata:

RedirectMatch 301 ^/blog/(.*)$ https://esempio.it/guide/$1

Da http a https, conservando path e query string:

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://esempio.it/$1 [R=301,L]

Da non-www a www, in un salto solo. La RewriteCond evita che la regola matchi anche la propria destinazione:

RewriteEngine On
RewriteCond %{HTTP_HOST} ^esempio\.it$ [NC]
RewriteRule ^(.*)$ https://www.esempio.it/$1 [R=301,L]

Una vecchia URL con query string verso una URL parlante. Il ? finale nella destinazione serve a buttare via la query string originale, altrimenti se la porta dietro:

RewriteEngine On
RewriteCond %{QUERY_STRING} ^id=42$
RewriteRule ^scheda\.php$ https://esempio.it/prodotti/sedia-vienna/? [R=301,L]

Trailing slash mancante, solo per i path che non corrispondono a un file reale:

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*[^/])$ https://esempio.it/$1/ [R=301,L]

Una cosa sola, che vale per tutti e sei: il flag va scritto [R=301,L] per intero. [R,L] produce un 302, il sito continua a funzionare benissimo e Google continua a tenere in indice la vecchia URL. È l’errore più silenzioso della lista, e si trova solo leggendo l’header della risposta.

Conta anche l’ordine: le regole si valutano dall’alto e con il flag L la prima che matcha chiude la partita.

Dove vanno le regole in un .htaccess di WordPress

Sopra il commento # BEGIN WordPress, mai in mezzo ai marker. Il blocco fra i due marker lo riscrive WordPress: la funzione che lo genera ci infila dentro un avviso, «The directives (lines) between BEGIN WordPress and END WordPress are dynamically generated, and should only be modified via WordPress filters. Any changes to the directives between these markers will be overwritten». Traduzione: quelle righe sono generate a runtime, si toccano solo via filtri, e qualunque modifica scritta lì dentro viene sovrascritta.

Non serve un evento drammatico. Basta che qualcuno apra Impostazioni, Permalink e prema Salva.

# le tue regole vanno qui, sopra i marker
Redirect 301 /vecchia-pagina/ https://esempio.it/nuova-pagina/

# BEGIN WordPress
# Le direttive di WordPress stanno qui dentro e vengono rigenerate.
# END WordPress

Se hai già perso delle regole una volta senza capire perché, ecco perché. Vale anche al contrario: se un plugin di caching o di sicurezza scrive un suo blocco con marker propri, quelle righe sono di sua competenza e riscriverle a mano dura fino al prossimo salvataggio delle sue impostazioni. I marker in un .htaccess sono confini, e conviene trattarli come tali.

Redirect 301 su nginx

La forma base su nginx è return 301 dentro il blocco server, con $request_uri per conservare path e query string. Niente regex da valutare, niente riscritture: è anche la strada più veloce.

server {
    listen 443 ssl;
    server_name vecchio.it www.vecchio.it;
    return 301 https://esempio.it$request_uri;
}

return accetta una URL per i codici 301, 302, 303, 307 e 308, quindi un 308 si scrive cambiando tre caratteri.

Quando devi valutare un pattern c’è rewrite. Il flag permanent «returns a permanent redirect with the 301 code», mentre redirect restituisce un 302:

rewrite ^/blog/(.*)$ https://esempio.it/guide/$1 permanent;

La regola che fa perdere un pomeriggio sta nella doc del modulo rewrite: «If a replacement string starts with http://, https://, or $scheme, the processing stops and the redirect is returned to a client». Cioè: se la stringa di sostituzione comincia con http://, https:// o $scheme, l’elaborazione si ferma e il redirect parte comunque, anche senza flag. Senza flag però il codice è 302, e la differenza la vedi solo se vai a leggere l’header.

Il classico http verso https, in un blocco server dedicato alla porta 80:

server {
    listen 80;
    server_name esempio.it www.esempio.it;
    return 301 https://esempio.it$request_uri;
}

Un dettaglio di sintassi che non perdona: ogni direttiva finisce con il punto e virgola, e il file va ricaricato perché la modifica valga. nginx -t controlla la configurazione prima di applicarla, nginx -s reload la ricarica senza buttare giù le connessioni aperte. Saltare il primo comando è il modo più rapido per spegnere un sito con un punto e virgola dimenticato.

Chi arriva da Apache tende a riscrivere le RewriteRule una per una in rewrite. Nella maggior parte dei casi bastano tre righe di return.

Redirect 301 su WordPress

Il criterio è dove sta la regola, non quale plugin installi. Le regole che valgono per tutto il sito, http verso https, www, cambio dominio, stanno sul server: sono poche, non cambiano mai e non costano una riga di PHP a ogni richiesta. Le singole URL che i redattori spostano ogni settimana stanno in un plugin, che gli dà un’interfaccia e li tiene lontani dai file di configurazione.

Sui plugin la regola è banale e la salta chiunque: prima di installarne uno, apri la sua scheda su wordpress.org e guarda la data dell’ultimo aggiornamento e la versione di WordPress con cui è dichiarato testato. Un plugin di redirect fa un lavoro semplice, quindi continua a funzionare a lungo anche dopo che l’autore ha smesso di seguirlo, ed è esattamente per questo che te lo ritrovi installato e abbandonato. Quelli chiusi per problemi di sicurezza spariscono dalla directory ma restano attivi sui siti che li avevano già.

Poi c’è il classico di functions.php. wp_redirect() ha lo status 302 di default, quindi il redirect che credevi permanente non lo è:

wp_redirect( 'https://esempio.it/nuova-pagina/', 301 );
exit;

Il secondo parametro serve. L’exit pure: la funzione non interrompe l’esecuzione da sola, e senza quella riga PHP continua a fare il suo lavoro dopo aver mandato l’header. Se la destinazione arriva da fuori, da un parametro in query string o da un campo salvato, usa wp_safe_redirect(), che accetta solo host consentiti e non ti trasforma il sito in un trampolino per gli altri.

Cloudflare, Next.js e i siti senza .htaccess

Se il sito sta dietro un CDN o gira su un framework, il redirect può vivere prima del server oppure dentro il codice, e il .htaccess non c’entra più niente.

Su Cloudflare i Bulk Redirects si definiscono a livello di account: «Bulk Redirects allow you to define a large number of URL redirects at the account level, which can apply across domains in your account», un elenco grande di redirect valido anche su più domini dello stesso account. Girano sull’edge, dopo il WAF nella pipeline della richiesta, e all’origin non arriva niente. La pagina dei Bulk Redirects, aggiornata al 26 giugno 2026, avverte anche del rovescio: se una regola WAF blocca la richiesta, il redirect non scatta proprio.

Su Next.js il 301 nel next.config non lo trovi, e non è una svista di chi ha scritto la doc. Nella configurazione dei redirect permanent: true «will use the 308 status code which instructs clients/search engines to cache the redirect forever», e permanent: false usa il 307. Il motivo sta scritto lì accanto: con 301 e 302 molti browser cambiano il metodo in GET, mentre 307 e 308 «explicitly preserve the request method used», conservano il metodo della richiesta.

module.exports = {
  async redirects() {
    return [
      {
        source: '/vecchia-pagina',
        destination: '/nuova-pagina',
        permanent: true,
      },
    ]
  },
}

Per Google il 308 vale quanto il 301, quindi in indice non cambia niente. Cambia solo che il 301 nel codice non lo scrivi.

Come verificare un redirect 301

curl -sI ti dà lo status e il Location del primo salto, curl -sIL segue la catena fino in fondo e te la stampa tutta. Sono i due comandi che coprono quasi tutte le verifiche.

Il primo salto:

curl -sI https://esempio.it/vecchia-pagina/ | grep -Ei '^(HTTP|location)'

La catena intera, ripulita dal resto degli header:

curl -sIL https://esempio.it/vecchia-pagina/ | grep -Ei '^(HTTP|location)'

HTTP/1.1 301
location: https://www.esempio.it/vecchia-pagina/
HTTP/2 301
location: https://www.esempio.it/nuova-pagina/
HTTP/2 200

Tre righe HTTP, quindi due salti prima di arrivare al 200. Per contarli senza leggerli uno per uno:

curl -sIL https://esempio.it/vecchia-pagina/ | grep -c '^HTTP'

Il numero che esce comprende anche la risposta finale, quindi gli hop sono uno in meno.

Tre note per non leggere male l’output. -I chiede una HEAD, e qualche server tratta HEAD e GET in modo diverso: se il risultato ti sembra strano, riprova con curl -sL -o /dev/null -w '%{http_code} %{url_effective}\n'. I nomi degli header arrivano in minuscolo con HTTP/2, quindi il grep va fatto senza distinzione di maiuscole. E curl la cache del browser non ce l’ha, che è esattamente il motivo per cui conviene fidarsi di lui.

Dentro Search Console ci sono altri due strumenti, gratuiti. Controllo URL ti dice cosa ha visto Googlebot su una singola URL, redirect compreso. Il report Indicizzazione delle pagine ha uno stato dedicato, «Pagina con reindirizzamento», che la guida di Search Console descrive così: «Si tratta di un URL non canonico che reindirizza a un’altra pagina. Pertanto, questo URL non verrà indicizzato. L’URL di destinazione del reindirizzamento potrebbe essere indicizzato o meno, a seconda di come lo considera Google».

Trovare le tue vecchie URL dentro quello stato è normale, ed è la conferma che il redirect è stato visto. La frase da tenere a mente è l’ultima: quello stato non dice niente sul destino della destinazione, che va controllata a parte.

Il 307 che non hai configurato tu

Se un checker ti mostra un 307 Internal Redirect da http:// a https:// sul tuo dominio, quella riga non arriva dal tuo server. È HSTS. La RFC 6797, al §8.3, prescrive che prima di caricare una URL http su un Known HSTS Host lo user agent «MUST replace the URI scheme with https»: deve sostituire lo schema con https.

La sostituzione avviene dentro il browser, prima che parta la richiesta. Da curl quel salto non lo vedi, perché non c’è nessuna risposta ad averlo generato, e questo spiega perché un checker che gira su browser e la tua riga di comando ti mostrano due catene diverse sullo stesso indirizzo. Nessuna delle due sta mentendo: stanno misurando due cose diverse.

Da qui una conseguenza pratica sulle catene. Il salto che aggiunge il browser non è una regola che puoi accorciare, e non lo togli riscrivendo la configurazione. Se stai contando gli hop per capire se sei sopra la soglia, conta quelli che vede curl: sono le risposte che il tuo server manda davvero.

Catene di redirect, loop e ERR_TOO_MANY_REDIRECTS

I numeri ufficiali sono tre. «Per impostazione predefinita, i crawler di Google seguono fino a 10 hop di reindirizzamento», si legge nella pagina sui codici di stato, dove è precisato che Google-InspectionTool i redirect non li segue affatto. La guida al cambio di sito chiede però di stare molto sotto quel tetto: «Anche se Googlebot può seguire fino a 10 hop in una “catena” di più reindirizzamenti (ad esempio Pagina 1 > Pagina 2 > Pagina 3), consigliamo di reindirizzare direttamente alla destinazione finale. Qualora non fosse possibile, non utilizzare un numero eccessivo di reindirizzamenti (idealmente, non più di 3 e meno di 5)». Il motivo lo dà la stessa pagina: la latenza per gli utenti, e il fatto che non tutti gli user agent reggono catene lunghe.

Le catene non le scrive nessuno di proposito. Si formano da sole, quasi sempre in uno di questi tre modi.

Due regole in fila invece di una. La regola http verso https e la regola non-www verso www sono scritte separate, e una richiesta a http://esempio.it/x fa due salti prima di atterrare. Si appiattisce mettendo la destinazione finale, schema e host compresi, già nella prima regola.

Un plugin sopra una regola di server. Il plugin manda la vecchia URL alla nuova, il server manda la nuova alla versione con lo slash finale. Due sistemi che non si parlano, due hop.

Una regola di migrazione mai rimossa. Il dominio è cambiato due volte in cinque anni e le regole sono ancora tutte lì, in ordine cronologico, ognuna che passa la palla alla successiva.

Il loop è la stessa storia portata all’estremo, e il browser risponde ERR_TOO_MANY_REDIRECTS. La causa tipica è una regola che matcha anche la propria destinazione: mandi tutto a https://esempio.it/$1, la richiesta ci arriva, la regola scatta di nuovo, e si va avanti finché non interviene il browser. Il rimedio è una condizione che escluda la destinazione, come la RewriteCond %{HTTP_HOST} dello snippet www più sopra. Per trovare la regola colpevole, curl -sIL con il conteggio degli hop ti dice fra quali due indirizzi sta rimbalzando, e a quel punto la riga da cercare nel file è una sola.

Redirect 301 e cambio dominio

La mappatura vale più della sintassi. Prima di toccare qualsiasi configurazione ti serve un elenco vecchia URL verso nuova URL, una riga per pagina, costruito partendo dalle URL che hanno traffico e link in ingresso. Il resto del lavoro è meccanico.

Poi c’è l’errore che costa più caro, e Google lo scrive per esteso: «Non reindirizzare un numero elevato di URL del sito precedente a un unico URL di destinazione, ad esempio la home page del nuovo sito. Ciò può confondere gli utenti e potrebbe essere considerato un errore soft 404». Subito dopo arriva un’eccezione dichiarata, che fa parte della regola: «Se, però, hai unito i contenuti che prima erano ospitati su diverse pagine in un’unica nuova pagina, puoi reindirizzare gli URL precedenti a questa nuova pagina raggruppata». Il consolidamento vero è legittimo. Quello che Google boccia è la home usata come discarica.

Il soft 404, nel report Indicizzazione delle pagine, ha una definizione sua: «La richiesta della pagina restituisce una presunta risposta soft 404. Ciò significa che restituisce un semplice messaggio “non trovato” ma non un codice di risposta HTTP 404». La home piena di redirect ci finisce per questo: risponde 200, ma non contiene niente di quello che l’utente stava cercando.

Sulla durata Google dà due consigli diversi a due destinatari diversi. Per i motori: «Conserva i reindirizzamenti il più a lungo possibile, in genere almeno 1 anno». Un anno è la finestra che si dà per riscansionare tutto e riassegnare i link che altri siti hanno ancora verso le vecchie URL. Per le persone, invece: «Dal punto di vista degli utenti, valuta la possibilità di mantenere i reindirizzamenti a tempo indeterminato». Chi ha un vecchio indirizzo nei preferiti non ha una scadenza.

Lo strumento Cambio di indirizzo serve quando passi da un dominio o sottodominio a un altro, e vanno inviate le richieste per tutte le varianti del vecchio nome, www e non-www comprese. Per le migrazioni da HTTP a HTTPS Google scrive esplicitamente di non usarlo.

Restano i lavori di contorno, quelli che si dimenticano: aggiornare i link interni, controllare che i rel="canonical" del nuovo sito puntino alle nuove URL, sistemare gli hreflang se ci sono, inviare la nuova sitemap. Su quest’ultima ne ho scritto nella guida alla sitemap XML.

Quando il 301 è la risposta sbagliata

Quando la pagina non ha un equivalente, la risposta giusta è 404 o 410. Un redirect di cortesia verso la categoria vagamente somigliante sposta il problema dall’utente ai tuoi report: chi cercava quel prodotto atterra su una lista, non trova quello che voleva e torna indietro. Il 410 dice esplicitamente che il contenuto è stato rimosso, il 404 che non c’è. Nessuno dei due è una sconfitta.

Quando le due URL devono restare entrambe raggiungibili, serve rel="canonical", non un 301. Il redirect toglie di mezzo l’originale: chi chiede la vecchia URL non la vede più, punto. Il canonical lascia tutte le versioni aperte e dice a Google quale considerare principale. È la differenza fra una pagina spostata e una pagina che esiste sotto più indirizzi, il caso classico delle URL parametriche generate dai filtri, che ho affrontato nella guida ai filtri di un e-commerce.

E poi il caso che passa per un dettaglio: il redirect non ripara i link interni rotti. Ripara la richiesta, non il link. Se cento link nel tuo sito puntano a una URL che risponde 301, ogni visita paga un salto in più e il file di configurazione si allunga a ogni ristrutturazione. Il redirect tiene in piedi i link degli altri, che non puoi cambiare. I tuoi cambiali. Dei prodotti fuori catalogo, dove la scelta fra tenere, reindirizzare e rimuovere ha conseguenze diverse, ho scritto nella guida alla SEO per e-commerce.

Domande frequenti