304 Not Modified: qué es y cómo funciona

TL;DR — Una respuesta 304 Not Modified es la forma en que el servidor dice: “ya tienes esto; tu copia sigue siendo válida, no la descargues otra vez”. No es un error y, aunque pertenece a la familia “3xx” de “redirecciones”, no envía a nadie a una URL nueva. Solo ocurre cuando el cliente (un navegador o un rastreador) envía primero una solicitud condicional preguntando “¿ha cambiado desde la última vez?”. En SEO no cambia tu posicionamiento, pero en sitios grandes puede ayudar a que los motores de búsqueda utilicen sus recursos con más eficiencia.

Qué es realmente una 304

Cada respuesta que envía tu servidor comienza con un código de estado de tres dígitos. 200 OK significa “aquí está la página, con cuerpo incluido”. Una 304 Not Modified significa algo más concreto: el cliente hizo una solicitud condicional —“dame esta página, pero solo si ha cambiado”— y el servidor determinó que no cambió. En vez del 200 que habría enviado, responde 304 sin cuerpo. Esa es la regla real: una 304 solo responde a una solicitud condicional GET/HEAD cuya condición resultó falsa.

Una segunda visita es la forma habitual de que ocurra y ayuda a imaginarlo: la primera vez que un navegador o rastreador obtiene una página recibe un 200 normal con todo el contenido, además de un par de cabeceras que actúan como “huellas”. En la siguiente visita, el cliente devuelve esa huella al servidor y pregunta “¿sigue igual?”. Si nada cambió, el servidor responde 304 sin cuerpo y el cliente reutiliza la copia que ya tenía. Pero “segunda visita” es el ejemplo, no la regla del protocolo: lo que activa una 304 es la propia solicitud condicional, sea cual sea la forma en que llegue. 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 qué pertenece a la familia de “redirecciones” pero no es una redirección

304 empieza por 3, la clase que HTTP utiliza para las redirecciones. Eso confunde constantemente. Pero una 304 no tiene cabecera Location y no te envía a otra dirección: nadie se mueve. Simplemente remite al cliente a su propia copia guardada. Por tanto, “familia de redirecciones” es una peculiaridad de numeración, no una descripción de lo que hace.

¿Una 304 es un problema?

No. Ver 304 en la pestaña de red del navegador o en un informe de rastreo indica que la caché funciona, exactamente lo que quieres. Muchos consejos sobre “error 304, cómo solucionarlo” lo tratan como si algo estuviera roto en tu sitio. No lo está: es el resultado correcto y esperado de una caché bien configurada.

¿Ayuda al SEO?

No directamente a tu posicionamiento. Google ya tiene tu contenido desde la última vez que rastreó la página; una 304 solo confirma que no cambió, así que Google sigue usando lo que ya almacenó (Search aún puede recalcular las señales de una URL, pero una 304 por sí sola no es una ventaja de posicionamiento ni de indexación). Donde sí ayuda es en la eficiencia de recursos: si un motor de búsqueda no tiene que volver a descargar páginas que no cambiaron, ahorra ancho de banda y capacidad de cálculo en ambos extremos. Google dice que eso puede mejorar indirectamente la eficiencia del rastreo, pero no garantiza que el esfuerzo ahorrado se redirija automáticamente a tus páginas nuevas o actualizadas. Importa sobre todo en sitios grandes con muchas páginas que cambian rara vez.

¿Quieres conocer la mecánica real —ETag, If-None-Match, validadores fuertes y débiles, cómo implementarlo y qué ha dicho realmente Google? Cambia a la pestaña Avanzado.

TL;DR — Una 304 es la respuesta a una solicitud condicional GET/HEAD cuya condición resulta falsa y que, de otro modo, habría recibido un 200 (RFC 9110 §15.4.5). Pertenece a la clase 3xx, pero no es una redirección: no hay Location, URL nueva ni —normativamente— cuerpo (“it cannot contain content or trailers”). La condición se transporta mediante If-None-Match (frente a un ETag) o If-Modified-Since (frente a Last-Modified); si el validador sigue coincidiendo, el servidor devuelve 304 y el cliente reutiliza su caché. Impacto SEO: ningún efecto directo en el posicionamiento —Google ya tiene el contenido, aunque Search aún puede recalcular señales— y ahorro de recursos en sitios grandes (Google dice que puede mejorar indirectamente la eficiencia del rastreo; no promete reasignar automáticamente el presupuesto de rastreo a otras URL). La infraestructura de rastreo de Google admite ambos validadores y recomienda ETag como principal porque no tiene problemas de formato de fecha. Compárala con 301/302/307/308 (que trasladan la URL) y 204 (también sin cuerpo, pero porque realmente no hay nada que enviar).

Qué significa 304 en la especificación

RFC 9110 (HTTP Semantics) §15.4.5 lo define con precisión: “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.” (traducción) «El código de estado 304 (Not Modified) indica que se recibió una solicitud GET o HEAD condicional que habría producido una respuesta 200 (OK) si no fuera porque la condición se evaluó como falsa». Ese es el disparador normativo: una solicitud condicional GET/HEAD cuya condición resulta falsa y que, de otro modo, habría recibido un 200. En términos sencillos: el cliente preguntó “dame esta página, pero solo si cambió”, el servidor determinó que no cambió y omite el cuerpo. “Segunda visita” es el ejemplo cotidiano de cómo una solicitud se vuelve condicional (el cliente adjunta un validador guardado de una respuesta anterior), pero es un ejemplo didáctico, no la regla: la especificación no exige una visita previa, solo una solicitud 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

