· 8 min de lecture

Backdater 11 posts de blog à la même date : pourquoi ne pas le faire

J'ai publié 11 articles prêts à la même date. Deux semaines plus tard, j'ai compris que je m'étais tiré une balle dans le pied. Comment corriger.

Le premier mois d’un nouveau site, je voulais constituer rapidement une masse de publications de blog. J’ai écrit une ‘vague’ de 21 articles en deux jours, publiée le 9 avril. Puis j’en ai rédigé 11 de plus et décidé de les sortir en un seul jour - le 17 avril. Techniquement c’était un git commit && rsync. Fin avril, j’ai commencé à remarquer que des pages voisines glissaient vers Excluded chez Yandex. Deux semaines plus tard, je suis revenu et j’ai redistribué les dates. L’histoire ci-dessous.

En bref

  • Publié 11 posts prêts en une journée avec pubDate calé sur le même jour (17 avril).
  • Environ 10 jours plus tard, des pages voisines ont commencé à glisser vers Excluded by noindex chez Yandex.
  • Je ne peux pas prouver à 100 % que la densité en est la cause - beaucoup d’autres édits tournaient en parallèle. Mais la corrélation temporelle est nette.
  • Redistribué pubDate sur la plage 20-30 avril, rafraîchi lastmod, pingé IndexNow. Excluded a reculé en une semaine.
  • Leçon : 2-3 posts par semaine, max 1-3 par jour. Pas 11.

Pourquoi j’ai publié 11 d’un coup au départ

La logique était simple. Le site avait 6 pages système et 18 pages de services - le set standard pour un site commercial. Les moteurs en veulent plus : ils aiment les sites avec du contenu profond, des FAQ, de l’expertise thématique. Le blog est le moyen le moins cher de le montrer.

Je me suis mis à écrire. En une semaine - 21 articles (vague 1, 9 avril). Une semaine plus tard, 11 de plus (vague 2, 17 avril). Thématiquement variés : guides de types de nettoyage, explications de questions courantes, articles pour requêtes locales. 1500-3000 mots chacun. La sagesse aurait été de les répartir sur le calendrier - deux par semaine, pas plus de cinq par jour. Mais je me suis dit : ‘mieux vaut tout balancer d’un coup, les moteurs indexeront plus vite.’ Erreur.

Ce que Yandex a vu

7 jours après la deuxième vague, j’ai ouvert Yandex Webmaster et regardé l’onglet ‘Pages dans la recherche’. Image :

  • Searchable - 111 pages
  • Excluded by noindex - 56 pages

Sur ces 56, environ 25 étaient des posts de blog. Le reste, d’anciennes versions d’URL et des pages de test que j’avais moi-même exclues via Disallow dans robots.txt. Donc la moitié des nouveaux posts était déjà rejetée.

J’ai ouvert le détail - Yandex affiche la raison. La plupart disaient ‘Le document ne répond pas aux exigences du moteur’. Motif abstrait, sans détail. Parfois ‘doublon d’un autre document’ - mais je n’ai pas fait de doublons physiques, le contenu est unique.

Le plus intéressant - le rejet était par cluster. Pas des articles aléatoires de différents endroits, mais des voisins par pubDate. Ces fameux 17 avril plus les voisins du 9 avril. Quelque chose dans la date de publication tirait sur les filtres.

Hypothèse : densité

Je ne peux pas prouver de causalité, parce que ces jours-là je faisais plein d’autres modifications en parallèle : ajout de schema, nettoyage du CLS, retouche de robots.txt. Peut-être qu’un de ces jours j’ai cassé autre chose accidentellement. Mais le timing était si serré que j’ai passé en revue les hypothèses et je me suis arrêté sur la densité de publication.

Théorie maintenant. Les moteurs utilisent depuis plusieurs années un pattern ‘usine à contenu’ contre le spam. C’est quand un site ‘sort’ brusquement un gros lot de posts à la même date - typique des PBN qui génèrent du contenu auto à partir d’un template. Les vrais blogs publient progressivement : deux posts par semaine, parfois un pic à trois-quatre par jour.

