Bloqueado por solicitud no autorizada (401)

TL;DR — «Bloqueado por solicitud no autorizada (401)» significa que Googlebot intentó leer tu página y se le pidió iniciar sesión. Google no tiene una contraseña de tu sitio, así que se rinde y la página no puede indexarse. Si quieres que esa página aparezca en Google, algo la está bloqueando cuando no debería: normalmente queda una protección de inicio de sesión, una contraseña de staging o una regla de seguridad que bloquea a Google por error. Si la página debe ser privada, es normal y no hay nada que corregir.

Qué significa este estado

Esta etiqueta del informe significa que Google recibió una respuesta de autorización HTTP 401 para la URL. Evidence for this claim The Page Indexing report identifies URLs where Google encountered an authorization request. 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 una respuesta 4xx persistente distinta 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 for indexing. 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 ves «Blocked due to unauthorized request (401)» en el informe de Indexación de páginas de Google Search Console, te está diciendo esto: Googlebot fue a rastrear la URL y tu servidor respondió con un HTTP 401, el código de «autenticación requerida»; en esencia, «tienes que iniciar sesión para ver esto».

Googlebot no tiene nombre de usuario ni contraseña para tu sitio, ni los tendrá nunca. Por eso, cuando una página exige iniciar sesión, Googlebot no puede entrar, leer el contenido ni indexar la página. Si la página antes aparecía en Google y empieza a devolver 401, Google termina retirándola de los resultados.

¿Es un problema?

Depende de si quieres que esa página aparezca en Google:

• Quieres que se indexe → sí, es un problema. Algo está poniendo un muro de inicio de sesión delante de una página que debería ser pública. Tienes que encontrar qué la bloquea y abrirla.
• La página es privada o de staging → no, funciona como debe. Un 401 es una forma perfectamente válida de mantener un área privada fuera de Google, y no deberías debilitar esa barrera solo para borrar esta fila del informe. Lo único que debes comprobar es si esa URL debería estar enlazada, incluida en un sitemap o enviada a esta propiedad de Search Console.

«¡Pero a mí la página me carga bien!»

Esta es la confusión más habitual. Abres la URL en tu navegador y funciona, así que ¿cómo puede decir Google que está bloqueada? Porque tú has iniciado sesión (o la IP de tu oficina está en la lista de permitidos) y Googlebot no. Tú ves la página después de la barrera; Googlebot se topa con ella. Para ver lo que ve Google, tienes que probar la página como visitante anónimo; la pestaña Advanced muestra cómo.

Qué suele causarlo

• Un sitio de staging o pruebas al que se dejó una contraseña.
• Protección de inicio de sesión activada por accidente en una sección que debería ser pública.
• Una herramienta de seguridad o CDN (como Cloudflare) que bloquea a Googlebot por error.
• Un muro de inicio de sesión real en contenido que querías restringir (solo para miembros, etc.).

¿Quieres los pasos de diagnóstico reales, la diferencia entre 401 y 403 y las soluciones exactas? Pasa a la pestaña Advanced.

TL;DR — «Blocked due to unauthorized request (401)» significa que Googlebot recibió un 401 (Unauthorized): una barrera de autenticación que no puede atravesar. Google nunca proporciona credenciales, así que no ve el contenido: la página no se indexará y una URL ya indexada que devuelva 401 acabará desapareciendo. 401 frente a 403, con precisión (RFC 9110): 401 = la solicitud carece de credenciales válidas (no se enviaron o el servidor rechazó las enviadas); 403 = el servidor entendió la solicitud, pero la rechazó por motivos que no siempre tienen que ver con las credenciales. Google trata todos los 4xx salvo 429 igual para la indexación, por lo que el resultado converge, pero la causa y la solución cambian; la solución depende de la página: quitar la autenticación de una página pública bloqueada por accidente; dejar pasar a Googlebot verificado por IP o DNS inverso (nunca por un user-agent falsificable) si la seguridad de bots la bloquea por error; mantener la autenticación en contenido realmente privado o de staging; usar datos estructurados de paywall de Google, no un 401 generalizado, en contenido de suscripción indexable. «En mi navegador carga bien» es una trampa: tú estás autenticado y Googlebot no. No uses 401/403 para limitar el rastreo. Diagnostica como bot (Live Test de Inspección de URL, curl -I): una cabecera WWW-Authenticate ausente significa que la respuesta está malformada, no que la haya causado un WAF. Live Test y Validate Fix confirman acceso, no indexación, y no existe una cadencia de reintento publicada.

Qué te está diciendo realmente Google

La etiqueta de Indexación de páginas informa de la respuesta que observó Google; no identifica qué regla de autenticación, CDN o aplicación la produjo. Evidence for this claim The Page Indexing report identifies URLs where Google encountered an authorization request. 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 de indexación subyacente procede del tratamiento documentado por Google para las respuestas 4xx. Evidence for this claim Google treats 4xx responses other than 429 as if the content does not exist for indexing. 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

El estado procede directamente del código de respuesta del servidor. Googlebot solicitó la URL y recibió un HTTP 401, el estado «Unauthorized»: la página está tras una barrera de autenticación (HTTP Basic Auth, un muro de inicio de sesión o una regla de control de acceso). La propia definición de Google en el informe de Indexación de páginas dice que una solicitud de autorización bloqueó la página para Googlebot y que, si quieres indexarla, debes quitar el requisito de autorización o dejar pasar a Googlebot después de verificar su identidad.