La especificación incluso usa la palabra “redirecting” en esta sección: “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” (traducción) «por tanto, el servidor redirige al cliente para que use esa representación almacenada como si fuera el contenido de una respuesta 200 (OK)». Pero léelo con cuidado: redirige al cliente a su propia caché, no a otra URL. No hay cabecera Location ni dirección nueva. Esta frase es el origen de gran parte de la confusión sobre si una 304 “es una redirección”. No lo es en el sentido HTTP.

Hay otros dos puntos normativos importantes:

• Nunca hay cuerpo. RFC 9110 dice: “A 304 response is terminated by the end of the header section; it cannot contain content or trailers.” (traducción) «Una respuesta 304 termina al final de la sección de cabeceras; no puede contener contenido ni tráileres». Una 304 que envía cuerpo viola la especificación y algunos clientes la gestionarán mal. Es una regla estricta, no una preferencia de estilo.
• Transporta los mismos metadatos que enviaría un 200. El 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” (traducción) «DEBE generar cualquiera de los siguientes campos de cabecera que se habría enviado en una respuesta 200 (OK) a la misma solicitud: Content-Location, Date, ETag y Vary», además de Cache-Control y Expires cuando corresponda. Una 304 son las cabeceras del 200 sin la carga útil.

Cómo funciona realmente una 304: solicitudes condicionales

Un servidor nunca envía una 304 de la nada. Siempre responde a una solicitud condicional: una solicitud que el cliente hace condicional al adjuntar un validador guardado de una respuesta anterior. Hay dos validadores.

ETag e If-None-Match

Un ETag (etiqueta de entidad) es un token opaco que el servidor adjunta a una respuesta 200; imagínalo como la huella de versión de esa representación exacta de la URL. En la siguiente solicitud a esa URL, el cliente devuelve el valor guardado en una cabecera If-None-Match. El servidor compara: si el ETag actual sigue coincidiendo, nada cambió y devuelve 304; si difiere, devuelve un 200 nuevo con el contenido actualizado y un ETag nuevo.

Last-Modified e If-Modified-Since

La alternativa basada en fecha: el servidor envía una marca de tiempo Last-Modified en el 200. La próxima vez, el cliente la devuelve en una cabecera If-Modified-Since y el servidor compara las fechas: si el recurso no ha cambiado desde esa marca, es un 304. Es más sencilla pero más tosca (solo tiene la granularidad de la marca de tiempo) y sensible al formato exacto de la fecha HTTP, una fuente habitual de errores. Cuando están presentes ambos validadores, If-None-Match (el ETag) tiene prioridad sobre If-Modified-Since.

ETag fuertes y débiles

Un ETag puede ser fuerte o débil, y la diferencia importa. Según la guía de solicitudes condicionales de MDN, “strong validation consists of guaranteeing that the resource is, byte to byte, identical to the one it is compared to.” (traducción) «la validación fuerte consiste en garantizar que el recurso es idéntico, byte a byte, al recurso con el que se compara». Un ETag débil lleva el prefijo W/ (por ejemplo, ETag: W/"abc123") y solo afirma equivalencia semántica: el ejemplo de MDN es 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.” (traducción) «una página que solo se diferenciara de otra por una fecha distinta en el pie o por publicidad distinta se consideraría idéntica mediante validación débil». Los ETag fuertes (sin prefijo) son necesarios para cosas como solicitudes de rango que exigen coincidencia exacta de bytes; los débiles sirven cuando la compresión, los espacios o diferencias triviales sin importancia sustantiva no deberían forzar una descarga completa. La trampa práctica: si el ETag cambia cada vez que el contenido se vuelve a comprimir con gzip/Brotli o varía entre servidores con balanceo de carga, provocarás nuevos rastreos innecesarios. Elige fuerte o débil deliberadamente y mantén estable el valor cuando el contenido no haya cambiado realmente.

El intercambio completo, paso a paso

1. Primera solicitud → el servidor devuelve 200 OK con el contenido y ETag o Last-Modified.
2. El cliente guarda el contenido y esos validadores.
3. Siguiente solicitud → el cliente envía If-None-Match o If-Modified-Since con los valores guardados.
4. El servidor decide: sin cambios → 304 Not Modified, sin cuerpo, y el cliente reutiliza su caché; con cambios → 200 OK con el cuerpo nuevo y validadores actualizados. 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

Si quieres un tratamiento más profundo de la caché y los validadores como palanca de eficiencia de rastreo —la historia completa de las solicitudes condicionales y su relación con el presupuesto de rastreo—, es un tema complementario; este artículo se centra en el código de estado.

304 y SEO: ningún efecto en el posicionamiento, sí en la eficiencia del rastreo

Esta es toda la historia SEO y es más estrecha de lo que sugiere mucho texto genérico de blogs. 304 no tiene efecto directo en el posicionamiento, y la propia orientación de Google sobre cómo los códigos de estado afectan al rastreo y la indexación limita también el efecto de indexación: Search aún puede recalcular las señales de una URL, pero una 304 no cambia de otro modo cómo se indexa la página. Google ya tiene el contenido del rastreo anterior; una 304 solo confirma que no cambió y conserva lo que tiene. No hay una bonificación de posicionamiento por devolver 304.

Lo que sí te aporta una 304 es ahorro de recursos que puede mejorar indirectamente la eficiencia del rastreo. En la publicación de Google Search Central de diciembre de 2024 sobre caché HTTP, Gary Illyes explicó que la caché local puede hacer más eficiente el rastreo de sitios grandes con contenido que cambia poco y que Google admite ETag, If-None-Match, Last-Modified e If-Modified-Since.

