vendredi 25 septembre 2026

À propos

Contact

Headless & API

Un site headless qui perdait son SEO : meta descriptions absentes de l’API

Un projet Next.js affichait des pages sans meta description ni canonique parce que Yoast n'exposait rien par défaut dans l'API REST. Voici le correctif exact que nous avons appliqué.

Par Clément Hadrot • 15 février 2021 • 4 min de lecture • Aucun commentaire
Un site headless qui perdait son SEO : meta descriptions absentes de l'API

Un mois après la mise en ligne d’un site headless en Next.js pour un client du secteur de la formation, une baisse notable des positions sur Google est remontée dans les alertes de la Search Console. En creusant, la cause est apparue rapidement : aucune page du site ne portait de balise meta description, et la balise canonique pointait systématiquement vers la racine du domaine, quelle que soit la page consultée.

Ce cas de figure ne traite pas du SEO headless dans sa globalité, un sujet déjà largement couvert plus loin sur ce blog. Il documente précisément ce qui a été cassé sur ce projet et le correctif appliqué dans l’urgence pour limiter les dégâts avant qu’ils ne s’aggravent.

Le diagnostic : Yoast ne parle pas à l’API REST par défaut

L’équipe éditoriale utilisait Yoast SEO pour renseigner, article par article, une meta description et un titre optimisé. Le problème, c’est que Yoast SEO ne pousse pas ces champs dans le point de terminaison natif /wp-json/wp/v2/posts par défaut. Le front Next.js, développé sans connaissance approfondie de Yoast, s’était contenté d’utiliser l’extrait généré automatiquement (excerpt.rendered) comme meta description, sans savoir qu’un champ dédié, bien plus travaillé par la rédaction, existait ailleurs mais restait invisible côté API.

curl -s https://exemple.fr/wp-json/wp/v2/posts/88 | jq '.yoast_head, .yoast_head_json'
null
null

Ces deux clés, ajoutées par Yoast lorsque l’option est activée, étaient tout simplement absentes de la réponse : l’extension REST de Yoast n’avait jamais été activée sur ce projet.

Le correctif appliqué en urgence

Yoast SEO propose nativement un champ yoast_head_json exposable dans l’API REST, à condition d’activer l’option correspondante dans les réglages de l’extension, sous « Réglages de l’API REST ». Une fois activée, chaque article expose un objet structuré contenant meta description, titre optimisé, URL canonique et données Open Graph :

curl -s https://exemple.fr/wp-json/wp/v2/posts/88 | jq '.yoast_head_json.description, .yoast_head_json.canonical'
"Une formation courte pensée pour les professionnels en reconversion, avec un suivi individuel dès la première semaine."
"https://exemple.fr/formations/reconversion-courte/"
L'essentiel à retenir : Yoast n'expose rien en REST sans configuration explicite ; Un point de terminaison dédié a suffi à combler le manque ; La balise canonique s'était perdue avec le reste

Adapter le front pour consommer ce nouveau champ

Côté Next.js, le composant de mise en page a été modifié pour lire ce champ plutôt que l’extrait automatique :

export async function generateMetadata({ params }) {
  const res = await fetch(
    `https://exemple.fr/wp-json/wp/v2/posts?slug=${params.slug}`
  )
  const [post] = await res.json()
  const yoast = post.yoast_head_json

  return {
    title: yoast?.title ?? post.title.rendered,
    description: yoast?.description ?? post.excerpt.rendered,
    alternates: {
      canonical: yoast?.canonical,
    },
  }
}

Le repli (??) sur les champs natifs reste volontaire : certains contenus plus anciens n’avaient jamais reçu de meta description manuelle dans Yoast, mieux valait un extrait automatique qu’une balise vide.

Le sort de la balise canonique

Le problème de canonique erronée avait une autre cause, indépendante de Yoast : le front générait la balise canonique à partir d’une variable d’environnement mal configurée après un changement de nom de domaine, pointant vers l’ancienne URL de préproduction restée accessible publiquement par erreur. Ce détail, découvert en marge du correctif principal, rappelle qu’un problème de SEO headless en cache souvent un second, sans lien apparent avec le premier.

Le suivi après correctif

  • Soumission d’un sitemap actualisé à la Search Console pour accélérer le nouveau passage de Google sur les pages corrigées.
  • Vérification manuelle, page par page, des dix contenus les plus consultés, pour confirmer la présence effective de la meta description et de la bonne URL canonique.
  • Ajout d’un test automatisé simple, exécuté à chaque déploiement, qui vérifie qu’aucune page ne renvoie une meta description vide.

Sur un projet headless, ne partez jamais du principe qu’une extension SEO fonctionne « comme dans un thème classique » simplement parce qu’elle est activée : vérifiez toujours ce qu’elle expose réellement à l’API.

En résumé

Une extension SEO installée et configurée ne suffit pas en headless si elle ne pousse rien vers l’API REST consommée par le front. Le correctif, une fois le diagnostic posé, a tenu en une option à activer côté WordPress et quelques lignes côté Next.js. La vraie perte, dans cette histoire, aura été le mois écoulé sans meta description avant que quelqu’un ne remarque la baisse de trafic, un délai qu’un test de non-régression basique aurait pu éviter.

Partager :

À propos de l'auteur

Clément Hadrot

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi