Se ha bloqueado debido a que el acceso no está permitido (403): ¿intencional o accidental?
El código 403 no se presta a confusión: acceso denegado, el servidor cerró la puerta. Eso es precisamente lo que vuelve engañoso el estado «Se ha bloqueado debido a que el acceso no está permitido (403)» del informe «Indexación de páginas» de la Google Search Console. El reflejo natural, abrir la URL en un navegador, muestra una página perfectamente normal. Parece una falsa alarma.
Pero esa prueba no demuestra nada. El 403 no apunta al internauta, apunta a Googlebot: el servidor muestra la página al visitante humano y se la niega al robot. Ese desfase, ningún navegador lo enseña.
De ahí la verdadera pregunta: ¿este 403 es deliberado o sufrido? ¿Quién le cierra la puerta a Googlebot? ¿Y cómo saber qué recibe el robot en realidad, cuando la pantalla, en cambio, lo muestra todo sin contratiempos? La respuesta no se lee en la pantalla, sino en el código servido a Googlebot.
«Se ha bloqueado debido a que el acceso no está permitido (403)»: qué señala Google
Este estado significa que Googlebot solicitó la URL y tu servidor respondió con un código HTTP 403 (acceso prohibido). Google concluye que el contenido no existe y retira la URL del índice si ya la había indexado. No es una directiva que tú das, como un robots.txt: es tu servidor el que rechaza activamente el acceso a Googlebot.
Esa es la diferencia de fondo con un bloqueo por robots.txt. El robots.txt es una consigna que tú escribes y que Google respeta de buen grado: «no rastrees estas URLs». El 403, en cambio, es una respuesta del servidor en el momento en que Googlebot llama a la puerta. Google no decide nada: sufre el rechazo, saca la conclusión lógica («contenido inalcanzable, por lo tanto inexistente») y desindexa.
La documentación de Google añade un matiz que cambia la lectura del problema: un 403 devuelto a Googlebot es, a sus ojos, casi siempre un error de configuración. El código 403 está pensado para decir «proporcionaste credenciales, pero el acceso te está denegado». Ahora bien, Googlebot nunca proporciona credenciales. La propia formulación de Google es tajante: «el robot de Google nunca proporciona credenciales, por lo que tu servidor devuelve este error de forma incorrecta». Dicho de otro modo, incluso un 403 que crees «intencional» es, desde el punto de vista de Google, un mal uso del código: trata todos los códigos 4xx (salvo el 429) de la misma manera, considerando que la página no existe.
403 intencional o accidental: el triaje primero
Antes de cualquier corrección, una sola pregunta lo decide todo: ¿esta URL debe aparecer en Google? Si la respuesta es sí, el 403 es un accidente que reparar con urgencia. Si es no, el 403 hace su trabajo (aunque no sea la herramienta más limpia para ello). El diagnóstico técnico viene después de ese triaje de intención, nunca antes.
Caso A: el 403 es intencional. La URL es una página de administración, un back-office, un entorno de preproducción, un espacio reservado a miembros conectados. La cerraste a todo lo que no esté autenticado, Googlebot incluido. Verla listada en «Se ha bloqueado debido a que el acceso no está permitido (403)» es coherente con tu intención: esta página no tiene ninguna razón de estar en Google. No hay urgencia, a lo sumo una limpieza que planificar (más abajo, ya que el 403 no es la herramienta ideal para ello).
Caso B: el 403 es accidental. La URL es una página pública, pensada para posicionarse y atraer tráfico: una ficha de producto, un artículo, una página de categoría. Y sin embargo el servidor le opone un 403 a Googlebot. Esto es urgente: mientras el rechazo se mantenga, la página no puede indexarse, y si lo estaba, sale del índice. Estás perdiendo tráfico en una página que querías ver en Google.
Todo el trabajo consiste en separar A de B. Una página de admin en 403 es sano. Una ficha de producto en 403 es una fuga de tráfico. Y el caso B es tanto más insidioso cuanto que suele ser invisible desde tu propio equipo.
El caso traicionero: 200 para ti, 403 para Googlebot
Es el escenario más tramposo del caso B: la página se abre perfectamente en tu navegador (código 200), pero Googlebot recibe un 403. Un cortafuegos de aplicaciones web (WAF), un modo de protección antibots o un servicio anti-DDoS sirve el contenido a un visitante humano y le opone un rechazo a lo que toma por un robot indeseable. Tu prueba de navegador nunca lo verá.
La razón es simple: estos dispositivos deciden permitir o bloquear en función de quién llama a la puerta. Un humano con un navegador clásico, una dirección IP residencial y un comportamiento «normal» pasa. Una petición identificada como un robot puede ser filtrada, y ahí está el drama, porque Googlebot es un robot. El sistema antibots no siempre distingue a Googlebot de un scraper malicioso, y lo mete en el mismo saco. Tú ves 200; Googlebot recibe 403.
Por eso abrir la URL en tu navegador no demuestra nada: estás probando el acceso humano, no el acceso Googlebot. El único veredicto que cuenta es el código HTTP que recibe realmente el robot de Google. Este mecanismo es primo de otra trampa en la que la página «se abre» sin satisfacer a Google: ver Soft 404, donde el servidor devuelve un 200 en una página vacía o en error.
💡 ¿Sospechas un 403 servido a Googlebot pero invisible en tu equipo? IndexProbe inspecciona tu lista de URLs a través de la API de la Search Console y te da, por página, el código HTTP que Google recibió realmente. Probar IndexProbe en acceso anticipado →
Las causas, del lado del servidor
Cuando el 403 es accidental (caso B), la causa se encuentra casi siempre en una capa de seguridad o de configuración que toma a Googlebot por una amenaza. Estos son los mecanismos más frecuentes, ordenados por origen.
- WAF y antibots, falsos positivos. Cloudflare (Bot Fight Mode, reglas WAF), Sucuri, Imperva, AWS WAF y similares bloquean las peticiones juzgadas sospechosas. Una regla demasiado agresiva atrapa a Googlebot junto con los scrapers y le devuelve un 403.
- Limitación de tasa (rate limiting). El servidor pone un tope al número de peticiones por IP en un intervalo dado. Si Googlebot rastrea activamente, puede cruzar el umbral y encontrarse con un 403. Google desaconseja explícitamente usar el 403 para frenar el rastreo: este código no tiene ningún efecto sobre la frecuencia de paso, al contrario que el 429.
- Bloqueo por IP o por geolocalización. Una regla que prohíbe ciertos rangos de direcciones, o todo el tráfico fuera de un país dado, puede cortar el acceso a las IP de Googlebot.
- Filtrado por user-agent. Una configuración que bloquea las peticiones según su firma puede apuntar, por error o por exceso de celo, al agente
Googlebot. - Permisos de archivos y
.htaccess. Un mal ajuste de derechos sobre una carpeta, o una directivaDeny fromen un.htaccess, devuelve un 403 sobre todo lo que cubre. - Alojamiento compartido. En un alojamiento compartido, protecciones del propio proveedor (límites de recursos, antibots integrados) pueden bloquear a Googlebot sin que tengas ningún control sobre ellas.
- Plugins y módulos anti-rastreo. Algunas extensiones de seguridad (sobre todo en WordPress) añaden sus propias reglas de bloqueo, a veces activas por defecto.
El hilo conductor: una capa de tu infraestructura decide que Googlebot no tiene derecho a entrar. Queda por saber cuál, y sobre qué URLs golpea.
403 vs 401 vs 404 vs 5xx vs robots.txt: la tabla
Cinco formas de «bloquear» una página se confunden sin cesar, cuando no le envían en absoluto la misma señal a Google. La distinción reside en quién devuelve qué, y en lo que Google concluye de ello. Esta es la tabla de lectura.
| Código / estado | Quién devuelve qué | Qué concluye Google | ¿Indexable? | Cuándo es legítimo |
|---|---|---|---|---|
| 403 (acceso prohibido) | El servidor rechaza el acceso a Googlebot | Contenido inalcanzable → inexistente, retirada del índice | No | Nunca ideal frente a Googlebot (Google lo ve como un error); reservarlo a un rechazo real del lado del servidor |
| 401 (autenticación requerida) | El servidor exige credenciales | Contenido protegido → tratado como inexistente, retirada del índice | No | Contenido real tras autenticación (miembros, intranet) |
| 404 (no encontrada) | El servidor indica que la página no existe | Página inexistente, retirada del índice | No | Página realmente eliminada, sin reemplazo |
| 5xx (error de servidor) | El servidor falla o no está disponible | Problema temporal, Google reintenta antes de desindexar | No (mientras dure el error) | Nunca buscado: a corregir (ver Error del servidor (5xx)) |
| Bloqueada por robots.txt | Tú prohíbes el rastreo mediante una directiva | Consigna respetada: página no rastreada | Posible sin rastreo (indexada vía enlaces externos) | Impedir el rastreo de páginas sin interés (admin, filtros) |
La diferencia decisiva: el 403 y el 401 son rechazos activos del servidor, que Google trata como una señal de «esta página no existe». El robots.txt, en cambio, es una consigna que Google respeta sin concluir por ello que la página haya desaparecido. Confundir ambos lleva a la corrección equivocada, y, en el caso del 5xx, a entrar en pánico donde Google todavía espera con paciencia.
Identificar los 403 a escala
La herramienta de Inspección de URL de la Search Console da el código HTTP visto por Googlebot, pero una URL cada vez: inspeccionas, lees el veredicto, pasas a la siguiente. Para detectar, sobre cientos de URLs, cuáles le devuelven un 403 a Google y cuáles caen en el caso B, la inspección manual no aguanta la distancia.
Ese es el muro que IndexProbe derriba: la versión en masa de la herramienta de inspección de URL de Google. Consulta la API oficial de la Search Console para inspeccionar, en un solo análisis, la lista de URLs que le proporcionas (importación CSV, sitemap, copiar y pegar) o la que construyes desde tu propia Search Console. Para cada página devuelve el «Estado del rastreo de Google»: el código HTTP que Googlebot recibió realmente, 403 incluido. IndexProbe no rastrea tu sitio para descubrir URLs: inspecciona las que le das, y solo esas.
El interés decisivo: cruzar el código visto por Googlebot con el código que ve tu navegador. Un 403 del lado de Googlebot sobre una URL que devuelve 200 en tu navegador es la firma exacta del 403 dirigido, el que un WAF le opone al robot mientras sirve la página a los humanos, y que ninguna prueba de navegador revela.
Lo que obtienes del análisis depende de la lista que aportes.
- Una selección de páginas estratégicas (tus páginas clave, tu sitemap de páginas a indexar). Cualquier página importante que aparezca en 403 es un caso B inmediato: una página que querías ver en Google, cerrada a Googlebot por accidente. La detectas sin presumir nada del resto del sitio.
- Una exportación completa de tus URLs (sitemap entero, exportación de rastreo). El desglose por tipo de página muestra dónde se concentran los 403: un pico en un segmento público (tus productos, tu blog) delata un bloqueo accidental, mientras que un 403 masivo en la admin o la preproducción es coherente.
Corregir un 403 accidental
Para una página del caso B, el objetivo es reabrirle el acceso a Googlebot sin bajar la guardia sobre la seguridad del sitio. El procedimiento:
- Lee los registros de tu WAF o CDN. Cloudflare, Sucuri, Imperva y la mayoría de los cortafuegos registran las peticiones bloqueadas. Busca los rechazos opuestos a Googlebot e identifica la regla responsable.
- Crea una excepción dirigida a Googlebot. En lugar de desactivar toda la protección, añade una regla que deje pasar a Googlebot. Es la corrección quirúrgica: le reabres el acceso al robot de Google sin abrirle la puerta a todo el mundo.
- Verifica la identidad real de Googlebot, este es el punto crítico. Nunca autorices basándote solo en el user-agent: cualquiera puede declararse «Googlebot». Un filtrado ingenuo por nombre de agente abre un agujero de seguridad enorme. El método oficial de Google es la verificación por DNS inverso (el
hostde la IP debe resolver haciagooglebot.com,google.comogoogleusercontent.com, y un DNS directo debe reconducir a la misma IP) o el cruce con los rangos de IP oficiales que Google publica en JSON. Muchos WAF integran una verificación de «bots verificados» ya conectada a esos rangos, prefiérela a cualquier lista blanca casera. - Desbloquea también el CSS y el JavaScript. Una página puede devolver 200, pero sus recursos (hojas de estilo, scripts) estar en 403. Google solo renderiza entonces la página parcialmente. Comprueba que los archivos necesarios para el renderizado sean, también ellos, accesibles para Googlebot.
- Solicita la reindexación. Una vez restablecido el acceso, usa la Inspección de URL para confirmar el paso a 200, y luego solicita la indexación para señalarle a Google que la página vuelve a ser accesible.
Gestionar un 403 intencional con limpieza
Para una página del caso A, el reflejo «no toques nada» tiene un límite: un 403 servido a Googlebot sigue siendo, a ojos de Google, un uso a contrapelo del código. La gestión limpia consiste en confirmar la intención, luego cortar las señales que conducen a Googlebot hacia la página, y por último elegir la herramienta adecuada según tu objetivo real.
- Confirma la intención. Esta página efectivamente no tiene ninguna vocación de aparecer en Google (admin, preproducción, espacio de miembros). Si queda la menor duda, trátala como un caso B.
- Sácala del sitemap. Una URL en 403 listada en tu sitemap envía una señal contradictoria: le pides a Google que indexe una página que tu servidor le niega.
- Corta el enlazado interno. Mientras enlaces internos apunten a la URL, Googlebot seguirá solicitándola y chocando con el 403. Retira esos enlaces.
- Elige la herramienta adecuada según el fin:
- Contenido real autenticado (intranet, espacio de miembros) → un 401 es más honesto que un 403, pero el resultado del lado del índice es idéntico: Google trata la página como inexistente.
- Impedir el rastreo de una zona sin interés → el robots.txt es la herramienta prevista para ello. Cuidado: impide el rastreo, no necesariamente la indexación si la URL es conocida en otro sitio, ver Indexada aunque bloqueada por robots.txt.
- Permitir el rastreo pero excluir del índice → la etiqueta
noindex. Google debe poder rastrear la página para ver la etiqueta: por lo tanto no debe estar ni en 403, ni bloqueada en elrobots.txt.
Comprobar que la corrección surtió efecto
Una vez levantado el 403, confirma que Google tomó nota. Vuelve a inspeccionar las URLs tratadas a través de la Inspección de URL: la «Prueba en directo» debe mostrar un 200 donde había un 403. Luego sigue la evolución en el tiempo, porque la reindexación no es instantánea: Google debe volver a rastrear la página, comprobar que vuelve a ser accesible, y reintegrarla al índice. Ese plazo se cuenta normalmente en días.
Un único análisis no demuestra nada: es la comparación entre un estado anterior y un estado posterior la que muestra el movimiento. Las páginas que has desbloqueado deben abandonar el estado «Se ha bloqueado debido a que el acceso no está permitido (403)», volver a 200, ser rastreadas, y luego pasar a indexadas.
La vista COMPARACIÓN de IndexProbe está concebida para este seguimiento: pone dos análisis frente a frente y cuantifica, por URL, el paso del 403 a la indexación. Es la confirmación de que tu excepción WAF realmente le reabrió el acceso a Googlebot, y no solo a tu navegador.
Preguntas frecuentes
¿Qué significa «Se ha bloqueado debido a que el acceso no está permitido (403)» en la Search Console? Significa que Googlebot solicitó la URL y tu servidor respondió con un código HTTP 403 (acceso prohibido). Google concluye que el contenido es inalcanzable, lo trata como inexistente y retira la URL del índice si la había indexado. No es una consigna que tú das, es un rechazo activo del servidor.
¿Por qué un 403 para Googlebot si la página se abre en mi equipo? Porque un cortafuegos de aplicaciones web (WAF), un modo antibots o un servicio anti-DDoS sirve la página a los visitantes humanos mientras le opone un 403 a lo que toma por un robot indeseable, Googlebot incluido. Tu navegador prueba el acceso humano; el único veredicto que cuenta es el código HTTP que recibe realmente Googlebot.
¿Cómo corregir un 403 que bloquea a Googlebot? Lee los registros de tu WAF o CDN para identificar la regla culpable, crea una excepción dirigida que deje pasar a Googlebot, y verifica su identidad real por DNS inverso o rangos de IP oficiales (nunca solo por el user-agent). Desbloquea también el CSS y el JavaScript, y luego solicita la reindexación a través de la Inspección de URL.
¿Un 403 impide la indexación? Sí. Google no recupera el contenido de las URLs que devuelven un 403 (como todos los códigos 4xx salvo el 429): considera que la página no existe. Una página nunca indexada no lo será mientras el 403 se mantenga; una página ya indexada sale del índice.
¿Qué diferencia hay entre 403, 401 y 404? El 403 es un rechazo de acceso, el 401 una exigencia de autenticación, el 404 una página no encontrada. Desde el punto de vista del índice, Google los trata a los tres como «contenido inexistente» y retira la URL. La diferencia está en la señal enviada al servidor, no en el resultado del lado de la indexación.
¿Puede Cloudflare bloquear a Googlebot? Sí. El Bot Fight Mode y ciertas reglas WAF de Cloudflare pueden devolverle un 403 a Googlebot si lo clasifican como bot indeseable. La solución es activar la verificación de «bots verificados» de Cloudflare (que se apoya en los rangos de IP oficiales de Google) o crear una regla de excepción dirigida a un Googlebot debidamente verificado.
Deja de basar tu diagnóstico en lo que muestra tu navegador. IndexProbe se conecta a la API oficial de la Search Console e inspecciona tu lista de URLs en un solo análisis: el código HTTP que Googlebot recibió realmente, el estado de indexación y la fecha del último paso del robot, uno al lado del otro. Detectas los 403 servidos a Google pero invisibles en tu equipo, separas el 403 intencional del bloqueo accidental, y compruebas de un análisis al siguiente, gracias a la vista COMPARACIÓN, que tus páginas vuelven de 403 a indexadas.