304 Não Modificado

TL;DR — Uma resposta 304 Not Modified é a forma de o servidor dizer “você já tem isto — sua cópia continua boa; não baixe de novo”. Ela não é um erro e, apesar de estar na família “redirecionamento” 3xx, não envia ninguém para uma nova URL. Ela só acontece quando o cliente (um navegador ou rastreador) primeiro envia uma solicitação condicional perguntando “isto mudou desde a última vez?”. Para SEO, ela não altera seus rankings, mas em sites grandes pode ajudar os mecanismos de busca a usar seus recursos com mais eficiência.

O que é um 304, de fato

Toda resposta que seu servidor envia começa com um código de status de três dígitos. 200 OK significa “aqui está a página, com corpo e tudo”. Um 304 Not Modified significa algo mais específico: o cliente fez uma solicitação condicional — uma que diz “entregue esta página, mas somente se ela tiver mudado” — e o servidor determinou que ela não mudou; por isso, em vez do 200 que teria enviado, responde 304 sem corpo algum. Essa é a regra real: um 304 só pode ser a resposta a um GET/HEAD condicional cuja condição resultou falsa.

Uma segunda visita é a forma típica de isso acontecer e uma maneira útil de visualizar o processo: na primeira vez que um navegador ou rastreador busca uma página, recebe um 200 normal com todo o conteúdo — além de alguns cabeçalhos pequenos de “impressão digital”. Na visita seguinte, o cliente mostra essa impressão digital ao servidor e pergunta: “continua igual?”. Se nada mudou, o servidor responde 304 e não envia nenhum corpo de página; o cliente simplesmente reutiliza a cópia que já tinha. Mas “segunda visita” é o exemplo, não a regra do protocolo — o que realmente dispara um 304 é a própria solicitação condicional, seja como for que ela chegue. Evidence for this claim RFC 9110 defines 304 Not Modified as the response to a conditional GET or HEAD when the selected representation has not changed and says the response cannot contain content. Scope: HTTP semantics for 304 conditional responses. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.4.5 — 304 Not Modified

Por que ele está na família de “redirecionamentos”, mas não é um redirecionamento

304 começa com 3, a classe que o HTTP usa para redirecionamentos. Isso confunde as pessoas o tempo todo. Mas um 304 não tem cabeçalho Location e não envia você para outro endereço — ninguém vai a lugar algum. Ele apenas aponta o cliente de volta para a própria cópia salva. Portanto, “família de redirecionamentos” é uma peculiaridade da numeração, não uma descrição do que ele faz.

Um 304 é um problema?

Não. Ver 304s na aba de rede do navegador ou em um relatório de rastreamento é sinal de que o cache está funcionando — exatamente o que você quer. Muitos conselhos sobre “erro 304, como corrigir” tratam isso como algo quebrado do seu lado. Não está. É o resultado correto e esperado de um cache que se comporta bem.

Isso ajuda o SEO?

Não diretamente os seus rankings. O Google já tem seu conteúdo da última vez que rastreou a página — um 304 apenas confirma que ele não mudou, então o Google continua usando o que já armazenou (a Busca ainda pode recalcular os sinais de uma URL, mas o 304 em si não é um bônus de ranking ou indexação). Onde ele ajuda é na eficiência de recursos: quando um mecanismo de busca não precisa baixar de novo páginas que não mudaram, economiza largura de banda e computação nos dois lados, algo que o Google diz que pode ajudar indiretamente o rastreamento a funcionar com mais eficiência — não há garantia de que o esforço economizado seja redirecionado automaticamente para suas páginas novas ou atualizadas. Isso é mais importante em sites grandes, com muitas páginas que mudam raramente.

Quer entender a mecânica real — ETags, If-None-Match, validadores fortes versus fracos, como implementar isso e o que o Google realmente disse sobre o assunto? Mude para a aba Avançado.

TL;DR — 304 é a resposta a um GET/HEAD condicional cuja condição resulta falsa e que, de outra forma, teria recebido um 200 (RFC 9110 §15.4.5). Ele pertence à classe 3xx, mas não é um redirecionamento: não tem Location, não tem nova URL e — normativamente — não tem corpo (“it cannot contain content or trailers”). A condição é transportada por If-None-Match (contra uma ETag) e/ou If-Modified-Since (contra Last-Modified); se o validador ainda corresponder, o servidor retorna 304 e o cliente reutiliza o cache. Impacto em SEO: nenhum efeito direto no ranking — o Google já tem o conteúdo, embora a Busca ainda possa recalcular os sinais de uma URL — e uma economia de recursos em sites grandes (o Google diz que ela pode melhorar indiretamente a eficiência do rastreamento; não promete realocação automática do orçamento de rastreamento para outras URLs). A infraestrutura de rastreamento do Google aceita os dois validadores e recomenda ETag como principal (ela não tem armadilhas de formatação de data). Compare-o com 301/302/307/308 (que movem a URL) e com 204 (também sem corpo, mas porque genuinamente não há nada a enviar).

O que 304 significa na especificação

A RFC 9110 (HTTP Semantics) §15.4.5 define isso com precisão: “The 304 (Not Modified) status code indicates that a conditional GET or HEAD request has been received and would have resulted in a 200 (OK) response if it were not for the fact that the condition evaluated to false.” (tradução) «O código de status 304 (Not Modified) indica que uma solicitação GET ou HEAD condicional foi recebida e teria resultado em uma resposta 200 (OK) se não fosse pelo fato de a condição ter sido avaliada como falsa.» Esse é o gatilho normativo real — um GET/HEAD condicional cuja condição resulta falsa e que, de outra forma, teria recebido um 200. Em termos simples: o cliente pediu “entregue esta página, mas somente se ela tiver mudado”, o servidor determinou que ela não mudou e, portanto, deixa de enviar o corpo. Uma “segunda visita” é o exemplo cotidiano de como uma solicitação se torna condicional (o cliente anexa um validador salvo de uma resposta anterior), mas é um exemplo didático, não a regra — nada na especificação exige uma visita anterior, apenas uma solicitação condicional. Evidence for this claim RFC 9110 defines 304 Not Modified as the response to a conditional GET or HEAD when the selected representation has not changed and says the response cannot contain content. Scope: HTTP semantics for 304 conditional responses. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.4.5 — 304 Not Modified

