200 OK: qué significa

TL;DR — Una respuesta 200 OK es el servidor diciendo «aquí está la página que pediste, todo está bien». Es el código de éxito discreto que quieres en cada página que te gustaría mostrar en Google. Pero un 200 por sí solo no garantiza que la página se indexe: Google aún comprueba si el contenido merece indexarse. Y un 200 en una página que en realidad está rota o vacía es un error, no una luz verde.

Qué significa 200 OK

Cada vez que tu navegador o Googlebot pide una página a un servidor, el servidor responde con un código de estado de tres dígitos antes de enviar cualquier otra cosa. 200 OK es el de «todo bien»: el servidor encontró lo que pediste y lo devuelve, normalmente con el contenido de la página incluido. (Técnicamente, la especificación permite un 200 con un cuerpo vacío en algunos casos, pero para una página que quieres que la gente lea necesitas un cuerpo real cada vez). Es el código que casi nunca notas porque significa que nada salió mal. Evidence for this claim RFC 9110 defines 200 OK as indicating that the request succeeded; the response content depends on the request method. Scope: HTTP semantics for 200 responses; this does not guarantee search indexing. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.3.1 — 200 OK

Patrick Stox lo resume en tres palabras en la guía de códigos de estado HTTP de Ahrefs: “200 OK – All good. Everything is successful.” (traducción) «200 OK: todo bien. Todo funciona correctamente».

Para las páginas de tu sitio que quieres que la gente encuentre en las búsquedas, 200 es exactamente el código que quieres que devuelvan.

Por qué un 200 no cuenta toda la historia

Esta es la parte que la mayoría de las páginas sobre «qué significa 200» omiten: un 200 hace que tu página sea considerada para la indexación, pero no garantiza que entre en el índice. Son dos cosas muy distintas.

Piensa en el 200 como el billete que te deja entrar. Una vez dentro, Google aún decide si merece la pena conservar el contenido: ¿es de alta calidad?, ¿es casi un duplicado de otra página?, ¿es escaso o está vacío?, ¿tiene una etiqueta noindex que le dice a Google que no entre? Cualquiera de esas circunstancias puede hacer que una página con un 200 perfectamente saludable no se indexe.

Así que, si una página devuelve 200 pero no aparece en Google, el problema no es el código de estado: es el contenido o la configuración.

La trampa: un 200 que en realidad significa «no encontrado»

El error más engañoso es una página que devuelve 200, pero cuyo contenido dice «esto no existe». Un producto agotado con una página en blanco, un artículo eliminado que aún carga una plantilla vacía o una página de resultados de búsqueda sin resultados: el servidor envía un alegre 200, pero no hay nada real ahí.

Google va más allá del código y mira el contenido real, decide que la página está vacía o es un error y la etiqueta como un soft 404 en Search Console, tratándola igual que una página «no encontrada» real. El artículo sobre errores soft 404 lo explica en profundidad; la versión corta es: si una página ha desaparecido de verdad, debe devolver 404 o 410, no 200.

La única regla que debes recordar

Una página que quieras en Google debe devolver 200 con contenido real. Si la página ha desaparecido, usa 404 o 410. Si se ha trasladado, redirígela (301). Si es un duplicado de otra página, usa una etiqueta canónica. ¿Quieres la formulación exacta de Google, la diferencia entre 200 y 204 y cómo comprobar qué recibió realmente Googlebot? Cambia a la pestaña Avanzado.

TL;DR — 200 OK es el código de éxito estándar de la familia 2xx (RFC 9110 §15.3.1): el servidor cumplió la solicitud y, para GET/HEAD, el cuerpo es una representación del recurso. Por defecto se puede almacenar en caché heurísticamente. Para SEO es necesario, pero no suficiente: la documentación de Google dice que “may index the content, but that’s not guaranteed,” (traducción) «la documentación deja abierta la indexación, pero no la garantiza»; Google también evalúa la calidad, la duplicación, la escasez y la directiva noindex además del 200. El fallo clásico es el soft 404: un 200 que envuelve contenido vacío o de error, que Google detecta en la capa de contenido e informa como soft 404 independientemente del código. Contrasta 200 (se espera un cuerpo) con 204 (cuerpo vacío, tratado como soft 404 en páginas) y 304 (una señal de caché, no una decisión de indexación). Y confirma qué recibió Googlebot: el encubrimiento, el bloqueo de bots, las reglas geográficas y la configuración de CDN/WAF pueden servirle un código distinto del que ve tu navegador.

