Générer des titres et meta descriptions SEO en masse avec l'IA dans n8n

Un audit SEO technique révèle presque toujours la même chose : des dizaines, parfois des centaines de pages sans meta description, ou avec une balise <title> tronquée dans les résultats de recherche parce qu'elle dépasse 60 caractères. Les corriger une par une dans l'éditeur du CMS prend des heures pour un site de taille moyenne — et c'est précisément le genre de tâche répétitive, bornée par des règles claires (longueur, unicité, présence du mot-clé), que n8n peut automatiser de bout en bout : repérer les pages concernées, générer un titre et une meta description uniques par IA, contrôler leur conformité, puis les republier sans repasser par l'éditeur.

Ce n'est pas qu'une question de confort. Une étude de référence en recherche d'information, Tombros et Sanderson (SIGIR, 1998) — voir sur Google Scholar, a montré que des résumés construits en fonction du besoin d'information réel de l'utilisateur (des résumés « orientés requête ») permettent de juger bien plus vite et plus précisément la pertinence d'un document qu'un résumé générique composé du titre et des premières phrases. C'est exactement ce qui distingue une bonne meta description d'une mauvaise : une phrase générique extraite mécaniquement du premier paragraphe convertit moins bien qu'une synthèse qui répond directement à l'intention de recherche visée par la page — ce que ce workflow demande explicitement au LLM de produire.

Vue d'ensemble du pipeline

Le workflow tient en cinq étapes : repérage des pages à corriger, extraction du contenu de chaque page, génération du titre et de la meta description par un LLM à sortie structurée, contrôle qualité, puis republication via l'API REST du CMS.

Sitemap / liste de pages → Extraire contenu + balises actuelles → Filtrer (absentes / hors bornes) → LLM (titre + meta) → Contrôle qualité → IF (ok / à relire) → Publication API

Étape 1 — Repérer les pages à corriger

Deux sources permettent de lister les pages du site : le sitemap.xml (un node HTTP Request puis XML pour extraire la liste des URLs) ou, pour un site WordPress, l'API REST native (GET /wp-json/wp/v2/posts?per_page=100) qui renvoie directement les identifiants de contenu. La seconde option est préférable dès que vous devez republier ensuite, car elle donne l'ID du post nécessaire à l'écriture.

Pour chaque URL, un node HTTP Request récupère le HTML de la page, puis un node Code en extrait la balise <title> et le contenu de <meta name="description"> par expression régulière :

