Comment protéger les environnements de test pré-production (staging)?

Protéger les environnements de test en bref

Prévenez les situations embarrassantes en vous assurant que vous protégez correctement vos environnements de test.

La meilleure façon de procéder est d’utiliser l’authentification HTTP.

Votre environnement de test est-il déjà indexé par les moteurs de recherche ? Pas de problème. Grâce à ce guide, vous apprendrez à inverser rapidement et efficacement cette tendance.

Table des matières

• Pourquoi avoir un environnement de test accessibles est une mauvaise chose?
• Que sont les environnements de développement et de test?
• La sécurité par l’obscurité n’est pas une stratégie viable
• Comment protéger vos environnements de développement et de test?
• Comment savoir si votre environnement de test est indexé ?
• Comment supprimer de l’index votre environnement de test déjà indexé ?

Cela arrive souvent : des environnements de test ou de mise à l’essai contenant des sites web en cours d’élaboration, laissés à la disposition du monde entier. Et souvent, ils sont aussi indexés par les moteurs de recherche !

Vous ne me croyez pas ?

Jetez un coup d’œil à cette requête!

Pourquoi avoir un environnement de test accessible est une mauvaise chose?

Ou plutôt, une double mauvaise chose : mauvaise du point de vue de l’entreprise et du référencement.

Le point de vue des entreprises

Voulez-vous que d’autres personnes voient votre contenu « lorem ipsum » et rient, ou même – Dieu nous en préserve – lisent une annonce importante telle qu’une acquisition ou un changement de marque qui aurait dû être gardé secret jusqu’au lancement du nouveau site ?

Ce n’est pas professionnel et, surtout, ce n’est pas très intelligent. C’est même une tactique de vente pour certaines agences : elles recherchent d’autres agences qui commettent ces erreurs et les proposent ensuite à leurs clients en tirant parti de la situation embarrassante.

Astuce Graines de Référenceur 

Les URL de test indexées permettent aux concurrents de voir les plans de développement futurs. Il leur suffit de suivre une URL de test découverte pour accéder à l’ensemble du site en développement, ce qui signifie que votre future stratégie/conception web est révélée. Une simple recherche dans Google pour site:staging.* ou site:test.* ou tout autre nom commun que les équipes de développement utilisent comme sous-domaines pour leurs environnements de test fait apparaître une pléthore d’environnements de développement, même de marques bien connues, qui n’ont pas suffisamment protégé leur environnement de test.

De plus, comme les environnements de test sont souvent – au mieux – un produit à moitié construit, lorsque les visiteurs tombent dessus, l’expérience utilisateur sera terrible et ne laissera probablement pas une bonne impression.

Le point de vue du référencement

Outre la gêne occasionnée, le fait d’avoir un environnement de test indexé par les moteurs de recherche peut entraîner des problèmes de contenu dupliqué lorsque l’environnement de test et l’environnement de production sont très similaires.

Il est totalement inutile d’avoir des environnements de test accessibles et indexés, car il est facile de l’éviter. Dans cet article, nous vous montrerons comment procéder, quelles méthodes vous pouvez utiliser et que faire si votre environnement de test est déjà indexé.

À partir de maintenant, lorsque nous parlerons d’environnements de test, nous ferons référence à la fois aux environnements de développement et aux environnements de test.

Astuce Graines de Référenceur

Lorsque je vérifie la présence de contenu dupliqué dans le cadre d’un audit de site, je découvre régulièrement des sites de démonstration qui n’ont pas été correctement protégés. Il s’agit parfois de sites de démonstration obsolètes issus de versions antérieures d’un site, mais il m’arrive aussi de découvrir des sites de développement non lancés qui contiennent des informations sensibles qui ne sont pas encore prêtes à être publiées. Les environnements de développement non protégés ne posent pas seulement des problèmes de référencement – ils représentent des risques commerciaux et doivent être traités avec le soin qui s’impose.

Astuce Graines de Référenceur 

J’ai vu de nombreux sites de démonstration indexés. Je pense que l’un des problèmes est que l’indexation et l’exploration ne sont pas pleinement comprises et que l’impact commercial est souvent ignoré.

