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 2 jours plus tard. À ce moment-là, le déploiement responsable est 20 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

2 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 2 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 → Surveillance → 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 « Vérifier maintenant » : voir Contrôles du site pour le pourquoi. Il peut être éteint dans Projet → URLs, où chacun a sa ligne, 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 de paiement, parce que le coût arrive des semaines plus tard, en trafic. Sur Pro Plus, c'est de quoi faire échouer le Check GitHub si le score plancher est réglé.

Limites et plans

Sur Découverte, 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.

Open Graph

Vérifier que la carte sociale d'une page reste montrable — titre, description, image qui se charge.

Quand un lien vers votre site est collé dans Slack, sur LinkedIn ou sur X, c'est la carte Open Graph qui s'affiche : un titre, une description, une image. Une refonte qui perd la balise og:image, une image déplacée par un déploiement, une description vidée par un gabarit — rien n'est visible sur le site, et chaque partage devient un lien nu. La cible OG / Twitter lit ces balises et va vérifier que l'image répond.

Ce que PostShip vérifie

PostShip demande la page (mêmes règles que le contrôle HTTP : 12 secondes, 5 redirections, 512 Ko) et lit 4 balises, écrites en meta property="…" ou meta name="…" :

Puis, si l'image est sur votre site (même domaine ou sous-domaine), un HEAD sur son adresse :

• elle doit répondre 200 ;
• son Content-Type doit être image/jpeg, image/png, image/webp ou image/gif ;
• son Content-Length, s'il est annoncé, doit rester sous 8 Mo — le plafond pratique que les robots des réseaux appliquent.