A especificação inclusive usa a palavra “redirecting” nesta seção — “the server is therefore redirecting the client to make use of that stored representation as if it were the content of a 200 (OK) response” (tradução) «portanto, o servidor está redirecionando o cliente para usar aquela representação armazenada como se fosse o conteúdo de uma resposta 200 (OK)» — mas leia com atenção: ele está redirecionando o cliente de volta para o próprio cache, não para outra URL. Não há cabeçalho Location nem novo endereço. Essa única frase é a origem da maior parte da confusão sobre se 304 “é um redirecionamento”. Não é, no sentido do HTTP.

Dois outros pontos normativos importam:

• Nunca há corpo. A RFC 9110 diz: “A 304 response is terminated by the end of the header section; it cannot contain content or trailers.” (tradução) «Uma resposta 304 termina no fim da seção de cabeçalhos; não pode conter conteúdo nem trailers.» Um 304 que envia um corpo viola a especificação, e alguns clientes podem tratá-lo incorretamente. Esta é uma regra rígida, não uma preferência de estilo.
• Ele carrega os mesmos metadados que um 200 carregaria. O servidor “MUST generate any of the following header fields that would have been sent in a 200 (OK) response to the same request: Content-Location, Date, ETag, and Vary,” (tradução) «DEVE gerar todos os seguintes campos de cabeçalho que teriam sido enviados em uma resposta 200 (OK) à mesma solicitação: Content-Location, Date, ETag e Vary», além de Cache-Control e Expires quando aplicável. Assim, um 304 contém os cabeçalhos do 200 sem a carga útil.

Como 304 realmente funciona: solicitações condicionais

Um servidor nunca envia um 304 do nada. Ele sempre é uma resposta a uma solicitação condicional — uma solicitação que o cliente torna condicional anexando um validador salvo de uma resposta anterior. Existem dois validadores.

ETag e If-None-Match

Uma ETag (entity tag) é um token opaco que o servidor anexa a uma resposta 200 — pense nele como uma impressão digital de versão daquela representação exata da URL. Na próxima solicitação para essa URL, o cliente envia o valor salvo de volta em um cabeçalho If-None-Match. O servidor compara: se a ETag atual ainda corresponder, nada mudou, então ele retorna 304; se for diferente, retorna um 200 novo com o conteúdo atualizado e uma nova ETag.

Last-Modified e If-Modified-Since

A alternativa baseada em data: o servidor envia um registro de data e hora Last-Modified no 200. Na próxima vez, o cliente o envia de volta em um cabeçalho If-Modified-Since, e o servidor compara as datas — se o recurso não mudou desde aquele momento, é um 304. Isso é mais simples, mas mais grosseiro (tão granular quanto o registro de data e hora) e sensível à formatação exata da data HTTP, uma fonte comum de bugs. Quando os dois validadores estão presentes, If-None-Match (a ETag) tem precedência sobre If-Modified-Since.

ETags fortes versus fracas

Uma ETag pode ser forte ou fraca, e a diferença importa. Segundo a orientação da MDN sobre solicitações condicionais, “strong validation consists of guaranteeing that the resource is, byte to byte, identical to the one it is compared to.” (tradução) «a validação forte consiste em garantir que o recurso é idêntico, byte a byte, àquele com o qual é comparado.» Uma ETag fraca recebe o prefixo W/ (por exemplo, ETag: W/"abc123") e afirma apenas uma equivalência semântica — o exemplo da MDN é que “a page that would differ from another only by a different date in its footer, or different advertising, would be considered identical to the other with weak validation.” (tradução) «uma página que diferisse de outra apenas por uma data diferente no rodapé ou por publicidade diferente seria considerada idêntica à outra com validação fraca.» ETags fortes (sem prefixo) são necessárias para coisas como solicitações de intervalo que exigem correspondência exata de bytes; ETags fracas são úteis quando compactação, espaços em branco ou diferenças triviais não substanciais não deveriam forçar uma nova busca completa. A armadilha prática: se sua ETag muda sempre que o conteúdo é recomprimido com gzip/Brotli, ou varia entre servidores balanceados, você provocará novos rastreamentos desnecessários — escolha forte ou fraca deliberadamente e mantenha o valor estável para conteúdo genuinamente inalterado.

O handshake completo, passo a passo

1. Primeira solicitação → o servidor retorna 200 OK com o conteúdo, além de ETag e/ou Last-Modified.
2. O cliente armazena o conteúdo e esses validadores.
3. Próxima solicitação → o cliente envia If-None-Match e/ou If-Modified-Since com os valores armazenados.
4. O servidor decide: inalterado → 304 Not Modified, sem corpo; o cliente reutiliza o cache; alterado → 200 OK com o novo corpo e validadores recentes. Evidence for this claim RFC 9111 defines validation as checking whether a stored response remains current, typically with a conditional request that can receive 304 Not Modified. Scope: HTTP cache validation; it does not create a Search ranking benefit. Confidence: high · Verified: 2026-07-14 IETF: RFC 9111 §4.3 — Validation

Se você quer o tratamento mais profundo de cache e validadores como alavanca de eficiência de rastreamento — toda a história das solicitações condicionais e sua relação com o orçamento de rastreamento — esse é um tema complementar; este artigo é a visão focada no código de status.

304 e SEO: nenhum efeito no ranking, efeito real na eficiência do rastreamento

Essa é toda a história de SEO, e ela é mais limitada do que muitos textos genéricos de blog sugerem. 304 não tem efeito direto no ranking, e a orientação do próprio Google sobre como códigos de status afetam rastreamento e indexação também limita o efeito sobre a indexação: a Busca ainda pode recalcular os sinais de uma URL, mas, fora isso, um 304 não muda como a página é indexada. O Google já tem o conteúdo do rastreamento anterior; um 304 apenas confirma que nada mudou, então ele continua usando o que possui. Não existe bônus de ranking por retornar 304s.

