How to scrape Google Trends, and why a Google Trends scraper hits 429

The requests behind the explore page

Open a Google Trends chart in a fresh browser profile and watch the network tab. The page first gets a visitor cookie, then asks one endpoint for its widgets, then fetches each widget's data with the token that came with it:

HEAD https://trends.google.com/trends/?geo=US&hl=en-US
     -> Set-Cookie: NID=...          the only cookie a logged-out visitor gets

GET  /trends/api/explore?hl=en-US&tz=0&req={"comparisonItem":[
       {"keyword":"coffee","geo":"US","time":"today 12-m"},
       {"keyword":"tea","geo":"US","time":"today 12-m"}],
       "category":0,"property":""}
     -> the page's widgets, each with its own request object and token:
        TIMESERIES, GEO_MAP, then per term GEO_MAP_i, RELATED_QUERIES_i, RELATED_TOPICS_i

GET  /trends/api/widgetdata/multiline?req=<TIMESERIES request>&token=<token>
GET  /trends/api/widgetdata/comparedgeo?req=<GEO_MAP request>&token=<token>
GET  /trends/api/widgetdata/relatedsearches?req=<RELATED_QUERIES_i request>&token=<token>

Each answer starts with a short anti-hijacking prefix ()]}') before the JSON. A single term gives four widgets; a comparison of up to five terms gives the shared timeline, the compared regional breakdown in percent, and regions, related queries and related topics for each term. Category, search type (web, images, news, YouTube, Shopping), time zone and language go in the same parameters.

Google's robots.txt for trends.google.com disallows /trends/explore? and /explore?, the HTML page, and nothing under /trends/api/. A scraper never needs the HTML page; a link to it in each row lets a person check a number by eye.

Trending now: one call, the whole list

The Trending now page (trends.google.com/trending) loads its list from one batchexecute call, with the country, the language and the window as arguments:

POST /_/TrendsUi/data/batchexecute?rpcids=i0OFE&hl=en-US
     f.req=[[["i0OFE","[null,null,\"US\",0,\"en-US\",24,1]",null,"generic"]]]
                                  geo   language hours (4, 24, 48 or 168)

It answers without any cookie. On 2026-10-05 it returned 446 searches for the United States over 24 hours and 1,993 over 7 days; on 2026-10-13, 467 over 24 hours. Each item carries the search, its start and end time, Google's volume bucket, the increase, category IDs and the trend breakdown. The public RSS feed lists 10, and the old dailytrends endpoint now answers 404. There is no worldwide list: Google publishes it per country or region, and the page's category filter runs in the browser, so a scraper filters the same way.

The 429 wall

Three lessons. The cookie is required but is not the limit: without it the explore request is refused at once, with it the limit is the IP. A refused IP stays refused for over an hour, so waiting it out is not a strategy for a batch. And dressing up as a browser does not help: three A/B rounds of 20 queries drew 15, 19 and 36 HTTP 429 with our own User-Agent, against 15, 78 and 54 with Chrome's. We kept ours.

Sessions, and the residential fallback

What works is many IPs, each used like a visitor. Our Actor runs eight workers in parallel; each holds one session, an Apify datacenter IP and its own visitor cookie, and sends one request at a time, at least 250 ms apart. When Google answers 429, that session is dropped and the request leaves again from a new IP, after a short wait: a new IP needs no long one. When a worker fails twice in a row, its next 30 requests go through residential IPs. A query that still comes back partial is read once more from fresh sessions, and the better answer is kept.

Two of those rules came from measurements. Capping the retry wait at 4 seconds: with a 20-second cap, one query once waited 150 seconds through the backoff ladder. And pushing Trending now rows in one batch per list: one at a time, 448 rows took 25 seconds and 5,581 rows took 323 seconds; batched, 1.3 and 4.4 seconds.

The result over three passes of the same 33 inputs (single terms in every time range, comparisons of 2 and 5 terms, regions, metros, cities, categories, the five search types, batches of 30, 100 and 200 terms, Trending now in one and five countries): 109 of 110 runs succeeded, the one failure an empty input refused on purpose, and 0 of 1,297 explore queries failed. The 429s never went away (691 in 2,962 requests on the last pass); they just stopped costing results.

What a logged-out visitor cannot get

• Related topics. Every logged-out answer we saw is tagged USER_TYPE_SCRAPER, even from headful Chrome, and its related-topics list is empty, while a signed-in browser sees topics for the same query. Related queries, interest over time and by region came back the same. Signing in is where reading public data turns into using an account, and we do not.
• Some cities. "bier" in Germany over 12 months gave no city to a logged-out client and two (Bamberg, Zwickau) to a signed-in browser. US metro areas did answer: 210 rows for "snow".
• Exact repeatability, for anyone. Google Trends is computed on a sample. The same comparison, coffee and tea in the US over 12 months, read logged out at 14:15 and 14:34 UTC on 2026-10-13, gave averages of 78 and 37, then 79 and 38; a signed-in browser in between showed 78 and 37. Two loads of that page in the signed-in browser listed different rising queries first. Expect a point of drift between reads.
• Clean rising lists. Google's own rising queries for coffee included "home workout routines" and "sports scores today", logged out and signed in alike. A scraper should return them as listed rather than guess which are noise.

What it costs in the cloud

Measured on Apify with our Actor: each run's total usage, compute, proxy and storage included.

Google's pressure, not the input, sets the bill: the same 100 terms cost $0.020 to $0.25 per 1,000 queries depending on how many 429s came back, and $0.42 per 1,000 in the worst case we measured, when residential IPs took over. The two three-query runs of 2026-10-13 are the same input nineteen minutes apart. Trending now is cheap in every case: one request per list.

Or skip the plumbing

Our Google Trends scraper does all of the above in one run: up to 2,000 terms, comparisons or Google Trends links, every time range and search type, regions down to US metros and cities, related queries, Trending now for any country, sessions and the residential fallback, and a status on every query. It costs $1.50 per 1,000 queries with data, platform usage included, and a query without data is free; the most used Google Trends Actor on Apify lists $3.00 per 1,000 on its free tier plus platform usage.

Questions

Aggregated, anonymized search interest only: no personal data, no login, no account. Not affiliated with Google.