Langues

403 Forbidden — réponse HTTP

Ce qu'est une erreur HTTP 403, la façon dont Google la traite (blocage proche d'un noindex), ses causes courantes (contrôles d'accès, blocage de robots, permissions mal configurées) et comment corriger les 403 en SEO.

Première publication : 27 juin 2026 · Dernière mise à jour : 9 août 2026 · Advanced
Langues
AIRédigé parAI v2
1 indice probant sur cette page

Un 403 Forbidden signifie que le serveur a compris la requête mais refuse de la satisfaire : l'accès est refusé, et ce refus n'implique pas nécessairement des identifiants (le serveur peut même envoyer 404 pour masquer l'existence d'une ressource interdite). Ce n'est ni un 404 (« rien ici »), ni un 401 (« authentifiez-vous d'abord ») ; le 403 est un refus actif. En SEO, un 403 persistant sur une page qui devrait être publique la tient hors de l'index Google : le résultat ressemble à noindex, mais le mécanisme est différent, puisque Google ne peut lire aucun contenu d'une réponse 4xx. Googlebot n'envoyant jamais d'identifiants, un 403 qui lui est renvoyé mérite une enquête, sans supposer qu'il est forcément involontaire : filtre de bots CDN/WAF, blocage d'IP ou d'agent utilisateur, extension de sécurité, .htaccess ou permissions sont des pistes, sans données fiables sur leur fréquence. N'utilisez jamais 403 pour ralentir le crawl (429/503 servent à cela pendant une courte période). Vérifiez d'abord l'intention : un 403 sur un staging, une administration ou un contenu protégé peut être correct. Enfin, un 403 sur robots.txt est traité de manière permissive, alors qu'un 403 sur une page constitue un blocage dur.

En bref — 403 signifie que le serveur a compris la requête mais la refuse pour une question d’accès. Le code se distingue de 404 (ressource absente) et de 401 (défi d’authentification). Pour l’indexation, le résultat ressemble à noindex : Google n’indexe pas une URL 403 et retire une URL déjà indexée, mais le mécanisme est un blocage serveur/CDN/WAF, pas une balise HTML. Googlebot n’envoie jamais de credentials, donc un 403 qui touche une page publique doit être vérifié. 403 ne réduit pas le crawl du site ; n’en faites jamais un outil de limitation (429/503 sont les codes temporaires adaptés). Enfin, 403 sur robots.txt est permissif, alors que 403 sur une page est un blocage dur.

403, 401 et 404 : poser le bon modèle mental

Ces trois codes sont souvent confondus, alors que leur différence guide tout le diagnostic. La définition de base vient de la RFC 9110 §15.5.4 : le serveur a compris la requête et refuse de la satisfaire. Plusieurs nuances sont importantes :

  • Le refus ne dépend pas obligatoirement des identifiants. La RFC autorise 403 pour des raisons étrangères à l’authentification. Le code ne prouve donc ni que le demandeur est connu, ni que des credentials ont été utilisés.
  • 403 n’a pas à révéler l’existence de la ressource. Un serveur qui veut cacher qu’une ressource interdite existe peut répondre 404. Inversement, un 404 ne signifie pas toujours qu’il n’y a jamais rien eu.
  • 401 et 403 ne sont pas seulement « faible » contre « fort ». 401 est un défi d’authentification et doit être accompagné de WWW-Authenticate. 403 n’impose pas cet en-tête et ne promet pas qu’une nouvelle authentification changera le résultat. MDN le résume ainsi : l’authentification ou sa répétition ne change rien lorsque l’échec est lié à la logique de l’application, par exemple des permissions insuffisantes. Evidence for this claim A 403 response means the server understood the request but refuses to fulfill it, and authenticating does not necessarily make a difference. Scope: RFC 9110 defines the protocol semantics; it does not identify the application, firewall, or policy responsible for a specific response. Confidence: high · Verified: IETF: RFC 9110 §15.5.4 — 403 Forbidden
  • 404 Not Found, dans le cas ordinaire, signifie que la ressource n’existe pas, sous réserve du cas de dissimulation décrit plus haut.

C’est pourquoi un 403 destiné à Googlebot mérite un second regard. Un 401 sur une zone réservée aux membres peut être cohérent : la connexion est requise. Un 403 sur une page censée être publique indique qu’une règle a refusé le demandeur ; vérifiez toutefois l’intention avant de qualifier cela de bug.

Comment Google traite un 403 : résultat proche de noindex, mécanisme différent

