El código de respuesta 200, o HTTP 200 OK, indica que una petición al servidor se ha procesado correctamente. Al solicitar una página mediante GET, lo habitual es recibir su contenido en la respuesta. No es un error HTTP ni garantiza que toda la web funcione, esté indexada o tenga buen posicionamiento.
Si una herramienta muestra «error 200», comprueba el contexto: una aplicación puede utilizar sus propios códigos o devolver un mensaje de error dentro de una respuesta HTTP satisfactoria. Aquí hablamos del estado HTTP de páginas y recursos web.
Qué significa 200 OK según la petición
El resultado depende del método utilizado. GET recupera un recurso; HEAD devuelve sus cabeceras sin el cuerpo; POST puede devolver información sobre una acción procesada. No todas las operaciones correctas deben responder con 200: existen otros estados de éxito.
La referencia de MDN sobre 200 OK explica estas diferencias. Para revisar una página, interesa comprobar la petición del documento principal y también si los recursos necesarios se descargan correctamente.
Cómo comprobar el código de una página
Desde el navegador
- Abre las herramientas de desarrollador de tu navegador.
- Entra en el panel de red, normalmente llamado Network o Red.
- Recarga la página y localiza la petición del documento principal.
- Revisa la URL solicitada, el estado y las cabeceras de la respuesta.
- Comprueba si hubo redirecciones y qué dirección terminó cargándose.
El nombre exacto de los controles depende del navegador. No confundas el 200 de una imagen o de una petición de analítica con el estado del documento HTML. Si la herramienta agrupa las peticiones, filtra por documentos.
En una auditoría de varias URLs
Un rastreador permite agrupar estados, detectar redirecciones y localizar errores. Guarda la dirección inicial y la final. Una URL antigua que redirige no responde directamente con 200 aunque el destino sí lo haga.
Para una comprobación técnica con curl, una petición GET que descarta el cuerpo y muestra las cabeceras puede hacerse con curl -sS -D - -o /dev/null https://example.com/. Sustituye el dominio por la página que estás revisando. Una comprobación HEAD puede comportarse de forma diferente en servidores mal configurados.
Por qué un 200 no garantiza indexación
El código confirma una respuesta satisfactoria a esa petición, pero Google todavía debe poder procesar el contenido y decidir su indexación. Una página puede devolver 200 y contener noindex, declarar otra URL canónica o mostrar información insuficiente.
Comprueba por separado disponibilidad, contenido e indexación. Search Console ayuda a revisar el estado conocido por Google; el navegador muestra la respuesta que recibes en ese momento. Los resultados pueden diferir si hubo cambios recientes.
Qué es un soft 404
Un soft 404 puede aparecer cuando una URL responde con 200, pero muestra una página inexistente, vacía o con un mensaje de error. La respuesta técnica y lo que recibe el visitante no coinciden. Google describe este escenario en su guía de errores de rastreo.
Ejemplo hipotético: eliminas un artículo y su dirección sigue mostrando «contenido no encontrado» con estado 200. No has conservado el artículo; has mantenido una respuesta engañosa para la revisión técnica. Corrige el comportamiento según lo que realmente deba ocurrir con esa URL.
200, redirecciones y errores: cuándo corresponde cada uno
- 200: el recurso solicitado se entrega correctamente.
- 301 o 308: traslado permanente a otro destino.
- 404 o 410: el recurso no está disponible o se ha retirado, según el caso.
- 500: el servidor encuentra un problema interno.
- 503: indisponibilidad temporal del servicio.
No fuerces todos los estados a 200 para que una auditoría parezca limpia. El estado debe describir la situación. La documentación de Google sobre códigos HTTP explica cómo afectan al rastreo.
La página devuelve 200, pero algo falla
Revisa qué está fallando: ¿falta contenido?, ¿no carga una imagen?, ¿el formulario no registra la solicitud?, ¿se ve una versión antigua? Comprueba la respuesta concreta relacionada con el problema y los mensajes de la aplicación, no solo el código de la portada.
En un formulario, recibir 200 no demuestra por sí solo que el correo haya llegado o que el contacto se haya guardado en el CRM. Verifica el recorrido completo. Con caché, contrasta fecha, contenido y cabeceras antes de atribuir el problema al estado HTTP.
Preguntas frecuentes sobre el código 200
¿Es bueno para SEO?
Es el estado habitual de una página disponible, pero no una ventaja de posicionamiento por sí misma. Debe acompañarse de contenido accesible, útil y correctamente configurado.
¿Todas las URLs deben devolver 200?
No. Las páginas retiradas, los traslados y los errores necesitan respuestas coherentes con su situación. Revisa también los posibles duplicados y versiones canónicas.
¿Qué reviso si no encuentro la causa?
Documenta la URL, el momento, la respuesta y el fallo visible. Una auditoría técnica SEO puede relacionar los estados con contenido, rastreo e indexación para priorizar la corrección.