O que 304 realmente oferece é economia de recursos que pode melhorar indiretamente a eficiência do rastreamento. Na publicação da Central da Pesquisa Google de dezembro de 2024 sobre cache HTTP, Gary Illyes explicou de forma direta: “Especially if you have a large site with rarely-changing content under individual URLs, allowing caching locally may help your site be crawled more efficiently. Google’s crawling infrastructure supports heuristic HTTP caching as defined by the HTTP caching standard, specifically through the ETag response- and If-None-Match request header, and the Last-Modified response- and If-Modified-Since request header.” (tradução) «Especialmente se você tem um site grande com conteúdo que muda raramente em URLs individuais, permitir o cache local pode ajudar seu site a ser rastreado com mais eficiência. A infraestrutura de rastreamento do Google aceita o cache HTTP heurístico definido pelo padrão de cache HTTP, especificamente por meio do cabeçalho de resposta ETag e do cabeçalho de solicitação If-None-Match, e do cabeçalho de resposta Last-Modified e do cabeçalho de solicitação If-Modified-Since.»

Sobre o mecanismo exato do 304, a mesma publicação é explícita sobre por que o corpo vazio é o ponto: se a ETag enviada pelo rastreador “matches the current value the server generated, your server should return an HTTP 304 (Not modified) status code with no HTTP body,” (tradução) «corresponder ao valor atual gerado pelo servidor, seu servidor deve retornar um código de status HTTP 304 (Not modified) sem corpo HTTP»; e a parte “no HTTP body” importa porque “your server doesn’t have to spend compute resources on actually generating content” (tradução) «seu servidor não precisa gastar recursos computacionais para realmente gerar conteúdo» e “doesn’t have to transfer the HTTP body” (tradução) «não precisa transferir o corpo HTTP» — você economiza computação e largura de banda nos dois lados. A formulação do Google para o benefício posterior é condicional: essa economia de recursos pode melhorar indiretamente a eficiência do rastreamento. Não é uma promessa de que o esforço economizado será realocado automaticamente para suas URLs novas ou atualizadas — trate-o como um mecanismo de economia de recursos com um benefício secundário plausível, não garantido.

Por que isso importa mais em sites grandes

Se você tem algumas centenas de páginas, isso é em grande parte acadêmico — o Google rastreará seu site inteiro confortavelmente de qualquer maneira. O retorno cresce com o tamanho: um site com centenas de milhares ou milhões de URLs, muitas delas raramente alteradas, se beneficia de forma concreta quando os rastreadores podem evitar buscar novamente todas as que não mudaram. Esse é o público da publicação do Google, e essa é a forma honesta de apresentar o assunto — não venda 304 como uma tática para sites pequenos.

ETag ou Last-Modified, e o que conta como “mudado”

O Google recomenda ETag como validador principal: “We strongly recommend using ETag because it’s less prone to errors and mistakes (the value is not structured unlike the Last-Modified value).” (tradução) «Recomendamos fortemente usar ETag porque ela é menos propensa a erros e enganos (o valor não é estruturado, ao contrário do valor Last-Modified).» Definir os dois é aceitável e incentivado. Se você usar Last-Modified, a data “must be formatted according to the HTTP standard” (tradução) «deve ser formatada de acordo com o padrão HTTP» — o Google recomenda o formato “Weekday, DD Mon YYYY HH:MM:SS Timezone,” (tradução) «Dia da semana, DD Mon AAAA HH:MM:SS Fuso horário», por exemplo, “Fri, 4 Sep 1998 19:15:56 GMT” — ou ela pode ser ignorada silenciosamente. O Google também sugere definir o campo max-age de Cache-Control para ajudar os rastreadores a decidir quando rastrear novamente.

O que conta como uma mudança que merece invalidar o cache fica a seu critério, e o conselho do Google é reservá-la para mudanças substanciais: “Our recommendation is that you require a cache refresh on significant changes to your content; if you only updated the copyright date at the bottom of your page, that’s probably not significant.” (tradução) «Nossa recomendação é que você exija uma atualização do cache em mudanças significativas no seu conteúdo; se você apenas atualizou a data de copyright no rodapé da página, isso provavelmente não é significativo.»

O que Googlebot e Bingbot realmente fazem com isso

Nem toda solicitação de rastreador é condicional. A documentação de rastreamento do Google observa que o suporte a cache varia entre rastreadores e buscadores individuais conforme o produto atendido — o Googlebot aceita cache ao rastrear URLs novamente para a Busca, enquanto alguns outros buscadores do Google só o aceitam em determinadas condições — portanto, mesmo com os cabeçalhos configurados corretamente, não espere que 100% das solicitações carreguem If-None-Match/If-Modified-Since. No Bing, as solicitações condicionais não são um recurso exclusivo do Google. O rastreador do Bing aceita GET condicional (enviando If-Modified-Since e, quando disponível, If-None-Match, e aceitando um 304 quando o conteúdo não mudou) desde pelo menos uma publicação do Live Search de 2008 — embora o Bing não tenha publicado um equivalente moderno ao texto do Google de 2024. Trate a mecânica como comportamento HTTP genérico que se aplica aos dois mecanismos.

Como implementar o suporte a 304

