// diagnostic GSC
Accès interdit (403) : débloquer Googlebot.
Le statut qui rend fou : la page s'affiche parfaitement dans le navigateur, mais Search Console jure qu'elle est inaccessible. C'est que le blocage ne vise pas l'URL, il vise le visiteur. Quelque part entre le CDN et le serveur, une couche de sécurité prend Googlebot pour un bot hostile.
Ce que signifient 403 et 401.
Search Console distingue deux statuts voisins : "Bloquée en raison d'une interdiction d'accès (403)" et "Bloquée en raison d'une demande non autorisée (401)". Dans les deux cas, le serveur refuse de livrer la page à Googlebot, qui ne peut ni la lire ni l'indexer.
401 : authentification requise
La page exige un login (espace client, intranet, htpasswd). Googlebot ne s'authentifie jamais : le 401 est donc normal et attendu sur du contenu privé. Agir uniquement si une page censée être publique apparaît ici, signe d'une protection par mot de passe oubliée.
403 : accès interdit
Le serveur comprend la requête mais la refuse. Sur une page publique, c'est presque toujours involontaire : une règle de sécurité classe Googlebot comme indésirable. C'est le cas à traiter en priorité, car il désindexe des pages qui doivent ranker.
// à retenir
Un 403 sur page publique est un faux positif de sécurité : le site se protège des bots et attrape Googlebot dans le filet. La correction se joue dans la configuration de sécurité, jamais dans le contenu.
Trouver la couche qui bloque.
Entre Googlebot et la page, la requête traverse plusieurs couches. Chacune peut émettre le 403. Vérifier de l'extérieur vers l'intérieur :
- 01
Le CDN et sa protection anti-bot
Cloudflare ("Bot Fight Mode", règles WAF, blocage par pays), Akamai, Fastly, Vercel Firewall. Premier suspect en 2026 : le durcissement anti-scraping lié aux crawlers IA attrape régulièrement les bots de moteurs au passage. Vérifier les logs du CDN et le traitement réservé aux "bots vérifiés".
- 02
Le pare-feu applicatif et l'hébergeur
WAF de l'hébergeur (mutualisés notamment), mod_security, fail2ban, rate limiting. Certains hébergeurs activent des protections par défaut qui limitent les requêtes par IP : les rafales de crawl de Googlebot déclenchent alors des 403 intermittents, visibles dans les statistiques d'exploration.
- 03
Le serveur et l'application
Règles .htaccess ou nginx (deny par IP ou user-agent), plugin de sécurité WordPress (Wordfence, iThemes) en mode strict, protection de répertoire. Sur WordPress, les faux positifs de plugins de sécurité sont fréquents : le guide indexation WordPress liste les réglages sensibles.
Pour dater et localiser : Search Console > Paramètres > Statistiques d'exploration, courbe des réponses "Non autorisée (403)". Le début du pic coïncide en général avec un changement de configuration identifiable.
Débloquer sans ouvrir aux vrais bots hostiles.
L'objectif n'est pas de désactiver la sécurité mais de la rendre sélective. Deux principes :
- S'appuyer sur la vérification de bots, pas sur le user-agent : n'importe quel scraper peut se déclarer "Googlebot". Les CDN sérieux vérifient l'identité par DNS inverse ou liste officielle d'IP (Google publie ses plages). Utiliser la catégorie "verified bots" du CDN ou vérifier soi-même via reverse DNS.
- Exempter les bots vérifiés de tout challenge : un challenge JavaScript ou un CAPTCHA servi à Googlebot équivaut à un blocage, même si le code renvoyé est 200 (la page rendue est le challenge, pas le contenu, ce qui produit des soft 404 en cascade).
Après modification, confirmer avec Inspection de l'URL > "Tester l'URL en ligne" (réponse attendue : 200, "Exploration autorisée ? Oui"), demander la réindexation des pages stratégiques, puis "Valider la correction" sur la ligne du rapport. Pour accélérer sur un volume important, voir forcer l'indexation Google.
Prévenir les rechutes.
Tester après chaque durcissement
Tout changement de règle WAF, de plugin de sécurité ou de CDN doit être suivi d'un test en direct sur 2-3 URLs représentatives dans GSC.
Surveiller la courbe 403
Un contrôle mensuel des statistiques d'exploration détecte un blocage naissant avant qu'il ne désindexe : la courbe 403 doit rester à zéro ou presque.
Préférer le bon outil de blocage
Pour tenir un contenu hors de Google, le 403 est le mauvais levier : utiliser le robots.txt (crawl) ou la balise noindex (indexation).
Ce statut appartient à la famille des blocages techniques, avec les erreurs serveur (5xx) et les 404. Panorama complet dans page non indexée par Google.
Questions fréquentes.
Que signifient les statuts "Bloquée en raison d'une interdiction d'accès (403)" et "(401)" ?
Le serveur a répondu à Googlebot par un code de refus : 403 Forbidden (accès interdit) ou 401 Unauthorized (authentification requise). Google ne peut pas lire la page et l'exclut de l'index. Comme Google n'utilise jamais d'identifiants, toute page derrière un login renverra légitimement 401 ; le 403 sur une page publique, lui, est presque toujours un blocage involontaire.
Pourquoi la page fonctionne dans mon navigateur mais renvoie 403 à Google ?
Parce que le blocage ne vise pas l'URL mais le visiteur. Une couche de sécurité (Cloudflare, WAF, module serveur, plugin de sécurité) classe Googlebot comme bot indésirable : filtrage par user-agent, par plage d'IP, challenge JavaScript ou rate limiting. Le test dans un navigateur ne reproduit pas le problème ; il faut tester avec l'outil Inspection de l'URL de GSC, qui crawle avec la vraie identité de Googlebot.
Comment vérifier que le 403 touche bien Googlebot ?
Dans Search Console, Inspection de l'URL > "Tester l'URL en ligne" : le test en direct affiche le code de réponse obtenu par Googlebot à l'instant T. Compléter avec le rapport Paramètres > Statistiques d'exploration, qui ventile les réponses par code et permet de dater le début du blocage.
Comment autoriser Googlebot dans Cloudflare ?
Cloudflare maintient une catégorie "bots connus" (verified bots) qui inclut Googlebot : vérifier qu'aucune règle WAF personnalisée, aucun blocage géographique ni "Bot Fight Mode" ne s'applique aux bots vérifiés. Créer si besoin une règle d'exception basée sur cf.client.bot. Ne jamais whitelister sur le seul user-agent "Googlebot" : il est falsifiable, préférer la vérification par bot connu ou par DNS inverse.
Un pic soudain de 403 après une mise à jour, que faire ?
C'est le scénario type : nouveau plugin de sécurité, durcissement du pare-feu, changement d'hébergeur ou activation d'une protection anti-DDoS. Identifier ce qui a changé à la date du pic (visible dans les statistiques d'exploration), désactiver temporairement la règle suspecte, re-tester avec Inspection de l'URL, puis réactiver la protection avec une exception pour les bots vérifiés.
Les pages en 403 déjà désindexées reviennent-elles après correction ?
Oui. Une fois le blocage levé et confirmé par un test en direct, demander la réindexation des pages prioritaires et cliquer "Valider la correction" dans le rapport. Le retour dans l'index suit le rythme de re-crawl : quelques jours pour les pages importantes, plusieurs semaines pour la longue traîne. Les délais d'indexation dépendent de l'autorité du site.
// passer à l'action
Vérifier ce que reçoit vraiment un robot.
Le diagnostic gratuit interroge l'URL comme un crawler et révèle les codes de réponse, blocages et redirections rencontrés.