En mi artículo Códigos de estado HTTP y su impacto en el SEO describo un 401 como el caso en que el cliente no se ha identificado o verificado cuando era necesario: un modelo mental útil, pero no la definición completa del protocolo. La regla precisa de RFC 9110 es que un 401 significa que la solicitud carece de credenciales de autenticación válidas para el recurso, y también puede aparecer después de que el servidor rechace unas credenciales. Por tanto, un 401 no siempre significa que Googlebot (o el navegador) no enviara nada, sino que lo presentado no era válido. En cualquier caso, el resultado práctico para Googlebot es el mismo: no tiene credenciales que ofrecer y nunca supera la barrera.

Qué hace Google con un 401

Nada bueno, si querías que la página se indexara. La documentación de Google sobre estados HTTP dice explícitamente que todos los errores 4xx salvo 429 se tratan igual: los rastreadores informan al siguiente sistema de procesamiento de que el contenido no existe. Por tanto, un 401 le dice en la práctica a Google «aquí no hay nada». Las consecuencias son:

• La página no se indexará. Google nunca vio el contenido, así que no hay nada que indexar.
• Una página ya indexada desaparece. No es algo exclusivo del 401: es el comportamiento de la familia 4xx. Como explico en el artículo de Ahrefs sobre códigos de estado HTTP, los 4xx hacen que las páginas salgan del índice. Un 401 en una página que Google ya había indexado hará que, tras varios rastreos, la URL termine fuera.
• No limita el rastreo. Google lo dice claramente: no uses los códigos 401 y 403 para limitar la velocidad de rastreo. Los 4xx (salvo 429) no tienen efecto sobre la velocidad, así que no puedes usar un 401 como palanca para «ir más despacio»; para eso existen 503/429.

Hay algo que no voy a darte: una cadencia concreta de reintento. Google vuelve a rastrear con el tiempo, pero la documentación no publica un calendario garantizado de «Googlebot reintenta un 401 cada N días», así que no fingiré que existe. Considera el re-rastreo como «volverá por aquí, tarde o temprano», no como un cronómetro.

401 frente a 403 y otros 4xx: la parte importante

Esta es la distinción que más se difumina en otros artículos y donde está el valor real. Para la indexación, Google trata 401 y 403 de forma idéntica (la regla de 4xx salvo 429). Pero la causa y la solución son distintas porque los códigos significan cosas diferentes:

• 401 Unauthorized, según la definición de RFC 9110: la solicitud carece de credenciales de autenticación válidas para el recurso de destino. Abarca dos casos: no se enviaron credenciales, o se enviaron y el servidor las rechazó. Una respuesta 401 conforme debe incluir una cabecera WWW-Authenticate que nombre al menos un desafío. Mi versión abreviada —«el cliente no se ha identificado o verificado cuando era necesario»— sirve como atajo para el caso común, pero trátala como modelo mental, no como la regla exhaustiva.
• 403 Forbidden, según la misma RFC: el servidor entendió la solicitud, pero se niega a cumplirla. Las credenciales son un motivo posible, pero la especificación deja claro que una solicitud «puede estar prohibida por motivos no relacionados con las credenciales». Por eso 403 no siempre significa «el cliente es conocido o está autenticado, pero carece de permisos»: es un patrón común en la práctica, no una garantía. En el informe de Indexación de páginas de Google, un 403 a Googlebot (que nunca envía credenciales) suele indicar que el servidor devuelve ese error por equivocación, a menudo por un firewall, WAF o regla de bots mal configurados. (Para ese caso existe el estado hermano Blocked due to access forbidden (403); el flujo de diagnóstico se solapa mucho.)

El atajo mental práctico sigue siendo válido para el triaje: 401 ≈ «una barrera de autenticación que olvidé levantar» (un sitio de staging o una autenticación HTTP que quedó activa), mientras que 403 ≈ «una regla de seguridad que bloquea a Googlebot por error». Mismo resultado de indexación, causa raíz distinta; no trates ningún atajo como el límite real del protocolo. La tabla de decisión está en la pestaña Cheat Sheets.

Por qué lo ves: las causas habituales

En una página que realmente quieres indexar, un 401 casi siempre se debe a una de estas causas:

• Un sitio de staging o desarrollo detrás de Basic Auth. Protegiste con contraseña un entorno de staging (buen instinto), pero Google descubrió la URL de alguna forma: un enlace interno, un sitemap o una referencia filtrada; ahora informa del 401. Si la URL de staging no debería ser pública, esto es esperable (consulta la sección del 401 intencional).
• Autenticación HTTP accidental en una sección pública. Una regla de .htpasswd, un plugin de «próximamente» o una barrera de modo mantenimiento que quedó activa en un directorio que debería estar publicado.
• Un WAF, CDN o lista de permitidos por IP que bloquea a Googlebot. Esta es la causa escurridiza. Cloudflare, Akamai, Sucuri o una lista geográfica/de IP devuelve 401 (o 403) a las IP de Googlebot mientras sirve la página a las personas. La página «funciona para todos» porque todos los que la prueban llegan desde una IP permitida.
• Un muro de inicio de sesión en contenido de suscripción o de pago que sí quieres indexar. Un 401 generalizado mantiene fuera a Googlebot; la solución no es debilitar la barrera, sino usar los datos estructurados de paywall admitidos por Google (consulta la cuarta rama).

