What Google News reads and what it drops
A news sitemap is an ordinary <urlset> with the news extension namespace added. Each <url> carries a <news:news> block with the publication name, publication language, publication date and headline.
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
xmlns:news="http://www.google.com/schemas/sitemap-news/0.9">
<url>
<loc>https://news.example.com/2026/08/rates-cut</loc>
<news:news>
<news:publication>
<news:name>The Example Times</news:name>
<news:language>en</news:language>
</news:publication>
<news:publication_date>2026-08-28T09:00:00+00:00</news:publication_date>
<news:title>Central bank cuts rates</news:title>
</news:news>
</url>
</urlset>
That is the whole vocabulary. The tool emits nothing else on purpose. No changefreq, no priority, no lastmod in the news entries, because Google News ignores all three. The <news:keywords>, <news:genres> and stock ticker tags that older guides still show were retired and do nothing now. Emitting dead markup makes the file bigger and gives you something extra to get wrong.
The 48-hour window changes how you publish
Google News only reads articles published in the last 2 days. An entry older than that is not merely ignored, it is noise in a file that is supposed to be a signal about what is new.
The practical consequence: this file has to be regenerated continuously, not on a content-edit hook. A news sitemap rebuilt once a day at 3am is stale by breakfast. Publishers who do this properly regenerate on every publish and drop entries as they cross the 48-hour line.
Feed the tool a publication date per article and it counts how many have already aged out, then tells you. If a large share of your list is stale, you are not maintaining a news sitemap, you are maintaining an archive with a news namespace on it.
Dates must be W3C datetime with a timezone. 2026-08-28T09:00:00+00:00 and 2026-08-28T09:00:00Z are both fine. A bare 2026-08-28 is accepted and expanded to midnight UTC, which will make an article look older than it is. Supply the full timestamp for anything published today.
pubName and pubLang are the 2 fields most often rejected
- Publication name must match the name registered for your publication in Google News, character for character. Not your domain, not your legal entity, not a shortened version. A mismatch here is why a technically valid file produces nothing. If you leave the field blank, the tool falls back to your Base URL hostname with
www.stripped, which is a placeholder, not an answer. - Publication language is an ISO 639-1 2-letter code.
en,fr,de,es. There are exactly 2 exceptions in the spec:zh-cnandzh-tw. Anything else with a region suffix,en-usoren-gbincluded, is not what this element expects. The field defaults toenand is lowercased for you.
Both values apply to every entry in the file. If you publish in 2 languages, that is 2 publications and 2 sitemaps.
One article per line, columns in any order
The format is url | Headline | publication date, but the parser identifies columns by shape rather than position. Whichever column parses as a date becomes the publication date; the remaining text column becomes the headline. Tabs work like pipes, so a 2- or 3-column CSV export pastes in directly.
https://news.example.com/2026/08/rates-cut | Central bank cuts rates | 2026-08-28T09:00:00Z
https://news.example.com/2026/08/election-recap | 2026-08-28T06:30:00Z | Election night, explained
https://news.example.com/2026/08/storm-warning
The third line demonstrates both fallbacks. With no date, the entry is stamped with the current time, which is a guess and should be replaced. With no headline, one is derived from the URL slug, so storm-warning becomes "Storm warning". The tool counts these and warns, because a derived headline is rarely the real one, and <news:title> should match the headline on the page.
Lines starting with # are skipped, duplicate URLs are removed, and every line that is not a parseable URL is listed back to you with the reason.
The 1,000-URL ceiling
A Google News sitemap is capped at 1,000 URLs, well below the 50,000 of a standard sitemap. In practice the 48-hour rule binds first: unless you publish more than a thousand articles every 2 days, you will never approach it.
If you do exceed it, the tool splits the output and generates a sitemap_index.xml. But hitting the cap is usually a sign that old articles are not being dropped. Fix the window before you reach for the index. Your archive belongs in the standard sitemap, which has no age restriction and a much larger ceiling.
This file supplements your regular sitemap
A news sitemap does not replace your standard XML sitemap, and submitting only the news file is a way to make everything older than 2 days invisible to normal discovery. Publish both:
sitemap.xmlcovering everything, regenerated when the URL set changes.news-sitemap.xmlcovering the last 48 hours, regenerated on every publish.
Reference both from robots.txt with 2 Sitemap: lines, and submit both in Search Console. Google retired the sitemap ping endpoint in 2023, so any publishing script still calling it is making a request that goes nowhere. For a news operation, that removes the last excuse for not keeping the file fresh at the source: nothing you can ping will speed up a file that is already stale.
Every URL in the file should be the article's canonical URL, returning 200, with no redirect hop and no paywall interstitial standing between the crawler and the text. BlazeHive automates SEO content production end to end, but a news feed is one place where your own publishing system has to own the timestamps.