204 Sem Conteúdo

TL;DR — Uma resposta 204 No Content significa “sua solicitação funcionou, e estou enviando deliberadamente uma página vazia”. É um código de sucesso, não um erro. Isso é perfeitamente adequado para coisas como um aplicativo salvando seu trabalho em segundo plano ou um rastreador de analytics — mas está errado para uma página real que você quer no Google. Um corpo vazio não dá ao Google nada para indexar, então ele trata um 204 em uma página como um soft 404.

O que é um 204, de fato

Toda resposta que seu servidor envia vem com um código de status. Os códigos 2xx significam “sucesso”. 200 OK — o que você quer nas suas páginas — significa “aqui está a página”, com corpo e tudo. 204 No Content também significa sucesso, mas com uma diferença: o servidor está dizendo “fiz o que você pediu, e intencionalmente não há nada para mostrar”.

A palavra-chave é intencionalmente. Um 204 não é uma página que falhou ao carregar nem uma URL que não existe — é uma resposta projetada para ser vazia. Pense nele como o servidor acenando “pronto” sem entregar nada em troca.

Por que isso é um problema para uma página

O Google indexa o conteúdo de uma página. Se uma URL retorna 204, não há conteúdo para ler — o corpo está vazio por definição. A documentação do próprio Google diz isso claramente: “wasn’t able to receive any content and therefore can’t process it.” (tradução) «não conseguiu receber nenhum conteúdo e, portanto, não pode processá-lo». Assim, uma página que você quer ranquear e que retorna 204 não dá ao Google nada com que trabalhar, o que significa que não será indexada — e, na prática, o Search Console costuma sinalizar essas páginas da mesma forma que sinaliza um soft 404: uma página que tecnicamente “teve sucesso”, mas não tem nada que valha a pena indexar.

Portanto, quando uma página que você quer ranquear aparece como 204 em um rastreamento ou no Search Console, isso é um bug para corrigir, não algo para deixar como está.

Quando um 204 é perfeitamente adequado

A maioria dos 204s que você verá não são páginas:

• Aplicativos salvando em segundo plano. Você toca em “salvar” e o aplicativo armazena seu trabalho sem recarregar a página — o servidor pode responder com 204.
• Analytics e rastreamento. Os rastreadores disparam pequenas requisições de beacon para registrar que algo aconteceu. Não há uma página para retornar, então um 204 é exatamente o certo.
• Interfaces de aplicativos (APIs). Quando um sistema manda outro excluir algo, muitas vezes não há nada para devolver — um 204 diz “pronto”.

Nada disso precisa estar no Google, então um 204 nesses casos é a resposta correta, não um erro.

A única regra para lembrar

Nunca retorne 204 para uma URL que você quer que as pessoas encontrem na busca. Se uma página desapareceu de vez, use 404 ou 410. Se ela mudou de lugar, redirecione-a (301). Se deveria ter conteúdo, corrija o que está servindo uma resposta vazia. Quer a versão mais aprofundada — a redação exata do Google, os casos de uso de APIs e beacons e como diagnosticar um 204 acidental? Mude para a aba Avançado.

TL;DR — 204 é um código de sucesso 2xx compatível com a especificação (RFC 9110 §15.3.5) que retorna um corpo vazio por design — o corpo precisa estar vazio (sem Content-Length também, nem mesmo 0), e os navegadores podem rejeitar um 204 que envia conteúdo. Não é um erro e não diz nada sobre a existência; a RFC não o restringe a uma lista fixa de métodos. Os usos legítimos são quase todos para respostas que não são documentos: DELETE/PUT de APIs REST e beacons de analytics (sendBeacon(), o Measurement Protocol do GA4) — embora profissionais discordem sobre com que frequência as APIs deveriam usá-lo. A consequência de SEO é restrita: a tabela de códigos de status do Google diz claramente que, em um 204, “Google wasn’t able to receive any content and therefore can’t process it” (tradução) «o Google não conseguiu receber nenhum conteúdo e, portanto, não pode processá-lo» — o que significa que uma página que você quer ranquear não será indexada a partir dessa resposta e, na prática, essas páginas costumam ser sinalizadas como soft 404s no Search Console, embora o Google não garanta esse rótulo exato nem um prazo de remoção. Portanto, 204 é adequado para endpoints de API e beacon e errado para tudo que deveria ranquear. Se uma página realmente desapareceu, use 404 ou 410; se mudou, use 301; se deveria ter conteúdo, corrija o servidor/CDN que está enviando 204 em vez de 200 com um corpo real.

