204 No Content: qué significa

TL;DR — Una respuesta 204 No Content significa «tu solicitud funcionó y te devuelvo deliberadamente una página vacía». Es un código de éxito, no un error. Está perfecto para cosas como una aplicación que guarda tu trabajo en segundo plano o un rastreador de analítica, pero es incorrecto para una página web real que quieres en Google. Un cuerpo vacío no le da nada que indexar a Google, así que trata un 204 en una página como un soft 404.

Qué es realmente un 204

Cada respuesta que envía tu servidor lleva un código de estado. Los códigos 2xx significan «éxito». 200 OK —el que quieres en tus páginas— significa «aquí está la página», con cuerpo incluido. 204 No Content también significa éxito, pero con un matiz: el servidor dice «hice lo que pediste y no hay nada que mostrarte intencionadamente».

La palabra clave es intencionadamente. Un 204 no es una página que no terminó de cargar ni una URL que no existe: es una respuesta diseñada para estar vacía. Imagínalo como el servidor asintiendo «listo» sin devolverte nada.

Por qué es un problema para una página web

Google indexa el contenido de una página. Si una URL devuelve 204, no hay contenido que leer: el cuerpo está vacío por diseño. La propia documentación de Google lo dice claramente: “wasn’t able to receive any content and therefore can’t process it.” (traducción) «no pudo recibir ningún contenido y, por tanto, no puede procesarlo». Así que una página que quieres posicionar y devuelve 204 no le da a Google nada con lo que trabajar, lo que significa que no se indexará; en la práctica, Search Console suele marcarla igual que un soft 404, una página que «tuvo éxito» técnicamente pero no tiene nada que merezca indexarse.

Así que, cuando una página que quieres posicionar aparece como un 204 en un rastreo o en Search Console, es un error que debes corregir, no algo que debas dejar así.

Cuándo un 204 está perfectamente bien

La mayoría de los 204 que verás nunca son páginas:

• Aplicaciones que guardan en segundo plano. Pulsas «guardar» y la aplicación almacena tu trabajo sin recargar la página; el servidor puede responder con un 204.
• Analítica y seguimiento. Los rastreadores envían pequeñas solicitudes «beacon» para registrar que ocurrió algo. No hay ninguna página que devolver, así que 204 es exactamente lo correcto.
• Interfaces de aplicaciones (API). Cuando un sistema indica a otro que elimine algo, a menudo no hay nada que devolver; un 204 dice «listo».

Nada de eso necesita estar en Google, así que un 204 ahí es la respuesta correcta, no un error.

La única regla que debes recordar

Nunca devuelvas un 204 para una URL que quieres que la gente encuentre en las búsquedas. Si una página ha desaparecido para siempre, usa 404 o 410. Si se ha trasladado, redirígela (301). Si se supone que debe tener contenido, corrige lo que esté sirviendo una respuesta vacía. ¿Quieres la versión detallada —la formulación exacta de Google, los casos de uso de API y beacons y cómo diagnosticar un 204 accidental—? Cambia a la pestaña Avanzado.

TL;DR — 204 es un código de éxito 2xx conforme a la especificación (RFC 9110 §15.3.5) que devuelve un cuerpo vacío por diseño: el cuerpo debe estar vacío (sin Content-Length, ni siquiera 0) y los navegadores pueden rechazar un 204 que envíe contenido. No es un error y no dice nada sobre la existencia de una URL; el RFC no lo restringe a una lista fija de métodos. Sus usos legítimos son casi siempre respuestas que no son documentos: DELETE/PUT de API REST y beacons de analítica (sendBeacon(), protocolo de medición GA4), aunque los profesionales discrepan sobre con qué frecuencia deberían usarlo las API. La consecuencia SEO es acotada: la tabla de códigos de estado de Google dice claramente que, para un 204, “Google wasn’t able to receive any content and therefore can’t process it” (traducción) «Google no pudo recibir ningún contenido y, por tanto, no puede procesarlo»; eso significa que una página que quieres posicionar no se indexará a partir de esa respuesta y, en la práctica, suele marcarse como soft 404 en Search Console, aunque Google no garantiza esa etiqueta concreta ni un plazo de retirada. Corrige un 204 accidental a nivel de página restaurando un 200 real o usando 404/410/301 según la intención.

