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.

Publicado por primera vez: 27 jun 2026 · Última actualización: 8 ago 2026 · Avanzado
Idiomas
1 señal de evidencia en esta página

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 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-Authenticate que 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 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 specification

Así 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:

  1. 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.
  2. 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.

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.

Open in new tab ↗

Add an expert note

Pin an expert quote

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