Sujet : seo
-
Pages 404 personnalisées et soft 404 : servir la page d'erreur avec le statut d'erreur
Une page 404 personnalisée n'aide les utilisateurs que si elle est servie avec le statut 404 ; une page « introuvable » servie avec un 200 est un soft 404 que les robots d'indexation continuent d'explorer et que les moteurs de recherche excluent. La directive error_page de nginx peut réécrire le statut (error_page 404 =200 ...), ce qui est exactement la manière dont les soft 404 sont créés par accident ; conserver le statut, rendre la page utile, et vérifier avec curl -I.
-
Rendre un site web lisible pour des agents : robots.txt, sitemaps et llms.txt
Les agents et les robots d'indexation trouvent le contenu grâce à un petit ensemble de conventions : robots.txt pour les règles d'accès et l'emplacement du sitemap, un sitemap XML avec de vraies dates de modification, et llms.txt comme court guide sélectionné ; aucune de ces conventions ne remplace l'authentification.
-
Plans de site et adresses canoniques : un contenu, une adresse
Chaque contenu devrait avoir exactement une adresse HTTPS canonique, déclarée sur la page elle-même ; les jumeaux comme les versions Markdown ou JSON y renvoient par un en-tête Link, les paramètres sans effet sur le contenu ne créent pas de nouvelles adresses, et le plan de site ne liste que des adresses canoniques avec des dates de modification véridiques.
-
Réduire les chaînes de redirection à un seul saut augmente la part des requêtes de robots d'indexation qui se terminent par un 200 sur un grand site
Hypothèse : sur un site comptant des dizaines de milliers d'URL et des redirections accumulées, réécrire chaque chaîne pour que chaque ancienne URL réponde par une seule redirection vers sa cible finale augmente mesurablement la part des requêtes des robots d'indexation qui atteignent une page en 200 dans un volume de requêtes quotidien fixe, parce que les robots dépensent des requêtes à chaque saut ; un test avant-après proposé sur les journaux serveur.
-
Les agents d'IA récupèrent-ils réellement llms.txt, et ce fichier change-t-il quelque chose à leur comportement ?
Question ouverte : llms.txt est une proposition sans normalisation, et de nombreux sites créent ce fichier sans savoir si un agent le lit. Quels motifs de récupération les journaux serveur montrent-ils pour /llms.txt et les jumeaux Markdown, quels agents ou outils l'interrogent réellement, et peut-on démontrer une différence de qualité de réponse ou de nombre de récupérations par rapport aux sites sans ce fichier ?
-
URL canoniques et contenu dupliqué
Chaque contenu devrait avoir une unique adresse HTTPS canonique déclarée sur la page ; les versions alternatives, comme les variantes Markdown ou JSON, y renvoient avec un en-tête Link, et les paramètres qui ne changent pas le contenu ne devraient pas créer de nouvelles URL.
-
llms.txt et sites web lisibles par des agents : robots.txt, sitemap et un point d'entrée organisé
Les agents et les robots d'exploration trouvent le contenu au moyen de quelques conventions : robots.txt pour les règles d'accès et l'emplacement de la sitemap (RFC 9309), une sitemap avec des dates de modification exactes, et llms.txt comme court guide organisé en Markdown, complété par des jumeaux Markdown des pages. Aucune de ces conventions ne remplace l'authentification.
-
Données structurées avec JSON-LD : seulement ce qui est vrai
JSON-LD dans un bloc script décrit la page à l'aide des types schema.org ; utiliser des propriétés correspondant au contenu visible, échapper le bloc contre l'injection, et ne rien attendre en matière de résultats enrichis à moins que les exigences d'une fonctionnalité précise soient remplies.
-
robots.txt, noindex et contrôle du crawl
robots.txt contrôle la récupération, noindex contrôle l'indexation ; une URL bloquée dans robots.txt ne peut pas porter un noindex effectif, et ni l'un ni l'autre ne constitue un contrôle d'accès. Les utiliser chacun pour ce à quoi ils servent, et protéger les points de terminaison privés par une authentification.
-
HTML sémantique et repères (landmarks)
Utiliser header, nav, main, article, section, aside et footer avec un seul h1 par page et un ordre de titres logique ; les technologies d'assistance, les moteurs de recherche et les agents naviguent tous à partir de ces structures.
Lisible par machine : JSON