401 Unauthorized: qué significa y cómo afecta al SEO

Qué significa una respuesta HTTP 401 Unauthorized, cómo se diferencia de 403 Forbidden, cómo trata Google las páginas protegidas por autenticación y cuáles son sus implicaciones para el SEO.

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

401 Unauthorized significa que la solicitud carece de credenciales de autenticación válidas: el servidor quiere que inicies sesión. Se diferencia de 403 Forbidden (se proporcionaron credenciales, pero se deniega el acceso), pero para la indexación Google las trata igual: Googlebot nunca envía credenciales, así que el contenido de una página con 401 no existe en la práctica para Google, no se indexará y saldrá del índice con el tiempo si ya estaba allí. Una 401 no es necesariamente mala: es la forma correcta de proteger sitios de staging y zonas para miembros; solo es un problema cuando afecta a una página que quieres posicionar. No tiene ningún efecto sobre la velocidad de rastreo, pese a un mito habitual.

TL;DR — 401 Unauthorized es un error del cliente (RFC 9110 §15.5.2, que sustituyó a RFC 7235) que significa que la solicitud carece de credenciales de autenticación válidas, incluidas las credenciales que se enviaron pero fueron rechazadas, no solo las que nunca se enviaron; una 401 conforme también envía una cabecera WWW-Authenticate que nombra el esquema esperado. Se diferencia de 403 (un rechazo que no requiere ese desafío y puede no tener ninguna relación con las credenciales), pero Google trata todos los 4xx salvo 429 de la misma forma para la indexación: el contenido «no existe», así que no se indexa y las URL indexadas anteriormente salen del índice con el tiempo. Como el Googlebot normal nunca envía credenciales, un 403 a Googlebot es —en palabras del propio Google— normalmente una configuración incorrecta del servidor. 401/403 no tienen ningún efecto sobre la velocidad de rastreo de todo el sitio (un mito muy repetido), aunque una URL individual que siga devolviendo 4xx se vuelve a rastrear con menos frecuencia con el tiempo. Una 401 es la forma correcta y respaldada por Google de proteger contenido verdaderamente privado; solo es un problema cuando afecta a una página que quieres indexar. Para el contenido de pago existe una vía autorizada que no consiste en una 401 general.

Qué es realmente una 401

401 Unauthorized es una respuesta de error del cliente. La definición de MDN es la explicación técnica más limpia:

“The HTTP 401 Unauthorized client error response status code indicates that a request was not successful because it lacks valid authentication credentials for the requested resource. This status code is sent with an HTTP WWW-Authenticate response header that contains information on the authentication scheme the server expects the client to include to make the request successfully.” (traducción) «El código de estado de respuesta de error del cliente HTTP 401 Unauthorized indica que una solicitud no tuvo éxito porque carece de credenciales de autenticación válidas para el recurso solicitado. Este código de estado se envía con una cabecera de respuesta HTTP WWW-Authenticate que contiene información sobre el esquema de autenticación que el servidor espera que el cliente incluya para realizar correctamente la solicitud».

Evidence for this claim A 401 response means the request lacks valid authentication credentials and the response must include a WWW-Authenticate challenge. Scope: RFC 9110 defines the status semantics and required challenge header; it does not prescribe a site's authentication product or login flow. Confidence: high · Verified: IETF: RFC 9110 §15.5.2 — 401 Unauthorized

Conviene extraer dos cosas de ahí. Primero, «authentication»: quien solicita aún no ha demostrado quién es. Normalmente significa que faltan las credenciales, no son válidas o han caducado, pero una 401 también puede seguir a unas credenciales que se enviaron y fueron rechazadas; por eso no supongas que falta por completo la cabecera de autenticación sin comprobar realmente la solicitud. Segundo, una 401 conforme con la especificación debe llevar una cabecera WWW-Authenticate: según RFC 9110 §15.5.2, que sustituyó al RFC 7235 anterior, debe indicar al cliente qué esquema o esquemas espera (HTTP Basic Auth, un token Bearer, un flujo de cookie de sesión, etc.). Si estás depurando una 401, esa cabecera es lo primero que debes inspeccionar: si está presente y qué esquema nombra. Evidence for this claim A 401 response means the request lacks valid authentication credentials and the response must include a WWW-Authenticate challenge. Scope: RFC 9110 defines the status semantics and required challenge header; it does not prescribe a site's authentication product or login flow. Confidence: high · Verified: IETF: RFC 9110 §15.5.2 — 401 Unauthorized

