What is backdating and why does it work from a single workstation?

Backdating is when an article is written today but published with a date in the past (a week ago, say). Technically it's just the value of the pubDate field in the MD file frontmatter. This lets you 'fill the gap' in your archive: if nothing came out for six months, you can write a few posts and spread them across different dates so the blog doesn't look abandoned. It works from one workstation because you control both the content and the publishing system.

Do search engines really see the difference between 'published yesterday' and '11 posts published on the same day'?

Yes. They see the date from sitemap (lastmod), the publishing date from BlogPosting schema, the date from meta og:article:published_time. All three are usually identical. If 11 posts share the same pubDate, this enters the SERP dataset as a cluster with the same timestamp. When a site is young and used to publish 2-3 posts a week, a sudden 11-in-one-day is an anomaly. Search engines have been using such signals as part of spam detection for several years.

What happened after my 11 posts on a single date?

One of the article clusters fell into Excluded by noindex in Yandex. Not all 11, but about 5-6 from neighbouring pages. I can't definitively say the cause was backdating, because lots of other edits were happening in parallel. But the temporal correlation points there: the day of the 11-post drop and the next three days saw a noticeable rise in the Excluded share. Two weeks later I redistributed pubDate across the 20-30 April range and Excluded began rolling back.

What publishing cadence is normal for a new blog?

In my metrics, 2-3 articles a week works. That gives a steady flow, search engines see the 'a person writes regularly' pattern. In the first month you can push a 'wave' of 10-20 articles over a couple of weeks to quickly build a base. But I'd spread that wave across days, not hours. Minimum one post a day, maximum three. More than that is a 'content farm' signal, not a 'real author' one.

Can you fix the mistake after the fact, the way I did?

I rewrote pubDate in the frontmatter of all 11 articles, refreshed lastmod in the sitemap (which is pulled automatically from PHP filemtime), and pinged IndexNow on each URL to refresh the date in the index. Different dates appeared in the sitemap, Yandex and Google re-read the pages. Overall it worked - Excluded rolled back in 5-7 days. But it isn't a perfect fix: the original '11 on one day' signal was seen by search engines and may have been recorded. Better to publish evenly from the start.

Backdating 11 blog posts on one date: why not to do it

In the first month of a new site I wanted to quickly build a mass of blog posts. I wrote a ‘wave’ of 21 articles in two days and published it on April 9. Then I wrote another 11 and decided to ship them in one day - April 17. Technically it was one git commit && rsync. By the end of April I started noticing neighbouring pages slipping into Excluded in Yandex. Two weeks later I came back and redistributed the dates. Story below.

In brief

Published 11 ready posts in a single day with pubDate set to the same day (April 17).

About 10 days later, neighbouring pages started slipping into Excluded by noindex in Yandex.

I can’t 100% prove the density was the cause - many other edits were running in parallel. But the temporal correlation is clear.

Redistributed pubDate across April 20-30, refreshed lastmod, pinged IndexNow. Excluded rolled back within a week.

Lesson: 2-3 posts a week, max 1-3 a day. Not 11.

Why I published 11 at once in the first place

The logic was simple. The site had 6 system pages and 18 service pages - the standard set for a commercial site. Search engines want more: they like sites with deep content, FAQ, topical expertise. A blog is the cheapest way to show it.

I sat down and wrote. In a week - 21 articles (wave 1, April 9). A week later, another 11 (wave 2, April 17). They were topically diverse: cleaning-type guides, common Q&A explainers, local-query articles. 1500-3000 words each. The sensible thing would have been to spread them across the calendar - a couple a week, no more than five a day. But I thought: ‘better dump all the content at once, search engines will index it faster.’ That was a mistake.

What Yandex saw

7 days after the second wave I opened Yandex Webmaster and looked at the ‘Pages in search’ tab. The picture:

Searchable - 111 pages
Excluded by noindex - 56 pages

Of those 56, roughly 25 were blog posts. The rest were old URL versions and test pages I’d excluded myself via Disallow in robots.txt. So half of the new blog posts had already been rejected.

I opened the details - Yandex shows the reason. Most said ‘Document does not meet search engine requirements’. An abstract reason with no breakdown. Sometimes ‘duplicate of another document’ - but I made no physical duplicates, the content is unique.

The most interesting part - rejections were clustered. Not random articles from different places, but neighbours by pubDate. Those April 17 ones plus neighbours from April 9. Something in the publication date was tugging at filters.

Hypothesis: density

I can’t definitively prove cause and effect, because those days I was running plenty of other edits in parallel: adding schema, cleaning up CLS, reshuffling robots.txt. Maybe one of those days I accidentally broke something else. But the time alignment was so tight that I went through the hypotheses and landed on publishing density.

Now the theory. Search engines have for several years used a ‘content farm’ pattern as part of spam detection. That’s when a site suddenly ‘drops’ a large batch of posts on one date - typical of PBNs that auto-generate content from a template. Real blogs publish gradually: a pair of posts a week, sometimes a spike to three or four a day.

The signal in my case looked like this:

New site, domain registered in March
First two weeks - a static commercial site with no blog
April 9 - 21 posts on one date
April 17 - another 11 on one date

That’s a content-farm pattern. Especially if you look at the site RSS feed on April 17 - 32 fresh items at once with similar H1s (‘Apartment cleaning X’, ‘Apartment cleaning Y’, ‘Apartment cleaning Z’). Any automated moderation system will see a suspicious signal here.

What I did to fix it

When I figured out what was happening - on April 28 I sat down and re-spread the dates.

Step 1: rewrote pubDate in the frontmatter of 11 wave-2 articles. Instead of one 2026-04-17 I set dates across the April 20-30 range, one per day:

# Was
---
pubDate: 2026-04-17
---

# Became (different across articles)
---
pubDate: 2026-04-22
---

Step 2: updated updated: too, so Yandex would see a fresh timestamp. Didn’t repeat pubDate, set 2026-04-28 (that day).

Step 3: rebuilt the sitemap. My lastmod is pulled from PHP filemtime(), so re-saving the files and regenerating the sitemap was enough.

Step 4: sent all 11 URLs through IndexNow to Bing and Yandex:

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

Step 5: for safety, sent a portion of URLs via Yandex Webmaster API /recrawl/queue (quota 620/day):

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/..."}'

What happened after the fix

Excluded started rolling back. 5 days after the edit, 12 of 25 pages returned to Searchable, another 9 followed five days later. By May 5 Excluded held 1-2 posts (and those were system pages, not blog).

Exact figures are in the ‘50 days of SEO’ article - it has overall Searchable/Excluded dynamics and recrawl-via-API tricks. On backdating - this is the ‘don’t publish in bulk’ story.

If I did it again

Scenario 1: one person writing a 20-article ‘wave’ in a week.

Prepare all 20 in advance. Publish 2-3 a day across 7-10 days. Different pubDate each day. The site RSS updates as a steady stream. Search engines see an ‘active blog’ pattern, not a ‘content farm’.

Scenario 2: a blog that’s been dead for a while, needs reviving.

Sometimes a blog hasn’t published for six months to a year, and the gap needs filling. Then you can actually backdate - but not all articles on one date, spread them across the calendar with a 5-10 day step. For instance, 8 ready articles across ‘3 months ago → today’ looks like ‘a person publishes biweekly, doesn’t hit a regular cadence, but is active’.

Scenario 3: one day - one post, no schedule.

That’s the ideal mode for a small blog. You write when you feel like it and have something to say. If you have two solid drafts in one day - publish both, but with an hour gap and two different pubDates. Not as one line in the RSS feed.

Control indicators

To catch the anomaly before search engines do:

Searchable / Excluded chart in Yandex Webmaster. If Excluded climbs after a wave drop - that’s the signal.
Sitemap index and lastmod. A site with healthy publishing dynamics has lastmod spread across the calendar. All identical lastmod is a red flag.
RSS feed. If it has 10+ fresh items with the same <pubDate>, redo the layout.

This isn’t about fooling search engines - actually impossible. It’s about your blog looking like a blog, not like an import from an old system. Cadence is a signal. Search engines watch it because content farms get in the way of ranking quality content.

The full case for 50 days of SEO in B2B cleaning - in the article ‘50 days of SEO in B2B cleaning’. This backdating story is one of the episodes from there.

If you’re planning a blog launch or need to fix an already-formed pattern - write to me in Telegram @dimik90. On services:

SEO for services - tech, schema, content, publishing cadence
Remote head of marketing - external marketing department lead
Independent contractor audit - review of your current SEO agency’s work