Google Trends Scraper — compare keywords on one scale

Google Trends numbers are relative. A term's 100 is only its own maximum, so two terms fetched separately both peak at 100 and comparing them says nothing. The only way to compare is to put the terms in one request, where Google normalises them against each other.

Measured on air fryer / instant pot / slow cooker, past 12 months, US:

Keyword	One request (shared scale)	Fetched separately
air fryer	average 64.4	64.4
instant pot	average 20.6	47.8
slow cooker	average 13.7	64.7

air fryer is about 5× slow cooker. Scraped separately, they look identical.

This Actor sends your keywords together, and every output row carries sharedScale and comparedWith so you always know whether two numbers may be divided by each other. Past Google's own five-per-request ceiling it keeps one scale by anchoring, up to 100 keywords — see Compare more than 5 keywords.

Use this when

• You are comparing two or more search terms and the numbers have to be comparable with each other — not two charts that each peak at 100.
• You want to know which term is gaining on the others, not just which is bigger. recentChangeVsGroup answers that, and it is the one reading that cannot be assembled from separately scraped series.
• You are comparing more than five terms. Google answers five per request, so past five most Trends scrapers either stop or return a separate 100 per group of five.
• You need the cost known before the call: $0.002 per keyword, no start fee. A keyword with no search volume, an unusable keyword, a request that failed and the extra requests spent joining scales are all free.
• You are an agent and the result has to fit in a context window. One row per keyword, ranked most-searched first, and includeTimeline: false puts 100 keywords in about 64 KB. The common shape elsewhere is one row per data point — 100 keywords over a year is 5,200 rows, usually billed per row, and the first thing you read is week 1 of whichever keyword came back first.

Don't use this when

• You want daily trending searches — "what is trending right now". This Actor only answers about terms you name.
• You want absolute search volumes. Google publishes none, here or anywhere; every number is relative to the other terms in the comparison.
• You are checking one keyword and not comparing it to anything. Any Trends scraper will do, and nothing on this page buys you something.

What you can compare

• Compare keywords against each other over 12 months, 5 years, or any custom window.
• Brand vs competitor search: put a brand and its rivals in one request and the comparison turns "we are at 30, they are at 80" into a real ratio, rather than two unrelated charts.
• Seasonal keyword demand: compare when each term peaks across 5 years of weekly data — which one arrives first, and by how much.
• Compare regional search interest — with several keywords, the per-region breakdown comes back on the same shared scale, so you can see where one term beats another, not just where each is searched.
• Compare search volume trends without Google Ads: Trends gives relative interest, and a comparison on one scale is what makes those relative numbers usable.

Compare more than 5 keywords on one scale

Google answers at most five keywords per request. Five is therefore where most Trends scrapers stop, or they hand back several groups of five with a separate 100 in each — numbers that cannot be divided by one another.

Up to 100 keywords go on one 0–100 scale here, by anchoring. A keyword that appears in two requests has a known value in both, and the ratio between those two values converts one request's scale into the other's. Keywords go out in groups of five; the largest keyword of each group becomes that group's anchor; the anchors are then fetched together — recursively, when there are more than five of them — and one ratio per group lands everything on a single scale, renormalised so the biggest keyword is 100, exactly as Google would have returned it had it accepted all of them at once.

There is no anchor keyword to choose. The anchor is picked per group, and deliberately the largest keyword in it: an anchor that is small where two scales meet rounds towards zero there, and that one rounding error would be multiplied into every keyword of its group.

Each row reports what it cost:

Field	Meaning
scaleGroup	The keywords that shared this row's request. Region and related-query data are produced by Google relative to these, not to the whole comparison
scaleAnchor	The keyword that joined this row's request to the shared scale; null when one request covered everything
scaleConfidence	exact when no joining was needed, then high / medium / low by how large the anchor was where the scales met

Joined values are fractional (0.8, not 1), so a keyword a hundredth of the leader's size stays visible instead of rounding to zero. Joining costs about one extra request per five keywords, and those requests are never billed — they carry no keyword of their own.

Quick start

{ "keywords": ["air fryer", "instant pot", "slow cooker"], "geo": "US", "timeRange": "today 12-m" }

One row per keyword, with the full weekly timeline, the average, the latest complete bucket, the peak and its date, how the recent quarter compares with the one before it, and a link that opens Google's own page for the same request so you can check the numbers against the source.

Rows come back most-searched first. The dataset is ordered by averageValue and numbered with rank, so reading the first row — or the first page — gives you the answer rather than whichever group of five Google happened to return first.