1. Envie validadores no 200. Configure seu servidor, CDN ou aplicativo para anexar uma ETag (recomendada) e/ou um cabeçalho Last-Modified formatado corretamente às respostas 200 normais. Muitos servidores e frameworks geram ETags automaticamente para arquivos estáticos; respostas dinâmicas geralmente exigem ativação explícita.
2. Respeite os cabeçalhos condicionais na volta. Quando uma solicitação chega com If-None-Match/If-Modified-Since, compare com o validador atual e retorne 304 (sem corpo) quando ele ainda corresponder, ou um 200 novo quando não corresponder. Novamente, servidores de arquivos estáticos costumam cuidar disso; rotas de aplicativo e workers de edge frequentemente não o fazem sem configuração.
3. Decida o que significa “mudou” e mantenha a ETag estável para conteúdo genuinamente inalterado — não permita que recompressão ou variação por servidor a altere sem necessidade.
4. Observe as configurações incorretas clássicas:
   • Sempre-200 — nunca emitir validadores, de modo que nenhuma solicitação seja condicional e você nunca obtenha o benefício de eficiência.
   • ETags instáveis — um valor que muda mesmo quando o conteúdo não muda (balanceadores de carga, recompressão), forçando novas buscas constantes.
   • 304s obsoletos — o caso perigoso: um servidor que continua retornando 304 (ou uma ETag inalterada) depois de o conteúdo ter mudado, de modo que rastreadores e caches nunca recebem a atualização. Isso é um bug a ser detectado na análise de logs, não uma falha inerente ao 304.

304 versus outros códigos de status

304 versus 301 / 302 / 307 / 308

Esses são os redirecionamentos de verdade. Um 301/308 (permanente) ou 302/307 (temporário) carrega um cabeçalho Location e move o cliente para uma URL diferente — e 301/308 também passam um sinal de canonicalização. Um 304 não tem Location, não move ninguém e não passa sinal de ranking. Mesma família 3xx pela numeração, função completamente diferente. Os detalhes de cada redirecionamento estão nos próprios artigos (veja o artigo sobre redirecionamento 301 e o sub-hub de redirecionamentos).

304 versus 204 No Content

Ambos não têm corpo, por razões completamente diferentes. Um 204 No Content é um sucesso 2xx com corpo intencionalmente vazio porque o servidor genuinamente não tem nada a enviar — um DELETE/PUT de API bem-sucedido, um beacon de analytics. Um 304 também não envia corpo, mas não porque não haja nada a enviar; é porque “você já tem isto e ele ainda é válido”. Não os confunda: um 204 em uma URL de página pode ser tratado como um soft 404 porque não há conteúdo indexável, enquanto um 304 é uma confirmação de validade para conteúdo que o Google já possui. O artigo sobre 204 No Content aborda esse código em detalhes.

Mitos comuns sobre 304

1. “304 is a redirect.” (tradução) «304 é um redirecionamento.» Não há cabeçalho Location e ninguém vai a lugar algum. O cliente reutiliza sua própria cópia em cache. O “redirecting the client to make use of that stored representation” (tradução) «redirecionar o cliente para usar aquela representação armazenada» da RFC 9110 significa apontar de volta para o cache, não para outra URL.
2. “304 is an error I need to fix.” (tradução) «304 é um erro que preciso corrigir.» É o resultado correto e esperado de uma configuração funcional de solicitação condicional. Ver 304s em um rastreamento ou no DevTools é sinal de que o cache está funcionando — o equívoco mais comum na SERP.
3. “304 helps rankings.” (tradução) «304 ajuda os rankings.» Não há efeito direto no ranking, e o Google também limita o efeito sobre a indexação — a Busca pode recalcular os sinais de uma URL, mas, fora isso, um 304 não altera a indexação. O benefício é a economia de recursos que o Google diz que pode melhorar indiretamente a eficiência do rastreamento em sites muito grandes, mas isso não é sinal de ranking nem garantia de que o esforço economizado será transferido para outras URLs.
4. “If my server returns 304, Google will use stale content forever.” (tradução) «Se meu servidor retornar 304, o Google usará conteúdo obsoleto para sempre.» O 304 só é emitido enquanto o validador corresponder. Assim que o conteúdo muda de fato, um servidor implementado corretamente retorna um 200 novo com validadores novos. O risco real é um servidor configurado incorretamente que continua retornando 304 depois que o conteúdo mudou — um bug, não uma propriedade do 304. Evidence for this claim RFC 9111 defines validation as checking whether a stored response remains current, typically with a conditional request that can receive 304 Not Modified. Scope: HTTP cache validation; it does not create a Search ranking benefit. Confidence: high · Verified: 2026-07-14 IETF: RFC 9111 §4.3 — Validation
5. “ETag and Last-Modified are interchangeable.” (tradução) «ETag e Last-Modified são intercambiáveis.» Ambos são validadores, mas Last-Modified depende do formato da data e tem apenas a granularidade do seu registro de data e hora, enquanto ETag é opaca e precisa (e pode variar de forma problemática entre servidores ou após recompressão, se implementada sem cuidado). O Google recomenda ETag como principal; usar os dois é possível.

Perguntas frequentes

HTTP 304 é um erro? Não — é um sinal de sucesso de que o cache está funcionando. Isso significa que a cópia em cache do cliente ainda é válida.

304 Not Modified é um redirecionamento? Não. Ele está na classe 3xx pela numeração, mas não tem cabeçalho Location e não move o cliente para uma nova URL.

304 ajuda o SEO ou os rankings? Não há efeito direto no ranking nem efeito sobre a indexação além de o Google possivelmente recalcular os sinais de uma URL. Ele economiza largura de banda e computação ao permitir que rastreadores ignorem páginas inalteradas, algo que o Google diz que pode melhorar indiretamente a eficiência do rastreamento em sites grandes.

Qual é a diferença entre ETag e Last-Modified? ETag é uma impressão digital de versão opaca comparada por meio de If-None-Match; Last-Modified é um registro de data e hora comparado por meio de If-Modified-Since. O Google recomenda ETag por ser menos propensa a erros.

O que é uma ETag fraca versus forte? Uma ETag forte afirma que o conteúdo é idêntico byte a byte; uma ETag fraca (com o prefixo W/) afirma equivalência semântica, tolerando diferenças triviais como compactação ou uma data de rodapé alterada.

Por que vejo 304s nos meus logs ou relatórios de rastreamento? Porque os clientes estão fazendo solicitações condicionais e seu servidor está confirmando corretamente que o conteúdo não mudou. Isso é esperado e bom.

Como faço meu servidor retornar 304 corretamente? Envie ETag/Last-Modified no 200; depois respeite If-None-Match/If-Modified-Since na próxima solicitação, retornando 304 sem corpo quando o validador ainda corresponder.