Qué significa 204 en la especificación

RFC 9110 (HTTP Semantics) no deja lugar a dudas: un 204 indica que “the server has successfully fulfilled the request and that there is no additional content to send in the response payload body.” (traducción) «el servidor ha cumplido correctamente la solicitud y no hay contenido adicional que enviar en el cuerpo del payload de respuesta». Es un código de éxito, de la misma familia 2xx que 200 OK, con la diferencia deliberada de que no hay cuerpo.

Hay tres detalles operativos importantes. Primero, el cuerpo tiene que estar realmente vacío: MDN señala que un 204 “must not include any content or the Content-Length header (browsers may reject responses that include content).” (traducción) «no debe incluir contenido ni la cabecera Content-Length (los navegadores pueden rechazar las respuestas que incluyan contenido)». Es una prohibición real, no una convención flexible: RFC 9110 §8.6 prohíbe Content-Length en un 204, así que «envía simplemente Content-Length: 0» (una solución que he visto recomendar) tampoco cumple la especificación; la respuesta termina al acabar la sección de cabeceras. Segundo, las cabeceras que sí lleve un 204 —un ETag, un Last-Modified— describen la representación seleccionada después de completar la acción, no un cuerpo enviado. Tercero, un ETag aparece en algunos 204 (el ejemplo de MDN es un PUT que actualiza un recurso en su sitio), pero el RFC no exige que todos los 204 lo incluyan: no lo des por hecho. Un 204 se puede almacenar heurísticamente en caché por defecto, salvo que el método o unas cabeceras explícitas de control de caché indiquen lo contrario.

Y lo más importante: 204 no tiene nada que ver con que exista una URL. Un endpoint de API funcional puede devolver correctamente 204 para siempre. Esa es la diferencia con un 404 (no encontrado) o un 410 (desaparecido): esos códigos tratan de la ausencia; 204 trata de una solicitud correcta que lleva deliberadamente un payload vacío.

Cómo trata Google un 204

Esta es toda la historia SEO y es más acotada de lo que hacen parecer las fórmulas de los blogs de proveedores. Google indexa contenido. Un 204 no tiene contenido. La documentación de Google sobre códigos de estado destaca el 204 con una afirmación específica y limitada: mientras que la regla general de 2xx es que «Google considers the content for processing» (traducción) «Google considera el contenido para procesarlo», la fila dedicada al 204 dice que “Google wasn’t able to receive any content and therefore can’t process it.” (traducción) «Google no pudo recibir ningún contenido y, por tanto, no puede procesarlo».

Ese es el límite real y conviene precisar qué promete y qué no. La guía general sobre 2xx de esa misma página dice que el contenido vacío o parecido a un error puede informarse como soft 404; pero la fila del 204 no garantiza que todos los 204 acaben bajo esa etiqueta concreta de Search Console, y Google no publica un calendario de retirada. Lo sólido es esto: un 204 en una URL de contenido no proporciona nada al pipeline de indexación de Google, así que decir que la URL no se indexará a partir de esa respuesta es una inferencia razonable; no la extendería a «pérdida de posiciones garantizada en todo el sitio» ni a «recuperación automática del presupuesto de rastreo», porque la documentación de Google no promete ninguna de las dos cosas. En la práctica, Search Console suele mostrar estos casos como soft 404 —ese es el patrón que he observado y sobre el que he escrito—, pero trata la etiqueta concreta y el momento como comportamiento observado, no como garantía documentada.

Esta es la postura que he mantenido en mis propios textos. En mi guía Códigos de estado HTTP y su impacto en el SEO del blog de Ahrefs, en la sección sobre cómo gestiona Google las respuestas 2xx, resumo la lectura práctica: las respuestas 2xx suelen permitir la indexación, pero los 204 se tratan como soft 404 y no se indexan. Mantengo esa lectura práctica; la formulación actual y más precisa de la propia documentación de Google es la de «no puede recibir ni procesar contenido», que es la que señalaría para conocer el límite oficial exacto.

Los soft 404 siguen rastreándose y desperdiciando presupuesto de rastreo, según la documentación, pero esa es la guía general de Google sobre soft 404, no una promesa específica para 204. Usar 204 no libera ni redirige automáticamente recursos de rastreo; la propia precisión de Google es que la asignación depende de los límites de servicio, la calidad del sitio y el inventario, no del código de estado que provocó la exclusión. La conclusión segura es: corrige un 204 accidental porque impide indexar una página, no porque te corresponda un dividendo concreto de presupuesto de rastreo por hacerlo.

204 frente a los códigos con los que se confunde

La trampa es que 204, 200 vacío, 404 y 410 pueden acabar todos como «soft 404» en GSC cuando no hay contenido utilizable, pero señalan intenciones muy distintas a un cliente conforme a la especificación. 410 es la señal deliberada de «esto existía y ha desaparecido permanentemente»; 204 nunca se diseñó para significar eso y no debe aparecer en URL de páginas.

Cuándo 204 es exactamente lo correcto (no un error)

Casi todos los 204 legítimos son respuestas que no son documentos:

• API REST DELETE / PUT. Cuando un cliente elimina un recurso o lo actualiza en su sitio y no hay nada relevante que devolver, 204 es la respuesta idiomática: es el patrón recomendado por el propio RFC 9110.
• Beacons de analítica y seguimiento. La especificación Beacon del W3C, basada en navigator.sendBeacon(), espera que los endpoints de beacons respondan con 204. El endpoint del protocolo de medición de Google Analytics 4 devuelve 204 para los hits que acepta. Importante: GA4 devuelve 204 incluso para hits mal formados o inválidos, así que un 204 solo confirma que el endpoint era accesible y respondió estructuralmente, no que el hit se procesara. No interpretes el 204 de un beacon como prueba de éxito.
• Experiencia «guardar sin salir de la página». Un PUT que guarda el estado en el sitio y deja al usuario en la página actual: la formulación de MDN es que, con un 204, “the client doesn’t need to navigate away from its current page.” (traducción) «el cliente no necesita salir de su página actual».

La idea común es que estas no son URL que nadie deba indexar, así que 204 es correcto y esperado. El problema es solo un 204 colocado en una URL de documento que se supone que debe posicionarse.

Conviene señalar otro matiz: RFC 9110 no restringe 204 específicamente a DELETE/PUT/beacons; esos son solo los patrones habituales. La definición de la especificación es independiente del método; lo que importa es el contrato del propio método y si sería útil devolver una representación. Esto funciona en ambas direcciones. Una solicitud GET que devuelve 204 es legal según el protocolo —los profesionales llevan años debatiéndolo en Stack Overflow—; la pregunta real para una página indexable no es «¿está permitido 204 en GET?», sino «¿necesita esta URL entregar una representación para que se pueda encontrar en Google?», y para una página que quieres posicionar la respuesta siempre es sí. Por tanto, la regla SEO no trata del método HTTP que se use, sino de si la URL está pensada para ser un documento.

También conviene saber que ni siquiera entre los diseñadores de API existe acuerdo universal en que «204 siempre es correcto para respuestas de API». El texto de Postman presenta 204 como la opción habitual para acciones sin nada que devolver; Brandur Leach ha defendido la postura contraria: una respuesta de éxito vacía puede ser ligeramente perjudicial para clientes de API que esperan recibir una representación (estado actualizado, un ID generado o un campo calculado) incluso después de una escritura correcta. Es una decisión legítima de diseño de API sobre ergonomía del desarrollador, no una cuestión de corrección HTTP: 204 sigue cumpliendo la especificación en ambos casos, y es independiente de la cuestión SEO de este artículo. Un punto en el que algunos textos de API se vuelven descuidados: enviar Content-Length: 0 en un 204 «por seguridad». No lo hagas: RFC 9110 §8.6 prohíbe Content-Length en una respuesta 204 por completo, no solo cuando es distinto de cero.

Diagnóstico y corrección de un 204 accidental a nivel de página

Si un rastreador (Screaming Frog, Ahrefs Site Audit) o tus registros muestran un 204 en una página que debería tener contenido:

1. Confirma qué recibe realmente Googlebot. Usa la Inspección de URL de Search Console para ver el estado y el contenido renderizado que recibe Google, no solo lo que ve tu navegador. Una CDN, un worker de borde, un WAF o una ruta de la aplicación puede devolver 204 a los bots o en condiciones concretas aunque a ti te parezca correcta (el mismo patrón de «en mi navegador se ve bien» que aparece con un 403 inesperado).
2. Después corrige según la intención:
   • La página debe existir con contenido → encuentra la lógica del servidor/CDN/aplicación que emite 204 y recupera un 200 correcto con el cuerpo real.
   • La página ha desaparecido sin sustituto → devuelve 404 o 410.
   • La página se ha trasladado → 301 a la URL nueva.
3. Monitoriza. Observa el informe de Indexación de páginas de GSC para detectar entradas soft 404, vigila los códigos de estado de rastreo en tus registros y configura tu rastreador para señalar los 204, de modo que uno accidental en una plantilla no desindexe silenciosamente toda una sección.

Quédate con este modelo mental: 204 no es «malo». Es una herramienta precisa, correcta para endpoints de API y beacons y equivocada para documentos. El fallo solo consiste en usarlo en el lugar incorrecto. Sus hermanos, como 403, 404, 410 y soft 404, tienen cada uno su lugar en esa decisión; el lugar de 204 está fuera de la página.

Resumen con IA

Una síntesis de la versión avanzada:

• 204 No Content es un código de éxito 2xx (RFC 9110 §15.3.5) que devuelve un cuerpo vacío por diseño. No es un error y no dice nada sobre si existe una URL. El RFC no lo restringe a una lista fija de métodos: DELETE/PUT y los beacons son patrones habituales, no un requisito, y 204 en un GET es legal según el protocolo.
• El cuerpo debe estar vacío, sin excepciones. Según MDN, un 204 no debe incluir contenido ni una cabecera Content-Length; RFC 9110 §8.6 prohíbe Content-Length por completo, así que Content-Length: 0 tampoco cumple la especificación. Las cabeceras que sí lleve un 204 describen la representación seleccionada después de la acción, no un cuerpo transferido. Un 204 se puede almacenar heurísticamente en caché por defecto, pero no todos incluyen un ETag: el ejemplo de MDN lo lleva para un caso específico de PUT, no como regla universal.
• Consecuencia SEO (acotada con precisión): la documentación de Google sobre códigos de estado dice claramente que, para un 204, “Google wasn’t able to receive any content and therefore can’t process it.” (traducción) «Google no pudo recibir ningún contenido y, por tanto, no puede procesarlo». Eso permite una inferencia razonable: una página que quieres posicionar no se indexará a partir de esa respuesta; pero Google no garantiza una etiqueta soft 404 concreta ni un calendario de retirada, y usar 204 no recupera automáticamente el presupuesto de rastreo ni demuestra un efecto en las posiciones. Como dice Patrick en sus propios textos: “204s will be treated as soft 404s and won’t be indexed” (traducción) «los 204 se tratarán como soft 404 y no se indexarán», el patrón práctico que ha observado, aunque la formulación oficial precisa sea más limitada.
• Los usos legítimos son sobre todo para respuestas que no son documentos: DELETE/PUT de API REST y beacons de analítica (sendBeacon(), protocolo de medición GA4). GA4 devuelve 204 incluso para hits mal formados, así que un beacon 204 no demuestra que el hit se procesara. Los profesionales tampoco están completamente de acuerdo aquí: Postman trata 204 como la opción predeterminada para acciones sin nada que devolver, mientras Brandur Leach considera que un éxito vacío puede perjudicar ligeramente a clientes que esperan una representación; es un debate de ergonomía de API, no de corrección HTTP.
• 204 nunca es correcto para una página posicionable. Desaparecida sin sustituto → 404/410; trasladada → 301; debe tener contenido → corrige el servidor/CDN que emite 204 y recupera un 200 real. Confirma qué recibe Googlebot mediante la Inspección de URL.

Documentación oficial

Referencias de fuentes primarias sobre qué es 204 y cómo lo gestiona Google.

Especificación HTTP y referencia del navegador

