Código de estado HTTP 200

O que esta verificação faz

Envia um pedido GET ao URL auditado e lê o código de estado HTTP final. A verificação só passa em 200 OK. Sinaliza:

• redirecionamentos 3xx (o URL não é o canónico)
• erros 4xx (404 página não encontrada, 410 gone, 403 forbidden)
• erros 5xx (queda do servidor, gateway timeout)

O crawler segue até um pequeno número de redirecionamentos para também te poder dizer qual o estado final no fim da cadeia.

Porque é importante

Os motores de busca e os crawlers de IA tratam respostas não-200 como “não indexar este URL”.

• 301/302 — o URL não vai ranquear; o destino do redirecionamento sim. Se partilhaste example.com/post-antigo e ele faz 301 para example.com/post-novo, cada backlink, cada partilha social, cada seleção em featured snippet aponta para um URL que o Google vai deixar cair do índice em poucas semanas.
• 404 / 410 — o URL é removido do índice. Se isto aconteceu por acidente (gralha numa regra de redirecionamento, falta de barra final, página apagada que ainda tem backlinks), estás a perder tráfego silenciosamente.
• 500 / 502 / 503 / 504 — o Google tenta de novo e depois desindexa após uns dias de falhas. Pior, o Googlebot vai reduzir o crawl budget de todo o domínio.

Uma página que devolva algo diferente de 200 é invisível.

Como corrigir

Primeiro vê exatamente o que o servidor devolve. O curl -I mostra a cadeia toda:

curl -ILso /dev/null -w "%{http_code} %{url_effective}\n" https://example.com/pagina

Adiciona -L e -w "%{http_code} -> %{redirect_url}\n" para mapear todos os saltos. Se vires várias linhas 30x antes do 200 final, tens uma cadeia de redirecionamento — também vale a pena corrigir.

Se o URL deveria devolver 200 mas devolve 301/302:

Culpados comuns:

• Discrepância de WWW ou de barra final — example.com/pagina faz 301 para example.com/pagina/. Escolhe uma forma canónica (com ou sem barra) e linka-a consistentemente. Não ligues internamente para a forma que redireciona.
• Upgrade HTTPS — http://example.com/pagina faz 301 para https://example.com/pagina. Esperado, mas garante que todos os links internos e o sitemap usam HTTPS para que os crawlers nunca cheguem ao redirecionamento. Vê Redirecionar HTTP para HTTPS.
• Redirecionamento de locale no caminho raiz — / faz 302 para /en/ com base em Accept-Language. O Googlebot rasteja a partir dos EUA com en-US, por isso / torna-se um redirecionamento para /en/. Ou fazes com que / sirva diretamente o conteúdo em inglês (com hreflang para os outros locales) ou usas um 302 mais um hreflang x-default.

Se o URL devolve 404 por acidente:

• Verifica a configuração de routing (nginx try_files, Next.js [...slug].tsx, Astro getStaticPaths).
• Verifica a sensibilidade a maiúsculas — /About e /about são URLs diferentes em servidores Linux.
• Verifica a base de dados — uma página de CMS marcada como “rascunho” devolve 404 na maioria dos templates.

Se a página estiver genuinamente removida, devolve 410 Gone em vez de 404 — o Google desindexa 410s cerca de duas vezes mais depressa. Configura uma página 404 personalizada para que a resposta continue útil para humanos.

Se o URL devolve 5xx:

Isto é um problema do servidor, não de configuração. Consulta os logs da aplicação no momento em que o MetricSpot correu a auditoria. Causas comuns: pool de ligações à base de dados esgotado, out-of-memory numa função serverless, API de terceiros de que a página depende devolveu timeout.

Receitas:

# nginx — 200 explícito para uma rota, sem redirecionamento
location = /pricing {
  try_files /pricing.html =404;
}

// Express — devolver 410 para URLs removidos permanentemente
app.get("/old-product/:id", (req, res) => res.status(410).send("Gone"));

// Next.js (App Router) — devolver 410 a partir de um segmento de rota
import { notFound } from "next/navigation";
export default async function Page({ params }) {
  const product = await getProduct(params.id);
  if (!product) notFound(); // devolve 404 por defeito
  // ...
}

Em sites estáticos com Astro, um 410 tem de ser servido pelo teu host (nginx return 410; ou Cloudflare Worker), já que o output estático do Astro só emite 404s para rotas em falta.

Perguntas frequentes

O 301 é sempre mau?

Não. Um 301 é correto quando o URL mudou genuinamente — slug antigo para slug novo, HTTP para HTTPS, www para não-www. Só é mau quando o MetricSpot audita o URL que pretendes ser canónico e ele faz 301 para outro lado — isso significa que nos deste (e ao Google, e a todos os backlinks) o URL errado.

Devo devolver 200 para páginas em falta com uma mensagem de “não encontrado”?

Não. Devolver 200 com conteúdo “página não encontrada” chama-se soft 404. O Google deteta-o (por padrão de conteúdo) e trata-o como 404 de qualquer forma, mas confunde a analítica e inflaciona o teu crawl budget. Devolve sempre o código HTTP correto.

E o 304 Not Modified?

O 304 é uma resposta condicional bem-sucedida — o navegador já tem a página em cache. Não é um problema; o MetricSpot não envia cabeçalhos If-Modified-Since, por isso não o vês normalmente no nosso crawl. Se vires, a tua CDN está demasiado agressiva a fazer cache de respostas a GETs não autenticados.