Qual é a diferença entre 304 e 204? Ambos não têm corpo; 204 porque não há nada a enviar, e 304 porque você já tem uma cópia que continua válida.

O Googlebot envia cabeçalhos condicionais em todas as solicitações? Não — o suporte a cache varia conforme o rastreador, portanto nem toda solicitação será condicional mesmo com os cabeçalhos configurados.

Uma resposta 304 pode ter corpo? Não. De acordo com a RFC 9110, “it cannot contain content or trailers.” (tradução) «ela não pode conter conteúdo nem trailers.» Um 304 com corpo viola a especificação.

Resumo de IA

Uma versão condensada da versão Advanced:

• 304 Not Modified é a resposta a um GET/HEAD condicional cuja condição resulta falsa e que, de outra forma, teria recebido um 200 (RFC 9110 §15.4.5). Ele está na classe 3xx, mas NÃO é um redirecionamento: não tem cabeçalho Location, nova URL nem — normativamente — corpo: “it cannot contain content or trailers.” (tradução) «não pode conter conteúdo nem trailers.» Uma segunda visita é o exemplo típico de como uma solicitação se torna condicional, não a regra do protocolo.
• Ele é a resposta a uma solicitação condicional. Um GET/HEAD que carrega If-None-Match (comparado a uma ETag) e/ou If-Modified-Since (comparado a Last-Modified). Se o validador ainda corresponder, o servidor retorna 304 e o cliente reutiliza sua cópia em cache.
• A palavra “redirecting” da especificação é metafórica — ela aponta o cliente de volta ao próprio cache, não a outra URL. Essa frase causa a maior parte da confusão sobre se 304 é um redirecionamento.
• ETag versus Last-Modified: ETag é um token de versão opaco (comparado por If-None-Match); Last-Modified é uma data (comparada por If-Modified-Since, com formatação exata de data HTTP obrigatória). If-None-Match tem precedência quando os dois estão presentes. ETag forte = idêntica byte a byte; ETag fraca (prefixo W/) = equivalência semântica.
• Nenhum efeito direto no ranking, e nenhum efeito sobre a indexação além de o Google possivelmente recalcular os sinais de uma URL. O Google já tem o conteúdo; 304 apenas confirma que nada mudou. Como Gary Illyes formulou, o cache “may help your site be crawled more efficiently” (tradução) «pode ajudar seu site a ser rastreado com mais eficiência» — o benefício é economia de recursos que pode melhorar indiretamente a eficiência do rastreamento em sites grandes, não uma realocação garantida do orçamento de rastreamento nem um sinal de ranking.
• O Google recomenda ETag como principal (“less prone to errors and mistakes” (tradução) «menos propensa a erros e enganos»), e não há problema em definir os dois; Last-Modified deve usar o formato “Weekday, DD Mon YYYY HH:MM:SS Timezone” (tradução) «Dia da semana, DD Mon AAAA HH:MM:SS Fuso horário»; invalide o cache somente em mudanças significativas (não uma data de copyright no rodapé).
• O suporte a cache varia por rastreador — nem toda solicitação do Googlebot é condicional. O Bing aceita GET condicional desde uma publicação do Live Search de 2008; é comportamento HTTP genérico.
• Não confunda com 301/302/307/308 (redirecionamentos reais que movem a URL) nem com 204 No Content (também sem corpo, mas porque genuinamente não há nada a enviar).
• O risco real não é o 304 em si, mas um servidor configurado incorretamente que retorna 304 depois que o conteúdo mudou — detecte isso na análise de logs. Um 304 válido também pode parecer um erro em algumas bibliotecas de cliente ou camadas de cache da plataforma mesmo quando nada está errado.

Documentação oficial

Referências de fontes primárias sobre o que é 304 e como os mecanismos de busca o utilizam.

Especificação HTTP e referência do navegador

• RFC 9110 §15.4.5 — 304 — Não modificado — a definição oficial: solicitação condicional, ausência de corpo e cabeçalhos obrigatórios.
• MDN — 304 — Não modificado — explicação em linguagem simples, o gatilho If-None-Match/If-Modified-Since e a lista de cabeçalhos que um 304 deve carregar.
• MDN — solicitações HTTP condicionais — explicação sobre validação forte e fraca.
• MDN — ETag — o cabeçalho ETag, incluindo a sintaxe fraca (W/) e forte.

Central da Pesquisa Google

• Dezembro do rastreamento: cache HTTP — publicação de Gary Illyes de 9 de dezembro de 2024: como ETag/If-None-Match e Last-Modified/If-Modified-Since geram 304s e por que ajudam a eficiência do rastreamento.
• Visão geral dos rastreadores do Google (user agent) — quais rastreadores do Google aceitam cache e a recomendação de ETag em vez de Last-Modified.
• Como os códigos de status HTTP afetam os rastreadores do Google — a linha atual do Google sobre 304, incluindo a ressalva de que a Busca pode recalcular os sinais de uma URL embora o 304 não tenha outro efeito sobre a indexação.
• Solucionar erros de rastreamento da Pesquisa Google — a fonte da formulação condicional do Google de que a economia de recursos de solicitações condicionais “may indirectly” (tradução) «pode melhorar indiretamente» a eficiência do rastreamento e de que o Google não envia cabeçalhos condicionais em todas as tentativas de rastreamento.

Bing

• Anúncio de melhorias no rastreamento do Live Search — a antiga publicação do Bing/Live Search que confirma suporte a GET condicional (If-Modified-Since/If-None-Match → 304) desde 2008.

Citações da fonte

Declarações registradas. Cada link é um link profundo que salta para o trecho citado na página de origem onde a fonte dá suporte a ele.

A especificação HTTP

