Next SEO

Ce qu'est Next SEO aujourd'hui

Next SEO (github.com/garmeeh/next-seo) est une bibliothèque TypeScript, sous licence MIT et maintenue depuis 2018, qui donne à un projet Next.js des composants prêts à l'emploi pour les données structurées JSON-LD. Vous importez un composant, vous lui passez des props typées, et il affiche la balise script qui indique à un moteur de recherche ce qu'est la page : un article avec un auteur et une date, un produit avec un prix et une politique de retour, un ensemble de questions fréquentes, un fil d'Ariane, une organisation, une vidéo, une offre d'emploi. Le README en documente plus de deux douzaines, ainsi qu'une primitive JsonLdScript et une bibliothèque de processeurs d'entrée pour les types Schema.org qu'il ne couvre pas.

Le fait le plus intéressant sur ce projet est ce qu'il a cessé de faire. Next SEO est né comme la manière standard de gérer titres et balises meta dans Next.js, à l'époque où le framework n'avait aucun avis sur la question. Depuis que l'App Router propose une API de métadonnées de premier ordre, ce travail revient au framework — et plutôt que de rivaliser, le README de la bibliothèque vous dit clairement d'utiliser la fonction intégrée pour les balises meta ordinaires et réserve sa propre surface aux données structurées, les anciens composants du Pages Router étant déplacés derrière un import séparé. Une dépendance qui rétrécit quand la plateforme absorbe une partie de son travail est un signal plus sain qu'une dépendance qui ne cesse de grossir.

Où les données structurées aident vraiment

Le JSON-LD est un bloc d'affirmations lisibles par une machine à propos d'une page, posé à côté du texte destiné aux humains. Ce n'est pas un canal secret et cela ne rend pas forte une page faible. Ce qui change, c'est la lisibilité de votre page pour des systèmes qui doivent décider, sans la lire comme le ferait une personne, ce qu'elle est et s'il vaut la peine de la réutiliser.

• Éligibilité aux résultats enrichis Certains types peuvent changer l'apparence d'un résultat de recherche : avis, questions fréquentes, produits, événements, recettes. Un balisage correct rend une page éligible ; il n'oblige jamais un moteur à afficher quoi que ce soit.
• Lisibilité pour les moteurs de réponse Un auteur, une date, une entité et des paires question-réponse explicites donnent à un système de récupération quelque chose de non ambigu à reprendre, ce qui constitue la moitié mécanique de l'optimisation pour moteurs génératifs.
• Cohérence interne Remplir un composant typé oblige à déclarer qui a écrit une page et quand, précisément là où les sites faits main se contredisent en silence.

Pour un petit SaaS ou une boutique, l'ensemble utile est court : un type organisation ou application logicielle sur le site, des types article et questions fréquentes sur le contenu, des fils d'Ariane pour la structure, et des types produit et avis si vous vendez des biens physiques. La bibliothèque accepte en outre un nonce sur chaque script qu'elle affiche, ce qui compte si vous appliquez une politique de sécurité de contenu stricte — le genre de détail qui coûte un après-midi quand on le fait soi-même. Le concept lui-même est expliqué dans le balisage schema.

Ce qu'elle ne fait pas

Les données structurées ne sont pas un levier de classement. Google répète de façon constante qu'un balisage valide rend une page éligible à certaines présentations plutôt qu'il ne la positionne plus haut, et aucune quantité de balisage ne compense une page que personne n'avait de raison d'ouvrir. Voyez cela comme la différence entre une page comprise et une page qu'il faut deviner.

Ce qui place clairement ce type de bibliothèque du côté de la construction, pas de la croissance. Une page parfaitement balisée a toujours besoin d'une question qui mérite réponse, d'une raison qu'on la référence et d'assez de pages sœurs pour former un sujet. Si vous choisissez quoi publier plutôt que comment l'annoter, le SEO pour un site tout neuf est la décision en amont, et open-seo est le versant recherche du même travail : ceci en est le versant rendu.

Une observation de première main sur la mise en production du schema

Chez AgentCeres — l'équipe de croissance IA sur agentceres.com — nous écrivons notre JSON-LD à la main dans l'App Router plutôt que via une bibliothèque, voici donc une comparaison depuis l'autre côté du choix. Notre erreur n'était pas syntaxique. Nos pages de questions-réponses émettaient à l'origine le type QAPage, qui semble l'évidence, et c'était faux : ce type décrit des pages où des visiteurs publient des réponses concurrentes, alors que les nôtres sont écrites par nous. Nous sommes passés à FAQPage. Rien n'a changé sur la page sinon la véracité de ce que le balisage affirmait — et une bibliothèque aurait affiché le mauvais type aussi proprement que le bon.

La seconde leçon a coûté plus cher. Un balisage est un ensemble d'affirmations, et les affirmations vieillissent en silence, car rien ne paraît cassé sur la page quand cela arrive. Chaque page de nos sections /ask, /glossary et /grow est une entrée typée sous contrôle de version, accompagnée d'une suite de tests qui fait échouer la compilation sur un lien interne mort, un titre meta trop long ou une date de publication manquante, de sorte que les valeurs qui alimentent le schema ne peuvent pas dériver sans que quelqu'un le voie. Next SEO vous achète une syntaxe correcte et fait gagner du temps réel ; rien ne vous achète des faits corrects, sinon la décision de savoir lesquels ne doivent jamais être saisis deux fois. Cette distinction constitue l'essentiel de ce que notre spécialiste du contenu SEO fait réellement respecter.