Idiomas

Códigos de error HTTP

Cómo afectan al SEO los códigos de error HTTP 4xx y 5xx: cómo trata Google los errores, cuáles provocan desindexación, desperdicio de rastreo o pérdida de posicionamiento, y cómo monitorizarlos y corregirlos.

Publicado por primera vez: 27 jun 2026 · Última actualización: 22 ago 2026 · Avanzado
Idiomas
AIEscrito porAI v2
1 señal de evidencia en esta página

Los códigos de error HTTP son las respuestas 4xx del cliente y 5xx del servidor que se devuelven en lugar de una respuesta 2xx correcta. Google trata ambas familias de forma distinta: los 4xx, salvo 429, indican que el contenido no existe y eliminan la URL del índice sin afectar a la frecuencia de rastreo; los 5xx y 429 indican un fallo del servidor, por lo que Google limita primero el rastreo de todo el sitio y solo elimina páginas si el problema persiste. Un 404 blando devuelve 200 aunque parezca una página no encontrada. Los 404 no son una señal de calidad ni una penalización; prioriza por enlaces, sitemap y tráfico. Para una interrupción planificada usa 503 con Retry-After y nunca lo apliques a robots.txt. Este centro enlaza las guías de 401, 403, 410, 451, 500, 502 y 504, además del resto de códigos de la familia.

TL;DR — Los códigos de error HTTP son las clases de estado 4xx (cliente) y 5xx (servidor). Google traza una línea de comportamiento clara entre ellas: 4xx (excepto 429) significa «el contenido no existe» —la URL se elimina del índice, con «no afecta a la frecuencia de rastreo»—; 5xx (y 429) significa «el servidor está fallando»: Google limita el rastreo de forma proporcional, conserva al principio las URL indexadas y solo las desindexa si los errores persisten, después vuelve a aumentar la frecuencia gradualmente tras la recuperación. 429 es numéricamente un 4xx, pero Google lo llama «un error del servidor». Se ignora el contenido de cualquier respuesta de error. Los 404 no son una señal de calidad (Mueller): prioriza por enlaces y tráfico, no intentes corregirlo todo, y recuerda que el impacto real de un error aislado depende de la URL (robots.txt tiene un tratamiento especial que una página normal no tiene). Google marca los 404 blandos (un 200 que se lee como «no encontrado») porque desperdician presupuesto de rastreo: es sobre todo un problema de sitios grandes, no un efecto garantizado en todos los sitios. Para una interrupción planificada usa 503 + Retry-After, durante «como máximo unos días», y nunca devuelvas 503 para robots.txt. Monitoriza la familia mediante el informe de indexación de páginas de GSC. Este hub enlaza y orienta hacia cada código individual.

La distinción que recorre todo el tema

El código del protocolo describe el resultado HTTP; una etiqueta de Search Console describe cómo Google clasificó una obtención observada. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: RFC 9110: Status codes No deduzcas una única causa raíz ni un momento exacto de eliminación solo a partir de la familia. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: Google: HTTP and network errors

Cuando la gente habla de errores, cuatro capas se reducen a «es un 404»; mantenerlas separadas es lo que hace comprensible el resto de esta página:

  1. Semántica del protocolo: qué significa el código de estado según la especificación HTTP (un 404 significa «no encontrado», punto).
  2. La obtención observada: lo que Googlebot recibió realmente en una solicitud concreta y en un momento concreto, que puede diferir de lo que ve un navegador.
  3. Procesamiento de búsqueda: cómo el pipeline de indexación de Google clasifica y trata esa obtención (elimina la URL, limita el rastreo, ignora el cuerpo).
  4. Causa raíz: el motivo real en tu servidor (un despliegue defectuoso, una base de datos sobrecargada o una regla del WAF), que el código de estado por sí solo nunca te indica.

Saber la familia (4xx frente a 5xx) te dice cuál de las tres primeras capas estás viendo. Nunca sustituye a la cuarta: aún tienes que averiguar por qué ocurrió.

La documentación de Google presenta claramente la división, y vale la pena interiorizarla antes de cualquier otra cosa: “4xx errors say “the content doesn’t exist”; 5xx errors say “the server itself is failing.”” (traducción) «Los errores 4xx dicen que el contenido no existe; los errores 5xx dicen que el propio servidor está fallando». Son dos problemas completamente distintos y el pipeline de indexación de Google responde a ellos de dos maneras completamente distintas.

