403 Forbidden: qué significa y cómo corregirlo
Qué es un error HTTP 403 Forbidden, cómo lo trata Google (bloqueo similar a noindex), cuáles son sus causas habituales (controles de acceso, bloqueo de bots y permisos mal configurados) y cómo corregirlo para el SEO.
Idiomas
1 señal de evidencia en esta página
- Herramienta activa relacionadaHTTP Status & Redirect Checker
Una 403 Forbidden significa que el servidor entendió la solicitud, pero la rechazó: el acceso se denegó y el rechazo no tiene por qué estar relacionado con las credenciales (el servidor incluso puede enviar una 404 para ocultar que existe un recurso prohibido). No es una 404 («no hay nada aquí») ni una 401 («autentícate primero»); una 403 es un «no puedes tener esto» activo. Para el SEO, una 403 persistente en una página que quieres hacer pública la mantiene fuera del índice de Google: el resultado se parece a noindex, pero el mecanismo es diferente, porque Google no puede leer contenido de una respuesta 4xx. Como Googlebot nunca envía credenciales, una 403 servida a Googlebot merece investigación en lugar de asumirse intencionada: las causas habituales incluyen un filtro de bots de CDN/WAF, un bloqueo de IP o user-agent del servidor, un plugin de seguridad o un error de .htaccess/permisos, aunque no hay datos fiables sobre cuál es más frecuente. No uses nunca 403 para limitar el rastreo (para una ventana breve están 429/503). Y comprueba primero la intención: algunas 403 (staging, administración y contenido protegido) son correctas y no necesitan corrección. Hay un giro importante: una 403 en el propio robots.txt se trata de forma permisiva, mientras que una 403 en una página es un bloqueo estricto.
TL;DR — Una 403 Forbidden significa que el servidor entendió la solicitud, pero la rechaza: quien la hizo no tiene permiso. Se diferencia de una 404 («no hay nada aquí») y de una 401 («inicia sesión primero»). Para el SEO, una página que sigue devolviendo 403 a Googlebot no se indexará y, si ya estaba indexada, saldrá del índice; por tanto, si quieres que se encuentre, una 403 es un problema que debes corregir.
Qué significa realmente una 403
Si eres un visitante que acaba de recibir una 403 en un sitio que no administras: es una regla del servidor, no algo de tu navegador. Prueba otra red o dispositivo, comprueba que no estás usando una VPN que el sitio bloquee y borra las cookies; pero si persiste, la corrección corresponde al propietario del sitio, y el resto de este artículo está escrito para él.
Cuando tú (o un bot de un motor de búsqueda) pides una página, el servidor devuelve un código de estado. 200 significa «aquí está». Una 403 Forbidden significa «entendí lo que pedías y me niego a entregártelo». El rechazo no tiene por qué deberse a las credenciales: el servidor puede rechazar por otros motivos y hasta puede enviar una 404 si quiere ocultar que existe un recurso prohibido. Evidence for this claim A 403 response means the server understood the request but refuses to fulfill it, and authenticating does not necessarily make a difference. Scope: RFC 9110 defines the protocol semantics; it does not identify the application, firewall, or policy responsible for a specific response. Confidence: high · Verified: IETF: RFC 9110 §15.5.4 — 403 Forbidden
La forma más sencilla de distinguir los códigos 4xx:
- 404 Not Found — «No hay nada aquí». La página no existe.
- 403 Forbidden — «Hay algo aquí, pero no puedes tenerlo». Un bloqueo activo.
- 401 Unauthorized — «Primero tienes que iniciar sesión o autenticarte». (Una 403 es más contundente: ni siquiera iniciar sesión ayudaría.)
Así que una 403 no significa que el servidor esté roto. Significa que el servidor funciona exactamente como se le indicó; la cuestión es si se le indicó lo correcto.
Por qué importa para el SEO
Googlebot tiene que poder obtener una página para indexarla. Si pide tu página y recibe una 403, Google no puede leer absolutamente ningún contenido de esa respuesta: el rechazo ocurre antes de que llegue a ese punto. Google no indexará una página que devuelva 403, y una página que ya estaba indexada acabará saliendo de los resultados si sigue devolviéndola. El resultado final se parece mucho a añadir un noindex: la página desaparece de Google, pero el mecanismo es diferente: una etiqueta noindex debe obtenerse y leerse para funcionar, mientras que una 403 impide que Google lea nada desde el principio. Evidence for this claim Google does not index 4xx URLs and removes already-indexed 4xx URLs over time. Scope: Google's crawler documentation supports the indexing outcome for persistent 403 responses, not the article's analogy to noindex. Confidence: high · Verified: Google: How HTTP status codes affect Google's crawlers
Aquí está el matiz que hace que merezca la pena entender las 403: Googlebot nunca inicia sesión. No envía contraseñas ni credenciales. Así que una 403 —que a menudo significa «no se aceptaron tus credenciales»— no puede significar eso, concretamente, para Googlebot. Pero eso no indica automáticamente un error: el bloqueo puede ser intencionado (un sitio de staging, una zona de administración o contenido protegido que nunca quisiste rastrear). Lo que sí significa es que una 403 en una página que sí quieres hacer pública merece investigación: alguna regla de seguridad, firewall o plugin pudo decidir que Googlebot parecía sospechoso. La orientación del propio Google tiene el mismo alcance: si quieres indexar la página, permite que Googlebot pase sin exigir autenticación.
Qué suele causarla
No tengo datos sólidos sobre cuál es la causa más habitual: trátalo como una lista de comprobación, no como una clasificación:
- Una CDN o un firewall (WAF) que bloquea al bot: Cloudflare Bot Fight Mode es un infractor frecuente y puede atrapar a Googlebot junto con los bots maliciosos.
- Una regla del servidor o del hosting que bloquea determinadas direcciones IP o user-agents.
- Un archivo
robots.txto.htaccessmal configurado. - Un plugin de seguridad (como Wordfence en WordPress) demasiado agresivo.
- Una barrera de inicio de sesión: todo lo que está detrás de autenticación devuelve 403 a un bot por diseño, y este caso suele ser intencionado, no un error.
- Errores de permisos de archivos en el servidor.
Ruta de corrección rápida
- En Google Search Console, abre el informe Page Indexing y busca “Blocked due to access forbidden (403).” (traducción) «Bloqueado por acceso prohibido (403)».
- Pasa la URL por la herramienta URL Inspection y pulsa Test Live URL para ver qué recibe Googlebot ahora mismo.
- Si usas Cloudflare u otra CDN/firewall, comprueba sus registros de seguridad para ver si Googlebot está bloqueado y permite el paso de bots de búsqueda verificados.
- Cuando hayas corregido la regla, usa Validate Fix en Search Console.
Y hay algo que no debes hacer: no uses nunca una 403 para intentar ralentizar Googlebot. No funciona y puede desindexar tus páginas. Si un bot está golpeando tu servidor, para eso existen 429 y 503.
¿Quieres la versión más profunda: el diagnóstico de Cloudflare/WAF, el problema particular de 403 en robots.txt y la forma correcta de permitir bots? Cambia a la pestaña Avanzado.
TL;DR — Una 403 significa que el servidor entendió la solicitud y la rechazó por motivos de acceso, lo que la distingue de 404 (desaparecido) y 401 (autenticarse). Para la indexación, el resultado se parece a un
noindex: Google no indexará una URL 403 y elimina una que ya estaba indexada, aunque el mecanismo (un bloqueo del servidor/CDN/WAF) no se parece en nada a una etiqueta meta. Como Googlebot nunca envía credenciales, una 403 a Googlebot casi siempre es una configuración incorrecta, normalmente un filtro de bots de CDN/WAF (Cloudflare Bot Fight Mode suele encabezar la lista), bloqueos de IP/UA del servidor, plugins de seguridad o.htaccess/permisos. Una 403 no tiene efecto sobre la velocidad de rastreo: nunca la uses para limitarla (para eso están 429/503). Y el caso contrario importa: una 403 en el propio robots.txt se trata de forma permisiva, mientras que una 403 en una página es un bloqueo estricto.
403 frente a 401 y 404: primero construye el modelo mental correcto
Estos tres códigos se confunden constantemente y la distinción dirige todo el diagnóstico. La definición base procede de la propia especificación HTTP, RFC 9110 §15.5.4: el servidor entendió la solicitud y se niega a cumplirla. En esa misma sección hay un par de matices más importantes de lo que suele reconocerse:
- El rechazo no tiene por qué deberse a las credenciales. RFC 9110 permite una 403 por motivos no relacionados con la autenticación: no demuestra universalmente que quien solicita sea «conocido» ni que haya intervenido ninguna credencial. No leas toda 403 como una historia de autenticación.
- Una 403 no tiene que admitir que existe el recurso. La especificación permite expresamente que un servidor de origen que quiera ocultar si existe un recurso prohibido responda con 404. Por tanto, lo contrario también es cierto: una 404 no siempre significa «aquí nunca hubo nada»; a veces significa «hay algo aquí que no quiero que conozcas».
- 401 frente a 403 no es simplemente «más débil frente a más fuerte». Una 401 es específicamente un desafío de autenticación: la especificación exige que incluya una cabecera
WWW-Authenticateque indique al cliente cómo autenticarse. Una 403 no tiene ese requisito; es un rechazo más amplio que no promete que volver a autenticarse (con las mismas credenciales o con otras) cambie nada. La versión clara de MDN: una 403 es «similar to 401, except that … authenticating or re-authenticating makes no difference. The request failure is tied to application logic, such as insufficient permissions.» (traducción) «similar a 401, salvo que… autenticarse o volver a autenticarse no cambia nada. El fallo de la solicitud está ligado a la lógica de la aplicación, como permisos insuficientes». Evidence for this claim A 403 response means the server understood the request but refuses to fulfill it, and authenticating does not necessarily make a difference. Scope: RFC 9110 defines the protocol semantics; it does not identify the application, firewall, or policy responsible for a specific response. Confidence: high · Verified: IETF: RFC 9110 §15.5.4 — 403 Forbidden - 404 Not Found, por contraste: el caso habitual es «no hay nada aquí», aunque debes recordar el punto anterior sobre ocultar recursos.
Esa diferencia es una de las razones por las que una 403 a Googlebot merece revisarse en lugar de aceptarse como rutina. Una 401 a un bot en una página solo para miembros puede estar funcionando: la zona exige iniciar sesión. Una 403 a un bot en una página que debería ser pública significa que alguna regla consideró que quien solicitaba no era bienvenido; aun así, como veremos, conviene confirmar que esa página realmente debía ser pública antes de llamarlo un error.
Cómo trata Google una 403 (el resultado se parece a noindex, el mecanismo no)
Google agrupa las 403 con el resto de la familia 4xx. Según la documentación de Search Central: «Google doesn’t index URLs that return a 4xx status code, and URLs that are already indexed and return a 4xx status code are removed from the index.» (traducción) «Google no indexa las URL que devuelven un código de estado 4xx, y las URL que ya están indexadas y devuelven un código de estado 4xx se eliminan del índice». Y: «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». Google también señala que la frecuencia de rastreo de una URL conocida disminuye gradualmente cuanto más tiempo sigue devolviendo 4xx; es un efecto por URL, independiente de la velocidad de rastreo de todo tu sitio (más adelante volveremos sobre esa diferencia). Evidence for this claim Google does not index 4xx URLs and removes already-indexed 4xx URLs over time. Scope: Google's crawler documentation supports the indexing outcome for persistent 403 responses, not the article's analogy to noindex. Confidence: high · Verified: Google: How HTTP status codes affect Google's crawlers
Así que el resultado se parece a un noindex: la página no entrará en el índice y, si ya estaba allí, saldrá con el tiempo. Pero el mecanismo es realmente distinto, no una diferencia cosmética: una etiqueta noindex tiene que obtenerse y analizarse desde el HTML de la página para surtir efecto, mientras que una 403 impide que Google lea cualquier contenido; no hay ninguna página que Google pueda procesar. Son dos caminos diferentes que convergen en el mismo resultado de no aparecer en Search. Por eso, en mi guía de códigos de estado HTTP, describo la 403 simplemente como «the client is known but doesn’t have access rights» (traducción) «el cliente es conocido, pero no tiene derechos de acceso», y señalo que las 4xxs hacen que las páginas salgan del índice; aunque «conocido» es el resumen del informe de Google, no una afirmación de que toda 403 implique un solicitante con credenciales.
Por qué conviene investigar una 403 a Googlebot (no siempre es un error)
Esta sección se apoya en el documento de ayuda de Google sobre Page Indexing: «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 indica que el agente de usuario presentó credenciales, pero el acceso fue denegado. Googlebot no presenta credenciales, por lo que en este caso el servidor está respondiendo de forma incorrecta; la página no se indexará». Léelo en contexto: es una orientación específica del informe sobre una página que Search Console supone que quieres indexar, no una afirmación universal de que toda 403 a Googlebot sea un error. Googlebot no se autentica, así que una 403 planteada estrictamente como «tus credenciales no son suficientes» no encaja del todo con él; pero muchas 403 no tienen que ver con las credenciales y un servidor puede decidir legítimamente que Googlebot (o cualquier otra persona) no obtenga un recurso, sin más.
Así que, antes de perseguir una corrección, pregunta: ¿es esta una página que realmente quieres hacer pública e indexar? Si es staging, una zona de administración, un muro de pago o cualquier contenido protegido, una 403 a Googlebot es correcta y no hay nada que arreglar (más información en «Cuándo está bien una 403», abajo). Si sí debe ser pública, lo más probable es que estés viendo una regla que se activó contra el solicitante equivocado: un WAF que marcó el rastreador como bot que debía bloquear, un bloqueo de rango de IP que incluyó los rangos de Google o la paranoia predeterminada de un plugin de seguridad. Pero no tengo datos fiables sobre la frecuencia con que cada causa es realmente la responsable, así que trata la lista siguiente como candidatos que debes comprobar, no como un diagnóstico. La orientación de Google para una página que debería ser pública es permitir el acceso a usuarios no autenticados o permitir explícitamente a Googlebot sin autenticación (después de verificar su identidad; volveremos sobre ello).
Una 403 no afecta a la velocidad de rastreo: no la uses para limitarla
A veces se recurre a 403 (o 404) para conseguir que Googlebot se aparte de un servidor con problemas. No lo hagas. Google lo dice claramente: «Don’t use 401 and 403 status codes for limiting the crawl rate. The 4xx status codes, except 429, have no effect on crawl rate.» (traducción) «No conviertas los estados 401 y 403 en un mecanismo para limitar el rastreo. Salvo 429, los estados 4xx no modifican la velocidad de rastreo». Conviene precisar el alcance: Google también dice por separado que la frecuencia de rastreo de una URL conocida disminuye gradualmente cuanto más tiempo sigue devolviendo 4xx; pero eso es una reducción del interés por esa URL, no una limitación de la velocidad de rastreo de todo el sitio. Si necesitas esto último, una 403 no lo consigue.
Gary Illyes escribió una publicación entera sobre esto (Don’t 404 my yum): «All 4xx HTTP status codes (again, except 429) will cause your content to be removed from Google Search.» (traducción) «Todos los códigos de estado HTTP 4xx (de nuevo, salvo 429) harán que tu contenido se elimine de Google Search». La palanca de emergencia correcta es devolver 500, 503 o 429 durante una ventana breve (horas, no días), e incluso eso no es un pase libre: Google advierte que las respuestas 5xx persistentes durante varios días también pueden hacer que las páginas salgan del índice, así que importan el alcance y la duración, no solo el código elegido. El artículo de Barry Schwartz sobre un incidente anterior explicó claramente lo que estaba en juego: los sitios habían «lost load[s] of their pages from our index because they were serving them with a 403 status code instead of a 503» (traducción) «perdido montones de páginas del índice porque las servían con un código de estado 403 en lugar de 503». Una 503 se entiende como temporal; una 403 te desindexa.
El problema de robots.txt: una 403 en robots.txt es permisiva, no restrictiva
Esta es una distinción que casi todos los artículos de la competencia omiten y que invierte la intuición. Una 403 en una página es un bloqueo estricto. Pero una 403 en el propio archivo robots.txt se trata de la manera opuesta. La especificación de robots.txt de Google dice: «Google’s crawlers treat all 4xx errors, except 429, as if a valid robots.txt file didn’t exist. This means that Google assumes that there are no crawl restrictions.» (traducción) «Para Google, los rastreadores tratan cada error 4xx salvo 429 como si faltara un robots.txt válido: por eso asume que no hay restricciones de rastreo».
Evidence for this claim A 403 on `/robots.txt` is handled differently from a 403 on a page: Google treats a non-429 4xx robots response as if no valid robots file exists and assumes no restrictions from that file. Scope: robots.txt fetch only Confidence: high · Verified: How Google interprets the robots.txt specificationAsí que, si tu firewall empieza a devolver 403 para robots.txt, Google concluye que no tienes reglas y rastrea libremente, incluidos los caminos que querías bloquear. La versión colorida de Illyes es que, si tenías una regla que impedía mostrar tu «ropa sucia», ahora Googlebot también sabe de ella. No confundas «mi robots.txt devolvió 403» (Google ahora ignora tus reglas) con «mis páginas devolvieron 403» (esas URL salen del índice). Tienen efectos opuestos, y diagnosticar mal cuál de los dos estás viendo hace que corrijas lo que no corresponde.
Cómo trata Bing las 403
Sinceramente, la documentación pública de Bing sobre las 403 concretas es más escasa que la de Google, así que delimitaré esta sección en vez de rellenarla. Bingbot recibe el mismo tipo de denegación que Googlebot: reglas de robots.txt, bloqueos de IP/user-agent a nivel del servidor y reglas de WAF/firewall. Bing Webmaster Tools muestra errores de rastreo en sus alertas de errores de rastreo. La conclusión práctica es la misma en ambos motores: permite el paso del rastreador verificado a través de tu capa de seguridad y verifica el bot mediante sus rangos de IP publicados y DNS inverso, en lugar de confiar en una cadena de user-agent. Si acaso, toma Bing como recordatorio de que «corregir Googlebot» no significa automáticamente «corregir todos los bots»: comprueba las herramientas de ambos motores después de un cambio en el WAF.
Causas habituales (no están clasificadas: no tengo datos de prevalencia entre sitios)
Protección de bots de CDN/WAF: la causa más desatendida en el contenido SEO existente. Aquí empezaría a comprobar en 2026, aunque no puedo decirte con qué frecuencia es realmente la culpable frente a las demás causas. Cloudflare Bot Fight Mode y Super Bot Fight Mode, las reglas gestionadas del WAF y las reglas de firewall personalizadas devuelven habitualmente 403 a Googlebot y Bingbot como daño colateral. La pista es que el bloqueo está en el edge: tu servidor de origen y tu CMS parecen completamente limpios mientras GSC sigue mostrando 403. Comprueba los Security Events del panel de tu CDN para ver si el rastreador está siendo desafiado o bloqueado.
2. Bloqueos de IP o user-agent a nivel del servidor/hosting. Algunos hosts bloquean por user-agent o limitan la velocidad por defecto, y los bloqueos de rangos de IP destinados al tráfico abusivo pueden atrapar rangos de rastreadores.
3. Configuración incorrecta de robots.txt/.htaccess. Un Deny from perdido o una regla de reescritura rota puede prohibir un directorio completo. (Y recuerda el problema de robots.txt anterior.)
4. Plugins de seguridad. Wordfence, iThemes Security y herramientas similares incluyen valores predeterminados agresivos para bloquear bots que pueden atrapar a rastreadores legítimos.
5. Barreras de inicio de sesión/contenido autenticado. Todo lo que está protegido por autenticación devuelve 403s a un bot por diseño: Googlebot nunca inicia sesión. Este caso suele ser intencionado (consulta la última sección).
6. Errores de permisos de archivos o directorios. La causa clásica para el administrador del servidor. En WordPress, Rank Math documenta valores razonables —directorios 755/750, archivos 644/640, wp-config.php 400/440— y «regenerate .htaccess» desde la configuración de enlaces permanentes como una corrección habitual.
7. Malware o sitio comprometido que inyecta reglas de acceso incorrectas, y 8. Bloqueo geográfico que atrapa inadvertidamente el rango de IP de un rastreador.
Diagnosticar una 403: aislar qué capa la emite
La mayoría de las guías salta directamente a «desactiva tus plugins». La habilidad real consiste en encontrar qué capa rechaza la solicitud: un código de estado 403 aislado no te lo dice; necesitas cabeceras de respuesta, registros o una entrada de evento de seguridad que señale de verdad a la CDN, el WAF, la aplicación, el host, los permisos, la geografía o la caché antes de nombrar un culpable. No saltes directamente a «probablemente es el WAF» sin pruebas. Así cambia la corrección según la capa:
- Informe de indexación de páginas de GSC → «Bloqueado por acceso prohibido (403)» para ver las URL afectadas; después Inspección de URL → Probar URL en directo para obtener la respuesta en directo actual.
- Reprodúcelo con curl, cambiando los user-agents, para confirmar el estado que devuelve realmente el servidor:
# As a generic client curl -I https://example.com/page/ # Spoofing Googlebot's UA (tests UA-based rules) curl -I -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://example.com/page/
Si un user-agent de navegador normal obtiene 200 pero el user-agent de Googlebot obtiene 403, has encontrado una regla basada en user-agent.
3. Comprueba el estado del propio robots.txt (¿también devuelve 403? Es un problema diferente; consulta arriba).
4. Revisa los Security Events de la CDN/WAF para ver si el rastreador está siendo desafiado o bloqueado.
5. Verifica que el rastreador sea realmente Googlebot mediante DNS inverso + directo, no mediante la cadena de UA (que se falsifica fácilmente).
6. Aísla desactivando por etapas: una regla WAF o un plugin cada vez, hasta que desaparezca la 403.
Corregirla: permitir bots de la manera adecuada
La corrección tentadora es permitir la cadena de user-agent de Googlebot. No te detengas ahí: las cadenas de UA se falsifican con facilidad, así que permitir solo por UA es un agujero de seguridad que deja entrar a cualquier scraper que se haga pasar por Googlebot. Verifica correctamente:
- Confirma los bots mediante DNS inverso + DNS directo o contra los rangos de IP publicados por Google/Bing.
- La mayoría de las CDN/WAF ofrece una categoría de «verified bots» que hace esta validación por ti; prefierela a una regla de permiso basada en UA sin más.
- Corrige la regla específica (una regla gestionada del WAF, una regla de firewall o un ajuste de plugin) en lugar de desactivar la seguridad por completo.
- Después usa Validate Fix en el informe Page Indexing de GSC y, si es urgente, solicita la reindexación mediante URL Inspection.
Cuándo está bien una 403: no «corrijas» estos casos
No toda 403 es un error. Una 403 es correcta e intencionada para sitios de staging, zonas de administración, secciones privadas para miembros y contenido de pago/protegido que nunca quisiste indexar. En una auditoría de Ahrefs o Screaming Frog, una 403 en esas zonas no es un problema; solo hace falta corregirla cuando una página que debería ser pública e indexable se bloquea por accidente. No «resuelvas» por reflejo cada 403 que marque una auditoría: confirma primero que realmente quieres esa página en el índice.
Para conocer la familia más amplia —en qué se diferencian 4xx y 5xx y dónde encaja 403—, consulta mi guía Códigos de estado HTTP y su impacto en el SEO y los análisis hermanos 401 Unauthorized y 404 Not Found de este grupo.
Resumen de IA
Una versión condensada de la versión Advanced:
- 403 = «entendí, pero rechazo». Según RFC 9110, el rechazo no tiene por qué deberse a las credenciales, y el servidor incluso puede enviar una 404 si quiere ocultar que existe un recurso prohibido. Se diferencia de 404 (normalmente no existe) y de 401 (un desafío de autenticación específico que exige una cabecera
WWW-Authenticate): volver a autenticarse no arregla una 403 de forma fiable. - El resultado de indexación se parece a
noindex, pero el mecanismo es distinto. Una etiquetanoindextiene que obtenerse y leerse para funcionar; una 403 impide que Google lea cualquier contenido. Ambas terminan haciendo que la página no aparezca en Search, por caminos diferentes. - Una 403 a Googlebot merece investigación, no es automáticamente un error. Comprueba primero si la página realmente debería ser pública. Si lo es, la causa probable es una regla activada por error (WAF, bloqueo de IP o plugin de seguridad), pero no existen datos fiables sobre cuál es la más habitual; trata las causas como una lista de comprobación, no como una clasificación.
- Una 403 no afecta a la velocidad de rastreo de todo el sitio. La frecuencia de rastreo de una URL conocida disminuye gradualmente cuanto más tiempo devuelve 4xxs, pero no es lo mismo que limitar todo el sitio. No uses nunca 401/403 para limitar Googlebot; usa 429/503/500 durante una ventana breve, e incluso eso puede desindexar si se deja demasiado tiempo.
- El problema de robots.txt (efecto contrario): una 403 en una página es un bloqueo estricto; una 403 en el propio robots.txt se trata de forma permisiva: Google supone que no existen reglas de rastreo.
- Diagnostica con pruebas, no con suposiciones. Una 403 aislada no identifica su origen; confírmalo con cabeceras de respuesta, registros o eventos de seguridad de la CDN antes de culpar a una capa concreta. GSC Page Indexing + Test Live URL → curl con y sin UA de Googlebot → Security Events de la CDN → verificar el bot mediante DNS/IP, no UA → desactivar por etapas.
- Corrección: permite bots verificados (DNS/IP o una categoría de CDN de «verified bots»), no la cadena de UA sin más. Después usa Validate Fix en GSC.
- Algunas 403 son correctas: staging, administración, contenido solo para miembros y contenido de pago; no las «corrijas». Comprueba la intención antes de suponer que son errores.
Documentación oficial
Documentación de fuentes primarias sobre cómo se gestionan las 403 y la familia 4xx.
Protocolo
- RFC 9110 §15.5.4: 403 Forbidden — la especificación HTTP base: el rechazo no tiene por qué deberse a las credenciales y un origen puede enviar 404 para ocultar un recurso prohibido.
- Cómo afectan los códigos de estado HTTP a los rastreadores de Google — la afirmación definitiva de que las URL 4xx (salvo 429) se eliminan del índice y no afectan a la velocidad de rastreo.
- Informe de indexación de páginas — Ayuda de Search Console — el estado «Bloqueado por acceso prohibido (403)» y la explicación de que Googlebot nunca proporciona credenciales.
- No uses 403/404 para limitar el rastreo — Gary Illyes, febrero de 2023, sobre por qué los códigos 4xx son una herramienta incorrecta para limitar el rastreo.
- Reducir la frecuencia de rastreo de Google — el enfoque correcto: devolver 500/503/429 durante poco tiempo, no 403/404.
- Cómo interpreta Google la especificación de robots.txt — el matiz de que un 4xx en robots.txt se trata como si no hubiera restricciones.
- Verificación de Googlebot — DNS inverso y rangos de IP publicados para permitirlo de la manera adecuada.
Bing / Microsoft
- List of crawl error alerts — Bing Webmaster Tools — categorías de errores de rastreo de Bing.
CDN/WAF
- Detección de bots falsos que bloquea solicitudes legítimas — documentación de Cloudflare sobre cómo las reglas gestionadas de detección de bots falsos pueden producir bloqueos por falso positivo, útil para confirmar (no suponer) que una regla WAF es la capa que emite la respuesta.
Referencia web general
- MDN — 403 Forbidden — definición base autorizada y distinción clara entre 401 y 403.
Citas de las fuentes
Declaraciones registradas. Cada enlace es un enlace profundo que salta al pasaje citado en la página de origen.
Google: cómo se gestionan los 4xx/403
- “Google doesn’t use the content from URLs that return 4xx status codes… Google doesn’t index URLs that return a 4xx status code, and URLs that are already indexed and return a 4xx status code are removed from the index.” (traducción) «Google no usa el contenido de las URL que devuelven códigos de estado 4xx… Google no indexa las URL que devuelven un código de estado 4xx, y las URL que ya están indexadas y devuelven un código de estado 4xx se eliminan del índice». — Documentación de Google Search Central. Ir a la cita
- “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». Ir a la cita
- “Don’t use 401 and 403 status codes for limiting the crawl rate. The 4xx status codes, except 429, have no effect on crawl rate.” (traducción) «No uses los códigos de estado 401 y 403 para limitar la velocidad de rastreo. Los códigos de estado 4xx, salvo 429, no tienen ningún efecto sobre la velocidad de rastreo». Ir a la cita
Google: el punto de que «Googlebot nunca se autentica»
- “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 agente de usuario proporcionó credenciales, pero no obtuvo acceso. Sin embargo, Googlebot nunca proporciona credenciales, así que tu servidor está devolviendo este error incorrectamente. La página no se indexará». — Ayuda de Search Console, «Blocked due to access forbidden (403)». Ir a la cita
Gary Illyes, Google: no limitar la velocidad con 4xx
- “All 4xx HTTP status codes (again, except 429) will cause your content to be removed from Google Search. What’s worse, if you also serve your robots.txt file with a 4xx HTTP status code, it will be treated as if it didn’t exist.” (traducción) «Todos los códigos de estado HTTP 4xx (de nuevo, salvo 429) harán que tu contenido se elimine de Google Search. Y lo que es peor: si también sirves tu archivo robots.txt con un código de estado HTTP 4xx, se tratará como si no existiera». — Blog de Google Search Central, febrero de 2023. Ir a la cita
- “Return a 500, 503, or 429 HTTP status code to Googlebot when it’s crawling too fast.” (traducción) «Devuelve a Googlebot un código de estado HTTP 500, 503 o 429 cuando rastree demasiado rápido». Ir a la cita
Google: el giro de 403 en robots.txt
- “Google’s crawlers treat all 4xx errors, except 429, as if a valid robots.txt file didn’t exist. This means that Google assumes that there are no crawl restrictions.” (traducción) «Los rastreadores de Google tratan todos los errores 4xx, salvo 429, como si no existiera un archivo robots.txt válido. Esto significa que Google supone que no hay restricciones de rastreo». — Cómo interpreta Google la especificación de robots.txt. Ir a la cita
MDN: la definición general y la distinción entre 401 y 403
- “The HTTP 403 Forbidden client error response status code indicates that the server understood the request but refused to process it. This status is similar to 401, except that for 403 Forbidden responses, authenticating or re-authenticating makes no difference.” (traducción) «El código de estado de respuesta de error del cliente HTTP 403 Forbidden indica que el servidor entendió la solicitud, pero se negó a procesarla. Este estado es similar a 401, salvo que, en las respuestas 403 Forbidden, autenticarse o volver a autenticarse no cambia nada». — MDN Web Docs. Ir a la cita
Barry Schwartz, Search Engine Roundtable: gravedad de 403 frente a 503 Información transmitida sobre una declaración de Google, no una página de Google de primera mano; además, la propia URL de origen devuelve 403 a los fetchers automatizados (una ironía relacionada con el tema). Confírmalo en un navegador antes de tratarlo como definitivo.
- Al informar de la advertencia de Google: los sitios habían «lost load[s] of their pages from our index because they were serving them with a 403 status code instead of a 503.» (traducción) «perdido montones de páginas del índice porque las servían con un código de estado 403 en lugar de 503». Leer la cobertura
Diagnosticar una 403: árbol de decisión
Empieza por lo que recibe realmente Googlebot y después acota por capa.
P1. ¿La 403 está en una página que quieres indexar?
- No (staging, administración, solo para miembros, de pago) → probablemente es correcta. Déjala. Detente aquí.
- Sí → continúa.
P2. ¿Es la página la que devuelve 403 o es robots.txt?
- robots.txt devuelve 403 → problema diferente: Google ahora ignora todas tus reglas de rastreo (trata robots.txt como ausente). Corrige robots.txt para que devuelva
200; la 403 de la página puede ser un problema aparte. - La página devuelve 403 → continúa.
P3. ¿curl lo reproduce y depende del user-agent?
curl -I https://example.com/page/
curl -I -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://example.com/page/- UA del navegador = 200, UA de Googlebot = 403 → una regla de user-agent bloquea al bot (WAF, configuración del servidor o plugin). Ve a P4.
- Ambos = 403 → un bloqueo más amplio (rango de IP, permisos del directorio o
.htaccessDeny). Comprueba la configuración del servidor y los permisos de archivos. - Ambos = 200, pero GSC sigue mostrando 403 → probablemente el bloqueo está en el edge/CDN y depende de la IP o del estado de bot verificado. Ve a P4 y comprueba los Security Events de la CDN.
P4. ¿Estás detrás de una CDN/WAF (Cloudflare, etc.)?
- Sí → comprueba los Security Events para ver si el rastreador está siendo desafiado o bloqueado. Sospecha Bot Fight Mode/Super Bot Fight Mode, reglas gestionadas del WAF o una regla de firewall personalizada. Permite bots de búsqueda verificados, no una regla de permiso basada en UA sin más.
- No → comprueba los bloqueos de IP/UA a nivel del servidor, después los plugins de seguridad (Wordfence, etc.) y por último
.htaccessy los permisos de archivos.
P5. ¿Has corregido la regla?
- Permite por bot verificado/DNS/rango de IP, nunca solo por cadena UA → Validate Fix en GSC Page Indexing → solicita la reindexación mediante URL Inspection si es urgente.
Antipatrones: errores con 403 que veo constantemente
Usar 403 (o 404) para ralentizar Googlebot. El mito dice que devolver una 403 limita el rastreo. No lo hace: los 4xx (salvo 429) no tienen ningún efecto sobre la velocidad de rastreo y, en cambio, desindexan las páginas a las que devolviste 403. Si necesitas ralentizar un rastreo, devuelve 429, 503 o 500 durante una ventana breve (horas, o uno o dos días), o usa los informes de velocidad de rastreo de Search Console. Una 403 nunca es una herramienta de control del rastreo, ni siquiera temporalmente.
Tratar una 403 exactamente igual que una 404 en una auditoría. Ambas terminan eliminando la URL del índice, así que es tentador agruparlas. Pero una 404 normalmente significa «desaparecido», mientras que una 403 significa «acceso rechazado activamente»: a veces es una configuración incorrecta que se puede corregir y a veces es un bloqueo intencionado. Mezclarlas oculta el problema real en ambos casos. Diagnostica la causa y la intención, no solo el resultado.
Suponer que Googlebot «hizo algo sospechoso» para merecer el bloqueo. Googlebot nunca envía credenciales, así que una 403 presentada como «credenciales incorrectas» no encaja con él. Pero eso no significa que todo bloqueo sea un error: confirma primero que la página debía ser pública. Si lo era, no racionalices el bloqueo como algo que Googlebot provocó; encuentra la regla que se activó (WAF, bloqueo de IP o plugin).
Permitir por una cadena de user-agent sin más. Las cadenas UA se falsifican fácilmente, así que una regla del tipo allow if UA contains "Googlebot" deja pasar directamente a cualquier scraper que finja ser Google. Verifica mediante DNS inverso + directo o rangos de IP publicados, o usa la categoría de verified-bots de tu CDN.
Confundir una 403 en robots.txt con una 403 en tus páginas. Tienen efectos opuestos. Una 403 en una página es un bloqueo estricto que la desindexa. Una 403 en robots.txt hace que Google suponga que no tienes reglas de rastreo, y puede rastrear caminos que querías bloquear. Diagnostica cuál de las dos estás viendo antes de corregir nada.
«Corregir» 403 intencionadas. Los sitios de staging, zonas de administración, contenido solo para miembros y contenido de pago deben devolver 403 a los rastreadores. Resolver por reflejo cada 403 de una auditoría puede exponer cosas que nunca quisiste indexar. Confirma primero que la página deba ser pública.
El marco de intención, alcance y capa emisora
Una auditoría de 403 se vuelve más rápida cuando respondo tres preguntas en orden:
- Intención: ¿debe ser público este recurso? Deja intacto un bloqueo deliberado de una zona privada. Trata una 403 en una página indexable como un incidente.
- Alcance: ¿el fallo afecta a una URL, un directorio, un user-agent, una geografía o todas las solicitudes? El límite suele identificar la regla responsable más rápido que cambiar plugins al azar.
- Capa emisora: compara el evento de la CDN/WAF, el registro de acceso del origen, el registro de la aplicación y las cabeceras de respuesta. Cambia la primera capa que realmente emite la 403, no todas las capas que podrían hacerlo.
Después de la corrección, verifica por separado el acceso anónimo y el acceso del rastreador verificado. Un user-agent que afirma ser Googlebot sirve para reproducir una regla basada en UA, pero no demuestra la identidad del rastreador.
Prompt: aislar una 403 por capa
Diagnose this HTTP 403 using only the evidence I paste. Classify the likely issuing
layer as CDN/WAF, web server, application/security plugin, filesystem permissions,
or intentional access control. Compare generic and claimed-bot responses, identify
which observation supports each conclusion, and give the smallest safe change plus
an anonymous curl test and Search Console validation. Do not recommend disabling all
security or trusting a user-agent string as identity.
[PASTE SANITIZED HEADERS, CURL OUTPUT, SECURITY EVENT, AND LOG LINES]Prompt: revisar una excepción de WAF
Review this WAF rule intended to stop 403s for legitimate search crawlers. Check its
scope, whether crawler identity is verified, what non-crawler traffic it could admit,
and whether robots.txt behaves differently from page URLs. Return a least-privilege
rewrite, test cases, and rollback conditions. Do not invent provider syntax.
[PASTE RULE AND PROVIDER] Herramientas para diagnosticar respuestas 403
- Comprobador masivo de códigos de estado HTTP: descubre si el bloqueo está aislado o afecta a un patrón de URL sin llevar tu sesión de inicio de sesión.
- Comprobador de cabeceras HTTP: inspecciona las huellas de la CDN, los ID de solicitud y las cabeceras de seguridad que ayudan a identificar la capa emisora.
- Verificador de Googlebot: valida las pruebas de IP antes de permitir el acceso a un rastreador; nunca trates el user-agent por sí solo como una prueba.
- Indexación de páginas e Inspección de URL en Search Console: consulta el conjunto afectado que se informa, prueba en directo la respuesta actual y valida después de la corrección.
- Eventos de seguridad de CDN/WAF y registros del origen: si el edge registra un bloqueo y el origen no registra ninguna solicitud, la corrección corresponde al edge.
Ponte a prueba: 403 Forbidden
Cinco preguntas rápidas sobre qué significa una 403 y cómo gestionarla. Elige una respuesta para cada una y después compruébala.
Recursos que merecen tu tiempo
Mis textos relacionados
- Códigos de estado HTTP y su impacto en el SEO — el resumen completo de 4xx/5xx, dónde encaja 403 entre los códigos y la mecánica de que las 4xx hagan salir las páginas del índice.
- Guía para principiantes de SEO técnico — dónde encajan en el panorama general los problemas de acceso de rastreo/indexación, como las 403.
- Robots.txt y SEO: todo lo que debes saber — el matiz de 403 en robots.txt y cómo funcionan realmente los controles de rastreo.
Mis charlas
- How Search Works (SlideShare) — mi recorrido por rastrear → renderizar → indexar → servir; una 403 es un fallo en la primera barrera. (Descargo habitual: «This is my understanding of systems… not going to be 100% complete or accurate.» (traducción) «Esta es mi interpretación de los sistemas… no será 100 % completa ni exacta».)
De otros lugares de la industria
- No uses 403/404 para limitar el rastreo (blog de Google Search Central) — Gary Illyes explica por qué los 4xx son una herramienta incorrecta para limitar el rastreo.
- Reducir la frecuencia de rastreo de Google (Google Search Central) — el enfoque correcto de 500/503/429, para contrastarlo.
- Google advierte del uso indebido de códigos 403 (Search Engine Roundtable) — la anécdota sobre la gravedad de 403 frente a 503 (verifícala en un navegador; la página devuelve 403 a los bots).
- Google: no uses respuestas de error 403/404 para limitar el rastreo de Googlebot (Search Engine Journal) — cobertura de la orientación de 2023.
- Cómo corregir «Bloqueado por acceso prohibido (403)» en Google Search Console (SEOTesting) — estructura sólida de causas y correcciones, incluido el encuadre de «¿debes corregir toda 403?».
- Cómo corregir el error «Bloqueado por acceso prohibido (403)» (Rank Math) — valores concretos de
chmoden WordPress y un flujo de Health Check. - Códigos de estado HTTP: por qué no se rastrea mi sitio (Screaming Frog) — diagnóstico desde el rastreador (cambio de UA, renderizado JS y permisos por IP/UA).
Registro de cambios
Actualizado el 8 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 6 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 5 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.
La comparación completa no está disponible: no se archivó una instantánea anterior para esta revisión.
Try it live
This is a real endpoint on this site — not a simulation.
Hit it from the button, open it in a new tab, or
curl -i it from your terminal, and the server answers with the actual status code this article is about.