Field	Meaning
rank	Position by averageValue among the rows on this scale, 1 being the most searched. null when the row has no shared scale to be ranked on; a keyword with no volume is ranked last and flagged with noData
latestValue	The most recent complete bucket. Google leaves the final bucket of a period still filling, and it reads low — reporting it would invent a drop that has not happened
recentChangePercent	The last quarter of the series against the quarter before it. Seasonality is in this number and it is not a trend — on a 12-month window every term past its annual peak reads negative. No row claims to be "rising" or "falling", because one year of data cannot tell season from trend. To separate them, use today 5-y and compare the same weeks a year apart; or read it against the other keywords, since all of them falling together is the season and one holding while the rest fall is the signal
recentChangeVsGroup	The same number measured against the median of the comparison, in percentage points. This is where seasonality cancels: a season moves the whole category, so what survives the subtraction is the part that is about this term. Six kitchen appliances in October were all down, median -32 — and slow cooker came out +34 against it, which is the only reading of those six series worth acting on. Needs at least three keywords on one scale, and needs the shared scale to exist at all
trendsUrl	Google Trends' own page for exactly this row's request. It carries the row's scaleGroup, never the whole comparison, because Google charts five terms at a time and a longer link would not open to anything checkable

Input

Field	Type	Notes
keywords	string[]	Up to 100, all on one shared scale
compare	boolean	Default true: the keyword comparison lands on one scale, anchoring across requests when there are more than five. False fetches each term alone — each then peaks at its own 100, correct for unrelated terms and wrong if you then compare them
geo	string	US, GB, DE… empty for worldwide
timeRange	string	Default today 12-m, the same default as Google Trends
category	integer	Google Trends category id, 0 for all
includeRegion	boolean	Adds the per-region breakdown (one extra request per keyword)
includeRelated	boolean	Adds top and rising related queries
includeTimeline	boolean	Default true. Turning it off keeps every derived number but drops the week-by-week series, which is ~4.5 KB a keyword — a 100-keyword run goes from roughly 1 MB to under 100 KB. Worth it when the comparison is the answer and an agent has to read the dataset into a context window
maxConcurrency	integer	1–4, default 1 — parallel requests share one address, so a rate limit takes all of them at once

Output

{
  "keyword": "air fryer",
  "rank": 1,
  "sharedScale": true,
  "comparedWith": ["air fryer", "instant pot", "slow cooker"],
  "scaleGroup": ["air fryer", "instant pot", "slow cooker"],
  "scaleAnchor": null,
  "scaleConfidence": "exact",
  "averageValue": 64.4,
  "latestValue": 60,
  "recentChangePercent": -17.3,
  "recentChangeVsGroup": 14.9,
  "peakValue": 100,
  "peakDate": "2026-01-04",
  "trendsUrl": "https://trends.google.com/trends/explore?q=air+fryer%2Cinstant+pot%2Cslow+cooker&date=today+12-m&geo=US",
  "timeline": [{ "date": "2025-10-05", "label": "Oct 5 – 11, 2025", "value": 64, "partial": false }],
  "noData": false,
  "billable": true
}

Billing

One event per keyword that came back with data. Not charged: keywords Google has no volume for (noData: true), keywords rejected as unusable, and keywords whose request failed.

When a comparison is meaningless

Two numbers may only be divided by each other when they came from the same request. The output says so on every row:

Field	Meaning
sharedScale	true when this keyword's value may be divided by the other rows'
comparedWith	The exact set of keywords sharing this row's 0–100 scale
scaleConfidence	How much of that scale was measured directly and how much was anchored

If you scrape terms one at a time — with compare: false, or across separate runs — each keyword's 100 is its own maximum and comparing them says nothing about which is bigger. That is a property of Google Trends itself, not of this Actor; the difference is that here it is labelled.

Limits worth knowing

• A comparison of 100 keywords is about 25 requests before region or related data, which is why that is the ceiling: beyond it a run is likelier to be cut off by a rate limit than to finish.
• Google Trends limits each address by total volume, not just by rate: measured, 60 requests at 2/s drew nothing, but roughly 80 from one address did — and the block then lasted over 20 hours, not minutes. Leave Apify Proxy on (the default) so the run rotates addresses instead of spending one for a day.
• An address is retired at 30 requests, before Google has to say no — tripping a limit leaves that address unusable for hours, so the run steps aside early rather than discovering the ceiling.
• A rate-limited comparison is retried as a whole, from the request that mints the widget tokens: those tokens belong to the address that asked for them, so replaying just the refused call on a fresh address cannot work. One retry per group of keywords, and only for a rate limit.
• A blocked address is retired, not retried — the run warms up a fresh one and carries on. After three blocks in a row it pauses for a minute rather than burning through more. Whatever was already fetched is in the dataset; nothing partial is charged.
• Requests are spread over a 0.3–1.2s window rather than emitted on a fixed interval.
• Values are relative, never absolute search counts. Google publishes no absolute volumes.
• The last bucket of a period is usually partial: true — it is still filling.