Un punto de referencia útil: ni siquiera un código de éxito es una promesa. Google dice claramente que “for Google Search, an HTTP 2xx (success) status code doesn’t guarantee indexing.” (traducción) «para Google Search, un código de estado HTTP 2xx (success) no garantiza la indexación». En realidad, los códigos de error son la parte más determinista del panorama: le dicen a Google, sin ambigüedad, «desaparecido» o «averiado».

Cómo trata Google los errores 4xx

Para los errores del cliente, el comportamiento de Google es uniforme y tajante: “Google doesn’t use the content from URLs that return 4xx status codes,” (traducción) «Google no usa el contenido de las URL que devuelven códigos de estado 4xx», y “Google crawlers inform the next processing system that the content doesn’t exist.” (traducción) «los rastreadores de Google informan al siguiente sistema de procesamiento de que el contenido no existe». Aunque tu página 403 o 404 renderice una gran cantidad de texto real, nada de ello se indexa: se ignora el cuerpo de una respuesta de error.

De aquí se desprenden dos consecuencias:

  • Las URL que ya estaban indexadas se eliminan. Cuando una página devuelve 4xx de forma fiable, Google la elimina del índice con el tiempo.
  • No hay una penalización de frecuencia de rastreo. Este es el mito que conviene desmontar: “The 4xx status codes, except 429, have no effect on crawl rate.” (traducción) «Los códigos de estado 4xx, excepto 429, no afectan a la frecuencia de rastreo». Una montaña de 404 no ralentiza el rastreo de Google del resto de tu sitio.

Ese último punto elimina un mal instinto: no intentes limitar Googlebot con un 401 o un 403. Google advierte explícitamente “don’t use 401 and 403 status codes for limiting the crawl rate.” (traducción) «no uses los códigos de estado 401 y 403 para limitar la frecuencia de rastreo». Una barrera de autenticación no ralentiza el rastreo; solo vuelve invisible el contenido.

Cómo trata Google los errores 5xx (y el 429)

Los errores del servidor activan la rama de «el servidor tiene problemas», y aquí Google protege deliberadamente tu sitio:

  • Primero limita la frecuencia de rastreo, de forma proporcional al volumen. “5xx and 429 server errors prompt Google’s crawlers to temporarily slow down with crawling,” (traducción) «los errores de servidor 5xx y 429 hacen que los rastreadores de Google ralenticen temporalmente el rastreo», y “the decrease in crawl rate is proportionate to the number of individual URLs that are returning a server error.” (traducción) «la disminución de la frecuencia de rastreo es proporcional al número de URL individuales que devuelven un error de servidor». Un puñado de errores 500 apenas se nota; una caída de todo el sitio reduce mucho el rastreo.
  • Las URL indexadas se conservan… hasta que persisten los errores. “Already indexed URLs are preserved in the index, but eventually dropped,” (traducción) «las URL ya indexadas se conservan en el índice, pero finalmente se eliminan», y Google “removes from the index URLs that persistently return a server error.” (traducción) «elimina del índice las URL que devuelven persistentemente un error del servidor». Un fallo breve no te desindexa; un fallo sostenido sí.
  • También se ignora el contenido de los 5xx. “Any content Google receives from URLs that return a 5xx status code is ignored.” (traducción) «se ignora cualquier contenido que Google reciba de URL que devuelvan un código de estado 5xx».
  • La recuperación es automática, pero gradual. “Once the server starts responding with a 2xx status code, Google gradually increases the crawl rate for the site.” (traducción) «cuando el servidor empieza a responder con un código de estado 2xx, Google aumenta gradualmente la frecuencia de rastreo del sitio». Google retrocede rápido y vuelve a subir con cautela: no hay un «desbloqueo» manual; corrige la causa raíz y espera.

Por qué el 429 pertenece a la categoría de errores del servidor

Este es el matiz que más se omite en las guías. 429 Too Many Requests es numéricamente un 4xx, pero Google lo trata como una señal del servidor: “Google’s crawlers treat the 429 status code as a signal that the server is overloaded, and it’s considered a server error.” (traducción) «los rastreadores de Google tratan el código de estado 429 como una señal de que el servidor está sobrecargado y se considera un error del servidor». Así que un WAF o limitador de frecuencia que empiece a devolver 429 a Googlebot limitará tu rastreo igual que una oleada de 500, no eliminará páginas individuales como hace un 404. Cuando desgloso los códigos en mi guía de códigos de estado HTTP de Ahrefs, coloco el 429 junto a los errores del servidor precisamente por este motivo: es «una forma de limitación de frecuencia para proteger el servidor» y hace que Google reduzca el ritmo.

Mapa de familias de códigos de error

Esta es la vista rápida de triaje de toda la familia. Cada código tiene su propio análisis profundo anidado bajo este hub (también aparecen en la barra lateral):

