Auditoria à Integridade dos Códigos de Estado

As frameworks modernas servem 200 para quase tudo, por isso um produto apagado, um resultado de filtro vazio e uma chamada falhada a um terceiro parecem todos páginas saudáveis a um crawler. O Google tem depois de adivinhar, através da detecção de soft 404, que é lenta e pouco fiável. A correcção reflexa de acrescentar noindex está errada para a maioria destes estados, porque mantém o URL na fila de rastreio indefinidamente em vez de o remover.

O ficheiro da competência

---
name: status-code-integrity-audit
description: Use quando páginas removidas, vazias ou com falha devolvem 200 OK, quando aparecem soft 404 na Search Console, ou antes de remover um lote de URLs de um site.
---

# Auditoria à Integridade dos Códigos de Estado

As frameworks modernas servem 200 para quase tudo, por isso um produto apagado, um resultado de filtro vazio e uma chamada falhada a um terceiro parecem todos páginas saudáveis a um crawler. O Google tem depois de adivinhar, através da detecção de soft 404, que é lenta e pouco fiável. A correcção reflexa de acrescentar noindex está errada para a maioria destes estados, porque mantém o URL na fila de rastreio indefinidamente em vez de o remover.

## O que precisa primeiro

- Uma exportação de crawl com códigos de estado, mais a lista de soft 404 da Search Console
- Uma lista de todos os estados que a aplicação consegue produzir sem conteúdo útil, retirada do código ou dos programadores e não de um crawl
- Acesso por linha de comandos para pedir URLs e ler os cabeçalhos de resposta em bruto
- A possibilidade de alterar códigos de estado na aplicação e de ver o que o CDN lhes faz

## Método

1. Enumere os estados de falha a partir do código, com os programadores: item apagado, pesquisa ou filtro sem resultados, anúncio expirado, esgotado em permanência, conteúdo atrás de login, dependência de API em falha. Um crawl só encontra os estados que já estão ligados, que são a minoria.
2. Peça um URL por estado a partir da linha de comandos e registe o estado do cabeçalho, não o que o corpo da página diz. Uma página que diz "não encontrado" enquanto envia 200 é o achado mais comum desta auditoria e é invisível num browser.
3. Atribua o código correcto a cada estado: 404 quando a coisa desapareceu e não tem equivalente, 410 quando tem a certeza e quer remoção mais rápida, 301 quando existe um substituto genuíno um-para-um, 200 com conteúdo real quando a página ainda serve para alguma coisa, e 503 com Retry-After para indisponibilidade planeada.
4. Verifique o que acontece sob carga e durante falhas de dependências. Um servidor que responde 200 com uma página de erro esconde uma avaria da monitorização e do Google, ao passo que um 503 correcto faz o rastreio abrandar e retomar sem perda de índice.
5. Concilie a lista com o relatório de soft 404. Cada entrada ali é o Google a dizer que discorda do seu 200, e é a confirmação mais barata que vai ter de que um estado está mal classificado.
6. Verifique ao nível do cabeçalho depois de fazer deploy, porque um edge worker, uma regra de cache ou uma página de erro personalizada podem reescrever um estado que a aplicação definiu correctamente, e os logs da aplicação vão mostrar o correcto.
7. Acompanhe as estatísticas de rastreio durante duas semanas. Um lote grande de novos 404 ou 410 produz um gráfico alarmante que é esperado e se corrige sozinho; uma subida de 5xx na mesma janela não é, e tem de ser travada.

## O que isto produz

Um mapa de códigos de resposta estado a estado, com o código actual e o correcto para cada um, e uma verificação ao nível do cabeçalho que confirma o que a produção envia de facto.

## Onde isto corre mal

- Redireccionar todas as páginas removidas para a homepage, o que o Google trata na mesma como soft 404 enquanto destrói o sinal de que a página desapareceu
- Servir 200 com noindex num estado vazio, deixando o URL na fila de rastreio para sempre sem nunca sair
- Testar num browser, onde um router do lado do cliente ou um service worker podem desenhar uma página 404 que foi entregue com um cabeçalho 200
- Responder 404 durante uma janela de manutenção em vez de 503, o que faz cair páginas funcionais do índice por causa de uma hora

---

Da biblioteca de competências da QuQi - https://www.quqi.io/pt/skills/status-code-integrity-audit

O que precisa primeiro

• Uma exportação de crawl com códigos de estado, mais a lista de soft 404 da Search Console
• Uma lista de todos os estados que a aplicação consegue produzir sem conteúdo útil, retirada do código ou dos programadores e não de um crawl
• Acesso por linha de comandos para pedir URLs e ler os cabeçalhos de resposta em bruto
• A possibilidade de alterar códigos de estado na aplicação e de ver o que o CDN lhes faz

Método

1. 01 Enumere os estados de falha a partir do código, com os programadores: item apagado, pesquisa ou filtro sem resultados, anúncio expirado, esgotado em permanência, conteúdo atrás de login, dependência de API em falha. Um crawl só encontra os estados que já estão ligados, que são a minoria.
2. 02 Peça um URL por estado a partir da linha de comandos e registe o estado do cabeçalho, não o que o corpo da página diz. Uma página que diz "não encontrado" enquanto envia 200 é o achado mais comum desta auditoria e é invisível num browser.
3. 03 Atribua o código correcto a cada estado: 404 quando a coisa desapareceu e não tem equivalente, 410 quando tem a certeza e quer remoção mais rápida, 301 quando existe um substituto genuíno um-para-um, 200 com conteúdo real quando a página ainda serve para alguma coisa, e 503 com Retry-After para indisponibilidade planeada.
4. 04 Verifique o que acontece sob carga e durante falhas de dependências. Um servidor que responde 200 com uma página de erro esconde uma avaria da monitorização e do Google, ao passo que um 503 correcto faz o rastreio abrandar e retomar sem perda de índice.
5. 05 Concilie a lista com o relatório de soft 404. Cada entrada ali é o Google a dizer que discorda do seu 200, e é a confirmação mais barata que vai ter de que um estado está mal classificado.
6. 06 Verifique ao nível do cabeçalho depois de fazer deploy, porque um edge worker, uma regra de cache ou uma página de erro personalizada podem reescrever um estado que a aplicação definiu correctamente, e os logs da aplicação vão mostrar o correcto.
7. 07 Acompanhe as estatísticas de rastreio durante duas semanas. Um lote grande de novos 404 ou 410 produz um gráfico alarmante que é esperado e se corrige sozinho; uma subida de 5xx na mesma janela não é, e tem de ser travada.

O que isto produz

Um mapa de códigos de resposta estado a estado, com o código actual e o correcto para cada um, e uma verificação ao nível do cabeçalho que confirma o que a produção envia de facto.

Onde isto corre mal

• Redireccionar todas as páginas removidas para a homepage, o que o Google trata na mesma como soft 404 enquanto destrói o sinal de que a página desapareceu
• Servir 200 com noindex num estado vazio, deixando o URL na fila de rastreio para sempre sem nunca sair
• Testar num browser, onde um router do lado do cliente ou um service worker podem desenhar uma página 404 que foi entregue com um cabeçalho 200
• Responder 404 durante uma janela de manutenção em vez de 503, o que faz cair páginas funcionais do índice por causa de uma hora

Use esta skill na sua própria IA

O ficheiro é markdown simples, com o nome e o gatilho no frontmatter. Quando um assistente consegue carregar skills sozinho, é esse frontmatter que lê para decidir que esta se aplica.

Mais em SEO técnico