200 OK — Tudo certo

TL;DR — Uma resposta 200 OK é o servidor dizendo “aqui está a página que você pediu, está tudo certo”. É o código de sucesso discreto que você quer em todas as páginas que gostaria de exibir no Google. Mas um 200, por si só, não garante que a página será indexada — o Google ainda avalia se vale a pena indexar o conteúdo. E um 200 em uma página que está quebrada ou vazia é um bug, não um sinal verde.

O que 200 OK significa

Sempre que seu navegador ou o Googlebot solicita uma página, o servidor responde com um código de status de três dígitos antes de enviar qualquer outra coisa. 200 OK é o código de “tudo certo” — o servidor encontrou o que você pediu e devolve o recurso, normalmente com o conteúdo da página incluído. (Tecnicamente, a especificação permite um 200 com corpo vazio em alguns casos, mas, para uma página que você quer que as pessoas leiam, o objetivo é sempre ter um corpo real.) É o código que você quase nunca percebe, porque significa que nada deu errado. Evidence for this claim RFC 9110 defines 200 OK as indicating that the request succeeded; the response content depends on the request method. Scope: HTTP semantics for 200 responses; this does not guarantee search indexing. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.3.1 — 200 OK

Patrick Stox resume isso em três palavras no guia de códigos de status HTTP da Ahrefs: “200 OK – All good. Everything is successful.” (tradução) «200 OK — Tudo certo. Tudo foi bem-sucedido.»

Para as páginas do seu site que você quer que as pessoas encontrem na busca, 200 é exatamente o código que elas devem retornar.

Por que 200 não é a história toda

Aqui está a parte que a maioria das páginas que explicam “o que significa 200” omite: um 200 faz sua página ser considerada para indexação, não garante que ela entrará no índice. São duas coisas muito diferentes.

Pense no 200 como o ingresso que deixa você passar pela porta. Depois que você entra, o Google ainda decide se vale a pena manter o conteúdo — ele tem alta qualidade? É quase uma duplicata de outra página? É superficial ou vazio? Tem uma tag noindex dizendo ao Google para ficar de fora? Qualquer uma dessas condições pode fazer uma página 200 perfeitamente saudável não ser indexada.

Portanto, se uma página retorna 200 mas não aparece no Google, o problema não é o código de status — é o conteúdo ou a configuração.

A armadilha: um 200 que na verdade significa “não encontrado”

O erro mais sorrateiro é uma página que retorna 200, mas cujo conteúdo diz “isso não existe”. Um produto sem estoque com uma página em branco, um artigo excluído que ainda carrega um template vazio, uma página de resultados de busca sem resultados — o servidor envia um 200 simpático, mas não há nada real ali.

O Google olha além do código para o conteúdo real, decide que a página está vazia ou é um erro e a rotula como soft 404 no Search Console — tratando-a como uma página realmente “não encontrada”. Isso é explicado em profundidade no artigo sobre soft-404-errors; a versão curta é: se uma página realmente desapareceu, ela deve retornar 404 ou 410, não 200.

A única regra para lembrar

Uma página que você quer no Google deve retornar 200 com conteúdo real. Se a página desapareceu, use 404 ou 410. Se mudou, redirecione-a (301). Se é uma duplicata de outra página, use uma tag canonical. Quer a redação exata do Google, a diferença entre 200 e 204 e como verificar o que o Googlebot realmente recebeu? Mude para a aba Avançado.

TL;DR — 200 OK é o código de sucesso 2xx padrão (RFC 9110 §15.3.1): o servidor atendeu à solicitação e, para GET/HEAD, o corpo é uma representação do recurso. Ele é armazenável em cache heuristicamente por padrão. Para SEO, é necessário, mas não suficiente — a documentação do próprio Google diz que o pipeline de indexação “may index the content, but that’s not guaranteed,” (tradução) «pode indexar o conteúdo, mas isso não é garantido», então qualidade, duplicação, conteúdo superficial e noindex ainda decidem o resultado depois do 200. A falha clássica é o soft 404: um 200 envolvendo conteúdo de erro ou vazio, que o Google detecta na camada de conteúdo e reporta como soft 404 independentemente do código. Compare 200 (corpo esperado) com 204 (corpo vazio, tratado como soft 404 em páginas) e 304 (um sinal de cache, não uma decisão de indexação). E confirme o que o Googlebot recebeu — cloaking, bloqueio de bots, regras geográficas e configuração de CDN/WAF podem entregar a ele um código diferente do que o navegador vê.

