¿Qué son los códigos de estado HTTP?

Los códigos de estado forman parte del protocolo HTTP, que explica la entrada sobre HTTP de este glosario. El RFC 9110, publicado por el IETF en junio de 2022, define los códigos válidos entre 100 y 599 y los agrupa en cinco clases según la primera cifra. Las dos últimas cifras no indican ninguna categoría.

- 1xx, informativos: la petición se ha recibido y el proceso sigue. - 2xx, éxito: la petición se ha recibido, entendido y aceptado. - 3xx, redirección: hace falta otro paso para completar la petición, normalmente pedir otra dirección. - 4xx, error del cliente: la petición tiene un error o no se puede atender, por ejemplo porque pide una página que no existe. - 5xx, error del servidor: la petición parecía válida, pero el servidor no ha podido atenderla.

La primera cifra dice, por tanto, de quién es el problema. Un 4xx señala la petición, un 5xx señala al servidor.

El RFC 9110 obliga a todo cliente a entender la clase de un código, aunque no conozca el código concreto. Un código desconocido se trata como el x00 de su clase: un 299 que nadie conoce se lee como un 200, y un 599 como un 500.

Los códigos más habituales, el 200 de éxito, la redirección permanente 301 y el 404 de página no encontrada, se explican en la entrada sobre HTTP. Junto a ellos hay otros con consecuencias para el SEO:

- 304 Not Modified: el cliente ha preguntado si su copia sigue valiendo y el servidor responde que sí, sin enviar contenido. - 307 y 308: redirecciones temporal y permanente, como el 302 y el 301. Con el 302 y el 301, por razones históricas, el cliente puede convertir un POST en un GET al seguir la redirección; el RFC indica el 307 y el 308 para cuando no se quiere ese cambio. El 308 es de junio de 2014, mucho más reciente que los demás. - 410 Gone: el recurso ya no está disponible y probablemente no volverá. Según el RFC, si el servidor no sabe si la ausencia es definitiva, debe usar el 404. - 429 Too Many Requests: el cliente ha enviado demasiadas peticiones en poco tiempo. Lo define el RFC 6585, de abril de 2012. - 503 Service Unavailable: el servidor no puede atender la petición por una sobrecarga temporal o un mantenimiento programado. Puede añadir la cabecera Retry-After para indicar cuándo volver.

Google decide con el código qué hace con cada URL. En su documentación explica que un 2xx no garantiza la indexación, que el 307 equivale al 302 y el 308 al 301, y que con un 304 sus rastreadores indican al sistema siguiente que el contenido no ha cambiado desde el último rastreo.

En los 4xx, Google trata todos los códigos igual salvo el 429: no usa el contenido, no indexa las URL nuevas y elimina del índice las que ya estaban. Para Google, por tanto, un 410 y un 404 tienen el mismo efecto, aunque su significado en el RFC sea distinto. El 429, en cambio, cuenta como señal de que el servidor está sobrecargado, igual que un 5xx, y hace que los rastreadores reduzcan temporalmente el ritmo de rastreo.

Para reducir el rastreo durante poco tiempo, por ejemplo si el sitio está fuera de servicio, Google recomienda devolver un 500, un 503 o un 429 durante unas horas o uno o dos días, y acepta la cabecera Retry-After con el 503 y el 429. Si los mismos errores se repiten varios días en una URL, puede eliminarla del índice.

En zds.es lo medimos el 15 de octubre de 2026. Pedimos las 1.389 URL del sitemap sin seguir redirecciones, y las 1.389 respondieron 200. Una dirección inventada devolvió un 404 real, y una fuente tipográfica pedida otra vez con su ETag devolvió un 304.

• Devolver a cada URL el código que describe su estado real, no uno que parezca más favorable.
• Usar 410 cuando un contenido se ha retirado a propósito y 404 cuando no se sabe si volverá.
• Programar los mantenimientos con un 503 y la cabecera Retry-After, y no alargarlos más de uno o dos días.
• Dejar en el sitemap solo URL que respondan 200.
• Comprobar los códigos con una petición directa, por ejemplo con curl, porque el navegador sigue las redirecciones sin mostrarlas.

• Responder con un 200 a una página de error, que Google puede tratar como soft 404.
• Esperar que un 410 saque una URL del índice antes que un 404, cuando Google trata los dos igual.
• Usar 401 o 403 para frenar a los rastreadores: según Google, esos códigos no afectan al ritmo de rastreo.
• Dejar un 503 de mantenimiento activo durante semanas.
• Confundir un 5xx, que es un problema del servidor, con un 4xx, que se refiere a la petición.