Sobre el mecanismo exacto de la 304, la misma publicación explica por qué el cuerpo vacío es el punto central: si el ETag que envía el rastreador “matches the current value the server generated, your server should return an HTTP 304 (Not modified) status code with no HTTP body” (traducción) «coincide con el valor actual generado por el servidor, tu servidor debe devolver un código de estado HTTP 304 (Not modified) sin cuerpo HTTP», y esa parte de “no HTTP body” (traducción) «sin cuerpo HTTP» importa porque “your server doesn’t have to spend compute resources on actually generating content” (traducción) «tu servidor no tiene que gastar recursos de cálculo en generar contenido» y “doesn’t have to transfer the HTTP body” (traducción) «no tiene que transferir el cuerpo HTTP»; ahorras cálculo y ancho de banda en ambos extremos. El lenguaje de Google sobre el beneficio posterior es condicional: esos ahorros pueden mejorar indirectamente la eficiencia del rastreo. No promete que el esfuerzo ahorrado se reasigne automáticamente a tus URL nuevas o actualizadas; trátalo como un mecanismo de ahorro con un beneficio plausible, no garantizado.

Por qué importa más en sitios grandes

Si tienes unos cientos de páginas, esto es bastante académico: Google rastreará cómodamente todo tu sitio. El beneficio escala con el tamaño: un sitio con cientos de miles o millones de URL, muchas de ellas con cambios poco frecuentes, gana de forma tangible cuando los rastreadores pueden evitar volver a obtener todas las que no cambiaron. Ese es el público al que se dirige la publicación de Google y ese es el encuadre honesto: no vendas la 304 como una táctica para sitios pequeños.

ETag o Last-Modified, y qué cuenta como “cambio”

Google recomienda 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).” (traducción) «Recomendamos encarecidamente usar ETag porque es menos propenso a errores y equivocaciones (el valor no tiene estructura, a diferencia del valor Last-Modified)». Configurar ambos está bien y se recomienda. Si usas Last-Modified, la fecha “must be formatted according to the HTTP standard” (traducción) «debe tener el formato del estándar HTTP»; Google recomienda “Weekday, DD Mon YYYY HH:MM:SS Timezone,” (traducción) «Día de la semana, DD Mon AAAA HH:MM:SS Zona horaria,»; por ejemplo “Fri, 4 Sep 1998 19:15:56 GMT”, o puede ignorarse silenciosamente. Google también sugiere establecer el campo max-age de Cache-Control para ayudar a los rastreadores a decidir cuándo volver a rastrear.

La decisión sobre qué cuenta como un cambio que merece invalidar la caché es tuya, y el consejo de Google es reservarlo para cambios sustantivos: “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.” (traducción) «Nuestra recomendación es que exijas una actualización de la caché cuando haya cambios significativos en el contenido; si solo actualizaste la fecha de copyright al pie de la página, probablemente no sea significativo».

Qué hacen realmente Googlebot y Bingbot

No todas las solicitudes de rastreadores son condicionales. La documentación de rastreo de Google señala que cada rastreador y recuperador de Google varía en cuanto al soporte de caché según el producto al que sirve: Googlebot admite caché al volver a rastrear URL para Search, mientras que algunos recuperadores de Google solo la admiten en determinadas condiciones. Por tanto, aunque las cabeceras estén bien configuradas, no esperes que el 100 % de las solicitudes lleve If-None-Match/If-Modified-Since. En Bing, las solicitudes condicionales no son una función exclusiva de Google. El rastreador de Bing admite solicitudes GET condicionales (envía If-Modified-Since y, cuando está disponible, If-None-Match, y acepta una 304 cuando el contenido no cambió) desde al menos una publicación de Live Search de 2008, aunque Bing no ha publicado un equivalente moderno del texto de Google de 2024. Trátalo como comportamiento HTTP genérico aplicable a ambos motores.

Cómo implementar el soporte de 304

1. Envía validadores en el 200. Configura tu servidor, CDN o aplicación para adjuntar un ETag (recomendado) o una cabecera Last-Modified correctamente formateada a las respuestas 200 normales. Muchos servidores y frameworks generan ETag automáticamente para archivos estáticos; las respuestas dinámicas suelen requerir que lo actives.
2. Respeta las cabeceras condicionales al recibirlas. Cuando llegue una solicitud con If-None-Match/If-Modified-Since, compárala con el validador actual y devuelve 304 (sin cuerpo) si sigue coincidiendo, o un 200 nuevo si no coincide. De nuevo, los servidores de archivos estáticos suelen encargarse; las rutas de aplicación y los workers del edge a menudo no lo hacen si no los configuras.
3. Decide qué significa “cambiado” y mantén estable el ETag para el contenido que no ha cambiado realmente; no dejes que una recompresión o la variación entre servidores lo cambie sin motivo.
4. Vigila las configuraciones erróneas clásicas:
   • Siempre-200 — nunca se envían validadores, así que ninguna solicitud es condicional y nunca obtienes el beneficio de eficiencia.
   • ETag inestables — un valor que cambia aunque el contenido no cambie (balanceadores, recompresión), lo que fuerza descargas constantes.
   • 304 obsoletas — la peligrosa: un servidor sigue devolviendo 304 (o un ETag sin cambios) después de que el contenido haya cambiado, de modo que rastreadores y cachés nunca reciben la actualización. Es un error que debes detectar en el análisis de logs, no un defecto inherente de la 304.

