Rafraîchir d'anciens articles : la méthode qui ne casse rien

Pourquoi rafraîchir plutôt qu’écrire

Un site qui publie depuis des années a souvent plus de valeur dormante dans ses anciens articles que de valeur à créer avec de nouveaux. Les anciens ont des liens entrants, un historique, des impressions dans les résultats de recherche. Ce qui leur manque est presque toujours le même : des faits datés devenus faux, un titre qui ne donne pas envie de cliquer, aucun lien vers ce que l’entreprise vend, et une structure qui ne répond pas aux questions réellement tapées.

Le risque est symétrique. Une remise à jour mal faite peut supprimer le passage qui faisait le classement, changer une adresse sans redirection, ou introduire des chiffres que personne n’a vérifiés. Avec un assistant IA, ce dernier risque grandit : un modèle reformule vite, et remplit volontiers un trou avec un nombre plausible. La méthode ci-dessous existe pour qu’une refonte, même massive, reste vérifiable.

Le cas : 113 articles gelés

Notre client est une agence digitale d’une vingtaine de personnes, dont le site compte 233 adresses sous Drupal 7. Son blog réunissait 113 articles, l’essentiel écrit entre 2016 et 2019, avec un dernier vrai article en décembre 2025. Des actualités périmées et trompeuses restaient en ligne, et une bonne partie des articles ne liait aucun service.

Le 17 septembre, nous avons retravaillé ces 113 articles et les 31 pages de services, dans la même passe. Sur les 144 pages : 86 retravaillées avec la check-list entière, 41 en passe légère, 7 proposées à la fusion et 10 au retrait. Rien n’est publié à ce jour : la nouvelle version du site part en ligne d’un bloc, et les mesures avant et après seront publiées après la mise en ligne. Ce qui suit décrit la méthode et ce qu’elle a trouvé, pas un gain.

Geste 1 : figer et mesurer avant de toucher

Deux choses se font avant la première ligne modifiée.

Un point de retour. Un commit étiqueté qui ne contient aucun contenu modifié, seulement l’outillage et l’état « avant ». N’importe quelle page peut ensuite être comparée, ou restaurée, en une commande.

Un point de départ par page. Un script relève, pour chaque page, les clics, les impressions, la position moyenne et les premières requêtes sur 28 jours dans Search Console, ainsi que le nombre de mots, et range le tout daté dans un fichier de suivi. La règle de la check-list est écrite sans nuance : pas de point de départ, pas de refonte. Quatre semaines après la publication, le même script remesure la page au même endroit, avec les mêmes outils.

Ce relevé nous a appris quelque chose sur nos propres outils : la première version du script s’arrêtait à 5 000 lignes de Search Console et tronquait les requêtes des pages. Corrigé avant de s’en servir, sinon le « avant » aurait été faux.

Geste 2 : un journal par page, avant et après et pourquoi

Chaque page retravaillée a son journal : un fichier qui liste chaque modification, le point de la check-list qu’elle sert, le principe qu’elle applique, le texte avant, le texte après et la raison. Les sources citées y sont consignées, ainsi que les liens ajoutés, réorientés et retirés, et les questions laissées ouvertes.

C’est plus long à produire qu’un simple diff, et c’est ce qui rend la refonte relisable. Le client ne relit pas « un article qui a changé », il relit une liste de décisions, chacune justifiée. Il peut en refuser une sans tout rejeter.

Les principes eux-mêmes sont numérotés et partagés par toutes les pages. Deux comptent particulièrement pour un rafraîchissement :

• Fraîcheur honnête. Un fait daté est mis à jour avec une source ouverte, ou présenté comme historique. La date de mise à jour ne bouge que si le fond change, et la modification est dite. Une date changée sans raison fait perdre la confiance.
• Sources officielles, jamais les concurrents. Une à trois sources d’autorité à côté de l’affirmation qu’elles appuient, ouvertes avant d’être citées.

Sur cette passe, 698 sources ont été consignées, dont 633 ouvertes et lues avant d’être citées. Et la relecture des faits a trouvé des erreurs jusque dans des articles récents : des dates de textes réglementaires, des frais de vérification d’une plateforme, la fermeture supposée d’un moteur de recherche qui n’avait pas eu lieu. Les liens sortants ont aussi été relevés un par un : 178 au départ, dont 11 répondaient 404.

