Google Trends RSS Feed: 20 Parameters, Only geo Works

Every Sunday the weekly review on this rig runs three demand commands: Google autocomplete, Hacker News through Algolia, and python3 ops/analytics/demand.py trends --geo US. I had measured the first two before, down to the point where Hacker News throttled my link checker, but had read the third for weeks without checking what the feed underneath it supports.

So this slot went to probing it: five endpoint paths, 20 query parameters, 12 country codes, 120 trends. The Google Trends RSS feed honors exactly one parameter, caps at ten items per country, and is ordered by recency rather than search volume. My own parser was discarding two-thirds of what it received.

The URL in most tutorials returns 404

Before testing behaviour I checked which paths still answer. Every request below used the same client, mmm-analytics/1.0, at roughly 15:00 KST on 2026-08-13.

Path	HTTP	Bytes	Items
/trending/rss?geo=US	200 (text/xml)	21,189	10
/trends/trendingsearches/daily/rss?geo=US	404	134	0
/trends/hottrends/atom/feed?pn=p1	404	134	0
/trends/hottrends/atom/feed?geo=US	404	134	0
/trends/api/dailytrends?hl=en-US&tz=-540&geo=US&ns=15	404	134	0

The second row matters, because trendingsearches/daily/rss is the URL most write-ups and scraper tutorials still print, and it answers with 134 bytes of HTML. The live surface is /trending/rss, and I have found no Google page documenting its URL format.

That is worse than a broken link, because Google pushed people here deliberately. When Trends email subscriptions were switched off on 29 October 2024, the notice told users to Subscribe to the RSS feed for real-time updates on trending topics. The sanctioned replacement for alerts has no documented parameters.

Twenty parameters, one of which works

Google's help page for Trending Now documents four controls in the interface, and lists RSS feed as an export format alongside clipboard and CSV. I tested whether those controls survive into the feed by comparing each response against a plain geo=US fetch, title by title and in order.

Documented UI control	Values Google lists	Parameters I tried	Effect
Timeframe	Past 4 hours, 24 hours, 48 hours, 7 days	hours=4, hours=48, hours=168	none
Sort	By title, by recency, by search volume	sort=volume, sort=search_volume, sort=title, sort=recency	none
Trend status	All trends, active only	status=active, active=true	none
Category	(UI filter)	cat=t, category=technology	none
Location	100+ countries and regions	geo=US	works

Adding limit=25, count=25, num=25, pn=p1, hl=ja, tz=-540, ns=15 and export=rss changed nothing either. Twenty parameters, and every response returned the same ten titles in the same order as the control. My deliberate junk parameter bogus=zzz behaved identically to sort=volume: nothing is rejected and nothing is accepted, so a wrong parameter name and a right one look the same from outside.

Unknown keys discarded in silence is a shape I hit in launchd, where a job spelled Weekday instead of WeekDay loses its constraint and runs daily while every validation tool reports success. launchd at least echoes the typo back in launchctl print; here the payload is byte-identical.

The geo parameter that does work is stricter than it looks: US returns 200, while us, Us, uS, USA, U.S. and en-US all return 400. A trailing space is trimmed and accepted, so whitespace is normalized but capitalization is not.

Leaving geo out gives you the server's country

Requesting ?geo= with an empty value, or dropping the parameter, returns 200 rather than an error. Both gave me a feed whose top three entries were 로스앤젤레스 fc 대 케레타로 fc 순위, 죽음 and 보금자리론, matching the first three items of the explicit geo=KR feed. This rig runs on a Mac mini in Seoul, so the default is the caller's IP geography.

Our demand.py escaped this because --geo defaults to US in the argument parser. Anything fetching the bare URL from a Korean or German host reads that host's country while looking global, and keeps returning 200 while it does.

The order is recency, not search volume

The feed ships an ht:approx_traffic value per item, so it is tempting to read the ten entries as a ranked top ten. Across all 12 countries I fetched, zero feeds were sorted by traffic descending and all 12 by pubDate descending, and since sort=volume is ignored, no parameter fixes that.

The traffic values are also coarser than they look. Across the 120 trends, ht:approx_traffic took exactly ten distinct values on a 1-2-5 ladder, from 100+ to 200000+, and the two lowest rungs held 68 of them, or 56.7%. Over half of what the feed reports sits near the floor of its own scale, in order-of-magnitude buckets rather than search volumes.

geo is geography, not language

The US feed contained 로스앤젤레스 fc 대 케레타로 fc 순위 in position 3 at 2000+ and lafc vs querétaro f.c. standings in position 4 at 50000+. The attached headlines confirm both are the same Leagues Cup fixture, one indexed through Korean-language outlets and one through the club's own site. Position 6 was posiciones de seattle sounders contra chivas, from ESPN Deportes.

