Metadata Next.js, titres et descriptions

Tout part du fichier layout.tsx, à la racine de votre dossier app. C'est là que ça se joue. Il enveloppe l'ensemble du site, c'est donc l'endroit des valeurs de repli.

3 réglages y sont indispensables.

• metadataBase. L'adresse de référence du site, sous forme d'objet URL. Elle permet ensuite d'écrire des chemins courts partout ailleurs. Sans elle, vos images d'aperçu pointeront vers une adresse locale une fois le site en ligne, et le partage sera cassé.
• Le titre en 2 parties. Donnez à title un objet plutôt qu'une simple chaîne. La clé default fournit le titre de repli, la clé template contient un motif comme %s puis un séparateur puis le nom du site. Chaque page enfant remplit le %s et hérite du reste.
• La description. Elle sert de repli pour toutes les pages qui n'en déclarent pas et alimente aussi les aperçus de partage.

Un détail qui compte pour la vitesse. Les polices importées avec next/font sont hébergées sur votre propre serveur, ce qui supprime une connexion vers un domaine tiers. C'est bon pour le temps de chargement et cela évite d'envoyer l'adresse IP de vos visiteurs à un service extérieur, ce qui pose un vrai problème au regard du RGPD.

Dans chaque page fixe, exportez une constante metadata au-dessus du composant. Le nom et la casse comptent, Next.js reconnaît ce nom exact et rien d'autre.

Ce qu'il faut savoir pour bien les écrire.

• Le titre décide du clic. Placez le mot-clé principal au début, gardez 50 à 60 caractères. Au-delà, Google coupe.
• La description ne fait pas monter une page. Elle fait cliquer. Environ 155 caractères, avec une promesse concrète plutôt qu'une liste de mots-clés.
• Aucun doublon. 2 pages qui portent le même titre se font concurrence. C'est le défaut le plus courant sur les sites livrés vite.
• Le titre absolu. Sur une page où le motif du gabarit gêne, par exemple la page d'accueil, passez un objet avec la clé absolute. Le motif est alors ignoré pour cette page seulement.

Une règle de méthode qui vous sauvera. Rédigez ces 2 champs au moment où vous créez la page, jamais à la fin du projet. Repoussée, la tâche devient une corvée de 200 lignes que personne ne fait correctement.

Une fiche produit, un article de blog ou une page client ne peuvent pas avoir de titre écrit à l'avance. Leur contenu dépend de l'adresse.

Dans ce cas, on n'exporte plus un objet mais une fonction asynchrone nommée generateMetadata. Elle reçoit les mêmes paramètres que la page, va chercher la donnée, puis renvoie l'objet de metadata construit à partir de cette donnée.

3 points à ne pas manquer.

• Le piège de la version 16. Les paramètres d'adresse ne sont plus disponibles directement, ce sont des promesses qu'il faut attendre avec await. C'est la cause numéro 1 des routes cassées après une migration depuis la version 14.
• La donnée absente. Si la fiche n'existe pas, renvoyez quand même une metadata explicite plutôt que rien. Une page vide sans titre est le pire signal que vous puissiez envoyer à un robot.
• La double requête. La fonction et la page vont chercher la même donnée. Avec fetch, Next.js déduplique automatiquement, la requête ne part qu'une fois. Avec un ORM comme Prisma ou avec Axios, cette déduplication n'a pas lieu et il faut envelopper votre fonction d'accès dans cache, importé de React.

Ce dernier point coûte cher, et en silence. Sur une page qui affiche 5 composants appelant chacun la même requête, on passe de 5 requêtes à 1. Le sujet est développé dans notre article sur les composants serveur et clients.

C'est le réglage le plus oublié, et celui qui cause le plus de dégâts sur un catalogue.

Le problème est simple à voir. Une fiche produit accessible avec un paramètre de couleur, un paramètre de taille et un paramètre de tri devient 4 adresses différentes aux yeux d'un robot, pour un contenu identique. Vos signaux se divisent au lieu de s'additionner.

La solution tient en une ligne de metadata. Dans le champ alternates, la clé canonical désigne l'adresse de référence de cette page.

2 règles à respecter.

• Toujours une adresse absolue, jamais un chemin qui commence par une barre oblique seule. Le champ metadataBase du gabarit racine s'en charge si vous l'avez posé.
• Sur les pages dynamiques aussi. Dans generateMetadata, construisez l'adresse canonique à partir du paramètre, exactement comme le titre.

Un cas particulier utile. Sur une liste paginée, chaque page de résultats doit se déclarer canonique d'elle-même, et non de la première page. Faire pointer toutes les pages vers la première fait disparaître des résultats tout ce qui suit.

À ne pas confondre avec le fichier robots.txt, qui traite du site entier. Ici, on parle d'une consigne posée dans la metadata d'une seule page.

Les 2 réglages utiles.

• index. Autorise ou non l'apparition de la page dans les résultats. Une page de remerciement après formulaire, un espace de test ou une page de connexion n'ont rien à y faire.
• follow. Autorise ou non le robot à suivre les liens présents sur la page. Gardez-le actif dans presque tous les cas, y compris sur une page non indexée, sinon vous coupez la circulation vers le reste du site.

Le piège classique, celui qu'on retrouve sur un site sur 2. Bloquer une page dans robots.txt et lui poser un noindex en même temps ne fonctionne pas. Le robot bloqué n'entre jamais dans la page, il ne lit donc jamais la consigne. L'adresse peut alors rester listée dans les résultats, sans description. Choisissez l'un ou l'autre, jamais les 2. Le sujet est détaillé dans notre article sur le robots.txt en Next.js.

Le champ googleBot permet des réglages plus fins, comme la longueur maximale de l'extrait affiché ou la taille des aperçus d'image. La valeur -1 signifie aucune limite, c'est le comportement par défaut et il convient dans la grande majorité des cas.

La metadata est invisible à l'écran. Il faut donc la contrôler, sinon une faute reste en ligne des mois.

3 vérifications, de la plus rapide à la plus fiable.

• Le code source de la page. Ouvrez les outils de développement, onglet des éléments, et dépliez la balise head. Vos titres, descriptions et balises de partage doivent y être, en clair. S'ils manquent, votre page est probablement devenue un composant client.
• Un vérificateur d'aperçu. Il montre le rendu réel de votre lien dans les messageries et les réseaux. Attention, le validateur de cartes de X est fermé depuis 2022, ne perdez pas de temps à le chercher.
• La Search Console. L'inspection d'URL affiche le HTML tel que Google l'a reçu, ce qui tranche définitivement les cas douteux.

Une dernière remarque sur un champ qu'il ne faut pas remplir. Le champ keywords traîne dans à peu près tous les tutoriels. Google ne s'en sert plus depuis 2009 et Bing peut voir un excès de mots-clés comme un signal indésirable. Le laisser vide ne vous coûtera pas une position.