O Bulk HTTP Status Checker da Screpy verifica uma lista de até 50 URLs e mostra a primeira resposta, a resposta final e as etapas de redirecionamento observadas. Use-o após uma migração, para investigar páginas inacessíveis ou preparar reparos. O resultado descreve uma requisição GET pública no horário indicado, não disponibilidade contínua, velocidade de carregamento no navegador ou indexação confirmada.
Escolha uma lista de URLs com propósito claro
Cole um endereço HTTP ou HTTPS público e completo por linha. Comece com uma pergunta: os links antigos de campanhas chegam aos substitutos ou a navegação ainda retorna erros? Ao conferir redirecionamentos, inclua os endereços originais. Verificar somente os destinos finais não mostra o comportamento do link antigo.
O limite é de 50 linhas enviadas não vazias. Linhas em branco são ignoradas e URLs repetidas após normalização são verificadas uma vez. Remova duplicatas antes de enviar se elas ultrapassarem o limite. Corrija as linhas inválidas. A ferramenta não descobre páginas do site nem importa automaticamente um sitemap.
Uma amostra útil inclui uma página inalterada, uma transferida e conteúdo removido intencionalmente. Anote o resultado esperado antes da verificação. Um 404 pode estar correto para conteúdo excluído, mas merece investigação em um checkout ativo. Use caminhos públicos reais, não painéis privados ou endereços com credenciais.
Leia a primeira resposta e o destino final
O primeiro código pertence ao endereço enviado. O último é da página alcançada após os redirecionamentos seguidos. Os URLs finais aparecem na tabela; as cadeias de redirecionamento observadas estão agrupadas nos detalhes do relatório. Um destino bem-sucedido não significa que o endereço original retorne 200 diretamente.
Estes exemplos fictícios explicam verificações concluídas; não são resultados de um site específico.
| Primeira → última resposta | Significado | O que revisar |
|---|---|---|
| 200 → 200 | Resposta bem-sucedida direta | É a página pretendida, com conteúdo útil? |
| 301 → 200 | Redirecionamento permanente para resposta bem-sucedida | A URL final é o substituto esperado? |
| 302 → 200 | Redirecionamento temporário para resposta bem-sucedida | A mudança é realmente temporária? |
| 301 → 404 | Redirecionamento para recurso não encontrado | Corrigir destino ou mapeamento se a página deveria existir |
| 403 → 403 | A requisição foi recusada | Examinar regras de acesso sem supor bloqueio para todos |
A referência HTTP da MDN explica os códigos. 404 significa não encontrado; 410 indica recurso removido. Ambos podem ser intencionais. 429 sinaliza excesso de requisições; 5xx indica erros do servidor. O código identifica a categoria, não toda a causa.
As contagens se sobrepõem: uma URL redirecionada também pode terminar com sucesso ou erro HTTP. Somá-las não precisa produzir o total de URLs únicas.
Separe verificações indisponíveis de erros HTTP
Um erro HTTP, como 404 ou 503, é uma resposta. Resultado indisponível significa que a observação não terminou. Resolução DNS, falha de conexão segura ou timeout podem impedir a resposta final. Leia o motivo em vez de interpretar uma célula vazia como 404.
Cada URL tem oito segundos e o lote completo, 30 segundos. A ferramenta segue até cinco redirecionamentos HTTP. Loop, destino ausente ou cadeia maior podem deixar o resultado incompleto. São limites da ferramenta, não do rastreamento do Google. As etapas observadas permanecem: um 301 pode aparecer sem código final quando a conexão segura seguinte falha.
A mudança de HTTPS para HTTP é sinalizada. A ferramenta segue redirecionamentos de respostas HTTP, mas não executa JavaScript nem instruções meta-refresh da página. Um navegador pode agir de modo diferente.
A duração descreve esta verificação e seu percurso de requisições. Não mede carregamento de imagens, execução de JavaScript ou quando o visitante pode interagir. Use-a para investigar a observação, não como pontuação de velocidade.
Exporte os reparos e confira as mesmas URLs
Priorize erros em páginas que devem continuar disponíveis, destinos errados e endereços quebrados ainda ligados por páginas importantes. Não redirecione toda remoção à página inicial apenas para obter verde. Se o conteúdo mudou, escolha um substituto relevante; se desapareceu, avalie a resposta pretendida e remova referências obsoletas.
Filtre erros HTTP, redirecionamentos ou verificações indisponíveis e pesquise URLs. O CSV inclui apenas as linhas filtradas: primeiro/último código, destino, duração, motivo, horário e cadeia observada. Guarde esse retrato com o resultado esperado, faça o reparo e repita os mesmos endereços originais.
Investigue conteúdos duvidosos separadamente. As orientações HTTP do Google confirmam que 2xx não garante indexação; até uma página de erro pode retornar 200. A ferramenta não analisa o corpo para detectar soft 404. Use o Noindex Checker para diretivas de indexação ou o Redirect Checker para investigar redirecionamentos. Um status corrigido é uma condição verificada, não uma auditoria SEO completa.
Para analisar uma lista de URLs preferidos declarados, use o verificador canônico em lote. Ele verifica declarações HTML e cabeçalhos HTTP e um destino imediato por página; não mostra o canônico escolhido pelo Google.