O que 204 significa na especificação

A RFC 9110 (HTTP Semantics) é inequívoca: um 204 indica que “o servidor cumpriu a solicitação com sucesso e que não há conteúdo adicional a enviar no corpo do payload da resposta”. É um código de sucesso — da mesma família 2xx que 200 OK — com a diferença deliberada de que não há corpo.

Três detalhes operacionais importam. Primeiro, o corpo realmente precisa estar vazio: o MDN observa que um 204 “must not include any content or the Content-Length header (browsers may reject responses that include content).” (tradução) «não deve incluir conteúdo nem o cabeçalho Content-Length (os navegadores podem rejeitar respostas que incluam conteúdo)». Isso é uma proibição real, não uma convenção flexível — a RFC 9110 §8.6 proíbe Content-Length em um 204 sem exceção, então “basta enviar Content-Length: 0” (uma correção que já vi ser recomendada) também não está em conformidade; a resposta termina na seção de cabeçalhos, ponto final. Segundo, quaisquer cabeçalhos que um 204 carregue — um ETag, um Last-Modified — descrevem a representação selecionada depois que sua ação foi concluída, não um corpo que foi enviado. Terceiro, um ETag aparece em alguns 204s (o exemplo do MDN é um PUT que atualiza um recurso no local), mas a RFC não exige que todo 204 inclua um — não conte com ele. Um 204 é armazenável em cache heuristicamente por padrão, salvo se o método ou cabeçalhos explícitos de controle de cache disserem o contrário.

Fundamentalmente, 204 não tem nada a ver com a existência de uma URL. Um endpoint de API que funciona pode retornar 204 para sempre. Essa é a diferença em relação a um 404 (não encontrado) ou 410 (gone) — eles tratam de ausência; 204 trata de uma solicitação bem-sucedida que deliberadamente não carrega payload.

Como o Google trata um 204

Esta é toda a história de SEO, e ela é mais restrita do que o texto genérico de blogs de fornecedores faz parecer. O Google indexa conteúdo. Um 204 não tem conteúdo. A documentação de códigos de status do próprio Google destaca o 204 com uma afirmação específica e limitada: enquanto a regra geral para 2xx é que “Google considers the content for processing,” (tradução) «o Google considera o conteúdo para processamento», a linha dedicada ao 204 diz que “Google wasn’t able to receive any content and therefore can’t process it.” (tradução) «o Google não conseguiu receber nenhum conteúdo e, portanto, não pode processá-lo».

Esse é o limite real, e vale ser preciso sobre o que ele promete e o que não promete. A orientação geral sobre 2xx em outra parte da página diz que conteúdo vazio ou semelhante a erro pode ser reportado como soft 404 — mas a linha do 204 não garante que todo 204 receberá esse rótulo específico no Search Console, e o Google não publica um prazo de remoção. O que é sólido: um 204 em uma URL de conteúdo não fornece nada ao pipeline de indexação do Google, então dizer que a URL não será indexada a partir dessa resposta é uma inferência razoável — não uma afirmação que eu estenderia para “perda garantida de ranking em todo o site” ou “recuperação automática do crawl budget”, porque a documentação do Google não promete nenhuma das duas coisas. Na prática, o Search Console costuma apresentar esses casos como soft 404s — esse é o padrão que já vi e sobre o qual escrevi — mas trate o rótulo específico e o momento como comportamento observado, não como garantia documentada.

Esta é a posição que mantenho nos meus próprios textos. No meu guia Códigos de status HTTP e seu impacto em SEO no blog da Ahrefs, na seção sobre como o Google trata respostas 2xx, escrevi diretamente: “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.» Continuo defendendo essa leitura prática; a formulação mais precisa e atual da documentação do Google é o enquadramento “não consegue receber nem processar conteúdo” acima, e é essa que eu indicaria para o limite oficial exato.

Soft 404s são documentados como continuando a ser rastreados e desperdiçando crawl budget — mas essa é a orientação geral do Google sobre soft 404, não uma promessa específica para 204. Usar 204 não libera nem redireciona automaticamente recursos de rastreamento; a própria ressalva do Google é que a alocação de recursos depende de limites de serviço, qualidade do site e inventário, não do código de status que causou a exclusão.