O que 200 significa na especificação

A RFC 9110 (HTTP Semantics) é a autoridade atual, e a §15.3.1 é direta: “The 200 (OK) status code indicates that the request has succeeded.” (tradução) «O código de status 200 (OK) indica que a solicitação teve sucesso.» O conteúdo do corpo depende do método da solicitação. Para os métodos importantes em páginas — GET e HEAD — o conteúdo é uma representação do recurso de destino. A RFC também faz uma ressalva: exceto nas respostas a CONNECT, espera-se que um 200 carregue conteúdo, salvo quando o enquadramento da mensagem sinaliza explicitamente comprimento zero — portanto, “um 200 sempre tem corpo” é uma abreviação, não um absoluto. Na prática, para uma página que você quer indexar, essa abreviação é o objetivo: um corpo real, não um vazio. Um 200 também é “armazenável heuristicamente em cache” por padrão, a menos que uma diretiva de controle de cache diga o contrário, razão pela qual cabeçalhos de validação como ETag e Last-Modified importam em páginas muito rastreadas. Evidence for this claim RFC 9110 defines 200 OK as indicating that the request succeeded; the response content depends on the request method. Scope: HTTP semantics for 200 responses; this does not guarantee search indexing. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.3.1 — 200 OK

Tecnicamente, 200 não serve apenas para páginas. A RFC explica o que “sucesso” significa para cada método:

Para métodos que não são GET, você muitas vezes não verá um 200 — o MDN observa que solicitações PUT ou DELETE bem-sucedidas “often do not result in a 200 OK response,” (tradução) «muitas vezes não resultam em uma resposta 200 OK», sendo 201 Created ou 204 No Content mais comuns. Nada disso é relevante para SEO de URLs de páginas; a frase a levar adiante é que, para um documento que você quer indexar, o objetivo é 200 com um corpo real.

Necessário, mas não suficiente, para indexação

Esta é a coisa mais importante de acertar e é onde a maioria das páginas de glossário concorrentes está categoricamente errada. Elas dizem “200 significa que a página é indexada”. A documentação do próprio Google diz o contrário. Para um 200, o Google “passes on whatever it received to the next processing step… For Google Search, the next system is the indexing pipeline. The indexing systems may index the content, but that’s not guaranteed.” (tradução) «passa o que recebeu para a próxima etapa de processamento… Para a Pesquisa Google, o sistema seguinte é o pipeline de indexação. Os sistemas de indexação podem indexar o conteúdo, mas isso não é garantido.» Evidence for this claim Google passes a 2xx response to its indexing pipeline, which may index the content but does not guarantee that it will do so; error-like content can be classified as a soft 404. Scope: Google Search handling of 2xx page responses and soft 404s. Confidence: high · Verified: 2026-07-14 Google: HTTP status codes and Search

Portanto, o 200 é um contrato sobre a resposta HTTP, não uma promessa sobre o destino da página na Busca. Depois do 200, o Google avalia independentemente:

• Qualidade — páginas superficiais, de baixo valor ou geradas automaticamente podem não ser indexadas.
• Duplicação — uma quase duplicata de uma URL mais forte pode ser incorporada a essa URL em vez de ser indexada separadamente (é isso que a tag canonical existe para controlar).
• Diretivas — um noindex em uma meta tag ou cabeçalho X-Robots-Tag mantém a página fora do índice mesmo com um 200 perfeito.

O guia de Patrick na Ahrefs traça o mesmo limite no nível da família: “Most 2xxs will allow pages to be indexed. However, 204s will be treated as soft 404s and won’t be indexed.” (tradução) «A maioria dos códigos 2xx permitirá que as páginas sejam indexadas. No entanto, os 204s serão tratados como soft 404s e não serão indexados.» O 200 torna uma página elegível; não faz com que ela seja indexada.

A armadilha do soft 404

