Verificador de Status HTTP
Diagnostique um deploy quebrado, uma regra de CDN errada ou um pico de erros 5xx. Envie uma requisição HTTP real contra qualquer URL e veja o status bruto, todos os cabeçalhos de resposta e a cadeia completa de redirects — exatamente como o Googlebot enxerga.
Por que verificar os Status HTTP?
Entender como seu servidor responde às requisições é crucial para SEO e experiência do usuário. Erros de configuração em redirecionamentos ou códigos de erro inesperados impedem que usuários e robôs de busca acessem seu site.
Códigos de Status Comuns:
- 200 OK: A requisição foi bem-sucedida.
- 301 Moved Permanently: A URL foi movida permanentemente para um novo local.
- 404 Not Found: O servidor não encontrou o recurso solicitado.
- 500 Internal Server Error: O servidor encontrou uma condição inesperada.
Como interpretar os resultados
A ferramenta mostra três coisas: o status HTTP final, cada cabeçalho de resposta agrupado por finalidade, e a cadeia completa de redirects com tempos. Leia juntos — um 200 isolado raramente conta a história toda.
- 200 OK com
cache-control: public, max-age=0— tecnicamente sucesso, mas CDNs não vão cachear. Tudo bem para páginas logadas, ruim para uma landing estática. - 301 → 301 → 200 — o destino responde, mas cada hop extra adiciona latência e consome budget de crawl. Colapse cadeias em um único redirect.
- 302 onde você esperava 301 — buscadores tratam 302 como temporário e podem manter a URL antiga indexada por meses. Troque para 301 assim que a movimentação for permanente.
- 404 Not Found — o servidor respondeu, mas o recurso não existe. Compare com uma URL funcional: é erro de digitação, slug faltando ou rota quebrada?
- 403 Forbidden — requisição rejeitada. Causas típicas: listagem de diretório desabilitada, desafio de WAF, regra de firewall por IP.
- 429 Too Many Requests — rate limit atingido. Veja o
retry-aftere recue. - 502 / 503 / 504 — a borda (CDN, load balancer, reverse proxy) não conseguiu alcançar uma origem saudável. Olhe a origem antes de culpar a borda.
- Timeout sem status — DNS resolveu mas o servidor não enviou bytes. Firewall, porta errada ou origem caída.
Problemas comuns e como resolver
Loop de redirect ao forçar HTTPS
Sintoma clássico: o proxy termina o TLS e encaminha HTTP puro para a aplicação, que vê http e redireciona de volta para https. Solução: confie em X-Forwarded-Proto na aplicação (Express app.set('trust proxy', 1), Rails config.force_ssl com checagem de proxy, Django SECURE_PROXY_SSL_HEADER).
200 misto entre www e apex
Tanto seudominio.com quanto www.seudominio.com respondem 200. O Google vai escolher um e pode dividir o link equity. Escolha um host canônico e redirecione o outro com 301 na borda.
Cabeçalhos de segurança sumiram após troca de CDN
Headers customizados às vezes são removidos pela CDN se não forem explicitamente encaminhados. Reaplique Strict-Transport-Security, Content-Security-Policy e X-Content-Type-Options na camada de CDN, não só na origem.
3xx inesperado em endpoint POST
301/302 legados podem silenciosamente reescrever POST para GET e descartar o corpo. Se não puder remover o redirect, use 307 ou 308 para preservar método e payload.
CORS parece quebrado mas requisição retorna 200
Erros de CORS aparecem no console do navegador, não no status. Confira o Access-Control-Allow-Origin e garanta que o preflight OPTIONS retorne os cabeçalhos esperados.
Próximos passos
Depois que a resposta parece correta em uma checagem pontual, a próxima pergunta é: vai continuar correta às 3h de um sábado? Status, cadeias de redirect e headers desviam silenciosamente — uma mudança de regra na CDN, uma rotação de certificado ou um deploy novo podem virar 200 em 500 sem que ninguém perceba até o tráfego cair.
- Rode esta checagem após cada deploy como parte do release checklist.
- Configure alertas específicos para os cabeçalhos que importam (HSTS, CSP) — não apenas para o status code.
- Para páginas de alto tráfego, configure monitoramento contínuo no FlashMon.app para que o próximo 5xx gere uma notificação antes dos tweets dos usuários.
Monitore seus códigos de status automaticamente
Seja o primeiro a saber quando seu site começar a retornar erros 404 ou 500.
Perguntas Frequentes
Códigos de status HTTP são números de três dígitos que servidores retornam para descrever o resultado de uma requisição. São agrupados em cinco classes: 1xx (informacional), 2xx (sucesso), 3xx (redirecionamento), 4xx (erros do cliente) e 5xx (erros do servidor). Os mais comuns são 200 OK (sucesso), 301 Moved Permanently (redirect permanente), 404 Not Found (página não encontrada) e 500 Internal Server Error (falha no servidor). Entendê-los é essencial para depurar aplicações web e otimizar o SEO.
Um redirect 301 é permanente — informa buscadores e navegadores que a página se moveu para sempre, transferindo a autoridade de SEO (link equity) acumulada para a nova URL. Um redirect 302 é temporário — os buscadores continuam indexando a URL original pois o movimento não é definitivo. Usar 302 quando se quer 301 é um erro de SEO comum que dilui o valor de ranqueamento ao longo do tempo. Sempre use 301 em migrações de domínio, reestruturação de URLs e movimentos permanentes de conteúdo.
Cabeçalhos de resposta HTTP são pares chave-valor enviados junto com a resposta do servidor, fornecendo metadados sobre o conteúdo e a conexão. Controlam comportamento de cache (Cache-Control, ETag), políticas de segurança (Content-Security-Policy, HSTS), tipo de conteúdo (Content-Type) e identidade do servidor. Headers como Strict-Transport-Security forçam conexões HTTPS, enquanto X-Frame-Options previnem ataques de clickjacking. Inspecioná-los é essencial para auditorias de segurança e diagnóstico de performance.
Um loop de redirect ocorre quando a página A redireciona para a página B, que redireciona de volta para A (ou por uma cadeia circular mais longa). Navegadores detectam isso após alguns hops e exibem o erro "Too many redirects", tornando a página completamente inacessível. Crawlers de buscadores também abandonam URLs presas em loops, impedindo a indexação. Isso pode fazer páginas desaparecerem dos resultados de busca. O verificador HTTP do FlashMon detecta loops imediatamente, exibindo toda a cadeia.
Os cabeçalhos de segurança mais importantes são: Strict-Transport-Security (impõe HTTPS), Content-Security-Policy (previne XSS), X-Frame-Options (bloqueia clickjacking), X-Content-Type-Options (previne MIME sniffing), Referrer-Policy (controla vazamento de informações do referrer) e Permissions-Policy (restringe acesso às APIs do navegador). A ausência desses cabeçalhos deixa o site vulnerável a ataques comuns. O Verificador HTTP do FlashMon audita todos eles, mostrando o que está presente e o que está faltando.
Verificações manuais funcionam para auditorias pontuais, mas sites em produção precisam de monitoramento contínuo. Cabeçalhos e configurações de redirect podem mudar inesperadamente devido a atualizações de servidor, mudanças de CDN ou novos deploys. O FlashMon monitora seus cabeçalhos HTTP e cadeias de redirect continuamente, alertando imediatamente quando um header de segurança desaparece, um redirect inesperado surge ou seu servidor começa a retornar erros — antes que usuários ou buscadores sejam afetados.
Clientes diferentes parecem diferentes para o servidor. Navegadores enviam User-Agent, aceitam cookies, negociam TLS e chegam frequentemente com referrer. Uma probe HTTP simples não faz isso. WAFs (Cloudflare, AWS WAF, Akamai) costumam desafiar tráfego não-navegador com 403 Forbidden, 503 Service Unavailable ou uma página de desafio JavaScript. Se isso acontece, geralmente significa que seu site está protegido — não quebrado — mas checagens automáticas de uptime, crawlers de SEO e o Googlebot também podem ser afetados. Libere IPs de monitoramento conhecidos ou relaxe as regras de desafio bot para /robots.txt e /sitemap.xml.
Ambos são redirects permanentes, mas o 301 era historicamente ambíguo sobre preservação do método: muitos clientes silenciosamente convertiam um POST em GET. O 308 foi criado para proibir explicitamente esse comportamento — método e corpo devem ser preservados. Para link equity em páginas GET, o Google trata os dois de forma equivalente. Use 301 para movimentações canônicas de páginas (o padrão seguro que todo crawler entende) e 308 quando redireciona endpoints de API ou destinos de formulário e não pode sofrer conversão silenciosa de método.
O Google classifica como Soft 404 quando o status HTTP é 200 mas o conteúdo parece uma página de erro — conteúdo raso, mensagem "item não encontrado", redirect para a home em vez de um 404 real, ou página de produto cujo registro sumiu do banco. A solução é retornar 404 real (ou 410 Gone se o conteúdo foi permanentemente removido) quando o recurso não existe. Veja o relatório de Cobertura no Search Console para identificar as URLs afetadas e verifique o status com esta ferramenta.