Indexabilité

La panne que ce contrôle attrape n'a aucun symptôme ailleurs. Un robots.txt de préproduction expédié par-dessus le vrai, un noindex oublié sur l'accueil après une refonte, un canonical qui pointe encore vers localhost — chaque URL répond 200, la disponibilité est parfaite, et le trafic organique meurt deux jours plus tard. À ce moment-là, le déploiement responsable est vingt déploiements en arrière. C'est un contrôle du site : créé par PostShip, hors quota, exécuté à chaque déploiement.

Ce que PostShip vérifie

Deux requêtes, en parallèle : robots.txt à la racine, et la page d'accueil. Tout est une lecture de document — pas de robot d'exploration, pas d'API Search Console, rien qui demande un navigateur.

1. robots.txt en erreur serveur. Un 5xx n'est pas « pas de robots.txt » : les moteurs le lisent comme un blocage temporaire du site entier, ce qui est pire qu'un 404. Un 404 est normal et autorise tout.
2. Disallow: / pour tout le monde. Le fichier est lu groupe par groupe, pas par recherche de texte : Disallow: / ne veut dire « tout bloquer » que dans un groupe User-agent: *, et un Disallow: /admin dans le même fichier est normal. Un groupe qui porte aussi Allow: / n'est pas un blocage — les deux règles ont la même longueur et le protocole tranche en faveur de Allow. Un groupe qui vise un robot nommé n'est pas un blocage du site.
3. L'en-tête X-Robots-Tag de la page d'accueil : noindex ou none retire la page de l'index. Il pèse autant que la balise et se pose plus facilement par accident, depuis un proxy ou une configuration de framework.
4. La balise meta name="robots" : mêmes deux directives. nofollow, noarchive et les autres changent la façon dont la page est traitée, pas le fait qu'elle soit listée — elles ne sont pas des échecs.
5. Le canonical. Un rel="canonical" vers un autre domaine — localhost, un domaine de préprod, un concurrent — est un échec. Un canonical entre www.acme.fr et acme.fr est noté mais ne fait jamais échouer : beaucoup de sites canonisent volontairement d'un côté ou de l'autre.

Régler

Rien à créer : la cible existe dès la création du projet, sur l'origine. Elle se lit sur Projet → Santé, carte « Indexabilité », qui affiche le verdict en clair — « En attente du premier déploiement » tant qu'aucun ship n'a été vu. Le détail (statut du robots.txt, directives lues, canonical) est sur la page de la cible.

Le contrôle ne tourne qu'au déploiement, à T+2 / T+8 et sur « Lancer maintenant » : voir Contrôles du site pour le pourquoi. Il peut être désactivé depuis la page Santé, mais c'est rarement le bon choix — un site qu'on ne veut pas indexer se dit avec noindex, et c'est justement ce qu'on veut savoir.

Ce qui déclenche une alerte

L'alerte ne dit jamais « répond 200 » : tout l'intérêt du contrôle est que la page a l'air d'aller bien. Un site non indexable coûte 30 points au Ship Score — juste derrière une page argent, parce que le coût arrive des semaines plus tard, en trafic. Sur Team, c'est de quoi faire échouer le Check GitHub si le score plancher est réglé.

Limites et plans

Sur Free, le verdict est calculé, stocké et affiché ; c'est la notification que le plan ne porte pas.

Dépannage

Pourquoi mon site de préproduction est en échec ?

Parce qu'il porte un noindex ou un Disallow: /, et c'est exactement ce qu'il doit porter. Ne surveillez pas une préproduction comme un projet : utilisez les previews pour vérifier un déploiement avant la production.

Le robots.txt bloque un seul robot, pourquoi pas d'alerte ?

Un groupe User-agent: GPTBot avec Disallow: / ne bloque que ce robot : ce n'est pas un blocage du site. Pour les robots des moteurs de réponse, voyez Visibilité IA, qui pose cette autre question.

Pourquoi le canonical vers www. n'est pas signalé ?

Parce que c'est presque toujours volontaire. Le verdict www-variant est écrit dans le détail du passage, sans échec. Ce qui est vérifié ici est le domaine ; la forme du canonical (absolu, http ou https) relève des balises.