En mi propia guía de códigos de estado resumo la 401 así: «the client hasn’t identified or verified itself when needed.» (traducción) «el cliente no se ha identificado ni verificado cuando era necesario». Esa es toda la idea: todavía nadie ha dicho quién es.

401 frente a 403 Forbidden: la distinción que importa

Aquí es donde la mayoría se vuelve imprecisa, así que voy a dejarlo claro. En una sola línea:

  • 401 = «¿Quién eres?»: faltan las credenciales o no son válidas; autentícate e inténtalo de nuevo.
  • 403 = «Sé quién eres, pero no».: la solicitud se entendió, pero el acceso se deniega independientemente de las credenciales.

MDN lo plantea de la misma manera:

“A 401 Unauthorized is similar to the 403 Forbidden response, except that a 403 is returned when a request contains valid credentials, but the client does not have permissions to perform a certain action.” (traducción) «Una respuesta 401 Unauthorized es similar a la respuesta 403 Forbidden, salvo que se devuelve una 403 cuando una solicitud contiene credenciales válidas, pero el cliente no tiene permisos para realizar una determinada acción».

Yo marco el mismo contraste en mi guía: 401 es «the client hasn’t identified or verified itself when needed» (traducción) «el cliente no se ha identificado ni verificado cuando era necesario», mientras que 403 es «the client is known but doesn’t have access rights» (traducción) «el cliente es conocido, pero no tiene derechos de acceso». Autenticación frente a autorización.

Esa frase es un resumen fiable, pero aquí tienes la prueba de protocolo más precisa si necesitas elegir entre los dos códigos en el código o en una regla WAF: 401 exige ese desafío WWW-Authenticate —RFC 9110 lo establece como MUST—, mientras que 403 no lo exige, porque un rechazo 403 puede deberse a motivos que no tienen nada que ver con las credenciales (un bloqueo de IP, una regla de permisos o una política de limitación de velocidad). Por eso «¿había credenciales?» no basta para distinguirlos: una 401 puede seguir a credenciales rechazadas, no solo a credenciales ausentes. Si decides qué código devolver, pregunta más bien: ¿estoy emitiendo un desafío de autenticación (401) o un rechazo tajante (403)?

Aquí aparece el matiz de SEO que no es obvio, y es la propia observación de Google sobre la 403. El Googlebot normal nunca envía credenciales. Así que una 403 servida específicamente a Googlebot significa, en palabras del propio Google, que el servidor se está equivocando:

“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á».

Es un diagnóstico útil. Una 401 para Googlebot puede ser intencionada (la página está protegida por diseño). Una 403 para Googlebot suele apuntar a una configuración incorrecta: Googlebot no envió credenciales, así que nada debería activar una respuesta del tipo «se denegaron las credenciales». Si ves 403 en páginas a las que Googlebot debería llegar, sospecha primero de la configuración de tu CDN, WAF o servidor. Esto describe los rastreadores habituales de Google. Google documenta por separado los rastreadores especiales y los fetchers activados por el usuario, con comportamientos propios; no supongas que la regla de «nunca envía credenciales» se generaliza a todas las integraciones de productos de Google sin comprobarlo.

401 Unauthorized403 Forbidden
SignificadoFaltan las credenciales o no son válidas: «¿quién eres?»Se entendió, pero se deniega el acceso: «te conozco, no»
Cabecera obligatoriaWWW-Authenticate (RFC 9110)Ninguna obligatoria
Activador habitualBarrera de inicio de sesión, token caducado, Basic Auth, tiempo de espera de sesiónReglas de permisos, bloqueos de IP/geográficos, reglas WAF, restricciones de directorio
Para GooglebotPuede ser intencionada (la página está protegida)Normalmente una configuración incorrecta del servidor (Googlebot no envía credenciales)
Resultado de indexaciónNo se indexa; sale del índice con el tiempoNo se indexa; sale del índice con el tiempo

La última fila es la conclusión: para la indexación, Google las trata de forma idéntica.

Cómo trata Google las páginas 401

El documento de Google sobre códigos de estado HTTP es tajante con la familia 4xx:

“Google doesn’t use the content from URLs that return 4xx status codes. If a URL was previously used but is now returning 4xx status code, Google systems will stop using the URL over time. In the case of Google Search, 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. Si una URL se usaba anteriormente pero ahora devuelve un código de estado 4xx, los sistemas de Google dejarán de usarla con el tiempo. En el caso de la Búsqueda de Google, 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». 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 Search indexing outcome for 401 responses; it does not address access decisions for private users. Confidence: high · Verified: Google: How HTTP status codes affect Google's crawlers

Y la 401 no es un caso especial dentro de esa familia. En la tabla del documento, 401 (unauthorized) y 403 (forbidden) aparecen como filas separadas que comparten una explicación:

“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».

Así que el resultado es binario, no una degradación. Una página con 401 no «se posiciona peor»: no se indexa en absoluto o se elimina por completo si ya estaba indexada. No existe una penalización parcial. Esto encaja con la afirmación de referencia de mi propia guía: las 4xx hacen que las páginas salgan del índice. Este artículo es el análisis específico de 401 que se añade a ese punto de partida.

Hay un matiz sobre el momento: la eliminación ocurre «con el tiempo», no en la primera obtención incorrecta. La documentación de Google describe un proceso gradual, y el sistema de rastreo históricamente se ha descrito como tolerante con los errores de corta duración antes de considerar que una URL ha desaparecido de verdad.

El mito de la velocidad de rastreo: una 401 NO ralentiza el rastreo

Este punto confunde a muchos artículos que por lo demás son buenos, así que quiero ser preciso. Una 401 (o 403) no ralentiza la velocidad de rastreo de Google. Google lo dice directamente:

“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».

Esto importa porque verás consejos que dicen que proteger páginas tras una 401 «ahorra presupuesto de rastreo» o «desperdicia presupuesto de rastreo»; ambos enfoques son incorrectos. Solo 429 (y las señales de tipo 5xx, como 503) indican a Googlebot que reduzca la velocidad. Una 401 no es un limitador: es una señal de que «el contenido no existe» para la indexación, sin más. Si de verdad quieres ralentizar temporalmente un rastreo, usa 429/503, no 401/403.

Conviene precisar el alcance, porque estas dos afirmaciones se confunden fácilmente: «sin efecto sobre la velocidad de rastreo» se refiere a la velocidad de rastreo general de tu sitio. Por separado, Google dice que una URL individual que sigue devolviendo 4xx se vuelve a rastrear con menos frecuencia con el tiempo: su frecuencia de reintento disminuye gradualmente. Son alcances diferentes: el presupuesto de rastreo de todo tu sitio no se limita, pero una URL que devuelve 401 de forma persistente sí se comprueba con menos frecuencia a medida que Google le da menos prioridad.

También hay un caso especial que conviene conocer: una 401 en una página normal y una 401 en el propio /robots.txt no se gestionan igual. Si tu archivo robots.txt devuelve un 4xx distinto de 429 (incluido 401), Google lo trata como si no existiera ningún robots.txt: supone que ese archivo no impone restricciones de rastreo, no que todo tu sitio haya dejado de estar accesible. No pongas /robots.txt detrás de la misma barrera de autenticación que tus páginas privadas.

¿Una 401 siempre es un problema? No.

Una 401 solo es un error cuando aparece de forma no intencionada en una página que quieres hacer pública. Cuando la página es realmente privada, una 401 es la forma correcta de mantenerla fuera de las búsquedas, y es lo que recomienda Google. John Mueller lo explicó claramente (según lo transmitió Search Engine Journal): el enfoque ideal es una autenticación del lado del servidor que impida a los usuarios normales ver el contenido, «that would include GoogleBot» (traducción) «eso incluiría a GoogleBot». (Transmitido por Search Engine Journal a partir de un hangout de Google de 2019; trátalo como una declaración de un representante parafraseada con exactitud, no como una cita literal verificada por fragmentos.)

La autenticación del lado del servidor (que es la que produce una 401) es el mecanismo que recomienda para ocultar contenido no público, por delante de robots.txt, precisamente porque bloquea el acceso de verdad en lugar de limitarse a pedir a los bots que no entren.

Así que el marco de decisión es sencillo:

  • Debe seguir devolviendo 401: entornos de staging, zonas solo para miembros, herramientas internas y cualquier contenido realmente privado. Funciona según lo diseñado. No lo «corrijas».
  • Necesita corrección: una página pública e indexable que devuelve 401 por accidente: un falso positivo de CDN/WAF, un Basic Auth que quedó activo, un token caducado o un conflicto de plugin/middleware.