Cómo diagnosticarlo: prueba como bot, no como navegador

La mayor trampa aquí es «a mí me funciona». Claro que sí: estás autenticado, tu IP está en la lista de permitidos o tu navegador tiene una cookie de sesión. Googlebot no tiene nada de eso. Así que diagnostica como un bot:

• Inspección de URL → Live Test (GSC). Es lo más cerca que estarás de ver la respuesta real que recibe Googlebot. Ejecútalo en la URL afectada; si no puede recuperarla por la autorización, has confirmado que el 401 es real y reproducible.

• curl -I desde un contexto no autenticado. Solicita la URL sin cookies ni credenciales y lee la línea de estado:

  curl -I https://www.example.com/page/
  # Look for:  HTTP/1.1 401 Unauthorized
  # and a WWW-Authenticate: header confirming an auth gate

  Si curl (que no envía sesión ni autenticación) recibe 401 mientras tu navegador obtiene 200, esa diferencia es el problema: tu navegador está autenticado y Googlebot no. RFC 9110 exige que un 401 conforme lleve una cabecera WWW-Authenticate; su presencia confirma un desafío de autenticación real. Su ausencia, en cambio, no te da la respuesta: indica que la respuesta está malformada o incompleta, no qué capa la produjo. No saltes directamente a «debe ser el WAF» solo por una cabecera ausente.

• Comprueba si está limitado por IP. Si curl desde tu equipo devuelve 200 pero falla el Live Test de GSC, es una señal real de que algo depende de la IP de origen o del enrutamiento; confírmalo comparando los registros del edge/CDN, del origen, de la aplicación y del proveedor de identidad antes de atribuir la causa al WAF. Una petición HEAD (la que envía curl -I) también puede enrutarse o almacenarse en caché de forma distinta a una GET, así que contrástala con una GET anónima.

Cómo solucionarlo: cuatro ramas según lo que sea la página

No hay una única solución: hay cuatro, y elegir la equivocada puede exponer contenido que querías proteger o dejar una página indexable bloqueada para siempre. Clasifica la URL en una de estas ramas antes de tocar la configuración:

1. Contenido realmente privado o de staging → conserva la autenticación y no lo toques. Si la URL de verdad no debería ser pública, el 401 funciona como está diseñado: la autenticación en el servidor es una forma legítima y recomendada por Google de mantener el contenido alejado de todo el mundo, incluido Googlebot. John Mueller ha señalado esto para los sitios de staging: la forma correcta de ocultar un sitio es usar autenticación en el servidor, por IP, cookie o autenticación normal, de modo que las personas —y eso incluye a Googlebot— no puedan ver el contenido. No incluyas a Googlebot en la lista de permitidos de una barrera que protege contenido realmente privado solo para borrar esta fila del informe; eso anula el propósito de la barrera. Aquí la solución es la higiene de descubrimiento, no el acceso: confirma que la URL no esté enlazada, incluida en un sitemap ni enviada a esta propiedad de Search Console, y deja la autenticación en su sitio.

2. Página pública bloqueada por accidente → elimina el requisito de autorización. Si la página debería indexarse y la barrera quedó de antes —Basic Auth, muro de inicio de sesión o plugin de modo mantenimiento—, desactívala para esa ruta. Este es el caso directo: cuando una petición anónima obtiene 200, la página queda abierta para Googlebot.

3. Página pública bloqueada por error por la seguridad de bots → admite a Googlebot verificado, no la cadena literal del user-agent. Cuando un WAF, CDN o lista de permitidos por IP rechaza a Googlebot en una página que sí quieres pública, incluye a Googlebot verificado por IP o DNS inverso. El user-agent se falsifica con facilidad; cualquiera puede afirmar que es Googlebot. La vía recomendada por Google es verificar el rastreador mediante sus rangos de IP publicados o una comprobación de DNS inverso y directo, y después dejar pasar esas peticiones concretas: no eliminas la regla de seguridad, sino que creas una excepción verificada. Para corregir el falso positivo:

• Identifica la regla que devuelve 401/403 a Googlebot (Cloudflare Firewall Events, registros de Akamai/Sucuri o tus propios registros de edge, origen y aplicación).
• Incluye los rangos de IP verificados de Google (o la categoría del bot) en la lista de permitidos en vez de desactivar toda la protección.
• Vuelve a probar con el Live Test de Inspección de URL hasta que Google pueda recuperar la página.

4. Contenido de suscripción o de pago que quieres indexar → no uses un 401 generalizado. Si la página está detrás de un registro o suscripción, pero quieres que se descubra en Search, un 401 duro es la herramienta equivocada sea cual sea la causa: Googlebot seguirá sin poder recuperarla. Google documenta una implementación de paywall compatible: sirve la página con los datos estructurados adecuados para contenido de pago (isAccessibleForFree, hasPart y las propiedades relacionadas), para que Google pueda indexar la parte de vista previa gratuita sin que tengas que abrir toda la página. Es un cambio de marcado y de respuesta del servidor, no de la barrera de autenticación.