204 vs. os códigos com que ele é confundido

A armadilha é que 204, 200 vazio, 404 e 410 podem acabar como “soft 404” no GSC quando não há conteúdo utilizável — mas eles sinalizam intenções muito diferentes para um cliente compatível com a especificação. 410 é o sinal deliberado de “isso existia e desapareceu permanentemente”; 204 nunca foi projetado para esse significado e não deveria aparecer em URLs de páginas.

Quando 204 é exatamente o certo (não um bug)

Quase todo 204 legítimo é uma resposta que não é um documento:

• DELETE / PUT de API REST. Quando um cliente exclui um recurso ou o atualiza no local e não há nada significativo para retornar, 204 é a resposta idiomática — é o padrão recomendado pela própria RFC 9110.
• Beacons de analytics e rastreamento. A especificação Beacon do W3C, construída em torno de navigator.sendBeacon(), espera que os endpoints de beacon respondam com 204. O endpoint do Measurement Protocol do Google Analytics 4 retorna 204 para hits que aceita. Um alerta importante: o GA4 retorna 204 até para payloads malformados ou inválidos, então esse 204 confirma apenas que o endpoint estava acessível e respondeu estruturalmente — não que o hit foi realmente processado. Não interprete o 204 de um beacon como prova de sucesso.
• UX de “salvar sem sair da página”. Um PUT que salva o estado no local e mantém o usuário na página atual — o próprio enquadramento do MDN é que, com um 204, “the client doesn’t need to navigate away from its current page.” (tradução) «o cliente não precisa sair da página atual».

A linha comum é: essas não são URLs que alguém deveria indexar, então um 204 é correto e esperado. O problema é somente um 204 em uma URL de documento que deveria ranquear.

Uma nuance relacionada merece destaque: a RFC 9110 não restringe 204 especificamente a DELETE/PUT/beacons — esses são apenas os padrões comuns. A definição da especificação é neutra quanto ao método; o que importa é o contrato do próprio método e se seria útil retornar uma representação. Isso funciona nos dois sentidos. Uma requisição GET que retorna 204 é legal segundo o protocolo — profissionais discutem isso no Stack Overflow há anos — e a pergunta real para uma página indexável não é “204 em GET é permitido?”, mas “esta URL precisa entregar uma representação para ser encontrada?”. Para uma página que você quer ranquear, a resposta é sempre sim. Portanto, a regra de SEO não depende do método HTTP usado; depende de a URL ser um documento ou não.

Também vale saber que “204 é sempre certo para respostas de API” não é uma opinião universal nem entre designers de API. O texto do Postman apresenta 204 como opção padrão para ações sem nada a retornar; Brandur Leach defendeu o caso oposto — uma resposta de sucesso vazia pode ser levemente prejudicial para clientes de API que esperam receber uma representação (estado atualizado, um ID gerado, um campo calculado) mesmo depois de uma gravação bem-sucedida. Esse é um trade-off legítimo de design de API sobre ergonomia do desenvolvedor, não uma questão de correção HTTP — 204 continua compatível com a especificação em qualquer caso — e é separado da questão de SEO deste artigo. Um ponto em que textos sobre APIs às vezes são descuidados: enviar Content-Length: 0 em um 204 “por segurança”. Não faça isso — a RFC 9110 §8.6 proíbe Content-Length inteiramente em uma resposta 204, não apenas quando o valor é diferente de zero.

Diagnosticando e corrigindo um 204 acidental no nível da página

Se um rastreador (Screaming Frog, Ahrefs Site Audit) ou seus logs mostrarem 204 em uma página que deveria ter conteúdo:

1. Confirme o que o Googlebot realmente recebe. Use a Inspeção de URL no Search Console para ver o status e o conteúdo renderizado que o Google recebe — não apenas o que o seu navegador vê. Uma CDN, um worker de borda, um WAF ou uma rota do aplicativo pode retornar 204 para bots ou sob condições específicas enquanto tudo parece normal para você (o mesmo padrão de “parece normal no meu navegador” que ocorre com um 403 perdido).
2. Depois corrija de acordo com a intenção:
   • A página deve existir com conteúdo → encontre a lógica do servidor/CDN/aplicativo que emite 204 e restaure um 200 adequado com o corpo real.
   • A página desapareceu sem substituta → retorne 404 ou 410.
   • A página mudou → use 301 para a nova URL.
