Faut-il changer la date de publication après une grosse refonte ?

Changer la date de publication après une grosse refonte SEO peut être une bonne décision. Mais c’est aussi l’un des gestes les plus faciles à faire de travers. Une date récente rassure le lecteur, peut améliorer le clic si le sujet vieillit vite, et rend la page plus cohérente quand elle a vraiment été reprise. À l’inverse, changer une date pour donner un coup de frais artificiel abîme la confiance.

Le sujet est donc moins technique qu’il en a l’air. La vraie question n’est pas “est-ce que Google va aimer ?”. La vraie question est : est-ce que la page mérite honnêtement d’être présentée comme une nouvelle version ?

Date de publication ou date de mise à jour ?

Avant de décider, il faut distinguer trois informations qui sont souvent mélangées.

Dans WordPress, un éditeur peut facilement modifier la date de publication. Sur un site Next ou statique, la date peut venir d’un fichier de contenu, d’un CMS, d’un champ `datePublished`, d’un champ `dateModified`, ou d’une combinaison. Peu importe l?architecture : si la page affiche une date récente, le contenu doit mériter cette date.

C’est aussi pour cela que le guide sur la mise à jour d’un vieil article sans perdre son SEO commence par l’intention, l’URL, les sections à préserver et les preuves. La date n’arrive pas en premier. Elle vient valider le niveau réel de travail.

Ce que Google dit vraiment sur les dates

Google recommande d’utiliser des dates claires, visibles et cohérentes quand elles aident l’internaute. Sa documentation sur les dates de publication dans les résultats de recherche explique que les dates peuvent venir de plusieurs signaux : texte visible, données structurées, sitemap, flux ou autres éléments de page. Elle insiste surtout sur la cohérence.

Google précise aussi qu’il ne faut pas donner une impression de fraîcheur si le contenu n’a pas changé de manière substantielle. C’est le point à retenir. Le problème n’est pas de mettre à jour une date. Le problème est de faire croire à une mise à jour qui n’existe pas.

Sur les données structurées, le balisage Article ou BlogPosting permet d’indiquer `datePublished` et `dateModified`. Là encore, ces champs ne doivent pas raconter une histoire différente de celle que le lecteur voit dans la page.

Quand garder la date d’origine

Garder la date d’origine est souvent le meilleur choix quand la modification reste légère. Par exemple : correction d’une faute, remplacement d’un lien cassé, ajout d’une phrase, petite mise à jour de CTA, précision sur un prix, ajustement d’un paragraphe ou nettoyage d’un visuel.

Dans ces cas, il est plus honnête d’afficher “Mis à jour le…” que de faire comme si l’article venait d’être publié. Le lecteur comprend que la page a de l’historique, mais qu’elle n’est pas abandonnée. Pour les sujets de méthode, cette transparence peut même renforcer la confiance.

Je garderais aussi la date d’origine si l’article a une valeur historique. Un retour d’expérience, une annonce, une analyse d’un événement passé ou une étude datée ne doivent pas toujours être “rajeunis”. On peut ajouter une note de mise à jour, corriger les informations périmées, et garder la trace du moment où l’article a été publié.

Quand changer la date de publication

Changer la date de publication se défend quand la refonte transforme vraiment la page. Pas forcément parce que 80 % des phrases ont changé, mais parce que la valeur livrée au lecteur n’est plus la même.

1. L’intention a été reprise. L’article ne répond plus seulement à l’ancien angle ; il répond à la manière dont les gens cherchent aujourd’hui.
2. Les informations sensibles ont été vérifiées. Prix, fonctionnalités, captures, liens, dates, alternatives, conditions commerciales ou règles Google ont été actualisés.
3. La structure a changé. Nouveaux H2, FAQ, tableau, exemple, verdict, section de décision ou comparaison utile.
4. Le maillage a été revu. Les liens entrants et sortants sont cohérents avec les contenus actuels du site.
5. Le contrôle après publication est prévu. La refonte est notée dans Search Console, dans un suivi interne ou dans un journal de changements.

Dans ce cas, changer la date ne sert pas à tromper. Cela signale au lecteur que la page a été reprise sérieusement. Ici, c’est exactement ce qu’on fait quand un vieux contenu est réellement reconstruit : on assume la nouvelle version, au lieu de laisser une date ancienne contredire le travail effectué.

Les cas limites les plus fréquents

La décision devient moins évidente quand la page mélange ancienneté, trafic, affiliation, historique et changement d’angle. Voici les cas où je ferais particulièrement attention.

Un ancien article qui ranke déjà bien. Ne changez pas la date juste parce que l’année paraît vieille. Si la page fonctionne, commencez par comprendre pourquoi. Une date de mise à jour visible peut suffire.

Un article commercial avec prix ou code promo. Si le prix, le code, les captures et les conditions ont été revérifiés, une date récente est utile. Si seul le code promo change, mieux vaut indiquer la vérification du code plutôt que republier toute la page.

Deux articles fusionnés. Si une page devient la nouvelle version complète de deux contenus plus faibles, changer la date de publication peut être logique. Mais les redirections, les anciennes URL et les liens internes doivent suivre.

Un article d’actualité transformé en guide durable. C’est souvent un bon candidat à une nouvelle date, car la page ne joue plus le même rôle. Il faut toutefois réécrire l’intro pour éviter l’effet “ancien article maquillé”.

Un changement de titre sans vrai fond. Là, prudence. Si vous modifiez seulement le title ou l’année dans le H1, gardez la date d’origine et assumez une simple mise à jour.

Tableau de décision

Comment afficher les dates proprement

Le plus propre est souvent d’afficher deux informations quand le contexte le justifie : “Publié le…” et “Mis à jour le…”. Sur certains articles, une seule date de mise à jour peut suffire, surtout si le template garde la date de publication dans les données structurées.

Ce qu’il faut éviter, c’est l’incohérence. Si la page visible dit “Publié le 4 septembre 2026” mais que le schéma indique une date de 2024, le signal est brouillé. Même chose si le sitemap, l’Open Graph ou les cartes d’archive racontent autre chose.

Pour une refonte importante, je préfère cette logique :

• date visible récente si la page est vraiment reconstruite ;
• `datePublished` cohérent avec la version publiée ;
• `dateModified` cohérent avec la dernière modification importante ;
• note de mise à jour si un passage ancien mérite d’être contextualisé ;
• annotation dans le suivi SEO pour relire les courbes plus tard.

L’article sur les annotations Search Console après refonte ou publication complète bien ce point. Sans date de suivi, une variation SEO devient vite impossible à interpréter.

Contrôles après refonte

Une fois la date choisie, le travail n’est pas terminé. Il faut vérifier que le site entier raconte la même chose.

1. Ouvrir la page. Date visible, fil d’Ariane, carte d’archive, article lié et image principale doivent être cohérents.
2. Vérifier les données structurées. Article ou BlogPosting, `datePublished`, `dateModified`, image, auteur et fil d’Ariane.
3. Contrôler le sitemap. La page doit apparaître avec une date cohérente si elle est publiée.
4. Tester les anciennes URL. En cas de fusion ou de changement de slug, les redirections doivent être propres.
5. Relire Search Console. Surveillez clics, impressions, requêtes et title affiché dans Google pendant les semaines suivantes.

Google rappelle que les changements de page peuvent demander du temps avant d’être repris dans les résultats, car la page doit être recrawlée et retraitée. Il faut donc distinguer le bug immédiat, qu’on corrige tout de suite, de l’évolution SEO, qui se lit sur plusieurs semaines.