Qué significa 200 en la especificación

RFC 9110 (HTTP Semantics) es la autoridad actual y §15.3.1 es tajante: “The 200 (OK) status code indicates that the request has succeeded.” (traducción) «El código de estado 200 (OK) indica que la solicitud se ha completado correctamente». Lo que contiene el cuerpo depende del método de solicitud. Para los métodos importantes en las páginas —GET y HEAD— el contenido es una representación del recurso objetivo. El RFC también lo matiza: salvo las respuestas a CONNECT, se espera que un 200 lleve contenido, a menos que el encuadre del mensaje indique explícitamente una longitud cero; por tanto, «un 200 siempre tiene cuerpo» es una forma abreviada de decirlo, no una verdad absoluta. En la práctica, para una página que quieres indexar, ese resumen es el objetivo: un cuerpo real, no uno vacío. Además, un 200 se puede almacenar en caché «heurísticamente» por defecto, salvo que una directiva de control de caché diga lo contrario; por eso las cabeceras de validación como ETag y Last-Modified importan en páginas que se vuelven a rastrear mucho. Evidence for this claim RFC 9110 defines 200 OK as indicating that the request succeeded; the response content depends on the request method. Scope: HTTP semantics for 200 responses; this does not guarantee search indexing. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.3.1 — 200 OK

Técnicamente, 200 no se usa solo para páginas. El RFC explica qué significa «éxito» para cada método:

En los métodos que no son GET a menudo no verás un 200: MDN señala que las solicitudes PUT o DELETE correctas “often do not result in a 200 OK response,” (traducción) «a menudo no dan como resultado una respuesta 200 OK», y que 201 Created o 204 No Content son más habituales. Nada de eso es relevante para el SEO de las URL de páginas; la frase que debes conservar es que, para un documento que quieres indexar, el objetivo es 200 con un cuerpo real.

Necesario, pero no suficiente, para la indexación

Esto es lo más importante que debes entender bien y donde la mayoría de las páginas de glosario de la competencia se equivocan por completo. Dicen que «200 significa que la página se indexa». La documentación de Google dice otra cosa. Para un 200, Google “passes on whatever it received to the next processing step… For Google Search, the next system is the indexing pipeline. The indexing systems may index the content, but that’s not guaranteed.” (traducción) «Google entrega lo recibido al paso siguiente; el contenido puede indexarse, pero no hay garantía». Evidence for this claim Google passes a 2xx response to its indexing pipeline, which may index the content but does not guarantee that it will do so; error-like content can be classified as a soft 404. Scope: Google Search handling of 2xx page responses and soft 404s. Confidence: high · Verified: 2026-07-14 Google: HTTP status codes and Search

Así que el 200 es un contrato sobre la respuesta HTTP, no una promesa sobre el destino de la página en la Búsqueda. Después del 200, Google evalúa por separado:

• Calidad — las páginas escasas, de poco valor o generadas automáticamente quizá no se indexen.
• Duplicados — un duplicado casi idéntico de una URL más sólida puede integrarse en esa URL en lugar de indexarse por separado (esto es lo que ayuda a controlar la etiqueta canónica).
• Directivas — un noindex en una etiqueta meta o en una cabecera X-Robots-Tag mantiene la página fuera incluso con un 200 perfecto.

La guía de Ahrefs de Patrick marca la misma distinción a nivel de familia: las respuestas 2xx suelen permitir la indexación, pero una 204 se trata como soft 404 y no se indexa. El 200 hace que una página sea apta; no hace que esté indexada.

La trampa del soft 404

La ilustración más clara de que «200 no cuenta toda la historia» es el soft 404. La documentación de Google sobre códigos de estado explica el mecanismo: “If the content suggests an error for Google Search, an empty page or an error message, Search Console will show a soft 404 error.” (traducción) «Si el contenido sugiere un error para la Búsqueda de Google, una página vacía o un mensaje de error, Search Console mostrará un error soft». Observa lo que significa: la clasificación se basa en el contenido renderizado, no en el código HTTP. El pipeline de indexación de Google mira más allá del 200, comprueba lo que hay realmente en la página y, si parece «no encontrado», la incluye en la misma categoría y la informa como un 404 real.

Los casos que debes comprobar: un producto descatalogado cuya página ahora carga una plantilla vacía, un artículo eliminado que aún devuelve una carcasa 200, una página de categoría filtrada o un resultado de búsqueda sin elementos y con un mensaje de «no hay nada aquí». Todos devuelven un 200 técnicamente correcto mientras dicen tanto a los usuarios como a Google que no hay nada que ver.

Este sitio tiene un artículo específico sobre errores soft 404 para explicar la detección y las soluciones; no las repetiré aquí. La idea clave para la conversación sobre 200 es sencilla: devolver 200 en una página que ha desaparecido de verdad es la preparación para un soft 404. La solución es hacer que el código coincida con la realidad.

Otra trampa relacionada: el éxito del transporte no es el éxito de la aplicación

Conviene hacer una aclaración acotada porque aparece en los círculos de las API y la monitorización: la capa HTTP y la capa de aplicación pueden discrepar. Un endpoint de API puede enviar 200 con un objeto JSON de error en el cuerpo; una página puede enviar 200 mientras una dependencia del backend ha fallado silenciosamente y ha renderizado un bloque roto en lugar del contenido real. La línea de estado dice «entregado correctamente»; eso es todo lo que afirma. Que el payload sea correcto es otra cuestión que el código de estado no responde. Los profesionales están realmente divididos sobre si una API debe señalar un error con un estado distinto de 200 o con un 200 que envuelva un payload de error; es un contrato que elige cada equipo, no una regla HTTP. Para el enfoque SEO de este sitio, la versión del mismo problema a nivel de página es el soft 404 anterior: la solución sigue el mismo principio, no confíes solo en la línea de estado y mira qué contiene realmente el cuerpo.

200 frente a 204 y 304: no los confundas

Hay tres códigos que la gente mezcla y solo uno de ellos es el éxito de «aquí tienes tu página»:

204 es un código de éxito genuino, pero su cuerpo vacío no deja nada que indexar a un rastreador; por eso, en una URL de página, cae en la categoría de soft 404 (es otro artículo; no confundas el caso de cuerpo vacío con un 200 normal). 304 ni siquiera pertenece a la misma familia: responde a una solicitud condicional (If-None-Match / If-Modified-Since) indicando al cliente que su copia en caché sigue vigente. No lleva cuerpo y no dice nada sobre si se debe indexar; es un mecanismo de eficiencia de rastreo, no un duplicado de 200. La pregunta habitual «200 frente a 304, ¿no son la misma idea?» confunde una optimización de caché con una respuesta de éxito.

Confirma qué ve realmente Googlebot

Este es un vacío que casi todos los artículos de la competencia omiten: distintos solicitantes pueden recibir códigos distintos para la misma URL. Tu navegador puede ver un 200 limpio mientras Googlebot recibe otra cosa, a veces deliberadamente (encubrimiento, una infracción de las Search Essentials de Google) y más a menudo por accidente debido a reglas de WAF o bloqueo de bots, segmentación geográfica por IP, lógica de borde de la CDN o una configuración de pruebas A/B que falla para los bots.

Así que «en mi navegador es 200» no demuestra que «Google vea 200». El diagnóstico correcto es comprobar qué recibió Googlebot:

• Inspección de URL de GSC — ejecuta una prueba en tiempo real para ver el estado y el contenido renderizado que obtiene Google, no lo que ve tu máquina.
• Registros del servidor/CDN — la fuente de verdad sobre qué código recibió realmente cada agente de usuario.

Un curl -I normal desde tu terminal es útil, pero es otro solicitante que puede encontrarse con reglas de borde distintas de las de Googlebot; trátalo como un dato, no como la última palabra.

