Does Google actually use publish dates as a spam signal?

Google does not publish its feature list, but the March 27, 2026 core update notes specifically called out programmatically generated sites, and date distribution is one of the cheapest behavioural tells available to a classifier. A corpus where every page shares a timestamp could not have come from an editorial process. pseolint treats it as corroborating evidence at warning severity, not as a standalone verdict.

I migrated my site and every page got today's date. Am I penalised?

A migration that rewrites all publish dates to the cutover day is the classic false-trigger. It is not a penalty, but it does erase the genuine history that would otherwise vouch for your site. Where you can, restore the real article:published_time from your old system; the rule reads that field directly and the warning clears once the dates reflect reality.

What is the difference between the 100/day floor and the 10% ceiling?

The rule uses whichever is larger. Small and mid-size sites are governed by the absolute floor of 100 pages per day. Once 10% of your total corpus exceeds 100, the corpus-relative ceiling takes over — a 50,000-page site can publish up to 5,000 pages on one day before tripping. The design lets big publishers grow in bursts while keeping small sites from faking scale with a single dump.

Should I just remove publish dates to avoid this?

Only if you have no real dates to show. The rule skips pages with no detectable date, so stripping dates does silence it — but it also throws away a freshness and trust signal that helps elsewhere. The better move is to expose accurate dates that happen to be well distributed, which satisfies this rule and the aeo/freshness-signals rule at the same time. A philately seller who stamps each listing with the day its first-day cover was catalogued shows a believable, well-spread release history rather than one suspicious bulk import.

Rule referencespam/publication-velocity

Publication Velocity — When Your Publish Dates Betray Bulk Generation

spam/publication-velocity groups your pages by publish date and warns when any single day exceeds the greater of 100 pages or 10% of your whole corpus — the date-stacking signal Google's March 27, 2026 core update tightened against programmatically generated sites.

Test this rule on your site →Run a full audit

Test your site for publication velocity — when your publish dates betray bulk generation

What it detects

spam/publication-velocity reads the publish date off every page — from article:published_time, a datePublished meta, or the first time[datetime] element — truncates it to a calendar day, and groups the corpus by that day. Pages with no detectable date are skipped, so the rule only judges what it can actually see.

The ceiling is corpus-relative. The effective limit for any day is the greater of two numbers: the absolute floor of 100 pages per day, and 10% of your total page count. A 400-page site is governed by the 100/day floor; a 50,000-page site can legitimately publish up to 5,000 pages on one date before the rule says anything. Any day that exceeds its effective limit emits a single warning naming the date, the count, and which ceiling it breached. The corpus-relative design is what keeps the rule from punishing large, legitimately busy publishers while still catching the small site that stamped 800 generated pages with one timestamp.

Why it matters

Real editorial calendars are lumpy but human. Pages trickle out across days and weeks; a backlog clears in a burst, then quiet returns. A corpus where ten thousand URLs all carry the same publish date did not come from an editorial process — it came from a single generation job, and the timestamp is the receipt. Date-stacking is one of the few scaled-content signals that survives even when each individual page looks acceptable, because it describes the corpus, not the page.

Google's March 27, 2026 core update explicitly tightened how date-stacked corpora are weighed, which is why this rule moved from a curiosity to a real signal. The fix costs nothing in content quality — you are not rewriting anything, only spreading out the dates you expose — but ignoring it leaves a structural fingerprint that pairs badly with thin-content or near-duplicate findings on the same template. When several scaled-content signals stack, the corpus gets re-scored as a unit.

A page that fails

A recipe site imports 2,400 pages from a spreadsheet on a Sunday and ships them at once. Every page carries an article:published_time of 2026-02-15. The corpus is 3,000 pages, so the effective ceiling is the greater of 100 and 300, which is 300; the 2,400-page spike on a single date blows through it and the rule warns: '2,400 pages share publish date 2026-02-15, exceeding 10% of the 3,000-page corpus (300/day).'

A page that passes

The same 2,400 imported recipes, but the import script backdates each page to the day its source recipe was actually created and drip-publishes new ones on a real cadence. No single day holds more than roughly 40 pages. The effective ceiling of 300/day is never approached, the rule stays silent, and the corpus reads like something a kitchen team built over years rather than a spreadsheet dumped in an afternoon.

How to fix it

1Spread real dates, do not fabricate them. If your pages were genuinely created over time, surface that true history in article:published_time instead of stamping every record with the import date.
2Drip-publish new batches. Releasing generated pages over days or weeks both lowers the per-day count and matches how Google expects a healthy site to grow.
3Raise the corpus, not the spike. The ceiling scales with total page count, so the rule naturally relaxes as a site earns scale — but only if growth is distributed, not stacked.
4Check which field you expose. If you have no real publish dates, consider omitting them rather than stamping a placeholder, since the rule skips pages with no detectable date.
5Treat a velocity warning as a prompt to audit the same template for thin-content and near-duplicate — date-stacking rarely travels alone.

SpamBrain context

Publication velocity is a behavioural signal rather than a content one, which is what makes it hard to fake. The scaled-content-abuse policy introduced on March 5, 2024 reframed Google's old 'automatically generated content' rule around volume-and-value rather than authorship, and the March 27, 2026 core update sharpened enforcement on corpora whose publish-date distribution looks machine-made.

spam/publication-velocity (in @pseolint/core, MIT-licensed at github.com/ouranos-labs/pseolint) is deliberately the gentlest member of the spam family — it emits at warning severity, never critical, because a date spike alone is suggestive, not damning. Its value is as corroboration: when a template already trips spam/template-diversity or spam/boilerplate-ratio, a date-stacked publish history is the behavioural evidence that the structural homogeneity came from bulk generation. The corpus-relative 10% ceiling, layered over the absolute 100/day floor, is tuned so a genuine large publisher clears it while a small site faking scale does not.

Frequently asked questions

Does Google actually use publish dates as a spam signal?: Google does not publish its feature list, but the March 27, 2026 core update notes specifically called out programmatically generated sites, and date distribution is one of the cheapest behavioural tells available to a classifier. A corpus where every page shares a timestamp could not have come from an editorial process. pseolint treats it as corroborating evidence at warning severity, not as a standalone verdict.
I migrated my site and every page got today's date. Am I penalised?: A migration that rewrites all publish dates to the cutover day is the classic false-trigger. It is not a penalty, but it does erase the genuine history that would otherwise vouch for your site. Where you can, restore the real article:published_time from your old system; the rule reads that field directly and the warning clears once the dates reflect reality.
What is the difference between the 100/day floor and the 10% ceiling?: The rule uses whichever is larger. Small and mid-size sites are governed by the absolute floor of 100 pages per day. Once 10% of your total corpus exceeds 100, the corpus-relative ceiling takes over — a 50,000-page site can publish up to 5,000 pages on one day before tripping. The design lets big publishers grow in bursts while keeping small sites from faking scale with a single dump.
Should I just remove publish dates to avoid this?: Only if you have no real dates to show. The rule skips pages with no detectable date, so stripping dates does silence it — but it also throws away a freshness and trust signal that helps elsewhere. The better move is to expose accurate dates that happen to be well distributed, which satisfies this rule and the aeo/freshness-signals rule at the same time. A philately seller who stamps each listing with the day its first-day cover was catalogued shows a believable, well-spread release history rather than one suspicious bulk import.

Related rules

Want to know whether this rule actually fires on your site?

Run pseolint against your sitemap. The audit is free, takes about a minute, and returns a per-URL list of every rule that fired — including this one — with the exact metric values so you can prioritise the fix queue.

Open the spambrain checker All rules