Errores de bloqueo y acceso

  • 401 Unauthorized: el cliente no se ha identificado ni verificado cuando era necesario. Googlebot queda bloqueado detrás de una solicitud de autenticación.
  • 403 Forbidden: el cliente es conocido, pero no tiene permisos de acceso.

Errores de página no encontrada

  • 404 Not Found: no se encuentra el recurso solicitado.
  • 404 frente a 410: la diferencia práctica entre «no encontrado» y «eliminado» (es menor de lo que la gente cree).
  • 410 Gone: como un 404, pero también indica que el recurso no volverá. Elimina las páginas ligeramente más rápido.

El código de doble identidad

  • 429 Too Many Requests: limitación de frecuencia; numéricamente es 4xx, pero Google lo trata como un error del servidor a efectos de la frecuencia de rastreo.

Legal

  • 451 No disponible por motivos legales: bloqueado por un motivo legal: bloqueos por país o retiradas de DMCA.

Errores del servidor (5xx)

  • 500 Internal Server Error: el servidor encontró un problema que no puede gestionar.
  • 502 Bad Gateway: una respuesta incorrecta de un servidor ascendente.
  • 503 Service Unavailable: el servidor está sobrecargado o en mantenimiento (el código correcto para una interrupción planificada).
  • 504 Gateway Timeout: no hubo una respuesta a tiempo de un servidor ascendente.

El caso trampa

  • 404 blando: una página que devuelve 200 OK pero se lee como «no encontrado». Lo peor de ambos mundos; más abajo se explica.

Las redirecciones rotas están relacionadas con los errores, pero se clasifican por separado (Google las muestra como «Redirect error» en Search Console, distinto de una «Page with redirect» normal y funcional). De forma predeterminada, los rastreadores de Google «siguen hasta 10 saltos de redirección» antes de rendirse; una cadena demasiado larga, un bucle o una URL defectuosa se convierte en ese estado de error de redirección.

¿Un error HTTP perjudica tu SEO?

Empieza por el veredicto: un error aislado en una página normal casi nunca es un problema, y los 404 en concreto no son una señal de posicionamiento ni de calidad. Mueller lo ha dicho de forma explícita y repetida. El reflejo de pensar «tengo 50 000 errores 404, mi sitio debe estar penalizado» es el mito número uno que hay que desmontar. Los errores son una parte normal de la web; que una página devuelva 404 o 410 es la forma técnicamente correcta de gestionar URL que no existen.

«Aislado» no significa «siempre inofensivo», pero el impacto real depende de lo que devuelve el error. Un 404 de una página normal no es nada; un recurso especial es diferente. Google tiene reglas de tratamiento propias para robots.txt, distintas de las URL normales, así que un error del servidor en robots.txt puede afectar al rastreo de una forma que el 404 de una página normal nunca haría. Juzga un error por la URL en la que aparece y por lo que depende de ella, no solo por el código de estado.

El patrón con un mecanismo real y documentado es el 5xx persistente y masivo: limitación de la frecuencia de rastreo → desindexación final. Incluso eso es proporcional al número de URL que devuelven errores y generalmente reversible cuando el servidor se recupera. Google describe la recuperación como gradual, no instantánea, así que trata el momento exacto, la cadencia de reintentos y la velocidad de recuperación como cuestiones dependientes de la evidencia (lo que describen los documentos de Google), no como garantías fijas. La distinción de Mueller que debes recordar es que la frecuencia de rastreo reacciona a errores del servidor (429/500/503/tiempos de espera), no a los 404.

Desperdicio de rastreo frente a desindexación: dos daños distintos

Conviene separar las dos formas en que los errores pueden perjudicarte:

  • Desindexación: 4xx persistentes (la página se elimina como «desaparecida») o 5xx persistentes (las páginas se eliminan después de un fallo sostenido del servidor). Se trata de páginas que salen del índice.
  • Desperdicio de presupuesto de rastreo: principalmente un problema de sitios grandes. La guía de presupuesto de rastreo de Google señala que “if the site slows down or responds with server errors, the limit goes down and Google crawls less.” (traducción) «si el sitio se ralentiza o responde con errores del servidor, el límite baja y Google rastrea menos». Pero el verdadero desperdicio de presupuesto es el 404 blando: “soft 404 pages will continue to be crawled, and waste your budget.” (traducción) «las páginas 404 blandas seguirán rastreándose y desperdiciarán tu presupuesto». Como un 404 blando parece activo (devuelve 200), Google sigue comprobando una página que en realidad no está ahí. Por eso es el peor caso: no desaparece limpiamente como un 404 real, sino que permanece y consume solicitudes.

