Declaration officielle
Autres déclarations de cette vidéo 2 ▾
Google recommande de réduire le TTL DNS à 5 minutes avant un changement d'hébergeur pour accélérer la propagation vers la nouvelle IP. Cette manipulation technique permet aux bots et utilisateurs de basculer plus vite, limitant les erreurs de crawl et les temps d'indisponibilité. Reste à savoir si cette fenêtre de 5 minutes suffit réellement dans tous les contextes de migration.
Ce qu'il faut comprendre
Qu'est-ce que le TTL DNS et pourquoi ça compte pour le SEO ?
Le TTL (Time to Live) définit la durée pendant laquelle un résolveur DNS met en cache l'adresse IP associée à un nom de domaine. Quand le TTL est fixé à 3600 secondes (1 heure), les serveurs DNS du monde entier conservent cette information pendant une heure avant de redemander la valeur.
Pour un site qui migre d'hébergeur, un TTL élevé pose un problème simple : les bots Google continuent de crawler l'ancienne IP pendant des heures, même si le nouveau serveur est déjà actif. Résultat, erreurs 404, timeout, voire perte temporaire d'indexation si les contenus ne sont plus accessibles sur l'ancien serveur.
Pourquoi Google insiste-t-il sur 5 minutes précisément ?
La valeur de 5 minutes (300 secondes) n'est pas arbitraire. C'est un compromis entre réactivité et charge serveur. Un TTL trop court (30 secondes par exemple) multiplie les requêtes DNS et peut dégrader les performances, surtout sur les sites à fort trafic.
Avec 5 minutes, le cache DNS se rafraîchit suffisamment vite pour que la transition soit quasi transparente, sans surcharger les résolveurs. Les crawlers Google passent généralement plusieurs fois par jour sur un site : si le TTL est bas au moment du basculement, ils récupèrent la nouvelle IP dès le passage suivant.
Que se passe-t-il si on oublie cette étape ?
Un TTL laissé à 86400 secondes (24h) signifie que pendant une journée entière, une partie du trafic et des bots continuera de pointer vers l'ancienne IP. Si l'ancien hébergeur coupe le service immédiatement, le site devient inaccessible pour ces visiteurs.
Côté SEO, Google peut rencontrer des erreurs HTTP 5xx ou des timeouts, ce qui déclenche des alertes dans Search Console et peut ralentir le crawl. Dans le pire des cas, si l'indisponibilité dure plusieurs jours, certaines pages risquent d'être désindexées temporairement.
- Réduire le TTL à 5 minutes au moins 24-48h avant la migration DNS
- Vérifier que l'ancienne IP reste accessible quelques heures après le basculement
- Surveiller Search Console pour détecter les erreurs de crawl pendant la transition
- Rétablir un TTL normal (3600-86400s) une fois la migration stabilisée
- Planifier la migration en dehors des pics de trafic pour limiter l'impact utilisateur
Avis d'un expert SEO
Cette recommandation est-elle suffisante dans tous les cas ?
La consigne de Google est correcte pour une migration simple : même hébergeur, même stack technique, juste un changement d'IP. Mais elle reste silencieuse sur les migrations complexes (changement de CMS, refonte d'architecture, passage HTTP vers HTTPS en simultané).
Dans ces contextes, le TTL DNS n'est qu'un paramètre parmi d'autres. Si la nouvelle infrastructure présente des temps de réponse dégradés ou des erreurs de configuration, baisser le TTL ne résoudra rien. Les bots crawleront la nouvelle IP plus vite, certes, mais tomberont sur un site mal configuré.
Pourquoi Google ne parle-t-il pas des autres couches techniques ?
Cette déclaration se concentre sur le DNS, mais ignore volontairement d'autres leviers critiques : redirections 301/302, configuration serveur, gestion du cache CDN. Un TTL bas ne sert à rien si les redirections ne sont pas en place ou si le CDN continue de servir les anciennes pages.
Soyons honnêtes : Google simplifie pour un public généraliste. Un professionnel SEO sait qu'une migration d'hébergement implique un audit complet [A vérifier] avant/après, pas juste un ajustement DNS. Le silence de Google sur ces points ne signifie pas qu'ils sont optionnels.
Les 5 minutes sont-elles toujours applicables ?
Pour un site corporate classique, oui. Pour un média à fort trafic ou un site e-commerce en peak season, c'est discutable. Un TTL trop court peut créer une sur-sollicitation des résolveurs DNS et dégrader la latence perçue par les utilisateurs finaux.
Certains hébergeurs imposent aussi des TTL minimums (600 secondes chez certains registrars). Si votre registrar ne permet pas de descendre sous 10 minutes, la recommandation de Google devient inapplicable. Vérifiez les limitations techniques de votre prestataire DNS avant de planifier.
Impact pratique et recommandations
Que faut-il faire concrètement avant une migration ?
Première étape : identifier le TTL actuel de vos enregistrements DNS. Utilisez `dig` ou `nslookup` pour vérifier la valeur en vigueur. Si elle est supérieure à 3600 secondes, réduisez-la à 300 secondes au moins 48 heures avant le jour J.
Pourquoi 48h d'avance ? Parce que les anciens TTL doivent expirer avant que la nouvelle valeur ne prenne effet globalement. Si votre TTL est à 86400s et que vous le baissez à 300s la veille, certains résolveurs garderont l'ancienne valeur pendant 24h supplémentaires.
Comment vérifier que le basculement s'est bien passé ?
Après avoir pointé vos DNS vers la nouvelle IP, surveillez trois indicateurs : erreurs HTTP dans Search Console, temps de réponse serveur (via GTmetrix ou Pingdom), et logs de crawl Googlebot. Si vous voyez un pic d'erreurs 5xx ou de timeouts dans les heures suivant la migration, c'est que la transition n'est pas fluide.
Testez aussi manuellement depuis plusieurs localisations géographiques (VPN, outils multi-région). Les DNS ne se propagent pas uniformément : un utilisateur en Asie peut encore voir l'ancienne IP alors qu'en Europe tout fonctionne. Laissez l'ancien serveur en ligne 24-48h après le basculement pour éviter les coupures brutales.
Quelles erreurs faut-il absolument éviter ?
Ne remontez pas le TTL trop tôt. Certains SEO, stressés par une éventuelle surcharge DNS, remontent le TTL à 3600s dès que le site semble stable. Problème : si un bug apparaît 12h après et nécessite un rollback, vous êtes coincé avec un TTL long qui ralentit le retour arrière.
Autre piège : oublier les sous-domaines. Si votre site utilise `blog.example.com` ou `shop.example.com`, chaque sous-domaine a son propre enregistrement DNS et son propre TTL. Un oubli sur un sous-domaine peut casser une partie du site sans que le domaine principal ne soit affecté.
- Réduire le TTL à 300 secondes au moins 48h avant la migration
- Vérifier que tous les enregistrements DNS (A, AAAA, CNAME) sont concernés
- Maintenir l'ancien serveur accessible pendant 24-48h après le basculement
- Purger le cache CDN en parallèle du changement DNS
- Surveiller Search Console et les logs serveur pendant 72h post-migration
- Remonter progressivement le TTL à 3600s une fois la stabilité confirmée
❓ Questions frequentes
Peut-on baisser le TTL à moins de 5 minutes pour accélérer encore la transition ?
Que faire si le registrar ne permet pas de modifier le TTL manuellement ?
Le TTL bas doit-il rester actif après la migration ou peut-on le remonter rapidement ?
Un TTL bas peut-il impacter négativement les Core Web Vitals ?
Faut-il prévenir Google via Search Console avant une migration d'hébergement ?
🎥 De la même vidéo 2
Autres enseignements SEO extraits de cette même vidéo Google Search Central · durée 4 min · publiée le 04/08/2011
🎥 Voir la vidéo complète sur YouTube →
💬 Commentaires (0)
Soyez le premier à commenter.