HTTP et assets

Une cible HTTP est ce que PostShip ajoute quand vous collez une URL sans rien préciser. Elle demande la page comme un visiteur, lit le statut, mesure le temps de réponse, cherche le contenu attendu, puis vérifie que les scripts et feuilles de style référencés par la page répondent aussi. C'est cette dernière partie qui attrape le déploiement classique : la page reste en apparence au vert, mais elle charge un app.3f2a.js qui n'existe plus.

Ce que PostShip vérifie

1. La requête. Un GET avec le User-Agent PostShipBot/0.1 (+https://postship.fr), un délai de 12 secondes, et 5 redirections au plus — au-delà, le passage est en erreur « Boucle de redirection. ». Chaque saut est revérifié : PostShip ne suit jamais une redirection vers une adresse privée. Le corps est lu jusqu'à 512 Ko.
2. Le statut. Il doit être exactement le statut attendu — 200 par défaut. Un 301 ou un 302 sont suivis, donc le statut comparé est celui de la dernière réponse.
3. Le TTFB. Le temps jusqu'au premier octet de la réponse, mesuré depuis les serveurs de PostShip. Il est toujours enregistré (page Performance) et devient un échec seulement si vous posez un seuil de latence.
4. Le contenu attendu. « Doit contenir » et « Ne doit pas contenir », comparés comme un lecteur le ferait — détail sur Contenu attendu.
5. Le HTML. Sur une réponse text/html, PostShip relève le titre, la description, le canonical, le h1 et l'og:title (ils alimentent le ce qui a changé et le diff du déploiement) et vérifie que chaque bloc JSON-LD est du JSON valide. Titre ou description absents ne sont jamais un échec ici : beaucoup de pages légitimes n'en ont pas.
6. Les assets. Les script src et link rel="stylesheet" de la page, même origine et https seulement (les scripts tiers ont leur propre contrôle : Scripts tiers), au plus 15, dans l'ordre du document. Chacun reçoit un HEAD — un GET si le serveur répond 405 — sous le même délai de 12 secondes que la page. Un asset est cassé s'il ne répond pas, répond 400 ou plus, ou répond du text/html (la page 404 d'un framework, servie en 200, à la place du fichier).

Régler

Au moment de l'ajout (Projet → URLs → « Surveiller… » → « Une page » → « La page répond », écran « Ce qu'on attend de la page »), ou ensuite sur le détail de l'URL :

• Statut attendu : de 100 à 599. Utile pour surveiller qu'une ancienne adresse redirige bien (attendre 200 après suivi) ou qu'une page privée répond 401 sans en-tête.
• Doit contenir / Ne doit pas contenir : 200 caractères chacun.
• Nom et valeur du header (page privée) : pour une page derrière un secret partagé. 4 noms sont acceptés — Authorization, X-Monitoring-Key, X-Health-Token, X-Api-Key — et rien d'autre : un Host ou un Cookie permettrait de détourner la requête ou de rejouer une session. L'en-tête n'est envoyé qu'à l'hôte d'origine, jamais à une redirection vers un autre hôte, jamais aux assets. La valeur est stockée hors de portée de votre session : elle s'écrit, elle ne se relit pas.
• Seuil de latence : sur le détail de l'URL, panneau « Seuil de latence ».

Ce qui déclenche une alerte

Un passage en erreur (délai, boucle, DNS) ouvre aussi un incident, avec la raison en clair : https://acme.fr : Timeout (12s).

L'alerte part à la transition — quand la série d'échecs vient d'atteindre le nombre réglé dans Règles — et de nouveau seulement si la panne change de nature. Le retour au vert envoie « Rétabli ». Un fichier statique manquant coûte 25 points au Ship Score.

Limites et plans

La vérification est identique sur tous les plans. Dans vos journaux, filtrez sur le User-Agent PostShipBot.

Dépannage

Pourquoi la page est en échec alors qu'elle s'ouvre dans mon navigateur ?

Regardez le détail de l'URL. Le cas le plus fréquent : un asset référencé par un HTML mis en cache et qui pointe vers le build précédent. Le navigateur a l'ancien fichier en cache, PostShip non. Purgez le cache du CDN ou attendez le prochain déploiement.

Pourquoi le statut attendu n'est pas respecté alors que le serveur renvoie 200 ?

Parce que PostShip suit les redirections et compare le dernier statut. Une page qui redirige vers une page de connexion en 200 passe ; une page qui redirige plus de 5 fois est en erreur.

Pourquoi le contenu attendu est absent alors qu'il est bien sur la page ?

Le corps est lu jusqu'à 512 Ko ; au-delà, le texte n'est pas vu. Le détail du passage indique bodyTruncated. Choisissez un texte qui apparaît tôt dans la page, ou allégez le HTML (Poids de page).

Contenu attendu

Exiger qu'un texte soit sur la page, ou qu'il n'y soit pas — comparé comme un lecteur le ferait.

Une page qui répond 200 peut être cassée : un bouton disparu, un gabarit vide, un message d'erreur rendu proprement avec le bon statut. Le contenu attendu dit à PostShip ce qui doit se lire sur la page — et ce qui ne doit pas s'y lire. C'est un réglage d'une cible HTTP, disponible sur tous les plans.

Ce que PostShip vérifie

2 champs, 2 règles :

• Doit contenir : le texte doit apparaître dans la page. Sinon, manque.
• Ne doit pas contenir : le texte ne doit pas apparaître. S'il apparaît, manque.

La comparaison se fait dans le texte visible de la page : balises retirées, scripts et styles retirés, entités HTML décodées ( , é, €…), espaces repliés, majuscules et accents ignorés. « Ajouter au panier » est donc trouvé dans Ajouter au panier, dans Ajouter <b>au</b> panier et dans AJOUTER AU PANIER.

Le pourquoi : une recherche dans le HTML brut trouverait « Ajouter au panier » dans le bundle JavaScript d'un gabarit qui n'a pas rendu — précisément la panne qu'on veut voir. Le texte visible est ce que voit un visiteur, et rien d'autre.

Le cas des repères techniques

Un texte qui contient <, >, =, ", {, }, [ ou ] ne peut pas être de la prose : data-testid="cart", <meta name=, {"@type". Il est cherché dans le HTML brut, en ignorant la casse, parce qu'il n'est visible nulle part. C'est le texte que vous tapez qui décide du régime — jamais un repli d'un régime sur l'autre après échec.

Régler

2 endroits :

• À l'ajout : Projet → URLs → « Surveiller… » → « Une page » → « La page répond », puis l'écran « Ce qu'on attend de la page » : « Doit contenir » / « Ne doit pas contenir ».
• Ensuite, à tout moment : le détail de l'URL, panneau « Contenu attendu », mêmes 2 champs, bouton « Enregistrer ». Le panneau montre aussi ce que le dernier passage en a conclu : « Vérifié au dernier passage : rien à signaler. » ou la phrase du manque.

Chaque champ accepte 200 caractères. Videz un champ et enregistrez pour retirer la règle.

Ce qui marche bien : le libellé d'un bouton clé (« Ajouter au panier », « Commander »), un prix (« 49 € »), un mot du pied de page qui prouve que le gabarit entier a rendu. Ce qui marche mal : une phrase longue que la rédaction peut retoucher, ou un texte présent seulement après exécution du JavaScript — PostShip lit le HTML tel qu'il est servi, sans navigateur.

Ce qui déclenche une alerte

Le texte réglé voyage dans le code du manque, pour que l'alerte le nomme :

Dans l'email ou le message Slack : « Ajouter au panier » n'apparaît plus sur la page — https://acme.fr/produit. Comme tout échec HTTP, l'alerte respecte la confirmation réglée dans Règles, part une fois par panne, et « Rétabli » suit le retour du texte.

Un texte vide, ou fait uniquement d'espaces, est considéré comme absent de règle : il ne déclenche rien.

Limites et plans

Le contenu attendu est disponible sur tous les plans, sans limite propre. Il ne s'applique qu'aux cibles HTTP : les étapes d'un parcours de paiement ont leurs propres assertions (prix, Stripe.js), et un contrat d'API juge la forme du JSON plutôt qu'un texte.

Dépannage

Pourquoi le texte est déclaré absent alors que je le vois sur la page ?

3 causes, dans l'ordre de fréquence. Le texte est ajouté par JavaScript après le chargement — PostShip ne l'exécute pas. La page fait plus de 512 Ko et le texte est après la coupure (le détail du passage indique bodyTruncated). Ou le texte contient un caractère technique (=, ", <) et est donc cherché dans le HTML brut, à l'identique : vérifiez qu'il y est écrit exactement ainsi.

Puis-je exiger plusieurs textes ?

Un seul par champ. Pour surveiller 2 éléments d'une même page, ajoutez la page 2 fois avec des règles différentes — chaque ligne compte dans le quota — ou choisissez le texte qui prouve que les deux ont rendu (le pied de page, par exemple).

La règle s'applique-t-elle aux redirections ?

Oui : PostShip suit jusqu'à 5 redirections et compare le texte de la page d'arrivée. Une page qui redirige vers une page de connexion n'a donc pas le contenu attendu — c'est souvent exactement ce qu'on veut savoir.

Redirections

Les 3 adresses que les gens tapent — http, www., sans www. — mènent-elles au site en https ?

Personne ne tape https://acme.fr/. On tape acme.fr, ou www.acme.fr, et le navigateur essaie d'abord en http. Le site n'est « en ligne » que si ces portes d'entrée aboutissent à la même origine, en https. Le défaut que ce contrôle attrape n'a aucun symptôme depuis la base elle-même : https://acme.fr/ répond 200, la disponibilité est parfaite, et pourtant la moitié des visiteurs voient une page d'erreur. C'est un contrôle du site : créé par PostShip, hors quota, exécuté au déploiement.

Ce que PostShip vérifie

2 scénarios reviennent sans cesse :

• la migration DNS qui recopie l'enregistrement de l'apex et oublie celui du www — quiconque tape www.acme.fr tombe sur une erreur de navigateur, et personne ne s'en aperçoit avant qu'un client se plaigne ;
• le serveur qui répond 200 en http au lieu de rediriger vers https — le site existe 2 fois, en clair et chiffré, avec 2 caches et 2 référencements, et la version en clair n'a aucun cadenas.

À partir de la base du projet (https://acme.fr/), PostShip construit 3 départs et suit chacun jusqu'au bout, en séquence — jusqu'au bout même si le premier échoue, parce que c'est le tableau complet qu'on veut montrer :

Si la base est en www., l'autre hôte est l'apex : les 3 départs deviennent http://www.acme.fr/, https://acme.fr/, http://acme.fr/. « Aboutir au site » veut dire arriver sur l'origine du projet, en https, après au plus 5 redirections. Les sauts en clair sont suivis avec la même garde d'hôte que le reste (jamais vers une adresse privée) ; dès que la chaîne arrive en https, la vérification ordinaire finit le travail.

2 cas particuliers : une adresse IP ou localhost n'a pas de variante www. — un seul départ. Un projet dont la base est en http ne peut pas se voir exiger des redirections vers https : le contrôle passe avec l'avertissement base_en_http.

Plus de 2 redirections avant d'arriver est un avertissement : chaque saut coûte environ 100 ms au visiteur et un peu de référencement.

La base elle-même n'est pas retestée : c'est le travail des autres contrôles.

Régler

Rien à créer. Projet → URLs, ligne « Redirections ». Le détail de la cible montre les 3 départs, où chacun est arrivé, en combien de sauts, et la raison s'il n'aboutit pas — « Répond 200 sans rediriger. » ou « Aboutit sur https://autre.fr/. ».

Les corrections sont chez votre hébergeur ou votre DNS : un enregistrement A, AAAA ou CNAME pour l'hôte manquant, et une redirection 301 de http vers https et de l'hôte secondaire vers l'hôte principal. Vercel, Netlify et Cloudflare Pages font les deux dès qu'un domaine est ajouté avec sa variante.

Ce qui déclenche une alerte

Manques — la cible échoue :

Le http qui ne répond pas est compté comme un manque de redirection : le visiteur qui tape le nom sans le https:// n'arrive nulle part. La variante d'hôte qui ne répond pas est un autre défaut, au DNS, et se corrige ailleurs.

Avertissements — notés, sans alerte :

Un échec coûte au plus 10 points au Ship Score, catégorie « hygiène du site ». Une panne de budget de requêtes côté PostShip n'est jamais transformée en « www ne répond pas » : le passage est en erreur et reporté.

Limites et plans

Dépannage

www. redirige vers l'apex mais est signalé « ne renvoie pas vers le site »

Regardez où il arrive dans le détail. Une redirection vers https://acme.fr puis vers /fr/ aboutit — le chemin est libre, l'origine doit être exactement celle du projet. Une redirection vers un autre domaine, une page de parking, ou une arrivée en http:// sans remontée en https n'aboutit pas.

Pourquoi « plus de 2 redirections » alors que je n'en ai qu'une ?

Comptez depuis http://www. : http vers https, puis www. vers l'apex, puis un slash final ou une langue — 3 sauts. Faites la redirection http://www. directement vers https://acme.fr/ en un saut.

Mon domaine est chez un registrar qui ne sait pas rediriger www.

Un CNAME www vers votre hébergeur suffit dans la plupart des cas : c'est lui qui fera la redirection. Une page en https://www. qui affiche le site sans rediriger ne suffit pas : « aboutir au site » veut dire arriver sur l'origine exacte du projet, et www.acme.fr n'est pas acme.fr. Le site existerait 2 fois.