Valida la solución y fija las expectativas

Cuando hayas abierto de verdad la página (y confirmado con curl o Live Test que una petición no autenticada devuelve 200), sé preciso sobre lo que confirma cada paso:

• Live Test confirma acceso, no indexación. La documentación de Inspección de URL de Google dice que la prueba en directo solo confirma si Google-InspectionTool puede acceder y analizar la página en ese momento; no hay una prueba que garantice que acabará en el índice o aparecerá en los resultados. Un Live Test aprobado significa que la barrera está abierta, no promete qué ocurrirá después.
• Validate Fix es opcional, no obligatorio. Google actualiza el recuento del problema cuando vuelve a rastrear una página, hayas pulsado Validate Fix o no. Úsalo para llevar tu propio seguimiento de una corrección real; no valides una URL que deba seguir privada y no consideres que la validación acelere la reindexación.
• No esperes una reindexación instantánea. El re-rastreo y la reindexación tardan, y, como se ha explicado, no existe una cadencia de reintento publicada que pueda citarte. Supervisa por separado el resultado indexado y el rendimiento en búsquedas; ni Live Test ni Validate Fix garantizan la selección de canonical o la aparición en búsquedas.
• Un mito que conviene descartar: un 401 en GSC no es una penalización ni una acción manual. Es un estado de acceso de rastreo. No perjudica las posiciones de tus otras páginas ni «incluye en una lista negra» a tu sitio; simplemente mantiene la página bloqueada fuera del índice.

Dónde encaja

Este es uno de los estados HTTP del informe de Indexación de páginas; sus hermanos incluyen Blocked due to access forbidden (403), los demás estados 4xx y 404 y el estado de error de servidor 5xx. Para consultar el informe y aprender a leer la tabla «Por qué las páginas no están indexadas», visita el centro del informe de Indexación de páginas. La mecánica subyacente —cómo recupera Googlebot las páginas y qué significan los códigos de estado— se explica en crawling e indexing.

Resumen de IA

Una síntesis de la versión Advanced:

• Qué es. Un estado de Indexación de páginas de GSC que significa que Googlebot recibió un HTTP 401 (Unauthorized): una barrera de autenticación que no puede atravesar. Google no proporciona credenciales, así que nunca ve el contenido.
• Qué hace Google. No indexa la página; una URL ya indexada que devuelve 401 acaba desapareciendo. Todos los 4xx salvo 429 se tratan igual: Google recibe el mensaje de que «el contenido no existe». Los 4xx no tienen efecto sobre la velocidad de rastreo, así que no uses 401/403 para ralentizar a Googlebot.
• 401 frente a 403, con precisión. Según RFC 9110: 401 = la solicitud carece de credenciales válidas (no se enviaron o se rechazaron); 403 = el servidor entendió la solicitud, pero la rechazó por motivos que no siempre tienen que ver con las credenciales. «401 = barrera de autenticación; 403 = regla de seguridad que bloquea a Googlebot por error» es un atajo de triaje útil, no la regla exhaustiva del protocolo.
• Causas habituales (en páginas que quieres indexar): sitio de staging detrás de Basic Auth, autenticación HTTP accidental en una sección pública, WAF/CDN o lista de IP que excluye a Googlebot, o muro de inicio de sesión en contenido de suscripción o de pago.
• «A mí me carga» es una trampa. Estás autenticado o tu IP está permitida; Googlebot no. Diagnostica como bot: Live Test de Inspección de URL y curl -I (sin cookies ni autenticación); un 401 allí lo confirma. Una cabecera WWW-Authenticate confirma una barrera real (RFC 9110 la exige en un 401 conforme); su ausencia solo indica que la respuesta está malformada: comprueba los registros del edge, origen, aplicación y proveedor de identidad antes de culpar a un WAF.
• Corrige según lo que sea la página, no con una solución universal. Página pública bloqueada por accidente → elimina el requisito de autorización. Página pública bloqueada por error por la seguridad de bots → incluye a Googlebot verificado por IP o DNS inverso (nunca por el user-agent falsificable) sin desactivar toda la regla. Contenido realmente privado o de staging → conserva la autenticación; nunca lo abras para borrar esta fila, solo limpia su descubrimiento (sitemaps, enlaces y propiedad). Contenido de suscripción o de pago indexable → usa los datos estructurados de paywall de Google en lugar de un 401 generalizado.
• Valida y espera, sin prometer de más. Live Test confirma el acceso actual, no la indexación. Validate Fix es opcional: Google actualiza el recuento en el siguiente rastreo de todos modos. La reindexación tarda, no hay una cadencia de reintento publicada y ninguno de los dos pasos garantiza la indexación, la selección de canonical o la aparición en búsquedas. Un 401 no es una penalización.

Documentación oficial

Documentación de fuente primaria de los buscadores.

Google