• “The 304 (Not Modified) status code indicates that a conditional GET or HEAD request has been received and would have resulted in a 200 (OK) response if it were not for the fact that the condition evaluated to false.” (tradução) «O código de status 304 (não modificado) indica que uma solicitação GET ou HEAD condicional foi recebida e teria resultado em uma resposta 200 (OK) se não fosse pelo fato de a condição ter sido avaliada como falsa.» — RFC 9110, HTTP Semantics, §15.4.5. Leia a seção
• “A 304 response is terminated by the end of the header section; it cannot contain content or trailers.” (tradução) «Uma resposta 304 termina no fim da seção de cabeçalhos; não pode conter conteúdo nem trailers.» — RFC 9110, §15.4.5 (a regra normativa de “nunca há corpo”). Leia a seção

MDN Web Docs

• “The HTTP 304 Not Modified redirection response status code indicates that there is no need to retransmit the requested resources.” (tradução) «O código de status de resposta de redirecionamento HTTP 304 — não modificado — indica que não há necessidade de retransmitir os recursos solicitados.» Ir para a citação
• “Strong validation consists of guaranteeing that the resource is, byte to byte, identical to the one it is compared to.” (tradução) «A validação forte consiste em garantir que o recurso é idêntico, byte a byte, àquele com o qual é comparado.» — MDN, “HTTP conditional requests”. Leia o guia

Gary Illyes, Google — “Crawling December: HTTP caching” (9 de dezembro de 2024)

• “Especially if you have a large site with rarely-changing content under individual URLs, allowing caching locally may help your site be crawled more efficiently. Google’s crawling infrastructure supports heuristic HTTP caching as defined by the HTTP caching standard, specifically through the ETag response- and If-None-Match request header, and the Last-Modified response- and If-Modified-Since request header.” (tradução) «Especialmente se o site for grande e tiver conteúdo que muda raramente em URLs individuais, permitir o cache local pode ajudar a rastreá-lo com mais eficiência. A infraestrutura de rastreamento do Google aceita o cache HTTP heurístico definido pelo padrão de cache HTTP, especificamente pelos cabeçalhos ETag/If-None-Match e Last-Modified/If-Modified-Since.» Leia a publicação
• “We strongly recommend using ETag because it’s less prone to errors and mistakes (the value is not structured unlike the Last-Modified value).” (tradução) «Recomendamos fortemente usar ETag porque ela é menos propensa a erros e enganos (o valor não é estruturado, ao contrário do valor Last-Modified).» Leia a publicação
• “If the ETag value sent by the crawler matches the current value the server generated, your server should return an HTTP 304 (Not modified) status code with no HTTP body.” (tradução) «Se o valor ETag enviado pelo rastreador corresponder ao valor atual gerado pelo servidor, seu servidor deve retornar um código de status HTTP 304 (não modificado) sem corpo HTTP.» Leia a publicação
• “Our recommendation is that you require a cache refresh on significant changes to your content; if you only updated the copyright date at the bottom of your page, that’s probably not significant.” (tradução) «Nossa recomendação é que você exija uma atualização do cache em mudanças significativas no seu conteúdo; se você apenas atualizou a data de copyright no rodapé da página, isso provavelmente não é significativo.» Leia a publicação

Patrick Stox — guia da Ahrefs

• “304 Not Modified – Says the page hasn’t been modified. Typically used for caching.” (tradução) «304 Not Modified — diz que a página não foi modificada. Normalmente usado para cache.» — do meu guia Códigos de status HTTP e seu impacto em SEO (este artigo é o aprofundamento que aquela entrada nunca recebeu). Ir para a citação

304 em contexto: os códigos sem corpo e 3xx com os quais ele é confundido

304 versus seus semelhantes

A armadilha: 304 e 204 não têm corpo, e 304/301/302/307/308 são todos 3xx — mas 304 é a exceção nos dois eixos. É o único 3xx que não move ninguém e o único código sem corpo que significa “você já tem isto”, em vez de “não há nada a enviar”.

Os dois validadores

Quando os dois estão presentes, If-None-Match tem precedência sobre If-Modified-Since.

Fatos rápidos

• 304 nunca tem corpo — a RFC 9110 torna isso normativo.
• 304 é um código 3xx, mas não é um redirecionamento (sem Location, sem nova URL).
• Nenhum efeito direto no ranking, e nenhum efeito sobre a indexação além de o Google possivelmente recalcular os sinais de uma URL — o benefício é a economia de recursos que pode melhorar indiretamente a eficiência do rastreamento em sites grandes.
• O Google recomenda ETag como principal; definir ETag e Last-Modified é aceitável.
• Last-Modified deve usar “Weekday, DD Mon YYYY HH:MM:SS Timezone” (tradução) «Dia da semana, DD Mon AAAA HH:MM:SS Fuso horário» ou pode ser ignorado.
• Invalide o cache em mudanças de conteúdo significativas, não em uma data de copyright no rodapé.
• Nem toda solicitação de rastreador é condicional — o suporte a cache varia conforme o rastreador.
• O Bing aceita GET condicional → 304 desde 2008; é HTTP genérico.
• O risco real é um 304 obsoleto (o servidor retorna 304 depois que o conteúdo mudou) — detecte-o na análise de logs.

O handshake de solicitação condicional, em HTTP bruto

Cadeias concretas de solicitação/resposta que mostram como um 304 surge. (Os valores dos cabeçalhos são ilustrativos.)

ETag / If-None-Match — a primeira busca (200)

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

HTTP/1.1 200 OK
Content-Type: text/html
ETag: "a1b2c3d4"
Cache-Control: max-age=3600

<full page body here>

O cliente armazena o corpo e o valor da ETag.

ETag / If-None-Match — a próxima busca, conteúdo inalterado (304)

GET /blog/my-article/ HTTP/1.1
Host: example.com
If-None-Match: "a1b2c3d4"

HTTP/1.1 304 Not Modified
ETag: "a1b2c3d4"
Cache-Control: max-age=3600

Sem corpo. A ETag correspondeu, então o servidor economizou a computação de gerar a página e a largura de banda de enviá-la. O cliente reutiliza sua cópia em cache.

Last-Modified / If-Modified-Since — o equivalente baseado em data

GET /blog/my-article/ HTTP/1.1
Host: example.com
If-Modified-Since: Fri, 4 Sep 1998 19:15:56 GMT