Cómo comprobar y monitorizar respuestas correctas

• DevTools del navegador — pestaña Network, recarga, haz clic en la solicitud del documento y lee la columna Status.
• Línea de comandos — curl -I https://example.com/page para las cabeceras de una sola solicitud, curl -IL para seguir la cadena de redirecciones.
• Google Search Console — Inspección de URL informa del estado rastreado y permite hacer una prueba en tiempo real.
• Bing Webmaster Tools — su herramienta de Inspección de URL es la forma de Bing de confirmar qué recibió Bingbot. (Bing no publica un documento específico sobre «cómo afectan los códigos de estado a la indexación» como hace Google; prefiero decir eso antes que inventar una política de Bing).
• Rastreadores — Screaming Frog y Ahrefs Site Audit muestran códigos de estado de todo el sitio en bloque; la barra SEO gratuita de Ahrefs muestra el código de la página que estás viendo.

Una URL importante y canónica devuelve un 200 de forma constante con contenido real; las páginas que deberían haber desaparecido o haberse trasladado devuelven 404/410 o 301, en lugar de un 200 engañoso.

La decisión en una línea

Haz que el código coincida con la realidad. En el índice → 200 con contenido sustancial. Desaparecida para siempre → 404 o 410 (consulta el artículo sobre el código 404). Trasladada → 301. Duplicada de otra URL → señala con una etiqueta canónica la versión preferida en lugar de intentar forzar un código que no sea 200. El 200 es la luz verde para las páginas que realmente lo merecen: ni más ni menos.

Resumen con IA

Una síntesis de la versión Avanzada:

• 200 OK es el código de éxito estándar de la familia 2xx (RFC 9110 §15.3.1): el servidor cumplió la solicitud y, para GET/HEAD, el cuerpo representa el recurso. El almacenamiento en caché puede aplicarse de forma heurística por defecto. El RFC presenta el cuerpo como algo esperado, no absoluto: un 200 de longitud cero es técnicamente válido, aunque una página que quieres indexar necesita uno real.
• Necesario, pero no suficiente, para la indexación. La documentación de Google dice que los sistemas de indexación “may index the content, but that’s not guaranteed.” (traducción) «pueden indexar el contenido, pero no está garantizado». La calidad, los duplicados, el contenido escaso y noindex se juzgan además del 200. La mayoría de las páginas de la competencia se equivoca al decir «200 = indexado».
• La trampa del soft 404: un 200 que envuelve contenido vacío o de error se detecta en la capa de contenido y se informa como soft 404 en Search Console: «if the content suggests an error… Search Console will show a soft 404 error» (traducción) «si el contenido sugiere un error… Search Console mostrará un error soft 404». Un 200 en una página desaparecida de verdad prepara este resultado. Consulta el artículo sobre errores soft 404.
• Una trampa paralela: la capa HTTP y la de aplicación pueden discrepar: un 200 puede envolver un payload de error de API o un bloque del backend roto silenciosamente. La línea de estado solo afirma que el transporte tuvo éxito, no que el payload sea correcto.
• 200 frente a 204 y 304: 200 = éxito con un cuerpo real (apto para indexación); 204 = éxito con un cuerpo vacío, tratado como soft 404 en URL de páginas (consulta 204-no-content); 304 = señal de caché que responde a una solicitud condicional, no una decisión de indexación.
• Confirma qué recibió Googlebot. Distintos solicitantes pueden ver códigos distintos para una URL por encubrimiento, bloqueo de bots, reglas geográficas o configuración de CDN/WAF. «200 en mi navegador» ≠ «Google ve 200». Compruébalo mediante la prueba en tiempo real de Inspección de URL de GSC o los registros del servidor, no solo con un navegador o curl.
• Haz que el código coincida con la realidad: la quieres → 200 con contenido real; desaparecida → 404/410; trasladada → 301; duplicada → etiqueta canónica. Como dice Patrick: “200 OK – All good. Everything is successful.” (traducción) «200 OK: todo funciona correctamente», para una página que realmente merece estar ahí.