Veillez à toujours protéger par un mot de passe votre site de préparation AVANT toute autre chose. Une fois qu’elles sont indexées, il est très difficile de supprimer ces URL en temps voulu. Cela peut sembler être une bonne solution, mais dans le cas d’une protection complète de votre environnement de test contre les robots et les humains, les canoniques ne fonctionnent pas, noindex ne fonctionne pas et robots.txt non plus, car il existe d’autres moyens pour les humains, Google (et d’autres moteurs de recherche) de trouver votre contenu.

Outre les problèmes techniques, pensez à l’impact commercial de la découverte de produits et de services avant leur lancement ou de toute autre information sensible. Cela pourrait avoir des conséquences très graves.

Si vos pages sont indexées, réfléchissez à un moyen efficace de supprimer les URL. Créez des listes pour les supprimer en masse et assurez-vous que les moteurs de recherche peuvent « voir » le noindex, donc ne bloquez pas les robots d’indexation par le biais de robots.txt.

Astuce Graines de Référenceur 

Je rencontre régulièrement deux problèmes sur ce front : les sites de test auto-hébergés (tels que WPEngine qui génère automatiquement staging.domain.com), et les sites de test sur les propres domaines des développeurs web (par exemple client.developer.com et developer.com/client/).

Dans le premier scénario, vous courez le risque d’avoir un contenu dupliqué indexable sur votre propre domaine, et le simple fait de bloquer un domaine via robots.txt ne garantit pas qu’il ne sera pas indexé, en particulier si vous ou d’autres personnes créez un lien vers ce domaine (ce qui est courant, car les liens vers les ressources du site de test se retrouvent souvent dans le code du site et ne sont pas pris en compte au moment du lancement).

Dans le second scénario, avec un miroir de votre site sur le domaine d’un développeur, vous courez le risque d’un contenu dupliqué d’un domaine à l’autre, et comme le contenu a d’abord été publié sur le domaine du développeur, il y a un risque que Google vous considère comme le duplicateur et lui comme la source originale (ce qui n’est pas une bonne situation).

Bloquez toujours, toujours, les robots pour qu’ils n’atteignent pas vos environnements de test. Pas seulement avec un fichier robots.txt, mais avec quelque chose de plus sûr (login/mot de passe, accès IP restreint ou les deux).

Deuxièmement, assurez-vous toujours que vos développeurs vérifient tout le code de votre site au moment du lancement et suppriment tout lien vers l’environnement de test. Vous voulez que vos liens internes pointent vers le site réel, pas ailleurs.

Si vous faites les deux, vous serez en bonne position !

Que sont les environnements de développement et de test ?

Lorsque vous travaillez sur un site web entièrement nouveau ou sur une nouvelle fonctionnalité, vous ne devez pas vous contenter de le faire sur votre site web en direct (souvent appelé « environnement de production »), car les sites web sont faciles à briser. La meilleure pratique consiste à travailler dans des environnements différents et distincts pour développer et tester les nouvelles fonctionnalités.

Quels sont les autres environnements ?

• Environnement de développement : c’est l’endroit où les développeurs testent initialement leur code. Souvent, ils le font sur leurs machines locales. Si c’est le cas, il n’y a aucun risque que cet environnement soit accessible à d’autres personnes et qu’il soit indexé par les moteurs de recherche. S’il n’est pas conservé localement, mais par exemple sur un sous-domaine dev.exemple.com, il y a un risque qu’il soit accessible à d’autres personnes et/ou qu’il soit indexé.
• Environnement de test ou de mise à disposition  : c’est ici que les versions sont mises à disposition et que les nouvelles fonctionnalités sont testées avant la sortie d’une version. Les nouveaux contenus sont publiés dans cet environnement afin d’être vérifiés et de s’assurer qu’ils sont conformes aux attentes. Souvent, les environnements de test ne sont pas exécutés localement : différents membres de l’équipe doivent pouvoir y accéder facilement, et ils sont donc généralement exécutés sur un sous-domaine ou un domaine séparé.

La sécurité par l’obscurité n’est pas une stratégie viable

