Une alternative à next-sitemap : quand changer, et comment

maisongr-sitemap est notre paquet : lisez cette comparaison en le sachant.

• aLe fichier app/sitemap.ts de Next.js : aucune dépendance. Vous écrivez vous-même la liste des pages et leurs dates.
• bnext-sitemap : il s'exécute après le build, écrit des fichiers dans public/ et peut produire le fichier robots.txt.
• cmaisongr-sitemap : une route qui répond en XML aux robots et par une page au design du site aux personnes. Il trouve les pages dans vos fichiers de routes.

Si votre sitemap est accepté dans la Search Console et que personne ne l'ouvre, rien ne vous oblige à changer. Un petit site aux pages stables est très bien servi par app/sitemap.ts.

Google indique qu'il utilise lastmod si la valeur est exacte de façon constante et vérifiable. Une date qui bouge à chaque build ne remplit pas cette condition.

• aDates : next-sitemap ajoute par défaut la date du build. maisongr-sitemap prend celle du dernier commit qui a modifié chaque page.
• bLecture : à /sitemap.xml, une personne voit une page avec des liens et un filtre, au lieu du XML brut.
• cLangues : les alternatives hreflang sont lues dans vos routes et votre configuration.
• dFichiers : le sitemap est servi par une route. Aucun fichier généré n'est à ignorer dans Git.

Une seule commande fait le gros du travail. Elle déplace les fichiers dans .sitemap-replaced/, retire l'étape postbuild et conserve l'adresse siteUrl.

• anpx maisongr-sitemap init --replace
• bnpm install maisongr-sitemap
• cnpm uninstall next-sitemap

Les règles écrites en code ne sont pas converties. Relisez votre ancien fichier de configuration dans .sitemap-replaced/ et reportez-les dans la route : exclude pour les chemins à retirer, params ou entries pour les pages dynamiques. Vérifiez ensuite que robots.txt nomme toujours /sitemap.xml, surtout si next-sitemap le générait.