Bloquée en raison d'une interdiction d'accès (403) : voulu ou accidentel
Le code 403 ne prête pas à confusion : accès refusé, le serveur a fermé la porte. C'est précisément ce qui rend trompeur le statut « Bloquée en raison d'une interdiction d'accès (403) » du rapport « Indexation des pages » de la Google Search Console. Le réflexe naturel, ouvrir l'URL dans un navigateur, affiche une page parfaitement normale. De quoi croire à une fausse alerte.
Mais ce test ne prouve rien. Le 403 ne concerne pas l'internaute, il concerne Googlebot : le serveur affiche la page au visiteur humain et la refuse au robot. Ce décalage, aucun navigateur ne le montre.
D'où la vraie question : ce 403 est-il délibéré ou subi ? Qui ferme la porte à Googlebot ? Et comment savoir ce que le robot reçoit vraiment, quand l'écran, lui, affiche tout sans accroc ? La réponse ne se lit pas à l'écran, mais dans le code servi à Googlebot.
« Bloquée en raison d'une interdiction d'accès (403) » : ce que dit Google
Ce statut signifie que Googlebot a demandé l'URL et que votre serveur a répondu par un code HTTP 403 (accès interdit). Google en conclut que le contenu n'existe pas et retire l'URL de l'index s'il l'avait déjà indexée. Ce n'est pas une directive que vous donnez, comme un robots.txt : c'est votre serveur qui refuse activement l'accès à Googlebot.
C'est la différence de fond avec un blocage par robots.txt. Le robots.txt est une consigne que vous écrivez et que Google respecte de bonne grâce : « n'explore pas ces URLs ». Le 403, lui, est une réponse du serveur au moment où Googlebot frappe à la porte. Google ne décide rien : il subit le refus, en tire la conclusion logique (« contenu inaccessible, donc inexistant ») et désindexe.
La documentation de Google ajoute une nuance qui change la lecture du problème : un 403 répondu à Googlebot est, à ses yeux, presque toujours une erreur de configuration. Le code 403 est censé signifier « vous avez fourni des identifiants, mais l'accès vous est refusé ». Or Googlebot ne fournit jamais d'identifiants. Lui renvoyer un 403 revient donc à utiliser le code à contre-emploi : Google traite tous les codes 4xx (sauf le 429) de la même manière, en considérant que la page n'existe pas. Autrement dit, même un 403 que vous croyez « voulu » est, du point de vue de Google, un mauvais usage du protocole.
403 voulu ou accidentel : le tri d'abord
Avant toute correction, une seule question tranche : cette URL doit-elle apparaître dans Google ? Si oui, le 403 est un accident à réparer en urgence. Si non, le 403 fait son travail (même si ce n'est pas l'outil le plus propre pour le faire). Le diagnostic technique vient après ce tri d'intention, jamais avant.
Cas A : le 403 est voulu. L'URL est une page d'administration, un back-office, un environnement de préproduction, un espace réservé aux membres connectés. Vous l'avez fermée à tout ce qui n'est pas authentifié, Googlebot compris. La voir listée en « Bloquée en raison d'une interdiction d'accès (403) » est cohérent avec votre intention : cette page n'a aucune raison d'être dans Google. Il n'y a pas d'urgence — tout au plus un nettoyage à prévoir (voir plus bas, le 403 n'est pas l'outil idéal pour cela).
Cas B : le 403 est accidentel. L'URL est une page publique, censée se positionner et recevoir du trafic : une fiche produit, un article, une page de catégorie. Et pourtant le serveur oppose un 403 à Googlebot. C'est une urgence : tant que le refus tient, la page ne peut pas être indexée, et si elle l'était, elle sort de l'index. Vous perdez du trafic sur une page que vous vouliez voir dans Google.
Tout le travail consiste à séparer A de B. Une page d'admin en 403, c'est sain. Une fiche produit en 403, c'est une fuite de trafic. Et le cas B est d'autant plus sournois qu'il est souvent invisible depuis votre poste.
Le cas insidieux : 200 pour vous, 403 pour Googlebot
C'est le scénario le plus piégeux du cas B : la page s'ouvre parfaitement dans votre navigateur (code 200), mais Googlebot, lui, reçoit un 403. Un pare-feu applicatif (WAF), un mode de protection anti-bots ou un service anti-DDoS sert le contenu à un visiteur humain et oppose un refus à ce qu'il prend pour un robot indésirable. Votre test navigateur ne le verra jamais.
La raison est simple : ces dispositifs décident d'autoriser ou de bloquer en fonction de qui frappe à la porte. Un humain avec un navigateur classique, une adresse IP résidentielle et un comportement « normal » passe. Une requête identifiée comme un robot peut être filtrée — et c'est là le drame, car Googlebot est un robot. Le système anti-bots ne fait pas toujours la différence entre Googlebot et un scraper malveillant, et le range dans le même sac. Vous voyez 200 ; Googlebot voit 403.
C'est pourquoi ouvrir l'URL dans votre navigateur ne prouve rien : vous testez l'accès humain, pas l'accès Googlebot. Le seul verdict qui compte est le code HTTP que reçoit réellement le robot de Google. Ce mécanisme est cousin d'un autre piège où la page « s'ouvre » sans pour autant satisfaire Google : voir Soft 404, où le serveur renvoie un 200 sur une page vide ou en erreur.
💡 Vous soupçonnez un 403 servi à Googlebot mais invisible chez vous ? IndexProbe inspecte votre liste d'URLs via l'API de la Search Console et vous donne, par page, le code HTTP que Google a réellement reçu. Tester IndexProbe en accès anticipé →
Les causes côté serveur
Quand le 403 est accidentel (cas B), la cause se trouve presque toujours dans une couche de sécurité ou de configuration qui prend Googlebot pour une menace. Voici les mécanismes les plus fréquents, classés par origine.
- WAF et anti-bots, faux positifs. Cloudflare (Bot Fight Mode, règles WAF), Sucuri, Imperva, AWS WAF et consorts bloquent les requêtes jugées suspectes. Une règle trop agressive attrape Googlebot avec les scrapers et lui renvoie un 403.
- Limitation de débit (rate limiting). Le serveur plafonne le nombre de requêtes par IP sur un intervalle donné. Si Googlebot crawle activement, il peut franchir le seuil et se voir opposer un 403. Google déconseille d'ailleurs explicitement d'utiliser le 403 pour brider le crawl : ce code n'a aucun effet sur la fréquence de passage, contrairement au 429.
- Blocage par IP ou par géolocalisation. Une règle qui interdit certaines plages d'adresses, ou tout le trafic hors d'un pays donné, peut couper l'accès aux IP de Googlebot.
- Filtrage par user-agent. Une configuration qui bloque les requêtes selon leur signature peut viser, par erreur ou par excès de zèle, l'agent
Googlebot. - Permissions de fichiers et
.htaccess. Un mauvais réglage de droits sur un dossier, ou une directiveDeny fromdans un.htaccess, renvoie un 403 sur tout ce qu'il couvre. - Hébergement mutualisé. Sur un hébergement partagé, des protections mutualisées (limites de ressources, anti-bots du provider) peuvent bloquer Googlebot sans que vous ayez la main dessus.
- Plugins et modules anti-crawl. Certaines extensions de sécurité (notamment sur WordPress) ajoutent leurs propres règles de blocage, parfois actives par défaut.
Le fil rouge : une couche de votre infrastructure décide que Googlebot n'a pas le droit d'entrer. Reste à savoir laquelle, et sur quelles URLs elle frappe.
403 vs 401 vs 404 vs 5xx vs robots.txt : la grille
Cinq façons de « bloquer » une page se confondent sans cesse, alors qu'elles n'envoient pas du tout le même signal à Google. La distinction tient à qui renvoie quoi, et à ce que Google en conclut. Voici la grille de lecture.
| Code / statut | Qui renvoie quoi | Ce que Google en conclut | Indexation possible ? | Quand l'utiliser légitimement |
|---|---|---|---|---|
| 403 (interdiction d'accès) | Le serveur refuse l'accès à Googlebot | Contenu inaccessible → inexistant, retrait de l'index | Non | Jamais idéal face à Googlebot (Google le voit comme une erreur) ; à réserver à un vrai refus côté serveur |
| 401 (authentification requise) | Le serveur exige des identifiants | Contenu protégé → traité comme inexistant, retrait de l'index | Non | Vrai contenu derrière authentification (membres, intranet) |
| 404 (introuvable) | Le serveur indique que la page n'existe pas | Page inexistante, retrait de l'index | Non | Page réellement supprimée, sans remplacement |
| 5xx (erreur serveur) | Le serveur plante ou est indisponible | Problème temporaire, Google réessaie avant de désindexer | Non (tant que l'erreur dure) | Jamais voulu : à corriger (voir Erreur serveur (5xx)) |
| Bloquée par robots.txt | Vous interdisez le crawl via une directive | Consigne respectée : page non crawlée | Possible sans crawl (indexée via liens externes) | Empêcher le crawl de pages sans intérêt (admin, filtres) |
La différence décisive : le 403 et le 401 sont des refus actifs du serveur, que Google traite comme un signal « cette page n'existe pas ». Le robots.txt, lui, est une consigne que Google respecte sans pour autant conclure à l'inexistence de la page. Confondre les deux mène à la mauvaise correction — et, pour le 5xx, à paniquer là où Google patiente encore.
Identifier les 403 à l'échelle
L'outil d'Inspection d'URL de la Search Console donne le code HTTP vu par Googlebot, mais une URL à la fois : vous inspectez, vous lisez le verdict, vous passez à la suivante. Pour repérer, sur des centaines d'URLs, lesquelles renvoient un 403 à Google et lesquelles tombent dans le cas B, l'inspection manuelle ne tient pas la distance.
C'est le mur que fait sauter IndexProbe : la version en masse de l'outil d'inspection d'URL de Google. Il interroge l'API officielle de la Search Console pour inspecter, en une seule analyse, la liste d'URLs que vous lui fournissez (import CSV, sitemap, copier-coller) ou que vous constituez depuis votre Search Console. Pour chaque page, il renvoie le « Statut du Crawl de Google » : le code HTTP que Googlebot a réellement reçu, 403 compris. IndexProbe n'explore pas votre site pour découvrir des URLs : il inspecte celles que vous lui donnez, et celles-là seulement.
L'intérêt décisif : recouper le code vu par Googlebot avec le code vu par votre navigateur. Un 403 côté Googlebot sur une URL qui renvoie 200 dans votre navigateur, c'est la signature exacte du 403 ciblé — celui qu'un WAF oppose au robot tout en servant la page aux humains, et qu'aucun test navigateur ne révèle.
Ce que vous tirez de l'analyse dépend de la liste que vous apportez.
- Une sélection de pages stratégiques (vos pages clés, votre sitemap des pages à indexer). Toute page importante qui ressort en 403 est un cas B immédiat : une page que vous vouliez voir dans Google, fermée à Googlebot par accident. Vous la repérez sans rien présumer du reste du site.
- Un export complet de vos URLs (sitemap entier, export de crawl). La segmentation par type de pages montre où les 403 se concentrent : un pic sur un segment public (vos produits, votre blog) trahit un blocage accidentel, alors qu'un 403 massif sur l'admin ou la préproduction est cohérent.
Corriger un 403 accidentel
Pour une page du cas B, l'objectif est de rouvrir l'accès à Googlebot sans pour autant baisser la garde sur la sécurité du site. La marche à suivre :
- Lisez les logs de votre WAF ou CDN. Cloudflare, Sucuri, Imperva et la plupart des pare-feux journalisent les requêtes bloquées. Cherchez les refus opposés à Googlebot et identifiez la règle responsable.
- Créez une exception ciblée pour Googlebot. Plutôt que de désactiver toute la protection, ajoutez une règle qui laisse passer Googlebot. C'est la correction chirurgicale : vous rouvrez l'accès au robot de Google sans ouvrir la porte à tout le monde.
- Vérifiez l'identité réelle de Googlebot — c'est le point critique. N'autorisez jamais sur le seul user-agent : n'importe qui peut se déclarer « Googlebot ». Un filtrage naïf par nom d'agent crée une faille de sécurité béante. La méthode officielle de Google est la vérification par DNS inverse (le
hostde l'IP doit résoudre versgooglebot.com,google.comougoogleusercontent.com, et un DNS direct doit reconduire à la même IP) ou par recoupement avec les plages d'IP officielles que Google publie en JSON. Beaucoup de WAF intègrent une vérification « bots vérifiés » déjà câblée sur ces plages — préférez-la à toute liste blanche maison. - Débloquez aussi le CSS et le JavaScript. Une page peut renvoyer 200, mais ses ressources (feuilles de style, scripts) être en 403. Google ne rend alors la page que partiellement. Vérifiez que les fichiers nécessaires au rendu sont, eux aussi, accessibles à Googlebot.
- Demandez la réindexation. Une fois l'accès rétabli, utilisez l'Inspection d'URL pour confirmer le passage à 200, puis demandez l'indexation pour signaler à Google que la page est de nouveau accessible.
Gérer un 403 voulu proprement
Pour une page du cas A, le réflexe « ne touchez à rien » a une limite : un 403 servi à Googlebot reste, aux yeux de Google, un usage à contre-emploi du code. La gestion propre consiste à confirmer l'intention, puis à couper les signaux qui mènent Googlebot vers la page, et enfin à choisir le bon outil selon votre objectif réel.
- Confirmez l'intention. Cette page n'a effectivement aucune vocation à apparaître dans Google (admin, préproduction, espace membre). Si le moindre doute subsiste, traitez-la comme un cas B.
- Sortez-la du sitemap. Une URL en 403 listée dans votre sitemap envoie un signal contradictoire : vous demandez à Google d'indexer une page que votre serveur lui refuse.
- Coupez le maillage interne. Tant que des liens internes pointent vers l'URL, Googlebot continuera de la solliciter et de buter sur le 403. Retirez ces liens.
- Choisissez le bon outil selon le but :
- Vrai contenu authentifié (intranet, espace membre) → un 401 est plus honnête qu'un 403, mais le résultat côté index est identique : Google traite la page comme inexistante.
- Empêcher le crawl d'une zone sans intérêt → le robots.txt est l'outil prévu pour cela. Attention : il empêche le crawl, pas forcément l'indexation si l'URL est connue ailleurs — voir Indexée malgré le blocage par robots.txt.
- Autoriser le crawl mais exclure de l'index → la balise
noindex. Google doit pouvoir crawler la page pour voir la balise : elle ne doit donc être ni en 403, ni bloquée aurobots.txt.
Vérifier que la correction a pris
Une fois le 403 levé, confirmez que Google a pris acte. Réinspectez les URLs traitées via l'Inspection d'URL : le « Test en direct » doit afficher un 200 là où il y avait un 403. Puis suivez l'évolution dans le temps, car la réindexation n'est pas instantanée — Google doit recrawler la page, constater qu'elle est de nouveau accessible, et la réintégrer à l'index. Ce délai se compte généralement en jours.
Une analyse unique ne prouve rien : c'est la comparaison entre un état avant et un état après qui montre le mouvement. Les pages que vous avez débloquées doivent quitter le statut « Bloquée en raison d'une interdiction d'accès (403) », repasser en 200, se faire crawler, puis basculer en indexées.
La vue COMPARAISON d'IndexProbe est conçue pour ce suivi : elle met deux analyses en regard et chiffre, par URL, le passage du 403 à l'indexation. C'est la confirmation que votre exception WAF a bien rouvert l'accès à Googlebot, et pas seulement à votre navigateur.
Questions fréquentes
Que signifie « Bloquée en raison d'une interdiction d'accès (403) » dans la Search Console ? Cela signifie que Googlebot a demandé l'URL et que votre serveur a répondu par un code HTTP 403 (accès interdit). Google en conclut que le contenu est inaccessible, le traite comme inexistant et retire l'URL de l'index s'il l'avait indexée. Ce n'est pas une consigne que vous donnez, c'est un refus actif du serveur.
Pourquoi un 403 pour Googlebot alors que la page s'ouvre chez moi ? Parce qu'un pare-feu applicatif (WAF), un mode anti-bots ou un service anti-DDoS sert la page aux visiteurs humains tout en opposant un 403 à ce qu'il prend pour un robot indésirable, Googlebot compris. Votre navigateur teste l'accès humain ; le seul verdict qui compte est le code HTTP réellement reçu par Googlebot.
Comment corriger un 403 bloquant Googlebot ? Lisez les logs de votre WAF ou CDN pour identifier la règle fautive, créez une exception ciblée laissant passer Googlebot, et vérifiez son identité réelle par DNS inverse ou plages d'IP officielles (jamais sur le seul user-agent). Débloquez aussi le CSS et le JavaScript, puis demandez la réindexation via l'Inspection d'URL.
Un 403 empêche-t-il l'indexation ? Oui. Google ne récupère pas le contenu des URLs renvoyant un 403 (comme tous les codes 4xx hors 429) : il considère que la page n'existe pas. Une page jamais indexée ne le sera pas tant que le 403 tient ; une page déjà indexée en sort.
Quelle différence entre 403, 401 et 404 ? Le 403 est un refus d'accès, le 401 une exigence d'authentification, le 404 une page introuvable. Du point de vue de l'index, Google les traite tous comme « contenu inexistant » et retire l'URL de l'index. La différence est dans le signal envoyé au serveur, pas dans le résultat côté indexation.
Cloudflare peut-il bloquer Googlebot ? Oui. Le Bot Fight Mode et certaines règles WAF de Cloudflare peuvent renvoyer un 403 à Googlebot s'il est classé comme bot indésirable. La parade est d'activer la vérification « bots vérifiés » de Cloudflare (qui s'appuie sur les plages d'IP officielles de Google) ou de créer une règle d'exception ciblée sur Googlebot dûment vérifié.
Ne fondez plus votre diagnostic sur ce que voit votre navigateur. IndexProbe se branche sur l'API officielle de la Search Console et inspecte votre liste d'URLs en une seule analyse : le code HTTP réellement reçu par Googlebot, le statut d'indexation et la date du dernier passage du robot, côte à côte. Vous repérez les 403 servis à Google mais invisibles chez vous, vous séparez le 403 voulu du blocage accidentel, et vous vérifiez d'une analyse à l'autre, grâce à la vue COMPARAISON, que vos pages repassent de 403 à indexées.