Catene di redirect e SEO: quanti passaggi sono troppi?

Una catena di redirect è formata da due o più redirect di fila tra l'URL richiesto da qualcuno e la pagina che risponde finalmente con un 200. Google documenta che Googlebot segue fino a 10 passaggi, consiglia di reindirizzare direttamente alla destinazione finale e indica le catene lunghe come un peso sulla scansione. Non dice che distruggano il posizionamento, e dice che i redirect permanenti non causano una perdita di PageRank. Quindi il riepilogo onesto è che le catene sono un problema di latenza e di efficienza di scansione da correggere a basso costo, non una catastrofe SEO.

La maggior parte delle catene non viene costruita di proposito. Qualcuno aggiunge una regola HTTPS, qualcun altro una regola www, uno strumento di marketing avvolge il link in un tracker, e ogni passaggio è ragionevole di per sé. Qui sotto: come si impilano i livelli, quanto costa ogni passaggio, quali affermazioni SEO reggono rispetto alla documentazione di Google e come tracciare e appiattire una catena. Per il vocabolario dei codici di stato, i tipi di redirect degli URL è la mappa. Se la catena torna su se stessa, ti serve invece come risolvere un ciclo di redirect.

Cos'è una catena di redirect

Una catena di redirect si verifica quando l'URL A reindirizza a B, e B reindirizza a C, invece che A puntare direttamente a C. Ogni freccia è una risposta HTTP a sé, e il client effettua una nuova richiesta per ognuna. Un redirect è normale; "catena" inizia da due.

Redirect multipli e passaggi di redirect descrivono la stessa cosa da angolazioni diverse: il numero di redirect tra la richiesta e la pagina finale. Un ciclo di redirect è una catena che non finisce mai perché rivisita un URL. Una catena, al contrario, finisce; ci mette solo troppo ad arrivarci.

Come si formano le catene di redirect

Le catene si impilano perché ogni livello impone la propria preferenza. I livelli abituali, nell'ordine in cui una richiesta li incontra:

• Schema. http:// va a https://, di solito in una regola del server o del proxy.
• Host. L'apex va a www, o viceversa, in una regola diversa che scatta dopo la regola dello schema.
• Percorso. Un normalizzatore della barra finale o delle minuscole riscrive /Promo/ in /promo.
• Wrapper di campagna o tracciamento. Un tracker dei click pubblicitari, il riscrittore di link di una piattaforma email o un link breve si trova davanti a tutto il resto.
• Mappa legacy. Un redirect di un vecchio redesign che nessuno ha riaggiornato.

Mettili insieme e un semplice http://example.com/Promo/ può richiedere quattro passaggi: a HTTPS, poi a www, poi al percorso normalizzato, poi attraverso una vecchia regola del redesign fino alla pagina attiva. I link brevi si aggiungono all'inizio. Uno è un passaggio legittimo. Il danno comincia quando la sua destinazione non è l'URL finale. Incolla http://example.com/promo come destinazione e il tuo link apre una catena che il sito di destinazione ha costruito, invisibile. Gli accorciatori di URL danneggiano la SEO? copre il lato del posizionamento di questa domanda; la risposta breve è che un passaggio pulito va bene e uno impilato spetta a te correggerlo.

Le catene sono facili da non vedere perché i browser le nascondono: la barra degli indirizzi mostra l'URL finale e la pagina si carica, quindi nulla sembra sbagliato. Emergono inoltre solo per la variante della richiesta che fa scattare ogni regola, di solito il più vecchio link http:// sul più vecchio materiale stampato.

Quanti passaggi segue Googlebot?

Googlebot segue fino a 10 passaggi di redirect per impostazione predefinita. Lo dice direttamente la documentazione del crawler di Google. Aggiunge che specifici prodotti di Google possono usare limiti diversi e che lo strumento di controllo dell'URL non segue affatto i redirect. Google non specifica cosa accada a una catena più lunga, quindi presumi che la destinazione semplicemente non venga raggiunta.

Dieci è un tetto, non una raccomandazione. Le indicazioni di Google sullo spostamento dei siti dicono di reindirizzare direttamente alla destinazione finale e, quando non è possibile, di mantenere bassa la catena, "idealmente non più di 3 e meno di 5", perché concatenare aggiunge latenza per gli utenti e non tutti gli user agent supportano catene lunghe. Citalo: un obiettivo di un passaggio, una tolleranza di pochi e uno stop netto a dieci.

I browser hanno i propri limiti. Chrome si arrende a 20 e restituisce ERR_TOO_MANY_REDIRECTS, che è il sintomo trattato nella guida ai cicli di redirect. Neppure lo standard HTTP fissa un numero: la RFC 9110 dice solo che i client dovrebbero rilevare e intervenire sui redirect ciclici.

Quanto costa ogni passaggio in latenza