• RFC 9110 §15.3.5 — 204 No Content — la definición autorizada: éxito, sin cuerpo de payload ni trailers, almacenamiento heurístico en caché y cabeceras que describen la representación seleccionada después de la acción.
• RFC 9110 §8.6 — Content-Length — la regla que prohíbe por completo Content-Length en una respuesta 204, no solo cuando es distinto de cero.
• MDN — 204 No Content — explicación en lenguaje claro, limitación del cuerpo vacío y Content-Length, almacenamiento en caché, un ejemplo específico de ETag y el caso de uso de guardar sin salir de la página.

Google Search Central

• Cómo afectan los códigos de estado HTTP, la red y los errores de DNS a la Búsqueda de Google — la tabla de códigos de estado que menciona específicamente 204 y la definición de soft 404 de Google.

Beacons y analítica (los casos legítimos de 204)

• W3C — Beacon — la especificación de navigator.sendBeacon() que espera un 204 de los endpoints de beacons.
• Google Analytics 4 — Measurement Protocol reference — el endpoint de recopilación de GA4 cuyas respuestas (incluido un 204 para los hits aceptados) se documentan aquí.

Citas de la fuente

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

La especificación HTTP

• “The 204 (No Content) status code indicates that the server has successfully fulfilled the request and that there is no additional content to send in the response payload body.” (traducción) «El código de estado 204 (No Content) indica que el servidor ha cumplido correctamente la solicitud y que no hay contenido adicional que enviar en el cuerpo del payload de respuesta». — RFC 9110, HTTP Semantics, §15.3.5. Leer la sección

MDN Web Docs

• “The HTTP 204 No Content successful response status code indicates that a request has succeeded, but the client doesn’t need to navigate away from its current page. A 204 response is cacheable by default, and an ETag header is included in such cases.” (traducción) «El código de respuesta correcta HTTP 204 No Content indica que una solicitud se ha completado correctamente, pero el cliente no necesita salir de su página actual. Una respuesta 204 se puede almacenar en caché por defecto y en esos casos incluye una cabecera ETag». Ir a la cita

Google Search Central — gestión de 2xx/204

• “Google wasn’t able to receive any content and therefore can’t process it.” (traducción) «Google no pudo recibir ningún contenido y, por tanto, no puede procesarlo». — documento de Google sobre códigos de estado HTTP, fila del 204 en la tabla de 2xx (en contraste con la regla general 2xx, donde «Google considers the content for processing» (traducción) «Google considera el contenido para procesarlo»). Documento de Google sobre códigos de estado

Patrick Stox — Ahrefs

• “Most 2xxs will allow pages to be indexed. However, 204s will be treated as soft 404s and won’t be indexed.” (traducción) «La mayoría de los códigos 2xx permiten indexar páginas. Sin embargo, los 204 se tratarán como soft 404 y no se indexarán». — de mi guía Códigos de estado HTTP y su impacto en el SEO. Ir a la cita

Matt G. Southern — la revista Search Engine Journal

• “The exception is a 204 status code, which means the page was successfully accessed but no content was found. Google may show a soft 404 in Search Console for pages serving a 204 code.” (traducción) «La excepción es un código de estado 204, que significa que se accedió correctamente a la página, pero no se encontró contenido. Google puede mostrar un soft 404 en Search Console para las páginas que sirven un código 204». Ir a la cita

204 legítimos frente a accidentales

Casos concretos de dónde encaja un 204 y dónde es un error.

Correcto: DELETE de una API REST

Un cliente elimina un recurso; no hay nada que devolver.

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

HTTP/1.1 204 No Content

No hay cuerpo ni Content-Length. Es la respuesta idiomática y nunca debería ser una URL que esperes ver en las búsquedas.

Correcto: beacon de analítica (sendBeacon)

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

El endpoint no tiene ninguna página que servir, así que 204 es exactamente lo correcto. Lo mismo ocurre con el endpoint del protocolo de medición de GA4; recuerda que GA4 devuelve 204 incluso para hits mal formados, así que un 204 confirma que el endpoint respondió, no que tu hit se procesara.

Incorrecto: una página de contenido que devuelve 204

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

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

Google recibe un cuerpo vacío, trata la URL como un soft 404 y no la indexa. La solución depende de la intención:

• Debe existir con contenido → restaura 200 OK con el cuerpo real (corrige el servidor/CDN/aplicación que emite 204).
• Desaparecida sin sustituto → 404 o 410.
• Trasladada → 301 a la URL nueva.

