Controllo Reindirizzamenti

Usa il Controllo Reindirizzamenti per seguire un URL pubblico attraverso i suoi reindirizzamenti HTTP e ispezionare la risposta raggiunta alla fine. Il rapporto mostra gli indirizzi osservati, i codici di stato e le destinazioni dei reindirizzamenti. Confronta questi dati con il punto a cui dovrebbe portare il link: una catena completata può comunque raggiungere la pagina sbagliata, mentre un controllo incompleto non conferma una destinazione finale.

Inserisci l'URL da controllare

Parti dall'indirizzo effettivamente usato dalle persone, includendo il percorso e i parametri di query rilevanti. Controllare solo la homepage non chiarisce cosa succede a un vecchio link di prodotto. Per esempio, http://example.com/products/old-mug/ è un indirizzo di partenza illustrativo; sostituiscilo con l'URL pubblico che vuoi esaminare.

Prima di inviarlo, identifica la destinazione attesa e decidi se lo spostamento deve essere permanente o temporaneo. Dopo un cambio di URL di prodotto, potrebbe essere lo stesso prodotto al nuovo indirizzo. Durante un'interruzione temporanea del servizio, l'indirizzo originale potrebbe dover rimanere il punto di accesso a lungo termine.

Inserisci un URL HTTP o HTTPS completo e avvia il controllo. Screpy effettua una richiesta GET e segue i reindirizzamenti HTTP supportati. Non scopre tutte le varianti del dominio, non usa la tua sessione autenticata del browser e non esegue script. Per confrontare percorsi, protocolli o nomi host diversi, invia separatamente gli URL di partenza.

Leggi la catena e la risposta finale

Leggi le righe delle risposte nell'ordine mostrato. Ogni riga indica l'URL richiesto, lo stato HTTP e una destinazione Location quando un reindirizzamento supportato la fornisce. I valori Location sono mostrati come indirizzi risolti. Se una risposta indica /products/new-mug/, il rapporto risolve il percorso rispetto all'URL che lo ha inviato; l'indirizzo visualizzato può quindi differire dal testo letterale originale dell'header.

Questa catena illustrativa contiene tre risposte e due reindirizzamenti. È un esempio, non la scansione di un sito reale:

http://example.com/products/old-mug/       301 → https://example.com/products/old-mug/
https://example.com/products/old-mug/      301 → https://example.com/products/new-mug/
https://example.com/products/new-mug/      200

Qui il primo stato è 301, quello finale è 200 e l'URL finale è il nuovo indirizzo del prodotto. L'ultima riga 200 è una risposta, non un ulteriore reindirizzamento. In un controllo completato, il numero di reindirizzamenti descrive le transizioni tra le risposte osservate. Se il controllo si interrompe prima, interpreta il numero insieme alle righe conservate, non come lunghezza totale della catena.

Interpreta il colore del risultato insieme a questi dettagli:

• Verde: una risposta riuscita diretta, senza reindirizzamenti seguiti. È utile quando l'URL dovrebbe già essere la destinazione.
• Giallo: un reindirizzamento, anche se termina con una risposta riuscita, o un'altra risposta da esaminare. Un reindirizzamento giallo non è automaticamente un link interrotto.
• Rosso: un errore HTTP finale, come 404 o 500. Leggi destinazione e codice prima di decidere cosa correggere.
• Grigio: il controllo non ha potuto stabilire una risposta finale. Le righe conservate sono evidenze parziali.

I colori descrivono categorie di risposta. Non valutano il contenuto, non provano l'indicizzazione e non stabiliscono se il reindirizzamento corrisponda alle tue intenzioni.

Comprendi i codici 301, 302, 303, 307 e 308

Scegli il comportamento desiderato prima dello stato. Questi sono i cinque codici di reindirizzamento seguiti dal controllo:

Le differenze seguono la semantica dei reindirizzamenti HTTP di RFC 9110. Un controllo basato solo su GET non verifica cosa accade a una richiesta POST inviata o al suo corpo. Vedere qui 307 o 308 non testa il flusso di invio di un modulo.

La guida di Google sui reindirizzamenti raccomanda reindirizzamenti permanenti lato server per cambiamenti permanenti degli URL. Google li usa come segnale a favore della destinazione come URL canonico; quelli temporanei hanno uno scopo diverso. Questo non rende ogni 302 un errore SEO e non garantisce che un 301 modifichi immediatamente i risultati di ricerca.

Se uno spostamento permanente restituisce inaspettatamente un codice temporaneo, esamina la regola che lo produce. Per una deviazione temporanea intenzionale, non cambiare lo stato solo per ottenere un risultato apparentemente migliore.

Verifica che la destinazione sia la pagina giusta

