Bloqueado por otro error 4xx

TL;DR — «Blocked due to other 4xx issue» en Google Search Console es la categoría residual de errores de cliente que no aparecen separados como 401, 403 o 404. Googlebot pidió tu página y recibió otro error 4xx (como 400, 410 o 451), así que la página no puede indexarse. Google no publica una lista exacta de los códigos que llegan aquí: tu primer trabajo es averiguar qué código es realmente, porque la corrección depende por completo de ello.

Qué significa este estado

Esta categoría de Search Console cubre una respuesta 4xx que no está representada por los tipos de problema más específicos del informe. Evidence for this claim The Page Indexing report uses this category for a 4xx issue not covered by its other issue types. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: Page indexing report Google trata las respuestas 4xx distintas de 429 como contenido no disponible para la indexación. Evidence for this claim Google treats 4xx responses other than 429 as if the content does not exist; 429 is handled as a server-overload signal. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: HTTP status codes

Cuando abres el informe de Page Indexing en Search Console y ves «Blocked due to other 4xx issue», significa que Googlebot intentó recuperar la URL y tu servidor respondió con un error de cliente 4xx, pero uno que no coincide con las categorías específicas que Google ya enumera por separado. Google separa 401 (se requiere iniciar sesión), 403 (prohibido) y 404 (no encontrado) en sus propias filas. La redacción de Google para esta fila es «a 4xx error not covered by any other issue type» (traducción) «un error 4xx no cubierto por ningún otro tipo de problema»; no publica un mapa exhaustivo de cada código que termina en esta categoría. En la práctica, 400, 405, 408, 410 Gone, 411, 413, 414, 421, 422 y 451 son códigos que suelen aparecer, pero trátalos como candidatos probables que debes comprobar, no como una garantía de lo que encontrarás.

Como Google recibió un error en lugar de la página, no puede leer su contenido, por lo que la página no se indexará; si antes estaba indexada, se retirará.

La etiqueta es un cajón de sastre: encuentra el código real

Esta es la parte que confunde a la gente. «Other 4xx» es una categoría, no un diagnóstico. Un 410 Gone (eliminaste una página deliberadamente) y un 400 Bad Request (una URL rota) pueden acabar en la misma fila, pero la respuesta correcta es opuesta en cada caso. Por eso, antes de «corregir» nada, encuentra el código de estado real:

• En Search Console, usa URL Inspection y pulsa Test live URL para ver qué está recibiendo Google actualmente.
• Abre la página en la pestaña DevTools → Network del navegador y mira el código de estado, o recupérala desde la línea de comandos con curl -I.
• Comprueba los registros del servidor para ver qué código recibió realmente Googlebot.

¿Es realmente un problema?

A veces «other 4xx» funciona como debe. Un 410 Gone en una página que eliminaste definitivamente es un comportamiento correcto; solo es un problema si la página aparece en un sitemap o todavía recibe enlaces cuando no debería. Pero si una página que quieres indexar devuelve algún 4xx extraño, es un error real que debes corregir en su origen.

Una nota rápida sobre 429

Quizá hayas leído que 429 («too many requests», una limitación de velocidad) pertenece aquí. Google trata 429 como una señal de sobrecarga del servidor, no como un error de cliente normal, y lo usa para ralentizar el rastreo en vez de retirar directamente tu página. La documentación de Google no dice en qué fila de Page Indexing aparece realmente una URL con 429, así que tampoco supongas que queda excluida de esta categoría. En cualquier caso, no desactives la limitación de velocidad para «corregir» un estado de other-4xx; encontrarás más información en la pestaña Advanced.

¿Quieres la guía completa de corrección código por código, el matiz de 429, el detalle de 410 frente a 404 y el árbol de decisión para el diagnóstico? Pasa a la pestaña Advanced.

TL;DR — «Blocked due to other 4xx issue» es la fila residual del informe de Indexación de páginas: un 4xx que recibió Googlebot y que no aparece separado como tipo de problema propio (401/403/404). Google no publica un mapa exhaustivo de cada código que llega a esta fila; 400, 405, 408, 410, 411, 413, 414, 421, 422, 451, etc. son ramas diagnósticas que debes comprobar una vez conocido el código real, no una lista garantizada de pertenencia. La regla de Google es que todos los 4xx salvo 429 se tratan igual: el contenido se considera inexistente, por lo que la página no se indexa y no hay efecto sobre la velocidad de rastreo. La etiqueta dice muy poco, así que el primer paso siempre es identificar el código real (prueba en directo de Inspección de URL → Crawl Stats → reproduce el método de solicitud original → registros correlacionados del servidor/CDN/WAF/app), porque corregir un 410 (eliminación intencionada) es lo contrario de corregir un 400 o un 429. Hay que desmontar este mito: 429 no es un 4xx normal; Google lo trata como un error del servidor (sobrecarga) y ralentiza el rastreo, pero ese comportamiento de procesamiento no demuestra qué etiqueta de Page Indexing recibe realmente una URL con 429; considera no confirmada su ubicación en el informe. No uses 4xx para ralentizar Googlebot: usa 429 o 503. Identifica → corrige la causa raíz (o confirma que es intencionada) → confirma un 200 en Test live URL → ejecuta Validate Fix (que hace que la URL sea apta para reindexarse, pero no lo garantiza).

Lo que dice realmente Google

La etiqueta del informe es una categoría, así que inspecciona la URL para determinar el código de estado y la causa reales. Evidence for this claim The Page Indexing report uses this category for a 4xx issue not covered by its other issue types. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: Page indexing report El comportamiento HTTP está documentado por separado de la taxonomía del informe. Evidence for this claim Google treats 4xx responses other than 429 as if the content does not exist; 429 is handled as a server-overload signal. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: HTTP status codes

La documentación del informe de Indexación de páginas de Google describe este estado con claridad: el servidor encontró un error 4xx que no está cubierto por ninguno de los otros tipos de problema que el informe separa, y recomienda depurar la página con la herramienta Inspección de URL. Por definición, esta es la categoría restante: cualquier 4xx que no aparezca ya en su propia fila (401 no autorizado, 403 prohibido, 404 no encontrado). Google no publica una tabla exhaustiva que asigne cada código 4xx restante a esta fila, así que trata cualquier lista de «códigos que llegan aquí», incluida la siguiente, como candidatos observados habitualmente, no como una lista oficial o completa de pertenencia.

El comportamiento que lo explica procede de la documentación independiente de Google sobre códigos de estado HTTP, y hay una regla central que gobierna casi todo lo de esta página: todos los errores 4xx, salvo 429, se tratan igual; los rastreadores de Google informan al siguiente sistema de procesamiento de que el contenido no existe. Para la indexación, el resultado es idéntico al de un 404: la página se trata como inexistente y no se indexa (o se retira si ya lo estaba). Y lo importante es que los códigos 4xx (de nuevo, salvo 429) no afectan a la velocidad de rastreo: no ralentizan Googlebot, simplemente sacan la página de consideración (aunque la frecuencia de rastreo de una URL que falla de forma persistente bajará de manera natural con el tiempo, mientras Google siga sin encontrar nada allí).

Qué códigos 4xx suelen llegar aquí

La definición residual de Google no los enumera individualmente; esto es lo que suele aparecer en la práctica una vez confirmado el código real. Qué debes inspeccionar y cuál es la inferencia equivocada habitual en cada caso:

• 400 Bad Request — destino, sintaxis o estructura de Host/enrutamiento de la solicitud malformados (a menudo una URL rota o mal codificada). Inferencia equivocada: «el código de la página está roto»; compara la solicitud exacta que recibió el servidor con la que pretendías generar.
• 405 Method Not Allowed — el método HTTP usado no está permitido para esa URL; la respuesta debería llevar una cabecera Allow que indique qué sí está permitido. Inferencia equivocada: que un fallo de curl -I (HEAD) demuestra que el GET de Googlebot falló igual; prueba ambos métodos por separado.
• 408 Request Timeout — la conexión o la solicitud no terminó a tiempo. Inferencia equivocada: «caída genérica del servidor»; correlaciona el momento en la capa de conexión/proxy/origen.
• 410 Gone — el recurso se eliminó permanentemente. A menudo es intencionado; consulta la sección siguiente.
• 411 Length Required — el servidor exige una cabecera Content-Length en una solicitud con cuerpo. Es poco habitual en una recuperación ordinaria de página; confirma que la solicitud tenía contenido y qué capa la rechazó antes de cambiar una regla.
• 413 Payload Too Large — el contenido de la solicitud supera un límite de tamaño. Confirma el cuerpo y las cabeceras de entrada, no el tamaño de la página.
• 414 URI Too Long — la URI solicitada supera un límite de longitud. Suele ser un problema de parámetros generados o de una cadena de redirecciones, no de contenido.
• 415 / 422 (Unsupported Media Type / Unprocessable Entity) — se rechazaron el tipo de contenido o las instrucciones de la solicitud. Como 411/413, describen condiciones del contenido solicitado y son atípicas en un GET de página simple; no relajes la validación de forma genérica sin pruebas de la solicitud rechazada.
• 421 Misdirected Request — la conexión se dirigió mal; Google también documenta devolver 421 como forma intencionada de excluir una ruta de HTTP/2. No supongas que la página está rota en todos los protocolos: confirma si Google reintentó por HTTP/1.1 y cuál fue la respuesta final.
• 451: bloqueo por motivos legales o de políticas — bloqueo legal o basado en políticas. Dirígelo a quien sea responsable de la revisión legal o de políticas, en vez de tratarlo como una configuración incorrecta rutinaria de geo/WAF.
• 429 Too Many Requests — una limitación de velocidad. Este caso es especial; consulta la sección siguiente.

El objetivo de esta lista no es que la memorices como un dogma, sino darte un conjunto inicial de ramas diagnósticas. Aun así, debes mirar el código real y la capa que lo produjo antes de elegir una corrección.

429 es la excepción: separa la semántica de la etiqueta del informe

Muchos textos de terceros meten 429 dentro de «other 4xx». Eso mezcla tres preguntas distintas que conviene mantener separadas: qué significa 429 según HTTP, cómo lo gestionan realmente los rastreadores de Google y en qué fila de Page Indexing se informa una URL con 429. Las dos primeras están documentadas; la tercera no. Los rastreadores de Google tratan el código de estado 429 como una señal de que el servidor está sobrecargado y lo consideran un error del servidor, no un error de cliente normal. Consecuencias prácticas:

• Un 429 hace que Googlebot ralentice el rastreo en vez de retirar inmediatamente la página.
• Como se gestiona como un error del servidor, un 429 real podría aparecer como un problema de servidor o rastreo y no como «Blocked due to other 4xx issue». Pero la documentación de Google describe el comportamiento de procesamiento, no la taxonomía del informe, así que considera no confirmada su ubicación en el informe en vez de suponer que queda excluido de esta categoría.
• El paso equivocado es desactivar una limitación legítima para «corregir» un estado de other-4xx. Si tu servidor está realmente bajo carga, conserva la limitación y envía una cabecera Retry-After; RFC 6585 hace opcional la cabecera en una respuesta 429 y, aunque es una buena práctica HTTP para cualquier cliente que se comporte correctamente, la documentación revisada de Google no dice que Googlebot programe su siguiente rastreo a partir de ese valor. Envíala como buena práctica, pero no la trates como una instrucción garantizada. Como escribí en mi guía de códigos de estado HTTP de Ahrefs, “429s are a little special because they are generally treated as server errors and will cause Google to slow down crawling. But eventually, Google will drop these pages from the index as well.” (traducción) «Los 429 son un poco especiales porque normalmente se tratan como errores del servidor y harán que Google ralentice el rastreo. Pero, con el tiempo, Google también retirará estas páginas del índice». Por tanto, un 429 no es gratis: compra tiempo, pero no mantiene una página indexada para siempre.

410 frente a 404: normalmente no es un problema

Un 410 Gone es el código intencionado más habitual de esta categoría: eliminaste una página y quieres que desaparezca. La gente se obsesiona con 410 frente a 404, pero la diferencia práctica es pequeña. La documentación de rastreo de Google incluye 410 entre los códigos 4xx que reciben el mismo tratamiento posterior de «el contenido no existe» que un 404. Como escribí en mi guía de códigos de estado HTTP de Ahrefs, “404s and 410s have a similar treatment. Both drop pages from the index, but 410s are slightly faster.” (traducción) «404 y 410 reciben un tratamiento similar. Ambos retiran las páginas del índice, pero 410 lo hace un poco más rápido». John Mueller ha dicho que la diferencia es, como mucho, del orden de unos pocos días y que, a medio y largo plazo, Google trata 404 y 410 de la misma manera: ambos se retiran del índice. Que Google incluya 410 en el tratamiento compartido de 4xx no confirma por sí solo en qué fila de Page Indexing se informa una URL con 410, así que verla aquí es coherente con lo esperado, no una certeza documentada. En cualquier caso, si un 410 de esta categoría es intencionado, funciona como debe: actúa solo si la página debería estar activa y confirma su estado en Search Console en vez de deducirlo únicamente del código.

Por qué ocurre

La mayoría de los estados «other 4xx» del mundo real proceden de una de estas causas:

• Reglas de WAF / protección contra bots / CDN que devuelven un 4xx extraño (a menudo un 4xx que no es un 403 limpio) cuando el patrón de solicitud de Googlebot activa una regla.
• Plugins de seguridad (por ejemplo, plugins de seguridad de WordPress) que bloquean o desafían a clientes que no son navegadores.
• Bloqueos de IP o geográficos que atrapan a Googlebot, cuyo rastreo procede principalmente de IP de Estados Unidos.
• Limitación agresiva de velocidad que devuelve un 4xx después de N solicitudes (debería ser 429; consulta más abajo).
• URL malformadas (400), límites de tamaño de solicitud (413) o fallos de validación (422) provocados por la forma en que se generó o enlazó una URL.
• Eliminaciones intencionadas (410) que simplemente no deberían seguir en un sitemap.

Una causa importante que uno mismo puede provocar es usar 4xx para ralentizar Googlebot. Google ha pedido a propietarios de sitios y CDN que dejen de usar 404 y otros códigos 4xx para reducir la velocidad de rastreo de Googlebot: no ralentiza el rastreo, solo elimina contenido de Search. Si necesitas que Googlebot reduzca el ritmo, devuelve 500, 503 o 429, no un 4xx.

Cómo diagnosticar el código real

Trabájalo como un árbol de decisión, de arriba abajo. Ninguna herramienta garantiza por sí sola que exponga el fallo exacto; encadénalas:

1. URL Inspection → Test live URL. Confirma la disponibilidad actual: si Google recibe un 4xx ahora, frente a una fila antigua del informe. Pero una prueba en directo fallida no siempre expone las cabeceras de respuesta sin procesar ni la línea de estado, así que trátala primero como una comprobación de disponibilidad, no como un diagnóstico completo.
2. Informe Crawl Stats. Extrae ejemplos representativos de las solicitudes de rastreo reales de Google (código de respuesta, tiempo de respuesta y tipo de archivo). Sirve para corroborar lo que vio un rastreo programado, ya que Test live URL usa Google-InspectionTool y no el rastreador común.
3. Reprodúcelo tú, igualando la solicitud original. Abre la URL en la pestaña Network de DevTools o usa curl; si sospechas una regla para bots, recupérala con el user-agent de Googlebot (idealmente desde fuera de tu red) para activar la misma regla. Iguala también el método: curl -I envía una solicitud HEAD, que puede devolver un resultado distinto del GET que hizo Google (por ejemplo, un 405 solo para HEAD no demuestra que falle GET). (Los comandos están en la pestaña Scripts.)
4. Lee de forma correlacionada los registros del servidor, CDN, WAF, proxy de autenticación y aplicación. Normalmente es el único lugar donde encontrarás el estado exacto, la capa que denegó la solicitud y la regla o condición que lo produjo, sobre todo cuando la prueba en directo no expone las cabeceras sin tratar.
5. Verifica la identidad de quien solicita, por separado de la respuesta. Una cadena de user-agent por sí sola no demuestra que la solicitud la hizo Googlebot; confirma mediante DNS inverso y directo o con los rangos de IP publicados por Google antes de decidir si el bloqueo afecta a un rastreador legítimo.
6. Relaciona el código con su causa. 400/405/408/414 → problema de estructura, tiempo o URI de la solicitud. 411/413/415/422 → diagnostícalo como problema del contenido solicitado solo si tienes pruebas del método y cuerpo reales que llevaba la solicitud de Google; son códigos inusuales en una recuperación ordinaria de página. 410 → eliminación intencionada (confirma que debe desaparecer). 421 → revisa si corresponde a la exclusión documentada de HTTP/2 de Google y qué devolvió la alternativa HTTP/1.1. Un 4xx de una capa de seguridad → una excepción para el cliente y la ruta verificados, no una autorización general. Un posible 429 → limitación de velocidad (gestiónalo como carga del servidor, no como 4xx).

Cómo corregirlo según el código

• 400 / 405 / 408 / 414 (estructura, método, tiempo y longitud de URI). Corrige el origen de la solicitud malformada, la URL rota o demasiado larga, el método no permitido o la conexión lenta/incompleta en la capa que realmente lo genera; compara la solicitud exacta que vio el servidor con la que tu aplicación pretendía enviar.
• 411 / 413 / 415 / 422 (errores del contenido solicitado). Describen condiciones ligadas al cuerpo, la longitud o el tipo de contenido de una solicitud, algo atípico en un GET de página normal. Antes de relajar un límite o una regla de validación, confirma en los registros qué método y contenido activaron el error y qué capa lo rechazó; no aflojes los límites de seguridad de forma genérica sin esa prueba.
• 410: ¿es intencionado? Si la página debe desaparecer, el 410 es correcto; quítala de los sitemaps y enlaces internos para que deje de aparecer como un «problema». Si la página debería estar activa, el 410 es un error que debes deshacer.
• 421: comprueba si es una exclusión intencionada de HTTP/2. Google documenta devolver 421 como forma de excluir una ruta del rastreo por HTTP/2. Confirma si la solicitud volvió a HTTP/1.1 y cuál fue la respuesta final antes de tratar 421 como una página rota.
• 429: limitación de velocidad bien hecha. No elimines una limitación legítima. Manténla y añade una cabecera Retry-After como buena práctica (es opcional según la especificación HTTP y la documentación de Google no confirma que Googlebot programe su siguiente rastreo a partir de ella). Recuerda que Google interpreta 429 como «slow down», no como «deindex». Si una regla devuelve 4xx a Googlebot únicamente para limitarlo, pásala a 429 o 503.
• 451: confirma primero el contexto legal o de políticas. No lo trates como una configuración incorrecta rutinaria de geo/WAF; dirígelo a quien sea responsable de las decisiones legales o de política de contenido antes de cambiar la respuesta.
• Bloqueos de WAF, CDN o plugin de seguridad. Identifica primero la capa y la regla exactas que deniegan la solicitud. Incluye en la lista de permitidos a Googlebot verificado, mediante identidad DNS inversa o los rangos de IP publicados por Google, no confiando en la cadena user-agent (que se puede falsificar), y limita la excepción a la ruta y el cliente previstos. Corrige la regla para que la URL devuelva 200.

No uses 4xx para ralentizar Googlebot

Vale la pena decirlo por separado, porque es una de las principales causas de «other 4xx» autoinfligido: devolver códigos 4xx para ralentizar Googlebot no funciona y elimina contenido de Search. Como resumo la regla en mi guía de códigos de estado HTTP de Ahrefs, “4xxs will cause pages to drop from the index.” (traducción) «Los 4xx harán que las páginas salgan del índice». Si tu objetivo real es ralentizar el rastreo, usa 429 o 503: son los códigos que Google interpreta como «come back later» y el efecto es temporal.

Después de corregirlo

Cuando se resuelva la causa subyacente (o hayas confirmado que el 410 es intencionado y hayas limpiado el sitemap y los enlaces):

1. Usa URL Inspection → Test live URL para confirmar que la respuesta en directo ahora es 200.
2. Solicita la Request indexing de las URL prioritarias o pulsa Validate Fix en la fila «Blocked due to other 4xx issue» del informe de Page Indexing.
3. Una respuesta 200 hace que la URL sea apta para que Google la rastree, procese y potencialmente vuelva a indexarla cuando la rastree de nuevo; no es una garantía de indexación ni de plazo fijo. No hagas un «Request indexing» masivo antes de corregir la causa raíz, porque solo volverás a entrar en la misma categoría.

¿Perjudica al SEO?

Solo si las páginas que realmente quieres indexar devuelven un 4xx: salen del índice y pierden sus posiciones hasta que se corrige. Si el 4xx es intencionado (un 410 en una página eliminada o un bloqueo deliberado de una ruta de administración que no debería estar en tu sitemap), funciona como debe y no está perjudicando nada.

Los estados hermanos que debes conocer son «Blocked due to access forbidden (403)» y «Blocked due to unauthorized request (401)», las filas específicas de firewall o inicio de sesión, y «Not found (404)», que tiene su propia categoría. Este estado es todo lo demás de la familia 4xx. Para consultar el informe y cómo agrupa los motivos de no indexación, mira la vista general de Page Indexing.

Resumen de IA

Una versión condensada de la sección Advanced:

• Qué es. «Blocked due to other 4xx issue» en el informe de Page Indexing de GSC significa que Googlebot recibió un 4xx que no aparece separado como 401/403/404. Google no publica una lista exhaustiva de los códigos que llegan aquí; 400, 405, 408, 410, 411, 413, 414, 421, 422 y 451 son candidatos habituales que debes comprobar, no una lista garantizada. La página no se indexa (y se retira si ya lo estaba).
• La regla central. Todos los 4xx salvo 429 se tratan igual: Google considera inexistente el contenido, como con un 404, y no hay efecto en la velocidad de rastreo.
• La etiqueta es un cajón de sastre. No dice cuál es la causa: encuentra primero el código de estado real (prueba en directo de Inspección de URL → Crawl Stats → reproduce el método de solicitud original → registros correlacionados de servidor/CDN/WAF; curl -I es HEAD, no GET, así que prueba ambos).
• 429 es la excepción (y un mito habitual). Google trata 429 como un error del servidor (sobrecarga) y ralentiza el rastreo en vez de retirar la página, pero ese comportamiento de procesamiento no confirma en qué fila de Page Indexing se informa una URL con 429; considera no confirmada su ubicación. Conserva la limitación legítima y envía Retry-After como buena práctica (es opcional según la especificación HTTP; la documentación de Google no dice que Googlebot programe sus rastreos a partir de él). No desactives la protección para «corregir» un estado de other-4xx.
• 410 frente a 404. 410 (Gone) es el código intencionado habitual; Google lo agrupa con 404 bajo el mismo tratamiento posterior de «el contenido no existe», y la diferencia práctica de plazo es pequeña. Si un 410 es intencionado, funciona como debe: confirma la intención antes de tocarlo.
• 421 también puede ser intencionado. Google documenta 421 como forma de excluir una ruta del rastreo por HTTP/2; comprueba la alternativa HTTP/1.1 y la respuesta final antes de suponer que la página está rota.
• Por qué ocurre. Bloqueos de WAF/CDN/plugin de seguridad, bloqueos de IP o geográficos, reglas de limitación de velocidad, URL malformadas o demasiado largas (400/414), condiciones del contenido solicitado (411/413/415/422; necesitas pruebas del cuerpo real) o eliminaciones intencionadas (410).
• No ralentices con 4xx. Usar 404 u otros 4xx para ralentizar Googlebot elimina contenido de Search: usa 429 o 503.
• Corrige y valida. Identifica el código (no te detengas ante una prueba en directo fallida; consulta Crawl Stats y registros correlacionados) → corrige la causa raíz (o confirma que es intencionada y limpia sitemaps/enlaces) → confirma un 200 en Test live URL → ejecuta Validate Fix. Un 200 hace que la URL sea apta para reindexarse; no lo garantiza ni fija un plazo.

Documentación oficial

Documentación de fuentes primarias de los buscadores.

Google

• Informe de Indexación de páginas — el propio informe, incluida la entrada «Blocked due to other 4xx issue» (un 4xx no cubierto por ningún otro tipo de problema) y sus estados hermanos 401/403/404.
• Cómo afectan los códigos de estado HTTP y los errores de red y DNS a la Búsqueda de Google — la regla de que todos los 4xx salvo 429 se tratan igual, que 429 se gestiona como una señal de sobrecarga del servidor y que los 4xx (salvo 429) no afectan a la velocidad de rastreo.
• Don’t 404 my yum (blog de Search Central, 2023) — Google pide a propietarios de sitios y CDN que dejen de usar 404 y otros códigos 4xx para ralentizar Googlebot, y explica qué usar en su lugar (500/503/429).
• Verificación de Googlebot y otros rastreadores de Google — DNS inverso y directo y rangos de IP publicados, para incluir al Googlebot real en la lista de permitidos antes de cambiar una regla de WAF o firewall.

Bing / Microsoft

• Bing Webmaster Tools — Crawl Control — Bing no usa la etiqueta exacta «other 4xx» de Google, pero el principio es el mismo: un 4xx significa que Bingbot no pudo recuperar contenido utilizable, así que la URL no se indexará. Usa Crawl Control para gestionar la velocidad de Bingbot en vez de bloquearlo con códigos de error.

Citas de la fuente

Declaraciones públicas de Google y de mi propia guía de códigos de estado de Ahrefs, que escribí y de cuyas palabras puedo hablar como autor. Cada enlace lleva directamente al pasaje citado de la página fuente.

Google: cómo se gestionan los 4xx (salvo 429)

• “All 4xx errors, except 429, are treated the same: Google crawlers inform the next processing system that the content doesn’t exist.” (traducción) «Todos los errores 4xx, salvo 429, se tratan igual: los rastreadores de Google informan al siguiente sistema de procesamiento de que el contenido no existe». — Documentación de Google Search Central. Saltar a la cita

Google: 429 se trata como un error 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 lo consideran un error del servidor». — Documentación de Google Search Central. Saltar a la cita

Google: no uses 4xx para limitar la velocidad de rastreo

• “The 4xx status codes, except 429, have no effect on crawl rate.” (traducción) «Los códigos de estado 4xx, salvo 429, no afectan a la velocidad de rastreo». — Documentación de Google Search Central. Saltar a la cita

John Mueller, Google: 410 frente a 404 (paráfrasis)

• John Mueller, de Google, ha descrito la diferencia entre 410 y 404 como pequeña, del orden de unos pocos días como máximo, y ha dicho que a medio y largo plazo Google trata 404 y 410 de la misma manera: ambos se retiran del índice. Lo recoge la cobertura de Search Engine Journal sobre sus declaraciones: Google ofrece consejos sobre los códigos de estado 404 y 410 (SEJ). (Aquí se parafrasea en vez de citar literalmente, a la espera de una comprobación independiente de las palabras exactas en esta pasada; confirma la redacción exacta en la fuente antes de citarla directamente.)

Patrick Stox (yo): de mi guía de códigos de estado de Ahrefs

• “4xxs will cause pages to drop from the index.” (traducción) «Los 4xx harán que las páginas salgan del índice». — Patrick Stox, «Códigos de estado HTTP y su impacto en SEO», Ahrefs. Saltar a la cita
• “404s and 410s have a similar treatment. Both drop pages from the index, but 410s are slightly faster.” (traducción) «Los códigos 404 y 410 reciben un tratamiento similar. Ambos sacan las páginas del índice, pero 410 lo hace algo más rápido». Saltar a la cita
• “429s are a little special because they are generally treated as server errors and will cause Google to slow down crawling. But eventually, Google will drop these pages from the index as well.” (traducción) «Los 429 son un poco especiales porque normalmente se tratan como errores del servidor y harán que Google ralentice el rastreo. A la larga, Google también sacará estas páginas del índice». Saltar a la cita

Nota sobre Retry-After: RFC 6585 permite (pero no exige) que una respuesta 429 incluya una cabecera Retry-After. Enviarla es una práctica razonable para cualquier cliente que se comporte correctamente, pero la documentación de Google revisada para esta página no afirma que Googlebot use ese valor como calendario literal del siguiente rastreo; preséntalo como metadato opcional de respuesta, no como una instrucción confirmada de Googlebot.

Lista de comprobación: diagnosticar → corregir → validar otro 4xx

Aplica esta lista a cualquier URL que muestre «Blocked due to other 4xx issue»:

• Encuentra primero el código real: Inspección de URL → Test live URL, Crawl Stats para detalles de solicitudes representativas y, además, pestaña Network de DevTools / curl (tanto HEAD como GET) / registros correlacionados de servidor-CDN-WAF. La etiqueta de la categoría no es el diagnóstico y Google no publica un mapa completo de código a fila.
• Confirma que es actual, no antiguo: Test live URL muestra un 4xx actual, no una fila antigua del informe. Ten en cuenta que una prueba en directo fallida puede no exponer las cabeceras sin procesar; corrobórala con registros cuando ocurra.
• Clasifícalo. ¿Error de estructura, tiempo o URI de la solicitud (400/405/408/414)? ¿Condición del contenido solicitado que requiere pruebas del cuerpo (411/413/415/422)? ¿Eliminación intencionada (410)? ¿Posible exclusión de HTTP/2 (421)? ¿Motivo legal o de políticas (451)? ¿Bloqueo de una capa de seguridad? ¿Un posible 429 (limitación de velocidad)?
• Si es 410 (Gone): ¿la página debe desaparecer? Si sí, es correcto; quítala de sitemaps y enlaces internos. Si no, restaura la página.
• Si es 421: confirma si es una exclusión intencionada de HTTP/2 y comprueba la alternativa HTTP/1.1 y la respuesta final antes de tratarlo como un fallo.
• Si es un error de estructura o de solicitud: corrige en el origen la URL malformada o demasiado larga, el método permitido o el problema de tiempo de espera/conexión; deja de enlazar o listar la URL incorrecta.
• Si es un error del contenido solicitado (411/413/415/422): confirma el método y el cuerpo reales en los registros antes de relajar cualquier límite o regla de validación.
• Si es un bloqueo de seguridad/WAF/CDN: verifica el Googlebot real (DNS inverso o rangos de IP publicados) y después inclúyelo en la lista de permitidos de forma limitada por identidad/IP y ruta; no por user-agent ni con una autorización general.
• Si en realidad se trata de ralentizar: no uses 4xx; devuelve 429 o 503 y añade una cabecera Retry-After como buena práctica. Mantén la limitación legítima; no supongas que Googlebot programa su siguiente rastreo a partir de esa cabecera.
• Confirma un 200: Test live URL devuelve ahora 200 para las páginas que quieres indexar.
• Valida: pulsa Validate Fix en la fila «other 4xx» o solicita Request indexing para las URL prioritarias. Eso hace que la URL sea apta para reindexarse, no lo garantiza; no hagas solicitudes masivas antes de corregir la causa.

Modelos mentales

1. La etiqueta es una categoría, no un diagnóstico. «Other 4xx» es la fila residual de Google para cualquier 4xx que no aparezca ya separado como tipo de problema propio. Google no publica la lista exacta de lo que llega aquí, aunque 400, 405, 408, 410, 411, 413, 414, 421, 422 y 451 son candidatos habituales. El primer paso nunca es «corregirlo», sino «¿qué código es realmente?». Todo lo que viene después depende de la respuesta.

2. Para la indexación, other-4xx = 404. Google trata todos los 4xx salvo 429 de la misma manera: el contenido se considera inexistente. Por tanto, sea cual sea el código concreto, el resultado de indexación es el mismo que con un 404: no se indexa y se retira si ya lo estaba. Eso también significa que no afecta a la velocidad de rastreo.

3. 429 es un error del servidor, no del cliente; su ubicación en el informe es una pregunta aparte y no confirmada. Google interpreta 429 como «server overloaded» y ralentiza en vez de retirar la página; eso está documentado. No está documentado si una URL con 429 aparece en esta fila concreta, así que no des por resuelta su ubicación en ninguna dirección. No desactives la limitación para que desaparezca: envía Retry-After como buena práctica, sin suponer que Googlebot la sigue según un calendario.

4. Intencionado frente a error. Un 410 en una página eliminada o un 421 que excluye una ruta de HTTP/2 pueden funcionar como deben; un 400 en una página que quieres indexar es un error. Pregunta «¿esta URL debería estar activa y en qué protocolo?» antes de aplicar una corrección. Si no debería estar activa, la solución es dejar de listarla (sitemaps y enlaces), no convertirla en 200.

5. 4xx es la limitación equivocada. Si tu objetivo es ralentizar Googlebot, 4xx no lo consigue: desindexa. Los códigos «come back later» son 429 y 5xx/503. Elige el código que corresponde a tu intención: «esto ha desaparecido» (4xx) frente a «estoy sobrecargado, inténtalo más tarde» (429/503).

Chuleta de other-4xx

Códigos que suelen aparecer aquí y corrección para cada uno (Google no publica una lista exhaustiva de pertenencia para esta fila; trata esta tabla como ramas diagnósticas que debes comprobar una vez conocido el código real, no como una garantía.)

Estados hermanos en Page Indexing

Elige el código correcto según tu intención

Encuentra el código de estado real

La etiqueta de GSC no te dirá con qué 4xx estás tratando: compruébalo directamente. -I envía una solicitud HEAD, no el GET que Google usa para recuperar una página, así que un resultado solo de HEAD (por ejemplo, un 405) no demuestra qué devuelve GET; prueba ambos.

macOS / Linux

# HEAD only — read the status line (e.g. "HTTP/1.1 410 Gone")
curl -s -I https://www.example.com/page/

# GET — reproduces the method Google actually uses to fetch page content
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.com/page/

# If you suspect a bot-specific block, fetch as Googlebot's user-agent (GET)
curl -s -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  -o /dev/null -w "%{http_code}\n" https://www.example.com/page/

Windows (PowerShell)