304 frente a otros códigos de estado

304 frente a 301 / 302 / 307 / 308

Esos sí son redireccionamientos reales. Un 301/308 (permanente) o 302/307 (temporal) lleva una cabecera Location y mueve al cliente a una URL diferente; además, 301/308 transmiten una señal de canonicalización. Una 304 no tiene Location, no mueve a nadie y no transmite una señal de posicionamiento. Pertenecen a la misma familia 3xx por número, pero cumplen trabajos completamente distintos. Los detalles de cada código de redirección están en sus propios artículos (consulta el artículo sobre la redirección 301 y el subcentro de redirecciones).

304 frente a 204 No Content

Ambas respuestas no tienen cuerpo, pero por razones completamente distintas. Una 204 No Content es un éxito 2xx con el cuerpo intencionadamente vacío porque el servidor no tiene nada que enviar realmente —por ejemplo, un DELETE/PUT de API correcto o una baliza de analítica—. Una 304 tampoco envía cuerpo, pero no porque no haya nada que enviar: significa “ya lo tienes y sigue siendo válido”. No las confundas: una 204 en una URL de página puede tratarse como un soft 404 porque no hay contenido indexable, mientras que una 304 confirma la validez del contenido que Google ya tiene. El artículo sobre 204 No Content cubre ese código por completo.

Mitos habituales sobre 304

1. “304 es una redirección”. No tiene cabecera Location y nadie va a ningún sitio. El cliente reutiliza su propia copia en caché. El “redirecting the client to make use of that stored representation” (traducción) «redirigir el cliente para que utilice esa representación almacenada» de RFC 9110 significa volver a la caché, no ir a otra URL.
2. “304 es un error que debo solucionar”. Es el resultado correcto y esperado de una configuración funcional de solicitudes condicionales. Ver 304 en un rastreo o en DevTools indica que la caché funciona: es la confusión más habitual en las SERP.
3. “304 ayuda al posicionamiento”. No existe un efecto directo de posicionamiento y Google también limita el efecto de indexación: Search puede recalcular las señales de una URL, pero una 304 no cambia de otro modo la indexación. El beneficio es el ahorro de recursos que Google dice que puede mejorar indirectamente la eficiencia del rastreo en sitios muy grandes; no es una señal de posicionamiento ni una garantía de que el esfuerzo ahorrado pase a otras URL.
4. “If my server returns 304, Google will use stale content forever.” (traducción) «Si mi servidor devuelve 304, Google usará contenido obsoleto para siempre». La 304 solo se activa mientras el validador coincide. En cuanto cambia el contenido de verdad, un servidor bien implementado devuelve un 200 nuevo con validadores nuevos. El riesgo real es un servidor mal configurado que continúa devolviendo 304 después de un cambio: es un error, no una propiedad de la 304.

5. “ETag y Last-Modified son intercambiables”. Ambos son validadores, pero Last-Modified depende del formato de fecha y solo tiene la granularidad de su marca de tiempo, mientras que ETag es opaco y preciso (aunque puede variar de forma problemática entre servidores o después de una recompresión si se implementa mal). Google recomienda ETag como principal y usar ambos si puedes.

Preguntas frecuentes

¿HTTP 304 es un error? No: es una señal de éxito que indica que la caché funciona. Significa que la copia guardada por el cliente sigue siendo válida.

¿304 Not Modified es una redirección? No. Pertenece a la clase 3xx por numeración, pero no tiene cabecera Location ni mueve al cliente a una URL nueva.

¿304 ayuda al SEO o al posicionamiento? No tiene efecto directo en el posicionamiento ni efecto de indexación más allá de que Google pueda recalcular las señales de una URL. Ahorra ancho de banda y cálculo al permitir que los rastreadores omitan páginas sin cambios, algo que Google dice que puede mejorar indirectamente la eficiencia del rastreo en sitios grandes.

¿Cuál es la diferencia entre ETag y Last-Modified? ETag es una huella opaca de versión que se compara mediante If-None-Match; Last-Modified es una marca de tiempo que se compara mediante If-Modified-Since. Google recomienda ETag porque es menos propenso a errores.

¿Qué es un ETag débil frente a uno fuerte? Un ETag fuerte afirma que el contenido es idéntico byte a byte; un ETag débil (con prefijo W/) afirma equivalencia semántica y tolera diferencias triviales, como la compresión o una fecha de pie de página modificada.

¿Por qué veo 304 en mis logs o informes de rastreo? Porque los clientes están haciendo solicitudes condicionales y tu servidor confirma correctamente que el contenido no cambió. Es algo esperado y positivo.

¿Cómo hago que mi servidor devuelva 304 correctamente? Envía ETag/Last-Modified en el 200 y, en la siguiente solicitud, respeta If-None-Match/If-Modified-Since devolviendo 304 sin cuerpo cuando el validador siga coincidiendo.

¿Cuál es la diferencia entre 304 y 204? Ambas respuestas no tienen cuerpo: 204 porque no hay nada que enviar y 304 porque ya tienes una copia que sigue siendo válida.

¿Googlebot envía cabeceras condicionales en todas las solicitudes? No. El soporte de caché varía según el rastreador, así que no todas las solicitudes serán condicionales aunque hayas configurado las cabeceras.

¿Puede una respuesta 304 tener cuerpo? No. RFC 9110 dice que “it cannot contain content or trailers” (traducción) «no puede contener contenido ni tráileres». Una 304 con cuerpo viola la especificación.