Una catena completata indica dove è terminata questa richiesta. Non stabilisce che la pagina sia una sostituzione adatta. Il controllo legge stati e destinazioni senza analizzare il contenuto della pagina finale.

Confronta l'URL finale con la destinazione identificata prima del controllo. Esamina nome host, percorso e parametri rilevanti. Un vecchio link di prodotto che termina sulla homepage con 200 può comunque non soddisfare il visitatore. Apri la destinazione e valuta se contiene il prodotto, l'articolo o un'altra sostituzione pertinente. Se non esiste un'alternativa adatta, non inventarla solo per eliminare un errore dal rapporto.

Esamina anche un avviso di passaggio da HTTPS a HTTP. Valuta se la regola punta all'indirizzo sicuro previsto e correggi un passaggio involontario. L'avviso descrive quella transizione; non è un audit di sicurezza della destinazione.

Per una pagina che deve comparire nelle ricerche, usa separatamente il Controllo Tag Canonical per ispezionare l'URL preferito dichiarato. Un reindirizzamento riuscito non conferma la dichiarazione canonical, l'assenza di noindex o la decisione di indicizzazione di Google. Una catena HTTP corretta e una dichiarazione corretta nella pagina sono osservazioni diverse.

Diagnostica una catena incompleta

Quando l'URL o lo stato finale non è disponibile, parti dall'ultima risposta effettivamente registrata. Un valore Location indica dove quella risposta voleva inviare la richiesta. Non prova che l'indirizzo successivo sia stato raggiunto o abbia restituito una risposta riuscita. Un risultato non disponibile è diverso anche da un errore HTTP osservato: un timeout non ha un codice finale confermato, mentre una risposta ricevuta può restituire esplicitamente 404 o 403.

Usa le righe conservate per restringere l'indagine:

• Indirizzi ripetuti: la sequenza illustrativa A → B → A è un ciclo. Esamina le regole che riportano la richiesta a un URL già visitato, come regole di host o percorso in conflitto.
• Sequenza lunga senza ripetizioni: il controllo segue al massimo cinque reindirizzamenti. Raggiungere questo limite non dimostra un ciclo e non rivela il resto della catena. Esamina separatamente l'ultima destinazione registrata.
• Stato di reindirizzamento senza destinazione utilizzabile: verifica che la risposta fornisca un Location valido. Una destinazione mancante o non valida non può essere trattata come uno spostamento completato.
• Nessuna risposta successiva: problemi di accesso pubblico, risoluzione dei nomi, connessione o connessione sicura possono impedire il controllo. L'intera catena ha otto secondi, non otto per ogni passaggio. Anche i limiti degli header e le destinazioni private o non supportate possono interromperla.

Se la destinazione restituisce una restrizione di accesso o un limite di richieste, esamina la condizione prima di presumere che il contenuto sia stato eliminato. Questa richiesta può ricevere una risposta diversa dal tuo browser autenticato. I reindirizzamenti JavaScript, meta refresh e il comportamento del browser sono esclusi, quindi il risultato HTTP non spiega ogni navigazione che vedi sullo schermo.

Correggi la causa e ricontrolla lo stesso URL

Scarica il rapporto JSON prima di cambiare una regola. Conserva con esso l'URL inviato e la destinazione prevista, così chi corregge può distinguere il comportamento osservato da quello desiderato. Lo strumento esporta il rapporto in JSON; non offre CSV filtrati e non modifica i reindirizzamenti al tuo posto.

1. Trova la risposta in cui l'indirizzo o lo stato si discosta per la prima volta dalla tua intenzione. Individua l'impostazione che produce la risposta, invece di modificare metadati non pertinenti.
2. Correggi una destinazione, uno stato, un ciclo o un passaggio a HTTP non voluto. Elimina passaggi intermedi inutili dove controlli le regole, mantenendo instradamento o tracciamento con uno scopo preciso. Punta i link interni direttamente alla destinazione prevista quando è utile al visitatore.
3. Esegui di nuovo lo stesso identico URL di partenza quando la risposta pubblica corretta è disponibile. Confronta sequenza, codici iniziale e finale, indirizzo finale e informazioni ancora non disponibili con il rapporto salvato.
4. Controlla separatamente le varianti rilevanti, come un vecchio percorso o un altro nome host. Riparare un indirizzo non conferma tutte le corrispondenze di una migrazione.

Usa il Controllo HTTP in Blocco quando hai un elenco. Accetta fino a 50 URL e supporta l'esportazione CSV filtrata. Mantieni questo controllo per leggere una singola catena nel dettaglio. Un nuovo controllo riuscito verifica la risposta osservata adesso; non prova che un futuro visitatore, browser o crawler riceva lo stesso comportamento.