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.

Publicado por primera vez: 23 jun 2026 · Última actualización: 9 ago 2026 · Avanzado
Idiomas
2 señales de evidencia en esta página

«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 — 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.

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

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:

  1. Pública y destinada a indexarse. El 403 es involuntario: recorre el ciclo de diagnóstico → solución → validación de abajo.
  2. 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 200 normal y utiliza una directiva noindex (o una redirección o eliminación adecuada).
  3. 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.
  4. 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.
Evidence for this claim A robots.txt disallow is a separate crawl gate and Page indexing reason; it does not itself generate the HTTP 403 response required for the Blocked due to access forbidden (403) reason. Scope: verified Search Console properties Confidence: high · Verified: Page indexing report

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.
Evidence for this claim A 401 response means valid authentication credentials are missing and must include a WWW-Authenticate challenge; a 403 is a refusal that can occur with or without credentials. Scope: 401 and 403 responses Confidence: high · Verified: RFC 9110: HTTP Semantics

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:

  1. El contenido se ignora. Google no utiliza el contenido de las URL 4xx, así que nada de la página puede indexarse.
  2. 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».
  3. La frecuencia de rastreo decae. Con el tiempo, Google rastrea las URL 4xx cada 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

  1. 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.
  2. 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.)
  3. 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ó.
  4. 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:

  1. URL Inspection → Test live URL para confirmar que la respuesta en vivo es ahora 200.
  2. 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.
  3. 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.
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

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.

Add an expert note

Pin an expert quote

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