• Informe de Indexación de páginas — el informe y la definición del estado «Blocked due to unauthorized request (401)», además de su hermano 403 y los demás estados HTTP.
• Cómo afectan los códigos de estado HTTP y los errores de red y DNS a Google Search — qué hace Googlebot con un 401: el tratamiento de 4xx salvo 429 y la regla «no uses 401/403 para limitar la velocidad de rastreo».
• Verificar Googlebot y otros rastreadores de Google — la forma recomendada de incluir a Googlebot en la lista de permitidos: verificar por IP o DNS inverso, no por el user-agent.
• Rangos de IP de Googlebot (googlebot.json) — los rangos de IP publicados que puedes permitir en un WAF/CDN.

Bing / Microsoft

• Ayuda de Bing Webmaster Tools — Bing no muestra una cadena de estado idéntica, pero una URL que devuelve 401/403 también se trata como inaccesible y no se indexa; bingbot también necesita llegar a la página de forma anónima y publica rangos de IP verificados y verificación por DNS inverso para la misma solución de lista de permitidos.

Citas de la fuente

Declaraciones atribuibles. Cada enlace es profundo y salta al pasaje citado en la página de origen.

Google: qué significa el estado 401 (informe de Indexación de páginas)

• “The page was blocked to Googlebot by a request for authorization (401 response). If you do want Googlebot to be able to index this page, either remove authorization requirements for this page, or else allow Googlebot to access your pages by verifying its identity.” (traducción) «Una solicitud de autorización bloqueó la página para Googlebot (respuesta 401). Si quieres que Googlebot pueda indexarla, elimina los requisitos de autorización de la página o permite que Googlebot acceda verificando su identidad». — Ayuda de Google Search Console, informe de Indexación de páginas. Jump to quote

Google: qué hace Googlebot con un 401 (documentación de estados HTTP)

• “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. Jump to quote
• “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 velocidad de rastreo». Jump to quote

Patrick Stox: mis definiciones de 401/403 y el impacto de 4xx en el índice

• “The client hasn’t identified or verified itself when needed.” (traducción) «El cliente no se ha identificado o verificado cuando era necesario» (401). — Patrick Stox, Códigos de estado HTTP y su impacto en el SEO, Ahrefs. Jump to quote
• “The client is known but doesn’t have access rights.” (traducción) «El cliente es conocido, pero no tiene permisos de acceso» (403). Jump to quote
• “4xxs will cause pages to drop from the index.” (traducción) «Los 4xx harán que las páginas salgan del índice». Jump to quote

John Mueller, Google: la autenticación en servidor es la forma correcta de proteger un sitio

• “Ideally, what you would want to do is provide some kind of server side authentication on the server so that normal users when they go there they would get blocked from being able to see the content; that would include GoogleBot.” (traducción) «Lo ideal sería proporcionar algún tipo de autenticación en el servidor para que, cuando los usuarios normales acudieran allí, no pudieran ver el contenido; eso incluiría a GoogleBot». (Webmaster Hangout, 25 de septiembre de 2019, transmitido por Search Engine Journal.) Leer la cobertura

Lista de diagnóstico y solución del 401

Úsala cuando GSC marque «Blocked due to unauthorized request (401)»:

• Decide primero la intención: ¿realmente quieres indexar esta URL? Si es realmente privada o de staging, el 401 es correcto; pasa al último punto. Si es contenido de suscripción o de pago que sí quieres indexar, omite los pasos de quitar autenticación y usa la solución de datos estructurados de paywall.
• Reprodúcelo como bot: ejecuta Inspección de URL → Live Test en la URL y confirma el fallo de autorización (no te fíes del navegador con sesión iniciada).
• curl -I sin cookies ni credenciales: confirma que devuelve 401 y busca una cabecera WWW-Authenticate. Un 401 aquí mientras el navegador recibe 200 es el problema. La cabecera confirma una barrera real; su ausencia señala una respuesta malformada, no la capa que la produjo.
• Identifica la barrera: revisa los registros del edge/CDN, origen, aplicación y proveedor de identidad para acotarla: Basic Auth (.htpasswd), plugin de mantenimiento o «próximamente», muro de inicio de sesión o regla de WAF/CDN/lista de IP.
• Si es un WAF/CDN: revisa los eventos de firewall de la regla que bloquea a Google; incluye los rangos de IP verificados de Googlebot en la lista de permitidos y no desactives toda la protección.
• Corrige con el método adecuado: elimina el requisito de autenticación de una página pública bloqueada por accidente o permite a Googlebot verificado por IP o DNS inverso (nunca por el user-agent falsificable) si es un falso positivo de seguridad de bots. Nunca dejes pasar a Googlebot por una barrera que protege contenido realmente privado.
• Vuelve a probar: curl -I (todavía sin autenticación) devuelve ahora 200 y el Live Test de Inspección de URL puede recuperar la página.
• Validate Fix (opcional) en el informe de Indexación de páginas y vuelve a inspeccionar una URL de muestra: Google actualiza el recuento en el siguiente rastreo de todos modos; un Live Test aprobado confirma acceso, no indexación.
• Fija las expectativas: el re-rastreo y la reindexación tardan; no hay una cadencia de reintento garantizada ni garantía de indexación o aparición en búsquedas. No es una penalización.
• Si es intencional: confirma que la URL privada o de staging no debería estar en esta propiedad (deja de enlazarla o enviarla) y conserva la barrera.

401 frente a 403 y otros 4xx: hoja rápida

Qué significa realmente cada código (y cuál es la causa habitual)

