Erreur 401 Unauthorized : la différence avec la 403

Erreur 401 Unauthorized : ce qu’elle signifie

Une erreur 401 Unauthorized signifie que le serveur exige une authentification que le visiteur n’a pas fournie ou qui est invalide : mot de passe de dossier, jeton d’API ou session expirée. La 403 Forbidden refuse l’accès même quand l’identité est connue : se reconnecter n’y change rien.

Bonne nouvelle : une 401 est rarement un bug. Dans la plupart des cas, quelqu’un a mis une protection en place (volontairement ou via un plugin), et il suffit de comprendre laquelle. Le nom « Unauthorized » est trompeur : il désigne un défaut d’authentification, pas d’autorisation.

L’authentification consiste à prouver qui l’on est (mot de passe, jeton, session). L’autorisation désigne le droit de faire une action une fois l’identité connue. La 401 touche la première, la 403 la seconde. Pour la 403, voir notre guide sur l’erreur 403 sur WordPress.

401 ou 403 : le tableau pour trancher

Selon la documentation de MDN sur le code 401, une 401 est envoyée avec un en-tête qui précise la méthode d’authentification attendue, alors qu’une 403 est renvoyée quand les identifiants sont valides mais que le client n’a pas la permission.

	401 Unauthorized	403 Forbidden
Message du serveur	« Je ne sais pas qui vous êtes »	« Je sais qui vous êtes, la réponse est non »
Se reconnecter règle le problème ?	Oui, avec les bons identifiants	Non
En-tête WWW-Authenticate	Présent	Absent en général
Causes typiques	Mot de passe de dossier, jeton absent ou expiré	Permissions de fichiers, règle IP, pare-feu

Pourquoi un site affiche une 401

Un dossier ou un site protégé par mot de passe : c’est la cause numéro un, surtout sur les préproductions (sites de test).
Une API appelée sans jeton, ou avec un jeton expiré ou invalide.
Une extension de sécurité qui protège la connexion, l’administration ou l’API.
Des cookies ou une session périmés côté visiteur.
Un serveur d’authentification mal configuré, côté développeur.

1. Lire l’en-tête avant de toucher à quoi que ce soit

WWW-Authenticate est l’en-tête de réponse qui indique la méthode d’authentification attendue par le serveur. Le lire évite de deviner. Selon MDN, un serveur en 401 renvoie au moins un challenge de ce type.

Ouvrez les outils de développement du navigateur (F12), onglet Réseau.
Rechargez la page, cliquez sur la requête en 401.
Dans En-têtes de réponse, lisez WWW-Authenticate.

Si vous voyez Basic realm="...", c’est une protection par mot de passe de dossier. Si vous voyez Bearer, c’est une API qui attend un jeton. Si l’en-tête est absent et que vous obtenez une page de connexion d’extension, la cause est un plugin.

2. Côté visiteur : identifiants et cookies

C’est le correctif le plus rapide, et il suffit souvent.

Ressaisissez l’identifiant et le mot de passe, sans espace parasite en copiant-collant.
Vérifiez l’URL : un identifiant valide pour staging.site.fr ne marche pas sur www.site.fr.
Supprimez les cookies du site, ou testez en navigation privée.

Si la 401 disparaît en navigation privée, le problème venait d’une session périmée. Si elle persiste, passez à l’étape suivante.

3. Dossier protégé : vérifier le .htaccess et le .htpasswd

L’authentification Basic consiste à envoyer un identifiant et un mot de passe encodés dans chaque requête, après une boîte de dialogue affichée par le navigateur. Sur Apache, elle se configure dans le .htaccess :

AuthType Basic
AuthName "Zone privée"
AuthUserFile /chemin/absolu/.htpasswd
Require valid-user

Selon la documentation Apache, AuthName est le texte affiché dans la boîte de dialogue, et le .htaccess n’est pris en compte que si AllowOverride l’autorise. Page ancienne, mais le mécanisme reste valable sur Apache 2.4.

Points à contrôler :

Le chemin de AuthUserFile doit être absolu et exact. Vérifiez-le avec la commande pwd en SSH (guide DreamHost).
Le fichier .htpasswd doit exister et contenir l’utilisateur (htpasswd -c .htpasswd utilisateur le crée).
Sur un sous-répertoire WordPress, ajoutez ErrorDocument 401 default. Sans cela, les règles de réécriture de WordPress peuvent transformer la 401 en 404.

