Automatiser un audit sémantique avec embeddings et LLM

Les embeddings transforment une requête ou une page en vecteur numérique, ce qui permet de mesurer la proximité de sens entre des milliers de contenus, là où une lecture manuelle prendrait des jours. Associés à un LLM, qui sait nommer, classer et expliquer, ils permettent d’automatiser une large part d’un audit sémantique : regrouper des mots-clés en clusters, classer les intentions, repérer les entités manquantes, détecter la cannibalisation et prioriser les opportunités éditoriales. L’automatisation ne remplace pas l’analyse d’un consultant, mais elle déplace son temps : moins de tri manuel dans des tableurs, davantage de décisions sur des données structurées. Cet article propose une méthode reproductible, les données à réunir, les contrôles qualité indispensables et un exemple de chaîne dans n8n.

01Embeddings SEO : de quoi parle-t-on ?

Un embedding, ou plongement, est une représentation d’un texte sous forme de liste de nombres, calculée par un modèle entraîné pour que des textes de sens proche obtiennent des vecteurs proches. Le Machine Learning Crash Course de Google présente les embeddings comme des représentations de plus faible dimension de données creuses, par exemple un vocabulaire encodé avec une dimension par mot. L’idée s’est popularisée avec word2vec, présenté en janvier 2013 par Tomas Mikolov et ses coauteurs, qui représentait des mots isolés. Les modèles actuels encodent des phrases, des paragraphes ou des pages entières, ce qui les rend directement utiles au SEO.

Parler d’« embeddings SEO » revient donc à appliquer cette mesure de proximité aux objets du référencement : requêtes, pages, passages, titres, entités. Deux requêtes formulées différemment (« isoler une porte d’entrée » et « calfeutrer une porte qui laisse passer l’air ») se retrouvent côte à côte, alors qu’un regroupement par mots communs les séparerait.

Embedding et LLM : deux rôles différents

Le modèle d’embedding et le LLM ne font pas le même travail, et les confondre conduit à des chaînes coûteuses ou fragiles.

• Le modèle d’embedding convertit un texte en vecteur. Il ne rédige rien. Il est rapide et généralement bien moins coûteux par élément traité qu’un appel de génération.
• Le LLM génère du texte. Dans un audit, il sert à interpréter : nommer un cluster, attribuer une intention, extraire des entités, rédiger une recommandation.

Les LLM qui alimentent les assistants conversationnels transforment eux aussi le texte en vecteurs internes, mais ces représentations ne sont pas exposées telles quelles. Les fournisseurs proposent des modèles d’embedding dédiés, accessibles par API, comme la famille text-embedding-3 d’OpenAI. Des modèles ouverts peuvent aussi tourner en local, par exemple via Ollama, ce qui évite d’envoyer des données sensibles à un tiers.

02Ce qu’un audit sémantique automatisé peut faire, et ses limites

Avant de construire la chaîne, il faut cadrer ce que l’on attend d’elle. Les embeddings et les LLM excellent sur quatre tâches :

• regrouper à grande échelle des milliers de requêtes ou de pages par proximité de sens ;
• détecter les quasi-doublons et les pages qui se concurrencent ;
• repérer les contenus hors sujet par rapport au thème central d’un site ou d’une rubrique ;
• étiqueter et résumer des ensembles de données trop volumineux pour une lecture manuelle.

Ils ne savent pas, en revanche, estimer une demande de recherche, une valeur business ou la réalité d’une SERP. Deux requêtes sémantiquement proches peuvent afficher des résultats très différents dans Google, et donc exiger deux pages distinctes. L’audit automatisé doit donc toujours être croisé avec des données de volume (Ahrefs, Search Console), des données de performance et une vérification des SERP sur les clusters prioritaires.

Screaming Frog illustre bien cette complémentarité. Depuis la version 22.0 du SEO Spider, publiée le 10 juin 2025, le crawler peut générer des embeddings via des fournisseurs d’IA comme OpenAI, Gemini ou Ollama, signaler les pages sémantiquement similaires (seuil de 0,95 par défaut, ajustable jusqu’à 0,5), repérer les contenus peu pertinents en comparant chaque page au centroïde du site, et visualiser les regroupements dans un diagramme de clusters. C’est un excellent point de départ, que la méthode ci-dessous prolonge avec les requêtes, les intentions et les entités.

03Préparer les données de l’audit

La qualité d’un audit sémantique dépend d’abord des données d’entrée. Une préparation soignée évite la plupart des résultats absurdes.

1. Collecter pages et requêtes

• Requêtes : export Search Console (via l’API ou l’export groupé quotidien vers BigQuery pour dépasser les limites de l’interface), exports d’un outil comme Ahrefs pour les mots-clés sur lesquels vous n’êtes pas encore visible, requêtes de recherche interne.
• Pages : crawl complet avec URL, title, H1, contenu principal, type de page, statut d’indexation, et si possible clics et impressions associés.
• Métriques : volume, difficulté, intention fournie par l’outil, positions actuelles, trafic.

Délimitez le périmètre avant de lancer les calculs : un segment de site (une rubrique, une gamme, un marché), une période de données Search Console et une liste de concurrents de référence. Un audit sur l’ensemble d’un grand site produit des milliers de clusters difficiles à exploiter ; un audit par segment donne des recommandations que l’équipe peut réellement traiter dans le trimestre.

2. Nettoyer et découper les contenus

Pour les requêtes : dédoublonner, normaliser la casse, retirer les requêtes parasites (fautes isolées sans volume, requêtes hors marché), isoler les requêtes de marque dans un segment à part. Pour les pages : extraire uniquement le contenu principal, sans menus, pieds de page ni blocs répétés, qui rapprocheraient artificiellement toutes les pages. Les pages longues gagnent à être découpées par section, en gardant la référence de l’URL et du titre de section.

3. Calculer et stocker les embeddings

Choisissez un seul modèle d’embedding pour tout l’audit, en vérifiant qu’il gère bien le français. Traitez les textes par lots, stockez chaque vecteur avec ses métadonnées (type, URL, date, segment) dans une table ou une base vectorielle, et gardez une trace du nom et de la version du modèle. Les vecteurs issus de deux modèles différents ne sont pas comparables. Conservez les vecteurs calculés : lors de l’audit suivant, seuls les contenus nouveaux ou modifiés devront être recalculés.

04La méthode en quatre analyses

Une fois les vecteurs disponibles, l’audit s’organise en quatre analyses successives. Chacune produit un onglet exploitable dans un tableur partagé.

1. Clustering des mots-clés et des pages

Le clustering regroupe les vecteurs proches. Plusieurs familles d’algorithmes existent : k-means, qui impose de fixer le nombre de groupes à l’avance ; le clustering hiérarchique avec seuil de distance, plus lisible pour un SEO ; HDBSCAN, qui détecte des groupes de densité variable et laisse de côté les éléments isolés. Pour un audit, un regroupement par seuil, calibré sur un échantillon, donne souvent le meilleur compromis entre finesse et lisibilité.

Pour présenter les résultats, une réduction de dimension (UMAP ou t-SNE, par exemple) projette les vecteurs sur un plan en deux dimensions. Cette carte ne sert pas à décider, car la projection déforme les distances, mais elle aide un client à visualiser les grands territoires sémantiques de son site et les zones laissées vides.

Le LLM intervient ensuite pour nommer chaque cluster à partir de ses éléments les plus représentatifs (les plus proches du centre du groupe). Donnez-lui une consigne stricte : un libellé de quelques mots, la requête principale probable et une phrase de justification. Sur les clusters à fort enjeu, vérifiez manuellement la SERP : si deux sous-groupes affichent des résultats différents, ils méritent deux pages.