Google classe 403 dans la famille 4xx. La documentation Search Central indique que Google n’indexe pas les URL qui renvoient un statut 4xx et retire de l’index celles qui y figuraient déjà. Elle précise aussi que tous les 4xx, sauf 429, sont traités de la même façon : les robots signalent au système suivant que le contenu n’existe pas. La fréquence de crawl d’une URL connue peut diminuer progressivement lorsqu’elle continue à renvoyer 4xx ; c’est un effet propre à cette URL, distinct du rythme de crawl global du site. 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 indexing outcome for persistent 403 responses, not the article's analogy to noindex. Confidence: high · Verified: Google: How HTTP status codes affect Google's crawlers

Le résultat ressemble donc à noindex, mais le chemin est vraiment différent. Une balise noindex doit être récupérée et lue dans le HTML ; 403 empêche toute lecture. Deux mécanismes différents aboutissent à la même absence dans les résultats. Dans mon guide des codes de statut HTTP, je décris ainsi 403 comme un client connu qui n’a pas les droits d’accès, tout en précisant que « connu » est le raccourci du rapport Google, pas la preuve d’une requête authentifiée.

Pourquoi un 403 à Googlebot mérite une enquête

L’aide Google sur l’indexation explique qu’un 403 peut signifier que l’agent a fourni des credentials sans obtenir l’accès, alors que Googlebot n’en fournit jamais. Cette explication concerne une page que Search Console suppose destinée à l’indexation ; elle ne signifie pas que tout 403 envoyé à Googlebot est forcément une erreur. Un serveur peut décider légitimement que Googlebot, comme n’importe quel autre client, n’a pas accès à une ressource.

Avant de chercher une correction, posez la question décisive : la page doit-elle être publique et indexée ? Pour un staging, une administration, un paywall ou un contenu protégé, le 403 est correct. Si la page doit être publique, une règle a probablement bloqué le mauvais demandeur : WAF, plage IP, extension de sécurité ou politique par défaut. Je ne dispose pas de données fiables sur la cause la plus fréquente ; vérifiez donc les hypothèses au lieu d’en faire un diagnostic. Google conseille de laisser entrer les utilisateurs non connectés ou d’autoriser Googlebot explicitement, après avoir vérifié son identité.

403 ne limite pas le rythme de crawl

On voit parfois 403 ou 404 utilisés pour demander à Googlebot de ralentir un serveur en difficulté. Il ne faut pas le faire. Google précise que 401 et 403 ne limitent pas le crawl et que les 4xx, sauf 429, n’ont aucun effet sur le rythme global. La fréquence d’une URL connue peut baisser lorsqu’elle renvoie longtemps 4xx, mais cela ne constitue pas un limiteur de site.

Gary Illyes a rappelé : “All 4xx HTTP status codes (again, except 429) will cause your content to be removed from Google Search.” (traduction) Tous les codes d’état HTTP 4xx, sauf 429, entraîneront la suppression de votre contenu de Google Search : Don’t 404 my yum. Pour une urgence courte, 500, 503 ou 429 sont les signaux appropriés, pendant des heures plutôt que des jours. Des 5xx persistants peuvent eux aussi faire disparaître des pages ; la durée et le périmètre comptent autant que le code choisi. Un article de Barry Schwartz rapporte le cas de sites ayant perdu de nombreuses pages après avoir servi 403 au lieu de 503 : 503 est compris comme temporaire, 403 comme un blocage qui mène à la désindexation.

Le cas particulier de robots.txt : 403 est permissif

Un 403 sur une page bloque la ressource. Mais un 403 sur le fichier robots.txt est traité à l’inverse. La spécification Google indique que les robots traitent les 4xx, sauf 429, comme si aucun robots.txt valide n’existait ; Google suppose alors qu’il n’y a aucune restriction de crawl. Evidence for this claim A 403 on `/robots.txt` is handled differently from a 403 on a page: Google treats a non-429 4xx robots response as if no valid robots file exists and assumes no restrictions from that file. Scope: robots.txt fetch only Confidence: high · Verified: How Google interprets the robots.txt specification

Si un pare-feu commence à renvoyer 403 pour robots.txt, Google peut donc explorer des chemins que vous vouliez interdire. Ne confondez pas « robots.txt renvoie 403 » avec « mes pages renvoient 403 » : les effets sont opposés et le mauvais diagnostic vous ferait corriger la mauvaise couche.

Comment Bing traite 403

La documentation publique de Bing est moins détaillée sur 403 que celle de Google ; restons donc précis. Bingbot peut être bloqué par robots.txt, une règle IP ou d’agent utilisateur du serveur, ou un WAF. Bing Webmaster Tools présente les erreurs dans ses alertes de crawl. Dans les deux moteurs, autorisez le robot vérifié dans la couche de sécurité et vérifiez son identité par plages IP publiées et DNS inverse, plutôt que de faire confiance au seul agent utilisateur. Corriger Googlebot ne garantit pas que Bingbot passe ; contrôlez les deux outils après un changement WAF.

