401 Unauthorized: se requiere autenticación

401 Unauthorized significa que la solicitud necesita una autenticación válida y no la tenía. A pesar del nombre, trata de la autenticación (quién eres), no de los permisos: si envías credenciales correctas, el servidor puede dejarte pasar. Cuando el servidor sabe quién eres y aun así te rechaza, es un 403 Forbidden.

Qué exige el estándar

La RFC 9110, sección 15.5.2 establece que una respuesta 401 debe incluir una cabecera WWW-Authenticate con al menos un desafío que indique al cliente cómo autenticarse, por ejemplo Basic o Bearer. Si la solicitud ya llevaba credenciales, el 401 significa que se rechazaron. Ante un desafío Basic, los navegadores muestran su ventana de inicio de sesión integrada.

Causas habituales

• Autenticación HTTP Basic en un sitio de staging, un área de administración o un directorio (.htpasswd).
• Tokens de API caducados, ausentes o mal formados (Authorization: Bearer …).
• Protección que se quedó activada tras el lanzamiento, o aplicada a todo el dominio en lugar de a una sola carpeta.
• Rutas protegidas de CSS, JavaScript o imágenes, que rompen el renderizado de la página para los rastreadores aunque el HTML sea público.
• La “protección de vistas previas” del hosting o de la plataforma, que cubre un dominio que querías hacer público.

Impacto en el SEO

Googlebot no inicia sesión. Una URL que devuelve 401 no se puede indexar y, si estaba indexada, se elimina. Search Console la notifica como “Bloqueada debido a una solicitud no autorizada (401)”. La documentación de Google sobre códigos de estado advierte además de que no se use el 401 ni el 403 para limitar la frecuencia de rastreo, porque esos códigos no la reducen. Para eso, devuelve 429 o 503 durante un periodo corto.

Usado a propósito, el 401 es útil: la protección con contraseña es la forma más fiable de mantener una copia de staging fuera de Google. Un bloqueo en robots.txt por sí solo no impide que una URL enlazada se indexe sin su contenido, y un noindex copiado de staging a producción puede borrar un sitio en producción de los resultados.

Cómo solucionar o configurar un 401

Quitar una protección no deseada

Revisa los archivos .htaccess de la raíz del sitio y de las carpetas superiores en busca de líneas AuthType, la configuración de Nginx en busca de auth_basic y el panel de tu hosting en busca de protección por contraseña o de vistas previas. Asegúrate de que las carpetas de recursos no queden cubiertas.

Proteger el staging correctamente

# Apache (.htaccess)
AuthType Basic
AuthName "Staging"
AuthUserFile /etc/apache2/.htpasswd
Require valid-user

# Nginx
location / {
    auth_basic "Staging";
    auth_basic_user_file /etc/nginx/.htpasswd;
}

# crea el archivo de contraseñas
htpasswd -c /etc/nginx/.htpasswd editor

En las API, envía un desafío WWW-Authenticate: Bearer con tu 401 para que los clientes sepan que deben renovar su token, y usa 403 cuando el token es válido pero no tiene el permiso necesario.

Cómo comprobarlo

Pasa las URL públicas por el comprobador de códigos de estado HTTP después de cada lanzamiento o migración; todo lo que devuelva 401 es invisible para los buscadores. El comprobador de cabeceras HTTP muestra el desafío WWW-Authenticate, que te dice qué capa está pidiendo las credenciales.

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="Staging", charset="UTF-8"
Content-Type: text/html; charset=utf-8
Cache-Control: no-store

Preguntas frecuentes