Ne parler à personne de votre environnement de test « secret » est un cas de « sécurité par l’obscurité ». Ce n’est pas une stratégie réalisable. Surtout pas en tant que seule couche de protection.

Que se passe-t-il si quelqu’un publie accidentellement un lien vers l’environnement de test? Ou si quelqu’un met en production un code qui inclut accidentellement des références canoniques ou hreflang à ce même environnement ?

Non seulement cela crée des problèmes dans votre environnement de production, mais cela conduit également les moteurs de recherche à capter « l’odeur » de votre environnement de test. Ils le mettront en file d’attente pour l’explorer, à moins que vous ne leur rendiez l’accès à l’environnement de test impossible ou que vous ne leur donniez des règles d’engagement à suivre.

Astuce Graines de Référenceur

Un grand site d’entreprise avait perdu beaucoup de trafic et de classement. Il s’est avéré qu’ils avaient décidé de lancer leur site bêta sans authentification HTTP afin que leurs parties prenantes puissent consulter le site pendant six mois avant d’achever leur refonte.

Malheureusement, le site bêta a commencé à accumuler des backlincks – plus de 5 000 d’entre eux provenant de grands journaux. L’utilisation du site bêta a également entraîné une perte de trafic de 50.000 visiteurs par mois pour le domaine principal lorsqu’il a été « relancé », en partie à cause du serveur d’essai (et d’autres problèmes). L’organisation a fini par migrer tout contenu unique vers le domaine principal et par tout rediriger par 301. Après environ un an, le site a presque retrouvé son niveau de trafic antérieur.

Comment protéger vos environnements de développement et de test?

La raison pour laquelle vous devez protéger vos environnements de développement et de test est désormais claire. Mais comment faire ? Il existe plusieurs façons de procéder, mais laquelle est la meilleure ?

Nous allons examiner les avantages et les inconvénients de chaque méthode, en tenant compte de ce qui suit :

1. 1. Convivialité : la mesure dans laquelle la méthode n’ajoute pas d’inconvénients supplémentaires.
   2. Accès des tiers : la mesure dans laquelle la méthode empêche les tiers d’accéder à un environnement.
   3. Facilité de référencement : la mesure dans laquelle la méthode empêche les moteurs de recherche d’indexer un environnement.
   4. Facilité de surveillance : le degré auquel la méthode vous permet de surveiller les environnements protégés à des fins de référencement.
   5. Faible risque d’erreur humaine : cette méthode présente-t-elle un faible risque d’erreur humaine ayant un impact sur le référencement ?

Méthode 1 : L’authentification HTTP – votre meilleur choix 🏆

La meilleure façon d’empêcher les utilisateurs et les moteurs de recherche d’accéder à vos environnements de développement et de préparation est d’utiliser l’authentification HTTP.

Veillez toutefois à la mettre en œuvre en utilisant HTTPS, car vous ne voulez pas que les noms d’utilisateur et les mots de passe voyagent librement sur le réseau.

Nous vous recommandons d’établir une liste blanche des adresses IP de votre bureau et de permettre aux parties externes et aux membres de l’équipe distante d’accéder à votre site au moyen d’une combinaison nom d’utilisateur/mot de passe.

De cette manière, les moteurs de recherche ne peuvent accéder à rien et vous avez un contrôle total sur qui peut voir quoi.

Vous pouvez préparer votre environnement de test avec le même fichier robots.txt que celui que vous utiliserez dans l’environnement de production, ainsi qu’avec les directives robots et canoniques corrects.

Cela vous permet d’obtenir une image représentative de votre environnement de test lorsque vous le surveillez pour détecter les problèmes et les changements avant le lancement.

Un autre avantage est que les développeurs n’ont pas tendance à oublier de publier les bons robots.txt, directives robots et des liens canoniques sur l’environnement de production.

Cette approche est bien meilleure que l’utilisation de directives robots.txt et/ou robots noindex et de liens canoniques, car ceux-ci n’empêchent pas d’autres personnes d’y accéder, et les moteurs de recherche ne respectent pas toujours ces directives.

De plus, lorsque l’on utilise l’authentification HTTP, il est toujours possible d’utiliser les outils de test de Google tels que AMP, Mobile-friendliness et Structured Data Testing Tool (outil de test des données structurées). Il suffit de mettre en place un tunnel.