Ogni passaggio costa almeno un viaggio di andata e ritorno sulla rete. Un passaggio verso un hostname diverso costa di più. Il client risolve il nuovo nome, apre una connessione TCP e completa un handshake TLS prima di poter inviare qualsiasi cosa. L'audit di Lighthouse boccia una pagina con due o più redirect e dice che il viaggio in più può ritardare una risorsa "di centinaia di millisecondi."

Ecco l'aritmetica, a titolo illustrativo e non come benchmark. Assumi un andata e ritorno di 100 ms, che è normale per una connessione mobile con un segnale medio. Un passaggio verso un nuovo host con DNS, TCP e un handshake TLS 1.3 prima della richiesta può facilmente costare da tre a quattro andata e ritorno, quindi da 300 a 400 ms. Un passaggio che riutilizza una connessione aperta verso lo stesso host ne costa uno, quindi 100 ms. Una catena di quattro passaggi con due nuove connessioni spende allora circa 900 ms prima che inizi la pagina vera, contro circa 450 ms per un redirect piatto.

Il mobile peggiora le cose per una ragione semplice: il vincolo è la latenza, non la banda. Le risposte di redirect sono minuscole, quindi l'attesa è fatta tutta di andata e ritorno, e un piano più veloce non fa nulla per loro. Eliminare un passaggio spesso costa meno che ridurre un'immagine. Per quanto dovrebbe costare un singolo passaggio lato server, vedi come i redirect scendono sotto i 15 ms.

Le catene perdono anche dati. Ogni passaggio è un punto in cui una regola di riscrittura può far cadere una query string, e un utm_source eliminato è il modo più comune in cui i parametri UTM scompaiono dagli analytics.

Link equity e crawl budget: cosa documenta Google

Prima la link equity. La documentazione di Google sullo spostamento dei siti afferma che "i redirect 301 e gli altri redirect permanenti non causano una perdita di PageRank". Gary Illyes di Google ha detto lo stesso sui redirect 30x nel 2016, ma era un post sui social, non documentazione. Quindi la vecchia regola pratica secondo cui ogni passaggio di redirect disperde una percentuale fissa di equity è folklore. Nessuna fonte di Google fornisce una percentuale, e vedrai numeri come il 15 percento ripetuti nei post SEO senza citazione. Se qualcuno te ne dà uno, chiedi la fonte.

Le catene non sono comunque gratuite. Sono documentati due effetti. Primo, l'efficienza di scansione: le indicazioni di Google sul crawl budget per i siti grandi dicono chiaramente di evitare le catene di redirect lunghe, che hanno un effetto negativo sulla scansione. Secondo, la latenza per l'utente, trattata sopra, che alimenta i segnali sull'esperienza della pagina. Il crawl budget conta soprattutto sui siti molto grandi o che cambiano in fretta; un sito di 200 pagine difficilmente sentirà un problema di crawl budget per qualche catena, anche se i visitatori sentono comunque il costo in velocità.

C'è anche una sfumatura sull'indicizzazione. Google usa i redirect permanenti come segnale canonico per la destinazione. Quale URL viene mostrato dipende in parte dal fatto che ogni redirect fosse temporaneo o permanente. Una catena che mescola passaggi 301 e 302 rende quel segnale meno chiaro, il che è un buon motivo per stabilire i codici una volta per tutte. Canonical vs redirect 301 approfondisce come questi segnali interagiscono.

La mia posizione: non farti prendere dal panico per l'equity, correggi le catene per velocità e igiene della scansione, e non promettere un miglioramento del posizionamento dall'appiattirne una. Nessuno ha documentato quel miglioramento. Caricamenti più rapidi e meno richieste sprecate sono ciò che puoi misurare.

Come rilevare le catene di redirect

Parti da curl, perché stampa ogni passaggio dove un browser li nasconde. Il primo comando mostra la riga di stato e la Location di ogni risposta:

curl -sIL http://example.com/Promo/ | grep -E '^HTTP|^[Ll]ocation'

Un risultato pulito è un 3xx seguito da un 200. Una catena mostra prima due o più righe 3xx. Per un conteggio e il tempo speso nei redirect, chiedi a curl i suoi numeri:

curl -sL -o /dev/null \
  -w 'hops: %{num_redirects}\nfinal: %{url_effective}\nredirect time: %{time_redirect}s\ntotal: %{time_total}s\n' \
  http://example.com/Promo/

Due avvertenze. -I invia una richiesta HEAD, e alcuni server rispondono a HEAD in modo diverso da GET, quindi se il risultato sembra troppo pulito, ripeti senza -I e scarta il corpo con -o /dev/null -D -. E prova la variante peggiore, quella che farebbe scattare ogni regola: http://, senza www, percorso in maiuscolo, barra finale. Testare solo l'URL canonico è il modo in cui le catene sopravvivono. Preferisco testare troppo le varianti brutte che fidarmi di quella pulita.