Regla práctica: si se supone que una persona debe llegar a la URL y leer algo, debe devolver 200 con un cuerpo. Reserva 204 para endpoints máquina a máquina —API y beacons— donde de verdad no haya nada que mostrar.

Diagnosticar un 204 inesperado

Una página aparece en blanco y el panel Network muestra 204

Síntoma: una URL de documento que debería mostrar contenido devuelve 204 No Content.

Causa probable: el enrutamiento de la aplicación, una regla de CDN, un worker de borde o un controlador de errores está emitiendo la respuesta correcta de estilo API en una ruta de página.

Solución: sigue la solicitud a través de la capa que controla la respuesta. Si la página debe existir, restaura un 200 con un cuerpo real. Confirma la solución con una nueva solicitud de cabeceras y recarga el navegador con la caché desactivada.

Search Console informa de un soft 404 para una URL 204

Síntoma: la URL queda excluida como soft 404 aunque 204 sea un código de éxito.

Causa probable: la clasificación se refiere al contenido ausente, no a si el código empieza por 2. Un 204 no tiene cuerpo por definición.

Solución: elige la respuesta según la intención: 200 con contenido para una página real, 301 para un traslado o 404/410 para una página desaparecida. Vuelve a ejecutar la Inspección de URL después de desplegar el cambio.

El navegador y el rastreador no coinciden sobre el estado

Síntoma: la página se ve normal en un navegador, pero un rastreador o una entrada de registro muestra 204.

Causa probable: la respuesta varía por bot, método, ubicación geográfica, caché, WAF o lógica de borde.

Solución: compara GET y HEAD, las solicitudes normales y las que usan el agente de usuario de Googlebot, y la solicitud exacta en los registros del servidor/CDN. Corrige la regla condicional y verifica después que ambas rutas devuelvan la misma respuesta prevista.

Clasificar un conjunto de URL 204 según su intención

Pega una exportación de rastreo o registros que incluya la URL, el método de solicitud, el tipo de contenido, el referente o tipo de ruta y el código de respuesta.

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

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

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

PASTE ROWS HERE

Encontrar respuestas 204 accidentales

Inspeccionar una URL y el método de solicitud

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

La solicitud del documento no debería ser 204 si la URL debe mostrar contenido. Prueba GET y HEAD porque los controladores defectuosos específicos de un método pueden no coincidir.

Comparar la respuesta predeterminada con la del agente de usuario de Googlebot

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

Un 204 con cero bytes descargados solo en una ruta apunta a una lógica condicional del servidor, la CDN o el WAF. Usa registros reales y la Inspección de URL para confirmar qué recibió Google realmente.

Informar de los 204 de una lista de URL

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

Ejecuta esto en macOS, Linux o WSL con una URL por línea en urls.txt. Revisa cada resultado según la intención de la ruta; los 204 de API y beacons no son errores.

Herramientas para separar los 204 legítimos de los accidentales

Herramienta gratuita de Patrick

• Bulk HTTP Status Code Checker — comprueba hasta 500 URL, filtra los resultados por 204 y exporta el conjunto afectado. Usa la ruta y el contexto del contenido para separar los endpoints válidos de API/beacon de las URL de página que deberían devolver contenido.

Confirmar la causa

• Inspección de URL de Google Search Console — prueba una URL de página en vivo para ver qué puede recuperar Google después de cambiar la respuesta.
• Registros del servidor/CDN — identifica si 204 varía por método, agente de usuario, ruta o ubicación de borde.
• Panel Network de las DevTools del navegador — distingue la solicitud del documento de las llamadas API y beacons en segundo plano; un 204 en un beacon puede ser correcto, mientras que un 204 en el documento no lo es.
• Un rastreador de todo el sitio — inventaría las URL de documentos que devuelvan 204 y mantendría la comprobación en auditorías periódicas para que una regresión de plantilla no afecte a toda una sección.

Ponte a prueba: 204 No Content

Cinco preguntas rápidas sobre qué significa un 204 y cuándo es correcto. Elige una respuesta para cada una y luego comprueba el resultado.

Registro de cambios