Astuce Graines de Référenceur 

Protégez votre environnement de test par un mot de passe, c’est tout. Rien d’extraordinaire, il suffit de le protéger par un mot de passe. Google ne peut pas voir l’autre côté de la protection par mot de passe (à moins que vous ne mettiez en place un tunnel à des fins de test). Même si vous utilisez un fichier robots.txt Disallow : / et meta robots noindex, il est possible que des pages soient indexées s’il y a suffisamment de liens et/ou d’autres signaux pointant vers elles.

Astuce Graines de Référenceur 

De nombreux outils SEO sont déjà configurés pour gérer l’authentification HTTP pour l’exploration et le test de ce type de configuration. Il est possible que vous souhaitiez explorer un peu plus lentement que d’habitude car les configurations de test n’ont généralement pas autant de ressources allouées ou n’ont pas de mise en cache, vous devez donc être plus prudent que d’habitude sur la charge que vous mettez sur le système.

Astuce Graines de Référenceur 

Les environnements de test doivent toujours être bien protégés. Les utilisateurs ne doivent pas pouvoir les consulter ; votre nouvelle version peut comporter de nombreux bogues, ce qui peut entamer la confiance des utilisateurs. Elle peut également être vulnérable aux attaques de pirates informatiques. En outre, vous ne voulez pas que Google l’indexe (afin d’éviter les problèmes de contenu dupliqué).

Mais comment tester un site de test à l’aide des outils de Google ? Que faire si vous souhaitez utiliser l’outil Inspection des URL pour vous assurer que Google peut afficher correctement votre site Web ? Et si vous souhaitez tester la mise en œuvre de Schema.org à l’aide de l’outil Structured Data Testing ?

Deux possibilités s’offrent à vous :

1. Vous pouvez mettre en place un tunnel (comme mentionné ci-dessus).
2. Vous pouvez mettre les adresses IP de Google sur liste blanche (66.x) et leur permettre ainsi d’y accéder. Parce que cela peut être délicat, vous devez limiter la période pour laquelle vous avez mis les adresses IP de Google sur liste blanche et pendant toute la durée de la période de mise sur liste blanche, vous devez vous assurer que votre version de test n’est pas indexable !

Méthode 2 : Accès VPN

VPN est l’abréviation de « virtual private network » (réseau privé virtuel). Vous connectez votre machine locale de manière à faire partie du réseau de l’entreprise.

Maintenant que vous faites partie du réseau de l’entreprise, vous pouvez accéder à l’environnement de test. Quiconque ne fait pas partie du réseau ne peut pas y accéder.

Cela signifie que ni les tiers ni les moteurs de recherche ne peuvent accéder à l’environnement de préparation.

L’accès via un VPN offre la plupart des avantages de l’authentification HTTP. Cependant, il y a un gros inconvénient : Les solutions de surveillance du référencement qui ne sont pas exécutées localement peuvent ne pas fonctionner dans leur version initiale, voire pas du tout.

L’impossibilité de suivre les progrès de votre équipe de développement est gênante, et cela devient vraiment problématique lorsque vous avez affaire à de très gros sites web.

Méthode 3 : Directives Meta Robots

Les Directives Meta Robots sont utilisées pour communiquer des préférences en matière d’exploration et d’indexation. Vous pouvez par exemple demander aux moteurs de recherche de ne pas indexer certaines pages et de ne pas suivre (certains) liens.

Vous pouvez définir des directives « robots » dans l’en-tête HTTP d’une page (en-tête X-Robots-Tag) ou via la directive « meta robots » dans la section <head>.

Étant donné que vous aurez d’autres types de contenu que des pages dans votre environnement de test, il est recommandé d’utiliser l’en-tête X-Robots-Tag pour vous assurer que les fichiers PDF, par exemple, ne soient pas indexés.

Les Directives Meta Robots, comme leur nom l’indique, sont destinées aux robots (« crawlers »). Elles n’empêchent pas l’accès des tiers.