A ilustração mais clara de que “200 não é a história toda” é o soft 404. A documentação de códigos de status do Google explica o mecanismo: “If the content suggests an error for Google Search, an empty page or an error message, Search Console will show a soft 404 error.” (tradução) «Se o conteúdo sugerir um erro para o Google Search, uma página vazia ou uma mensagem de erro, o Search Console mostrará um erro soft 404.» Observe o que isso significa — a classificação se baseia no conteúdo renderizado, não no código HTTP. O pipeline de indexação do Google olha além do 200 para o que realmente está na página e, se ela parece dizer “não encontrado”, é agrupada e reportada como um 404 real.

Os casos para o teste de realidade: um produto descontinuado cuja página agora carrega um template vazio, um artigo excluído que ainda retorna uma estrutura 200, uma página de categoria filtrada ou um resultado de busca com zero itens e uma mensagem de “nada aqui”. Cada um retorna um 200 tecnicamente correto enquanto informa a usuários e ao Google que não há nada para ver.

Este site tem um artigo dedicado a soft-404-errors sobre os mecanismos de detecção e as correções — não vou repeti-los aqui. O ponto para a discussão sobre 200 é simples: retornar 200 em uma página que realmente desapareceu é a configuração para um soft 404. A correção é fazer o código corresponder à realidade.

Uma armadilha relacionada: sucesso do transporte não é sucesso da aplicação

Vale uma ressalva limitada, pois o assunto surge em círculos de APIs e monitoramento: a camada HTTP e a camada da aplicação podem discordar. Um endpoint de API pode enviar 200 com um objeto JSON de erro no corpo; uma página pode enviar 200 enquanto uma dependência do backend falhou silenciosamente e renderizou um bloco quebrado em vez do conteúdo real. A linha de status diz apenas “entregue com sucesso” — é só isso que ela afirma. Se o payload está de fato correto é uma pergunta separada que o código de status não responde. Profissionais estão genuinamente divididos sobre se uma API deve sinalizar um erro com um status diferente de 200 ou com um 200 envolvendo um payload de erro; esse é um contrato que cada equipe escolhe, não uma regra HTTP. Para o foco de SEO deste site, a versão no nível da página é o soft 404 acima — a correção é a mesma em espírito: não confie apenas na linha de status, veja o que o corpo realmente contém.

200 vs. 204 vs. 304 — não os confunda

Três códigos que as pessoas misturam, e apenas um deles é o sucesso “aqui está sua página”:

204 é um código de sucesso genuíno, mas seu corpo vazio não dá nada para um rastreador indexar — portanto, em uma URL de página, cai na categoria de soft 404 (esse é um artigo separado; não confunda o caso de corpo vazio com um 200 normal). 304 nem sequer pertence à mesma família — responde a uma solicitação condicional (If-None-Match / If-Modified-Since) informando ao cliente que sua cópia em cache ainda está atualizada. Não carrega corpo e não diz nada sobre indexação; é um mecanismo de eficiência de rastreamento, não um equivalente de 200 duplicado. A pergunta comum “200 e 304 não são a mesma coisa?” mistura uma otimização de cache com uma resposta de sucesso.

Confirme o que o Googlebot realmente vê

Aqui está uma lacuna que quase todo artigo concorrente ignora: solicitantes diferentes podem receber códigos diferentes para a mesma URL. Seu navegador pode ver um 200 limpo enquanto o Googlebot recebe outra coisa — às vezes deliberadamente (cloaking, uma violação de spam segundo os Search Essentials do Google), mais frequentemente por acidente através de regras de WAF/bloqueio de bots, direcionamento por Geo-IP, lógica de borda da CDN ou uma configuração de teste A/B que falha para bots.

Portanto, “é 200 no meu navegador” não prova que “o Google vê 200”. O diagnóstico correto é verificar o que o Googlebot recebeu:

• Inspeção de URL do GSC — execute um teste ao vivo para ver o status e o conteúdo renderizado que o Google busca, não o que sua máquina vê.
• Logs do servidor/CDN — a fonte de verdade sobre qual código cada user-agent realmente recebeu.

Um curl -I simples no terminal é útil, mas é apenas mais um solicitante que pode atingir regras de borda diferentes das do Googlebot — trate-o como um dado, não como a palavra final.

Como verificar e monitorar 200s