Cómo los trata Google para la indexación

Mapa de soluciones

Dos soluciones oficiales para una página pública bloqueada por error (en palabras de Google)

1. Elimina el requisito de autorización de la página.
2. Deja pasar a Googlebot verificando su identidad: inclúyelo por IP o DNS inverso en la lista de permitidos, no por la cadena de user-agent (falsificable).

Ninguna se aplica al contenido realmente privado o de staging (conserva la barrera) ni al contenido de pago indexable (usa el marcado de paywall en vez de abrirla).

Los modelos mentales

1. Barrera frente a contenido. Un 401 no es un problema de contenido: Googlebot nunca llegó al contenido. Es un problema de barrera. Así que no editas la página; cambias lo que la barrera hace con un bot no autenticado. Separa siempre «¿la página es buena?» de «¿puede Googlebot pasar la puerta?».

2. La intención lo decide todo. Antes de cualquier solución, responde a una pregunta: ¿debe indexarse esta URL? Si la respuesta es sí, el 401 es una configuración incorrecta que debes quitar. Si es no, el 401 funciona como debe y la pregunta real es por qué esa URL está siquiera en esta propiedad de Search Console. No corrijas un 401 que está cumpliendo su función.

3. Prueba como bot, no como tú. «A mí me funciona» es el error de juicio predeterminado en este caso. Tú llevas una sesión, una cookie o una IP permitida. Googlebot no lleva nada de eso. Todo diagnóstico empieza eliminando esas condiciones: curl -I sin credenciales o el Live Test de Inspección de URL.

4. 401 frente a 403: mismo resultado, puerta distinta. Para la indexación son idénticos (4xx salvo 429). Según la RFC, 401 = la solicitud carece de credenciales válidas (no se enviaron o se rechazaron); 403 = el servidor entendió la solicitud y la rechazó por motivos que pueden tener o no que ver con las credenciales. Trata «401 = barrera de autenticación que controlo; 403 = regla de seguridad que falla» como atajo práctico de triaje, no como el límite real del protocolo: es suficientemente acertado para resultar útil, pero lo cierto es el texto de la RFC. Diagnostica mirando la puerta: 401 → revisa autenticación/staging; 403 → revisa WAF/firewall.

5. Verifica el bot, no te fíes del nombre. La solución que luego causa problemas es «incluye el user-agent de Googlebot en la lista de permitidos». Cualquiera puede afirmar que tiene esa cadena. La solución duradera es verificar la identidad por IP o DNS inverso: permite al bot que puedes demostrar que es Googlebot, no al que simplemente lo dice.

Diagnosticar un 401: ¿barrera intencional o configuración incorrecta?

La primera bifurcación es la intención, no la tecnología: decide si la URL debe indexarse antes de tocar la configuración. Cuando sepas que hay una configuración incorrecta real, la segunda bifurcación es si estás ante un muro de inicio de sesión que olvidaste levantar o ante una regla de WAF/CDN que bloquea a Googlebot por accidente. Ábrelo para recorrerlo.

Sigue el grupo de 401, 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 unauthorized request (401)» del informe de Indexación de páginas, no solo si la fila existe: una única instantánea no puede decirte si estás corrigiendo el problema o acumulando más URL bloqueadas.

Recuento del grupo de 401 a lo largo del tiempo

• Métrica: recuento de URL bajo «Blocked due to unauthorized request (401)» en el informe de Indexación de páginas de GSC, seguido semana a semana.
• Qué te dice: si una solución funcionó de verdad y si aparecen nuevos 401. Tras quitar un requisito de autenticación o permitir a Googlebot verificado, el recuento debería acercarse a cero para las URL corregidas. En URL bloqueadas intencionadamente (staging, secciones privadas), el recuento debería mantenerse estable; si sube, normalmente significa que nuevas URL privadas o de staging se están enlazando o incluyendo en un sitemap de esta propiedad por error.
• Cómo obtenerlo: informe de Indexación de páginas de GSC, filtrado a la fila 401; comprueba URL individuales con Inspección de URL → Live Test para confirmar que no se trata de una instantánea antigua.
• Referencia / rango realista: no hay un objetivo universal: depende por completo de cuántas páginas bloquees intencionadamente. La medida honesta es cero 401 entre las URL que quieres indexar y un recuento estable (no creciente) para las URL que mantienes deliberadamente detrás de autenticación. Establece tu propia línea base antes de juzgar la dirección de la tendencia.
• Cadencia: semanal justo después de una solución, hasta que el recuento se estabilice; después, mensual como comprobación de regresión.

Runbook: diagnostica, corrige y valida

El flujo del 401 es un ciclo corto y ordenado: no saltes directamente a «corregir» antes de confirmar la intención y reproducir el bloqueo como bot.

1. Decide primero la intención. ¿Debe indexarse realmente esta URL? Si es privada o de staging, detente aquí: el 401 es correcto y el único seguimiento consiste en asegurarte de que la URL no esté enlazada ni incluida en un sitemap de esta propiedad; no debilites la barrera. Si es contenido de suscripción o de pago que sí quieres indexar, pasa a la solución de datos estructurados de paywall en vez de tocar la barrera de autenticación.