HTTP/1.1 304 Not Modified
Last-Modified: Fri, 4 Sep 1998 19:15:56 GMT

Observe o formato exato da data HTTP — “Weekday, DD Mon YYYY HH:MM:SS Timezone” — que o Google recomenda para evitar problemas de análise.

Quando o conteúdo MUDOU — um 200 novo, não um 304

GET /blog/my-article/ HTTP/1.1
Host: example.com
If-None-Match: "a1b2c3d4"

HTTP/1.1 200 OK
Content-Type: text/html
ETag: "e5f6g7h8"          ← new value: content changed

<updated page body here>

A ETag armazenada não corresponde mais, então o servidor envia o novo conteúdo e um novo validador. O cache é atualizado. É exatamente por isso que um 304 implementado corretamente não pode “prender” um rastreador em conteúdo obsoleto — no momento em que o conteúdo muda, o validador muda e a próxima solicitação recebe um 200 real.

ETag fraca versus forte

ETag: "a1b2c3d4"      ← strong: asserts byte-for-byte identity
ETag: W/"a1b2c3d4"    ← weak: asserts semantic equivalence (the W/ prefix)

Regra prática: se você administra um site grande com muitas URLs que mudam raramente, enviar uma ETag estável (e respeitar If-None-Match) nos seus 200 permite que os rastreadores confirmem “continua igual” com um 304 barato e sem corpo — economizando largura de banda e computação que, segundo o Google, podem melhorar indiretamente a eficiência com que o restante do site é rastreado. Se sua ETag muda a cada recompressão ou entre servidores balanceados, você perde esse benefício.

Erros de 304 que quebram o cache condicional

Alterar a ETag quando a representação não mudou

Uma ETag vinculada à instância do servidor, à etapa de compactação ou ao registro de data e hora da solicitação derrota o validador: conteúdo inalterado continua retornando um 200 completo. Gere um validador estável a partir da representação ou use deliberadamente uma ETag fraca quando diferenças no nível dos bytes não forem significativas.

Retornar 304 depois que o conteúdo mudou

Um validador obsoleto pode esconder uma atualização real de clientes e rastreadores. Invalide a ETag ou avance Last-Modified sempre que a representação mudar; depois confirme que a solicitação condicional antiga recebe um 200 novo com corpo.

Enviar 304 sem uma solicitação condicional correspondente

Um servidor não deve presumir que o cliente tem uma cópia em cache. Retorne 304 somente depois de avaliar If-None-Match ou If-Modified-Since; uma primeira solicitação comum precisa de uma resposta completa.

Tratar 304 como redirecionamento ou página vazia

Um 304 não tem cabeçalho Location nem corpo de resposta. Não o encaminhe pela lógica de redirecionamento e não substitua um recurso realmente vazio por 304; use o status que descreve a resposta real.

Problemas comuns de 304

O servidor sempre retorna 200

Sintoma: solicitações repetidas baixam o corpo completo mesmo quando nada mudou. Causa provável: a resposta inicial não tem validador ou o aplicativo ignora os cabeçalhos de solicitação condicional. Correção: envie ETag e/ou um Last-Modified válido; depois implemente a verificação correspondente de If-None-Match ou If-Modified-Since. Confirme que uma solicitação inalterada retorna 304 sem corpo.

Servidores de origem diferentes produzem ETags diferentes

Sintoma: a mesma URL inalterada alterna entre 200 e 304 atrás de um balanceador de carga. Causa provável: cada nó gera seu próprio validador. Correção: derive a ETag do estado compartilhado do conteúdo, não do nó que atende a solicitação, e repita a mesma solicitação condicional contra várias respostas.

Conteúdo atualizado ainda retorna 304

Sintoma: um navegador ou rastreador mantém uma representação antiga depois de uma implantação. Causa provável: o validador não foi invalidado junto com o conteúdo. Correção: ajuste a chave de cache ou a lógica de implantação, elimine o cache afetado quando necessário e prove que a ETag antiga agora recebe um 200 com um validador novo.

Last-Modified parece ser ignorado

Sintoma: If-Modified-Since nunca produz um 304. Causa provável: data HTTP inválida, precisão insuficiente do registro de data e hora ou uma ETag tendo precedência. Correção: inspecione os cabeçalhos brutos, corrija o formato da data e teste cada validador separadamente.

Um 304 parece um erro no código do aplicativo

Sintoma: um script ou aplicativo lança uma exceção ou registra um “erro” em uma solicitação que, na verdade, recebeu um 304. Causa provável: algumas bibliotecas de cliente HTTP tratam qualquer status diferente de 200 — inclusive um 304 válido — como uma condição semelhante a exceção, a menos que você as configure explicitamente para seguir redirecionamentos ou aceitar respostas not-modified; isso é uma peculiaridade da biblioteca cliente, não um problema do protocolo ou do servidor. Correção: verifique especificamente como a biblioteca cliente trata 304 (não apenas como trata erros 4xx/5xx) e confirme que a resposta HTTP bruta é um 304 correto e sem corpo antes de presumir que o servidor é o culpado.

Uma camada de cache da plataforma (por exemplo, o cache de saída do IIS) confunde o diagnóstico

Sintoma: o aplicativo de origem parece correto, mas o comportamento de 304 ainda parece errado. Causa provável: uma camada de cache específica da plataforma de hospedagem — o cache de saída do IIS é um exemplo documentado — está entre o aplicativo e o cliente e pode gerar ou interceptar respostas 304 por conta própria. Correção: trate-a como uma possível camada entre várias (aplicativo de origem, CDN, balanceador de carga, cache da plataforma), não como a suspeita padrão; isole-a com um teste controlado que altere o validador em cada camada, uma de cada vez, antes de concluir qual camada é responsável.

Prompt: auditar um rastreamento de solicitação condicional

Cole os cabeçalhos de solicitação e resposta de uma busca inicial e de uma busca repetida.

