Sitemap Next.js, le générer automatiquement

Le principe tient dans une convention de nom. Rien de plus. Un fichier appelé sitemap.ts, placé à la racine du dossier app, produit automatiquement l'adresse sitemap.xml de votre site.

Ce fichier exporte une fonction par défaut nommée sitemap. Elle renvoie un tableau d'objets, un par adresse. L'extension est bien .ts et non .tsx, puisqu'il n'y a aucun affichage.

Un seul champ est obligatoire dans chaque objet, url. Et il doit contenir l'adresse complète, avec le protocole et le nom de domaine. Un chemin qui commence par une simple barre oblique est refusé.

La bonne pratique consiste à stocker l'adresse du site dans une variable d'environnement plutôt que de l'écrire en dur. Vous évitez ainsi le classique sitemap qui pointe vers une adresse locale une fois le site en ligne, défaut qu'un audit Lighthouse signale immédiatement.

Pour tester, lancez le site en mode développement et ouvrez l'adresse sitemap.xml dans le navigateur. Le fichier XML s'affiche tel que les moteurs le recevront.

Lister 5 pages fixes à la main est faisable. Lister 400 articles ne l'est pas, et personne ne tient ce fichier à jour plus de 2 mois.

La méthode qui tient dans le temps.

• Séparez les 2 familles. Un premier tableau pour les pages fixes, écrites une fois. Un second construit à partir de vos données.
• Interrogez votre source. Base de données, système de gestion de contenu ou fichiers, la fonction est asynchrone et peut aller chercher ce qu'elle veut.
• Transformez chaque élément en objet avec son adresse complète, puis fusionnez les 2 tableaux.

L'avantage est direct. Vous publiez un article, il apparaît dans le sitemap au déploiement suivant sans que personne n'y pense.

Attention au cas piégeux. Les pages que vous ne voulez pas indexer n'ont rien à faire dans le sitemap. Envoyer à Google une adresse portant une consigne de non-indexation génère une alerte dans la Search Console. Ce n'est pas une pénalité, mais c'est un bruit permanent qui masque les vraies erreurs.

3 champs facultatifs existent. Un seul mérite votre attention.

lastModified, la date de dernière modification. Google l'utilise, à une condition. Elle doit être vérifiable, c'est-à-dire cohérente avec la page réelle. Si votre déploiement estampille toutes les pages à la date du jour, Google finit par ignorer cette information sur l'ensemble du site. C'est un actif qu'on brûle une fois pour toutes.

priority, l'importance relative. Google l'ignore. La note de 0 à 1 n'influence ni le classement ni, en pratique, l'ordre d'exploration.

changeFrequency, la fréquence de mise à jour. Google l'ignore également. Elle est traitée au mieux comme une indication très faible.

Ce qu'il faut en faire concrètement. Si votre contenu porte une date de modification en base, utilisez-la pour lastModified. Sinon, laissez le champ vide plutôt que d'inventer une valeur. Une absence est plus honnête qu'un mensonge, et les robots traitent les 2 très différemment.

Un mot sur les autres moteurs. Bing et les robots des intelligences artificielles lisent aussi ce fichier. Sur un sujet où vous visez la citation dans une réponse générée, un sitemap propre reste le moyen le plus simple de vous faire découvrir, comme nous l'expliquons dans notre article sur ce que contient vraiment un fichier llms.txt.

La limite est fixée par la norme et reprise par Google. 50000 adresses maximum par fichier, et 50 Mo non compressés.

Un blog n'y arrivera jamais. Un catalogue produits, une place de marché ou un annuaire, oui.

Next.js fournit pour cela la fonction generateSitemaps. Elle renvoie une liste d'identifiants, et votre fonction sitemap reçoit ensuite cet identifiant en paramètre pour ne produire que la tranche correspondante. Le résultat se présente sous forme de fichiers numérotés, accessibles à des adresses distinctes.

2 précautions.

• Découpez par tranches franches, en général 50000 éléments, calculées à partir de l'identifiant.
• Vérifiez la charge au build. Générer 20 fichiers signifie 20 requêtes vers votre base pendant la compilation. Sur un catalogue important, il vaut mieux lire un index préparé qu'interroger la table complète 20 fois.

Pour les sites de taille intermédiaire, un découpage par nature de contenu est souvent plus lisible qu'un découpage par nombre. Un sitemap pour les articles, un pour les produits, un pour les pages fixes. Vous gagnez surtout en diagnostic, puisque la Search Console vous donne alors le taux d'indexation par famille.

Générer le fichier ne suffit pas. Il faut le signaler, à 2 endroits.

Dans le fichier robots. Une ligne sitemap suivie de l'adresse complète du fichier. C'est l'un des 4 seuls champs que Google reconnaît officiellement dans ce fichier, et tous les moteurs le lisent. Voir notre article sur le robots.txt en Next.js.

Dans la Search Console. Section Sitemaps, vous collez l'adresse du fichier et vous validez. Vous obtenez en retour un rapport de lecture, avec le nombre d'adresses découvertes et les erreurs rencontrées. C'est cette information que le fichier robots ne vous donnera jamais.

Ce qu'il faut en attendre, sans se raconter d'histoires. Un sitemap accélère la découverte. Il ne garantit rien. Google explore ce qu'il veut, dans l'ordre qu'il veut, et n'indexe qu'une partie. Sur un site neuf, comptez de quelques jours à quelques semaines.

Pour pousser une page précise, l'inspection d'URL de la Search Console permet de demander l'indexation à l'unité. C'est nettement plus rapide, avec une limite d'une dizaine d'adresses par jour et par propriété. Réservez-la à vos pages stratégiques.

Une vérification simple pour finir. Lancez dans Google une recherche restreinte à votre nom de domaine avec l'opérateur site. Vous voyez alors les pages réellement indexées. Si votre article n'y figure pas, le problème est la découverte, pas le classement.