2. Reprodúcelo como bot, no como tú. Ejecuta Inspección de URL → Live Test en GSC y solicita por separado la URL con curl -I, sin cookies ni credenciales. Si curl obtiene 401 mientras tu navegador con sesión obtiene 200, esa diferencia es el problema: tú estás autenticado o tu IP está permitida, Googlebot no.

3. Identifica la barrera. Comprueba si la respuesta anónima lleva una cabecera WWW-Authenticate: un 401 conforme debe incluirla, así que su presencia confirma una barrera real (Basic Auth, muro de inicio de sesión o modo mantenimiento). Su ausencia no te da la causa; significa que la respuesta está malformada, así que contrasta los registros del edge/CDN, origen, aplicación y proveedor de identidad antes de concluir que es una regla de WAF/CDN o de lista de permitidos.

4. Corrige según la causa. Barrera de autenticación en una página pública por accidente → elimina el requisito de autorización para esa ruta. Regla de WAF/CDN que bloquea por error una página pública → incluye a Googlebot verificado por IP o DNS inverso en el firewall, nunca solo por la cadena de user-agent falsificable. Nunca permitas que Googlebot atraviese una barrera que protege contenido realmente privado.

5. Valida. Vuelve a ejecutar el mismo curl -I anónimo y confirma que ahora devuelve 200. Validate Fix en el informe de Indexación de páginas es un seguimiento opcional: Google actualiza el recuento en el siguiente rastreo de todos modos, y el Live Test de Inspección de URL solo confirma que Google-InspectionTool puede acceder a la página ahora, no que vaya a indexarse.

6. Fija las expectativas y detente. El re-rastreo y la reindexación tardan, no hay una cadencia de reintento publicada y ni Live Test ni Validate Fix garantizan la indexación o la aparición en búsquedas: no «corrijas» dos veces la misma URL mientras esperas. Si el recuento del grupo de 401 en GSC no baja después de un par de semanas, vuelve al paso 2 y reprodúcelo en vez de adivinar una causa nueva.

Prompts de IA listos para usar

Prompts para copiar y pegar y clasificar un 401 a partir de datos de diagnóstico sin procesar. Te ayudan a hacer un triaje rápido de la causa probable; confirma siempre la conclusión contra la configuración real del servidor o firewall antes de cambiar nada.

Clasifica la causa probable a partir de la salida de curl

I'm diagnosing a "Blocked due to unauthorized request (401)" status in Google
Search Console. Below is the raw output of an unauthenticated request to the
URL (curl -I, no cookies, no credentials). Based on this output alone,
classify the most likely cause as one of: (1) staging/dev site behind Basic
Auth, (2) accidental HTTP auth or maintenance-mode gate left on a public
section, (3) WAF/CDN/IP-allowlist blocking Googlebot, (4) a login wall on
content that's meant to be gated. Explain which specific header or detail in
the output pointed you to that answer, and tell me what's missing if you
can't tell for sure.

CURL OUTPUT:
[paste]

Clasifica la causa a partir de una línea de registro del WAF/firewall

I'm investigating why Googlebot is getting a 401 or 403 on a page I want
indexed. Below is a log line (or a few) from my WAF/CDN showing a blocked
request. Tell me whether this looks like a bot-identity rule (blocking by
user-agent or IP range), a rate-limit/challenge rule, or something else, and
what I'd need to allowlist — by IP range or reverse-DNS — to let verified
Googlebot through without disabling the rule entirely.

LOG LINE(S):
[paste]

Comprueba la sensatez de una solución antes de publicarla

I'm about to remove an authorization requirement from a URL that's currently
returning 401 to Googlebot, because I want it indexed. Here's a short
description of the current gate and what I'm about to change: [describe].
Point out anything I might be missing — e.g. whether this could accidentally
expose a section I meant to keep private, or whether I should allowlist
verified Googlebot instead of removing the auth requirement outright.

Ponte a prueba: «Blocked due to unauthorized request (401)»

Cinco preguntas sobre qué significa un 401, en qué se diferencia de un 403 y cómo diagnosticarlo y corregirlo. Elige una respuesta para cada una y compruébala después.

Reproduce el 401 como una petición anónima

El objetivo de estas comprobaciones es el mismo que plantea la pestaña Advanced: tu navegador está autenticado y Googlebot no. Elimina por completo las cookies y las credenciales y comprueba qué recibe realmente un cliente anónimo.

macOS / Linux

# Fetch headers only, with no cookies and no credentials
curl -sI https://www.example.com/page/
# Look for:
#   HTTP/1.1 401 Unauthorized
#   WWW-Authenticate: Basic realm="..."   <- confirms a real auth gate

Windows (PowerShell)