Elles envoient un signal modérément fort aux moteurs de recherche pour qu’ils n’indexent pas les pages. Je dis « modérément » parce que les moteurs de recherche peuvent toujours décider d’ignorer les directives pour les robots et d’indexer vos pages.

Il ne s’agit pas non plus d’une solution facile à surveiller, car, comme dans le cas de robots.txt, les outils de référencement peuvent signaler des faux positifs.

En outre, le risque d’erreur humaine est énorme, car les Directives Meta Robots en phase de test sont souvent transférées accidentellement dans l’environnement de production.

Méthode 4 : Robots.txt

Le fichier robots.txt énonce les règles d’engagement pour les robots d’indexation.

En utilisant le fichier robots.txt, vous pouvez demander aux moteurs de recherche de ne pas accéder à votre environnement de test. La méthode la plus courante consiste à inclure le contenu suivant dans le fichier robots.txt :

User-agent: *

Disallow: /

Cela empêche les robots des moteurs de recherche d’explorer le site, mais ils peuvent toujours l’indexer s’ils trouvent des liens vers lui, ce qui conduit à des listes comme celles-ci :

Certaines personnes incluent la directive non officielle Noindex dans leur fichier robots.txt. Nous ne recommandons pas de le faire, car c’est une pire façon d’empêcher l’accès à votre environnement de test que d’utiliser une directive Disallow, puisqu’il s’agit en réalité d’une directive non officielle.

Votre fichier robots.txt n’offre aucune protection réelle contre l’accès de tiers au site, et il perturbe également les outils de surveillance du référencement, ce qui peut entraîner des résultats faussement positifs.

De plus, vous créez un énorme risque d’erreur humaine : ici encore, le fichier robots.txt de l’environnement de test est souvent transféré accidentellement dans l’environnement de production.

Astuce Graines de Référenceur 

Le simple fait d’ajouter un fichier robots.txt aux environnements de test ou d’ajouter le dossier de l’environnement de test à un site réel n’est pas une stratégie recommandée, car cela revient à donner aux concurrents (ou à toute autre personne) un accès direct à l’environnement.

En outre, les moteurs de recherche peuvent toujours indexer les URL ajoutées à un fichier robots.txt, en particulier si une URL est liée (par exemple, lorsque ce développeur télécharge un fichier sur le site avec un lien vers l’environnement de test, ce qui augmente sa popularité).

Nous voyons souvent des pages indexées qui ne devraient pas l’être et la méta-description dit simplement quelque chose comme « nous n’avons pas d’autres informations à ce sujet puisque le moteur de recherche ne peut pas réellement accéder à la page (il a seulement découvert et indexé l’URL, sur la base d’autres signaux) pour voir ce qu’il y a dedans ».

Méthode 5 : liens canoniques

Le lien canonique informe les moteurs de recherche de la version canonique d’une page. Si l’environnement de test fait référence à l’environnement de production, tous les signaux doivent être consolidés avec l’environnement de production.

Dans le cas contraire, les liens canoniques ressemblent à des Directives Meta Robots, surtout en ce qui concerne leurs inconvénients :

• Ils permettent toujours à des tiers d’accéder à l’environnement de préparation.
• Ils ne constituent pas une solution facile à surveiller, car ils peuvent donner lieu à des faux positifs signalés par les outils de référencement.
• Il existe un risque d’erreur humaine, car les directives canoniques de l’environnement de test sont parfois transférées accidentellement dans l’environnement de production.

Méthode 6 : mise sur liste blanche d’agents utilisateurs spécifiques

La mise sur liste blanche d’agents utilisateurs spécifiques pour l’accès à un environnement de test peut être utilisée pour permettre aux spécialistes du référencement de surveiller un environnement de préparation, à condition que leur outil de référencement prenne en charge la définition d’agents utilisateurs personnalisés.

Ils peuvent créer un agent utilisateur personnalisé et l’utiliser, tout en bloquant tous les autres agents utilisateurs (y compris les navigateurs).

Mais cette approche n’est pas très conviviale, car la vérification manuelle par le biais du navigateur est plus difficile. Ce n’est pas non plus une approche très sûre : Lorsque des tiers savent que vous travaillez pour ou dans l’entreprise X et qu’ils connaissent votre agent utilisateur (peut-être parce qu’il s’agit d’un client mécontent ou d’une personne malveillante), ils peuvent être en mesure d’accéder à l’environnement de test.