# GET request, matching what Google actually uses to fetch page content
$ua = "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
Invoke-WebRequest -Uri "https://www.example.com/page/" -Method Get `
  -UserAgent $ua -SkipHttpErrorCheck | Select-Object StatusCode, StatusDescription

Si el código difiere entre HEAD y GET, o entre una solicitud normal y otra con el user-agent de Googlebot, has encontrado una regla específica del método o del bot. Un WAF sofisticado también puede basarse en la IP, el protocolo o la categoría del cliente, no solo en el user-agent. Para reproducirlo por completo, prueba desde fuera de tu red y no supongas que una coincidencia de user-agent por sí sola demuestra que la misma regla se aplica al tráfico real de Googlebot.

Verifica que un bot sea realmente Googlebot (antes de incluirlo en permitidos)

Si el 4xx procede de una capa de seguridad y vas a dejar pasar al rastreador, confirma primero que sea realmente Googlebot: el user-agent se falsifica con facilidad, y cambiar solo el user-agent en una solicitud de prueba no reproduce la IP de origen, la categoría de cliente, el protocolo ni la ruta de reglas del edge reales de Google.

macOS / Linux

# 1) Reverse DNS the IP from your logs — must end in googlebot.com / google.com
host 66.249.66.1
# → ... domain name pointer crawl-66-249-66-1.googlebot.com

# 2) Forward DNS that hostname back — it must resolve to the same IP
host crawl-66-249-66-1.googlebot.com
# → crawl-66-249-66-1.googlebot.com has address 66.249.66.1

Windows

nslookup 66.249.66.1
nslookup crawl-66-249-66-1.googlebot.com

Si la búsqueda inversa no termina en un dominio de Google, o la búsqueda directa no coincide con la IP original, no es Googlebot: no lo incluyas en permitidos. También puedes comparar la IP con los rangos publicados por Google (googlebot.json). Incluye en permitidos por identidad/rango de IP verificados, nunca solo por la cadena user-agent.

Envía Retry-After en un 429 (no elimines la limitación de velocidad)

Si una URL está realmente limitada por velocidad, devuelve 429 con Retry-After como buena práctica HTTP, en vez de desactivar la protección o devolver un 4xx «real». Retry-After es opcional según RFC 6585 y la documentación de Google no confirma que Googlebot programe su siguiente rastreo a partir de ese valor, así que trátalo como una medida de higiene razonable, no como una corrección demostrada. Los fragmentos siguientes son puntos de partida ilustrativos: revísalos frente a tu propia configuración de servidor/CDN y tu política de seguridad antes de desplegarlos.

Apache (.htaccess / config)

# Example: return 429 with a 1-hour Retry-After for rate-limited responses
Header always set Retry-After "3600" "expr=%{REQUEST_STATUS} == 429"

Nginx

# limit_req_status makes throttled requests return 429 instead of 503
limit_req_status 429;
# add a Retry-After hint on 429 responses
error_page 429 = @rate_limited;
location @rate_limited {
    add_header Retry-After 3600 always;
    return 429;
}

Recursos que merecen tu tiempo

Oficiales

• Informe de Indexación de páginas (Google) — la entrada «other 4xx» y sus estados hermanos 401/403/404.
• Cómo afectan los códigos de estado HTTP a la Búsqueda de Google — la regla de todos los 4xx salvo 429, el matiz de 429 como error del servidor y la ausencia de efecto sobre la velocidad de rastreo.
• Don’t 404 my yum (Google, 2023) — no uses 404 u otros 4xx para ralentizar Googlebot.
• Verificación de Googlebot (Google) — DNS inverso y rangos de IP publicados.

Textos relacionados del autor

• Códigos de estado HTTP y su impacto en SEO — mi guía completa sobre lo que significa cada código de estado para el SEO, incluidos los pasajes sobre 4xx, 410 frente a 404 y 429 citados aquí.
• Guía para principiantes de SEO técnico — dónde encajan errores de rastreo e indexación como este en el panorama general.

De otros autores

• r/TechSEO — comunidad para depurar rastreo e indexación, incluidos los hilos sobre «4xx extraños en GSC».
• Google advierte contra usar 403 o 404 para limitar el rastreo (Search Engine Land) — cobertura de la guía «Don’t 404 my yum» de Gary Illyes; usa 500/503/429 en su lugar.
• Google: diferencias mínimas entre los códigos de estado 404 y 410 (Search Engine Roundtable) — Mueller sobre por qué la diferencia entre 410 y 404 es insignificante en la práctica.
• Google ofrece consejos sobre los códigos de estado 404 y 410 (Search Engine Journal) — fuente citada de las observaciones de Mueller sobre la velocidad relativa de 410 frente a 404; confirma la redacción exacta en la página activa antes de citarla directamente.
• How to Fix Blocked due to other 4xx issue (Onely) — guía paso a paso sobre los códigos habituales, útil para auditar sitemaps y enlaces internos. Trata sus afirmaciones concretas de pertenencia de códigos como la interpretación de esa fuente, no como taxonomía confirmada de Google.
• Blocked due to other 4xx issue (SEOTesting) — cubre el análisis de registros del servidor y la monitorización preventiva; también menciona 422, 405, 413 y 414. Aplica la misma cautela a sus afirmaciones de pertenencia.

Encuentra el código real detrás de «other 4xx»

«Other 4xx» es un cajón de sastre, así que el único primer paso útil es identificar qué código se está produciendo realmente. Eso es lo que quiere decir la sección de diagnóstico del artículo con «trabájalo como un árbol de decisión, de arriba abajo». Confirma primero el código en directo y después elige la rama de su familia antes de tocar cualquier configuración.

Sigue la categoría «other 4xx», no solo su existencia

El número que merece la pena vigilar es cuántas URL aparecen con el tiempo en la fila «Blocked due to other 4xx issue» del informe de Page Indexing. Una sola instantánea no puede decirte si una corrección funcionó o si se están colando nuevos códigos problemáticos, sobre todo porque esta categoría mezcla causas intencionadas y accidentales.

Recuento de la categoría other-4xx a lo largo del tiempo

• Métrica: recuento de URL bajo «Blocked due to other 4xx issue» en el informe de Page Indexing de GSC, seguido semana a semana, idealmente separado por el código de estado real una vez identificado para cada URL.
• Qué te dice: si las correcciones de solicitudes/validación (400/405/411/413/422) y la inclusión en permitidos de WAF/CDN están surtiendo efecto. Para las URL cuyo código real sea un 410 intencionado, el recuento de esas URL debería mantenerse plano después de limpiar sitemaps y enlaces internos. Un aumento suele significar que nuevas páginas «eliminadas» siguen enlazándose o entrando en sitemaps por error, no que haya aparecido un error nuevo.
• Cómo obtenerlo: informe de Page Indexing de GSC, filtrado a la fila «other 4xx»; comprueba URL individuales con URL Inspection → Test live URL para confirmar que el informe no muestra una instantánea antigua.
• Referencia / rango realista: no hay un objetivo universal; depende por completo de cuántas URL devuelvas intencionadamente con 410 (o similar). El criterio honesto es cero other-4xx entre las URL que quieres indexar y un recuento plano (no creciente) para las URL que eliminaste deliberadamente. Establece tu propia línea base antes de juzgar la dirección de la tendencia.
• Cadencia: semanalmente justo después de una corrección, hasta que el recuento se estabilice; después, mensualmente como comprobación de regresión, sobre todo si dependes de un WAF/CDN cuyas reglas pueden cambiar independientemente de tus despliegues.

Runbook: identifica, corrige, valida

El flujo de «other 4xx» es el mismo ciclo corto para todas las URL de esta categoría, independientemente del código concreto que haya detrás: identifica primero el código real, porque la corrección se bifurca drásticamente a partir de ahí.

1. Confirma el código en directo. Ejecuta URL Inspection → Test live URL para confirmar que Google recibe ahora un 4xx y ver qué recibió: la fila del informe puede estar obsoleta por sí sola y una prueba en directo fallida no siempre expone las cabeceras sin procesar. Contrasta con el informe Crawl Stats ejemplos representativos de lo que recibió realmente el rastreador programado.

2. Reprodúcelo igualando la solicitud original. Abre la URL en la pestaña Network de DevTools o usa curl; prueba el método GET, no solo curl -I (que envía HEAD y puede dar un resultado distinto). Si sospechas una regla específica para bots, recupérala con el user-agent de Googlebot, idealmente desde fuera de tu red, para activar la misma regla que encontraría un rastreo real. Ten en cuenta que cambiar solo el user-agent no reproduce la IP, el protocolo ni la categoría de cliente reales de Google.

3. Lee los registros. Comprueba los registros del servidor, CDN, WAF y proxy de autenticación para encontrar el código exacto y la regla o condición que lo produjo. Normalmente es más rápido que adivinar desde el navegador y a menudo es la única forma de ver los datos de respuesta sin procesar que la prueba en directo no expone.

4. Relaciona el código con su causa. 400/405/408/414 → problema de estructura, método, tiempo de espera o longitud de URI. 411/413/415/422 → diagnostícalo como problema del contenido solicitado solo con pruebas del método/cuerpo reales que llevaba la solicitud de Google. 410 → eliminación intencionada (confirma que debe desaparecer). 421 → comprueba si es la exclusión documentada de HTTP/2 de Google y qué devolvió la alternativa HTTP/1.1. 451 → revisión legal o de políticas. Un 4xx de una capa de seguridad → un bloqueo que debe incluirse en permitidos de forma limitada. Un posible 429 → limitación de velocidad, gestionada como carga del servidor; su ubicación en el informe no está confirmada en ninguna dirección.

5. Corrige según la causa. Errores de estructura de solicitud → corrige el origen (URL incorrecta o demasiado larga, método equivocado o tiempo de espera) y deja de enlazar/listar la URL mala. Errores del contenido solicitado → confirma la solicitud real en los registros antes de relajar cualquier límite. 410 intencionado o exclusión de 421 → déjalo así; limpia sitemaps y enlaces internos (410) o confirma la alternativa de protocolo (421). 451 → dirígelo a revisión legal o de políticas. Bloqueo de una capa de seguridad → verifica el Googlebot real (DNS inverso o rangos de IP publicados) e inclúyelo en permitidos de forma limitada por identidad y ruta, nunca por user-agent ni con una regla general. 429/limitación → conserva la limitación y añade Retry-After como buena práctica (opcional según RFC 6585 y no una planificación confirmada de Googlebot); si una regla usa un 4xx para limitar a Googlebot, sustitúyela por 429 o 503.

6. Valida y detente. Confirma que Test live URL devuelve ahora 200 para las páginas que quieres indexar y después pulsa Validate Fix en la fila «other 4xx» o solicita la indexación de las URL prioritarias. Una respuesta 200 hace que la URL sea apta para que Google vuelva a rastrearla y potencialmente la reindexe; no es una garantía ni fija un plazo. No hagas solicitudes masivas antes de corregir realmente la causa raíz, porque solo volverás a entrar en la misma categoría.

Prompts de IA listos para usar

Copia y pega estos prompts para clasificar qué código «other 4xx» estás viendo y qué corrección corresponde a partir de una salida diagnóstica sin procesar. Confirma siempre la conclusión frente a tu configuración real de servidor/WAF antes de cambiar nada.

Clasifica el código y la causa a partir de la salida de curl

I'm diagnosing a "Blocked due to other 4xx issue" status in Google Search
Console. Below is the raw output of GET and HEAD requests to the URL (note
that curl -I alone only tests HEAD, which can differ from what Google's GET
request receives). Tell me the exact status code, and classify the likely
cause as one of: (1) a request-framing/timeout/URI-length issue (400, 405,
408, 414), (2) a request-content condition needing body evidence (411, 413,
415, 422), (3) an intentional 410 Gone, (4) a possible HTTP/2 opt-out (421),
(5) a legal/policy block (451), (6) a WAF/CDN/security-plugin block, or (7) a
mislabeled 429 rate limit. Explain which detail in the output pointed you to
that answer, and flag anything you can't determine from this output alone.

CURL OUTPUT (GET and HEAD):
[paste]

Clasifica una línea de registro de WAF/servidor

I'm investigating an "other 4xx" status Googlebot is hitting on a page I want
indexed. Below is a log line (or a few) from my server/CDN/WAF showing the
blocked request. Tell me whether this looks like a bot-identity rule
(user-agent or IP based), a rate-limit/challenge rule that should really be
returning 429, or a request/validation error, and what I'd need to change or
allowlist to fix it without disabling the underlying protection.

LOG LINE(S):
[paste]

Comprueba una corrección antes de desplegarla

I'm about to change how a URL responds because it's currently returning
[status code] and showing as "Blocked due to other 4xx issue" in Search
Console. Here's what I'm about to change: [describe]. Point out anything I
might be missing — for example, whether this could accidentally expose or
re-index a page that's supposed to stay gone (a 410 I'm about to undo), or
whether I should allowlist verified Googlebot instead of loosening a security
rule for everyone.

Ponte a prueba: «Blocked due to other 4xx issue»

Cinco preguntas sobre el significado de la categoría «other 4xx», la excepción 429 y la forma de diagnosticarla y corregirla. Elige una respuesta para cada una y luego comprueba el resultado.

Herramientas para diagnosticar y corregir estados «other 4xx»

• HTTP Status Checker — pega la URL afectada (o un lote) para confirmar el código de estado real que hay detrás de la etiqueta de GSC, ver toda la cadena de respuesta y detectar redirecciones que ocurren antes del 4xx.
• Googlebot Verifier — comprueba si es genuina una IP que afirma ser Googlebot (rangos de IP publicados y confirmación mediante DNS inverso) antes de incluirla en permitidos frente a un WAF, CDN o plugin de seguridad.
• Google Search Console — URL Inspection → Test live URL — lo más cerca que estarás de ver la respuesta exacta que recibe Googlebot ahora mismo, en vez de una fila del informe posiblemente obsoleta.
• curl -I — la forma más rápida de leer la línea de estado sin procesar de una URL y de volver a recuperarla con el user-agent de Googlebot si sospechas una regla específica para bots.
• Panel de registros de tu servidor/CDN/WAF (Cloudflare, Akamai, Sucuri, el registro propio de un plugin de seguridad, etc.) — encuentra el código exacto y la regla o condición que lo produjo.

Problemas habituales, por código

Cada código que llega a «other 4xx» representa una situación independiente de síntoma, causa y corrección. La categoría no tiene una causa raíz única, así que trata estas entradas como tarjetas de consulta separadas, no como una sola cadena.

400 Bad Request

Síntoma: la URL afectada devuelve 400 a una solicitud.

Causa(s) probable(s): destino de solicitud malformado o mal codificado, problema de sintaxis o estructura de Host/enrutamiento que tu aplicación o edge rechaza por completo (parámetros de consulta incorrectos, caracteres no válidos o enrutamiento inesperado).

Corrección y comprobación: compara la solicitud exacta que recibió el servidor con la que pretendías generar; corrige la URL y deja de generar o enlazar la versión rota. Vuelve a comprobar con una solicitud GET (no solo curl -I, que es HEAD) hasta que devuelva 200.

405 Method Not Allowed

Síntoma: la URL devuelve 405 a algunas solicitudes aunque la página parezca funcionar bien en un navegador.

Causa(s) probable(s): el método HTTP usado no está permitido para esa ruta. A menudo es una regla del servidor o CDN que solo permite GET en esa ruta, mientras algo envía HEAD u otro método que rechaza. Comprueba la cabecera Allow de la respuesta para saber qué está permitido y no supongas que un fallo solo de HEAD (como un curl -I simple) demuestra que GET falla igual.

Corrección y comprobación: permite el método correcto para la ruta. Vuelve a probar con HEAD y GET.

408 Request Timeout

Síntoma: la URL devuelve 408 de forma intermitente o la conexión se queda colgada antes de devolver un estado.

Causa(s) probable(s): la conexión o solicitud no terminó dentro de la ventana de tiempo de espera del servidor, proxy o CDN. Es un problema de tiempo/conexión, no una prueba de una caída general del servidor.

Corrección y comprobación: correlaciona los tiempos de conexión y solicitud en la cadena proxy/CDN/origen y con el protocolo utilizado. Vuelve a probar después de ajustar el tiempo de espera pertinente o corregir la ruta lenta del origen.

410 Gone

Síntoma: la URL devuelve 410 y el recuento de «other 4xx» incluye páginas que crees haber eliminado deliberadamente.

Causa(s) probable(s): eliminación intencionada. Funciona como debe para páginas que deben desaparecer. Si la página debería estar activa, el 410 es un error.

Corrección y comprobación: si es intencionado, quítala de sitemaps y enlaces internos para que deje de aparecer como un «problema». Si no lo es, restaura la página.

411 Length Required

Síntoma: la URL devuelve 411 con determinadas solicitudes.

Causa(s) probable(s): el servidor exige una cabecera Content-Length en una solicitud que lleva cuerpo, algo poco habitual en un GET de página normal. Confirma en los registros que la solicitud tenía contenido antes de asumir que es un problema de rastreo rutinario.

Corrección y comprobación: confirma primero el método y el cuerpo reales; relaja o corrige el requisito en el servidor, o asegúrate de que la solicitud incluye la cabecera. Después vuelve a probar con el mismo método y contenido.

413 Payload Too Large

Síntoma: la URL devuelve 413, normalmente en solicitudes con cuerpo o con cabeceras/cookies grandes.

Causa(s) probable(s): el contenido de la solicitud supera un límite de tamaño definido por el servidor, CDN o WAF. Se trata de la solicitud entrante, no del tamaño de respuesta de la propia página.

Corrección y comprobación: confirma la solicitud entrante en los registros antes de subir cualquier límite; corrige lo que genera la solicitud demasiado grande o sube el límite solo si realmente es demasiado estricto para una solicitud legítima. Vuelve a probar para confirmar que una solicitud de tamaño normal devuelve ahora 200.

414 URI Too Long

Síntoma: la URL devuelve 414, normalmente en una URL larga generada o con parámetros.

Causa(s) probable(s): la URI solicitada supera un límite de longitud. A menudo se debe a una generación incorrecta de parámetros o de una cadena de redirecciones, no a un problema del contenido de la página.

Corrección y comprobación: corrige en el origen la generación de URL/redirecciones en vez de subir el límite a ciegas y limpia las entradas de sitemap/enlaces internos que apuntan al patrón demasiado largo.

415 / 422 (Unsupported Media Type / Unprocessable Entity)

Síntoma: la URL devuelve 415 o 422 aunque la solicitud parezca bien formada en un navegador.

Causa(s) probable(s): el servidor entendió la solicitud, pero rechazó su tipo de contenido o falló una regla de validación sobre su contenido/instrucciones, algo atípico en un GET de página simple. Confirma el contenido real de la solicitud antes de asumir que es un problema genérico del contenido de la página.

Corrección y comprobación: confirma la solicitud en los registros y después corrige la regla de validación o la gestión del tipo de contenido, o corrige lo que genera la solicitud rechazada. Vuelve a probar hasta que la respuesta sea 200.

421 Misdirected Request

Síntoma: la URL devuelve 421, a veces solo mediante HTTP/2.

Causa(s) probable(s): la conexión se dirigió mal, pero Google también documenta devolver 421 como forma intencionada de excluir una ruta del rastreo por HTTP/2, así que no es automáticamente una página rota.

Corrección y comprobación: confirma si la solicitud volvió a HTTP/1.1 y cuál fue la respuesta final. Si es una exclusión deliberada de HTTP/2, no necesita corrección; si no hay alternativa y la página es inaccesible en cualquier protocolo, corrige el enrutamiento de conexión y la gestión de SNI/Host.

451: bloqueo por motivos legales

Síntoma: la URL devuelve 451.

Causa(s) probable(s): bloqueo legal o basado en políticas, posiblemente intencionado (por ejemplo, contenido restringido en determinadas jurisdicciones). No lo trates como una configuración incorrecta rutinaria de geo/WAF.

Corrección y comprobación: dirígelo a quien sea responsable de las decisiones legales o de política de contenido para confirmar que el bloqueo es intencionado. Si lo es, funciona como debe: limpia los sitemaps/enlaces que apuntan a él. Si no, levanta el bloqueo.

429 confundido con «other 4xx»

Síntoma: esperabas encontrar aquí un 4xx normal, pero el código real resulta ser 429.

Causa(s) probable(s): la limitación de velocidad se activa con las solicitudes de Googlebot. Google trata 429 como una señal de sobrecarga del servidor, no como un error de cliente como el resto de esta categoría, así que un 429 genuino podría informarse como problema de rastreo/servidor en vez de conservar la etiqueta «other 4xx». Pero la documentación de Google cubre el comportamiento de procesamiento, no la taxonomía del informe, así que considera no confirmada su ubicación exacta.

Corrección y comprobación: no desactives una limitación legítima; añade una cabecera Retry-After como buena práctica (es opcional según RFC 6585 y Google no confirma que Googlebot programe su siguiente rastreo a partir de ella). Si una regla devuelve 4xx exclusivamente para limitar a Googlebot, cambia esa regla a 429 o 503.

Demuestra que la corrección funcionó realmente

Después de corregir el error de solicitud/validación, limpiar un 410 intencionado, incluir en permitidos al Googlebot verificado o confirmar que una limitación se gestiona correctamente, estas comprobaciones separan «la configuración cambió» de «Google ya puede llegar realmente a la página». Ejecútalas en orden.

Prueba 1: una solicitud nueva devuelve ahora el estado esperado

• Prueba que debes ejecutar: ejecuta curl con una solicitud GET sobre la URL afectada (igualando el método que usa Google; curl -I únicamente prueba HEAD) o compruébala con HTTP Status Checker.
• Resultado esperado: para una página que quieres indexar, la línea de estado dice HTTP/1.1 200 OK. En una página eliminada intencionadamente, es correcto que el estado siga siendo 410; la prueba importante en ese caso es la Prueba 3.
• Interpretación de un fallo: que siga apareciendo el 4xx original significa que la corrección no se aplicó realmente a esa ruta o que estás probando una URL o entorno equivocados. Un 4xx distinto del anterior (por ejemplo, 400 pasó a 403) significa que cambiaste un bloqueo por otro; comprueba la regla del WAF/CDN.
• Ventana de monitorización: inmediata: el servidor responde en cuanto el cambio está activo.
• Disparador de rollback: si relajar una regla de validación o tamaño abre un comportamiento que no pretendías, restaura la regla original y corrige la causa raíz de otra forma (por ejemplo, corrige la solicitud en vez de subir el límite).

Prueba 2: Google confirma que ya puede llegar a la página

• Prueba que debes ejecutar: ejecuta URL Inspection → Test live URL en Google Search Console sobre la URL afectada.
• Resultado esperado: para una página que quieres indexar, la prueba en directo tiene éxito y muestra 200 sin informar de ningún 4xx.
• Interpretación de un fallo: si Test live URL sigue informando de un 4xx después de que pase la prueba anónima con curl, sospecha una regla limitada específicamente a los rangos de IP de Googlebot (un problema de lista de permitidos de WAF/CDN), no un problema de solicitud general.
• Ventana de monitorización: inmediata o de unos minutos después de la corrección.
• Disparador de rollback: N/A: esta es una prueba de solo lectura; si sigue fallando, vuelve a la rama de fallo de la Prueba 1 en vez de deshacer nada.

Prueba 3: el estado desaparece (o se mantiene plano de forma intencionada) en el informe de Page Indexing

• Prueba que debes ejecutar: usa Validate Fix en la fila «Blocked due to other 4xx issue» del informe de Page Indexing y observa el recuento de la categoría durante las semanas siguientes (consulta la pestaña How to Measure).
• Resultado esperado: las URL corregidas pasan a ser aptas para salir de la categoría cuando Google vuelva a rastrear la 200 corregida. Eso no garantiza la reindexación ni un plazo concreto: solo indica elegibilidad. Las URL con un 410 intencionado permanecen en la categoría, pero los sitemaps y enlaces internos ya no apuntan a ellas.
• Interpretación de un fallo: no existe una cadencia de reintentos publicada, así que no interpretes una validación lenta como un fallo nuevo. Si el recuento no tiende a bajar después de un par de semanas para las URL que realmente corregiste, vuelve a ejecutar la Prueba 1 para confirmar que la corrección sigue activa (un redeploy o la caché de un CDN puede reintroducir silenciosamente la regla antigua).
• Ventana de monitorización: de días a unas semanas, siguiendo el recuento de la categoría.
• Disparador de rollback: vuelve a examinar la corrección subyacente solo si la Prueba 1 empieza a fallar otra vez; no persigas el calendario del informe de Page Indexing.

Registro de cambios