401 Unauthorized : authentification requise

401 Unauthorized signifie que la requête nécessite une authentification valide et n’en avait pas. Malgré son nom, il concerne l’authentification (qui vous êtes), pas les droits d’accès : envoyez des identifiants valides et le serveur vous laissera peut-être entrer. Quand le serveur sait qui vous êtes et refuse quand même, c’est 403 Forbidden.

Ce qu’exige la norme

La RFC 9110, section 15.5.2 précise qu’une réponse 401 doit inclure un en-tête WWW-Authenticate avec au moins un défi d’authentification, qui indique au client comment s’authentifier, par exemple Basic ou Bearer. Si la requête contenait déjà des identifiants, le 401 signifie qu’ils ont été refusés. Face à un défi Basic, les navigateurs affichent leur invite de connexion intégrée.

Causes courantes

• L’authentification HTTP Basic sur un site de préproduction, une zone d’administration ou un répertoire (.htpasswd).
• Des jetons d’API expirés, absents ou mal formés (Authorization: Bearer …).
• Une protection laissée active après le lancement, ou appliquée à tout un domaine au lieu d’un seul dossier.
• Des chemins de CSS, JavaScript ou images protégés, qui empêchent le rendu de la page par les robots même quand le HTML est public.
• Une « protection des aperçus » de l’hébergeur ou de la plateforme qui couvre un domaine que vous vouliez rendre public.

Impact SEO

Googlebot ne se connecte pas. Une URL qui renvoie 401 ne peut pas être indexée et, si elle l’était, elle est supprimée. La Search Console la signale comme « Bloquée en raison d’une requête non autorisée (401) ». La documentation de Google sur les codes de statut déconseille aussi d’utiliser 401 ou 403 pour limiter la fréquence de crawl, car ces codes ne ralentissent pas l’exploration. Pour cela, renvoyez brièvement 429 ou 503.

Utilisé volontairement, le 401 est précieux : la protection par mot de passe est le moyen le plus fiable de tenir une copie de préproduction hors de Google. Une interdiction dans robots.txt n’empêche pas à elle seule qu’une URL qui reçoit des liens soit indexée sans son contenu, et un noindex copié de la préproduction vers la production peut effacer un site en ligne des résultats.

Comment corriger ou mettre en place un 401

Supprimer une protection indésirable

Vérifiez les fichiers .htaccess à la racine du site et dans les dossiers parents à la recherche de lignes AuthType, votre configuration Nginx pour auth_basic, et le tableau de bord de votre hébergeur pour une protection par mot de passe ou des aperçus. Assurez-vous que les dossiers de ressources ne sont pas couverts.

Protéger correctement la préproduction

# 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;
}

# créer le fichier de mots de passe
htpasswd -c /etc/nginx/.htpasswd editor

Pour les API, envoyez un défi WWW-Authenticate: Bearer avec votre 401 afin que les clients sachent qu’ils doivent renouveler leur jeton, et utilisez 403 quand le jeton est valide mais n’a pas la permission requise.

Comment vérifier

Passez vos URL publiques dans le vérificateur de statut HTTP après chaque lancement ou migration ; tout ce qui renvoie 401 est invisible pour les moteurs de recherche. Le vérificateur d’en-têtes HTTP affiche le défi WWW-Authenticate, qui indique quelle couche réclame des identifiants.

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

Questions fréquentes