Se faire trouver

Votre lecteur arrive rarement par la page d'accueil. Il arrive par un moteur de recherche, par un lien qu'un collègue a collé, par le champ de votre propre en-tête — ou par un assistant qui a lu vos pages pour lui. Quatre portes, et cette leçon les ouvre toutes.

La recherche dans le site

Chaque page porte un champ dans son en-tête. Il mène à /search/, une page que la génération écrit avec le site : la liste de toutes les pages, qu'un petit script filtre à mesure que le lecteur tape.

search: false retire le champ et la page. Cela se défend sur un site de dix pages, où le menu montre déjà tout.

Les deux fichiers que lisent les robots

siteUrl: 'https://acme.example.com/docs',

Ce seul champ rend le reste possible — une adresse est ce dont un robot, un réseau social et un lecteur de flux ont tous besoin.

Une version marquée prerelease reste hors du plan du site et demande à ne pas être indexée. C'est ce qui évite qu'un lecteur cherchant votre outil atterrisse sur la documentation d'une version que personne ne peut encore installer.

Un lecteur qui est un programme

llms: true,

Quelqu'un demande à un assistant comment mettre en place votre outil. L'assistant va chercher vos pages, et ce qu'il reçoit, c'est du HTML : un en-tête, un menu, un pied de page, et quelque part au milieu le texte qu'il était venu chercher. llms: true lui tend le texte directement.

Les descriptions font ici aussi le travail. Une page sans description n'est qu'un lien nu dans llms.txt, et l'assistant doit l'ouvrir pour savoir de quoi elle parle : le champ qui écrit la ligne sous votre résultat de recherche écrit aussi celle-ci.

Il ne demande pas de siteUrl, et reste éteint tant que vous ne le demandez pas : que des programmes lisent vos pages, c'est à vous d'en décider.

À quoi ressemble un lien partagé

Un lien collé dans une conversation montre un titre, une description et une image. Les trois viennent de ce que vous avez déjà écrit :

L'aperçu

Titre et description depuis le frontmatter, image depuis socialImage.

La description d'une page n'est pas une décoration : c'est la phrase sous le titre dans un résultat de recherche, et celle sous le lien dans une conversation. Une page qui n'en a pas est annoncée par son seul titre.

socialImage se déclare une fois, dans la configuration, et a besoin de siteUrl — une autre machine va la chercher, donc l'adresse doit être absolue.

Dire ce qu'est une page

Les moteurs de recherche lisent les données structurées. La génération les écrit depuis le frontmatter, et une page peut dire de quel genre elle relève :

---
title: Installation
description: Une commande met le projet en place.
jsonld:
  type: TechArticle
  faq:
    - question: Quelle version de Node faut-il ?
      answer: La version 22 ou plus récente.
---

Les questions deviennent un vrai bloc de FAQ dans les données structurées — celui qu'un moteur peut afficher replié sous votre résultat.

Le poids, que personne ne remarque avant qu'il soit mauvais

Trois choses arrivent à la génération sans qu'on les demande :

• Chaque image reçoit ses dimensions, lues dans son fichier, pour que la page cesse de sauter pendant le chargement.
• Toutes les images sauf la première se chargent en différé, ce qui fait arriver le haut de la page en premier.
• La feuille de style est minifiée, et ne porte que les règles qu'emploient les pages.

Rien à configurer. Cela mérite d'être su parce que cela explique une surprise : la première image d'une page n'est délibérément pas différée, et ce n'est pas un oubli.

Les étiquettes, et ce qu'elles ne sont pas

tags: [cours, avancé, découvrabilité]

Elles s'affichent sous la page et passent dans les données structurées comme mots-clés. Il n'y a pas de page par étiquette : elles étiquettent, elles ne naviguent pas. Un lecteur qui cherche tout ce qui touche à un sujet emploie le champ de recherche.

Vérifiez par vous-même