Avant de retirer cette protection, demandez-vous pourquoi elle est là. Sur une préproduction, elle empêche le public et les moteurs de voir un site inachevé ou en doublon du site réel. Corrigez les identifiants ou communiquez-les, ne supprimez pas le verrou « pour voir ». Si vous reprenez un projet, les 7 accès à exiger de votre agence incluent ces identifiants.

4. Extension de sécurité : désactiver une à une

Un plugin de sécurité peut renvoyer une 401 sur la page de connexion, l’administration ou l’API REST. Le guide Hostinger recommande de désactiver plugins, modules et thèmes un par un pour repérer le coupable.

Renommez wp-content/plugins en plugins-off par FTP (tout est désactivé d’un coup).
Rechargez le site. Si la 401 disparaît, un plugin est en cause.
Remettez le nom d’origine, puis réactivez les plugins un par un.

Une fois le plugin identifié, ne le supprimez pas à la légère : ouvrez ses réglages (règles de connexion, protection de l’API). La méthode complète est dans notre article sur le conflit de plugins WordPress, et le rôle de l’API dans l’API REST de WordPress.

5. API : renvoyer un jeton valide

Selon MDN, une API sans jeton répond 401 Unauthorized avec WWW-Authenticate: Bearer. Les causes habituelles : en-tête Authorization manquant, jeton expiré, jeton d’un autre environnement.

401 : rafraîchissez le jeton, puis réessayez la requête.
403 : ne réessayez pas avec les mêmes identifiants, la permission manque.

6. Pourquoi Google ne peut pas indexer une page en 401

Googlebot est le robot d’exploration de Google, et il ne saisit pas de mot de passe. Selon la documentation de Google, les URL en 4xx ne sont pas indexées, et celles déjà indexées en sortent source : Google Search Central, 2026. Tous les 4xx sauf le 429 sont traités de la même façon : la 401 compte comme une 403 ou une 404, et le contenu reçu est ignoré.

Dans la Search Console, le rapport d’indexation des pages affiche alors « Blocked due to unauthorized request (401) ». Deux remèdes existent :

Retirer l’authentification sur les pages qui doivent être indexées.
Autoriser Googlebot après avoir vérifié son identité, jamais sur la seule foi de son nom dans le user-agent.

Si la page est volontairement privée (préproduction, espace client), laissez la 401 : c’est le comportement voulu. Ne l’utilisez pas pour freiner le crawl : Google réserve ce rôle au 429 (voir erreur 429 sur WordPress) ou au 503.

Tableau récapitulatif

Cause	Signe	Solution
Mot de passe de dossier	`WWW-Authenticate: Basic`	Bons identifiants, ou corriger `.htaccess` et chemin du `.htpasswd`
Session périmée	401 en direct, pas en navigation privée	Vider les cookies
Plugin de sécurité	401 sur login ou API	Désactivation une à une, réglage du plugin
API sans jeton	`WWW-Authenticate: Bearer`	Envoyer un jeton valide
Page à indexer en 401	Statut dans la Search Console	Retirer l’authentification ou vérifier Googlebot

FAQ

La 401 est-elle une faille de sécurité ?

Non, c’est généralement le signe inverse : une protection fonctionne. Le problème apparaît quand elle bloque des visiteurs ou Googlebot qui devraient accéder à la page.

Pourquoi ma 401 devient une 404 sur WordPress ?

Les règles de réécriture de WordPress peuvent intercepter la 401 d’un sous-répertoire protégé. Ajoutez ErrorDocument 401 default dans le .htaccess concerné.

Une 401 fait-elle perdre du SEO ?

Seulement si elle touche des pages publiques. Les URL en 401 sont ignorées par Google, donc une page indexée qui passe en 401 sort de l’index.

Quelle est la différence entre 401 et 403 en une phrase ?

La 401 dit « identifiez-vous », la 403 dit « même identifié, vous n’avez pas le droit ».

Quand passer la main à un pro

Faites-vous aider si la 401 touche des pages publiques que Google doit voir, si vous ne savez pas qui a posé la protection, ou si votre site est derrière un pare-feu dont vous n’avez pas les accès. Ce sont des protections qu’on ne retire pas au hasard. Une maintenance régulière évite ces erreurs : on sait qui a verrouillé quoi, et pourquoi.

Ce problème, Peechy s'en occupe

Plutôt que de tout gérer seul, confiez votre site à une agence qui s'occupe de tout, hébergement, sécurité, maintenance et corrections. Encore plus simple en abonnement : on règle les soucis avant même que vous les remarquiez.

Confier mon site à Peechy