La trampa del 404 blando tiene dos causas comunes: una plantilla personalizada de «página no encontrada» que devuelve 200 en lugar de un 404 real, y una redirección general de cada URL muerta a la página de inicio. Google también reconoce ese patrón como un 404 blando. Una página 404 amigable es buena para la experiencia de usuario y está plenamente recomendada, siempre que siga devolviendo el código de estado HTTP 404 real.

Cómo hacer correctamente una interrupción planificada

Cuando intencionadamente desconectas un sitio (o una sección), el código correcto es 503 Service Unavailable con una cabecera Retry-After; nunca un 4xx. La guía de Google «Pausa tu negocio online» es específica:

  • “If you need to urgently disable the site for 1-2 days, then return an informational error page with a 503 HTTP response status code.” (traducción) «si necesitas desactivar urgentemente el sitio durante 1–2 días, devuelve una página de error informativa con un código de estado de respuesta HTTP 503».
  • “This is an extreme measure that should only be taken for a very short period of time (a few days at most),” (traducción) «es una medida extrema que solo debería adoptarse durante un periodo muy corto (como máximo unos días)», porque “completely closing a site even for just a few weeks can have negative consequences on Google’s indexing of your site.” (traducción) «cerrar completamente un sitio aunque solo sea durante unas semanas puede tener consecuencias negativas para la indexación que Google hace de tu sitio».
  • “Don’t block the website by returning 403, 404, 410 HTTP status codes” (traducción) «no bloquees el sitio web devolviendo códigos de estado HTTP 403, 404 o 410» durante una interrupción: un 4xx dice «desaparecido permanentemente», exactamente la señal equivocada para una caída temporal.
  • La trampa que casi todos pasan por alto: “Don’t return a 503 HTTP response status code for the robots.txt file because this blocks all crawling.” (traducción) «no devuelvas un código de estado de respuesta HTTP 503 para el archivo robots.txt porque esto bloquea todo el rastreo». Devuelve 503 para tus páginas, no para robots.txt.

Cómo monitorizar toda la familia en Search Console

En el día a día encontrarás estos errores en el informe de indexación de páginas de Search Console, donde cada uno corresponde a un estado distinto:

  • No encontrado (404): “this page returned a 404 error when requested.” (traducción) «esta página devolvió un error 404 al solicitarla».
  • Error del servidor (5xx): “your server returned a 500-level error when the page was requested.” (traducción) «tu servidor devolvió un error de nivel 500 al solicitar la página».
  • Bloqueada por una solicitud no autorizada (401): “the page was blocked to Googlebot by a request for authorization.” (traducción) «la página fue bloqueada para Googlebot por una solicitud de autorización».
  • Bloqueada por acceso prohibido (403): un 403 en el que se proporcionaron credenciales, pero no se concedió el acceso.
  • Bloqueada por otro problema 4xx: un 4xx no cubierto por otro estado; usa la inspección de URL para depurarlo.
  • 404 blando: un mensaje «amigable para el usuario de “no encontrado”, pero no un código de respuesta HTTP 404».
  • Error de redirección: cadena demasiado larga, un bucle, una URL demasiado larga o una URL incorrecta dentro de la cadena.

Cada estado apunta a una causa raíz y un camino de corrección diferentes. Cuando hayas resuelto uno, usa Validar corrección para solicitar un nuevo rastreo, pero mantén expectativas realistas sobre el tiempo: el nuevo rastreo no es instantáneo. Y recuerda el enfoque de Google: “it’s fine for a URL not to be indexed for the right reasons — for example… a 404 for a page that you’ve removed and have no replacement for.” (traducción) «está bien que una URL no se indexe por las razones correctas, por ejemplo… un 404 de una página que has eliminado y para la que no tienes sustituto». No todos los errores son una tarea pendiente.

Search Console por sí sola no basta para actuar: es un punto de vista muestreado y retrasado. Cuando registres un error para triaje, anota como mínimo la URL, cuándo lo observaste, el punto de observación (Search Console frente a una comprobación en directo frente a logs del servidor/CDN), el user agent con el que llegó la solicitud, el método HTTP, el código de estado final y la ruta de respuesta (incluida cualquier cadena de redirección), si es puntual o recurrente y un paso de verificación posterior a la corrección una vez que hayas vuelto a desplegar. Contrastar GSC con una comprobación de estado en directo y tus propios logs convierte una fila obsoleta del informe en un problema confirmado y corregible.