Implicaciones para el SEO y la trampa de «a mí me funciona»

Los modos de fallo prácticos:

  • Las páginas que quieres indexar permanecen invisibles hasta que se elimina la barrera.
  • Las páginas que antes se posicionaban desaparecen si empiezan a devolver 401.
  • La trampa de «a mí me funciona»: quien hace la prueba está autenticado, ha iniciado sesión o usa una IP incluida en la lista de permitidas; el rastreador no. La orientación de Google para el caso 401 es: «You can verify this error by visiting the page in incognito mode.» (traducción) «Puedes verificar este error visitando la página en modo incógnito». Mejor aún, prueba sin autenticarte con curl -I https://example.com/page o usa Inspección de URL / Prueba en directo de Search Console.

Cuando necesites dejar pasar a un rastreador real, verifícalo mediante IP / DNS inverso, nunca confiando solo en la cadena de user-agent: las cadenas de user-agent se falsifican con facilidad, así que permitir «Googlebot» por nombre es un agujero de seguridad, no una solución.

¿Y el contenido de pago o solo para suscriptores?

Una 401 general para todo el mundo (incluido Googlebot) no es tu única opción si quieres que el contenido protegido siga posicionándose. Google permite indexar contenido de pago mediante los datos estructurados isAccessibleForFree, junto con la concesión de acceso a las identidades de rastreadores específicas de Google para contenido de suscriptores o usuarios registrados. El objetivo de la marca es:

“This structured data helps Google differentiate paywalled content from the practice of cloaking, which violates spam policies.” (traducción) «Estos datos estructurados ayudan a Google a diferenciar el contenido de pago de la práctica del encubrimiento, que infringe las políticas de spam».

La advertencia que incorpora es esta: servir silenciosamente el contenido completo solo a Googlebot, sin revelar esa situación mediante datos estructurados, es cloaking, un riesgo según las políticas contra el spam. Si quieres que el contenido protegido se indexe, hazlo de la forma autorizada (marcado + acceso del rastreador), no mediante un bypass silencioso.

Cómo corregir una 401 no deseada

  1. Confirma que realmente no la quieres. ¿Se supone que esta página debe ser pública? Si es de staging o solo para miembros, no hay nada que corregir.
  2. Elimina el requisito de autenticación en las páginas públicas: quita el Basic Auth que quedó activo (.htaccess/nginx), corrige los tokens caducados y resuelve los conflictos de plugins o middleware.
  3. Comprueba tu CDN/WAF, y no supongas que ya sabes qué capa emitió la 401. La respuesta (y su cabecera WWW-Authenticate) te indica que ocurrió un desafío, pero no dónde se originó: tu aplicación, un proxy de identidad/autenticación, la CDN o las reglas de gestión de bots del WAF y el servidor de origen pueden generarlo. Los falsos positivos de las reglas de gestión de bots del edge son una causa habitual; inspecciona los registros de cada capa y verifica Googlebot mediante DNS inverso antes de permitirlo.
  4. Deja pasar a los rastreadores verificados mediante IP/DNS inverso, no mediante user-agent.
  5. No uses 401 para desindexar una página que podrías hacer pública: utiliza noindex (permitiendo el rastreo). Una barrera de inicio de sesión es para contenido que debe ser verdaderamente privado.
  6. Valida la corrección con la Prueba en directo de Inspección de URL, pero interpreta un resultado satisfactorio como la confirmación de la obtención actual, no como una garantía. Google no se compromete con un plazo fijo de nuevo rastreo, reindexación o recuperación del posicionamiento después de corregir una 401; una Prueba en directo aprobada demuestra que la obtención en directo de Google pudo pasar, no que el rastreo programado o la indexación ya se hayan puesto al día. Dale tiempo y vuelve a comprobar el informe de indexación de páginas en lugar de esperar una reversión instantánea.

Para conocer el flujo completo de diagnóstico, corrección y validación de Google Search Console para el estado de indexación «Blocked due to unauthorized request (401)», consulta el artículo complementario dedicado; este artículo se mantiene en el nivel de protocolo y conceptos.

Bing

Bing se comporta funcionalmente de la misma manera: una URL que devuelve 401 (o 403) a Bingbot es inaccesible y no se indexará. Bingbot necesita acceso no autenticado igual que Googlebot, y para permitirlo debes verificarlo mediante sus rangos de IP publicados, no mediante el user-agent.

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.