Act as an HTTP caching reviewer. I will paste two request/response header traces for
the same URL: an initial fetch and a conditional repeat. Identify the validator used,
check whether If-None-Match or If-Modified-Since was evaluated correctly, verify that
a 304 has no body or Location header, and flag unstable or stale-validator risks.
Return: observed flow, pass/fail checks, likely cause of each failure, and the exact
next request I should run. Do not infer headers that are not present.

[PASTE BOTH TRACES]

Prompt: revisar uma implementação de ETag

Cole a configuração relevante do aplicativo, CDN ou servidor.

Review this ETag/Last-Modified implementation for conditional GET correctness. Trace
the 200 -> conditional request -> 304 path, explain what causes the validator to
change, and test mentally for multiple origin nodes, compression variants, and real
content updates. Separate protocol violations from efficiency issues. Give a minimal
fix and a curl-based validation plan. Do not invent platform behavior.

[PASTE CONFIGURATION OR CODE]

Shell: repetir uma ETag como solicitação condicional

Execute isto em um terminal macOS/Linux. Copie a ETag exatamente, incluindo as aspas.

URL='https://example.com/page'
curl -sS -D - -o /dev/null "$URL"
curl -sS -D - -o /dev/null -H 'If-None-Match: "PASTE_ETAG_HERE"' "$URL"

A primeira resposta deve expor o validador. A segunda deve retornar 304 quando a representação não tiver mudado e 200 quando a ETag colada estiver obsoleta.

PowerShell: testar Last-Modified

Execute no PowerShell depois de substituir a URL e o registro de data e hora.

$url = 'https://example.com/page'
$headers = @{ 'If-Modified-Since' = 'Tue, 14 Jul 2026 12:00:00 GMT' }
Invoke-WebRequest -Uri $url -Headers $headers -SkipHttpErrorCheck

Console do DevTools: listar validadores dos recursos da página

Execute no Console do navegador. Ele informa entradas de tempo dos recursos; use o painel Network para inspecionar os cabeçalhos reais ETag, Last-Modified e de status.

console.table(performance.getEntriesByType('resource').map(r => ({name: r.name, transferSize: r.transferSize, encodedBodySize: r.encodedBodySize})));

Ferramentas para inspecionar o comportamento de 304

• HTTP Header Checker: inspecione ETag, Last-Modified, Cache-Control, Vary e as impressões digitais da CDN/edge na resposta normal antes de repetir um validador.
• Painel Network do DevTools do navegador: desative “Disable cache”, recarregue e compare os cabeçalhos da solicitação/resposta. O DevTools também torna visíveis o HSTS e o comportamento do cache local; portanto, diferencie o comportamento do navegador do que a origem enviou.
• curl: envie um cabeçalho If-None-Match ou If-Modified-Since exato sem que o estado de cache do navegador interfira.
• Logs de acesso: quantifique quais solicitações de rastreadores foram condicionais e se terminaram em 304 ou em um 200 completo.

Prove que as respostas condicionais funcionam depois de uma mudança

Teste de representação inalterada

Teste a executar: busque a URL, copie sua ETag e repita com curl -I -H 'If-None-Match: "VALUE"' URL. Resultado esperado: 304, o validador correspondente e nenhum corpo ou Location. Interpretação da falha: o servidor ignorou a condição ou gerou um validador instável. Janela de monitoramento: imediata. Gatilho de rollback: a mudança de cache faz solicitações comuns perderem sua resposta 200 completa.

Teste de representação alterada

Teste a executar: implante uma mudança real de conteúdo e depois repita a ETag antiga. Resultado esperado: 200 com o corpo atualizado e um validador novo. Interpretação da falha: a invalidação do cache está obsoleta. Janela de monitoramento: imediatamente depois que a implantação chegar a cada origem. Gatilho de rollback: qualquer origem ainda retorna 304 para o validador antigo depois que a implantação foi concluída.

Teste de estabilidade entre várias origens

Teste a executar: repita as mesmas solicitações normais e condicionais vezes suficientes para alcançar o pool de atendimento, registrando a ETag e o status. Resultado esperado: representações inalteradas usam validadores compatíveis e produzem 304 de forma consistente. Interpretação da falha: os validadores variam por nó ou codificação sem uma estratégia Vary correspondente. Janela de monitoramento: imediata, em todo o pool implantado. Gatilho de rollback: a nova lógica de validadores entrega conteúdo obsoleto ou mistura representações entre clientes.

Medir a saúde do cache condicional

Taxa de sucesso da revalidação condicional

Métrica: solicitações condicionais que terminam em 304 versus um 200 completo. O que ela informa: se recursos inalterados evitam transferências desnecessárias. Como obtê-la: agrupe por status de resposta e classe de URL as solicitações dos logs de acesso que carregam If-None-Match ou If-Modified-Since. Benchmark / faixa realista: estabeleça uma linha de base por tipo de conteúdo; páginas que mudam com frequência não devem ser forçadas à taxa de ativos estáticos. Cadência: semanal durante a implantação, depois mensal.

Bytes evitados em buscas inalteradas

Métrica: bytes estimados do corpo da resposta que não foram transferidos em respostas 304 válidas. O que ela informa: o lado da largura de banda do benefício de eficiência do rastreamento. Como obtê-la: combine as contagens de logs de 304 com o tamanho mais recente de uma resposta completa para a mesma classe de URL. Benchmark / faixa realista: compare com a linha de base do próprio site antes da mudança; nenhum alvo universal serve para toda mistura de conteúdo. Cadência: mensal.

Falhas de validador obsoleto

Métrica: URLs alteradas que ainda aceitam um validador antigo. O que ela informa: se a eficiência está sendo obtida à custa da atualidade. Como obtê-la: execute uma pequena amostra pós-implantação que repita as ETags anteriores à implantação. Benchmark / faixa realista: qualquer resposta obsoleta confirmada exige investigação. Cadência: a cada implantação que altere o cache ou a geração de validadores.

Teste seus conhecimentos: 304 Not Modified

Cinco perguntas rápidas sobre o significado e o funcionamento de um 304. Escolha uma resposta para cada uma e depois confira.

Registro de alterações