Documentación oficial

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

Especificación HTTP y referencia del navegador

• RFC 9110 §15.3.1 — 200 OK — la definición autorizada: la solicitud se completó correctamente, semántica del cuerpo según el método y almacenamiento heurístico en caché.
• MDN — 200 OK — explicación en lenguaje claro, almacenamiento en caché por defecto y el matiz de PUT/DELETE (201/204 son habituales en su lugar).

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 formulación sobre 2xx (“may index the content, but that’s not guaranteed” (traducción) «puede indexar el contenido, pero no está garantizado») y la referencia cruzada al soft 404.
• Soft 404 errors — Page indexing report — la definición de Google sobre el error que en realidad es un 200 y por qué devolver un código de éxito para una página desaparecida es una mala práctica.
• Cloaking — por qué una URL puede servir un código o contenido a los usuarios y otro a Googlebot, y por qué hacerlo para manipular las posiciones es una infracción.

Bing / Microsoft

• Bing Webmaster Tools — URL Inspection — la forma de Bing de confirmar la respuesta HTTP que Bingbot recibió para una URL. (No existe un documento escrito por Bing sobre «cómo afectan los códigos de estado a la indexación»).

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 200 (OK) status code indicates that the request has succeeded.” (traducción) «El código de estado 200 (OK) indica que la solicitud se ha completado correctamente». — RFC 9110, HTTP Semantics, §15.3.1. Leer la sección

MDN Web Docs

• “The HTTP 200 OK success status response code indicates that a request has succeeded. A 200 OK response is cacheable by default.” (traducción) «El código de respuesta de éxito HTTP 200 OK indica que una solicitud se ha completado correctamente. Una respuesta 200 OK se puede almacenar en caché por defecto». Ir a la cita

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

• “Google passes on whatever it received to the next processing step (which is product specific). For Google Search, the next system is the indexing pipeline. The indexing systems may index the content, but that’s not guaranteed.” (traducción) «Google pasa lo que recibió al siguiente paso de procesamiento (que depende del producto). Para la Búsqueda de Google, el siguiente sistema es el pipeline de indexación. Los sistemas de indexación pueden indexar el contenido, pero no está garantizado». — Documento de Google sobre códigos de estado HTTP, entrada sobre 200. Documento de Google sobre códigos de estado

• “If the content suggests an error for Google Search, an empty page or an error message, Search Console will show a soft 404 error.” (traducción) «Si el contenido sugiere un error para la Búsqueda de Google, una página vacía o un mensaje de error, Search Console mostrará un error soft 404». — el mismo documento, referencia cruzada del soft 404. Documento de Google sobre códigos de estado

Patrick Stox — Ahrefs

• “200 OK – All good. Everything is successful.” (traducción) «200 OK: todo salió bien». — de mi guía de códigos de estado HTTP en el blog de Ahrefs. Ir a la cita

• “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 estos códigos permite indexar páginas. Sin embargo, las respuestas sin contenido se tratan como errores soft y no se indexan». — de la misma guía, sobre cómo gestiona Google la familia 2xx. Ir a la cita

200 OK — referencia rápida

Qué es

200 frente a sus hermanos confundidos

¿Qué código debería devolver esta URL?

• La quieres en el índice → 200 con contenido real y sustancial.
• Ha desaparecido para siempre → 404 o 410 (consulta el artículo sobre el código 404).
• Se ha trasladado a una URL nueva → 301.
• Es un duplicado de otra URL → conserva el 200 y añade una etiqueta canónica a la versión preferida.
• Está vacía a propósito (API/baliza) → 204 (consulta 204-no-content): nunca en una página.

Datos rápidos

• Un 200 hace que una página sea apta para la indexación, no que esté indexada: Google decide por separado según la calidad, los duplicados, el contenido escaso y noindex.
• Un 200 en una página que en realidad ha desaparecido o está vacía es un soft 404 para Google.
• Distintos solicitantes pueden ver códigos distintos para una URL: confirma qué recibió Googlebot mediante la Inspección de URL de GSC o los registros del servidor, no solo con un navegador o curl.
• Comprueba los códigos con la pestaña Network de DevTools, curl -I / curl -IL, la Inspección de URL de GSC/Bing, Screaming Frog o Ahrefs Site Audit/Toolbar.

