Robots.txt Next.js, bloquer sans se tromper

Même convention que pour le sitemap, on ne réinvente rien. Un fichier nommé robots.ts, placé à la racine du dossier app, génère le fichier robots.txt servi à la racine du site.

Il exporte une fonction par défaut nommée robots, qui renvoie un objet. Cet objet contient 2 choses utiles.

• Le champ rules, avec le robot visé, ce qu'il peut explorer et ce qu'il ne peut pas.
• Le champ sitemap, avec l'adresse complète de votre sitemap, dont la génération est détaillée dans notre article dédié.

Un point qui surprend tout le monde. Vous pouvez très bien déposer un fichier robots.txt statique dans le dossier public. Le format TypeScript n'apporte rien de plus au robot, il apporte quelque chose à votre équipe. Vous construisez vos règles avec des variables, vous adaptez le comportement entre la préproduction et la production, et le fichier reste versionné avec le reste du code.

Ce dernier usage est le plus précieux. Une préproduction accessible et explorée par Google est un problème classique, qui met des semaines à se réparer. Une condition sur la variable d'environnement suffit à tout bloquer sur cet environnement, et rien sur le site réel.

Le fichier se vérifie en mode développement, à l'adresse robots.txt.

La liste est courte, et beaucoup de tutoriels en ajoutent qui ne servent à rien.

• user-agent. Le robot visé. L'astérisque désigne tous les robots. La règle la plus spécifique l'emporte sur la règle générale.
• disallow. Les chemins interdits. Un chemin terminé par une barre oblique couvre tout ce qui se trouve en dessous.
• allow. Les exceptions à une interdiction. Utile pour bloquer un dossier entier tout en laissant passer une page précise.
• sitemap. L'adresse de votre sitemap, en adresse complète.

Tout le reste est ignoré par Google. Le champ crawl-delay, qui apparaît dans quantité d'exemples, n'a jamais eu d'effet sur son exploration. Bing et Yahoo, eux, le respectent. Si vos serveurs souffrent d'un robot trop insistant, c'est donc une piste valable, mais pas pour Google.

Ce qu'on bloque utilement sur un projet Next.js.

• Les routes d'API, qui n'ont aucune raison d'apparaître dans les résultats.
• L'espace d'administration et les tunnels de connexion.
• Les pages de résultats de recherche interne, qui génèrent une infinité d'adresses au contenu quasi identique.
• Les pages de confirmation après formulaire ou paiement.

C'est l'erreur la plus fréquente, et elle produit exactement l'inverse du résultat recherché.

Les 2 mécanismes ne font pas la même chose.

• Le robots.txt bloque l'exploration. Le robot ne lit pas la page. Il peut malgré tout en connaître l'existence par un lien venu d'ailleurs, et l'afficher dans les résultats sans description.
• Le noindex bloque l'indexation. Le robot lit la page, y trouve la consigne, et ne l'affiche pas.

D'où le piège. Bloquer une page dans robots.txt et lui poser un noindex ne fonctionne pas, puisque le robot bloqué n'entre jamais dans la page et ne lira jamais la consigne. Le résultat est une adresse fantôme qui reste listée.

La règle pratique est simple. Pour qu'une page n'apparaisse jamais dans les résultats, utilisez le noindex et laissez l'exploration ouverte. Pour économiser du temps d'exploration sur des zones sans intérêt, utilisez le robots.txt.

Un rappel de sécurité qui vaut d'être écrit. Un robots.txt est un fichier public, lisible par tous. Y lister vos chemins sensibles revient à publier la carte de ce que vous voulez cacher. Ce fichier gère la politesse des robots, jamais la confidentialité. Le réglage page par page est détaillé dans notre article sur la metadata Next.js.

Le paysage a changé. À côté de Google et Bing, une nouvelle famille de robots parcourt le web pour alimenter des modèles et pour répondre en direct aux questions des utilisateurs.

La décision se prend en 2 temps.

• Les robots d'entraînement collectent votre contenu pour construire des modèles. Les bloquer se défend, en particulier sur un contenu original et coûteux à produire.
• Les robots de réponse vont chercher une page au moment où quelqu'un pose une question, et citent la source. Les bloquer vous retire des réponses générées, qui deviennent un vrai canal de visites.

Notre position pour un site d'entreprise, et elle est tranchée. Sur du contenu qui sert à être trouvé, vous laissez passer. La visibilité dans une réponse d'intelligence artificielle vaut aujourd'hui davantage qu'une protection illusoire, puisque votre page reste de toute façon accessible à qui la lit.

Le second sujet concerne les robots d'outils d'analyse, qui explorent parfois de façon très soutenue et pèsent sur les serveurs. En Next.js, le champ rules accepte un tableau, ce qui permet de poser une règle spécifique par robot. Vous laissez tout ouvert par défaut et vous restreignez uniquement ceux qui posent problème.

Ces choix se relisent 2 fois par an. La liste des robots évolue vite, et un fichier écrit il y a 18 mois ne décrit plus le web d'aujourd'hui.