Content decay : détecter et corriger le déclin de trafic SEO avec n8n et l'IA

Une page qui rankait en position 4 depuis un an et qui glisse doucement en position 9, sans qu'aucune pénalité Google n'apparaisse dans Search Console : c'est le scénario le plus fréquent, et le plus silencieux, du content decay. Personne n'y touche, rien ne « casse » techniquement, et pourtant les clics fondent mois après mois. Le problème n'est pas qu'un algorithme a changé — c'est que le reste du web, lui, continue de bouger pendant que la page reste figée. Ce guide construit dans n8n un pipeline qui détecte ce déclin avant qu'il ne devienne critique, le diagnostique avec un AI Agent, et le route vers un backlog de refonte validé par un humain plutôt que de publier des correctifs automatiques.

Le content decay est mesurable, pas une impression

L'idée qu'un contenu « vieillit » sur le web n'est pas qu'une intuition de rédacteur SEO. Une étude de référence de Ntoulas, Cho et Olston, What's New on the Web? The Evolution of the Web from a Search Engine Perspective (WWW 2004), a suivi pendant un an l'évolution hebdomadaire de plusieurs centaines de sites : environ 8 % des pages sont remplacées chaque semaine, et près d'un quart des liens changent sur la même période. Concrètement, une page qui n'a pas bougé depuis sa publication ne reste pas simplement « stable » — elle recule mécaniquement par rapport à un environnement qui, lui, continue de se renouveler.

Ce n'est pas qu'un effet de contexte : les moteurs de recherche intègrent explicitement la fraîcheur dans leur modèle de pertinence. L'étude de Dong et al., Towards Recency Ranking in Web Search (WSDM 2010, équipe Yahoo Labs), décrit un classifieur qui détecte les requêtes sensibles à la récence et ajuste le classement en conséquence à l'aide de signaux temporels dédiés. La fraîcheur n'est donc pas qu'une bonne pratique éditoriale vague : c'est un signal de ranking modélisé pour une partie non négligeable des requêtes.

Le content decay se définit ainsi précisément : un déclin progressif des clics, impressions ou position moyenne sur une page, mesuré entre deux périodes comparables — pas un choc ponctuel lié à une mise à jour d'algorithme, qui touche le site entier plutôt qu'une page isolée.

Étape 1 — Extraire deux périodes comparables via l'API Search Console

Le workflow démarre par un Schedule Trigger mensuel, suivi de deux appels à l'endpoint searchanalytics.query de l'API Search Console : un premier pour les 90 derniers jours, un second pour les 90 jours précédents, tous deux avec la dimension page et un rowLimit élevé pour couvrir l'ensemble du site. La configuration du credential OAuth2 et les quotas de l'API sont détaillés dans notre guide du rapport SEO hebdomadaire avec Search Console — ce pipeline en reprend la base d'authentification sans la répéter ici.

Un point à surveiller : les deux appels doivent utiliser exactement les mêmes filtres (type de recherche, pays, appareil) pour rester comparables. Un filtre oublié sur l'un des deux appels fausse silencieusement tout le calcul de déclin qui suit.

Étape 2 — Calculer le déclin et éliminer le bruit

Un node Code fusionne les deux jeux de résultats sur l'URL de la page, puis calcule pour chacune la variation de clics, d'impressions et de position moyenne entre les deux périodes. Deux filtres évitent que le workflow ne remonte que du bruit statistique :

• un plancher d'impressions sur la période de référence (100 est un bon point de départ) : sous ce seuil, la variance naturelle dépasse largement tout signal réel de déclin ;
• un seuil de déclin réel, par exemple -25 % de clics entre les deux périodes.

Il vaut la peine de séparer deux signatures de déclin distinctes à ce stade, car elles n'appellent pas la même correction :

• impressions et clics baissent ensemble → la page perd effectivement de la visibilité dans les résultats, signe d'un vrai décalage de contenu ou de position ;
• impressions stables mais clics en baisse → la page reste visible mais moins cliquée, souvent le signe d'un titre ou d'une meta description devenus moins attractifs face à des extraits concurrents rafraîchis. Notre guide sur la génération de meta descriptions par IA couvre spécifiquement cette correction, plus rapide qu'une refonte complète.

Étape 3 — Diagnostiquer avec un AI Agent avant de toucher au contenu

Pour chaque page qui franchit le seuil, un node HTTP Request (ou un scraper dédié comme décrit dans notre guide de scraping web avec IA) récupère le contenu actuel de la page. Un AI Agent reçoit ensuite ce contenu, les métriques de déclin, et si possible un extrait du snippet actuellement en tête pour la requête principale visée. Sa mission n'est pas de réécrire la page, mais de poser un diagnostic structuré : statistique obsolète citée dans le texte, section devenue trop courte face à des concurrents plus complets, cannibalisation par une autre page du même site, ou absence de cause claire nécessitant une revue manuelle.

Un Structured Output Parser (voir notre guide dédié) force l'agent à retourner un format cohérent — verdict, cause probable, actions concrètes suggérées — exploitable sans reformatage manuel page après page.

Étape 4 — Router vers un backlog de refonte, jamais en publication directe

Le diagnostic de chaque page part ensuite vers une base Notion ou Airtable dédiée, servant de backlog de refonte trié par clics potentiellement récupérables (clics de la période de référence moins clics actuels). Un résumé condensé part en parallèle sur Slack, avec un node Wait qui suspend toute action tant qu'un éditeur n'a pas validé la priorité et l'angle de la refonte — le même mécanisme d'approbation humaine que celui détaillé dans notre guide sur Wait et Slack. Ce point n'est pas négociable : laisser un pipeline IA republier automatiquement une page qui génère déjà du trafic réel transforme un outil de diagnostic utile en risque de régression incontrôlée.

Pièges fréquents

• Confondre saisonnalité et déclin réel : comparez toujours la période récente à la même période l'année précédente en plus de la comparaison à 90 jours, pour écarter les variations cycliques normales (un guide « rentrée » qui décline naturellement chaque été, par exemple).
• Seuil trop bas : sans plancher d'impressions, le workflow noie les vraies alertes sous des dizaines de faux positifs venus de pages à trafic marginal.
• Déclin isolé vs déclin global : vérifiez d'abord la tendance de clics sur l'ensemble du site avant d'analyser page par page — un déclin généralisé pointe vers une mise à jour d'algorithme ou une perte d'autorité de domaine, pas vers un problème de contenu spécifique à corriger page par page.
• Oublier la cannibalisation interne : une page qui « décline » peut en réalité avoir été remplacée dans les résultats par une autre page plus récente de votre propre site. Vérifiez ce cas avant de lancer une refonte inutile.

Pour aller plus loin

Si vos contenus sont déjà indexés dans une base vectorielle pgvector pour un usage RAG, comme décrit dans notre guide Supabase et repris dans les workflows du Pack Assistant RAG (119 €), ce même index sert aussi à identifier automatiquement les pages evergreen du site à citer en maillage interne lors d'une refonte, sans recherche manuelle. Pour surveiller en parallèle ce que publient vos concurrents sur les mêmes sujets et enrichir le diagnostic de l'AI Agent, notre guide de veille concurrentielle automatisée complète naturellement ce pipeline de détection.