In un browser, apri gli strumenti per sviluppatori, vai al pannello Network, spunta "Preserve log" così i passaggi precedenti sopravvivono alla navigazione, e ricarica. Ogni redirect compare come una riga 301 o 302 a sé. Il nostro controllo dei link mostra la stessa catena senza un terminale.

Per fare l'audit di un intero sito, un crawler desktop come Screaming Frog o Sitebulb ha un report sulle catene di redirect che elenca ogni catena con ogni passaggio e i codici di stato. Per i link di lunga durata, inserisci la stessa verifica in un job pianificato, come in monitorare i redirect dei link.

Come appiattire una catena di redirect

Appiattire significa che ogni URL legacy punta direttamente all'URL finale. I passaggi, in ordine:

1. Scegli la forma canonica: schema, host, politica sulla barra finale e maiuscole/minuscole. Scrivila.
2. Traccia ogni vecchio URL e registra la sua destinazione finale.
3. Riscrivi ogni regola in modo che punti a quella destinazione finale, non alla regola successiva.
4. Aggiorna link interni, sitemap e tag rel="canonical" all'URL finale, così crawler e utenti smettono di entrare nella catena.
5. Riesegui la verifica e conferma al massimo un passaggio.

Il trucco lato server è combinare schema e host in un'unica regola. In nginx, si presenta così, usando $request_uri in modo che percorso e query string sopravvivano:

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

server {
    listen 443 ssl;
    server_name example.com;
    # ssl_certificate and key directives go here
    return 301 https://www.example.com$request_uri;
}

Una richiesta a http://example.com/page ora va a https://www.example.com/page in un solo passaggio, dove due regole ne avrebbero prodotti due. Configurare un redirect in .htaccess e come reindirizzare un URL coprono gli equivalenti per Apache e a livello applicativo.

Prova prima con 302. I browser memorizzano nella cache i 301 in modo aggressivo, quindi un errore persiste. Quando la catena è a un solo passaggio, passa al codice permanente. Aiuta anche HSTS: dopo che un browser ha visto un header Strict-Transport-Security, converte internamente http:// in https://, così i visitatori che tornano saltano del tutto quel passaggio. Non fa nulla per i crawler o per i visitatori alla prima visita, quindi integra la regola dell'unico passaggio e non la sostituisce.

Se le catene continuano a ricomparire, la causa è il processo, non la sintassi; la prevenzione del link rot descrive l'abitudine di audit che impedisce l'accumulo di vecchie mappe.

Com'è un redirect di un link breve fatto bene

Un link breve dovrebbe essere esattamente un passaggio dallo slug alla pagina canonica finale, e nient'altro. La richiesta raggiunge il dominio breve. La risposta è un 3xx con la destinazione in Location. La destinazione risponde 200 direttamente. Nessun accorciatore intermedio, nessun tracker che reindirizza di nuovo, nessuna destinazione che passa a www o a HTTPS perché hai incollato la vecchia forma.

Il codice dipende dal caso d'uso.

• 302 (o 307) per link tracciati e modificabili in campagne, post social, email e codici QR. Ti permette di reindirizzare altrove la destinazione in seguito e fa sì che ogni click raggiunga il livello del redirect, così gli analytics restano completi.
• 301 (o 308) quando lo spostamento è permanente e vuoi che la destinazione sia trattata come canonica, come un URL vanity che sostituisce definitivamente un vecchio indirizzo.

Redirect 301 vs 302 descrive la trappola della cache che rende sensato il 302 come impostazione predefinita. Due abitudini mantengono la catena a un passaggio. Incolla sempre l'URL finale come destinazione, dopo averlo caricato una volta e aver copiato l'indirizzo dalla barra, ed esegui il conteggio con curl qui sopra sui nuovi link prima del lancio. Se vuoi quella destinazione memorizzata una volta sola e modificabile senza ristampare, parti da uno spazio di lavoro Elido gratuito e traccia il tuo primo link con i comandi di questo articolo.

Le terze parti possono aggiungere passaggi che non controlli. Il tracker dei click di una piattaforma pubblicitaria o il wrapper dei link di un provider email si colloca davanti al tuo link breve che ti piaccia o no, ed è il miglior argomento per mantenere la tua parte del percorso a un solo passaggio. Un dominio personalizzato non ne aggiunge uno, come spiega domini personalizzati per i link brevi.

Questo articolo fa parte del cluster di ingegneria. Per la mappa completa dei codici di stato, leggi i tipi di redirect degli URL, e per il livello di redirect dietro un link breve, come funzionano gli accorciatori di URL.

Correlati sul blog

• Ciclo di redirect: come trovare e risolvere ERR_TOO_MANY_REDIRECTS
• Tipi di redirect degli URL: 301, 302, 307, 308 e altri
• Redirect 301 vs 302: quale dovrebbero usare i link brevi
• Gli accorciatori di URL danneggiano la SEO? La risposta onesta
• Canonical vs redirect 301: come scegliere il segnale giusto
• Come reindirizzare un URL: sei modi, e quando ciascuno è giusto