3. Monitore. Observe o relatório de Indexação de páginas do GSC em busca de entradas de soft 404, acompanhe os códigos de status de rastreamento nos logs e configure seu rastreador para sinalizar 204s, para que um erro acidental em um template não desindexe silenciosamente uma seção inteira.

O modelo mental a manter é: 204 não é “ruim”. É uma ferramenta precisa, correta para endpoints de API e beacon e errada para documentos. O modo de falha é usá-la no lugar errado. Códigos próximos como 403, 404, 410 e soft 404 também têm seu lugar nessa decisão — o lugar do 204 é fora da página.

Resumo de IA

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

• 204 No Content é um código de sucesso 2xx (RFC 9110 §15.3.5) que retorna um corpo vazio por design. Não é um erro e não diz nada sobre a existência de uma URL. A RFC não o restringe a uma lista fixa de métodos — DELETE/PUT/beacons são padrões comuns, não uma exigência, e 204 em uma requisição GET é legal segundo o protocolo.
• O corpo deve estar vazio, sem exceções. Segundo o MDN, um 204 não deve incluir conteúdo nem o cabeçalho Content-Length — e a RFC 9110 §8.6 proíbe Content-Length de forma absoluta, então Content-Length: 0 também não está em conformidade. Quaisquer cabeçalhos presentes descrevem a representação selecionada depois da ação, não um corpo transferido. Um 204 é armazenável em cache heuristicamente por padrão, mas um ETag não é garantido em todo 204 — o exemplo do MDN o inclui para um caso específico de PUT, não como regra universal.
• Consequência de SEO (restrita e precisamente delimitada): a documentação de códigos de status do Google diz claramente que, em um 204, “Google wasn’t able to receive any content and therefore can’t process it.” (tradução) «o Google não conseguiu receber nenhum conteúdo e, portanto, não pode processá-lo». Isso sustenta uma inferência razoável — uma página que você quer ranquear não será indexada a partir dessa resposta — mas o Google não garante que todo 204 receberá um rótulo específico de soft 404 nem um prazo de remoção, e usar 204 não recupera automaticamente o crawl budget nem prova um efeito no ranking. Como Patrick coloca em seus próprios textos: “204s will be treated as soft 404s and won’t be indexed” (tradução) «204s serão tratados como soft 404s e não serão indexados» — o padrão prático que ele observou, embora a redação oficial precisa seja mais restrita.
• Os usos legítimos são principalmente para não documentos: DELETE/PUT de APIs REST e beacons de analytics (sendBeacon() e Measurement Protocol do GA4). O GA4 retorna 204 até para hits malformados, então um 204 de beacon não prova que o hit foi processado. Os profissionais também não concordam totalmente aqui — o Postman trata 204 como padrão para ações sem nada a retornar, enquanto Brandur Leach argumenta que um sucesso vazio pode prejudicar levemente clientes que esperam uma representação; isso é um debate de ergonomia de API, não de correção HTTP.
• 204 nunca é adequado para uma página que deveria ranquear. Desapareceu sem substituta → 404/410; mudou → 301; deveria ter conteúdo → corrija o servidor/CDN que emite 204 e restaure um 200 real. Confirme o que o Googlebot recebe com a Inspeção de URL.

Documentação oficial

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

Especificação HTTP e referência de navegador

• RFC 9110 §15.3.5 — 204 No Content — a definição autoritativa: sucesso, sem corpo de payload, sem trailers, armazenável heuristicamente em cache, e cabeçalhos que descrevem a representação selecionada depois da ação.
• RFC 9110 §8.6 — Content-Length — a regra que proíbe inteiramente Content-Length em uma resposta 204 (não apenas quando o valor é diferente de zero).
• MDN — 204 No Content — explicação em linguagem simples, a restrição de corpo vazio / Content-Length, a cacheabilidade e um exemplo específico de ETag, além do caso de uso de “salvar sem sair da página”.

Google Search Central

• Como códigos de status HTTP, rede e erros de DNS afetam a Pesquisa Google — a tabela de códigos de status que cita 204 pelo nome e a definição de soft 404 do Google.

