Google peut-il vraiment voir votre site ?

Qu'est-ce que ce fichier au juste

Chaque site web a, ou devrait avoir, un fichier nommé robots.txt. Vous le trouvez en tapant /robots.txt après votre nom de domaine, par exemple votreentreprise.fr/robots.txt. Ce fichier est le premier que Google lit avant de regarder votre site. Il est en texte brut et indique aux moteurs de recherche quelles parties du site ils peuvent et ne peuvent pas visiter.

Vous pouvez le comparer à une pancarte à l'entrée d'un bâtiment. Certaines portes sont ouvertes, d'autres sont fermées avec un simple papier. Le problème, c'est que les entreprises mettent parfois le mauvais papier par accident. Au lieu de fermer une arrière-porte, elles ferment le bâtiment entier aux visiteurs, y compris les salles les plus importantes.

Au-delà des chemins qui peuvent ou non être visités, il y a quelque chose de plus subtil : les fichiers qui construisent la page. Pensez au CSS, qui crée la mise en page, et à JavaScript, qui crée le mouvement et l'interactivité sur la page. Si robots.txt bloque ces fichiers, Google peut visiter la page, mais ne peut pas bien la voir. Il voit alors une version nue et cassée de votre site.

Cela est étroitement lié à un autre point de contrôle : si votre contenu principal est aussi accessible sans JavaScript, comme nous l'expliquons dans le contenu principal est accessible sans JavaScript. Ces deux points portent sur la même question : Google peut-il voir votre page comme un visiteur la voit, ou Google obtient-il une image incomplète qui fait mauvais score.

Pourquoi c'est plus qu'un détail technique

Google utilise un processus appelé rendu : le moteur de recherche construit essentiellement votre page, exactement comme le ferait un navigateur, pour voir ce qu'un visiteur verra vraiment. Cela ne peut fonctionner que si Google a accès à tous les éléments nécessaires. Si le CSS ou JavaScript est bloqué, Google voit une page nue sans mise en page, sans menu, parfois sans le texte chargé par des scripts.

En conséquence, Google estime mal ce que votre page traite. Une page qui semble bien pour les visiteurs peut sembler incompréhensible ou vide pour Google. Ce n'est pas une question de score un peu moins bon. C'est une question de ne pas être inclus, alors que vous n'avez rien fait de mal au contenu lui-même.

Il y a une différence entre une page qui n'existe pas et une page qui existe mais a été rendue inaccessible. Cela touche aussi à d'autres points de notre liste de contrôle, comme la question de savoir si une page supprimée renvoie correctement un statut 404, comme nous l'expliquons dans la page 404 elle-même est utile. Dans les deux cas, il s'agit de clarté : montrez à Google ce qui est et n'est pas destiné à être trouvé.

Comment vérifier vous-même si tout va bien chez vous

Tapez votre nom de domaine suivi de /robots.txt dans la barre d'adresse de votre navigateur. Une simple liste de règles apparaît, généralement avec des mots comme « Disallow » suivi d'un chemin. Disallow signifie : ce chemin ne peut pas être visité. Vérifiez s'il y a quelque chose d'inattendu, comme une simple barre oblique, ce qui signifie que tout le site est fermé.

Faites particulièrement attention aux règles qui font référence à des dossiers avec des noms comme /wp-content/, /assets/, /css/ ou /js/. Ce sont souvent exactement les dossiers qui contiennent la mise en page et l'interactivité de votre site. Si ceux-ci sont bloqués, il y a de fortes chances que Google ne puisse pas bien afficher vos pages, même si le reste du fichier semble inoffensif.

Google Search Console, un service gratuit de Google pour les propriétaires de sites web, dispose d'un test permettant de vérifier une page spécifique pour les problèmes de rendu. Vous y voyez un exemple de la façon dont Google perçoit votre page. Si cela semble nu ou cassé alors que la page semble bien dans votre navigateur, c'est un signal clair que quelque chose ne va pas lors du chargement du CSS, JavaScript ou des images.