Comment savoir si votre environnement de test est indexé ?

Il existe plusieurs façons de savoir si votre environnement de test est indexé. Voici les trois méthodes les plus courantes :

Option 1 : requête de site

Si vous savez que votre environnement de test fonctionne sur un sous-domaine, vous pouvez essayer une requête de site telle que : site:example.com -inurl:www

Cette requête renvoie toutes les pages indexées par Google pour le domaine exemple.com, à l’exception de celles qui contiennent « www ».

Option 2 : Google Analytics

Si vous ne connaissez pas l’URL de votre environnement de test, vous pouvez essayer de vérifier dans Google Analytics :

• Naviguez vers Audience > Technologie et choisissez Réseau.
• Sélectionnez Hostname (nom d’hôte) comme Primary Dimension (dimension primaire).
• Recherchez les noms d’hôte qui ont un domaine différent ou qui contiennent des sous-domaines tels que staging, test ou dev.

Option 3 : Google Search Console

Avec la consolidation des propriétés dans Google Search Console, il est désormais beaucoup plus facile de repérer les pages qui ne devraient pas être indexées.

Que votre environnement de test soit configuré sur un domaine distinct, un sous-domaine ou un sous-dossier, si vous avez vérifié le domaine, vous pourrez voir toutes les pages indexées et toutes les requêtes pour lesquelles votre domaine est classé. Tout cela dans les aperçus que vous avez l’habitude de consulter ;

• Performance > Requêtes
• Performances > Pages
• Index > Couverture

Astuce Graines de Référenceur 

La configuration de Google Search Console pour un environnement de développement vous permettra de savoir si quelque chose a été indexé ou non et vous donnera la possibilité de supprimer rapidement toute URL qui se serait accidentellement glissée dans l’index. 

Il faut aussi vous assurer qu’il y a bien des instructions pour qu’un crawler n’indexe rien à partir du serveur de développement.

Comment supprimer de l’indexation un environnement de test déjà indexé?

Oh, oh ! Votre environnement de test a déjà été indexé par les moteurs de recherche et vous devez y remédier? La bonne nouvelle, c’est que si vous suivez les étapes ci-dessous, tout ira bien. Et c’est facile.

Étape 1 : masquer les résultats de recherche

Vérifiez l’environnement de test dans les outils pour webmasters tels que Google Search Console et Bing Webmaster Tools et supprimez l’URL (voir la documentation de Google et celle de Bing à ce sujet). 

Pour Google, cette demande est souvent acceptée en quelques heures (pour Bing, c’est un peu plus long), et votre environnement de test n’apparaîtra plus dans les résultats de recherche. 

Mais le hic, c’est qu’il figure toujours dans les index de Google et de Bing ; il n’est tout simplement pas affiché. Dans le cas de Google, l’environnement de test n’est caché que pendant 90 jours. Pendant cette période, vous devez donc veiller à demander la suppression de vos pages des index des moteurs de recherche de la bonne manière : via la directive « robots noindex« .

Étape 2 : application de la directive noindex et nouvelle exploration des pages

Veillez à appliquer la directive « robots noindex » à toutes les pages de votre environnement de test. Pour accélérer le processus d’exploration de ces pages par les moteurs de recherche, soumettez un sitemap XML. 

Surveillez maintenant les journaux de votre serveur pour voir si les robots d’indexation des moteurs de recherche demandent les pages précédemment indexées (et maintenant « noindexées »), afin de vous assurer qu’ils ont « compris le message ».

Dans la plupart des cas, ces 90 jours sont suffisants pour signaler aux moteurs de recherche qu’ils doivent supprimer les pages de l’environnement de mise en scène de leur index. Si ce n’est pas le cas, il suffit de nettoyer et de répéter l’opération.

Une fois que tout est terminé, protégez l’environnement de mise en scène à l’aide de l’authentification HTTP pour vous assurer que cela ne se reproduira pas et supprimez le sitemap XML de Google Search Console et de Bing Webmaster Tools.