• DevTools do navegador — aba Network, recarregue, clique na solicitação do documento e leia a coluna Status.
• Linha de comando — curl -I https://example.com/page para os cabeçalhos de uma solicitação, curl -IL para seguir a cadeia de redirecionamentos.
• Google Search Console — a Inspeção de URL informa o status rastreado e permite um teste ao vivo.
• Bing Webmaster Tools — sua ferramenta de Inspeção de URL é a forma de confirmar o que o Bingbot recebeu. (O Bing não publica um documento específico sobre “como códigos de status afetam a indexação” como o Google faz — prefiro dizer isso a inventar uma política do Bing.)
• Rastreadores — Screaming Frog e Ahrefs Site Audit mostram códigos de status de todo o site em massa; a Ahrefs SEO Toolbar gratuita mostra o código da página em que você está.

O que significa estar “saudável”: suas URLs importantes e canônicas retornam consistentemente 200 com conteúdo real, e as páginas que deveriam desaparecer ou mudar retornam 404/410 ou 301 em vez de um 200 enganoso.

A decisão, em uma linha

Faça o código corresponder à realidade. Desejada no índice → 200 com conteúdo substancial. Desaparecida de vez → 404 ou 410 (consulte o artigo sobre 404). Mudou de lugar → 301. Duplicata de outra URL → aponte uma tag canonical para a versão preferida em vez de tentar forçar um código diferente de 200. O 200 é a luz verde para páginas que realmente a merecem — nada mais, nada menos.

Resumo de IA

Uma versão condensada da versão Avançada:

• 200 OK é o código de sucesso 2xx padrão (RFC 9110 §15.3.1): o servidor atendeu à solicitação e, para GET/HEAD, o corpo representa o recurso. Ele é armazenável heuristicamente em cache por padrão. A RFC trata o corpo como esperado, não absoluto — um 200 de comprimento zero é tecnicamente válido, embora uma página que você quer indexar precise de um corpo real.
• Necessário, mas não suficiente, para indexação. A documentação do próprio Google diz que os sistemas de indexação “may index the content, but that’s not guaranteed.” (tradução) «podem indexar o conteúdo, mas isso não é garantido». Qualidade, duplicação, conteúdo superficial e noindex são avaliados além do 200. A maioria das páginas concorrentes erra ao dizer “200 = indexado”.
• A armadilha do soft 404: um 200 envolvendo conteúdo de erro ou vazio é detectado na camada de conteúdo e reportado como soft 404 no Search Console — “se o conteúdo sugerir um erro… o Search Console mostrará um erro soft 404”. Um 200 em uma página que realmente desapareceu prepara esse resultado. Veja o artigo soft-404-errors.
• Uma armadilha paralela: a camada HTTP e a camada da aplicação podem discordar — um 200 pode envolver um payload de erro de API ou um bloco de backend silenciosamente quebrado. A linha de status afirma apenas que o transporte teve sucesso, não que o payload está correto.
• 200 vs. 204 vs. 304: 200 = sucesso com corpo real (elegível para indexação); 204 = sucesso com corpo vazio, tratado como soft 404 em URLs de páginas (veja 204-no-content); 304 = sinal de cache que responde a uma solicitação condicional, não uma decisão de indexação.
• Confirme o que o Googlebot recebeu. Solicitantes diferentes podem ver códigos diferentes para uma URL por causa de cloaking, bloqueio de bots, regras geográficas ou configuração de CDN/WAF. “200 no meu navegador” ≠ “o Google vê 200”. Verifique pela Inspeção de URL do GSC com teste ao vivo ou pelos logs do servidor, não apenas pelo navegador ou curl.
• Faça o código corresponder à realidade: desejada → 200 com conteúdo real; desaparecida → 404/410; movida → 301; duplicada → tag canonical. Como Patrick diz: “200 OK – All good. Everything is successful.” (tradução) «200 OK — Está tudo certo. A operação foi bem-sucedida.» — para uma página que realmente merece estar ali.

Documentação oficial

Referências de fontes primárias para entender o que é 200 e como o Google o trata.

Especificação HTTP e referência de navegador

• RFC 9110 §15.3.1 — 200 OK — a definição autoritativa: solicitação bem-sucedida, semântica do corpo por método e cacheabilidade heurística.
• MDN — 200 OK — explicação em linguagem simples, cacheabilidade por padrão e a nuance de PUT/DELETE (201/204 são mais comuns).

Google Search Central