Beacons e analytics (os casos legítimos de 204)

• W3C — Beacon — a especificação de navigator.sendBeacon() que espera 204 dos endpoints de beacon.
• Google Analytics 4 — Measurement Protocol reference — o endpoint de coleta cujas respostas (incluindo 204 para hits aceitos) são documentadas aqui.

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 204 (No Content) status code indicates that the server has successfully fulfilled the request and that there is no additional content to send in the response payload body.” (tradução) «O código de status 204 (No Content) indica que o servidor cumpriu a solicitação com sucesso e que não há conteúdo adicional a enviar no corpo do payload da resposta.» — RFC 9110, HTTP Semantics, §15.3.5. Leia a seção

MDN Web Docs

• “The HTTP 204 No Content successful response status code indicates that a request has succeeded, but the client doesn’t need to navigate away from its current page. A 204 response is cacheable by default, and an ETag header is included in such cases.” (tradução) «O código de status de resposta bem-sucedida HTTP 204 No Content indica que uma solicitação teve sucesso, mas o cliente não precisa sair da página atual. Uma resposta 204 pode ser armazenada em cache por padrão, e um cabeçalho ETag é incluído nesses casos.» Ir para a citação

Google Search Central — tratamento de 2xx / 204

• “Google wasn’t able to receive any content and therefore can’t process it.” (tradução) «O Google não conseguiu receber nenhum conteúdo e, portanto, não pode processá-lo.» — documentação de códigos de status HTTP do Google, linha do 204 na tabela de 2xx (em contraste com a regra geral de 2xx, segundo a qual “o Google considera o conteúdo para processamento”). Documentação de códigos de status do Google

Patrick Stox — Ahrefs

• “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 meu guia Códigos de status HTTP e seu impacto em SEO. Ir para a citação

Matt G. Southern — Search Engine Journal

• “The exception is a 204 status code, which means the page was successfully accessed but no content was found. Google may show a soft 404 in Search Console for pages serving a 204 code.” (tradução) «A exceção é um código de status 204, que significa que a página foi acessada com sucesso, mas nenhum conteúdo foi encontrado. O Google pode mostrar um soft 404 no Search Console para páginas que servem um código 204.» Ir para a citação

204s legítimos vs. acidentais

Casos concretos de onde um 204 pertence — e onde ele é um bug.

Correto: DELETE de API REST

Um cliente exclui um recurso; não há nada para retornar.

DELETE /api/items/42 HTTP/1.1
Host: example.com

HTTP/1.1 204 No Content

Sem corpo, sem Content-Length. Essa é a resposta idiomática e nunca deveria ser uma URL que você espera encontrar na busca.

Correto: beacon de analytics (sendBeacon)

// Fires a fire-and-forget beacon on page unload
navigator.sendBeacon('/collect', payload);
// Endpoint responds:  HTTP/1.1 204 No Content

O endpoint não tem nenhuma página para servir, então 204 é exatamente o certo. O mesmo vale para o endpoint do Measurement Protocol do GA4 — lembre-se apenas de que o GA4 retorna 204 até para hits malformados, então um 204 confirma que o endpoint respondeu, não que o hit foi processado.

Errado: uma página de conteúdo retornando 204

GET /blog/my-article/ HTTP/1.1
Host: example.com

HTTP/1.1 204 No Content        ← bug: a real page must return 200 + body

O Google recebe um corpo vazio, trata a URL como um soft 404 e não a indexará. A correção depende da intenção:

• Deve existir com conteúdo → restaure 200 OK com o corpo real (corrija a rota do servidor/CDN/aplicativo que emite 204).
• Desapareceu sem substituta → 404 ou 410.
• Mudou de lugar → 301 para a nova URL.

Regra prática: se uma pessoa deve acessar a URL e ler algo, ela precisa retornar 200 com um corpo. Reserve 204 para endpoints máquina a máquina — APIs e beacons — nos quais realmente não há nada a mostrar.

Diagnostique um 204 inesperado

Uma página está em branco e o painel Network mostra 204

Sintoma: uma URL de documento que deveria renderizar conteúdo retorna 204 No Content.

Causa provável: o roteamento do aplicativo, uma regra da CDN, um worker de borda ou um tratador de erros está emitindo a resposta de sucesso no estilo de API em uma rota de página.