Cómo corregir y priorizar los errores

  • Prioriza los 404 por valor. Corrige los que tienen enlaces entrantes, enlaces internos, presencia en el sitemap o tráfico persistente; redirígelos con 301 a una página relevante para recuperar la autoridad de los enlaces. Deja que las URL realmente muertas devuelvan 404 o 410. Como digo en mi guía de Ahrefs, la corrección práctica para la mayoría es que “you just need to 301 redirect each of these pages to a relevant page” (traducción) «solo necesitas redirigir con 301 cada una de estas páginas a una página relevante», pero únicamente cuando exista un destino relevante. No redirijas todo indiscriminadamente a la página de inicio (eso es un 404 blando).
  • 410 frente a 404 es marginal. Un 410 elimina una página ligeramente más rápido que un 404; la diferencia práctica de SEO es pequeña. Usa 410 cuando quieras dejar claro que algo desapareció para siempre, pero no esperes que sea mucho mejor.
  • Errores 5xx en la causa raíz. Las correcciones están en el servidor: capacidad y tiempos de espera para 500, salud del upstream/CDN para 502/504 y reglas de WAF o limitación de frecuencia que estén bloqueando por error a Googlebot para 403/429. Confirma el bot real con una comprobación DNS inversa/directa antes de limitarlo.
  • Causas raíz comunes que conviene nombrar: errores de la aplicación y de la base de datos y hosts sobrecargados (5xx), fallos del upstream/CDN (502/504), limitación de frecuencia o WAF que bloquea bots (403/429), migraciones rotas y enlaces internos obsoletos (404), y páginas de error «amigables» mal configuradas (404 blando).

Bing: un patrón similar, no verificado código por código de forma independiente

Las declaraciones públicas de Bing apuntan en la misma dirección que el enfoque de Google: los códigos del rango 400 se tratan como ausentes o prohibidos y los del rango 500 indican problemas del servidor que perjudican la eficiencia del rastreo. Sin embargo, no he verificado de forma independiente una paridad completa y actual, código por código, con la documentación propia de Bing, así que debes tratarlo como una orientación y no como una equivalencia confirmada uno a uno. Fabrice Canel presenta el objetivo de Bing como “crawl efficiency north star … to crawl a URL only when the content has been added … updated” (traducción) «la estrella polar de la eficiencia de rastreo… rastrear una URL solo cuando se ha añadido contenido… actualizado», y los errores persistentes van directamente en contra de eso: Bing gasta capacidad de rastreo en URL que no producen contenido nuevo e indexable. Bing también recomienda un 503 con Retry-After para interrupciones planificadas en lugar de servir páginas de error como 200. Encontrarás las superficies de errores de rastreo de Bing en Bing Webmaster Tools (inspección de URL, control de rastreo y Site Scan).

Dónde continuar

Esta página es el hub conceptual de la familia de códigos de error. Está dentro del cluster más amplio de Códigos de estado HTTP (el panorama completo 1xx–5xx, además de redirecciones y códigos de éxito); este subhub es el mapa de la mitad de los errores. Cada código tiene su propio análisis profundo:

Bloqueo / acceso

  • 401 Unauthorized: qué activa el estado «Blocked due to unauthorized request» y por qué las barreras de autenticación no limitan Googlebot.
  • 403 Forbidden: credenciales proporcionadas pero acceso denegado, y los patrones de WAF/bloqueo de bots que provocan falsos 403 para Googlebot.

No encontrado

  • 404 Not Found: cómo trata Google las páginas ausentes, por qué no es una penalización y qué 404 conviene corregir.
  • 404 frente a 410: la diferencia real y pequeña, y cuándo elegir cada uno.
  • 410 Gone: la señal de «desaparecido permanentemente» y su eliminación ligeramente más rápida.

Limitación de frecuencia

  • 429 Too Many Requests: el 4xx que se comporta como un 5xx y cómo evitar que los límites de frecuencia ralenticen tu rastreo.

Legal

  • 451 No disponible por motivos legales: retiradas, bloqueos por país y cómo aparecen las eliminaciones legales.

Errores del servidor

  • 500 Internal Server Error: el fallo genérico del servidor y cómo encontrar su causa raíz.
  • 502 Bad Gateway: fallos del upstream/proxy.
  • 503 Service Unavailable: el código correcto para mantenimiento e interrupciones planificadas (con la trampa de robots.txt).
  • 504 Gateway Timeout: tiempos de espera del upstream.

El caso trampa

  • 404 blando: el 200 que se lee como desaparecido, por qué desperdicia el presupuesto de rastreo y cómo convertirlo en un 404 real.

Las redirecciones rotas se gestionan por separado como estado Redirect error: están relacionadas, pero se clasifican por sí solas en Search Console.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.