Google spam policies, fake freshness, and why your dates matter more than you think

We run three content sites on daily AI publishing. Last week we asked a simple question: are our posted dates honest? They were not. For context on how we structure production ops, see our AI design engineering guide.

SEO·Aug 25, 2026·6 min read

Google does not punish a single wrong date. It does punish a pattern of misleading freshness. The five places it checks — visible byline, `article:published_time`, JSON-LD, sitemap `lastmod`, and the live page — must agree and must not be in the future. We failed on two of them. Here is what we found, why the August 2026 spam update should worry you if you fake dates, and the three fixes that made our lint pass.

What Google means by spam policies and scaled content abuse

Google’s spam policies list named violations: cloaking, doorway abuse, expired domain abuse, hidden text, link spam, machine-generated traffic, misleading functionality, scaled content abuse, scraping, and others. There is no line that says “wrong dates = spam.”

Scaled content abuse is the one that matters for AI blogs in 2026:

Using automation or generative AI to produce many pages without adding value.

That includes scraping and synonymizing, stitching without value, and — by the spirit of the policy — bulk touching `lastmod` or bylines without substantive updates. Google’s SpamBrain and the helpful-content classifier compare `bylineDate` vs `lastSignificantUpdate`. The self-assessment question is explicit: “Are you changing the date of pages to make them seem fresh when the content has not substantially changed?”

The global spam update of Aug 18-21, 2026 — two days, sixteen hours — targeted scaled content abuse, scraped content, doorway and expired-domain patterns, not links. If you fake freshness at scale, you fit the pattern.

For a crisp explainer, Google Search Central on publication dates and the Search Essentials spam intro are the canonical sources.

What Google actually checks for your dates

From publication dates best practices:

“Google doesn’t depend on a single date factor … systems look at several factors to determine our best estimate.” “Make your dates and times consistent.” “Do not specify future dates, or the date of the action described on the page.” “Minimize the presence of other dates on the page.”

In practice, that means:

• Visible byline on the page must match `article:published_time` and JSON-LD `datePublished` / `dateModified`
• Sitemap `lastmod` must equal the page’s last substantive modification, not build time
• No future dates — they are ignored and you lose freshness signals, byline in SERPs, and Google News and Discover eligibility

Violations do not usually trigger a manual action you can reconsider. They feed algorithmic demotion via SpamBrain. Recovery, per Google, is “many months” after you fix the substance and the signals.

What we found across our three sites

We audit mosh.fyi, convfetti.com, and hawklist CMS daily. On 2026-08-25 the lint showed three patterns:

mosh.fyi — dates set via `publishedTime` in MDX plus ArticleJsonLd plus visible ArticleMeta plus sitemap at `app/sitemap.ts:24`. Sitemap used `lastModified: new Date()` for every URL, marking all pages as changed today. Three pillars were back-dated 107 to 275 days vs git (2025-10-15 claimed but init was 2024-12-19). Fix: replaced sitemap with per-route map to real dateModified or publishedTime. Lint now fails on bare new Date().

convfetti.com — YAML `date: 2026-08-24` plus JSON-LD at `public/content/blog/posts/*.md:3` and `src/app/sitemap.ts:75`. Legacy stubs used June 2026, July 2026, Jan 7 2026 — parseDate() in `src/lib/feed.ts:78` invented June 1 or fell back to new Date() = today, masking errors. Sitemap emitted no lastmod at all. Fix: normalized all frontmatter to YYYY-MM-DD, made sitemap read frontmatter per slug via getPostLastModified(), and synced Blog.tsx:19 to ISO.

hawklist CMS — strict z.date() plus Astro sitemap at `src/content/config.ts:10` and `astro.config.mjs:15`. Sitemap used lastmod: new Date() for every page. Four compare pages had lastPricingCheck: 2026-08-02 — 23 days old, approaching the 30-day gate in config.ts:105. Fix: removed global lastmod, bumped stale lastPricingCheck and dateModified to 2026-08-24.

The worst classic mistake was the sitemap lie. Google docs warn: do not set lastmod to now. They learn to ignore your sitemap entirely, you lose priority signalling, and at scale it looks like scaled freshness manipulation.

How we fixed it in three small changes

1. Make sitemap honest. Every `lastmod` now equals a real page date. In Next.js that is `publishedTime` or `dateModified`; in Astro we removed the global `new Date()` and let the page’s frontmatter drive it. No build ever claims “everything changed today.” For the distinction between global and per-page lastmod, the sitemap protocol’s lastmod semantics and Astro’s sitemap integration are useful references.

2. Normalize frontmatter to YYYY-MM-DD. The lint rejects month-name dates like June 2026 and Jan 7 2026. For convfetti we mapped June 2026 to 2026-06-01 and Jan 7 2026 to 2026-01-07 once, so visible equals JSON-LD equals sitemap equals RSS.

3. Add a CI gate that blocks publish on date lies. Each repo now has `scripts/lint-dates.sh` run by the daily cron before `git push`:

• Rejects any future date
• Rejects bare `lastModified: new Date()` in sitemap
• For hawklist, fails if `lastPricingCheck` is over 30 days
• For mosh and convfetti, warns if JSON-LD and byline diverge

The daily job now exits 1 on lint fail, committing nothing. That is intentional — a wrong date should stop the ship, not silently publish.

For anyone tying dates to business logic, Baymard’s cart-abandonment checkout research is a reminder that the same “honest signals” principle matters for trust beyond SEO.

Should you hijack google spam policies as a topic

Yes — write about it, do not become it.

Hijacking the topic is legitimate newsjacking: the August 2026 update plus the fake-freshness self-assessment question are high-interest queries with clear search intent. To hijack them without triggering the very policy you are writing about:

• Show a real audit with tables, not a rewrite of Google docs
• Attribute every quote and stat, use named experts and methodologies
• Publish with correct dates yourself — visible, JSON-LD, sitemap, and RSS all aligned to today, no back-dating for authority

What you must not do is bulk `sed` dates forward without substantive rewrites. That is the textbook case of “scaled content abuse + scraping via automated transformation without value,” and it is exactly what the August update was built to demote.

We shipped our fixes with this post on the same day, not back-dated to 2025. The lint passes. Next time you see `lastModified: new Date()` in a starter template, fix it before you publish anything else.