Use o Verificador de Redirecionamentos para seguir uma URL pública através dos seus redirecionamentos HTTP e examinar a resposta obtida no fim. O relatório mostra os endereços observados, os códigos de estado e os destinos dos redirecionamentos. Compare esses dados com o destino pretendido da ligação: uma cadeia concluída pode chegar à página errada, enquanto uma verificação incompleta não confirma um destino final.
Introduza a URL que pretende verificar
Comece pelo endereço que as pessoas realmente utilizam, incluindo o caminho e os parâmetros de consulta relevantes. Verificar apenas a página inicial não mostra o que acontece a uma ligação antiga de produto. Por exemplo, http://example.com/products/old-mug/ ilustra um endereço de origem; substitua-o pela URL pública que pretende investigar.
Antes de enviar a URL, identifique o destino esperado e decida se a mudança deve ser permanente ou temporária. Após uma alteração da URL de um produto, pode ser o mesmo produto no novo endereço. Durante uma interrupção temporária do serviço, o endereço original pode ter de continuar a ser o ponto de entrada a longo prazo.
Introduza uma URL HTTP ou HTTPS completa e inicie a verificação. O Screpy faz um pedido GET e segue os redirecionamentos HTTP suportados. Não descobre todas as variantes do domínio, não utiliza a sua sessão autenticada no navegador e não executa scripts. Para comparar caminhos, protocolos ou nomes de anfitrião diferentes, envie separadamente essas URL de origem.
Leia a cadeia e a resposta final
Leia as linhas de resposta pela ordem apresentada. Cada linha indica a URL solicitada, o estado HTTP e um destino Location quando um redirecionamento suportado o fornece. Os valores Location são apresentados como endereços resolvidos. Se uma resposta apontar para /products/new-mug/, o relatório resolve o caminho relativamente à URL que o enviou; o endereço mostrado pode não coincidir com o texto literal original do cabeçalho.
Esta cadeia ilustrativa contém três respostas e dois redirecionamentos. É um exemplo, não a análise de um site real:
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
Aqui, o primeiro estado é 301, o estado final é 200 e a URL final é o novo endereço do produto. A última linha 200 é uma resposta, não outro redirecionamento. Numa verificação concluída, o número de redirecionamentos descreve as transições entre as respostas observadas. Se a verificação parar antes do fim, interprete esse número juntamente com as linhas conservadas, não como o comprimento total da cadeia.
Interprete a cor do resultado com esses detalhes:
- Verde: uma resposta bem-sucedida direta, sem redirecionamentos seguidos. É útil quando a URL já deve ser o destino.
- Amarelo: um redirecionamento, mesmo que termine com uma resposta bem-sucedida, ou outra resposta que precisa de revisão. Um redirecionamento amarelo não é automaticamente uma ligação quebrada.
- Vermelho: um erro HTTP final, como 404 ou 500. Leia o destino e o código antes de decidir o que corrigir.
- Cinzento: não foi possível determinar uma resposta final. As linhas conservadas são evidência parcial.
Estas cores descrevem categorias de resposta. Não avaliam o conteúdo, não provam a indexação e não determinam se o redirecionamento corresponde à sua intenção.
Compreenda os códigos 301, 302, 303, 307 e 308
Escolha o comportamento pretendido antes do estado. Estes são os cinco códigos de redirecionamento que o verificador segue:
| Código | Significado HTTP | O que rever |
|---|---|---|
| 301 | Mudança permanente | As futuras ligações devem utilizar o novo endereço? |
| 302 | Mudança temporária | O endereço original deve continuar a ser utilizado? |
| 303 | Consultar outro recurso para obter a resposta | É um recurso seguinte deliberado, em vez de uma substituição permanente? |
| 307 | Redirecionamento temporário que preserva o método do pedido | Pretende-se um redirecionamento temporário sem alterar o método? |
| 308 | Redirecionamento permanente que preserva o método do pedido | Pretende-se uma mudança permanente sem alterar o método? |
As diferenças seguem a semântica dos redirecionamentos HTTP do RFC 9110. Uma verificação apenas com GET não confirma o que acontece a um pedido POST enviado ou ao seu corpo. Ver aqui 307 ou 308 não testa o processo de envio de um formulário.
As orientações do Google sobre redirecionamentos recomendam redirecionamentos permanentes no servidor para alterações permanentes de URL. O Google utiliza-os como sinal a favor do destino enquanto URL canónica; os temporários têm outra finalidade. Isso não transforma todos os 302 em erros de SEO nem garante que um 301 altere imediatamente os resultados de pesquisa.
Se uma mudança permanente devolver inesperadamente um código temporário, examine a regra responsável. Num desvio temporário intencional, não altere o estado apenas para obter um resultado com melhor aparência.
Confirme que o destino é a página certa
Uma cadeia concluída indica onde terminou este pedido. Não estabelece que a página seja uma substituição adequada. O verificador lê estados e destinos de redirecionamento sem examinar o conteúdo da página final.
Compare a URL final com o destino identificado antes da verificação. Examine o nome de anfitrião, o caminho e os parâmetros relevantes. Uma ligação antiga de produto que termina na página inicial com 200 pode continuar a não satisfazer o visitante. Abra o destino e decida se contém o produto, artigo ou outra substituição relevante. Se não existir uma alternativa adequada, não a invente apenas para eliminar um erro do relatório.
Examine também um aviso de passagem de HTTPS para HTTP. Decida se a regra aponta para o endereço seguro pretendido e corrija uma passagem involuntária. O aviso descreve essa transição; não é uma auditoria de segurança do destino.
Para uma página que deve aparecer na pesquisa, use separadamente o Verificador de Tags Canonical para examinar a URL preferida declarada. Um redirecionamento bem-sucedido não confirma a declaração canonical, a ausência de noindex ou a decisão de indexação do Google. Uma cadeia HTTP correta e uma declaração correta na página são observações distintas.
Diagnostique uma cadeia incompleta
Quando a URL ou o estado final não estiver disponível, comece pela última resposta realmente registada. Um valor Location indica para onde essa resposta pretendia enviar o pedido. Não prova que o endereço seguinte tenha sido alcançado ou devolvido uma resposta bem-sucedida. Um resultado indisponível também difere de um erro HTTP observado: um tempo esgotado não tem código final confirmado, enquanto uma resposta recebida pode devolver explicitamente 404 ou 403.
Use as linhas conservadas para limitar a investigação:
- Endereços repetidos: a sequência ilustrativa
A → B → Aé um ciclo. Examine as regras que devolvem o pedido a uma URL já visitada, como regras de anfitrião ou caminho em conflito. - Sequência longa sem repetição: o verificador segue no máximo cinco redirecionamentos. Atingir esse limite não estabelece um ciclo nem revela o resto da cadeia. Examine separadamente o último destino registado.
- Estado de redirecionamento sem destino utilizável: confirme que a resposta fornece um Location válido. Um destino ausente ou inválido não pode ser tratado como uma mudança concluída.
- Sem resposta seguinte: problemas de acesso público, resolução de nomes, ligação ou ligação segura podem impedir a verificação. A cadeia completa dispõe de oito segundos, não de oito por passo. Os limites dos cabeçalhos e os destinos privados ou não suportados também podem interrompê-la.
Se o destino devolver uma restrição de acesso ou um limite de pedidos, investigue essa condição antes de assumir que o conteúdo foi eliminado. Este pedido pode receber uma resposta diferente da do seu navegador autenticado. Redirecionamentos JavaScript, meta refresh e comportamento do navegador ficam fora do âmbito; um resultado HTTP não explica toda a navegação visível no ecrã.
Corrija a causa e verifique novamente a mesma URL
Descarregue o relatório JSON antes de alterar uma regra. Guarde com ele a URL enviada e o destino previsto, para que quem faz a correção distinga o comportamento observado do pretendido. Esta ferramenta exporta JSON; não fornece CSV filtrado nem altera os redirecionamentos por si.
- Encontre a resposta em que o endereço ou o estado se afasta pela primeira vez da sua intenção. Localize a configuração que produz essa resposta, em vez de alterar metadados não relacionados.
- Corrija um destino, estado, ciclo ou passagem para HTTP não pretendido. Remova passos intermédios desnecessários onde controla as regras e mantenha o encaminhamento ou acompanhamento com uma finalidade deliberada. Aponte ligações internas diretamente para o destino previsto quando isso ajudar o visitante.
- Verifique exatamente a mesma URL de origem quando a resposta pública corrigida estiver disponível. Compare a sequência, os códigos inicial e final, o endereço final e os dados ainda indisponíveis com o relatório guardado.
- Verifique separadamente variantes relevantes, como um caminho antigo ou outro nome de anfitrião. Corrigir um endereço não confirma todas as correspondências de uma migração.
Use o Verificador HTTP em Lote quando tiver uma lista. Aceita até 50 URL e suporta exportação CSV filtrada. Reserve esta ferramenta para ler uma cadeia em detalhe. Uma nova verificação bem-sucedida confirma a resposta observada agora; não prova que um visitante, navegador ou robô de pesquisa futuro receba o mesmo comportamento.