¿Qué es el Error 401 (Unauthorized)?

El 401 pertenece a la familia 4xx de los códigos de estado HTTP, los errores del cliente. Su definición vigente está en la RFC 9110, de junio de 2022, sección 15.5.2: la petición no se ha aplicado porque «carece de credenciales de autenticación válidas». La misma sección obliga al servidor a enviar la cabecera WWW-Authenticate con al menos un desafío, es decir, el esquema con el que el cliente puede identificarse. La RFC pone como ejemplo la línea WWW-Authenticate: Basic realm="simple". En español se traduce como «no autorizado», con la misma confusión que el original.

Un servidor devuelve un 401 cuando un recurso exige identificarse y la petición llega sin credenciales o con unas que no acepta. Si no se envió nada, el 401 pide al cliente que se identifique. Si se enviaron credenciales, la RFC dice que se han rechazado, y el cliente puede repetir la petición con otras. En un navegador, una protección del tipo Basic aparece como un cuadro que pide usuario y contraseña. En una API, el 401 llega por ejemplo cuando falta el token de acceso o ya no es válido.

Para Google, el 401 es un error 4xx más. Su documentación sobre códigos de estado, actualizada el 4 de febrero de 2026, trata igual todos los 4xx salvo el 429: Google no indexa la URL y, si ya estaba indexada, la retira del índice. El robot de Google nunca envía credenciales, según la ayuda de Search Console, así que lo que está detrás de un 401 queda fuera de la búsqueda. Google advierte además de que el 401 y el 403 no sirven para reducir la frecuencia de rastreo, porque los 4xx, salvo el 429, no la cambian.

El propio archivo robots.txt es un caso aparte. Si responde con un 401, Google actúa como si no existiera un robots.txt válido y entiende que no hay restricciones de rastreo.

Una web de pruebas en staging.ejemplo.es está protegida con usuario y contraseña. Quien la abre ve el cuadro de acceso, y el robot de Google recibe un 401 y no la indexa. Es la vía que Google recomienda para el contenido privado.

Una tienda conecta su catálogo con una API externa. El token caduca, la API responde con un 401 y el catálogo deja de actualizarse hasta que alguien renueva el token. Aquí el 401 no tiene que ver con Google.

Un tercer caso es un descuido: una regla de acceso pensada para el área de clientes se aplica a toda la carpeta del blog. En Search Console, esas páginas aparecen como «Bloqueada por una solicitud no autorizada (401)» y salen del índice.

Search Console tiene una categoría propia en el informe de indexación de páginas: «Bloqueada por una solicitud no autorizada (401)». Si quieres que la página se indexe, la ayuda de Google da dos salidas: quitar el requisito de autorización o dejar pasar al robot de Google después de verificar su identidad. Para comprobar el error, propone abrir la página en modo incógnito. Hay dos comprobaciones rápidas:

• Abre la URL en una ventana de incógnito. Si aparece el cuadro de acceso, cualquier visitante sin sesión, y también Google, recibe el 401.
• Pide solo las cabeceras desde la línea de comandos, por ejemplo con curl -I. La respuesta muestra el código 401 y la cabecera WWW-Authenticate.

Como protección, el 401 cumple lo que promete. Google recomienda la contraseña para el contenido confidencial o privado y escribe que así no aparece en la búsqueda o, si ya aparece, acaba saliendo de los resultados. Ni robots.txt ni noindex logran eso por sí solos: una URL bloqueada en robots.txt puede seguir en los resultados si otras páginas la enlazan, y la regla noindex solo funciona si el robot puede rastrear la página. La desventaja es la otra cara de lo mismo: lo que debe posicionar no puede estar detrás de un 401, porque Google no indexa lo que no recibe.

Fuente: RFC 9110, secciones 15.5.2, 15.5.4 y 15.5.5; Google, «How HTTP Status Codes Affect Google's Crawlers» (consultado el 11.11.2026).

Las fuentes no trazan igual la línea entre 401 y 403. La ayuda de Search Console da por hecho que un 403 llega después de enviar credenciales, mientras que la RFC 9110 admite un 403 por motivos que no tienen que ver con ellas. Lo explicamos en la entrada sobre el error 403.

• Protege la web de pruebas con usuario y contraseña en el servidor, de modo que cualquier petición sin credenciales reciba un 401.
• No la des por oculta solo con robots.txt: según Google, una URL bloqueada ahí puede aparecer en los resultados si otras páginas la enlazan.
• No te limites a un noindex o a la cabecera X-Robots-Tag: para el contenido privado, Google recomienda la contraseña.
• Abre la web de pruebas en una ventana de incógnito y comprueba que aparece el cuadro de acceso.
• Al pasar a producción, comprueba que la protección no se ha copiado al dominio real: abre varias URL en incógnito y revisa en Search Console la categoría del 401.
• Si una zona de pago debe indexarse, no uses un 401: Google documenta para eso datos estructurados que marcan el contenido de pago.

• Envía siempre la cabecera WWW-Authenticate con el 401, como exige la RFC 9110.
• Usa el 401 cuando falta la identificación y el 403 cuando el servidor niega el acceso por otro motivo.
• No uses 401 ni 403 para frenar el rastreo de Google; para eso Google remite a su guía para reducir la frecuencia de rastreo.
• Antes de dejar pasar a quien dice ser Googlebot, compruébalo con una búsqueda DNS inversa o con las listas de IP que publica Google.

• Dar por oculta una web de pruebas porque robots.txt la bloquea.
• Dejar la protección activa en una sección pública después de un lanzamiento.
• Responder con un 401 en el robots.txt pensando que bloquea a Google: Google lo trata como si no hubiera robots.txt.
• Usar 401 o 403 para reducir la carga que genera el rastreo.
• Dejar pasar cualquier petición que se presente como Googlebot sin verificarla.

Esta entrada se escribió en noviembre de 2026 con ayuda de IA. Los datos vienen de la RFC 9110, de la documentación de Google sobre códigos de estado, robots.txt, noindex y verificación de rastreadores, y de la ayuda de Search Console. Se revisó antes de publicarla y no contiene datos de clientes.