Le référencement

Précédemment. Les parties précédentes ont construit ce que le site écrit, protège et conserve, jusqu’à ses obligations légales. Reste ce que le monde extérieur en voit, avant même d’ouvrir une page.

Les pages publiques ont deux lecteurs de plus que les visiteurs : les moteurs de recherche, qui décident de ce qu'ils indexent et de la façon de le présenter, et les réseaux sociaux ou les messageries, qui affichent un aperçu quand on partage un lien. Les deux lisent les métadonnées de la page (titre, description, image), et les moteurs consultent en plus deux fichiers à la racine du site : robots.txt et sitemap.xml. Next.js produit tout cela à partir de code, dans le même projet que les pages.

Une seule adresse du site#

Les métadonnées, le plan du site et le robots.txt ont besoin d'URL absolues (https://akfc.fr/gallery, jamais /gallery). Elles partent toutes d'une seule constante :

Une préproduction ou un autre domaine se règle par la variable d'environnement, sans toucher au code. Le slash final est retiré pour que ${SITE_URL}/gallery ne produise jamais deux slashs.

Les métadonnées par défaut, depuis les Réglages#

Le layout racine déclare les métadonnées dont héritent toutes les pages. Elles sont lues dans les Réglages du site, comme le reste de l'identité du club :

Trois mécanismes de Next.js y travaillent :

• metadataBase rend absolues les URL relatives des métadonnées : une page écrit alternates: { canonical: "/events/stage-ete" }, et l'en-tête produit contient l'adresse complète.
• title.template compose le titre de chaque page : une page qui déclare title: "Galeries" s'affiche « Galeries · AKFC » dans l'onglet et dans les résultats. L'accueil y échappe avec title: { absolute: … }, pour un titre complet qui décrit le club.
• openGraph et twitter décrivent l'aperçu d'un lien partagé. Sans image propre, une page hérite de og-default.png (1 200 × 630 pixels, le format attendu par les réseaux).

Les métadonnées d'une page#

Une page fixe simple exporte un objet metadata ({ title: "Nos instructeurs" }). Une page dont le contenu vient de la base exporte une fonction generateMetadata, qui lit ce qu'il faut pour se décrire. Pour un évènement, un stage ou une discipline, elle commence par la même question que la page : le contenu est-il publié ?

// ⚠ Fichier introuvable : apps/web/src/app/(public)/events/[slug]/page.tsx// Il a été déplacé ou supprimé depuis la rédaction de ce chapitre.

Un brouillon (sans date de publication) ou un contenu programmé (date future) ne doit pas apparaître dans les moteurs, même si quelqu'un en a trouvé l'adresse. La page elle-même répond « introuvable » à un visiteur (un administrateur la voit en aperçu, avec le badge « Page non publiée ») ; la consigne noindex est une seconde garantie, posée par les métadonnées, qui vaut pour tous : un robot n’est jamais connecté. Un contenu publié reçoit son titre, une description, une adresse canonique (l'adresse de référence, si la page est accessible par plusieurs chemins) et un aperçu de type article.

Les pages « en construction »#

Les pages éditoriales (accueil, association, contacts) peuvent être dépubliées depuis le tableau de bord (voir « Authentification et droits », visibilité des pages). Le visiteur voit alors un message « Page en construction », à la même adresse que la vraie page. Pour un moteur, c'est une page comme une autre : sans consigne, il pourrait l'indexer, et « Page en construction » s'afficherait dans les résultats sous le nom du club. Chacune de ces pages ajoute donc la consigne tant qu'elle n'est pas publiée :

La règle ne dépend pas de la session : un administrateur voit la vraie page, mais un robot n'est jamais connecté. Une fois la page publiée, editorialRobots ne renvoie rien, et la page hérite de l'indexation par défaut du layout.

Le plan du site, généré depuis la base#

sitemap.xml liste les pages que le site souhaite voir indexées, avec leur date de dernière modification. Le fichier app/sitemap.ts le construit à chaque demande (force-dynamic), à partir de la base :

Les contenus y sont filtrés par la même règle de publication que les pages elles-mêmes :

La règle est une fonction de l’instant, appelée à chaque demande. Elle était une constante de module : new Date() évalué une fois, au chargement du fichier par le serveur. Le plan du site comparait alors chaque date de publication au moment du démarrage : un stage programmé pour lundi n’y entrait qu’au redémarrage suivant. Rien ne le signalait — le plan du site restait valide, simplement incomplet.

Les pages éditoriales du plan viennent du registre partagé (PAGE_REGISTRY), le même que le centre de contrôle des pages et que la route publique des fichiers : une page ajoutée au registre entre dans le plan du site sans autre modification.

Le plan du site et les consignes noindex disent donc la même chose de deux façons : ce qui est listé est publié, ce qui n'est pas publié demande à ne pas être indexé.

Le robots.txt : ce que les robots n'explorent pas#

app/robots.ts produit le robots.txt. Il autorise tout le site, sauf les espaces privés ou techniques, et indique l'adresse du plan du site :

// ⚠ Fichier introuvable : apps/web/src/app/robots.ts// Il a été déplacé ou supprimé depuis la rédaction de ce chapitre.

Ce qui ne doit pas être lu par les robots#

Certaines données publiques attirent les robots collecteurs, qui parcourent le web à la recherche d'adresses e-mail à démarcher. La page des instructeurs est publique, mais l'adresse du club de chaque instructeur n'y est affichée qu'aux membres connectés : la page lit la session pour le savoir. Les adresses personnelles, elles, ne sont jamais affichées (voir « La frontière serveur / client »).

Récapitulatif#

À suivre#

Le référencement présente le site aux moteurs ; le header le présente aux visiteurs. C'est la seule partie de l'interface présente sur toutes les pages, et la seule qui change selon la personne connectée.