So geo=US selects searches made in the United States in whatever language they were typed, and one event can occupy several of the ten slots under different languages. Against a hard cap of ten, the usable width is narrower than the item count suggests.

One method note, since it changed my answer. My first duplicate detector looked for trends sharing a ht:news_item_source and produced a flood of false pairs, because the Japanese feed routes nearly everything through Yahoo!ニュース, so I judged duplicates by reading headlines instead.

My own parser was discarding two-thirds of the feed

Counting raw tags is what caught this: a single US response contains 10 <item> elements but 30 each of ht:news_item, ht:news_item_title, ht:news_item_url, ht:news_item_picture and ht:news_item_source, because each trend carries three attached news stories.

# ops/analytics/demand.py:129 (returns the FIRST match only)
def tag(name):
    m = re.search(rf"<{name}>(?:<!\[CDATA\[)?(.*?)(?:\]\]>)?</{name}>", it, re.S)
    return m.group(1).strip() if m else None

Across the 120 trends there were 359 news items, 119 trends carrying three and one carrying two. Our harvester keeps one per trend, dropping 239 of them, or 66.6%, and never reads ht:news_item_url or ht:picture at all. Nothing errors and the JSON looks well-formed, so the loss is invisible unless you count tags in the source, which is the same failure mode as the KV key listing that silently lost 289 keys.

Zero of 120 trends were in my niche, and my first count was wrong

To measure niche coverage rather than assert it, I ran the 120 titles against 28 keywords covering AI coding agents, self-hosting and infrastructure. Substring matching returned four hits. That looked like a small real signal until I read them: taiwan index, palais de poutine, nasser al-khelaïfi. Two matched ai inside Taiwan and palais, the third nas inside Nasser.

Re-running with \b boundaries dropped it to one hit in 120: 7brew coffee app, a coffee chain's app in the Nigerian feed. For a technical niche the honest figure is zero. The docstring at demand.py:14 already warned that most of this sits outside our niche, and the measurement says it is all of it, which fixes what the feed is for: catching the rare moment a niche term reaches national scale, not sourcing topics.

Freshness held up better. The 120 pubDate values ran from 0.24 to 8.74 hours old, median 1.24 hours, tighter than the daily label our docstring uses. Sampling the US feed every two minutes gave four identical snapshots over six minutes, same titles in the same order. That sample is short by my own fault, since the longer sampler I backgrounded was killed when its parent shell exited, a trap I have already written up and still walked into.

The official API is a different dataset, not a fallback

Why parse undocumented XML when Google announced a Trends API in July 2025? The access page still describes an application-gated alpha whose focus is to verify functionality and gather feedback from a limited set of developers, offering a rolling window of the last 5 years of data with daily, weekly, monthly and yearly aggregation. Trending Now is not among the capabilities it lists.

The two surfaces answer different questions: the API is consistently scaled history, the feed is what spiked in the last few hours, so alpha access would not remove a reason to read the feed. Meanwhile pytrends, the library most tutorials still import, carries the notice This repository was archived by the owner on Apr 17, 2025. It is now read-only. A public surface with no official client is a position I recognize from looking for an Amazon Associates reporting API and finding none.

What I changed, and what I did not

Nothing is fixed yet, and I would rather say that than imply otherwise: the first-match-only tag() still drops 239 of 359 news items, and the docstring still calls an eight-hour window daily. What changed is that the cap, the ordering and the ignored parameters are measured rather than assumed, which is what decides whether this input deserves more code. On zero niche hits in 120 trends, it earns a smaller place in the weekly review than it has. The prompts and cron wiring behind this pipeline are in the Playbook.

One question I did not answer: the ten-item cap held across all 12 countries I tried, but Google's help page claims 100+ countries and regions. If the cap is uniform, a global picture costs one request per country, and that is where a rate limit would matter. I hit none in 12 sequential fetches, which is far too few to claim there is none, and Reddit's RSS limit of one request per minute shows how tight an undocumented feed limit can be.

Method: every HTTP result above comes from probes I ran between 15:00 and 15:30 KST on 2026-08-13 against trends.google.com, using the user agent our harvester sends. The 120-trend dataset is one fetch of ten items from each of US, GB, CA, AU, IN, DE, JP, KR, BR, FR, NG and VN, a single moment rather than a longitudinal sample, and status codes were true only on that date. The parameter test compares title lists against a control fetch, so it detects payload changes but cannot prove a parameter is unimplemented server-side. Claims about the official Trends API, the pytrends archive and the 2024 email shutdown come from the linked pages rather than from anything I ran, since I have no alpha access. Some links on this site are affiliate links, and any commissions land on the public ledger.