• Como códigos de status HTTP, rede e erros de DNS afetam a Pesquisa Google — a linguagem sobre tratamento de 2xx (“pode indexar o conteúdo, mas isso não é garantido”) e a referência cruzada a soft 404.
• Soft 404 errors — Page indexing report — a definição do próprio Google sobre o 200 que na verdade é um erro e por que retornar um código de sucesso para uma página desaparecida é uma prática ruim.
• Cloaking — por que uma URL pode servir código/conteúdo diferente a usuários e ao Googlebot e por que isso é uma violação quando feito para manipular rankings.

Bing / Microsoft

• Bing Webmaster Tools — URL Inspection — a forma de confirmar a resposta HTTP que o Bingbot recebeu para uma URL. (Não existe um documento do Bing sobre “como códigos de status afetam a indexação”.)

Citações da fonte

Declarações registradas. Cada link é um deep link que salta para a passagem citada na página de origem.

A especificação HTTP

• “The 200 (OK) status code indicates that the request has succeeded.” (tradução) «O código de status 200 (OK) indica que a solicitação teve sucesso.» — RFC 9110, HTTP Semantics, §15.3.1. Leia a seção

MDN Web Docs

• “The HTTP 200 OK success status response code indicates that a request has succeeded. A 200 OK response is cacheable by default.” (tradução) «O código de status de resposta de sucesso HTTP 200 OK indica que uma solicitação teve sucesso. Uma resposta 200 OK pode ser armazenada em cache por padrão.» Ir para a citação

Google Search Central — tratamento de 2xx / 200

• A documentação explica que uma resposta 200 segue para a etapa de processamento específica do produto; na Pesquisa Google, entra no pipeline de indexação, que pode indexar o conteúdo sem garantir esse resultado. — documentação de códigos de status do Google, entrada do 200. Documentação de códigos de status do Google

• “If the content suggests an error for Google Search, an empty page or an error message, Search Console will show a soft 404 error.” (tradução) «Se o conteúdo sugerir um erro para o Google Search, uma página vazia ou uma mensagem de erro, o Search Console mostrará um erro soft 404.» — a mesma documentação, referência cruzada de soft 404. Documentação de códigos de status do Google

Patrick Stox — Ahrefs

• “200 OK – All good. Everything is successful.” (tradução) «200 OK — Tudo certo. A operação foi bem-sucedida.» — do meu guia de códigos de status HTTP no blog da Ahrefs. Ir para a citação

• “Most 2xxs will allow pages to be indexed. However, 204s will be treated as soft 404s and won’t be indexed.” (tradução) «A maior parte dos códigos 2xx permite indexar páginas; no entanto, os 204s são tratados como soft 404 e não são indexados.» — do mesmo guia, sobre como o Google trata a família 2xx. Ir para a citação

200 OK — referência rápida

O que é

200 vs. seus semelhantes confundidos

Qual código esta URL deve retornar?

• Desejada no índice → 200 com conteúdo real e substancial.
• Desaparecida de vez → 404 ou 410 (consulte o artigo sobre 404).
• Movida para uma nova URL → 301.
• Duplicata de outra URL → mantenha o 200 e adicione uma tag canonical à versão preferida.
• Vazia de propósito (API/beacon) → 204 (veja 204-no-content) — nunca em uma página.

Fatos rápidos

• Um 200 torna uma página elegível para indexação, não indexada — o Google decide separadamente com base em qualidade, duplicação, conteúdo superficial e noindex.
• Um 200 em uma página que realmente desapareceu ou está vazia é um soft 404 aos olhos do Google.
• Solicitantes diferentes podem ver códigos diferentes para uma URL — confirme o que o Googlebot recebeu pela Inspeção de URL do GSC ou pelos logs do servidor, não apenas pelo navegador ou curl.
• Verifique códigos com: aba Network do DevTools, curl -I / curl -IL, Inspeção de URL do GSC/Bing, Screaming Frog e Ahrefs Site Audit/Toolbar.

Mitos comuns sobre 200 OK

“Um código de status 200 significa que a página está indexada.” Falso. 200 significa que o servidor retornou o conteúdo com sucesso; a indexação é uma decisão posterior separada. A documentação do próprio Google diz: “may index the content, but that’s not guaranteed.” (tradução) «os sistemas podem indexar o conteúdo, mas isso não é garantido». Qualidade, duplicação, superficialidade e a diretiva noindex ainda são analisadas depois do 200.