Geste 3 : prouver qu’aucun chiffre n’est inventé

C’est le contrôle qui nous paraît le plus important à l’époque des assistants de rédaction. Un script prend toutes les phrases nouvelles d’une page (absentes de la version de référence), en extrait chaque nombre, et cherche son origine :

• déjà présent dans la page avant la refonte (reformulation, déplacement) ;
• présent dans une source ouverte consignée au journal ;
• présent ailleurs sur le site ;
• une année seule (datation d’un fait), à relire ;
• examiné à la main et justifié dans le script.

Tout nombre qui ne rentre dans aucune case bloque : le script échoue. Sur la refonte, 2 143 nombres sont apparus dans des phrases nouvelles : 1 065 déjà dans la page, 809 dans une source du journal, 165 ailleurs sur le site, 61 années et 43 examinés un par un. Aucun sans origine.

Geste 4 : prouver qu’aucune perte ne se cache

Le risque inverse est plus discret : un passage utile qui disparaît dans une réécriture. Un premier contrôle compare chaque page à son archive et signale les passages absents. Sur une refonte, ces écarts sont attendus ; il faut donc un second contrôle qui les classe :

• cité dans un « avant » du journal (retrait ou réécriture assumés) ;
• reformulé (ses mots pleins sont toujours dans la page) ;
• dans une section dont la réécriture est documentée ;
• hors du corps de la page (blocs du gabarit) ;
• à relire.

Un passage absent d’une page qui n’a pas de journal est une perte, et le script échoue. Sur cette passe, 2 583 passages de l’archive avaient disparu, tous sur des pages retravaillées : 879 cités au journal, 446 reformulés, 1 086 dans des sections documentées, 58 hors du corps, et 114 fragments relus un par un. Aucun hors refonte.

Geste 5 : la check-list, la relecture, puis la mesure

Chaque page passe une check-list écrite, vérifiée par script sur toutes les pages : requête cible, titre et description, réponse directe en tête, structure en sous-questions avec une FAQ tirée des requêtes réelles, sources, lien vers le service, images décrites, écriture propre. Avant la refonte, l’audit relevait 938 cases non tenues sur 2 304, et aucune page sans défaut. Après, aucune. Ce qui reste attend une personne : la matière de première main de l’équipe, la relecture du client, la publication, la mesure.

La relecture n’est pas une formalité. Le client relit dans un outil où chaque modification est visible, et une règle de la mission limite la file : jamais plus de trois contenus en attente chez lui. Au-delà, plus personne ne relit vraiment.

Enfin, les décisions lourdes restent les siennes. Les fusions et les retraits sont proposés, avec les chiffres de chaque page et la page qui survivrait, mais aucun n’est appliqué sans sa décision. Une fusion n’est jamais un simple effacement : elle demande une redirection permanente, et que la page survivante reprenne ce qui faisait le trafic de l’autre.

Ce que nous faisons sur notre propre site

Notre moteur SEO et GEO applique la même logique en continu. Chaque nuit, un scan sans IA compare deux fenêtres de 28 jours de Search Console. Les pages dont les clics ont été divisés par deux ou plus entrent dans une file « refresh ». Un agent dédié prend la page et diagnostique avant de toucher : la glissade vient-elle d’un fait périmé, d’une page de résultats qui a changé de format, d’un problème technique (adresse, redirection, liens perdus), ou d’une saisonnalité ? Dans ce dernier cas, la bonne réponse est de ne rien faire, et de le dire.

Quand il y a quelque chose à corriger, l’agent produit un brouillon sur une branche, chaque chiffre re-sourcé, et c’est une personne qui relit et publie. Rien ne part automatiquement en ligne.

Cette discipline nous a servi sur nos propres textes : en relisant deux brouillons avant publication, la passe de fraîcheur a trouvé une affirmation qui citait l’annonce d’un déploiement à venir, alors que le déploiement avait déjà eu lieu. La leçon que nous en avons tirée vaut pour tout rafraîchissement : vérifier l’état présent d’un fait, jamais son annonce, et revérifier tout fait daté au moment de publier, pas seulement au moment d’écrire.

Si votre blog a des années d’articles et que vous ne savez pas par où commencer, un audit SEO donne l’ordre de priorité, page par page. Pour la structure qui relie ces articles aux pages qui vendent, voir la méthode du cocon sémantique.

Questions fréquentes