Mitos habituales sobre 200 OK

“A 200 status code means the page is indexed.” (traducción) «Un código de estado 200 significa que la página está indexada». Falso. 200 significa que el servidor devolvió contenido correctamente; la indexación es una decisión posterior independiente. La propia documentación de Google dice que los sistemas de indexación “may index the content, but that’s not guaranteed.” (traducción) «pueden indexar el contenido, pero no está garantizado». La calidad y la duplicación, la escasez de contenido y la directiva noindex también influyen después del 200.

“If Search Console shows a soft 404, my server has a bug.” (traducción) «Si Search Console muestra un soft 404, mi servidor tiene un error». No necesariamente. Soft 404 no es un código que envíe tu servidor: es una etiqueta que Google aplica según la discrepancia entre el estado 200 y un contenido que parece un error o una página vacía. El servidor hace exactamente lo que se configuró para hacer (enviar 200); el contenido es el problema, no la cabecera.

“200 is always good, full stop.” (traducción) «200 siempre es bueno, punto». No siempre. Un 200 en una URL que debería haber devuelto 404 —un producto eliminado, un anuncio caducado o una página de resultados de búsqueda vacía— es activamente malo. Invita al tratamiento como soft 404 y puede desperdiciar esfuerzo de rastreo al volver a visitar una URL sin nada que ofrecer.

“My browser shows 200, so Google definitely sees 200 too.” (traducción) «Mi navegador muestra 200, así que Google también ve 200, sin duda». No está garantizado. El bloqueo de bots, el encubrimiento, las reglas geográficas basadas en IP y la configuración de CDN/WAF pueden servir a Googlebot una respuesta distinta de la que recibe un navegador humano. Verifícalo mediante la Inspección de URL o los registros del servidor.

“200 and 204 are basically the same — both mean success.” (traducción) «200 y 204 son básicamente lo mismo: ambos significan éxito». Los dos son 2xx, pero 204 tiene un cuerpo vacío por diseño. Está bien para API y balizas, y es incorrecto para una página que quieres indexar: un 204 en una URL de página se trata como soft 404 (consulta 204-no-content).

“200 vs 304 — aren’t those the same idea?” (traducción) «200 frente a 304: ¿no son la misma idea?» No. 304 Not Modified es un mecanismo de caché que responde a una solicitud condicional (If-None-Match / If-Modified-Since) y dice al cliente que use su copia en caché. No lleva cuerpo y no es una decisión de indexación: es un concepto distinto de 200.

Por qué una página 200 OK aún puede fallar

Search Console llama soft 404 a la URL

Síntoma: la URL devuelve 200, pero la Indexación de páginas informa de que es un soft 404.

Causa probable: el cuerpo de la respuesta parece vacío, roto o una página de error. Los casos habituales son un producto descatalogado sin información útil, un artículo eliminado dentro de una plantilla por lo demás completa o una página de búsqueda sin resultados.

Solución: haz que la respuesta coincida con la realidad. Recupera contenido sustancial si la página debe existir, devuelve 404 o 410 si ha desaparecido o usa 301 si se ha trasladado. Vuelve a ejecutar la prueba en tiempo real de la Inspección de URL y confirma que la respuesta y el contenido renderizado coincidan.

Tu navegador obtiene 200, pero Googlebot no

Síntoma: DevTools o curl muestra 200, mientras Google no puede obtener ni indexar la URL.

Causa probable: una CDN, WAF, regla geográfica, regla para bots o experimento sirve una respuesta diferente a Googlebot. Tu propia solicitud no demuestra qué recibió Google.

Solución: compara una solicitud normal con otra que use un agente de usuario de Googlebot y después comprueba la Inspección de URL y los registros del servidor/CDN. Corrige la regla del borde y confirma que la prueba en tiempo real recibe 200 con el mismo cuerpo sustancial que reciben los usuarios.

La página es 200, pero aún no está indexada

