Pourquoi l'indexation de la préprod est un problème
Lors d'une refonte ou d'un nouveau projet, il est courant de travailler sur un sous-domaine ou une URL temporaire comme preprod.monsite.com, staging.monsite.com ou monsite.com/dev/. Si cette URL est accessible sans restriction, les robots de Google peuvent la trouver et l'indexer.
Les conséquences sont concrètes :
- Duplicate content : le même contenu existe sur deux URLs différentes (préprod et prod). Google doit choisir quelle version indexer, ce qui dilue l'autorité et brouille les signaux.
- Confusion dans l'index : si la préprod est référencée avant le site final, des URLs temporaires peuvent apparaître dans les résultats de recherche.
- Signaux parasites : des pages incomplètes, des erreurs 404 en masse ou du contenu placeholder ("Lorem ipsum") envoyés à Google créent une mauvaise première impression difficile à corriger.
- Cannibalisation à la mise en ligne : si les deux versions coexistent temporairement, Google peut continuer à indexer la préprod au lieu de la version finale, retardant le positionnement du nouveau site.
Google peut indexer un site en quelques heures si un lien externe y pointe déjà, notamment des liens de partage en équipe, des URLs dans des emails, ou des profils de test sur des plateformes tierces. Ce délai est souvent plus court que la durée d'un projet de refonte. Ne jamais supposer qu'un site "de test" est invisible parce que personne ne le connaît.
Comment bloquer l'indexation d'un environnement de test
Plusieurs méthodes existent, avec des niveaux de protection très différents, et deux d'entre elles s'annulent quand on les combine.
| Méthode | Comment ça fonctionne | Niveau de protection | Limites |
|---|---|---|---|
| Authentification HTTP (htpasswd) | Accès protégé par mot de passe côté serveur. Les robots ne peuvent pas s'identifier. | Très élevé | Bloque aussi les outils de vérification externe |
| Balise meta robots noindex | <meta name="robots" content="noindex"> dans le head de chaque page. |
Élevé | Google doit pouvoir explorer la page pour lire la balise, donc pas de robots.txt bloquant en même temps. Et la préprod reste visible par n'importe qui |
| Fichier robots.txt bloquant | Disallow: / pour tous les robots dans robots.txt. |
Faible | Empêche l'exploration, pas l'indexation. Une URL bloquée mais connue par un lien peut être indexée sans description. Et le blocage cache la balise noindex si elle existe |
| Liste blanche IP | Seules certaines adresses IP peuvent accéder au serveur. | Très élevé | Difficile à gérer avec des équipes distribuées |
| Variable d'environnement + noindex global | Le CMS ou le framework ajoute noindex sur tous les environnements non-production | Élevé | Risque d'oublier de désactiver en production |
Le robots.txt est la méthode la plus utilisée et la moins adaptée. Il interdit l'exploration, pas l'indexation. Google documente qu'une URL bloquée par robots.txt peut tout de même apparaître dans les résultats, sans description, si des liens pointent vers elle. Et il empêche Googlebot de lire la balise noindex qu'on aurait ajoutée par ailleurs, si bien que la combinaison robots.txt et noindex protège moins bien que le noindex seul. L'authentification HTTP reste la protection la plus fiable, parce qu'elle bloque l'accès avant que le contenu soit servi, et parce qu'un code 401 est un code d'erreur client, dont Google retire les URL de son index. C'est celle que j'installe par défaut, avec un noindex en plus pour le cas où le mot de passe serait retiré un jour par erreur.
Checklist SEO avant la mise en ligne
Avant de passer un site en production, voici les points SEO à contrôler systématiquement. Ce sont les erreurs les plus courantes après une migration.
-
Supprimer les protections de préprod
Retirer le mot de passe HTTP, désactiver le noindex global, supprimer ou remplacer le robots.txt de préprod. Vérifier que la production renvoie bien un code 200 et pas un code de redirection vers la préprod.
-
Vérifier les balises canoniques
Contrôler que les balises canoniques pointent vers les bonnes URLs finales de production, et non vers des URLs de préprod ou des variantes incorrectes. Un canonical mal configuré peut empêcher l'indexation pendant des semaines.
-
Tester toutes les redirections 301
Si des URLs ont changé par rapport à l'ancien site, vérifier que les redirections 301 sont en place et qu'elles pointent directement vers la bonne destination (pas de chaînes A → B → C). Utiliser un outil comme httpstatus.io ou Screaming Frog pour vérifier en masse.
-
Contrôler le sitemap XML
Le sitemap doit lister les bonnes URLs finales, être accessible à l'adresse
/sitemap.xmlet ne pas contenir d'URLs en 404, en noindex ou en redirection. -
Vérifier la balise meta viewport (mobile)
<meta name="viewport" content="width=device-width, initial-scale=1">doit être présente. Son absence empêche le rendu mobile correct et peut déclencher des alertes dans la Search Console. -
Connecter et paramétrer la Google Search Console
Soumettre le sitemap dès la mise en ligne. Si le domaine a changé, utiliser la fonction "Changement d'adresse" dans la Search Console pour notifier Google de la migration.
Suivi SEO dans les semaines après la mise en ligne
La mise en ligne n'est pas la fin du travail SEO, c'est le début d'une phase de surveillance active. Les problèmes post-lancement ont tendance à apparaître dans les 2 à 4 premières semaines.
- Surveiller le rapport "Pages" de la Search Console quotidiennement : toute nouvelle erreur 404 ou anomalie d'indexation doit être traitée rapidement, avant que Google en tire des conclusions négatives.
- Vérifier que les URLs prioritaires sont indexées : utiliser l'outil d'inspection d'URL dans la Search Console pour les pages les plus importantes. Si une page n'est pas indexée après 2 semaines, investiguer (noindex résiduel, canonical incorrect, URL bloquée).
- Comparer le trafic semaine par semaine : une chute brutale de trafic organique juste après une mise en ligne est toujours un signal d'alerte. Croiser avec le rapport de couverture pour identifier la cause.
- Tester les Core Web Vitals sur la version production : les performances peuvent varier entre la préprod (serveur moins puissant) et la production. Vérifier que les métriques restent dans les seuils recommandés.
Cas particulier de WordPress
WordPress dispose d'une option native "Demander aux moteurs de recherche de ne pas indexer ce site" dans Réglages > Lecture. Elle ajoute une balise noindex sur toutes les pages. C'est pratique en développement, mais il faut veiller à la décocher avant la mise en ligne. Oublier ce réglage est l'erreur la plus fréquente après une migration. Le nouveau site part en production mais reste en noindex pendant des semaines, parfois des mois.
Pour les plugins SEO WordPress comme Rank Math ou Yoast, vérifiez aussi leurs paramètres d'indexation globaux, parce que certaines configurations de staging désactivent l'indexation au niveau du plugin indépendamment du réglage natif WordPress.
Questions fréquentes
site:preprod.monsite.com (ou l'URL exacte) dans Google. Si des résultats remontent, votre préprod est indexée. Vérifiez aussi la Search Console côté préprod si elle y est connectée.