const html = $json.data;
const title = (html.match(/<title>(.*?)<\/title>/i) || [])[1] || "";
const metaMatch = html.match(/<meta\s+name=["']description["']\s+content=["']([^"']*)["']/i);
const description = metaMatch ? metaMatch[1] : "";

return [{
  json: {
    url: $json.url,
    titreActuel: title.trim(),
    metaActuelle: description.trim(),
    aTraiter: !description || description.length < 70 || description.length > 160 || title.length > 60,
  },
}];

Un node Filter ne garde ensuite que les lignes où aTraiter vaut true : pages sans meta description, meta trop courte pour être informative, meta tronquée dans les résultats de recherche, ou titre déjà trop long. Une meta description déjà présente et bien calibrée n'est jamais reprise — le workflow cible uniquement ce qui a réellement besoin d'être corrigé.

Étape 2 — Extraire le contenu utile de la page

Le LLM a besoin de plus que l'URL pour produire un texte pertinent : un node Code (ou HTML Extract, natif dans n8n) isole le H1 et les deux ou trois premiers paragraphes du corps de page, en excluant menu, footer et blocs de navigation. C'est ce contexte, pas le titre seul, qui permet au modèle de produire une synthèse réellement orientée vers ce que la page apporte — le même principe de contexte explicite que celui détaillé dans notre guide sur les fiches produits générées par IA et dans notre guide sur l'Information Extractor.

Étape 3 — Génération avec sortie structurée

Un node Chain LLM (voir nos guides pour connecter OpenAI ou Claude et GPT à n8n) reçoit le H1, l'extrait de contenu et l'URL, avec un prompt qui fixe des contraintes strictes de longueur et interdit les formules creuses (« Découvrez... », « Cliquez ici... »). Un node Structured Output Parser force la réponse dans un schéma fixe, comme dans notre guide dédié :

{
  "titre_seo": "string, 60 caractères max",
  "meta_description": "string, 150-160 caractères, doit inclure le sujet principal de la page"
}

Le prompt gagne à préciser explicitement le mot-clé ou l'intention de recherche visée par la page quand elle est connue (issue par exemple d'un export Google Search Console) : c'est le levier qui rapproche le résultat d'un résumé « orienté requête » plutôt que d'un simple résumé générique du contenu.

Étape 4 — Contrôle qualité avant publication

Un node Code vérifie systématiquement la sortie du LLM avant tout envoi vers le CMS :

const d = $json;
const problemes = [];

if (d.meta_description.length < 120 || d.meta_description.length > 160) {
  problemes.push("longueur meta hors bornes");
}
if (d.titre_seo.length > 60) problemes.push("titre trop long");
if (/découvrez|cliquez ici|n'hésitez pas/i.test(d.meta_description)) {
  problemes.push("formule générique détectée");
}

return [{ json: { ...d, ok: problemes.length === 0, problemes } }];

Un node IF sépare les pages conformes (publication directe) des pages à relire (routées vers une file humaine plutôt que bloquées). Pour les premières exécutions, le pattern d'approbation humaine avec Wait et Slack permet de valider un échantillon avant de généraliser à tout le site.

Étape 5 — Republier via l'API REST

C'est l'étape la plus spécifique au CMS. Sur WordPress avec Yoast SEO, l'API REST expose ces champs en lecture seule par défaut — un POST vers /wp-json/wp/v2/posts/{id} avec les champs Yoast dans le corps de la requête n'a tout simplement aucun effet. Deux options rendent l'écriture possible :

• Ajouter un court snippet PHP côté WordPress qui appelle register_post_meta() avec show_in_rest: true pour les champs _yoast_wpseo_title et _yoast_wpseo_metadesc, ce qui les rend accessibles en écriture via l'endpoint standard des posts.
• Passer par un plugin dédié qui expose un endpoint d'écriture spécifique pour ces champs, si vous préférez ne pas toucher au code du thème ou d'un plugin.

RankMath suit la même logique avec ses propres clés de métadonnées. Une fois l'un des deux en place, un node HTTP Request authentifié (Basic Auth avec un mot de passe d'application WordPress, ou credential OAuth2 selon la configuration) suffit à écrire le titre et la meta description générés, en mappant explicitement chaque champ plutôt que d'écraser l'objet post complet.

Champ généré	Destination WordPress + Yoast	Destination RankMath
titre_seo	_yoast_wpseo_title	rank_math_title
meta_description	_yoast_wpseo_metadesc	rank_math_description

Pour un site sur une autre plateforme (Webflow, Shopify), le principe reste identique en visant le champ SEO exposé par l'API du CMS — nos guides Shopify et Webflow détaillent l'authentification correspondante.

Traiter le site par lots, pas en une passe

Sur un site de plusieurs centaines de pages, un node Loop Over Items traite les URLs par lots de 20 à 50, avec un court Wait entre chaque lot pour rester sous les limites de l'API du LLM et de celle de WordPress. Ce pattern est détaillé dans notre guide sur les boucles n8n et notre guide sur les rate limits d'API ; il évite aussi de générer d'un coup des centaines d'appels LLM difficiles à auditer en cas d'erreur de prompt.

Suivre l'impact et éviter les doublons

Chaque exécution gagne à être journalisée — URL traitée, ancienne et nouvelle valeur, date — dans une table Supabase ou une feuille Google Sheets, sur le même principe de journalisation que notre guide sur la piste d'audit RGPD avec Supabase. Ce journal sert à deux choses : ne jamais retraiter une page déjà corrigée dans les 30 derniers jours, et croiser les variations de clics observées ensuite dans le rapport SEO hebdomadaire Search Console avec la date exacte de chaque changement de balise.

En résumé

Automatiser la génération de titres et meta descriptions dans n8n repose sur quatre garde-fous : cibler uniquement les pages réellement problématiques plutôt que tout réécrire, fournir au LLM le contenu réel de la page plutôt qu'un simple titre, imposer une sortie structurée avec des bornes de longueur strictes, et journaliser chaque changement pour pouvoir en mesurer l'effet. Le même socle — extraction structurée, génération contrainte, contrôle qualité, journalisation — est celui des workflows de reporting du Pack Conformité & Audit, pensé pour transformer des données brutes en actions fiables sans supervision humaine constante.