Resumen de IA

Una síntesis de la versión avanzada:

• 304 Not Modified es la respuesta a una solicitud GET/HEAD condicional cuya condición resulta falsa y que, de otro modo, habría recibido un 200 (RFC 9110 §15.4.5). Pertenece a la clase 3xx, pero NO es una redirección: no hay cabecera Location, URL nueva ni —normativamente— cuerpo: “it cannot contain content or trailers” (traducción) «no puede contener contenido ni tráileres». Una segunda visita es el ejemplo habitual de cómo una solicitud se vuelve condicional, no la regla del protocolo.
• Es la respuesta a una solicitud condicional. Un GET/HEAD lleva If-None-Match (comparado con un ETag) o If-Modified-Since (comparado con Last-Modified). Si el validador sigue coincidiendo, el servidor devuelve 304 y el cliente reutiliza su copia en caché.
• La palabra “redirecting” de la especificación es metafórica: remite al cliente a su propia caché, no a otra URL. Esa frase causa gran parte de la confusión sobre si 304 es una redirección.
• ETag frente a Last-Modified: ETag es un token opaco de versión (comparado mediante If-None-Match); Last-Modified es una fecha (comparada mediante If-Modified-Since y con formato HTTP exacto obligatorio). If-None-Match tiene prioridad cuando están presentes ambos. ETag fuerte = idéntico byte a byte; ETag débil (prefijo W/) = equivalencia semántica.
• No hay efecto directo en el posicionamiento ni efecto de indexación más allá de que Google pueda recalcular señales. Google ya tiene el contenido; 304 solo confirma que no cambió. Como explicó Gary Illyes, la caché “may help your site be crawled more efficiently” (traducción) «puede ayudar a que tu sitio se rastree de forma más eficiente»: el beneficio es ahorro de recursos que puede mejorar indirectamente la eficiencia del rastreo en sitios grandes, no una reasignación garantizada del presupuesto de rastreo ni una señal de posicionamiento.
• Google recomienda ETag como principal (“less prone to errors and mistakes” (traducción) «menos propenso a errores y equivocaciones»); está bien configurar ambos. Last-Modified debe usar el formato “Weekday, DD Mon YYYY HH:MM:SS Timezone”; invalida la caché solo ante cambios significativos, no por una fecha de copyright del pie.
• El soporte de caché varía según el rastreador: no todas las solicitudes de Googlebot son condicionales. Bing admite GET condicional desde una publicación de Live Search de 2008; es comportamiento HTTP genérico.
• No lo confundas con 301/302/307/308 (redirecciones reales que mueven la URL) ni con 204 No Content (también sin cuerpo, pero porque realmente no hay nada que enviar).
• El riesgo real no es la 304, sino un servidor mal configurado que devuelve 304 después de que el contenido haya cambiado: detéctalo en el análisis de logs. Una 304 válida también puede parecer un error en algunas bibliotecas cliente o capas de caché de plataforma aunque no haya ningún problema.

Documentación oficial

Referencias de fuentes primarias sobre qué es una 304 y cómo la utilizan los motores de búsqueda.

Especificación HTTP y referencia de navegadores

• RFC 9110 §15.4.5 — definición de 304 No modificado — definición autoritativa: solicitud condicional, ausencia de cuerpo y cabeceras obligatorias.
• MDN — definición de 304 No modificado — explicación en lenguaje llano, el disparador If-None-Match/If-Modified-Since y la lista de cabeceras que debe llevar una 304.
• MDN — solicitudes condicionales HTTP — explicación de la validación fuerte y débil.
• MDN — ETag — la cabecera ETag, incluida la sintaxis débil (W/) y fuerte.

Google Search Central

• Crawling December: HTTP caching — publicación de Gary Illyes del 9 de diciembre de 2024: cómo ETag/If-None-Match y Last-Modified/If-Modified-Since impulsan las 304 y por qué ayudan a la eficiencia del rastreo.
• Google Crawler (User Agent) Overview — qué rastreadores de Google admiten caché y la recomendación de ETag sobre Last-Modified.
• How HTTP status codes affect Google’s crawlers — la fila actual de Google sobre 304, incluida la precisión de que Search aún puede recalcular las señales de una URL aunque una 304 no tenga de otro modo efecto de indexación.
• Troubleshoot Google Search crawling errors — fuente del lenguaje condicional de Google: el ahorro de recursos de las solicitudes condicionales “may indirectly” (traducción) «puede mejorar indirectamente» la eficiencia del rastreo y Google no envía cabeceras condicionales en todos los intentos.

Bing

• Anuncio de mejoras del rastreador para Live Search — la antigua publicación de Bing/Live Search que confirma el soporte de GET condicional (If-Modified-Since/If-None-Match → 304) desde 2008.

Citas de la fuente

Declaraciones registradas. Cada enlace es un enlace profundo que salta al pasaje citado de la página de origen donde la fuente lo respalda.

La especificación 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.” (traducción) «El código de estado 304 (Not Modified) indica que se recibió una solicitud GET o HEAD condicional que habría producido una respuesta 200 (OK) si no fuera porque la condición se evaluó como falsa». — RFC 9110, HTTP Semantics, §15.4.5. Leer la sección
• “A 304 response is terminated by the end of the header section; it cannot contain content or trailers.” (traducción) «Una respuesta 304 termina al final de la sección de cabeceras; no puede contener contenido ni tráileres». — RFC 9110, §15.4.5 (la regla normativa de “nunca hay cuerpo”). Leer la sección

MDN Web Docs

