Une page en 404
ne se référence pas.

Le cas le plus courant n'est pas une panne, c'est un oubli de publication. Le texte est rédigé, les pages existent dans le code, elles s'affichent parfaitement sur le poste de celui qui les a écrites, et elles ne partent jamais en ligne. Sur un projet qui se déploie à la main, il suffit qu'une mise en ligne se concentre sur un autre sujet pour que le chantier reste à quai. Personne ne reçoit d'alerte, parce qu'aucune alerte n'existe pour un contenu qui n'a jamais été visité.

Les outils de suivi ne signalent que ce qui a existé puis disparu. Une page jamais publiée n'a pas d'historique, donc aucun rapport ne la réclame. Les liens internes ne pointent pas vers elle, puisqu'elle n'a jamais été reliée. Et celui qui l'a écrite la voit s'afficher chez lui. Le seul contrôle qui la trouve est celui qui part de la liste des adresses prévues et interroge le serveur public, une par une.

Le coût n'est pas la perte d'un classement, c'est la perte du temps déjà payé. Dans notre cas, dix articles et trois pages de service, soit plus de dix mille mots, sont restés inaccessibles pendant deux mois : ni Google, ni Bing, ni aucun assistant n'a pu les lire. Le travail de rédaction était intégralement fait et intégralement sans effet. Le délai d'indexation s'ajoute ensuite, donc les deux mois perdus ne se rattrapent pas le jour de la mise en ligne.

Il consiste à lire le plan du site, à appeler chaque adresse sur le domaine public, et à n'afficher que celles qui ne répondent pas correctement. Sur un site de cent pages, cela prend moins d'une minute. Il doit porter sur le domaine réel et non sur l'adresse technique du déploiement, car cette dernière peut très bien répondre alors que le site public est en erreur. Et il doit tourner après chaque mise en ligne, pas avant.