Definición:
El código de estado HTTP 200 OK indica que una solicitud se ha completado correctamente. El significado concreto de la respuesta depende del método utilizado: ante una petición GET suele incluir una representación del recurso; ante HEAD devuelve los mismos encabezados que GET, pero sin cuerpo; y ante POST puede comunicar el resultado de la acción.
Un 200 confirma el resultado satisfactorio de la solicitud desde el punto de vista del protocolo. No demuestra por sí solo que el contenido sea correcto, que la página pueda indexarse, que cargue rápido o que el usuario haya recibido la respuesta esperada.
Cómo funciona una respuesta 200 OK
Un cliente, como un navegador, un rastreador o una aplicación, envía una solicitud a un servidor mediante HTTP. El servidor procesa la petición y devuelve una respuesta compuesta por un código de estado, encabezados y, cuando corresponde, un cuerpo.
La especificación HTTP Semantics define 200 OK como una respuesta satisfactoria cuyo contenido depende del método. Una respuesta 200 puede incluir, entre otros elementos, el tipo de contenido, instrucciones de caché, validadores como ETag o Last-Modified y la representación solicitada.
200 OK no significa que se hayan transferido necesariamente «todos los datos». Una petición puede solicitar una representación concreta, estar condicionada por autenticación, negociación de contenido o parámetros, o devolver el resultado de una operación. Tampoco mide la eficiencia de la transmisión.
Diferencias entre 200 OK y otros códigos 2xx
Los códigos 2xx indican que la solicitud tuvo un resultado satisfactorio, pero no son intercambiables:
- 200 OK: la solicitud se completó y la respuesta contiene la representación o el resultado que corresponde al método.
- 201 Created: la operación creó uno o más recursos y la respuesta debería identificar el recurso principal creado.
- 204 No Content: la operación se completó, pero no hay contenido que enviar en el cuerpo de la respuesta.
- 206 Partial Content: el servidor entrega una parte del recurso como respuesta a una solicitud de rango válida.
Otros códigos de la familia responden a situaciones más específicas. Por ejemplo, 202 Accepted indica que el procesamiento ha sido aceptado pero puede no haber terminado, mientras que 203, 205, 207 y 208 tienen semánticas propias. Elegir un código por pertenecer a la familia 2xx no sustituye la comprobación de si describe realmente el resultado.
Código 200 OK y SEO
Para los buscadores, recibir un 200 permite procesar el contenido de la URL. Sin embargo, no garantiza su indexación ni su posicionamiento.
- Rastreo: el servidor entregó una respuesta satisfactoria, pero el rastreador todavía debe interpretar el contenido y las directivas aplicables.
- Indexación: el contenido puede pasar a los sistemas de indexación, aunque puede excluirse por canonicalización,
noindex, duplicidad, calidad u otras señales. - Soft 404: una URL puede devolver 200 y mostrar una página vacía, un mensaje de error o contenido que indica que el recurso no existe. Google puede tratarla como un error 404.
- Cambios de URL: una página trasladada no debería mantener un 200 en la dirección antigua si corresponde señalar el cambio mediante una redirección 301.
La documentación de Google sobre códigos HTTP explica que una respuesta 2xx permite considerar el contenido para su procesamiento, pero no asegura que vaya a indexarse. Un 200 incorrecto puede ocultar errores a usuarios, buscadores y sistemas de monitorización.
Cómo comprobar una respuesta 200 OK
El código puede revisarse en las herramientas de desarrollo del navegador, mediante una solicitud de línea de comandos, en los registros del servidor o con un rastreador técnico. Conviene comprobar la respuesta final después de todas las redirecciones y no limitarse a la apariencia visual de la página.
El diagnóstico debe relacionar el estado con el contenido y la intención de la URL. Una página válida puede responder 200; un recurso creado puede requerir 201; una respuesta sin cuerpo puede usar 204; una URL trasladada necesita el código de redirección adecuado; y un recurso inexistente debe comunicarlo con un estado de error pertinente.
También deben revisarse las variantes de URL, los parámetros, los dispositivos, las cabeceras de caché y las respuestas de CDN o proxy. Corregir el código sin corregir el contenido, la ruta o la configuración que lo genera puede mantener el problema.