• “The HTTP 304 Not Modified redirection response status code indicates that there is no need to retransmit the requested resources.” (traducción) «El código de estado de respuesta de redirección HTTP 304 Not Modified indica que no es necesario volver a transmitir los recursos solicitados». Ir a la cita
• “Strong validation consists of guaranteeing that the resource is, byte to byte, identical to the one it is compared to.” (traducción) «La validación fuerte consiste en garantizar que el recurso es idéntico, byte a byte, al recurso con el que se compara». — MDN, “HTTP conditional requests”. Leer la guía

Gary Illyes, Google — “Crawling December: HTTP caching” (9 de diciembre 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.” (traducción) «Sobre todo si tienes un sitio grande con contenido que cambia rara vez en URL individuales, permitir la caché local puede ayudar a que tu sitio se rastree de forma más eficiente. La infraestructura de rastreo de Google admite la caché HTTP heurística definida por el estándar de caché HTTP, concretamente mediante la cabecera de respuesta ETag y la cabecera de solicitud If-None-Match, y la cabecera de respuesta Last-Modified y la cabecera de solicitud If-Modified-Since». Leer la publicación
• “We strongly recommend using ETag because it’s less prone to errors and mistakes (the value is not structured unlike the Last-Modified value).” (traducción) «Recomendamos encarecidamente usar ETag porque es menos propenso a errores y equivocaciones (el valor no tiene estructura, a diferencia del valor Last-Modified)». Leer la publicación
• “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.” (traducción) «Si el valor ETag enviado por el rastreador coincide con el valor actual generado por el servidor, tu servidor debe devolver un código de estado HTTP 304 (Not modified) sin cuerpo HTTP». Leer la publicación
• “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.” (traducción) «Nuestra recomendación es que exijas una actualización de la caché cuando haya cambios significativos en el contenido; si solo actualizaste la fecha de copyright al pie de la página, probablemente no sea significativo». Leer la publicación

Cita de Patrick Stox en Ahrefs

• “304 Not Modified – Says the page hasn’t been modified. Typically used for caching.” (traducción) «304 Not Modified: indica que la página no se ha modificado. Normalmente se usa para la caché». — de mi guía Códigos de estado HTTP y su impacto en el SEO (este artículo es el análisis profundo que esa entrada nunca tuvo). Ir a la cita

304 en contexto: los códigos sin cuerpo y 3xx con los que se confunde

304 frente a sus equivalentes aparentes

| Código | Clase | Cuerpo | Cabecera Location | Lo que realmente dice | Señal de posicionamiento/canonical |\n| --- | --- | --- | --- | --- | --- |\n| 304 Not Modified | 3xx | Ninguno (por especificación) | No | “Tu copia en caché sigue siendo válida; reutilízala” | Ninguna (solo eficiencia de rastreo) |\n| 301 Moved Permanently | 3xx | — | Sí | “Traslado definitivo; ve allí” | Transmite señal de canonicalización |\n| 302 Found | 3xx | — | Sí | “Está aquí temporalmente” | Ninguna señal de canonicalización |\n| 307 Temporary Redirect | 3xx | — | Sí | Como 302, conserva el método | Ninguna señal de canonicalización |\n| 308 Permanent Redirect | 3xx | — | Sí | Como 301, conserva el método | Transmite señal de canonicalización |\n| 204 No Content | 2xx | Ninguno (no hay nada que enviar) | No | “Éxito, intencionadamente vacío” | Ninguna; en una URL de página se trata como soft 404 |\n| 200 OK | 2xx | Con contenido | No | “Aquí está la página” | Apta para indexación |

La trampa: 304 y 204 no tienen cuerpo, y 304/301/302/307/308 son 3xx, pero 304 es la excepción en ambos ejes. Es el único 3xx que no mueve a nadie y el único código sin cuerpo que significa “ya lo tienes” en vez de “no hay nada que enviar”.

Los dos validadores

| Validador (respuesta) | Cabecera de solicitud condicional | Tipo | Notas |\n| --- | --- | --- | --- |\n| ETag: "abc123" | If-None-Match: "abc123" | Token opaco | Principal recomendado por Google; fuerte = idéntico byte a byte |\n| ETag: W/"abc123" | If-None-Match: W/"abc123" | Token débil | Prefijo W/ = equivalencia semántica (tolera diferencias triviales) |\n| Last-Modified: Fri, 4 Sep 1998 19:15:56 GMT | If-Modified-Since: <date> | Marca de tiempo | Requiere formato exacto de fecha HTTP; más tosco que ETag |

Cuando están presentes ambos, If-None-Match tiene prioridad sobre If-Modified-Since.

Datos rápidos

• 304 nunca tiene cuerpo: RFC 9110 lo establece normativamente.
• 304 es un código 3xx pero no una redirección (no hay Location ni URL nueva).
• No hay efecto directo en el posicionamiento, ni efecto de indexación más allá de que Google pueda recalcular las señales de una URL; el beneficio es un ahorro de recursos que puede ayudar indirectamente a la eficiencia del rastreo en sitios grandes.
• Google recomienda ETag como principal; configurar ETag y Last-Modified es válido.
• Last-Modified debe usar “Weekday, DD Mon YYYY HH:MM:SS Timezone” o puede ignorarse.
• Invalida la caché ante cambios de contenido significativos, no por una fecha de copyright del pie.
• No todas las solicitudes de rastreadores son condicionales: el soporte de caché varía según el rastreador.
• Bing admite GET condicional → 304 desde 2008; es HTTP genérico.
• El riesgo real es una 304 obsoleta (el servidor devuelve 304 después de que cambió el contenido): detéctala en el análisis de logs.

El intercambio de solicitudes condicionales, en HTTP sin procesar

Cadenas concretas de solicitud/respuesta que muestran cómo se produce una 304. (Los valores de las cabeceras son ilustrativos.)

ETag / If-None-Match — la primera obtención (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>

El cliente guarda el cuerpo y el valor de ETag.

ETag / If-None-Match — la siguiente obtención, contenido sin cambios (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

Sin cuerpo. El ETag coincidió, así que el servidor ahorró el cálculo de generar la página y el ancho de banda de enviarla. El cliente reutiliza su copia en caché.

Last-Modified / If-Modified-Since — el equivalente basado en fecha

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

Observa el formato exacto de fecha HTTP —“Weekday, DD Mon YYYY HH:MM:SS Timezone”— que recomienda Google para evitar problemas de análisis.

Cuando el contenido SÍ ha cambiado: un 200 nuevo, no una 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>

El ETag guardado ya no coincide, así que el servidor envía el contenido nuevo y un validador nuevo. La caché se actualiza. Precisamente por eso una 304 bien implementada no puede “atrapar” a un rastreador con contenido obsoleto: en cuanto cambia el contenido, cambia el validador y la siguiente solicitud recibe un 200 real.

ETag débil frente a fuerte

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

Regla práctica: si gestionas un sitio grande con muchas URL que cambian rara vez, enviar un ETag estable (y respetar If-None-Match) en tus 200 permite a los rastreadores confirmar “sigue igual” mediante una 304 barata y sin cuerpo. Ahorras ancho de banda y cálculo, lo que según Google puede mejorar indirectamente la eficiencia con la que se rastrea el resto del sitio. Si tu ETag cambia en cada recompresión o entre servidores con balanceo, pierdes ese beneficio.

Errores de 304 que rompen la caché condicional

Cambiar el ETag cuando no cambió la representación

Un ETag vinculado a una instancia del servidor, una pasada de compresión o la marca temporal de la solicitud invalida el validador: el contenido sin cambios sigue devolviendo un 200 completo. Genera un validador estable a partir de la representación o usa deliberadamente un ETag débil cuando las diferencias a nivel de byte no sean significativas.

Devolver 304 después de que cambió el contenido

Un validador obsoleto puede ocultar una actualización real a clientes y rastreadores. Invalida el ETag o avanza Last-Modified cada vez que cambie la representación; después confirma que la solicitud condicional antigua recibe un 200 nuevo con cuerpo.

Enviar 304 sin una solicitud condicional coincidente

Un servidor no debe adivinar que el cliente tiene una copia en caché. Devuelve 304 solo después de evaluar If-None-Match o If-Modified-Since; una primera solicitud normal necesita una respuesta completa.

Tratar 304 como redirección o página vacía

Una 304 no tiene cabecera Location ni cuerpo de respuesta. No la envíes por la lógica de redirecciones ni sustituyas un recurso realmente vacío por 304; usa el estado que describa la respuesta real.

Problemas habituales con 304

El servidor siempre devuelve 200

Síntoma: las solicitudes repetidas descargan el cuerpo completo aunque nada haya cambiado. Causa probable: la respuesta inicial no tiene validador o la aplicación ignora las cabeceras de solicitud condicionales. Solución: envía ETag o un Last-Modified válido y después implementa la comprobación coincidente de If-None-Match o If-Modified-Since. Confirma que una solicitud sin cambios devuelve una 304 sin cuerpo.

Distintos servidores de origen generan ETag distintos

Síntoma: la misma URL sin cambios alterna entre 200 y 304 detrás de un balanceador. Causa probable: cada nodo genera su propio validador. Solución: deriva el ETag del estado compartido del contenido, no del nodo que lo sirve, y repite la misma solicitud condicional contra varias respuestas.

El contenido actualizado sigue devolviendo 304

Síntoma: un navegador o rastreador conserva una representación antigua después de un despliegue. Causa probable: el validador no se invalidó junto con el contenido. Solución: corrige la clave de caché o la lógica de despliegue, purga la caché afectada cuando sea necesario y demuestra que el ETag antiguo recibe ahora un 200 con un validador nuevo.

Last-Modified parece ignorarse

Síntoma: If-Modified-Since nunca produce una 304. Causa probable: una fecha HTTP no válida, precisión insuficiente de la marca de tiempo o un ETag que tiene prioridad. Solución: inspecciona las cabeceras sin procesar, corrige el formato de fecha y prueba cada validador por separado.

Una 304 parece un error en el código de la aplicación

Síntoma: un script o aplicación lanza una excepción o registra un “error” cuando la solicitud en realidad recibió una 304. Causa probable: algunas bibliotecas cliente HTTP tratan cualquier estado distinto de 200 —incluida una 304 válida— como una condición parecida a una excepción, salvo que las configures explícitamente para seguir redirecciones o aceptar respuestas no modificadas; es una peculiaridad de la biblioteca, no un problema del protocolo o del servidor. Solución: comprueba cómo gestiona la biblioteca cliente específicamente la 304 (no solo el manejo de errores 4xx/5xx) y confirma que la respuesta HTTP sin procesar es una 304 correcta y sin cuerpo antes de culpar al servidor.

Una capa de caché de la plataforma (por ejemplo, la caché de salida de IIS) enturbia el diagnóstico

Síntoma: la aplicación de origen parece correcta, pero el comportamiento de 304 sigue siendo extraño. Causa probable: una capa de caché específica de la plataforma de alojamiento —la caché de salida de IIS es un ejemplo documentado— está entre la aplicación y el cliente y puede generar o interceptar respuestas 304 por su cuenta. Solución: trátala como una capa posible entre varias (aplicación de origen, CDN, balanceador y caché de plataforma), no como sospechosa predeterminada; aísla el problema con una prueba controlada que cambie el validador en cada capa, una por una, antes de concluir cuál es responsable.

Prompt: audita una traza de solicitud condicional

Pega las cabeceras de solicitud y respuesta de una obtención inicial y de una obtención 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: revisa una implementación de ETag

Pega la configuración relevante de la aplicación, CDN o 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: repite un ETag como solicitud condicional

Ejecuta esto en un terminal macOS/Linux. Copia el ETag exactamente, incluidas las comillas.

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"

La primera respuesta debe mostrar el validador. La segunda debe devolver 304 cuando la representación no haya cambiado y 200 cuando el ETag pegado esté obsoleto.

PowerShell: prueba Last-Modified

Ejecuta esto en PowerShell después de sustituir la URL y la marca de tiempo.

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

Consola de DevTools: enumera los validadores de recursos de la página

Ejecútalo en la consola del navegador. Informa de las entradas de temporización de recursos; usa el panel Network para inspeccionar las cabeceras reales ETag, Last-Modified y de estado.

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

Herramientas para inspeccionar el comportamiento de 304

• HTTP Header Checker: inspecciona ETag, Last-Modified, Cache-Control, Vary y las huellas de la CDN/edge en la respuesta normal antes de repetir un validador.
• Panel Network de DevTools del navegador: desactiva “Disable cache”, recarga y compara las cabeceras de solicitud y respuesta. DevTools también hace visibles HSTS y la caché local, así que distingue el comportamiento del navegador de lo que envió el origen.
• curl: envía una cabecera If-None-Match o If-Modified-Since exacta sin que interfiera el estado de caché del navegador.
• Logs de acceso: cuantifica qué solicitudes de rastreadores fueron condicionales y si acabaron en 304 o en un 200 completo.

Demuestra que las respuestas condicionales funcionan después de un cambio

Prueba de representación sin cambios

Prueba que debes ejecutar: obtiene la URL, copia su ETag y repite con curl -I -H 'If-None-Match: "VALUE"' URL. Resultado esperado: 304, el validador coincidente y ningún cuerpo ni Location. Interpretación del fallo: el servidor ignoró la condición o generó un validador inestable. Ventana de seguimiento: inmediata. Activador de reversión: el cambio de caché hace que las solicitudes normales pierdan su respuesta 200 completa.

Prueba de representación modificada

Prueba que debes ejecutar: despliega un cambio real de contenido y repite el ETag antiguo. Resultado esperado: 200 con el cuerpo actualizado y un validador nuevo. Interpretación del fallo: la invalidación de caché está obsoleta. Ventana de seguimiento: inmediatamente después de que el despliegue llegue a todos los orígenes. Activador de reversión: cualquier origen sigue devolviendo 304 para el validador antiguo cuando el despliegue ya terminó.

Prueba de estabilidad entre orígenes

Prueba que debes ejecutar: repite las mismas solicitudes normales y condicionales suficientes veces para alcanzar el grupo de servidores, registrando el ETag y el estado. Resultado esperado: las representaciones sin cambios usan validadores compatibles y producen 304 de forma constante. Interpretación del fallo: los validadores varían según el nodo o la codificación sin una estrategia Vary coincidente. Ventana de seguimiento: inmediata, en todo el grupo desplegado. Activador de reversión: la nueva lógica de validación sirve contenido obsoleto o mezcla representaciones entre clientes.

Mide la salud de la caché condicional

Tasa de éxito de la revalidación condicional

Métrica: solicitudes condicionales que terminan en 304 frente a un 200 completo. Qué te dice: si los recursos sin cambios evitan transferencias innecesarias. Cómo obtenerla: agrupa las solicitudes de logs de acceso que llevan If-None-Match o If-Modified-Since por estado de respuesta y clase de URL. Referencia/rango realista: establece una línea base por tipo de contenido; no obligues a las páginas que cambian con frecuencia a acercarse a la tasa de los recursos estáticos. Periodicidad: semanal durante el despliegue y después mensual.

Bytes evitados en obtenciones sin cambios

Métrica: bytes estimados del cuerpo de respuesta que no se transfirieron en respuestas 304 válidas. Qué te dice: el lado del ancho de banda del beneficio de eficiencia del rastreo. Cómo obtenerla: une el número de 304 de los logs con el tamaño de la respuesta completa más reciente para la misma clase de URL. Referencia/rango realista: compáralo con la línea base propia del sitio antes del cambio; ningún objetivo universal encaja con todas las mezclas de contenido. Periodicidad: mensual.

Fallos de validadores obsoletos

Métrica: URL modificadas que aún aceptan un validador antiguo. Qué te dice: si la eficiencia se obtiene a costa de la frescura. Cómo obtenerla: ejecuta una pequeña muestra posterior al despliegue que repita los ETag anteriores al despliegue. Referencia/rango realista: toda respuesta obsoleta confirmada requiere investigación. Periodicidad: en cada despliegue que cambie la caché o la generación de validadores.

Ponte a prueba: 304 Not Modified

Cinco preguntas rápidas sobre qué significa una 304 y cómo funciona. Elige una respuesta para cada una y después comprueba el resultado.

Registro de cambios