Um verificador de cabeçalhos HTTP mostra os metadados devolvidos por um servidor para um URL. A Screpy faz um pedido GET público, segue os redirecionamentos suportados e lista os nomes e valores dos cabeçalhos da resposta final sem descarregar o corpo da página. Utilize o relatório para investigar um redirecionamento, confirmar uma alteração após a publicação ou encontrar uma instrução de indexação inesperada.
Comece pela resposta recebida e compare-a com o comportamento pretendido para esse recurso. Uma verificação concluída pode revelar um erro do servidor ou uma política inadequada. Um resultado verde não certifica segurança, desempenho da cache ou indexação nos motores de pesquisa.
Verifique o URL exato e a cadeia de respostas
Introduza um endereço HTTP ou HTTPS público completo, com o caminho e os parâmetros relevantes. A página inicial, um PDF e uma página de produto podem devolver cabeçalhos diferentes no mesmo domínio. Para uma página de produto fictícia, https://example.com/products/blue-mug/ é mais útil do que a raiz se pretender analisar precisamente essa resposta.
Leia a cadeia antes da tabela. Um redirecionamento pode alterar o protocolo, o anfitrião ou o caminho. A tabela contém os cabeçalhos da resposta final, não todos os cabeçalhos de cada passo. A cadeia inclui também a resposta final, pelo que o número de passos pode não coincidir com o número de redirecionamentos.
Confirme que o URL final é o recurso pretendido. Uma página de autenticação, de erro ou outro anfitrião podem explicar valores inesperados. Utilize o Redirect Checker quando precisar de analisar sobretudo o percurso dos redirecionamentos, em vez da lista final de cabeçalhos.
Leia um exemplo de resposta HTTP
Esta resposta fictícia mostra como campos diferentes respondem a perguntas diferentes. Não é um resultado capturado nem uma configuração para copiar para todas as páginas.
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Cache-Control: no-cache
X-Robots-Tag: noindex
O estado 200 indica uma resposta bem-sucedida. Content-Type declara HTML com codificação UTF-8. Cache-Control descreve instruções de cache, enquanto X-Robots-Tag fornece uma instrução de indexação. Uma resposta funcional pode, portanto, incluir noindex: sucesso HTTP não significa que a página se destina aos resultados de pesquisa.
A tabela normaliza os nomes para minúsculas; a capitalização não cria campos diferentes. A referência de cabeçalhos da MDN distingue campos de pedido e de resposta. Este verificador mostra a resposta, não os cookies, preferências ou dados de autenticação da sua sessão no navegador.
Reveja a cache e a indexação como decisões separadas
Filtre a tabela pelo nome do cabeçalho ao investigar um problema específico. Primeiro, defina as necessidades do recurso: HTML atualizado frequentemente, um ficheiro com versão e um documento deliberadamente excluído da pesquisa não precisam necessariamente da mesma política.
| Cabeçalho | Pergunta útil para a revisão |
|---|---|
content-type |
O formato declarado corresponde ao recurso esperado ou um redirecionamento chegou a outra resposta? |
cache-control |
A política corresponde às necessidades de atualização e privacidade do recurso? |
etag ou last-modified |
Existe um validador para pedidos condicionais? A presença não testa a revalidação. |
vary |
Que diferenças nos cabeçalhos do pedido identifica a resposta para selecionar a cache? |
x-robots-tag |
A instrução noindex observada é intencional para este URL? |
no-cache não significa «nunca armazenar». Permite armazenamento, mas exige validação antes da reutilização. no-store indica às caches que não guardem a resposta. A referência Cache-Control da MDN explica a diferença. Esta verificação não mede respostas servidas pela cache nem elimina cópias já guardadas.
Uma instrução de indexação é uma decisão distinta da atualidade do conteúdo. Se uma página destinada à indexação devolver noindex inesperadamente, encontre a aplicação, definição do servidor ou regra responsável antes de a alterar. Utilize o Noindex Checker para analisar também as diretivas HTML. A documentação noindex da Google descreve a instrução; observá-la não determina o estado atual no índice da Google.
Compreenda as observações sobre cabeçalhos de segurança
A Screpy destaca certas declarações para revisão. Trate uma observação como uma questão de configuração, não como um relatório de vulnerabilidades ou uma recomendação para copiar uma política desconhecida para produção.
| Observação | O que a verificação estabelece e o que não estabelece |
|---|---|
| Revisão HSTS | Procura um max-age positivo numa resposta HTTPS. Não valida toda a implementação HTTPS nem os certificados. |
| CSP em falta | Procura Content-Security-Policy numa resposta declarada como HTML. A presença não garante que as diretivas protejam a aplicação. |
| Revisão de incorporação | Procura frame-ancestors na CSP ou um valor reconhecido de X-Frame-Options. Permitir incorporação depende da função da página. |
| Revisão de deteção MIME | Verifica se X-Content-Type-Options declara nosniff. Não verifica o conteúdo real do ficheiro nem o comportamento de todos os navegadores. |
Uma informação ou a ausência de uma política não prova uma vulnerabilidade. A presença de um cabeçalho também não torna uma política eficaz. A documentação CSP da MDN distingue políticas aplicadas de Content-Security-Policy-Report-Only, que comunica violações sem impor essas restrições. Ver este último não demonstra que exista uma política que as imponha.
Avalie as alterações segundo as necessidades reais de recursos e incorporação da aplicação. O verificador não atribui uma classificação de segurança, não inspeciona certificados e não valida todas as diretivas. Para referências a recursos inseguros no HTML, utilize separadamente o Mixed Content Checker.
Interprete valores repetidos e ocultos
A contagem de cabeçalhos corresponde a nomes normalizados distintos. A coluna de ocorrências mostra quantas vezes apareceu cada nome, mantendo visíveis os valores normais repetidos. Mais de uma ocorrência não é automaticamente um erro: verifique se o campo permite essa estrutura e se a política combinada é intencional.
Os valores sensíveis de cookies, autenticação e segredos reconhecidos são ocultados ou limpos. Um valor oculto não é um cabeçalho ausente, e a sua presença não avalia a segurança dos cookies. Não volte a introduzir esses valores num relatório partilhado. Reveja os detalhes confidenciais apenas num ambiente privado de diagnóstico adequado.
Filtre pelo nome, como cache-control, sem esperar uma pesquisa em todos os valores. Guarde o relatório com o URL e a hora verificados ao comparar respostas. Interprete um campo presente ou ausente com o estado final, o tipo de recurso e o aviso de cobertura.
Distinga verificações parciais de erros HTTP
Uma resposta de erro do servidor é diferente de não conseguir chegar ao servidor. Leia a mensagem de cobertura antes de interpretar linhas ausentes.
| Resultado | Significado e próximo passo |
|---|---|
404 ou 500 final com cabeçalhos |
Foi observada uma resposta. Confirme o URL e investigue o erro do recurso ou servidor; uma ligação bem-sucedida não significa uma página funcional. |
| Cadeia parcial | Alguns passos foram observados, mas a resposta final não pôde ser verificada. Os cabeçalhos finais estão indisponíveis, não comprovadamente ausentes. |
| Tempo esgotado ou fonte indisponível | A resposta pedida não foi obtida. Verifique acesso público, endereço e redirecionamentos antes de repetir. |
O verificador segue um número limitado de redirecionamentos e espera durante um tempo limitado. Ciclos, destinos inacessíveis ou respostas que ultrapassem os limites suportados podem deixar a verificação incompleta. Nessa situação, uma lista final vazia não é uma lista de cabeçalhos de segurança em falta.
Endereços de rede privada, páginas autenticadas e pedidos que precisam dos cookies do seu navegador estão fora do âmbito deste formulário. Uma restrição de acesso também não demonstra o que recebe o Googlebot ou outro visitante real.
Compare os cabeçalhos após uma publicação
Antes de alterar algo, registe o URL exato, a resposta final, a hora da verificação e o campo que deverá mudar. Exporte o relatório como referência. Após publicar a configuração pretendida, verifique o mesmo URL e compare os valores relevantes, não apenas o número de cabeçalhos ou avisos. Repita com outro tipo de recurso se a regra também se deva aplicar aí.
Se o navegador mostrar algo diferente, abra o painel Rede, recarregue a página e examine o pedido relevante. Compare o URL após redirecionamentos, o método e o estado de autenticação. Uma resposta personalizada ou em cache pode diferir de um pedido público feito noutra localização. Este formulário não envia os seus cookies nem permite adicionar cabeçalhos de autenticação próprios.
Verifique também se outra ferramenta utilizou HEAD em vez de GET. A RFC 9110 explica que HEAD não contém corpo e pode omitir campos determinados durante a geração do conteúdo. A Screpy utiliza GET, mas para antes de descarregar o corpo. Alinhar o método e as condições ajuda a investigar diferenças; não torna todas as respostas do servidor iguais.