Le signal dans mon cas ressemblait à ça :

  • Site neuf, domaine déposé en mars
  • Deux premières semaines - site commercial statique sans blog
  • 9 avril - 21 posts à la même date
  • 17 avril - 11 de plus à la même date

C’est un pattern d’usine à contenu. Surtout si on regarde le flux RSS du site au 17 avril - 32 items frais d’un coup avec des H1 similaires (‘Nettoyage appartement X’, ‘Nettoyage appartement Y’, ‘Nettoyage appartement Z’). N’importe quel système de modération automatisée verra ici un signal suspect.

Ce que j’ai fait pour corriger

Quand j’ai compris ce qui se passait - le 28 avril, je me suis assis et j’ai ré-étalé les dates.

Étape 1 : réécrit pubDate dans le frontmatter des 11 articles de la vague 2. Au lieu d’un seul 2026-04-17, j’ai mis des dates sur la plage 20-30 avril, une par jour :

# Avant
---
pubDate: 2026-04-17
---

# Devenu (différent selon les articles)
---
pubDate: 2026-04-22
---

Étape 2 : mis à jour updated: aussi, pour que Yandex voie un timestamp frais. Pas répété pubDate, mis 2026-04-28 (ce jour).

Étape 3 : reconstruit le sitemap. Mon lastmod est tiré de PHP filemtime(), donc re-sauvegarder les fichiers et regénérer le sitemap a suffi.

Étape 4 : envoyé les 11 URL via IndexNow à Bing et Yandex :

curl -X POST https://api.indexnow.org/indexnow \
  -H "Content-Type: application/json" \
  -d '{"host":"example.com","key":"...","urlList":["...","..."]}'

Étape 5 : par sécurité, envoyé une partie des URL via l’API Yandex Webmaster /recrawl/queue (quota 620/jour) :

curl -X POST "https://api.webmaster.yandex.net/v4/user/<user-id>/hosts/<host-id>/recrawl/queue" \
  -H "Authorization: OAuth $TOKEN" \
  -d '{"url":"https://example.com/blog/..."}'

Ce qui s’est passé après le fix

Excluded a commencé à reculer. 5 jours après la correction, 12 pages sur 25 sont revenues dans Searchable, 9 de plus cinq jours plus tard. Au 5 mai, Excluded retenait 1-2 posts (et c’étaient des pages système, pas du blog).

Les chiffres exacts sont dans l’article ‘50 jours de SEO’ - il contient la dynamique globale Searchable/Excluded et les astuces de recrawl par API. Sur le backdating - c’est l’histoire ‘ne publiez pas en bloc’.

Si je devais refaire

Scénario 1 : une personne qui écrit une ‘vague’ de 20 articles en une semaine.

Préparer les 20 à l’avance. Publier 2-3 par jour sur 7-10 jours. pubDate différent chaque jour. Le flux RSS du site se met à jour en flux régulier. Les moteurs voient un pattern ‘blog actif’, pas ‘usine à contenu’.

Scénario 2 : un blog mort depuis longtemps, à ranimer.

Il arrive qu’un blog n’ait pas publié pendant six mois à un an et qu’il faille combler le vide. Là, on peut effectivement backdater - mais pas tous les articles à la même date, les étaler sur le calendrier avec un pas de 5-10 jours. Par exemple, 8 articles prêts sur la période ‘3 mois en arrière → aujourd’hui’ donne l’impression d’une personne ‘qui publie tous les quinze jours, ne tient pas une cadence régulière, mais est active’.

Scénario 3 : un jour - un post, aucun planning.

C’est le mode idéal pour un petit blog. On écrit quand on en a envie et qu’on a quelque chose à dire. Si deux bons brouillons sont prêts en une journée - on publie les deux, mais avec une heure d’écart et deux pubDate différents. Pas une seule ligne dans le RSS.

Indicateurs de contrôle

Pour repérer l’anomalie avant les moteurs :

  • Courbe Searchable / Excluded dans Yandex Webmaster. Si Excluded grimpe après une vague - c’est le signal.
  • Index sitemap et lastmod. Un site avec une dynamique de publication saine a lastmod réparti sur le calendrier. Tous les lastmod identiques, c’est un drapeau rouge.
  • Flux RSS. S’il contient 10+ items frais avec le même <pubDate>, refaire la disposition.

Il ne s’agit pas de tromper les moteurs - en réalité impossible. Il s’agit que votre blog ressemble à un blog, pas à un import d’un vieux système. La cadence est un signal. Les moteurs la regardent parce que les usines à contenu les empêchent de ranker du contenu de qualité.

Le cas complet sur 50 jours de SEO en nettoyage B2B - dans l’article ‘50 jours de SEO en nettoyage B2B’. Cette histoire de backdating en est un épisode.

Si vous prévoyez le lancement d’un blog ou devez soigner un pattern déjà installé - écrivez-moi sur Telegram @dimik90. Sur les services :

À lire aussi : CLS 0,377 → 0,002 en une journée, formulaire anti-spam sans captcha.

Questions fréquentes

Qu'est-ce que le backdating et pourquoi ça marche depuis un seul poste de travail ?
Le backdating, c'est quand un article est écrit aujourd'hui mais publié avec une date dans le passé (il y a une semaine, par exemple). Techniquement c'est juste la valeur du champ pubDate dans le frontmatter du fichier MD. Cela permet de 'combler le vide' dans les archives : si rien n'est sorti pendant six mois, on peut écrire quelques posts et les répartir sur différentes dates pour que le blog ne paraisse pas abandonné. Ça marche depuis un seul poste parce qu'on contrôle à la fois le contenu et le système de publication.
Les moteurs voient-ils vraiment la différence entre 'publié hier' et '11 posts publiés le même jour' ?
Oui. Ils voient la date du sitemap (lastmod), la date de publication du schema BlogPosting, la date de meta og:article:published_time. Les trois sont habituellement identiques. Si 11 posts partagent le même pubDate, cela entre dans le dataset SERP comme un cluster avec le même timestamp. Quand un site est jeune et publiait jusque-là 2-3 posts par semaine, un brusque 11-en-un-jour est une anomalie. Les moteurs utilisent ce genre de signaux dans la détection de spam depuis plusieurs années.
Que s'est-il passé après mes 11 posts à la même date ?
Un des clusters d'articles est tombé dans Excluded by noindex chez Yandex. Pas les 11, mais environ 5-6 issus de pages voisines. Je ne peux pas affirmer catégoriquement que la cause est le backdating, parce que plein d'autres modifications tournaient en parallèle. Mais la corrélation temporelle pointe par là : le jour de la publication des 11 posts et les trois jours suivants, la part d'Excluded a nettement grimpé. Deux semaines plus tard, j'ai redistribué pubDate sur la plage 20-30 avril et Excluded a commencé à reculer.
Quelle cadence de publication est normale pour un nouveau blog ?
Dans mes métriques, 2-3 articles par semaine fonctionne. Cela donne un flux régulier, les moteurs voient un pattern 'une personne écrit régulièrement'. Le premier mois on peut pousser une 'vague' de 10-20 articles sur deux semaines pour construire vite une base. Mais je répartirais cette vague sur des jours, pas sur des heures. Minimum un post par jour, maximum trois. Plus, c'est un signal 'usine à contenu', pas un 'vrai auteur'.
Peut-on rattraper l'erreur après coup, comme je l'ai fait ?
J'ai réécrit pubDate dans le frontmatter des 11 articles, rafraîchi lastmod dans le sitemap (qui est tiré automatiquement de PHP filemtime), et pingé IndexNow sur chaque URL pour rafraîchir la date dans l'index. Des dates différentes sont apparues dans le sitemap, Yandex et Google ont relu les pages. Globalement ça a marché - Excluded a reculé en 5-7 jours. Mais ce n'est pas un fix parfait : le signal initial '11 en un jour' a été vu par les moteurs et peut avoir été enregistré. Mieux vaut publier régulièrement dès le départ.