Síntoma: el código de estado es saludable, pero la URL sigue excluida del índice.

Causa probable: 200 solo hace que el contenido sea apto para el procesamiento. Un noindex, un conflicto entre duplicados y la URL canónica o un contenido de poco valor aún pueden mantenerlo fuera.

Solución: deja de cambiar el código de estado. Comprueba las directivas de indexación, la URL canónica que ha seleccionado Google y el contenido real. Una respuesta HTTP correcta no es un veredicto de indexación.

Respuestas 200 que cuentan una historia equivocada

Son ejemplos simplificados. La línea de estado es técnicamente correcta, pero el cuerpo determina si ese éxito es honesto.

Carcasa de producto vacía: 200 engañoso

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

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

Si el producto ha desaparecido permanentemente y no hay sustituto, devuelve 404 o 410. Si queda una página de producto útil —especificaciones, alternativas, asistencia o información de disponibilidad— 200 aún puede ser adecuado porque la página tiene una finalidad real.

Artículo eliminado con sustituto: usa una redirección

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

Una página 200 generada por plantilla que dice «artículo eliminado» deja a los usuarios sin salida e invita a una clasificación como soft 404. Un sustituto relevante debe ser el destino de una 301 del lado del servidor.

Búsqueda interna sin resultados: útil o vacía

Un 200 puede ser honesto cuando la página ayuda a los usuarios a reformular la búsqueda, explorar categorías o encontrar alternativas. Una página escasa que solo contiene «0 resultados» parece un error pese al código de éxito. La diferencia está en la utilidad del cuerpo, no en el número 200.

Clasifica las respuestas 200 sospechosas

Pega una exportación del rastreo con URL, estado, título, URL canónica, indexabilidad y una muestra breve del texto del cuerpo. Este prompt separa el éxito HTTP de los problemas de contenido e indexación.

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

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

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

PASTE CRAWL ROWS HERE

Comprueba la respuesta en lugar de fiarte de la página

Inspecciona una respuesta con curl

Ejecuta estos comandos en macOS, Linux o WSL. El primero lee las cabeceras de respuesta; el segundo descarga también el cuerpo para que puedas verificar que 200 contiene contenido real.

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

Busca una línea de estado 200 y después abre page.html. Las cabeceras por sí solas no pueden revelar un soft 404.

Compara una solicitud normal con un 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"

Una diferencia es motivo para inspeccionar las reglas y los registros de CDN/WAF, no una prueba de que Googlebot recibiera la respuesta de la solicitud suplantada. Confirma la obtención real en la Inspección de URL.

Comprueba una lista de respuestas que no sean 200

Pon una URL por línea en urls.txt:

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

Esto detecta discrepancias de estado evidentes. No puede juzgar si un cuerpo 200 es sustancial, así que revisa después las plantillas sospechosas y los informes de soft 404.

Herramientas para validar respuestas 200

Herramienta gratuita de Patrick

• Bulk HTTP Status Code Checker — pega hasta 500 URL para recopilar códigos de estado, destinos finales, cadenas de redirección y latencia en una sola exportación. Úsalo para encontrar URL que en realidad no devuelven 200; después inspecciona el cuerpo y Search Console por separado para detectar errores soft, porque un comprobador de estados no puede juzgar la calidad ni la indexación del contenido.

Evidencia del buscador y del servidor

• Inspección de URL de Google Search Console — compara el resultado indexado con una obtención en tiempo real y revisa el contenido renderizado que Google puede recuperar.
• Inspección de URL de Bing Webmaster Tools — comprueba la respuesta que Bingbot informa haber recibido.
• Registros del servidor y CDN — confirma qué código de estado recibieron las solicitudes reales de los rastreadores; los registros son una evidencia más sólida que cambiar una cadena de agente de usuario en curl.
• Panel Network de DevTools del navegador — verifica la solicitud del documento, las cabeceras de respuesta y el cuerpo de la sesión del navegador que tienes delante.

Ponte a prueba: 200 OK

Cinco preguntas rápidas sobre qué significa 200 para el SEO. Elige una respuesta para cada una y después compruébala.

Registro de cambios