Bloqueado por acceso prohibido (403)
Qué significa el estado «Blocked due to access forbidden (403)» en el informe de Indexación de páginas de Google Search Console, por qué Googlebot recibe un 403 cuando tu navegador no, en qué se diferencia de 401 y cómo diagnosticarlo, corregirlo y validarlo.
Idiomas
2 señales de evidencia en esta página
- Datos de origen enlazadosgooglebot.json
- Herramienta activa relacionadaHTTP Status & Redirect Checker
«Blocked due to access forbidden (403)» en el informe de Indexación de páginas de GSC significa que Googlebot rastreó la URL y tu servidor devolvió HTTP 403. Google no la indexará (y la elimina si ya estaba indexada). La ayuda de Indexación de páginas de Google describe el 403 como credenciales proporcionadas pero rechazadas —esa es la redacción del informe de Google, no la definición HTTP completa; RFC 9110 define el 403 de forma más amplia y puede no tener relación con credenciales—. Si la URL debe ser pública e indexable, trata el 403 como un error que debes encontrar; si debe seguir siendo privada, el 403 puede estar cumpliendo su función: corrige las señales de descubrimiento. En las URL que deberían ser públicas, un firewall, CDN o WAF es una causa mencionada con frecuencia, por eso la página suele cargarse bien en tu navegador pero devolver 403 a Google. Google trata 401 y 403 igual para la indexación y dice que no uses ninguno para limitar la tasa: usa 429 o 503. Verifica el Googlebot real antes de permitirlo, limita cualquier excepción y confirma después un 200 en URL Inspection y Validate Fix.
TL;DR — “Blocked due to access forbidden (403)” en Google Search Console significa que Googlebot intentó leer tu página y el servidor respondió «no tienes permiso» (un HTTP 403). La página no se indexará. Si debería ser pública, es un error que debes corregir: a menudo un firewall, una CDN o un plugin de seguridad bloquea Google por equivocación; por eso la página puede verse bien en tu navegador pero estar bloqueada para Google. Si la página debe seguir siendo privada, el 403 quizá esté haciendo exactamente lo que debe; la solución es otra.
Qué significa este estado
Esta etiqueta del informe significa que Google recibió una respuesta HTTP 403 al solicitar la URL. Evidence for this claim The Page Indexing report identifies URLs where Google encountered a forbidden-access response. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: Google: Page indexing report Google trata las respuestas 4xx persistentes 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 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: Google: HTTP status codes
Cuando abres el informe de Indexación de páginas en Search Console y ves «Blocked due to access forbidden (403)», te está diciendo algo sencillo: Googlebot pidió a tu servidor la página y el servidor rechazó la solicitud con un error 403 Forbidden.
Como Google recibió un 403, no puede leer el contenido de la página, así que no la indexará; y si ya estaba en Google, desaparece de los resultados.
¿De verdad debes corregirlo?
Antes de perseguir una regla, decide qué función debe cumplir la URL:
- Debe ser pública y estar indexada: el 403 es un error. Sigue leyendo; el resto de esta página explica la solución.
- Debe ser pública, pero no estar indexada: no dependas de robots.txt para esto; una desautorización en robots.txt es una barrera independiente, con su propio motivo en el informe, y por sí sola no puede producir un HTTP 403. Sirve la respuesta normal
200y utiliza una directivanoindex. - Debe seguir siendo privada: el 403 puede ser un control de acceso correcto y operativo. La solución no es la regla del firewall, sino comprobar que la URL no esté en tu sitemap ni en enlaces internos donde Google siga encontrándola.
Por qué se carga para ti, pero no para Google
Esta es la parte confusa en el caso de «debe ser pública». Haces clic en la URL en tu navegador y se carga perfectamente; entonces, ¿cómo puede Google estar bloqueado?
Tu navegador envía señales que un rastreador no envía: cookies, un user-agent de navegador «normal» y, en las barreras con desafío de JS o CAPTCHA, la capacidad de superar el desafío. La solicitud de Googlebot suele ser distinta: no lleva cookies y usa un user-agent de rastreador; eso puede bastar para que una regla contra scrapers se active solo para el rastreador, mientras los visitantes reales pasan sin problemas. Normalmente la página no está rota: una regla bloquea al visitante equivocado. (La pestaña Avanzado muestra cómo confirmar la diferencia exacta en lugar de adivinar.)
Un firewall o una CDN son causas frecuentes según los informes
En las URL que deberían ser públicas, que un firewall, una CDN o una herramienta de seguridad (por ejemplo, Cloudflare, un WAF o un plugin de seguridad de WordPress) bloquee por error a Googlebot es una de las causas más mencionadas, aunque no existe una cifra verificada de forma independiente sobre su frecuencia exacta. Otras causas son las reglas que bloquean por user-agent o país, la protección contra hotlinking o poner detrás de un inicio de sesión contenido que debería ser público.
Cómo empezar a corregirlo
- En Search Console, usa URL Inspection en una URL afectada y pulsa Test live URL para confirmar que Google realmente recibe un 403.
- Comprueba la configuración y los registros de tu CDN, firewall o plugin de seguridad para detectar cualquier bloqueo a Googlebot o a sus rangos de IP.
- Asegúrate de que sea realmente Googlebot antes de permitirlo y mantén la excepción limitada: la ruta y la regla concretas, no una autorización general. Muchos bots falsifican el nombre Googlebot. (Las pestañas Advanced y Scripts explican cómo verificarlo.)
- Una vez corregida la regla, la página debería devolver un
200normal. Después usa Validate Fix en el informe: la reindexación ocurre automáticamente cuando Google vuelve a rastrear el200, aunque no existe un plazo garantizado.
Conviene conocer un estado hermano: «Blocked due to unauthorized request (401)» es la misma idea, pero para páginas detrás de un muro de inicio de sesión. El mecanismo es distinto, pero el resultado y, en gran medida, la solución son los mismos.
¿Quieres el ciclo completo de diagnóstico y solución, los detalles del WAF y los comandos para verificar Googlebot? Cambia a la pestaña Avanzado.
TL;DR — Un 403 en el informe de Indexación de páginas significa que Googlebot recibió un HTTP 403 en la URL, así que Google no la indexará (y la elimina si ya estaba indexada). La ayuda de Indexación de páginas de Google presenta un 403 como credenciales enviadas pero rechazadas; esa es la redacción del informe de Google, no la definición HTTP completa. RFC 9110 define el 403 de forma más amplia como «la solicitud se entendió, pero se rechazó», con o sin credenciales, así que trata el encuadre de Google como una heurística, no como una prueba de configuración incorrecta. Decide primero si la URL debe ser pública e indexable: en las URL que deberían ser públicas, un firewall, una CDN o un WAF que bloquea involuntariamente a Googlebot es una causa mencionada con frecuencia, por eso la página puede renderizarse para ti pero devolver 403 a Google; en cambio, un 403 en una URL que debe ser privada puede estar funcionando como corresponde. Google trata 401 y 403 igual para la indexación y dice explícitamente que no se deben usar 401/403 para limitar la tasa de rastreo: usa 429 (o 503). Verifica el Googlebot real (DNS inverso, rangos de IP publicados y la categoría correcta del cliente) antes de incluirlo en una lista de permitidos, limita cualquier excepción a la ruta y regla concretas y después confirma un 200 en URL Inspection → Test live URL y ejecuta Validate Fix.
Lo que Google realmente dice sobre un 403 y lo que realmente dice HTTP
La etiqueta informa de la respuesta observada, no del WAF, la CDN o la regla de acceso específica que la provocó. Evidence for this claim The Page Indexing report identifies URLs where Google encountered a forbidden-access response. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: Google: Page indexing report Su consecuencia para la indexación se deriva del tratamiento general de los 4xx por parte de Google. 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: Google: HTTP status codes
La documentación del informe de Indexación de páginas de Google lo describe así: un HTTP 403 significa que el user-agent proporcionó credenciales, pero no obtuvo acceso; sin embargo, Googlebot nunca proporciona credenciales, por lo que, en palabras de Google, tu servidor está devolviendo el error incorrectamente. La página no se indexará. Si quieres que se indexe, la solución de Google es admitir a usuarios que no hayan iniciado sesión o permitir explícitamente las solicitudes de Googlebot sin autenticación.
Ese es el encuadre de la ayuda de Google, pero no la definición HTTP completa. RFC 9110 (la especificación actual de semántica HTTP) define el 403 de forma más amplia: el servidor entendió la solicitud y se niega a cumplirla. Las credenciales pueden formar parte del motivo, pero la RFC deja claro que una solicitud puede estar prohibida por razones totalmente ajenas a las credenciales: una política, una regla de control de acceso, una decisión de seguridad del edge o cualquier otra decisión del propietario del servidor. La conclusión útil no es «un 403 a Googlebot siempre significa por definición que una regla está rota», sino «averigua si esta URL debe ser accesible y encuentra después la regla exacta que devolvió el 403». Para una página que debería ser pública e indexable, un 403 a Googlebot casi siempre es algo que corregir. Para una página deliberadamente privada o prohibida, el 403 puede ser una decisión de acceso válida y operativa: el problema suele ser que Google no debería haber descubierto la URL en primer lugar (consulta la comprobación de intención más abajo), no que el firewall esté equivocado.
Sea cual sea el caso, la documentación independiente de Google sobre códigos de estado HTTP es tajante sobre la consecuencia para la indexación: no utiliza el contenido de las URL que devuelven códigos 4xx; todos los errores 4xx, salvo 429, se tratan igual (el rastreador informa al sistema siguiente de que el contenido no existe), y el proceso de indexación elimina la URL del índice si ya estaba indexada.
Decide qué debe hacer la URL antes de corregir nada
No todas las filas de este informe necesitan la misma solución. Clasifica primero la URL en uno de estos cuatro grupos:
- Pública y destinada a indexarse. El 403 es involuntario: recorre el ciclo de diagnóstico → solución → validación de abajo.
- Pública, pero no destinada a indexarse. No recurras a robots.txt para resolverlo: la desautorización de robots.txt es una barrera de rastreo independiente, con su propio motivo en Indexación de páginas («blocked by robots.txt»); por sí sola no produce el HTTP 403 que informa este estado. Sirve el
200normal y utiliza una directivanoindex(o una redirección o eliminación adecuada). - Deliberadamente privada o prohibida. Un 403 puede ser el resultado correcto e intencionado para un recurso al que el solicitante no debe acceder. Si aparece en este informe, el problema accionable suele ser que la URL sea descubrible (en tu sitemap, en enlaces internos o en otro lugar), no que la regla de acceso sea incorrecta. Limpia la señal de descubrimiento en vez de abrir la puerta.
- Una URL que no debería existir o cuya existencia no quieres confirmar. Elige la respuesta según la política de seguridad de tu aplicación, no como atajo de SEO: un 403 (o un 404 si no quieres confirmar que la URL existe) puede ser legítimo en ambos casos.
A partir de aquí, todo supone el caso 1: una URL que realmente quieres que se rastree y se indexe.
403 frente a 401: cómo distinguirlos
Estos dos estados son hermanos en el informe y muchos artículos los simplifican con una regla práctica («403 = no se pidieron credenciales; 401 = muro de inicio de sesión») que por sí sola no es fiable: una capa de autenticación mal configurada también puede devolver 403 y acabar en esta fila. La respuesta es la señal real:
- 401 (unauthorized): según RFC 9110, un 401 significa específicamente que faltan credenciales de autenticación válidas, y la respuesta debe incluir una cabecera de desafío
WWW-Authenticate(autenticación HTTP, un muro de inicio de sesión). Se informó a Google de que debía autenticarse y no pudo. - 403 (access forbidden): es un rechazo más amplio. RFC 9110 lo define como “the server understood the request but refuses to fulfill it,” (traducción) «el servidor entendió la solicitud, pero se niega a cumplirla», con o sin credenciales. En la práctica, esta fila suele corresponder a un bloqueo del firewall, CDN, WAF o regla de seguridad, pero también puede ser una aplicación que devuelve 403 por una comprobación de autenticación rota, un limitador de tasa o una decisión deliberada de control de acceso.
Para distinguirlos de verdad en una URL concreta, comprueba el estado y las cabeceras devueltas: ¿la respuesta lleva una cabecera WWW-Authenticate? No supongas el mecanismo a partir de la etiqueta del informe. Comparten el resultado (no indexado) y a menudo la solución (permitir el paso a un Googlebot verificado o abrir el contenido a usuarios anónimos), así que el mismo ciclo de diagnóstico de abajo sirve para ambos estados.
Qué efecto tiene un 403 en la indexación
Cuando Googlebot recibe un 403, se derivan tres cosas:
- El contenido se ignora. Google no utiliza el contenido de las URL
4xx, así que nada de la página puede indexarse. - La URL se elimina si estaba indexada. Un 403 puede desindexar una página que antes posicionaba: no es solo un problema de «no se añadirá», sino de «desaparece».
- La frecuencia de rastreo decae. Con el tiempo, Google rastrea las URL
4xxcada vez menos; por eso un 403 prolongado recibe menos visitas y se recupera más despacio una vez corregido.
Por qué Googlebot recibe un 403 cuando tu navegador no
Esta es la pregunta que hace dar vueltas a mucha gente. La página se carga en tu navegador, así que el contenido está bien; pero Google informa de un 403. La explicación probable es que tu navegador y Googlebot hacen solicitudes con aspectos muy distintos, y una regla de gestión de bots creada para detener scrapers puede activarse para el rastreador mientras sirve normalmente a las personas. Trátalo como una hipótesis que debes confirmar, no como una conclusión, porque el atributo que realmente importa cambia según el sitio:
- Tu navegador envía cookies, un user-agent de navegador real y puede resolver un desafío de JS o CAPTCHA; la solicitud de Googlebot normalmente no lleva nada de eso: no lleva cookies, usa un user-agent de rastreador y no puede resolver un desafío interactivo (aunque Google-InspectionTool sí renderiza JavaScript e informa del resultado renderizado, así que “Googlebot has no JavaScript” (traducción) «Googlebot no tiene JavaScript» no es exacto para todas las partes de este proceso).
- Además de las diferencias del cliente, las dos solicitudes pueden diferir en IP de origen/categoría, geografía, método, referer, estado de la caché y regla que se activó: cualquiera de esos factores puede ser el desencadenante real.
No adivines qué atributo lo causó. Compara los registros exactos del edge y del origen para una solicitud realmente bloqueada con los de una visita normal del navegador: el mismo ID de regla, cabeceras de respuesta, método, UA, IP de origen y su categoría verificada, geografía, cookies, referer, estado de la caché y resultado del desafío. Cambia un atributo cada vez hasta encontrar el que invierte la respuesta. Así confirmas que el 403 es selectivo en lugar de darlo por supuesto.
Causas habituales
- Gestión de bots en CDN / WAF. Cloudflare (Bot Fight Mode / Super Bot Fight Mode, Browser Integrity Check, Managed Challenge), Akamai, Imperva/Incapsula, Sucuri y AWS WAF pueden desafiar o devolver 403 a clientes que no son navegadores, incluido Googlebot. En las URL que deberían ser públicas, esta es una de las causas más mencionadas y casi siempre es involuntaria, aunque no hay una cifra verificada de forma independiente sobre la proporción de casos que representa.
- Firewall del servidor / reglas de seguridad. mod_security / OWASP CRS, fail2ban o firewalls del host que marcan como abusivo el patrón de Googlebot.
- Reglas de user-agent / referer / hotlinking. Reglas que devuelven 403 a cualquier solicitud que no tenga un user-agent o referer parecido al de un navegador.
- Bloqueo geográfico o de IP. Excluir los rangos de IP desde los que rastrea Googlebot (Googlebot rastrea sobre todo desde IP de EE. UU.), de modo que un bloqueo por país lo capture sin avisar.
- Muros de inicio de sesión o credenciales. Exigir cookies o un inicio de sesión para ver contenido que debería ser público; esto se solapa con el caso 401.
- Reglas de limitación de tasa que devuelven 403 después de N solicitudes. No lo hagas; consulta la sección siguiente.
No uses 403 para limitar Googlebot
Este es el antipatrón que merece ser nombrado. Algunas personas (y algunas CDN) devuelven 403 o 404 para ralentizar Googlebot y reducir la carga del servidor. Google ha dejado claro que no funciona y que no debe hacerse: no uses códigos de estado 401 y 403 para limitar la tasa de rastreo. No afectan a la tasa; simplemente desindexan la página. Si de verdad necesitas que Googlebot reduzca el ritmo, devuelve 429 (o un 5xx como 503): esos son los códigos que Google interpreta como «reduce la velocidad», y el efecto es temporal, no permanente.
Cómo diagnosticarlo
- URL Inspection → Test live URL. Pasa una URL afectada por Search Console y usa Test live URL para confirmar que Google recibe actualmente un 403 (no un informe obsoleto). Recuerda que esta prueba la realiza Google-InspectionTool, un cliente concreto de Google: que la prueba en vivo funcione demuestra que InspectionTool pudo pasar en ese momento, no que el Googlebot programado vaya a seguir exactamente la misma ruta de WAF, geografía, caché o limitación de tasa en su próximo rastreo.
- Reprodúcelo como Googlebot. No pruebes desde tu navegador normal: solicita la URL con el user-agent de Googlebot, idealmente desde fuera de tu red y desde más de una región (Google rastrea sobre todo desde IP de EE. UU., pero puede cambiar a otros países si se bloquean las solicitudes estadounidenses; una prueba correcta en una sola región no demuestra acceso global). Así activarás la misma regla. (Los comandos están en la pestaña Scripts.)
- Lee los registros de la CDN / WAF / firewall. Encuentra la regla exacta que se activó en la solicitud de Googlebot: compara sus cabeceras de respuesta, ID de regla y desencadenante (user-agent, IP, desafío o límite de tasa) con la entrada de una visita normal del navegador, en lugar de suponer qué atributo lo causó.
- Verifica el Googlebot real y su categoría. Antes de permitir nada, confirma que las solicitudes son realmente de Googlebot mediante DNS inverso y directo o los rangos de IP publicados por Google, y comprueba qué cliente de Google hizo la solicitud. El Googlebot común, los rastreadores especiales y los recuperadores activados por usuarios (como Google-InspectionTool) usan máscaras de host y listas de IP distintas; verificar contra la lista equivocada puede hacer que una solicitud real parezca suplantada.
Cómo corregirlo
- Limita una excepción para el Googlebot verificado en tu WAF o firewall mediante identidad verificada (DNS inverso y directo, asociado a la categoría correcta del cliente) o los rangos actuales de IP de rastreadores publicados por Google, no confiando solo en la cadena de user-agent. Mantén la excepción limitada: las rutas concretas que la necesitan y la regla específica que bloquea, no una autorización general para todo Google. Conserva los demás controles de seguridad, límites de tasa y registros, y establece una fecha de caducidad o revisión para que una lista antigua no sobreviva en silencio a su motivo. Pide a tu proveedor de CDN o firewall que confirme que Googlebot está permitido y automatiza la comprobación de tus reglas de bloqueo contra las subredes actuales publicadas por Google para que una futura actualización de rangos no vuelva a bloquearte sin avisar.
- Abre el contenido público a usuarios anónimos. Si el 403 procede de exigir un inicio de sesión o una cookie en contenido que debería ser público, elimina ese requisito (también es la solución compartida con el estado hermano 401).
- Cambia los límites 403 por 429. Si una regla devuelve 403 después de superar un umbral de solicitudes, haz que devuelva 429 (o 503) para que Googlebot lo interprete como «reduce la velocidad» y no como «vete».
Valida la solución y vuelve a indexarlo
Una vez corregida la regla, la URL debería devolver 200. Después:
- URL Inspection → Test live URL para confirmar que la respuesta en vivo es ahora
200. - Request indexing para las URL prioritarias y/o pulsa Validate Fix en la fila «Blocked due to access forbidden (403)» del informe de Indexación de páginas.
- La reindexación ocurre automáticamente cuando Google vuelve a rastrear un
200: no existe una garantía oficial sobre la rapidez exacta y la URL todavía debe superar un rastreo normal antes de reaparecer. No necesitas activar nada manualmente aparte de retirar el bloqueo, confirmar que la respuesta es correcta y dar tiempo a Google para volver a rastrear.
Para entender mejor qué motivos de no indexación aparecen aquí y cómo agrupa el informe, consulta el resumen del informe de Indexación de páginas. El estado hermano, «Blocked due to unauthorized request (401)», es la versión 401 de este mismo problema.
Resumen de IA
Una versión condensada de la explicación avanzada:
- Qué es. «Blocked due to access forbidden (403)» en el informe de Indexación de páginas de GSC significa que Googlebot rastreó la URL y el servidor devolvió HTTP 403. Google no la indexará y la elimina si ya estaba indexada.
- El encuadre de Google frente al de HTTP. La ayuda de Google describe el 403 como credenciales proporcionadas pero rechazadas; esa es la redacción de su informe, no la definición HTTP completa. RFC 9110 define el 403 de forma más amplia: un rechazo que el servidor puede emitir con o sin credenciales, por cualquier motivo.
- Decide primero la intención de la URL. Pública y destinada a indexarse → corrige el 403. Pública, pero no destinada a indexarse → usa
noindex, no robots.txt (que es una barrera independiente y por sí sola no puede producir un 403). Deliberadamente privada → el 403 puede ser correcto; limpia la forma en que Google descubre la URL. - Una causa mencionada con frecuencia (en URL públicas). Un firewall, CDN o WAF (Cloudflare, Akamai, Imperva/Incapsula, Sucuri o AWS WAF), o un plugin de seguridad, bloquea Googlebot casi siempre sin intención, aunque no hay una cifra verificada de la frecuencia de esta causa concreta.
- Por qué puede cargarse para ti y no para Google. Tu navegador suele llevar cookies, un user-agent real y capacidad para resolver desafíos que la solicitud de Googlebot no tiene; confirma el desencadenante real comparando los registros en lugar de suponerlo.
- 401 frente a 403. Comprueba la respuesta: 401 exige un desafío
WWW-Authenticate; 403 es un rechazo más amplio que puede darse con o sin credenciales. Google trata ambos igual para la indexación y sus soluciones suelen solaparse. - No lo uses para limitar la tasa. No uses 401/403 para limitar el rastreo: solo desindexan. Usa 429 (o 503) para indicar «reduce la velocidad».
- Diagnóstico. URL Inspection → Test live URL (confirma el acceso de Google-InspectionTool en ese momento, no la ruta exacta del Googlebot programado); reproduce como Googlebot desde más de una región; compara línea por línea los registros del WAF o firewall; verifica el Googlebot real y la categoría de su cliente antes de permitirlo.
- Solución y validación. Limita una excepción estrecha para el Googlebot verificado (o abre el contenido), cambia los límites 403 por 429, confirma un
200en Test live URL y ejecuta Validate Fix. La reindexación ocurre automáticamente cuando Google vuelve a rastrear un 200, sin un plazo garantizado.
Documentación oficial
Documentación de fuentes primarias de los motores de búsqueda.
- Informe de Indexación de páginas: el propio informe, incluidas las entradas «Blocked due to access forbidden (403)» y «Blocked due to unauthorized request (401)», y el significado de cada una.
- Cómo afectan los códigos de estado HTTP y los errores de red y DNS a la Búsqueda de Google: cómo trata Google los
4xx(contenido ignorado, URL eliminada del índice) y la regla contra usar 401/403 para limitar la tasa de rastreo. - Verificación de Googlebot y otros rastreadores de Google: DNS inverso y directo, y rangos de IP publicados, para permitir el Googlebot real y no un suplantador.
- Descripción general de los rastreadores y recuperadores de Google: todos los user-agent de Google y los archivos JSON de rangos de IP con los que compararlos.
- Don’t 404 my yum (Blog de Search Central, 2023): Google pide a propietarios de sitios y CDN que dejen de usar 403/404 para limitar Googlebot y explica qué usar en su lugar.
Bing / Microsoft
- Bing Webmaster Tools — Crawl Control: Bingbot, como Googlebot, no puede indexar una página que recibe un 403; verifica que las reglas del firewall o CDN no estén bloqueando Bingbot (los nombres de host resuelven a
*.search.msn.com) y utiliza Crawl Control para gestionar la velocidad en lugar de bloquearlo.
Estándar HTTP
- RFC 9110 — Semántica HTTP, §15.5.2 (401) y §15.5.4 (403): las definiciones del protocolo que esta página utiliza para corregir la redacción más estrecha y basada en credenciales de la ayuda de Google: 401 exige un desafío
WWW-Authenticate, mientras que 403 es un rechazo más amplio que puede producirse con o sin credenciales.
Citas de la fuente
Declaraciones de Google registradas públicamente. Cada enlace profundo salta al pasaje citado de la página de origen.
Google: qué significa un 403 para la indexación (informe de Indexación de páginas)
- “HTTP 403 means that the user agent provided credentials, but was not granted access. However, Googlebot never provides credentials, so your server is returning this error incorrectly. The page will not be indexed.” (traducción) «HTTP 403 significa que el user-agent proporcionó credenciales, pero no obtuvo acceso. Sin embargo, Googlebot nunca proporciona credenciales, por lo que tu servidor está devolviendo este error incorrectamente. La página no se indexará.» — Ayuda de Google Search Console, «Page Indexing report». Saltar a la cita
Google: cómo se gestionan los 4xx (incluido 403)
- “Google doesn’t use the content from URLs that return
4xxstatus codes.” (traducción) «Google no utiliza el contenido de las URL que devuelven códigos de estado4xx.» — Documentación de Google Search Central. Saltar a la cita - “All
4xxerrors, except429, are treated the same: Google crawlers inform the next processing system that the content doesn’t exist.” (traducción) «Todos los errores4xx, salvo429, se tratan igual: los rastreadores de Google informan al siguiente sistema de procesamiento de que el contenido no existe.» Saltar a la cita
Google: no uses 401/403 para limitar la tasa de rastreo
- “Don’t use
401and403status codes for limiting the crawl rate.” (traducción) «No uses códigos de estado401y403para limitar la tasa de rastreo.» — Documentación de Google Search Central. Saltar a la cita
Lista de comprobación: diagnosticar, corregir y validar un 403
Ejecuta esto contra cualquier URL que muestre «Blocked due to access forbidden (403)»:
- Decide la intención de la URL: pública/indexable, pública/no indexable, deliberadamente privada o no debería ser descubrible. Solo el caso pública-e-indexable necesita el resto de esta lista.
- Confirma que está activo y no obsoleto: URL Inspection → Test live URL muestra un
403actual (esto confirma el acceso de Google-InspectionTool, no necesariamente la ruta exacta del Googlebot programado). - Reprodúcelo como Googlebot: solicita la URL con el user-agent de Googlebot (y desde fuera de tu red, idealmente desde más de una región), no desde tu navegador normal.
- Encuentra la regla: compara los registros de CDN, WAF, firewall o plugin de la solicitud bloqueada con una visita normal del navegador (ID de regla y desencadenante: user-agent, IP, desafío o límite de tasa), en vez de suponer la causa.
- Verifica el Googlebot real y la categoría de su cliente: DNS inverso y directo (el host termina en
googlebot.com,google.comogoogleusercontent.com) o comparación con la lista de rangos de IP de la categoría correcta, antes de permitir nada. - Limita una excepción para Googlebot verificado: las rutas y reglas concretas, por identidad o rango de IP, con registro y fecha de caducidad o revisión; no una autorización general y nunca confiando solo en el user-agent.
- Abre el contenido público: si el 403 es un requisito de inicio de sesión o cookie en contenido que debería ser público, elimínalo.
- Cambia cualquier límite 403 por
429(o503): nunca uses 401/403 para ralentizar el rastreo. - Confirma un
200: URL Inspection → Test live URL devuelve ahora200. - Valida: pulsa Validate Fix en la fila 403 y/o Request indexing para las URL prioritarias; después la reindexación ocurre automáticamente al volver a rastrear.
- Prepárate para el futuro: automatiza la comprobación de tus reglas de bloqueo contra las subredes publicadas por Google para que una actualización de rangos no vuelva a bloquearte sin avisar.
Modelos mentales
1. Pregunta «¿debería ser pública?» antes de «¿quién está mal configurado?» La redacción de la ayuda de Google presenta el 403 como credenciales enviadas y rechazadas, pero RFC 9110 lo define de forma más amplia: una solicitud que el servidor entendió y rechazó por cualquier motivo, con credenciales o sin ellas. Para una página que debe ser pública e indexable, un 403 a Googlebot casi siempre significa que una regla se activa para el visitante equivocado: trátalo como «encuentra la regla», no como «juzga la página». Para una página deliberadamente privada, el 403 puede estar cumpliendo su función; la solución es retirar la URL de la ruta de descubrimiento de Google, no abrir el firewall.
2. La misma regla, un visitante con otro aspecto: confirma qué diferencia importa. La página puede cargarse para ti y devolver 403 a Google porque tu navegador lleva cookies, un user-agent real y resuelve desafíos que la solicitud de Googlebot no puede. Pero no supongas qué atributo activó la regla: compara los registros y cambia un atributo cada vez. Depura haciendo la solicitud de Googlebot, no la tuya, y deja que los registros expliquen el motivo en lugar de adivinarlo.
3. Verifica la identidad y limita la excepción. Cualquiera puede falsificar el user-agent de Googlebot. El orden siempre es: confirma la identidad y la categoría del cliente (DNS inverso o la lista de rangos de IP correspondiente) → después permite el acceso. Incluso entonces, limita la excepción a la ruta y regla concretas, con registro y fecha de caducidad o revisión, en lugar de una lista general de permitidos para Google. Permitir por user-agent únicamente, o hacerlo con demasiada amplitud, abre un agujero para scrapers que fingen ser Google.
4. El 403 es un limitador equivocado.
Si tu objetivo es ralentizar Googlebot, 401/403 no sirven: desindexan. Los códigos de «reduce la velocidad» son 429 y 5xx/503. Elige el código que corresponda a tu intención: «vete para siempre» (desindexar) frente a «vuelve más tarde» (limitar la tasa).
5. 403 y 401 son primos cercanos, y la respuesta los distingue.
401 exige un desafío WWW-Authenticate, un muro real de autorización. 403 es un rechazo más amplio que puede darse con o sin credenciales; no deduzcas el mecanismo solo por la etiqueta y comprueba la respuesta real. Cuando sepas cuál estás viendo, comparten el resultado (no indexado) y a menudo la solución (permitir el Googlebot verificado o abrir el contenido): diagnostícalos con el mismo ciclo.
Ficha rápida del 403
Estados hermanos en Indexación de páginas
| Estado | Qué recibió Google | Qué suele significar |
|---|---|---|
| Blocked due to access forbidden (403) | HTTP 403 (rechazo, con o sin credenciales) | A menudo un firewall, CDN, WAF o regla de seguridad bloquea a Googlebot; también puede ser una página prohibida de forma intencionada o una comprobación de autenticación mal configurada |
| Blocked due to unauthorized request (401) | HTTP 401 (requiere desafío WWW-Authenticate) | Página detrás de un muro de inicio de sesión o autenticación HTTP |
| URL blocked due to other 4xx issue | Otro 4xx | Depúralo con URL Inspection |
Códigos de estado y rastreo: elige el correcto
| Objetivo | Código que se debe devolver | Efecto |
|---|---|---|
| Bloquear un bot dañino o no deseado | 403 | Página no indexada; se desindexa si ya lo estaba |
| Pedir a Googlebot que reduzca la velocidad | 429 (o 503) | Limitación temporal: la señal compatible de «reduce la velocidad» |
| La página ha desaparecido de verdad | 404 / 410 | Sale del índice con el tiempo |
| La página debe indexarse | 200 | Rastreable e indexable |
Qué le hace un 403 a una página que debería indexarse
- Contenido ignorado (Google no utiliza el contenido
4xx). - URL eliminada del índice si ya estaba indexada.
- La frecuencia de rastreo decae mientras persiste el 403.
Referencia rápida para verificar Googlebot
- DNS inverso de la IP → el host debe terminar en
googlebot.com,google.comogoogleusercontent.com. - DNS directo de ese host → debe resolver de nuevo a la misma IP.
- O compara la IP con los archivos JSON de rangos de IP de rastreadores publicados actualmente por Google para la categoría correcta del cliente: Googlebot común, rastreadores especiales y recuperadores activados por usuarios (como Google-InspectionTool) publican listas independientes.
Reproduce el 403 como Googlebot
No pruebes desde tu navegador normal: no activará la regla de bots. Solicita la URL con el user-agent de Googlebot para ver lo que ve Google.
macOS / Linux
# Fetch headers only, as Googlebot's user-agent — look at the status line
curl -s -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
-I https://www.example.com/page/
# A "HTTP/1.1 403 Forbidden" here reproduces what Googlebot is getting.Windows (PowerShell)
# -SkipHttpErrorCheck so PowerShell shows the 403 instead of throwing
$ua = "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
Invoke-WebRequest -Uri "https://www.example.com/page/" -Method Head `
-UserAgent $ua -SkipHttpErrorCheck | Select-Object StatusCode, StatusDescriptionSi eso devuelve 403, pero una solicitud normal del navegador devuelve 200, has confirmado un bloqueo específico para bots. Nota: un WAF sofisticado también puede basarse en la IP, así que para una prueba completa reproduce la solicitud desde fuera de tu propia red.
Verifica que un bot sea realmente Googlebot (antes de permitirlo)
Mucho tráfico falsifica el user-agent de Googlebot. Confirma la identidad mediante una comprobación DNS inversa y directa antes de permitir una IP en tu firewall.
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.1Windows
nslookup 66.249.66.1
nslookup crawl-66-249-66-1.googlebot.comSi la búsqueda inversa no termina en un dominio de Google, o la directa no coincide con la IP original, no es Googlebot: no lo permitas. También puedes comparar la IP con los rangos publicados por Google (googlebot.json). Ten en cuenta que googlebot.json solo cubre el Googlebot común: los rastreadores especiales y los recuperadores activados por usuarios (como Google-InspectionTool) publican archivos de rangos de IP independientes, así que debes comparar con la lista del cliente real que intentas verificar. Confirma primero la identidad y después limita la excepción a la ruta y regla concretas; nunca permitas por el user-agent únicamente ni abras una excepción general.
Diagnóstico de un 403: ¿bloqueo WAF, muro de inicio de sesión o mal uso de un límite de tasa?
La primera bifurcación comprueba la respuesta misma: un 403 sin cabecera WWW-Authenticate ni aviso de inicio de sesión apunta lejos del estado hermano 401 y hacia un rechazo de regla de seguridad o control de acceso. A partir de ahí, las ramas siguen el ciclo de diagnóstico y solución de la pestaña Advanced; trata cada resultado como una hipótesis que debes confirmar en tus registros, no como una certeza. Haz clic para recorrerlo.
Why is Googlebot getting a 403, and what fixes it?
Sigue el grupo de 403, no solo su existencia
La cifra que merece la pena vigilar es cuántas URL aparecen con el tiempo en la fila «Blocked due to access forbidden (403)» del informe de Indexación de páginas, no solo si la fila existe: una instantánea aislada no puede decirte si una solución funcionó o si se están acumulando nuevos 403.
Evolución del recuento del grupo 403
- Métrica: número de URL bajo «Blocked due to access forbidden (403)» en el informe de Indexación de páginas de GSC, seguido semana a semana.
- Qué te dice: si una solución de lista de permitidos o de regla de firewall funcionó y si aparecen nuevos 403. Después de permitir Googlebot verificado o abrir una ruta pública, este recuento debería acercarse a cero para las URL corregidas. Si se mantiene estable, solo es correcto cuando has decidido deliberadamente que esas URL nunca deben rastrearse; un recuento al alza suele indicar que una regla de WAF/CDN o una actualización de rangos de IP está capturando ahora a Googlebot.
- Cómo obtenerlo: informe de Indexación de páginas de GSC, filtrado por la fila 403; comprueba URL individuales con URL Inspection → Test live URL para confirmar que no sean una instantánea obsoleta.
- Referencia o rango realista: no existe un objetivo universal: depende de cuántas URL quieras indexar. La medida honesta es cero 403 entre las URL que quieres indexar y un recuento estable (no creciente) en el resto. Establece tu propia línea base antes de juzgar la dirección de la tendencia.
- Periodicidad: semanalmente justo después de una solución, hasta que el recuento se estabilice; después, mensualmente como comprobación de regresión, porque una CDN o una actualización de rangos de IP de Googlebot puede volver a introducir el bloqueo sin avisar.
Manual operativo: diagnosticar, corregir y validar
El flujo de trabajo del 403 es un ciclo corto y ordenado: no empieces por permitir el acceso antes de reproducir el bloqueo como Googlebot y confirmar la identidad de aquello a lo que estás a punto de dar paso.
1. Confirma que está activo y no obsoleto. Ejecuta URL Inspection → Test live URL en GSC para la URL afectada y confirma que Google recibe actualmente un 403, no un informe almacenado en caché.
2. Reprodúcelo como Googlebot, no como tú. Solicita la URL con el user-agent de Googlebot, idealmente desde fuera de tu red y desde más de una región: tu navegador normal envía cookies, un user-agent real y puede superar desafíos de JS o CAPTCHA que la solicitud de Googlebot normalmente no puede, por lo que quizá no active la misma regla. Compara las entradas resultantes de los registros una junto a otra en vez de suponer qué diferencia causó el bloqueo.
3. Encuentra la regla. Lee los registros de CDN, WAF o firewall para localizar la regla exacta que se activó con la solicitud de Googlebot: el ID de regla y el desencadenante (user-agent, IP, desafío o límite de tasa) te dicen qué debes cambiar.
4. Verifica el Googlebot real y su categoría antes de permitirlo. Confirma que las solicitudes que vas a permitir son realmente de Googlebot mediante DNS inverso y directo o la lista de rangos de IP que corresponda a la categoría de ese cliente (el Googlebot común, los rastreadores especiales y los recuperadores activados por usuarios publican listas distintas). De lo contrario, abrirás un agujero para suplantadores o comprobarás contra la lista equivocada.
5. Corrige según la causa. Regla de WAF/CDN → limita una excepción estrecha para el Googlebot verificado a la ruta y regla concretas, por identidad o rango de IP. Requisito de inicio de sesión o cookie en contenido público → elimínalo. Regla de limitación de tasa que devuelve 403 → cámbiala por 429 (o 503).
6. Valida. Confirma que URL Inspection → Test live URL devuelve ahora 200, después pulsa Validate Fix en la fila 403 y/o Request indexing para las URL prioritarias. La reindexación ocurre automáticamente cuando Google vuelve a rastrear un 200; si el recuento del grupo 403 no baja después de un par de semanas, vuelve al paso 2 y reproduce la solicitud en lugar de adivinar una causa nueva.
Prompts de IA listos para usar
Prompts para copiar y pegar que clasifican un 403 a partir de datos de diagnóstico sin procesar. 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 access forbidden (403)" status in Google
Search Console. Below is the raw output of a request made with Googlebot's
user-agent (curl -A "...Googlebot..." -I). Based on this output alone,
classify the most likely cause as one of: (1) CDN/WAF bot-management
challenging or blocking non-browser clients, (2) server firewall / mod_security
rule flagging the crawl pattern as abuse, (3) user-agent or referrer/hotlink
rule, (4) geo/IP blocking excluding Googlebot's IP ranges, (5) a login/cookie
requirement on content that should be public, (6) a rate-limit rule misusing
403 instead of 429. 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 o firewall
I'm investigating why Googlebot is getting a 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 challenge/CAPTCHA rule, or a rate-limit rule misusing 403, 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 allowlist a set of IPs as "Googlebot" in my WAF, because a page
I want indexed is currently returning 403 to the crawler. Here's the evidence
I have that these requests are genuinely Googlebot: [describe reverse-DNS or
IP-range check]. Point out anything I might be missing — e.g. whether I should
verify by both reverse and forward DNS, whether I should match Google's
published IP-range JSON instead, or whether allowlisting by user-agent alone
would leave a hole for spoofers. Ponte a prueba: «Blocked due to access forbidden (403)»
Cinco preguntas sobre qué significa un 403, en qué se diferencia de un 401 y cómo diagnosticarlo y corregirlo. Elige una respuesta para cada una y compruébalas después.
Herramientas para diagnosticar y corregir un 403
- HTTP Status Checker: pega la URL afectada (o un lote) para confirmar el código de estado 403, ver toda la cadena de respuesta y detectar cualquier redirección que ocurra antes del bloqueo.
- Googlebot Verifier: comprueba si una IP que afirma ser Googlebot es auténtica (rangos de IP publicados y confirmación mediante DNS inverso) antes de permitirla más allá de una regla de WAF o firewall.
- Google Search Console — URL Inspection → Test live URL: lo más parecido a ver la respuesta exacta que Googlebot recibe ahora mismo.
curl -A "...Googlebot...": la forma más rápida de solicitar una URL con el user-agent de Googlebot y leer la línea de estado sin procesar.- Registro de eventos del firewall de tu WAF o CDN (Cloudflare, Akamai, Sucuri, etc.): encuentra la regla específica que devuelve 403 a los rangos de IP de Googlebot.
Demuestra que la solución funciona de verdad
Una vez que hayas permitido Googlebot verificado, abierto el contenido público o cambiado una regla de limitación de tasa a 429, 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 con user-agent de Googlebot devuelve ahora 200
- Prueba que se debe ejecutar: solicita la URL afectada con el user-agent de Googlebot (o compruébala con HTTP Status Checker).
- Resultado esperado: la línea de estado dice
HTTP/1.1 200 OK. - Interpretación de un fallo: que siga apareciendo
403significa que la regla del firewall o WAF no se actualizó realmente, o que permitiste el rango de IP equivocado. Un401en lugar de403significa que cambiaste un bloqueo por un muro de autenticación; comprueba esa ruta por separado. - Ventana de seguimiento: inmediata: el servidor responde así en cuanto el cambio de regla está activo.
- Desencadenante de reversión: si abrir la ruta expone contenido que querías mantener restringido, vuelve a bloquearla y permite en su lugar el Googlebot verificado por IP o DNS inverso mediante una regla más estrecha.
Prueba 2: Google confirma que ya puede llegar a la página
- Prueba que se debe ejecutar: ejecuta URL Inspection → Test live URL en Google Search Console para la URL afectada.
- Resultado esperado: la prueba en vivo funciona y muestra el contenido de la página, sin informar de un error de acceso prohibido.
- Interpretación de un fallo: si Test live URL todavía informa de un 403 después de que la solicitud con user-agent de Googlebot funcione, sospecha de una regla limitada específicamente a los rangos de IP publicados por Google, no al user-agent; busca una segunda regla en los registros del firewall.
- Ventana de seguimiento: inmediata o de unos minutos después de la solución.
- Desencadenante de reversión: N/A: es una prueba de solo lectura. Si sigue fallando, vuelve a la rama de fallo de la Prueba 1 en lugar de revertir nada.
Prueba 3: el estado 403 desaparece del informe de Indexación de páginas
- Prueba que se debe ejecutar: usa Validate Fix en el problema «Blocked due to access forbidden (403)» del informe de Indexación de páginas y observa el recuento del grupo durante las semanas siguientes (consulta la pestaña Cómo medir).
- Resultado esperado: la URL sale del grupo 403 y, si ya estaba indexada, vuelve al índice con el tiempo, cuando Google vuelve a rastrear la página que ahora devuelve 200.
- Interpretación de un fallo: la reindexación es automática, pero no inmediata; no interpretes una validación lenta como un fallo nuevo. Si el recuento del grupo 403 no baja después de un par de semanas, repite la Prueba 1 para confirmar que la solución sigue activa: una caché de CDN o una actualización de rangos de IP de Googlebot puede volver a introducir el bloqueo sin avisar.
- Ventana de seguimiento: de días a unas semanas, seguido mediante el recuento del grupo 403.
- Desencadenante de reversión: revisa la regla solo si la Prueba 1 vuelve a fallar; no persigas el tiempo de procesamiento del informe de Indexación de páginas.
Recursos que merecen tu tiempo
Oficiales
- Informe de Indexación de páginas (Google): las entradas 403 y 401, literalmente.
- Cómo afectan los códigos de estado HTTP a la Búsqueda de Google: tratamiento de los
4xxy regla de no usar 401/403 para limitar la tasa. - Verificación de Googlebot (Google): DNS inverso y directo y rangos de IP publicados.
- Don’t 404 my yum (Google, 2023): no uses 403/404 para limitar Googlebot.
Artículos relacionados míos
- Guía para principiantes de SEO técnico: dónde encajan en el panorama general los problemas de acceso de rastreo como este.
- Robots.txt y SEO: todo lo que necesitas saber: la otra forma habitual en que las páginas se bloquean involuntariamente para el rastreo.
De otras fuentes
- r/TechSEO: comunidad para depurar rastreo e indexación, incluidos los hilos sobre Googlebot bloqueado por una CDN.
- Google desaconseja usar los estados 403 o 404 para limitar el rastreo de Googlebot (Search Engine Land): cobertura de la guía «Don’t 404 my yum» de Gary Illyes y de qué usar en su lugar (429/503).
- Google: no uses respuestas de error 403/400 para limitar el rastreo de Googlebot (Search Engine Journal): resumen de SEJ de la misma publicación de Illyes, con contexto adicional.
- La causa más común de bloquear Googlebot son los firewalls y las CDN (Search Engine Roundtable): Google Search Relations explica que la gran mayoría de bloqueos de Googlebot son reglas involuntarias de CDN o firewall.
- Rastreadores que se hacen pasar por Googlebot (johnmu.com): John Mueller explica por qué debes verificar Googlebot mediante DNS inverso antes de permitirlo, en lugar de confiar solo en el user-agent.
- How to fix «Blocked due to access forbidden (403)» (Onely): guía práctica sobre WAF y CDN y sobre el ciclo de diagnóstico → solución.
Registro de cambios
Actualizado el 9 ago 2026.
Resumen editorial y detalles registrados del cambio.Detalles del cambio
-
Los detalles del cambio están disponibles actualmente en inglés.
La comparación completa no está disponible: no se archivó una instantánea anterior para esta revisión.
Actualizado el 17 jul 2026.
Resumen editorial y detalles registrados del cambio.Detalles del cambio
-
Los detalles del cambio están disponibles actualmente en inglés.
-
Los detalles del cambio están disponibles actualmente en inglés.
-
Los detalles del cambio están disponibles actualmente en inglés.
-
Los detalles del cambio están disponibles actualmente en inglés.
La comparación completa no está disponible: no se archivó una instantánea anterior para esta revisión.