“Se o Search Console mostra um soft 404, meu servidor tem um bug.” Não necessariamente. Soft 404 não é um código que seu servidor envia — é um rótulo que o Google aplica com base no descompasso entre o status 200 e um conteúdo que parece erro ou página vazia. O servidor está fazendo exatamente o que foi configurado para fazer (enviando 200); o problema é o conteúdo, não o cabeçalho.

“200 é sempre bom, ponto final.” Nem sempre. Um 200 em uma URL que deveria ter retornado 404 — um produto excluído, uma oferta expirada, uma página de resultados de busca vazia — é ativamente ruim. Isso convida o tratamento como soft 404 e pode desperdiçar esforço de rastreamento revisitando uma URL sem nada a oferecer.

“Meu navegador mostra 200, então o Google com certeza também vê 200.” Não é garantido. Bloqueio de bots, cloaking, regras de Geo-IP e configuração de CDN/WAF podem servir uma resposta diferente ao Googlebot da que um navegador humano recebe. Verifique pela Inspeção de URL ou pelos logs do servidor.

“200 e 204 são basicamente iguais — ambos significam sucesso.” Ambos são 2xx, mas 204 tem um corpo vazio por design. Isso é adequado para APIs e beacons e errado para uma página que você quer indexar — um 204 em uma URL de página é tratado como soft 404 (veja 204-no-content).

“200 vs. 304 — não são a mesma ideia?” Não. 304 Not Modified é um mecanismo de cache que responde a uma solicitação condicional (If-None-Match / If-Modified-Since), dizendo ao cliente para usar sua cópia em cache. Não carrega corpo e não é uma decisão de indexação — é um conceito diferente de um 200.

Por que uma página 200 OK ainda falha

O Search Console chama a URL de soft 404

Sintoma: a URL retorna 200, mas a Indexação de páginas a reporta como soft 404.

Causa provável: o corpo da resposta parece vazio, quebrado ou uma página de erro. Casos comuns são um produto descontinuado sem informações úteis, um artigo excluído dentro de um template que de resto está completo ou uma página de busca sem resultados.

Correção: faça a resposta corresponder à realidade. Restaure conteúdo substancial se a página deve existir, retorne 404 ou 410 se ela desapareceu, ou use 301 se mudou. Execute novamente o teste ao vivo da Inspeção de URL e confirme que a resposta e o conteúdo renderizado agora coincidem.

Seu navegador recebe 200, mas o Googlebot não

Sintoma: DevTools ou curl mostra 200, enquanto o Google não consegue buscar ou indexar a URL.

Causa provável: uma CDN, WAF, regra geográfica, regra de bot ou experimento está servindo ao Googlebot uma resposta diferente. Sua própria solicitação não prova qual foi a solicitação do Google.

Correção: compare uma solicitação normal com uma solicitação usando user-agent do Googlebot e depois verifique a Inspeção de URL e os logs do servidor/CDN. Corrija a regra de borda e confirme no teste ao vivo que a resposta recebida é 200 com o mesmo corpo substancial que os usuários recebem.

A página é 200, mas ainda não está indexada

Sintoma: o código de status está saudável, mas a URL continua excluída do índice.

Causa provável: 200 apenas torna o conteúdo elegível para processamento. Um noindex, conflito de duplicata/canonical ou conteúdo de baixo valor ainda pode mantê-lo fora do índice.

Correção: pare de mudar o código de status. Verifique as diretivas de indexação, a canonical escolhida pelo Google e o conteúdo real. Uma resposta HTTP bem-sucedida não é um veredito de indexação.

Respostas 200 que contam a história errada

Estes são exemplos simplificados. A linha de status é tecnicamente bem-sucedida, mas o corpo determina se esse sucesso é honesto.

Estrutura vazia de produto: 200 enganoso

HTTP/1.1 200 OK
Content-Type: text/html

<h1>Product unavailable</h1>
<p>There is nothing here.</p>

Se o produto desapareceu permanentemente sem substituto, retorne 404 ou 410. Se ainda existe uma página de produto útil — especificações, alternativas, suporte ou informações de disponibilidade — um 200 ainda pode ser adequado porque a página tem uma finalidade real.

