Declaration officielle
Autres déclarations de cette vidéo 5 ▾
- □ Faut-il vraiment surveiller les accès Search Console de vos prestataires SEO ?
- □ Pourquoi Google insiste-t-il sur la vérification de propriété de votre site ?
- □ Pourquoi retirer tous les jetons de vérification des anciens utilisateurs dans Search Console ?
- □ Faut-il vraiment limiter les accès des outils SEO à la lecture seule dans la Search Console ?
- □ Pourquoi l'accès délégué est-il préférable aux mots de passe partagés avec vos prestataires SEO ?
Google recommande de vérifier et retirer les accès Search Console des agences ou consultants qui ne travaillent plus sur votre site. Les utilisateurs délégués se retirent facilement, mais les vérifications par jeton nécessitent l'intervention d'un développeur ou de votre hébergeur. Un audit des accès actifs s'impose pour éviter des fuites de données stratégiques.
Ce qu'il faut comprendre
John Mueller aborde ici un sujet de sécurité et de gouvernance souvent négligé : la gestion des accès à Search Console. Quand une agence ou un consultant quitte un projet, ses accès persistent tant qu'on ne les révoque pas explicitement.
Le problème ? Ces accès donnent une visibilité totale sur vos performances organiques, vos requêtes stratégiques, vos pénalités manuelles et vos données structurées. Un ancien prestataire conserve donc un œil sur votre stratégie SEO — et potentiellement sur celle de vos concurrents s'il travaille pour eux.
Quelle est la différence entre utilisateurs délégués et vérification par jeton ?
Search Console propose deux modes d'accès distincts. Les utilisateurs délégués sont ajoutés via l'interface GSC classique : vous les retirez en quelques clics depuis les paramètres de propriété.
La vérification par jeton — qu'elle soit DNS, fichier HTML, balise meta ou Google Tag Manager — prouve que vous contrôlez le domaine. Un ancien prestataire ayant ajouté un jeton DNS ou un fichier de vérification conserve son accès même si vous le retirez des utilisateurs. Vous devez supprimer physiquement le jeton pour invalider sa vérification.
Pourquoi Google insiste sur ce point maintenant ?
Cette recommandation n'est pas nouvelle, mais Mueller la reformule explicitement. Google constate probablement que de nombreux sites accumulent des accès obsolètes — anciens freelances, stagiaires, agences remplacées il y a trois ans.
Le vrai risque ? Un accès non révoqué peut être exploité pour manipuler des données, détecter vos axes stratégiques ou même masquer des actions négatives si l'ancien prestataire conserve aussi des accès serveur. C'est rare, mais ça arrive.
- Auditez régulièrement la liste complète des utilisateurs Search Console et Google Analytics
- Documentez qui a accès à quoi, et pour quelle raison précise
- Révocation systématique dès la fin d'une mission ou d'un contrat
- Vérifiez les jetons actifs avec votre développeur ou hébergeur — ce n'est pas visible dans GSC
- Activez la double authentification sur le compte propriétaire pour limiter les risques de piratage
Avis d'un expert SEO
Cette déclaration est-elle une simple piqûre de rappel ou révèle-t-elle un problème répandu ?
Soyons honnêtes : 90 % des sites que j'audite ont au moins un accès GSC zombie. Ancien CTO parti sans transition, stagiaire qui a « juste aidé sur un truc », agence remplacée en catastrophe. Personne ne pense à nettoyer derrière.
Le fait que Mueller le reformule explicitement suggère que Google observe ce phénomène à grande échelle. Ou alors — hypothèse moins charitable — ils anticipent des contentieux post-rupture contractuelle où un ancien prestataire revendique un accès « légitime » parce qu'il a techniquement vérifié le domaine.
Quels sont les vrais risques d'un accès non révoqué ?
Le risque numéro un, c'est la fuite de données stratégiques. Un concurrent indirect qui a bossé pour vous il y a deux ans peut suivre vos évolutions de trafic, vos nouvelles requêtes ciblées, vos tests de structure. C'est de l'espionnage passif, mais efficace.
Deuxième risque : si cet accès est couplé à des droits serveur ou CMS non révoqués, un ancien prestataire mécontent peut saboter discrètement. Ajouter un noindex dans le robots.txt, modifier un redirect stratégique, injecter du spam… puis surveiller l'impact dans GSC. Improbable, mais j'ai vu deux cas en 15 ans.
Faut-il vraiment systématiser cet audit ?
Oui, mais sans tomber dans la paranoïa. Un audit semestriel des accès GSC + GA + GTM est largement suffisant pour 95 % des sites. Pour les très gros comptes (médias, e-commerce leader), un audit trimestriel et une procédure documentée de révocation sont indispensables.
Le vrai défi, c'est la détection des vérifications par jeton. GSC ne liste pas clairement « qui a ajouté quel jeton ». Vous devez croiser manuellement : fichier HTML racine, balise meta dans le <head>, enregistrements DNS TXT, snippet GTM. C'est fastidieux, et beaucoup de PME n'ont tout simplement pas la documentation technique pour savoir qui a fait quoi.
Impact pratique et recommandations
Comment identifier et retirer les utilisateurs obsolètes ?
Connectez-vous à Search Console, sélectionnez votre propriété, puis allez dans Paramètres > Utilisateurs et autorisations. Vous voyez la liste complète des utilisateurs délégués avec leur niveau d'accès (propriétaire, accès complet, accès restreint).
Retirez immédiatement tous les comptes que vous ne reconnaissez pas ou qui correspondent à d'anciens prestataires. Pour les comptes que vous hésitez à supprimer — peut-être un ancien collaborateur qui pourrait revenir — rétrogradez-les en accès restreint plutôt que de les laisser propriétaires.
Comment détecter et supprimer les vérifications par jeton ?
C'est là que ça se complique. GSC affiche les méthodes de vérification actives dans Paramètres > Propriétaires vérifiés, mais ne précise pas forcément qui les a ajoutées ni quand. Vous devez investiguer manuellement.
Vérifiez successivement : le fichier HTML de vérification à la racine de votre site (googleXXXXXX.html), la balise <meta name="google-site-verification"> dans le code source de votre homepage, les enregistrements DNS TXT chez votre registrar ou hébergeur, et les déclencheurs Google Site Verification dans GTM.
Si vous identifiez un jeton que personne dans l'équipe actuelle ne reconnaît, supprimez-le. Attention : si vous retirez TOUS les jetons, vous perdrez temporairement l'accès GSC jusqu'à ce qu'un propriétaire actuel se re-vérifie. Assurez-vous qu'au moins un utilisateur de confiance reste vérifié.
Quelle procédure mettre en place pour éviter ce problème à l'avenir ?
Documentez chaque ajout d'utilisateur dans un registre des accès : qui, pourquoi, niveau d'accès, date de début, date de fin prévue. Ça paraît bureaucratique, mais ça évite six mois plus tard de se demander « c'est qui ce compte @ agence-disparue.com ? ».
Imposez une révocation systématique dans vos contrats avec freelances et agences. Clause explicite : « À la fin de la mission, le prestataire s'engage à transmettre la liste exhaustive des accès ajoutés et à les révoquer lui-même, ou à fournir la documentation pour que le client le fasse. »
- Auditez la liste des utilisateurs GSC au moins tous les 6 mois
- Croisez avec votre liste interne des collaborateurs et prestataires actifs
- Retirez immédiatement tout compte non reconnu ou obsolète
- Vérifiez les méthodes de vérification actives dans les paramètres GSC
- Inspectez manuellement fichiers HTML, balises meta, DNS TXT et GTM
- Supprimez les jetons non documentés après validation avec votre équipe technique
- Documentez chaque nouvel accès dans un registre centralisé
- Intégrez une clause de révocation dans vos contrats prestataires
❓ Questions frequentes
Que se passe-t-il si je retire tous les utilisateurs vérifiés par erreur ?
Un ancien prestataire peut-il conserver un accès même après révocation dans GSC ?
Comment savoir si quelqu'un a utilisé mon accès GSC récemment ?
Faut-il aussi auditer Google Analytics et Google Tag Manager ?
Puis-je déléguer la gestion des accès à une seule personne en interne ?
🎥 De la même vidéo 5
Autres enseignements SEO extraits de cette même vidéo Google Search Central · publiée le 26/07/2023
🎥 Voir la vidéo complète sur YouTube →
💬 Commentaires (0)
Soyez le premier à commenter.