Si vous doutez qu'un chemin particulier soit intentionnellement exclu ou accidentellement, consultez la personne qui a construit votre site web. Certains blocages sont délibérés et judicieux, comme l'exclusion d'une page de résultats de recherche interne, sujet que nous abordons séparément dans nos pages de résultats de recherche interne avec noindex. D'autres blocages sont simplement des erreurs dues à un paramètre par défaut qui n'a jamais été vérifié.

Ce que cela coûte si ce n'est pas en ordre

Si robots.txt bloque des chemins importants, vous fermez sans le remarquer des parties de votre site à Google. Il peut s'agir de pages produits, d'articles de blog, ou même de tout le site après une migration vers un nouveau système. Cela arrive plus souvent qu'on ne le pense, particulièrement après une refonte de site web, lorsqu'un paramètre destiné à l'environnement de test reste accidentellement actif sur le site en production.

Le problème insidieux, c'est que vous ne le remarquez pas dans votre utilisation quotidienne du site. Les pages se chargent normalement, les visiteurs qui reçoivent le lien directement peuvent toujours y accéder. C'est uniquement le trafic provenant des moteurs de recherche qui diminue progressivement, sans raison apparente. De nombreux entrepreneurs attribuent alors le problème au contenu ou à la concurrence, alors que le problème réside dans un fichier technique qu'ils n'ont jamais ouvert.

Lorsque seuls les CSS et JavaScript sont bloqués, l'effet est plus subtil mais tout aussi dommageable. Vos pages restent trouvables, mais Google les évalue sur la base d'une image incomplète. Le texte chargé par un script peut alors ne pas compter. Une page qui vous semble parfaite s'affiche aux yeux de Google comme pauvre en contenu, avec toutes les conséquences pour votre positionnement dans les résultats de recherche.

La correction n'est généralement pas une affaire de mois de travail. Souvent, il s'agit d'ajuster quelques lignes dans un fichier. Le point clé est de d'abord reconnaître le problème. Sans contrôle, un blocage peut rester inaperçu pendant des années, simplement parce que personne n'a plus regardé après la dernière modification du site.

Ce qui doit être fait pour mettre cela en ordre

Le principe est simple : robots.txt ne doit bloquer que les chemins que vous souhaitez volontairement exclure, comme une page de connexion pour administrateurs ou un panier d'achat qui ne devrait jamais apparaître dans les résultats de recherche. Tout ce qui contribue à l'apparence ou au fonctionnement de la page doit rester accessible. C'est tout le principe de ce point de contrôle : ne pas tout verrouiller par précaution, mais bloquer délibérément quand c'est nécessaire.

Faites examiner ce fichier dans le cadre d'un aperçu plus large de ce qui doit et ne doit pas être indexé. Cet aperçu, une matrice d'indexation par type de page, cartographie les pages qui doivent être visibles à Google et celles qui ne doivent pas l'être intentionnellement, comme nous l'expliquons dans une matrice d'indexation par type de page. Robots.txt est alors l'instrument avec lequel ces choix sont mis en œuvre, non pas le lieu où ces choix sont pris.

Ne contrôlez pas ce fichier uniquement lors de la construction du site, mais aussi après chaque modification importante : une migration vers un autre système, un nouveau constructeur de site web, ou une restructuration du site. Ce sont précisément les moments où les paramètres sont accidentellement repris d'un environnement de test. Une brève vérification après coup évite qu'un paramètre temporaire ne devienne permanent.

Gardez également à l'esprit que robots.txt ne fonctionne pas isolément. Il est étroitement lié à d'autres signaux que vous envoyez à Google, comme l'instruction au niveau de la page via une balise noindex, dont nous parlons plus dans noindex via meta robots ou la X-Robots-Tag. Les deux ne doivent pas se contredire. Une page que vous souhaitez afficher ne doit pas être ouverte par un canal et reste bloquée par un autre.