Artigo excluído com substituto: use um redirecionamento

HTTP/1.1 301 Moved Permanently
Location: https://example.com/current-guide

Uma página 200 baseada em template dizendo “artigo excluído” abandona os usuários e convida a uma classificação de soft 404. Um substituto relevante deve ser o destino de um 301 no servidor.

Busca interna sem resultados: útil ou vazia

Um 200 pode ser honesto quando a página ajuda os usuários a reformular a busca, navegar pelas categorias ou encontrar alternativas. Uma página superficial contendo apenas “0 resultados” parece um erro apesar do código de sucesso. A diferença é a utilidade do corpo, não o número 200.

Faça a triagem de respostas 200 suspeitas

Cole uma exportação de rastreamento com URL, status, título, canonical, indexabilidade e uma amostra curta do texto do corpo. Este prompt separa sucesso HTTP de problemas de conteúdo e indexação.

You are auditing URLs that return HTTP 200. Review the pasted rows without assuming that
"200" means "indexed" or "healthy."

For each URL:
1. Classify it as a substantive page, likely soft 404, redirect-needed page, genuinely gone
   page, duplicate/canonical case, or needs manual review.
2. Cite the exact evidence from the supplied title, body sample, canonical, and directives.
3. Recommend one response: keep 200, restore content, 301 to a relevant replacement,
   return 404/410, or fix canonical/noindex signals.
4. Flag any conclusion that cannot be made from the supplied data.

Do not invent page content, redirect targets, or indexing status. End with a prioritized
manual-check list.

PASTE CRAWL ROWS HERE

Verifique a resposta em vez de confiar na página

Inspecione uma resposta com curl

Execute estes comandos no macOS, Linux ou WSL. O primeiro lê os cabeçalhos da resposta; o segundo também baixa o corpo, para que você possa verificar se o 200 contém conteúdo real.

curl -sI https://example.com/page
curl -sS -D - https://example.com/page -o page.html

Procure uma linha de status 200 e depois abra page.html. Os cabeçalhos sozinhos não revelam um soft 404.

Compare uma solicitação normal com um user-agent do Googlebot

url="https://example.com/page"
curl -sS -o /dev/null -w "default: %{http_code} %{size_download} bytes\n" "$url"
curl -sS -A "Googlebot" -o /dev/null -w "Googlebot UA: %{http_code} %{size_download} bytes\n" "$url"

Uma diferença é motivo para inspecionar regras e logs de CDN/WAF, não prova de que o Googlebot recebeu a resposta da solicitação falsificada. Confirme a busca real na Inspeção de URL.

Verifique uma lista em busca de respostas não 200

Coloque uma URL por linha em urls.txt:

while IFS= read -r url; do
  curl -sS -o /dev/null -w "%{http_code}\t%{url_effective}\n" "$url"
done < urls.txt

Isso encontra incompatibilidades óbvias de status. Não consegue julgar se um corpo 200 é substancial, então investigue os templates suspeitos e os relatórios de soft 404.

Ferramentas para validar respostas 200

Ferramenta gratuita de Patrick

• Bulk HTTP Status Code Checker — cole até 500 URLs para coletar códigos de status, destinos finais, cadeias de redirecionamento e latência em uma única exportação. Use-a para encontrar URLs que na verdade não retornam 200; depois inspecione o corpo e o Search Console separadamente em busca de soft 404s, pois um verificador de status não consegue avaliar a qualidade do conteúdo nem a indexação.

Evidências de mecanismos de busca e servidor

• Inspeção de URL do Google Search Console — compare o resultado indexado com uma busca ao vivo e revise o conteúdo renderizado que o Google consegue recuperar.
• Inspeção de URL do Bing Webmaster Tools — verifique a resposta que o Bingbot informa ter recebido.
• Logs do servidor e da CDN — confirme qual código de status as solicitações reais de rastreadores receberam; logs são evidências mais fortes do que mudar um user-agent no curl.
• Painel Network do DevTools do navegador — verifique a solicitação do documento, os cabeçalhos da resposta e o corpo da sessão do navegador à sua frente.

Teste seus conhecimentos: 200 OK

Cinco perguntas rápidas sobre o que 200 significa para SEO. Escolha uma resposta para cada pergunta e depois confira.

Registro de alterações