Vai al contenuto 
Prestazioni del reindirizzamento HTTP determina in modo misurabile la velocità con cui gli utenti e i crawler raggiungono gli URL di destinazione e l'autorità che viene mantenuta durante il passaggio. In questa guida vi mostrerò strategie specifiche per 301 e 302 che riducono la latenza, SEO ed evitare le fonti di errore.
Punti centrali
Riassumo brevemente le linee guida più importanti prima di entrare nel dettaglio. In questo modo si ottiene prima un filo conduttore e si possono stabilire le priorità. Mi concentro sulla selezione del codice giusto, sulla riduzione al minimo dei percorsi di reindirizzamento, sulle strategie di cache e sulla diagnostica. Passo poi all'implementazione nelle configurazioni di hosting, al monitoraggio e alle prestazioni dei dispositivi mobili. Ogni raccomandazione mira a ridurre al minimo la latenza, a un'indicizzazione pulita e a prestazioni stabili. Esperienza dell'utente.
- Selezione del codice301 per i permanenti, 302/307 per i temporanei.
- Smontare le cateneOgni fase ha un costo in termini di tempo e di budget.
- Intestazione della cache301 cache long, 302 hold short.
- Obiettivi 1:1Le pagine di destinazione pertinenti assicurano il posizionamento.
- MonitoraggioControllare la quota 3xx, il TTFB e i loop.
Mi affido a regole snelle e a percorsi diretti. È così che mantengo il Latenza basso e di evitare i reindirizzamenti che aumentano il tempo di caricamento.
301 vs 302: effetto su SEO, cache e UX
A 301 segnali in modo permanente, un 302 solo temporaneamente - questa scelta influenza il flusso di autorità, la cache e l'esperienza dell'utente. Il 301 trasferisce la maggior parte del potere di collegamento e di solito viene memorizzato nella cache dal browser. 302 mantiene l'origine in primo piano, il che è utile per i test, ma viene ricontrollato a ogni visita. Per modifiche permanenti come HTTPS, nuova struttura o spostamento del dominio, uso 301. Per campagne, finestre di manutenzione o test incrementali, uso 302 o 307 se il metodo di richiesta deve essere conservato.
| Tipo di reindirizzamento | Segnale | Trasferimento SEO | Caching | Utilizzo |
|---|---|---|---|---|
| 301 | Permanente | Alto | Forte | Migrazione, struttura, HTTPS |
| 302 | Temporaneo | Limitato | Debole | Test A/B, campagne |
| 307 | Temporaneo | Medio | Debole | Ricevere il modulo-POST |
| 308 | Permanente | Alto | Forte | API, metodo receive |
Scelgo sempre il codice di stato per intenzione, non per abitudine. In questo modo evito Perdite in classifica e ridurre la rilavorazione.
Costi delle prestazioni: ogni redirect è importante
Ogni inoltro provoca ulteriori Viaggi di andata e ritornoDNS, handshake, richiesta e risposta. Anche un solo passaggio costa spesso 100-300 ms, a seconda della rete e della distanza. Sulle reti mobili, l'impatto aumenta rapidamente, soprattutto in presenza di più hop. I reindirizzamenti di risorse (CSS, JS, immagini) sono doppiamente dannosi perché ritardano il rendering critico. Per questo motivo, riduco i reindirizzamenti a un solo passaggio e mantengo tutte le risorse direttamente accessibili.
Accorcio ulteriormente i percorsi accorpando le modifiche al protocollo. Un 301 pulito da http:// a https:// e la standardizzazione parallela di www/non-www risparmiano Richieste. Con l'HSTS, riduco i costi di reindirizzamento futuri perché il browser favorisce direttamente l'HTTPS. Un reindirizzamento edge sul nodo CDN è utile per gli utenti internazionali. In questo modo si riduce al minimo il tempo di attesa prima del caricamento effettivo della pagina.
Evitare le catene di reindirizzamento: Diagnosi e accorciamento
Regalare catene come A → B → C Budget per le strisciate e tempo. Per prima cosa controllo gli URL iniziali, la navigazione principale, le sitemap interne e le landing page con collegamenti frequenti. Poi apro i log di rete nel browser e seguo tutte le risposte 3xx. Affronto ogni fase alla fonte e conduco direttamente da A a C finché la catena non scompare. Quanto le catene vi rallentino è spiegato in questo articolo su Perché le catene di reindirizzamento aumentano il tempo di caricamento in modo vivido.
Poi ripulisco i link interni in modo che non si creino nuovi salti. In questo modo il lavoro è doppiamente utile: i bot raggiungono rapidamente l'URL finale e gli utenti risparmiano tempo di clic. Controllo anche le regole lato server per verificare la presenza di condizioni duplicate. Le eccezioni mancanti spesso creano dei loop o delle eccezioni inutili. luppolo. Un'altra strisciata alla fine conferma che tutto finisce in un unico passaggio.
Migrazione HTTPS senza deviazioni
Per il passaggio all'HTTPS, ho impostato un parametro globale 301 da tutti i percorsi http all'equivalente https. Allo stesso tempo, definisco un canonical (con o senza www) e inoltro coerentemente la variante alternativa. Aggiorno i link interni, le sitemap e i canonical in modo che non rimangano salti nascosti. Dopo la messa in funzione, attivo l'HSTS quando tutti i sottodomini sono pronti. Informazioni più approfondite sono disponibili in questo articolo su Prestazioni del reindirizzamento HTTPS con frequenti errori di configurazione.
Poi verifico se le API, i webhook e i callback di pagamento funzionano ancora correttamente. Le rotte POST, in particolare, hanno spesso bisogno di 307/308 per mantenere intatto il metodo. Blocco proattivamente i contenuti misti per evitare i fallback a http. Rimuovo i vecchi certificati in modo che i clienti non possano utilizzare Avvertenze vedere. Alla fine, controllo le statistiche 3xx e il TTFB finché i valori non sono stabili.
Strategie di caching e CDN
Con intestazioni di cache adeguate, un 301 il primo reindirizzamento alle future chiamate dirette. Imposto una validità lunga per 301 e la mantengo corta per 302, per rimanere flessibile. Sul CDN, sposto le regole verso il bordo in modo che gli utenti ricevano l'URL finale nel nodo successivo. Le richieste di origine diminuiscono, il tempo per il primo byte è più breve. Verifico anche se i cookie o le intestazioni Vary aggirano inutilmente le cache.
Per il traffico elevato, scelgo un hosting 301 302 con I/O veloce, in modo che i reindirizzamenti rispondano senza ritardi. Le regole Edge risparmiano i viaggi di andata e ritorno verso l'origine e riducono i picchi di carico. Evito le regole duplicate tra CDN e origine perché creano salti. Le regioni di test rivelano chiaramente le differenze di latenza. Questo significa che più budget confluisce nei contenuti e meno nei marcia a vuoto.
Implementazione lato server: Apache, Nginx, WordPress
Do priorità ai reindirizzamenti lato server perché reagisce più velocemente e guida in modo affidabile i bot. In Apache, spesso è sufficiente una breve regola di riscrittura in .htaccess. In Nginx, utilizzo il ritorno o la riscrittura direttamente nella configurazione del server. Per casi particolari, lavoro con le intestazioni PHP, ma non faccio affidamento sui salti JavaScript lato client. Una buona panoramica delle priorità si trova in questa guida a Reindirizzamenti di dominio e prestazioni.
# Apache (.htaccess)
RewriteEngine On
# 301 diretto dal vecchio al nuovo URL
RewriteRule ^old-url$ /new-url [R=301,L]
# Nginx (contesto server)
location = /old-url {
restituisce 301 /new-url;
}
# PHP (come fallback)
header("Location: https://example.com/neue-url", true, 301);
uscita;
In WordPress, evito un numero eccessivo di regole per i plugin e preferisco memorizzare i percorsi principali nel server. Divido grandi insiemi di regole in base a schemi, in modo che la valutazione rimanga veloce. Uso con parsimonia i segnaposto per ridurre al minimo i costi delle regex. Mantengo basso il numero di condizioni e uso chiare Priorità. Dopo il rollout, verifico la sequenza con richieste reali.
Monitoraggio, misurazione e diagnosi dei guasti
Misuro gli effetti di reindirizzamento con ricciolo (-I, -L), devtools del browser, log del server e controlli esterni. I fattori decisivi sono il numero di salti, il TTFB, le visite alla cache e lo stato HTTP. Monitoro anche il tasso di 3xx in Analytics e nei file di log. Picchi evidenti indicano nuove catene o loop. I test effettuati da diverse regioni riconoscono le differenze di latenza e le mancanze della CDN.
Ho impostato degli avvisi per le condivisioni 301/302 al di sopra di una soglia definita. Un crawl regolare porta alla luce vecchi link interni che stanno ancora reindirizzando. Per le campagne, imposto date di fine in modo che i 302 vengano rimossi dopo il completamento. Per le rotte API, verifico se 307/308 funzionano correttamente. Verifico immediatamente ogni correzione con un nuovo Richiesta.
Prestazioni mobili e dati vitali del web
Sullo smartphone, ulteriori Viaggi di andata e ritorno particolarmente evidente. Ogni salto ritarda l'LCP e sposta la stabilità visiva. Pertanto, mantengo tutte le rotte critiche senza reindirizzamento e consegno direttamente le risorse importanti. Se necessario, utilizzo la preconnessione al dominio di destinazione e riduco i tempi del DNS. Per gli utenti che ritornano, HSTS impedisce il salto di protocollo nelle chiamate future.
Evito i reindirizzamenti a risorse che vengono utilizzate above the fold. Immagini e CSS dovrebbero essere accessibili senza nuovi percorsi. Imposto con parsimonia i parametri ai file statici, perché altrimenti le cache dei bordi sono meno accurate. Per gli utenti mobili, è utile un TTL stretto sui test 302, in modo che le modifiche abbiano effetto rapidamente. In questo modo il tempo di caricamento e l'interazione rimangono evidenti liquido.
E-commerce: filtri, parametri e campagne
I negozi si affidano a molti Parametri ma ogni reindirizzamento impostato in modo errato comporta un costo per le entrate. Aggiorno le categorie con 301, in modo che i segnali arrivino, mentre le azioni temporanee passano per 302. Non inoltro alla cieca le pagine di filtro, altrimenti gli utenti perdono il loro contesto. Per i parametri UTM, verifico se il tracciamento funziona senza creare anelli di reindirizzamento. Disattivo i percorsi stagionali alla fine e reindirizzo alle pagine di destinazione legate all'argomento.
Definisco regole chiare: Prodotto eliminato, prodotto sostituito, prodotto definitivamente esaurito. Ognuna di queste situazioni richiede un reindirizzamento diverso. Uso i canonici e il noindex quando le varianti non devono essere classificate. Testiamo in anticipo gli URL di forte sconto con una sessione reale, in modo che i percorsi dei moduli vengano mantenuti. Quindi il UX coerente e l'attrito di conversione basso.
Errori comuni e soluzioni rapide
Un errore comune è rappresentato dalla duplicazione delle regole per il protocollo e l'host, che insieme formano un Catena forma. Combino entrambi in un redirect e risparmio un salto. Un secondo classico: 302 per gli spostamenti permanenti, che ritardano l'indicizzazione. In questo caso passo a 301 e mantengo il percorso attivo per molto tempo. In terzo luogo, i loop di redirect bloccano l'accesso, di solito a causa di eccezioni mancanti: correggo specificamente questa condizione.
Gli aggiornamenti mancanti dei link interni causano carico e costi. Correggo immediatamente la navigazione, i footer, le sitemap e i teaser più popolari. Non utilizzo salti lato client tramite JavaScript o meta refresh perché sono più lenti e non sicuri per i bot. Interrompo i reindirizzamenti delle risorse direttamente alla fonte e correggo i riferimenti in HTML e CSS. In questo modo si eliminano gli inutili Ostacoli e il tempo di visualizzazione diminuisce.
Architettura e priorità delle regole
Organizzo i reindirizzamenti lungo la catena che va dall'utente all'applicazione: DNS/CDN → WAF/load balancer → reverse proxy/web server → applicazione. Posiziono le regole con un'alta percentuale di successo e una bassa complessità il più presto possibile (al CDN/edge) e i singoli casi complessi più vicino all'applicazione. In questo modo si risparmiano i viaggi di andata e ritorno e si mantengono brevi i percorsi decisionali. È importante che ogni livello conosca già l'URL canonico di destinazione - evito regole duplicate o concorrenti tra CDN e Origin attraverso responsabilità e test chiari.
Normalizzo host, protocollo, percorso e minuscole in uno saltare. Tengo conto delle eccezioni (ad esempio, le rotte API, il percorso di upload, l'area di amministrazione) per evitare i loop. Contrassegno chiaramente le regole che valutano i parametri delle query e le proteggo dagli errori di cache (Vary: cookie/user agent solo se assolutamente necessario).
Effetti di HTTP/2, HTTP/3 e TLS
I protocolli influenzano i costi di reindirizzamento. Con HTTP/2, il sito beneficia del multiplexing della connessione, ma un 3xx aggiuntivo rimane comunque un ritardo di andata e ritorno. Con HTTP/3 (QUIC), la ripresa a 0-RTT aiuta con le revisioni, ma un reindirizzamento costa ancora tempo e può rinegoziare la connessione se l'host/porta cambia. Pertanto, assicuro offerte ALPN coerenti (h2, h3) e imposto HSTS, in modo che le chiamate future selezionino direttamente HTTPS. Se opportuno, annuncio HTTP/3 tramite alt-svc, in modo che i clienti passino più rapidamente al protocollo ottimale. Mantengo le catene di certificati snelle e attivo la pinzatura OCSP per ridurre ulteriormente la latenza TLS durante il primo reindirizzamento.
Percorsi linguistici e nazionali senza perdite di SEO
Per l'internazionalizzazione, mi affido a una netta separazione tra riconoscimento e inoltro. Per le visite iniziali, un 302 al percorso localizzato, controllato tramite accept-language o geosegnali e protetto da un cookie in modo che le chiamate successive possano essere effettuate senza ulteriori reindirizzamenti. Rispetto i bot e i deep link non forzando mai un reindirizzamento quando viene chiamato un URL in una lingua specifica. Mantengo coerenti i segnali hreflang e utilizzo una pagina neutra di default senza un salto forzato come ripiego. In questo modo mantengo in equilibrio l'indicizzazione, il controllo dell'utente e le prestazioni.
Stringhe di interrogazione, normalizzazione e alternative di stato
Mi assicuro che l'inoltro Stringhe di query correttamente, soprattutto per i parametri della campagna. In Nginx, lo proteggo con $is_args$args oppure $query_stringa, in Apache con i flag appropriati (l'impostazione predefinita è: mantenere la query, QSD rimosso deliberatamente). Rimuovo deliberatamente i parametri superflui in un unico passaggio, se non hanno più una funzione, per aumentare le percentuali di accesso alla cache. Invece di ricorrere di riflesso a 301, ho impostato anche 410 Andata - questo accorcia i cicli di scansione. Indirizzo i contenuti inesistenti ma correlati verso alternative forti. Evito in particolare i soft 404 (301 → pagina irrilevante) perché indeboliscono sia l'UX che i segnali.
Mappe di reindirizzamento per migrazioni di grandi dimensioni
Per i rilanci di ampio respiro, lavoro con Mappature, che eseguo in versione e importo automaticamente. Per Nginx uso mappa-blocchi o file di inclusione, per Apache RiscritturaMappa con backend di testo o DB. Ciò consente di mappare migliaia di vecchi percorsi verso nuove destinazioni con prestazioni elevate, senza dover controllare costose regex in ogni richiesta. Creo un controllo di qualità in anticipo: ogni vecchio URL deve avere esattamente una destinazione, la gestione delle query è definita e i conflitti sono esclusi. Uno staging separato convalida la libertà di catena e i codici di stato prima che le regole vengano applicate.
# Nginx: instradamento basato su mappe (esempio)
map $request_uri $redir_target {
/alt/percorso-1 /nuovo/percorso-1;
/alt/percorso-2 /nuovo/percorso-2;
# ...
}
server {
se ($redir_target) {
return 301 $scheme://example.com$redir_target$is_args$args;
}
}
Esempio: inoltro canonico in un solo passaggio
Combino la canonicalizzazione dell'host e del protocollo in modo snello per evitare doppi salti. Risolvo la normalizzazione dei percorsi (barra di separazione, file indice) allo stesso tempo, con eccezioni per i file.
# Nginx
server {
ascolta 80;
ascolta 443 ssl http2;
nome_server www.example.com example.com;
# Una regola canonica host/HTTPS
if ($host != 'example.com') {
return 301 https://example.com$request_uri;
}
se ($scheme != 'https') {
restituire 301 https://example.com$request_uri;
}
# Barra finale per le directory, ma non per i file
se ($request_uri ~ ^(.+[^/])$) {
se ($uri ~ ^.*\.[a-zA-Z0-9]{2,5}$) { }
else { return 301 https://example.com$1/; }
}
}
# Apache
RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^example\.com$ [NC]
RewriteRule ^ https://example.com%{REQUEST_URI} [R=301,L]
# Slash finale solo per l'aspetto di "directory
RewriteCond %{REQUEST_URI} !\.[a-zA-Z0-9]{2,5}$
RewriteCond %{REQUEST_URI} !/$
RewriteRule ^ https://example.com%{REQUEST_URI}/ [R=301,L]
API, webhook e flussi di moduli
I clienti macchina spesso non seguono i reindirizzamenti o perdono metodi/corpi. Per POST/PUT uso 307/308, in modo che il metodo rimanga intatto. Ove possibile, mantengo stabili gli URL di destinazione dei webhook ed evito del tutto i reindirizzamenti. Per la manutenzione, uso 503 con retry-after invece di 302, in modo che i mittenti si reindirizzino correttamente. Documento le aspettative di reindirizzamento per le integrazioni, eseguo test con HEAD e verifico che le intestazioni di autorizzazione nei client persistano nei reindirizzamenti.
Sicurezza: reindirizzamenti aperti e controllo della cache
Prevengo Reindirizzamenti aperti, inserendo rigorosamente i parametri di destinazione in una lista bianca di host/percorsi consentiti. Normalizzo i percorsi relativi sul lato server e scarto i target esterni assoluti se non sono esplicitamente consentiti. Per i reindirizzamenti dinamici e dipendenti dall'utente, riduco al minimo i rischi della cache: non imposto intestazioni di cache a lunga durata e Vary solo per quanto necessario. Per i percorsi sensibili, prevengo l'avvelenamento della cache separando chiaramente i cookie e lo stato di autorizzazione e non facendo dipendere i reindirizzamenti da intestazioni manipolabili.
Lavoratori del servizio, SPA e riscritture
Nelle applicazioni a pagina singola, separo chiaramente le riscritture della navigazione (interne al server, 200) dai reindirizzamenti veri e propri (3xx). Il server dovrebbe consegnare i percorsi /app senza un salto, mentre i vecchi URL pubblici vanno ai nuovi obiettivi semantici tramite 301. Nel service worker, mi assicuro che non vengano memorizzate nella cache risposte di reindirizzamento non intenzionali e controllo i gestori di fetch in modo che le richieste di navigazione non finiscano in loop. Per i documenti critici dal punto di vista SEO, preferisco i 301 lato server ai salti di router lato client, per trasmettere i segnali in modo affidabile.
Configurazione fine: minuscole, codifica e file di indice
Capitalizzazioni incoerenti, doppi slash o umlaut codificati in modo errato costano in termini di prestazioni e creano varianti duplicate. Normalizzo i percorsi (ad esempio i reindirizzamenti in minuscolo), assicuro la corretta codifica UTF-8 nei target e rimuovo le sequenze di slash duplicate in un unico passaggio. Indirizzo i file di indice (index.html, index.php) all'URL della directory e mi assicuro che nei template sia collegata esattamente questa forma canonica. Le risorse con estensioni di file sono escluse da queste regole per evitare salti inutili.
Strategia di rollback e browser “sposati” con 301
Dal momento che il browser 301 spesso persistente nella cache, pianifico un modo per tornare indietro. Nelle fasi di test, inizialmente utilizzo 302/307, passando a 301/308 solo quando viene approvato. Se un 301 errato diventa attivo, lo annullo con una nuova regola più specifica, fornisco l'URL di destinazione corretto senza un ulteriore salto e correggo i link interni. Informo il team e l'assistenza che le cache locali/elenchiHSTS possono essere la causa di un comportamento diverso e attendo che la maggior parte si risolva di nuovo correttamente.
Approfondire la misurazione: Budget e segmentazione
Definisco i budget: massimo un redirect per navigazione, TTFB target sotto X ms, tasso di 3xx sotto Y per cento. Misuro separatamente per tipo di dispositivo, regione e tipo di pagina (homepage, categoria, prodotto, cassa). I test sintetici rivelano catene strutturali, il RUM mostra effetti reali su LCP/INP/FID. Nei log, contrassegno le risposte di reindirizzamento con bucket di latenza e le metto in relazione con lo stato della cache (HIT/MISS/BYPASS). In caso di deviazioni, regolo le sequenze, le eccezioni e le regole dei bordi finché le curve non sono stabili.
Lista di controllo QA prima del go-live
- Tutti i principali URL testati: 200 senza deviazioni o un singolo 301/308 verso l'URL di destinazione finale.
- Nessuna catena A→B→C, nessun mix di regole di protocollo e di host in salti separati.
- Le stringhe e i frammenti di query sono stati trasferiti correttamente, i parametri della campagna sono stati mantenuti.
- API/webhooks/forms: Metodo preservato per i reindirizzamenti (307/308), corpi intatti.
- Regole Edge e Origin senza conflitti, casi di test identici a entrambi i livelli.
- HSTS attivo dopo la terminazione dell'HTTPS, precarica solo quando è completamente pronto.
- Link interni, canonici, sitemap aggiornati; niente più 3xx interni.
- Allarmi di monitoraggio impostati per quota 3xx e TTFB; test da diverse regioni.
Sintesi e passi successivi
Per prima cosa do la priorità alla Selezione del codice appropriato, quindi accorcio tutti i percorsi a un salto esatto. Quindi garantisco il caching: 301 lungo, 302 breve, regole di bordo al bordo della CDN. Allo stesso tempo, pulisco i link interni, le sitemap e i canonical in modo che le richieste arrivino direttamente. Misuro TTFB, quota 3xx e LCP fino a raggiungere valori stabili. Infine, pianifico audit a intervalli regolari per evitare che catene, loop e test temporanei diventino cantieri permanenti.
Questa sequenza mantiene i reindirizzamenti snelli, i segnali di ricerca intatti e le pagine veloci. Ecco come aumentare le prestazioni dei reindirizzamenti HTTP in modo misurabile e permanente. Ogni correzione ha un impatto sull'esperienza dell'utente, sull'efficienza del crawling e sul carico del server. Mantengo le regole il più possibile concise e le verifico con costanza. In questo modo si risparmia tempo, budget e si protegge il Risorse.