2. Classification des intentions par LLM

Le LLM classe chaque cluster ou requête selon une taxonomie fermée que vous définissez : informationnelle, commerciale, transactionnelle, navigationnelle, locale, éventuellement complétée d’une étape du parcours. La consigne doit contenir les définitions, deux ou trois exemples par catégorie et un format de sortie structuré (JSON avec la catégorie, un score de confiance et une justification courte). Réduisez la créativité du modèle et versionnez le prompt pour pouvoir comparer deux audits.

Exemple de consigne, à adapter à votre taxonomie :

Tu classes des requêtes de recherche françaises.
Catégories autorisées : informationnelle, commerciale, transactionnelle, navigationnelle, locale.
Pour chaque requête, renvoie un objet JSON : {"requete": "...", "intention": "...", "confiance": 0 à 1, "justification": "une phrase"}.
Si la requête est ambiguë, choisis la catégorie la plus probable et indique une confiance inférieure à 0,6.
N'invente aucune catégorie.

Les outils SEO fournissent déjà des indicateurs d’intention : Ahrefs, par exemple, permet de filtrer les mots-clés par intention (informationnelle, navigationnelle, commerciale, transactionnelle) et par attributs de marque ou locaux. Comparez les deux classifications : les désaccords signalent souvent des requêtes ambiguës qui méritent une vérification de SERP.

3. Extraction et couverture des entités

Pour chaque cluster, le LLM extrait les entités attendues : produits, marques, attributs, concepts, questions récurrentes. En comparant ces entités avec celles présentes dans votre page cible, vous obtenez une liste de manques concrets. Exemple : un cluster « isolation phonique d’une chambre » peut faire apparaître des entités comme « laine de roche », « indice d’affaiblissement acoustique » ou « cloison doublée » absentes de la page existante. L’objectif n’est pas de les placer mécaniquement, mais de vérifier que le contenu répond vraiment aux questions du sujet.

Cette clarté sur les entités sert aussi la visibilité dans les moteurs IA, qui composent leurs réponses à partir de passages explicites. Elle s’inscrit dans une stratégie GEO fondée sur la donnée, sans garantie de citation : aucun moteur ne publie de règle permettant de l’assurer.

4. Détection des opportunités éditoriales

La dernière analyse croise les résultats précédents avec vos données de performance. Quatre situations ressortent :

• Cluster sans page : une demande identifiée, aucune page proche dans l’espace vectoriel. C’est une création de contenu potentielle.
• Cluster avec plusieurs pages : plusieurs URL très proches, qui se partagent les mêmes requêtes dans Search Console. C’est un signal de cannibalisation, que la SERP et l’historique des positions doivent confirmer.
• Page isolée : un contenu éloigné du centre thématique du site. Il faut le relier, le recentrer ou questionner sa place.
• Voisins non liés : deux pages très proches sans lien entre elles. C’est une suggestion de maillage interne à valider.

Exemple sur un site de rénovation : le cluster « isolation des combles perdus » rassemble plusieurs dizaines de requêtes et deux articles de blog très proches, qui se partagent les impressions dans Search Console sans qu’aucun ne dépasse la deuxième page. La recommandation consiste à fusionner les deux contenus dans une page guide, à rediriger l’URL la plus faible et à renforcer les liens depuis la page service correspondante. Le vecteur a signalé le problème ; la décision repose sur les données de performance et la lecture des deux pages.

Attribuez à chaque opportunité un score simple, par exemple demande multipliée par écart de couverture et par valeur business estimée par le client. Le tableau final doit tenir en une vue : cluster, intention, page cible, action recommandée, priorité, justification.

05Automatiser la chaîne avec n8n

La méthode se prête bien à un workflow n8n, qui rend l’audit reproductible chaque trimestre. Un enchaînement type :