Une image hébergée ailleurs (un CDN, un service d'images) n'est pas demandée : c'est la norme de servir ses images depuis un CDN, et aller frapper n'importe quel hôte écrit dans une balise ferait de PostShip un relais de requêtes. Sa présence est vérifiée, pas sa réponse.

Ce qui n'est pas vérifié : le rendu visuel de la carte. C'est un contrôle de balises et d'accessibilité de l'image, pas une capture d'écran. Pour voir la carte telle qu'elle est, et ce qu'elle était avant un déploiement, il y a l'archive de ship.

Régler

Projet → URLs → « Surveiller… » → « Une page » → « Sa carte sociale ». L'URL est celle de la page dont on partage le lien — la page d'accueil, un article, une page produit. Il n'y a pas d'autre réglage : les seuils sont ceux des réseaux, pas les vôtres.

Ajoutez une cible OG par gabarit (l'accueil, un article, une fiche produit) plutôt qu'une par page : les balises viennent du gabarit, et si l'une casse, toutes cassent.

Ce qui déclenche une alerte

Tous ces manques mettent la cible en échec. Quand l'image manque ou ne répond pas, l'alerte dit : La carte sociale n'a plus d'image valide. Une carte OG cassée coûte 15 points au Ship Score. L'alerte respecte la confirmation du projet et part une fois par panne.

Limites et plans

La vérification est la même sur tous les plans et compte pour une URL du quota (Découverte 5, Pro 25, Pro Plus 100). L'archive des cartes sociales — l'avant / après — garde 30 jours sur Pro, 90 sur Pro Plus.

Dépannage

Pourquoi l'image est déclarée inaccessible alors qu'elle s'affiche ?

Le HEAD a répondu autre chose que 200 : souvent un 403 d'une protection anti-robot ou d'un bucket qui refuse HEAD, parfois un 301 vers un CDN (le statut comparé est celui de la réponse à l'adresse de la balise, après suivi des redirections). Vérifiez avec curl -I l'adresse exacte écrite dans og:image.

Pourquoi le type d'image n'est pas supporté ?

Le serveur annonce un Content-Type hors des 4 acceptés — image/svg+xml, application/octet-stream, ou text/html parce que l'adresse renvoie une page. Les réseaux sociaux ont la même exigence : servez du JPEG, PNG, WebP ou GIF avec le bon type.

Les balises sont là dans mon navigateur mais absentes pour PostShip

Elles sont injectées par JavaScript. Les robots des réseaux sociaux n'exécutent pas non plus votre JavaScript : mettez les balises dans le HTML servi.

Sitemap et SSL

Le sitemap est lu et ses pages sondées ; le certificat est suivi jusqu'à son expiration, palier par palier.

2 vérifications qui n'ont rien à voir, sinon qu'elles concernent le site entier plutôt qu'une page. Le sitemap dit aux moteurs ce qui existe : un sitemap vide ou amputé fait sortir des pages de l'index sans qu'aucune page ne casse. Le certificat dit aux navigateurs qu'on peut entrer : un certificat expiré ferme le site avec un avertissement rouge, à une date que tout le monde connaissait.

Sitemap

Ce que PostShip vérifie

PostShip demande l'URL du sitemap (12 secondes, 5 redirections, 512 Ko lus) et en extrait les <loc>. Si c'est un index de sitemaps (<sitemapindex>), il suit jusqu'à 3 sitemaps enfants — sur votre domaine seulement — et prend leurs pages. Puis :

1. Il doit y avoir des URL. Zéro URL, c'est un sitemap vide, ou pas un sitemap.
2. Un échantillon de 10 URL de votre domaine reçoit un HEAD. Une URL qui répond 400 ou plus, ou ne répond pas, est injoignable.
3. Ce qui a disparu. La liste des URL est mémorisée (jusqu'à 2 000) et comparée à celle d'un passage d'il y a au moins un jour. Une disparition est un manque quand elle est trop large pour être un retrait éditorial : au moins 3 pages ET au moins 5 % du sitemap précédent. En dessous — un article dépublié — c'est un avertissement, parce que c'est presque toujours voulu.
4. Les pages parties répondent-elles encore ? Jusqu'à 10 des URL disparues reçoivent un HEAD. Une page qui redirige, n'importe où, ou qui répond encore est en règle ; une page en 404 ou 410 sans redirection est une perte : les moteurs perdent la page et les liens qui pointaient vers elle.

Pourquoi un jour de recul : comparer au dernier passage signalait une disparition une seule fois — le passage suivant la comparait à une liste qui ne la contenait déjà plus. Avec un jour, un retrait est signalé pendant 24 heures, puis devient la norme.

Régler

Projet → URLs → « Surveiller… » → « Une page » → « Un sitemap », avec l'URL du sitemap (https://acme.fr/sitemap.xml). Un projet neuf le reçoit automatiquement quand vos réponses à l'inscription disent que le référencement compte.

Ce qui déclenche une alerte

Le détail de la cible liste jusqu'à 20 URL disparues et celles qui sont perdues sans redirection. Un sitemap vidé entièrement est no_urls_found : il n'est pas signalé 2 fois.

SSL

Ce que PostShip vérifie

PostShip ouvre une connexion TLS sur le port 443 (ou 8443 si l'URL le précise ; aucun autre port n'est surveillé) et lit la date de fin du certificat présenté. Il en déduit le nombre de jours restants et applique 3 paliers : 30 jours, 7 jours, 1 jour, puis expiré.

Chaque palier est son propre code. C'est ce qui fait qu'un certificat à « moins de 30 jours » alerte une fois en franchissant le palier, pas à chaque cycle pendant 3 semaines : l'empreinte du passage change à chaque palier, et seulement là.

Le certificat vérifié est celui du nom d'hôte de l'URL : ajoutez une cible par hôte qui compte (acme.fr, app.acme.fr). Pour être prévenu quand quelqu'un émet un certificat pour votre domaine — une autre question — voyez Certificats.

Régler

Projet → URLs → « Surveiller… » → « Une page » → « Son certificat ». Un projet neuf reçoit toujours cette cible sur son origine. La page Santé du projet montre la carte « Certificat SSL » avec la date de fin et la frise des renouvellements.

Ce qui déclenche une alerte

Erreurs (pas de verdict) : « Timeout TLS (12s). », « Certificat introuvable. », « Port non surveillé. ». Un certificat à moins de 14 jours coûte 10 points au Ship Score, même si la cible SSL est encore verte.

Limites et plans

La sonde de 30 secondes de Pro Plus ne regarde que les pages : le sitemap et le certificat suivent le cycle.

Dépannage

Pourquoi le sitemap alerte à 30 jours alors que Let's Encrypt renouvelle à 30 jours ?

Ce n'est pas le sitemap mais le certificat, et c'est voulu : un renouvellement automatique qui marche remet le compteur à 90 jours avant le palier suivant. Si vous recevez ensuite l'alerte des 7 jours, le renouvellement n'a pas eu lieu — c'est exactement le moment d'agir.

Pourquoi « des pages ont disparu » alors que je n'ai rien retiré ?

Le sitemap est probablement généré à la volée et a répondu tronqué ou partiel à un passage (limite des 512 Ko, page d'erreur, index dont un enfant n'a pas répondu). Le détail du passage donne le nombre d'URL lues ; comparez-le à votre sitemap réel.

Pourquoi le certificat est « introuvable » ?

Le serveur n'a pas présenté de certificat pour ce nom : un hôte absent du proxy, ou un CDN qui n'a pas encore émis le certificat. Testez avec openssl s_client -servername acme.fr -connect acme.fr:443.

Balises SEO

Titre, meta description, canonical, viewport et hreflang de la page d'accueil, tels qu'un moteur les lit.

Un moteur n'a que le HTML servi pour décider quoi afficher dans ses résultats : le <title> devient le lien bleu, la description le texte gris dessous, le canonical désigne l'URL qui reçoit le crédit, le viewport dit si la page mérite l'index mobile. Une refonte qui perd la description dans un layout, un gabarit qui laisse « Home » en titre, un canonical relatif écrit à la main : rien de visible pour un humain, mais des positions perdues en quelques semaines. C'est un contrôle du site : créé par PostShip, hors quota, exécuté au déploiement.

Ce que PostShip vérifie

Une lecture du HTML de la page d'accueil, sans navigateur. Ce contrôle ne regarde que ce qu'aucun autre ne juge : l'indexabilité tranche déjà le noindex, le robots.txt et un canonical vers un autre hôte ; la carte Open Graph juge déjà og:title, og:description et og:image. Re-juger ici ferait échouer 2 contrôles pour un seul défaut et doublerait les alertes.

Les blancs sont repliés avant de mesurer : <title> indenté sur 3 lignes par un gabarit ne compte pas ses retours à la ligne, et « Home » entouré d'espaces reste « Home ». Le <title> lu est celui du document, pas celui d'un logo SVG en ligne.

Un score sur 100 : 20 points par manque, 5 par avertissement.

Régler

Rien à créer. Projet → URLs, ligne « Balises ». Le détail de la cible donne le titre et sa longueur, la description et sa longueur, le canonical, la présence du viewport, les hreflang lus, et le score.

Les corrections sont dans le <head> de votre gabarit. Pour un canonical, écrivez l'URL complète (https://acme.fr/), avec le slash final si c'est celle qui sert la page.

Ce qui déclenche une alerte

Manques — la cible échoue :

Avertissements — notés, sans alerte :

L'alerte parle du déploiement qui a introduit le défaut : La page d'accueil a perdu sa meta description — https://acme.fr/, La page d'accueil a perdu son <title> — https://acme.fr/. Un échec coûte au plus 10 points au Ship Score, catégorie « hygiène du site ».

Limites et plans

Seule la page d'accueil est analysée. Pour surveiller le titre et la description d'autres pages d'un déploiement à l'autre, le ce qui a changé compare ces champs sur chaque cible HTTP.

Dépannage

Mon titre fait 62 caractères et Google le coupe quand même

Google coupe en pixels, pas en caractères : des majuscules et des lettres larges passent moins. 65 est le milieu de la zone ; visez 55 si votre titre est en capitales.

Pourquoi un canonical vers www.acme.fr passe alors que le site est sur acme.fr ?

Ce contrôle ne juge que la forme (absolue, http(s)). Le domaine visé est la question de l'indexabilité, qui note la variante www sans échouer, parce qu'elle est presque toujours volontaire.

Les hreflang sont corrects mais signalés incohérents

Vérifiez l'attribut lang de la balise html : sans lui, aucune étiquette ne peut correspondre à la langue de la page. Ajoutez lang, ou un hreflang="x-default".

Contrôles du site

Les 8 vérifications que PostShip pose lui-même sur votre domaine, hors quota, et qui ne tournent qu'au déploiement.

Certaines questions ne portent pas sur une page mais sur le site : est-il indexable, ses en-têtes de sécurité sont-ils là, ses emails arrivent-ils, www. mène-t-il quelque part ? PostShip les pose lui-même, une fois par projet, sans que vous ayez à ajouter quoi que ce soit. Ce sont les contrôles du site : ils ne comptent pas dans votre quota, ils ne tournent qu'au déploiement, et chacun se désactive d'un clic.

Les 8 contrôles

Tous sont posés sur l'origine du projet (https://acme.fr/).

Comment ils tournent

Au déploiement seulement. Ce que robots.txt autorise, les en-têtes, les cookies, les redirections d'un site ne changent qu'à la mise en ligne. Les redemander toutes les 5 minutes referait la même requête pour la même réponse. Le cycle ordinaire les écarte donc ; seuls un webhook de déploiement, une revérification T+2 / T+8 ou un « Vérifier maintenant » les déclenchent. Une exception : les scripts tiers repassent aussi une fois par jour hors déploiement, parce que c'est précisément un changement sans déploiement qu'ils cherchent.

La conséquence à connaître : sans hébergeur raccordé, un contrôle du site n'a aucun déclencheur automatique, et la page Contrôles affiche « pas encore mesuré » jusqu'au premier ship. Branchez Vercel, Netlify, Cloudflare ou un webhook générique, ou laissez la détection sans webhook reconnaître vos déploiements.

Hors quota. Vous ne les avez pas demandés ; les facturer reviendrait à réduire votre forfait sans le dire. Un projet Découverte à 5 URL garde ses 5 URL.

Manque et avertissement. Chaque contrôle distingue ce qui met la cible en échec (un manque) de ce qu'il note sans alerter (un avertissement), et calcule un score sur 100. Les pages de chaque contrôle listent les deux.

Où les lire

Projet → Surveillance → Sécurité : la note sur 100 et ce qu'il faut corriger, contrôle par contrôle. L'indexabilité a sa carte sur la page Santé. Chaque contrôle a l'un de ces états :

Ce qui déclenche une alerte

Un manque met le contrôle en échec et ouvre un incident, avec la première cause nommée : L'adresse http ne renvoie plus vers https — https://acme.fr/, Le domaine n'a plus d'enregistrement SPF — acme.fr. Les codes exacts sont sur la page de chaque contrôle. L'alerte suit la confirmation du projet — comptée en déploiements, puisque c'est là qu'ils tournent — et « Rétabli » suit le retour au vert.

Sur le Ship Score, les contrôles du site forment une seule catégorie, « hygiène du site », plafonnée à 10 points : 4 hygiènes manquantes ne doivent pas coûter 40 points à un site qui vend très bien. L'indexabilité (30 points) et la visibilité IA (25) ont leur propre catégorie.

Limites et plans

Sur Découverte, les contrôles tournent et s'affichent — c'est la notification que le plan ne porte pas, pas le contrôle. Relancer une cible à la main n'envoie pas non plus l'alerte que le plan exclut.

Dépannage

Pourquoi tout est « pas encore mesuré » ?

Aucun déploiement n'a été vu. Cliquez « Vérifier maintenant » dans la barre du projet pour un premier passage, puis branchez votre hébergeur pour les suivants.

Pourquoi un contrôle passe en erreur à chaque déploiement ?

Une erreur est un « je n'ai pas pu conclure » : le site a mis plus de 12 secondes, ou un annuaire tiers n'a pas répondu. Le détail de la cible donne la raison. Une indisponibilité qui est la nôtre ou celle d'un tiers est reportée au passage suivant, jamais transformée en incident chez vous.

Puis-je ajouter un contrôle sur un sous-domaine ?

Non : ils sont posés une fois par projet, sur son origine. Créez un projet par sous-domaine qui mérite ses propres contrôles.