Correção: rastreie a solicitação pela camada responsável pela resposta. Se a página deve existir, restaure um 200 com um corpo real. Confirme a correção com uma nova solicitação de cabeçalhos e recarregando o navegador com o cache desativado.

O Search Console reporta um soft 404 para uma URL 204

Sintoma: a URL é excluída como soft 404 mesmo que 204 seja um código de sucesso.

Causa provável: a classificação trata da ausência de conteúdo, não de o código começar com 2. Um 204 não tem corpo por definição.

Correção: escolha a resposta conforme a intenção: 200 com conteúdo para uma página real, 301 para uma mudança ou 404/410 para uma página desaparecida. Execute novamente a Inspeção de URL depois de publicar a mudança.

Seu navegador e o rastreador discordam sobre o status

Sintoma: a página parece normal no navegador, mas um rastreador ou uma entrada de log mostra 204.

Causa provável: lógica de bot, método, região, cache, WAF ou borda está variando a resposta.

Correção: compare GET e HEAD, solicitações com user-agent normal e do Googlebot e a requisição exata nos logs do servidor/CDN. Corrija a regra condicional e verifique se ambos os caminhos retornam a mesma resposta pretendida.

Classifique um conjunto de URLs 204 por intenção

Cole uma exportação de rastreamento ou log que inclua URL, método da solicitação, tipo de conteúdo, referenciador ou tipo de rota e código de resposta.

Classify each HTTP 204 row I provide as:
- likely legitimate API response,
- likely legitimate beacon/background request,
- accidental document/page response, or
- insufficient evidence.

For every row, cite the supplied evidence, explain why 204 does or does not fit, and give
the next verification step. For accidental page responses, recommend exactly one intended
outcome: 200 with content, 301 to a relevant replacement, or 404/410 if gone.

Do not infer that a 204 analytics response means the event was processed. Do not invent
route behavior, redirect targets, or page content. Return a table followed by a prioritized
manual-check queue.

PASTE ROWS HERE

Encontre respostas 204 acidentais

Inspecione uma URL e o método da solicitação

curl -sS -D - -o /dev/null https://example.com/page
curl -sS -X HEAD -D - -o /dev/null https://example.com/page

A solicitação do documento não deveria ser 204 se a URL deve renderizar conteúdo. Teste GET e HEAD, porque tratadores defeituosos específicos de método podem discordar.

Compare a resposta padrão com a resposta para o 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"

Um 204 com zero bytes baixados em apenas um caminho aponta para uma lógica condicional do servidor, da CDN ou do WAF. Use logs reais e a Inspeção de URL para confirmar o que o Google realmente recebeu.

Relate 204s de uma lista de URLs

while IFS= read -r url; do
  code=$(curl -sS -o /dev/null -w "%{http_code}" "$url")
  if [ "$code" = "204" ]; then printf '%s\t%s\n' "$code" "$url"; fi
done < urls.txt

Execute isto no macOS, Linux ou WSL com uma URL por linha em urls.txt. Revise cada resultado de acordo com a intenção da rota; 204s de APIs e beacons não são erros.

Ferramentas para separar 204s legítimos e acidentais

Ferramenta gratuita de Patrick

• Bulk HTTP Status Code Checker — confira até 500 URLs, filtre os resultados para 204 e exporte o conjunto afetado. Use o contexto da rota e do conteúdo para separar endpoints válidos de API/beacon de URLs de páginas que deveriam retornar conteúdo.

Confirme a causa

• Inspeção de URL do Google Search Console — teste uma URL de página ao vivo para ver o que o Google consegue buscar depois que você alterar a resposta.
• Logs do servidor/CDN — identifique se o 204 varia por método, user-agent, rota ou local da borda.
• Painel Network do DevTools do navegador — diferencie a solicitação do documento de chamadas de API e beacon em segundo plano; um 204 em um beacon pode estar correto, enquanto um 204 no documento não está.
• Um rastreador de site completo — faça o inventário das URLs de documento que retornam 204 e mantenha a verificação em auditorias recorrentes, para que uma regressão em um template não afete um grupo inteiro.

Teste seus conhecimentos: 204 No Content

Cinco perguntas rápidas sobre o significado de um 204 e quando ele é adequado. Escolha uma resposta para cada pergunta e depois confira.

Registro de alterações