Google News RSS: the missing reference

Google publishes these feeds and documents almost none of it. Everything below was tested against the live feed on 18 September 2026, and where something does not work, that is written down too.

The four endpoints

All of them live under https://news.google.com/rss and all return plain RSS 2.0. No key, no account, no rate limit published.

The topic slugs are the ones Google uses in its own navigation, in capitals: WORLD, NATION, BUSINESS, TECHNOLOGY, ENTERTAINMENT, SPORTS, SCIENCE, HEALTH. The geo slug is a plain place name.

Counts vary with the subject and the hour — the numbers above are one measured run. Search never returned more than about 101 items however the query was shaped, and there is no pagination parameter. That ceiling is the first thing to design around.

Language and country

Three parameters control which edition of Google News answers you. They are not interchangeable and getting them inconsistent gives you a mix.

The sixteen editions we run against in production, with the exact values:

Note es-419 and pt-419 — those are the Latin American editions, and they are what Google actually serves for Spanish and Brazilian Portuguese. Using es-ES or pt-PT gets you a different, thinner edition.

Query operators that work

The q parameter takes Google search syntax. Every one of these was run against the live feed; the counts are from that run.

when: takes 1h, 12h, 1d, 7d, 30d, 1y and so on. It cannot be combined with after:/before: — one or the other.

The date filter is honoured exactly, which is worth knowing because plenty of search endpoints quietly ignore it. We asked for June 2008 and checked every pubDate that came back: 100 of 100 fell inside 1–30 June 2008. Same for 2012 and 2020.

What an item contains — and what it does not

This is the part that decides whether the feed is enough for you.

There is no article body. No content:encoded, which is the RSS element that would normally carry one. description holds the headline again wrapped in an anchor tag, not a summary — if you strip the HTML you get the title back.

There is also no author, no section, and no image. If your plan was to build a reading app or feed a model from this alone, that is the plan changing shape.

How far back it goes

Much further than anyone writes down. We ran two unrelated subjects per year and checked the dates that came back:

The oldest article that came back in this run was dated 23 August 1995. The feed does not stop at ten years, or at 2010, or anywhere anyone has documented.

What does fall away is the articles themselves. The links keep resolving — 16 of 16 at every depth, including 1995 — but by the 1990s only about a quarter of those pages still exist to be read. Around 2006 it is 94%. The archive is real; its readability is a curve.

The three walls

This is where a weekend project stops, and there is no shame in it — these took us months.

1. The link does not go where you think

Every <link> in the feed looks like this:

https://news.google.com/rss/articles/CBMijwFBVV95cUxQN2dfdmhzcDU5UHk1OXp...

That is not the publisher's URL and it is not a redirect you can follow with curl -L. It is an opaque identifier that Google's own front end exchanges for the real address through an internal RPC. Fetch it directly and you get a page of JavaScript, not a Location header.

The exchange is doable — it needs a signature scraped from the article page and a batched call to Google's batchexecute endpoint, with the request body shaped exactly right. We run it in production: 636 of 646 articles resolved across sixteen years, and 16 of 16 even on 1995 articles. Getting the body shape wrong is the most common way to get nothing back, and it fails silently.

2. There is no article text, and getting it is not a fetch

Once you have the publisher's URL you still have to extract readable text from a news page, which is mostly navigation, consent banners and scripts. Naive approaches — concatenating every <p>, checking the length — pass their own tests while returning menus and CSS. Ours did, on 821KB of CNN JavaScript, and every length check we wrote said it was fine.

Then publishers refuse you. Measured across 636 articles, 77% gave up clean text — and that number moves from 40% to 100% depending on the subject. Technology and housing stories sit near the top; central-bank and climate coverage near the bottom, because that is where the paywalls are.

Some refuse every time, and it is worth naming them: reuters.com answers 401 — it wants a subscription, and no amount of clever routing changes that. nytimes.com answers 403 to nearly everything. finance.yahoo.com refuses the connection outright. We verified the block is on the address rather than the request: the same 80 URLs fetched bare and with full Chrome headers produced identical rejection counts, 27 each time.

3. One story, many times

Measured over 160 articles: 18% of a result set is a story already in it, almost all syndication. On one search, "Prediction: Tesla Stock Will Be Worth This Much in 2031" came back from The Motley Fool, Yahoo Finance and AOL.ca, character for character.

If you are feeding a model, that is worse than waste — the same claim three times makes it more confident, not better informed. Title-token overlap catches it without any model at all, but pick the threshold carefully: a loose one merged three different Sky Sports pages about three different clubs, because their titles share boilerplate.

So: is it worth doing yourself?

Often, yes. If you want headlines on one subject, in one language, and you can live with roughly 100 results and no article text, the feed is free, honest and about ten lines of code. Do that.

It stops being worth it at a fairly specific point: when you need the publisher's real URL, or the article text, or more than one language, or results you can trust not to be three copies of one story. Each of those is a separate problem, none of them is a weekend, and the third one has a residential-proxy bill attached.

Start free Read the API reference See the measurements