# -SkipHttpErrorCheck so PowerShell shows the 401 instead of throwing
Invoke-WebRequest -Uri "https://www.example.com/page/" -Method Head `
  -SkipHttpErrorCheck | Select-Object StatusCode, Headers
# Check the Headers output for WWW-Authenticate

Si devuelve 401 con una cabecera WWW-Authenticate, has confirmado una barrera de autenticación real (Basic Auth o muro de inicio de sesión): RFC 9110 exige que un 401 conforme envíe esa cabecera. Si devuelve 401/403 sin cabecera WWW-Authenticate, eso te dice que la respuesta está malformada o incompleta, no qué capa la produjo; la ausencia de la cabecera por sí sola no demuestra que sea un WAF o CDN. Si el bloqueo solo ocurre fuera de tu red, esa limitación por IP es una pista más fuerte hacia una regla de WAF/CDN o lista de IP; confírmala en los registros del firewall/CDN, vuelve a probar desde otra red o usa el Live Test de Inspección de URL de GSC, que solicita la página como Googlebot.

Verifica que un bot sea realmente Googlebot (antes de permitirlo)

Antes de abrir una regla del WAF para dejar pasar una petición de «Googlebot», confirma que la IP sea realmente de Google: mucho tráfico falsifica la cadena de user-agent.

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 la incluyas en la lista de permitidos: no es Googlebot. También puedes comparar la IP con los rangos publicados por Google (googlebot.json) o verificarla directamente con la herramienta Googlebot Verifier. Permite por identidad verificada, nunca solo por la cadena de user-agent.

Herramientas para diagnosticar y corregir un 401

• HTTP Status Checker: pega la URL afectada (o un lote) para confirmar el código de estado, ver toda la cadena de respuesta y detectar cualquier redirección que ocurra antes de llegar a la barrera de autenticación.
• Googlebot Verifier: comprueba si una IP que afirma ser Googlebot es auténtica (rangos de IP publicados más confirmación por DNS inverso) antes de permitirla a través de una regla de WAF o firewall.
• Google Search Console — Inspección de URL → Live Test: lo más cerca que estarás de ver la respuesta exacta que recibe Googlebot, incluido si ahora está bloqueado por autorización.
• curl -I: la forma más rápida de solicitar una URL sin cookies ni credenciales y leer la línea de estado y las cabeceras sin procesar, incluida WWW-Authenticate.
• Registro de eventos del firewall de tu WAF/CDN (Cloudflare, Akamai, Sucuri, etc.): encuentra la regla concreta que devuelve 401/403 a los rangos de IP de Googlebot.

Demuestra que la solución funcionó de verdad

Cuando hayas quitado un requisito de autenticación o permitido a Googlebot verificado, estas comprobaciones separan «la configuración cambió» de «Google ya puede llegar de verdad a la página». Ejecútalas en orden.

Prueba 1: una petición anónima devuelve ahora 200

• Prueba: ejecuta curl -I sin cookies ni credenciales en la URL afectada (o compruébala con HTTP Status Checker).
• Resultado esperado: la línea de estado dice HTTP/1.1 200 OK y no hay cabecera WWW-Authenticate.
• Interpretación de un fallo: que siga en 401 significa que el requisito de autenticación no se quitó realmente para esa ruta o que estás probando la URL o el entorno equivocados. Un 403 en lugar de 401 significa que cambiaste una barrera por otra: revisa la regla del WAF/CDN.
• Ventana de seguimiento: inmediata: el servidor responde en cuanto el cambio está activo.
• Disparador de rollback: si quitar la barrera expone contenido que querías mantener privado, restablece de inmediato el requisito de autenticación y permite a Googlebot verificado por IP o DNS inverso.

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

• Prueba: ejecuta Inspección de URL → Probar URL en directo en Google Search Console sobre la URL afectada.
• Resultado esperado: la prueba en directo tiene éxito y muestra el contenido de la página; no informa de un fallo de autorización. Esto confirma que Google-InspectionTool puede acceder y analizar la página ahora: es un resultado de acceso, no una garantía de indexación. La documentación de Google dice que la prueba en directo no comprueba todas las condiciones de indexación y que aprobarla no garantiza la inclusión en el índice.
• Interpretación de un fallo: si Live Test sigue informando de un bloqueo de autorización después de que la prueba anónima con curl pase, sospecha de una regla limitada específicamente a los rangos de Googlebot (un problema de lista de permitidos del WAF/CDN), no de una barrera de autenticación general.
• Ventana de seguimiento: inmediata o de unos minutos después de la solución.
• Disparador de rollback: N/A: 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 401 desaparece del informe de Indexación de páginas

• Prueba: usa Validate Fix (opcional: Google actualiza el recuento en el siguiente rastreo de todos modos) en el problema «Blocked due to unauthorized request (401)» del informe de Indexación de páginas y observa el recuento del grupo durante las semanas siguientes (consulta la pestaña How to Measure).
• Resultado esperado: la URL sale del grupo de 401 y, si estaba indexada, reaparece en el índice con el tiempo. Ni Validate Fix ni un Live Test aprobado garantizan la indexación, la selección de canonical o la aparición en búsquedas; sigue por separado el estado realmente indexado y el rendimiento de búsqueda.
• Interpretación de un fallo: no existe una cadencia de reintento publicada, así que no interpretes una validación lenta como un fallo nuevo. Si el recuento del grupo de 401 no baja tras un par de semanas, vuelve a ejecutar la Prueba 1 para confirmar que la solución sigue activa (un despliegue nuevo o la caché del CDN puede reintroducir la barrera silenciosamente).
• Ventana de seguimiento: de días a unas semanas, siguiendo el recuento del grupo de 401.
• Disparador de rollback: vuelve a revisar la barrera solo si la Prueba 1 vuelve a fallar; no persigas los tiempos del informe de Indexación de páginas.

Registro de cambios