Faut-il vraiment conserver l'enregistrement DNS de vérification Search Console après validation ?

Pourquoi cette règle existe-t-elle techniquement ?

La vérification de propriété dans Search Console n'est pas un processus ponctuel. Google rechecke périodiquement que vous contrôlez toujours le domaine.

Si l'enregistrement DNS TXT disparaît entre deux validations, Search Console considère que vous n'êtes plus propriétaire légitime. La propriété passe alors en statut non vérifié — et vous perdez l'accès aux données, rapports, soumissions de sitemaps.

Qu'est-ce qui se passe concrètement si je supprime le record ?

Dès que Google détecte l'absence du token de vérification lors d'un contrôle périodique, votre accès à la propriété est révoqué. Vous recevez une notification par email, mais si elle passe inaperçue, vous pouvez vous retrouver sans visibilité sur vos métriques pendant des jours.

La ré-vérification est possible, mais elle implique de regénérer un nouveau token DNS, de le publier, d'attendre la propagation — et pendant ce temps, vous êtes aveugle sur vos performances organiques.

Cette vérification est-elle différente selon la méthode choisie ?

Google propose plusieurs méthodes : DNS, balise HTML, Google Analytics, Tag Manager, fichier HTML. La logique reste identique pour toutes : le jeton de validation doit rester présent en permanence.

Le DNS est souvent privilégié en agence car il ne dépend pas d'une balise qu'un développeur pourrait retirer lors d'un refonte. Mais il faut documenter ce record dans la gouvernance technique du domaine.

• Ne jamais supprimer un enregistrement DNS de vérification Search Console après validation
• Documenter chaque token dans un gestionnaire de configuration (wiki interne, tableau de bord DNS)
• Prévenir les équipes infra que ces records sont critiques et ne doivent jamais être purgés lors d'audits DNS
• Vérifier régulièrement que le statut de propriété reste actif, surtout après migrations ou changements d'hébergement
• Prévoir un processus de ré-validation rapide en cas de perte accidentelle (contact propriétaire DNS, délai de propagation)

Cette déclaration est-elle cohérente avec les pratiques observées sur le terrain ?

Absolument. On voit régulièrement des cas où un SEO perd l'accès à Search Console après une migration ou un audit DNS « ménage ». L'équipe technique supprime des records jugés obsolètes, sans savoir qu'ils servent à maintenir la vérification.

Le problème c'est que Google ne prévient pas toujours immédiatement. Certains utilisateurs découvrent la révocation plusieurs jours après, quand ils tentent de consulter un rapport de performance ou soumettre un sitemap corrigé.

Quelles nuances faut-il apporter à cette recommandation ?

Google ne précise pas la fréquence exacte des contrôles de vérification. Est-ce quotidien ? hebdomadaire ? [A vérifier] — aucune documentation officielle ne le détaille.

De plus, certains praticiens ont observé que la révocation n'est pas toujours instantanée : il peut y avoir un délai de grâce de quelques heures. Mais compter dessus serait risqué — mieux vaut partir du principe que la suppression du record entraîne une révocation quasi immédiate.

Dans quels cas cette règle pourrait-elle ne pas s'appliquer ?

Si vous utilisez la méthode de vérification par Google Analytics ou Tag Manager, le jeton n'est pas dans le DNS — il est dans le code. Mais la logique reste la même : retirer la balise = perte de vérification.

Certains SEO pensent qu'une fois la propriété vérifiée pendant plusieurs mois, Google « fait confiance ». Faux. La vérification est technique et automatisée, pas basée sur l'ancienneté. Aucun passe-droit.

Que faut-il faire concrètement pour éviter toute perte de vérification ?

D'abord, documenter chaque enregistrement DNS de vérification dans un fichier de gouvernance accessible à toute l'équipe technique. Note la date de création, le service concerné (Search Console, Analytics, etc.), et le propriétaire responsable.

Ensuite, configurer des alertes automatiques dans Search Console pour recevoir une notification immédiate si le statut de propriété change. Google envoie un email, mais beaucoup finissent en spam — mieux vaut un slack webhook ou un monitoring dédié.

Quelles erreurs éviter absolument lors d'une migration ou refonte ?

La première erreur : confier la migration DNS à une équipe qui ne connaît pas le rôle des records TXT de vérification. Résultat : ils copient les MX, les A, les CNAME — mais oublient les TXT « obscurs ».

Seconde erreur : nettoyer le DNS « pour faire propre » après une migration réussie. Les anciens tokens de vérification semblent inutiles, donc on les purge. Sauf que Google les checke toujours.

Comment vérifier que mon site reste bien vérifié en permanence ?

Mets en place un monitoring hebdomadaire du statut de propriété dans Search Console. Un simple script qui checke via l'API si la propriété est toujours active suffit.

Si tu gères plusieurs dizaines de domaines en agence, centralise ces tokens dans un gestionnaire de secrets (Vault, 1Password Teams) avec métadonnées : domaine, date, service, contact propriétaire.

• Lister tous les enregistrements DNS TXT de vérification actuellement actifs sur chaque domaine géré
• Documenter chaque token dans un fichier de gouvernance partagé avec l'équipe technique et infra
• Configurer des alertes automatiques (email, Slack, webhook) pour détecter toute révocation de propriété Search Console
• Inclure une vérification systématique des records TXT dans tout checklist de migration DNS ou changement d'hébergement
• Former les équipes techniques sur l'importance critique de ces enregistrements — ne jamais les supprimer sans validation SEO
• Prévoir un processus de ré-validation rapide en cas de perte accidentelle (contact DNS, délai de propagation, re-génération token)