1. Déclencheur manuel ou planifié.
2. Lecture des données : requêtes et pages depuis Google Sheets, une base de données ou l’API Search Console.
3. Découpage par lots pour respecter les limites des API.
4. Calcul des embeddings via un nœud d’embeddings ou une requête HTTP vers l’API du fournisseur, puis stockage des vecteurs.
5. Clustering dans un nœud Code ou dans un petit service Python appelé par HTTP, plus adapté aux gros volumes.
6. Étiquetage par LLM : nom du cluster, intention, entités, au format JSON validé.
7. Écriture des résultats dans un tableur partagé, avec un onglet par analyse.
8. Notification à l’équipe avec un résumé des principaux changements depuis l’audit précédent.

Prévoyez dès la conception la gestion des erreurs : réessai automatique en cas de limite de débit d’une API, validation du JSON renvoyé par le LLM avant écriture, et journal des éléments rejetés. Un audit qui échoue silencieusement sur une fraction des requêtes fausse toutes les priorités calculées ensuite.

Ce workflow peut ensuite être exposé à un assistant grâce au nœud MCP Server Trigger de n8n, qui rend des outils et des workflows n8n accessibles aux clients MCP. Un consultant peut alors demander à son assistant de relancer l’analyse d’un segment précis sans ouvrir n8n. Notre article sur le fonctionnement d’un serveur MCP détaille ce montage et le standard sur lequel il repose.

Les résultats d’audits successifs constituent aussi une base documentaire précieuse. Indexés dans un système de recherche augmentée, ils permettent de retrouver une recommandation passée ou de comparer deux périodes : notre article pour comprendre le RAG appliqué au SEO explique comment. Enfin, si vous envisagez de confier tout ou partie de la chaîne à un agent, lisez d’abord notre analyse des agents IA autonomes appliqués au SEO : un workflow déterministe reste préférable pour les étapes qui doivent produire le même résultat à chaque exécution.

06Limites, contrôles qualité et erreurs à éviter

Un audit automatisé produit vite beaucoup de résultats. Sans contrôle, il produit aussi vite beaucoup d’erreurs. Voici les points à surveiller.

• Seuils non calibrés : un score de similarité n’a de sens que pour un modèle donné. Calibrez vos seuils sur un échantillon validé à la main avant de les appliquer à tout le site.
• Classification instable : un LLM peut classer différemment la même requête d’une exécution à l’autre. Figez le prompt, réduisez la créativité, journalisez les versions et contrôlez un échantillon de 50 à 100 éléments à chaque audit.
• Entités inventées : le LLM peut proposer des entités plausibles mais hors sujet ou inexactes. Vérifiez-les avant de les transmettre à un rédacteur.
• Proximité prise pour identité d’intention : deux requêtes proches en sens peuvent appeler des pages différentes. La SERP tranche, pas le vecteur.
• Données confidentielles envoyées à des API : vérifiez les conditions d’utilisation des fournisseurs et privilégiez un modèle local pour les contenus sensibles.
• Décisions automatiques : fusion de pages, redirections ou suppressions ne doivent jamais être déclenchées sans validation humaine.

Checklist de contrôle avant de livrer l’audit :

1. Le modèle d’embedding et la version du prompt sont documentés.
2. Les seuils ont été calibrés sur un échantillon relu.
3. Les dix clusters prioritaires ont fait l’objet d’une vérification de SERP.
4. Chaque cas de cannibalisation est confirmé par les données Search Console.
5. Chaque recommandation indique la page concernée, l’action et sa justification.

La frontière entre automatisation utile et délégation excessive mérite d’être posée dès le départ. Un repère simple : automatisez la collecte, les calculs et l’étiquetage, et gardez les décisions (fusion, redirection, réécriture) entre les mains d’une personne qui connaît le site. Bien conduit, un audit sémantique par embeddings et LLM ne décide pas à votre place : il met sous vos yeux une cartographie qu’un tri manuel rendait longue et fragile à construire, et vous laisse le temps de l’interpréter.