News sitemaps: the two-day window, and what the archive stays out of

A news sitemap is a short rolling window over what you have just published, not a directory of your site. Google's news sitemap documentation, read in July 2026, states that you should only include URLs for articles created in the last 2 days, that a sitemap may hold up to 1,000 news entries, and that once articles pass 2 days old you either remove the URLs or strip their news metadata. Everything else you have ever published belongs in ordinary XML sitemaps, behind a sitemap index.

That framing matters because at publisher scale the thing that goes wrong is inclusion rather than omission. A newsroom with a decade of archive and a CMS that generates sitemaps from a query will eventually put a 2019 story into a file describing the last 2 days, and the file becomes less useful to a crawler than a smaller, honest one.

Three files, three jobs

One consequence for a large archive: the news file is the smallest and busiest artefact you publish, and the standard sitemaps are the largest and quietest. They should not be generated by the same job, on the same schedule, from the same query — the single most common cause of both being wrong at once.

The five ways the archive leaks into the window

• Republished timestamps. A story edited for a typo gets a new publication date, re-enters the window and displaces something genuinely new. Whether an edit justifies a new date is an editorial decision before it is a technical one — see what a correction owes the reader and an update does not.
• Non-article URLs. Tag pages, author pages, section indexes and paginated lists all have publication dates in some content models, so a query written as "recently published things" collects them.
• Scheduled stories that flip live twice. A story that publishes, unpublishes and republishes can appear with 2 different dates in the same window, which is a symptom of the scheduling problem covered in scheduled stories that go live late or twice.
• Syndicated duplicates. The same article under a partner URL or a second masthead, both eligible, both submitted, competing with each other.
• A prune that never runs. The most common of all: entries are appended on publish and removed by the same job, so a quiet Sunday leaves Friday's stories in a window that claims to hold 2 days.

Generate it as an event stream with a prune on a clock

1. Subscribe to publish events rather than polling the content store. The same event that invalidates caches drives the sitemap, which keeps them from disagreeing about what is live.
2. Append on publish. One entry per eligible article, written to a small store the generator owns, with the publication instant, the title and the language.
3. Filter at generation, not at insertion. Eligibility is a function of the clock, so it has to be evaluated when the file is rendered — a flag written at insert time is right once and wrong from then on.
4. Prune on a timer, independent of traffic and publishing volume, and treat the prune as the thing that keeps the promise the file makes.
5. Split before the cap, not after it. Above 1,000 entries the file has to become several, referenced from a sitemap index, and a newsroom that occasionally publishes 1,200 stories in a day should have that split working before the day it needs it.
6. Give the file its own cache key and a short time-to-live, and purge it in the same publish event that purges the story — the key-set discipline in surrogate keys and purging one story rather than the site applies to sitemaps exactly as it applies to pages.

The last step is the one missed on a decoupled stack. When the site is statically built, the sitemap is often produced at build time, so its clock is your deploy schedule rather than the newsroom's — a real problem on a quiet day and an invisible one on a busy day. Whether the file is rendered by the CMS, the front end, or a small service that does nothing else, is one of the practical differences between the options in headless or hybrid rendering for a news site.

A news sitemap makes one promise: everything in here is from the last two days. A file that breaks that promise is worse than no file.

Two boundaries worth naming. Search-engine rules change, so treat every number here as dated and verify it against current documentation before building to it — what lasts is the shape, a small fresh window plus a separate archive. And a sitemap is a discovery aid rather than a ranking mechanism, so if traffic has fallen it is rarely the cause and rarely the fix; that investigation is why search traffic fell after the replatform.

The generator is a small piece of software with one job, an obvious failure mode and a natural alert — the profile of work we build as internal tools and ops systems. How the story body is stored decides how cheaply it can tell a substantive rewrite from a typo fix, one more reason the block body versus markup blob decision reaches beyond rendering. The rest of this silo sits under CMS and publishing platform engineering, and our wider work for publishers is in the media and publishing practice.

• sitemaps
• SEO infrastructure
• publishing
• crawling