Causes fréquentes : aucune hiérarchie fiable

Protection anti-bots CDN/WAF. C’est une bonne première piste en 2026, sans que je puisse affirmer qu’elle soit la cause la plus courante. Bot Fight Mode et Super Bot Fight Mode de Cloudflare, les règles gérées WAF et les règles personnalisées peuvent renvoyer 403 à Googlebot ou Bingbot par erreur. Le blocage se trouve à la périphérie : l’origine et le CMS paraissent sains tandis que Search Console signale 403. Cherchez le robot dans les Security Events du CDN.

2. Blocage au niveau de l’hébergeur. Une règle par agent utilisateur, une limite par défaut ou un blocage de plage IP peut toucher les robots légitimes.

3. Mauvaise configuration de robots.txt ou .htaccess. Un Deny from isolé ou une réécriture incorrecte peut interdire tout un répertoire ; gardez en tête le cas particulier de robots.txt.

4. Extensions de sécurité. Wordfence, iThemes Security et des outils comparables peuvent appliquer des réglages anti-bots trop agressifs.

5. Connexion et contenu authentifié. Googlebot ne se connecte pas, et le 403 peut être parfaitement intentionnel pour une zone protégée.

6. Permissions de fichiers ou de répertoires. Sur WordPress, Rank Math documente notamment 755/750 pour les répertoires, 644/640 pour les fichiers et 400/440 pour wp-config.php, ainsi que la régénération de .htaccess depuis les permaliens.

7. Malware ou site compromis qui injecte une règle d’accès, et 8. blocage géographique qui englobe sans le vouloir la plage IP d’un robot.

Diagnostiquer un 403 : isoler la couche émettrice

Beaucoup de guides conseillent immédiatement de désactiver les extensions. La vraie compétence consiste à trouver la couche qui refuse : CDN, WAF, application, hébergeur, permissions, géographie ou cache. Le code seul ne suffit pas ; cherchez des en-têtes, journaux ou événements de sécurité qui le prouvent.

  1. Dans GSC, ouvrez Indexation des pages → Bloquée en raison d’un accès interdit (403), puis Inspection de l’URL → Tester l’URL publiée.
  2. Reproduisez la réponse avec curl et plusieurs agents utilisateurs : 
    # Client générique
curl -I https://example.com/page/
# Agent Googlebot déclaré (teste les règles fondées sur l'UA)
curl -I -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://example.com/page/
    Si un navigateur obtient 200 et l’UA Googlebot 403, une règle d’agent utilisateur est probablement en cause.
  3. Vérifiez le statut de robots.txt lui-même : un 403 à cet endroit est un autre problème.
  4. Consultez les Security Events du CDN/WAF et cherchez le robot bloqué.
  5. Vérifiez qu’il s’agit bien de Googlebot par DNS inverse puis direct, pas seulement par sa chaîne UA, qui est facile à usurper.
  6. Isolez la règle en désactivant les contrôles par étapes, un réglage WAF ou une extension à la fois, jusqu’à disparition du 403.

Corriger : autoriser les robots de la bonne manière

La correction tentante consiste à autoriser la chaîne d’agent utilisateur Googlebot. Ne vous arrêtez pas là : elle est facile à usurper et créerait une faille. Vérifiez plutôt les points suivants :

  • Confirmez le robot par DNS inverse puis direct ou par les plages IP publiées par Google et Bing.
  • Utilisez, si le CDN/WAF le propose, sa catégorie de robots vérifiés plutôt qu’une règle basée uniquement sur l’UA.
  • Corrigez la règle précise (règle WAF, règle pare-feu ou option d’une extension), au lieu de désactiver toute la sécurité.
  • Lancez Valider la correction dans le rapport GSC et, si nécessaire, demandez une nouvelle exploration avec Inspection de l’URL.

Quand un 403 est parfaitement correct

Un 403 n’est pas toujours un bug. Il est approprié pour un staging, une administration, un espace privé de membres ou un contenu payant/protégé qui ne doit jamais être indexé. Dans un audit Ahrefs ou Screaming Frog, ce 403 ne nécessite pas de correction ; il faut agir seulement lorsqu’une page publique et indexable est bloquée par accident. Vérifiez toujours l’intention avant de « résoudre » chaque 403 du rapport.

Pour la famille complète des codes, consultez mon guide des codes HTTP et de leur impact SEO, ainsi que les articles frères 401 Unauthorized et 404 Not Found.

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.