Configurer un robots.txt différent entre préproduction et production

Comment un mutualisé qui héberge à la fois le site de préproduction et, à terme, le site de production sur des sous-domaines voisins peut-il servir un robots.txt différent selon l’environnement, sans dupliquer le thème ni oublier de reconfigurer quoi que ce soit le jour de la bascule ?

La réponse tient dans une variable définie une bonne fois pour toutes dans wp-config.php, couplée au filtre robots_txt de WordPress. Le fichier physique robots.txt n’existe alors même plus sur le serveur : WordPress le génère à la volée, et son contenu dépend de l’environnement détecté.

Le risque concret d’un mutualisé partagé

Sur un hébergement mutualisé, il est fréquent de placer la préproduction sur un sous-domaine du type preprod.exemple.fr, en clonant régulièrement la base et les fichiers depuis la production. Le problème apparaît quand ce clonage recopie aussi un robots.txt permissif : le sous-domaine de préproduction se retrouve alors explorable, puis indexé, avec un contenu parfois daté ou incomplet qui vient concurrencer les pages réelles dans les résultats de recherche.

Un simple oubli de configuration suffit à provoquer ce scénario, et il passe souvent inaperçu plusieurs semaines, le temps que Google Search Console signale des pages indexées sur un domaine qui ne devrait jamais apparaître dans les résultats.

Définir l’environnement dans wp-config.php

La constante WP_ENVIRONMENT_TYPE, reconnue nativement par WordPress depuis la version 5.5, permet de déclarer explicitement le type d’environnement. Elle accepte les valeurs local, development, staging et production :

// wp-config.php de l'environnement de préproduction
define( 'WP_ENVIRONMENT_TYPE', 'staging' );

Sur le serveur de production, cette même constante prend la valeur production. C’est cette unique différence entre les deux fichiers wp-config.php qui va piloter le contenu du robots.txt généré.

Étape par étape : le filtre robots_txt

1. Dans functions.php du thème, ou dans une extension maison chargée tôt, on accroche une fonction au filtre robots_txt.
2. Cette fonction teste la valeur de retour de wp_get_environment_type(), la fonction native qui lit la constante définie plus haut.
3. Si l’environnement n’est pas production, on remplace intégralement le contenu par un Disallow: / général.
4. Sinon, on laisse passer le contenu par défaut généré par WordPress, basé sur les réglages de visibilité du site.

add_filter( 'robots_txt', function ( $output, $public ) {
    if ( 'production' !== wp_get_environment_type() ) {
        return "User-agent: *\nDisallow: /\n";
    }
    return $output;
}, 10, 2 );

Ce filtre s’applique que le réglage « Visibilité par les moteurs de recherche » des réglages de lecture soit coché ou non, ce qui protège contre un oubli lors d’un clonage de base de données qui aurait réactivé l’indexation par erreur.

Compléter par une protection HTTP

Le robots.txt reste une simple directive que les robots respectueux suivent, mais qu’un robot mal intentionné peut ignorer. Pour un mutualisé, deux protections complémentaires renforcent le dispositif :

• Une en-tête X-Robots-Tag: noindex envoyée uniquement en environnement non-production, via une condition similaire dans le fichier de configuration du serveur ou un filtre wp_headers.
• Une restriction d’accès par identifiant et mot de passe au niveau du serveur, qui empêche purement et simplement tout robot d’atteindre les pages de préproduction.

Sur un mutualisé, il ne faut jamais compter sur une seule ligne de défense : le robots.txt ferme la porte poliment, l’authentification HTTP la verrouille vraiment.

Le jour de la mise en ligne

Cette approche a un avantage décisif au moment de la bascule : il n’y a rien à modifier manuellement. Le contenu du site de préproduction devient celui de production simplement en changeant la valeur de WP_ENVIRONMENT_TYPE dans le fichier de configuration correspondant, ou en pointant le domaine final vers le bon environnement. Le robots.txt s’ajuste automatiquement, sans étape supplémentaire à cocher dans une liste de vérification qui pourrait être oubliée sous la pression du planning.

En résumé

Piloter le robots.txt depuis une constante d’environnement plutôt que depuis un fichier statique élimine le risque d’oubli le plus fréquent sur les hébergements mutualisés qui partagent production et préproduction. La fonction native wp_get_environment_type(), disponible depuis WordPress 5.5, rend cette solution accessible sans extension, et la combinaison avec une authentification HTTP côté serveur ferme le sujet durablement.