Faut-il vraiment laisser le robots.txt intact pendant une migration SEO ?

Pourquoi Google insiste-t-il autant sur la stabilité du robots.txt ?

La déclaration de Martin Splitt rappelle un principe souvent malmené en pratique : une migration technique ne devrait jamais déclencher une révision des règles de crawl. Le fichier robots.txt définit ce que les moteurs peuvent ou non explorer, et ces décisions relèvent d'une stratégie éditoriale ou technique préalable.

Si vous avez bloqué certaines sections (facettes de filtres, archives, pages de recherche interne) avant la migration, c'est que vous aviez identifié un problème de crawl budget, de contenu dupliqué ou de performance. Changer ces règles en pleine migration introduit une variable incontrôlable dans un processus déjà risqué.

Qu'est-ce qui justifie un blocage robots.txt avant migration ?

Les raisons classiques incluent : éviter l'indexation de contenus faibles (tags, filtres sans valeur ajoutée), protéger des données sensibles (espaces clients, API), ou encore préserver le crawl budget en écartant des URL générées dynamiquement sans intérêt SEO.

Ces décisions stratégiques ne changent pas avec la technologie sous-jacente. Que vous passiez de WordPress à Shopify ou d'un serveur Apache à Nginx, les URLs à exclure restent les mêmes — seule leur structure technique évolue. Soyons honnêtes : beaucoup de SEO profitent d'une migration pour « tout remettre à plat », et c'est souvent là que les choses dérapent.

Dans quel contexte cette règle peut-elle poser problème ?

La déclaration de Google suppose que votre robots.txt initial était pertinent. Mais si l'ancien fichier contenait des erreurs — blocages trop larges, directives obsolètes, wildcards mal calibrés — vous vous retrouvez coincé. Faut-il vraiment reporter les corrections après la migration ?

Google ne donne pas de réponse tranchée ici. La consigne « ne changez rien » s'applique surtout aux sites dont le robots.txt était correctement configuré. Pour les autres, il faut arbitrer entre stabilité du processus de migration et nécessité de corriger des erreurs critiques avant de basculer.

• Une migration change la structure technique, pas la stratégie de crawl
• Les blocages robots.txt doivent être décidés en amont, pas pendant la migration
• Corriger un robots.txt défaillant pendant une migration ajoute un risque supplémentaire
• Auditer le fichier robots.txt avant le projet évite les mauvaises surprises
• Google part du principe que votre configuration initiale était pertinente

Cette directive est-elle réaliste face aux migrations complexes ?

La position de Google est logique en théorie, mais elle pose problème dans les scénarios réels. Beaucoup de sites migrent justement parce que leur configuration SEO était défaillante. Demander de conserver un robots.txt problématique revient à perpétuer des erreurs pour ne pas perturber le crawl.

Concrètement, si votre ancien site bloque par erreur des catégories entières ou contient des directives devenues inutiles, vous avez deux options : les corriger avant la migration (et risquer de déstabiliser un site déjà fragile) ou les corriger après (et subir une période où le nouveau site hérite des mêmes limitations). Aucune des deux n'est idéale. [A vérifier] — Google ne précise pas comment gérer ces cas de figure.

Quelles contradictions observe-t-on sur le terrain ?

En pratique, beaucoup de migrations réussies incluent justement une révision complète du robots.txt. L'argument « ne rien changer » ignore que certaines plateformes génèrent automatiquement des URLs parasites (Shopify avec ses collections filtrées, WordPress avec ses archives de tags) qui n'existaient pas sur l'ancien site.

Et c'est là que ça coince. Si vous migrez d'un site custom vers un CMS qui génère massivement de nouvelles URLs, devez-vous vraiment attendre « après la migration » pour bloquer ces nouvelles URLs ? La réponse de Google reste floue. Sur le terrain, les SEO qui ont attendu ont souvent vu leur crawl budget exploser avant de pouvoir réagir.

Quand cette règle ne s'applique-t-elle clairement pas ?

Si votre migration implique un changement radical de structure (passage d'un e-commerce à un site vitrine, refonte complète de l'architecture), conserver le robots.txt à l'identique n'a aucun sens. Les URLs bloquées n'existent peut-être même plus, ou correspondent à des fonctionnalités abandonnées.

Dans ces cas, il faut cartographier les anciennes règles, identifier celles qui restent pertinentes, et reconstruire un nouveau fichier avant la bascule. Oui, cela ajoute une étape. Mais prétendre qu'une migration est neutre vis-à-vis du crawl est une fiction dans beaucoup de projets.

Que faut-il vérifier avant de lancer une migration ?

Avant toute bascule, auditez votre robots.txt ligne par ligne. Identifiez chaque directive Disallow et User-agent, et demandez-vous si elle a encore du sens. Beaucoup de fichiers contiennent des règles ajoutées il y a des années par des prestataires qui ne sont plus là, sans documentation.

Utilisez Google Search Console pour vérifier quelles URLs sont actuellement bloquées. Comparez avec votre plan de migration : ces URLs existeront-elles encore ? Sous la même structure ? Si la réponse est non, vous ne pouvez pas vous contenter de copier-coller le fichier.

Comment gérer les changements de CMS ou de plateforme ?

Un changement de plateforme génère souvent de nouvelles URLs techniques : Shopify crée des /collections/, PrestaShop génère des /index.php?id_category=, Magento ajoute des paramètres de tri. Ces URLs n'existaient pas sur l'ancien site, donc votre robots.txt actuel ne les couvre pas.

Vous devez anticiper ces nouveaux patterns et préparer les règles correspondantes en amont de la migration. Tester sur un environnement de staging est indispensable : déployez le nouveau site en préproduction, crawlez-le avec Screaming Frog ou Oncrawl, et vérifiez que votre robots.txt bloque bien ce qui doit l'être.

Quelles erreurs éviter absolument pendant la transition ?

Ne supprimez jamais toutes les règles « par précaution » en pensant les rétablir plus tard. Vous ouvrirez un boulevard au crawl de Google vers des contenus faibles ou dupliqués, et les dégâts peuvent être durables.

Inversement, ne bloquez pas tout par peur de faire une erreur. Certains SEO placent un Disallow: / temporaire « le temps de voir », ce qui revient à désindexer le site. Le robots.txt n'est pas un interrupteur on/off pour gérer la visibilité : utilisez les balises meta robots pour ça.

• Auditer le robots.txt actuel au moins 30 jours avant la migration
• Cartographier les nouvelles URLs techniques générées par la plateforme cible
• Tester le nouveau robots.txt sur un environnement de staging
• Comparer les règles actuelles avec la nouvelle architecture (correspondance ou obsolescence)
• Documenter chaque directive (pourquoi elle existe, ce qu'elle bloque)
• Prévoir un plan de rollback si un blocage critique apparaît post-migration