Google Trends Scraper — Interest, Regions & Related Queries

Google Trends data that actually comes back.

Pull interest over time, interest by region, and top + rising related queries for any keyword, any country, any time range — as clean tabular rows ready for a spreadsheet, a dashboard, or an LLM pipeline.

---

Why this one

Most Google Trends scrapers drive a headless browser and read the page. Google changes the page, the selectors break, and the run either returns nothing or spins until it times out — while you get billed for it anyway.

This actor takes a different path:

	This actor	Typical browser-based scraper
How it gets data	Google's own JSON endpoints	Headless browser + DOM selectors
Breaks when Google restyles the page	No	Yes
Memory	1 GB	4 GB
Rate limits (HTTP 429)	Fresh proxy session per retry and a re-established cookie session on every rotation — the part that actually clears a 429	Usually just fails
When something goes wrong	Tells you which — bad input, rate limit, or genuinely no data	"Run failed"
What you pay for	Only rows actually delivered	Often a start fee regardless of output

If a run returns nothing, it costs you nothing. There is no actor-start charge. Every row you are billed for is a row in your dataset.

---

What you get

Every example below is a real, unedited row from this run:

{ "searchTerms": ["bitcoin"], "dataTypes": ["TIMESERIES", "GEO_MAP", "RELATED_QUERIES"],
  "timeRange": "today 3-m", "geo": "US" }

→ 194 rows in 33 seconds: 93 interest-over-time + 51 regions + 50 related queries.

Interest over time

{
  "recordType": "interest_over_time",
  "searchTerm": "bitcoin",
  "date": "Jul 10, 2026",
  "dateShort": "Jul 10",
  "timestamp": "2026-07-10T00:00:00.000Z",
  "value": 51,
  "isPartial": false,
  "geo": "US",
  "timeRange": "today 3-m",
  "category": 0,
  "scrapedAt": "2026-08-25T19:11:17.879Z"
}

Always sort on timestamp, never on date — date is Google's display string and its shape follows the time range ("Jul 10, 2026" for a daily bucket, "Aug 24 – 30, 2025" for a weekly one). timestamp is ISO-8601 and always parses.

Interest by region

{
  "recordType": "interest_by_region",
  "searchTerm": "bitcoin",
  "region": "Wyoming",
  "geoCode": "US-WY",
  "value": 100,
  "maxValueIndex": 0,
  "hasData": true,
  "geo": "US",
  "timeRange": "today 3-m",
  "category": 0,
  "scrapedAt": "2026-08-25T19:11:17.879Z"
}

geoCode is a real ISO sub-region code, so these rows join straight onto a choropleth or a US-XX lookup table without string-matching region names.

Related queries — top

{
  "recordType": "related_query",
  "searchTerm": "bitcoin",
  "rankType": "TOP",
  "query": "bitcoin price",
  "value": 100,
  "formattedValue": "100",
  "link": "https://trends.google.com/trends/explore?q=bitcoin+price&date=today+3-m&geo=US",
  "geo": "US",
  "timeRange": "today 3-m",
  "category": 0,
  "scrapedAt": "2026-08-25T19:11:17.879Z"
}

Related queries — rising

{
  "recordType": "related_query",
  "searchTerm": "bitcoin",
  "rankType": "RISING",
  "query": "spcx stock",
  "value": 49200,
  "formattedValue": "Breakout",
  "link": "https://trends.google.com/trends/explore?q=spcx+stock&date=today+3-m&geo=US",
  "geo": "US",
  "timeRange": "today 3-m",
  "category": 0,
  "scrapedAt": "2026-08-25T19:11:17.879Z"
}

You get 25 TOP + 25 RISING per term. TOP is a 0–100 popularity score; RISING is percentage growth, where value is the raw number behind formattedValue (2900 → "+2,900%"). Google prints "Breakout" instead of a number for the extreme ones — but value is still populated (49200 above), so you can sort and threshold rising queries numerically instead of parsing strings.

---

Input

Field	Type	Notes
searchTerms	array	Required. One or more keywords.
dataTypes	array	TIMESERIES, GEO_MAP, RELATED_QUERIES. Fewer types = fewer rows = lower cost.
timeRange	string	now 1-H … today 5-y, all. Default today 12-m.
customTimeRange	string	YYYY-MM-DD YYYY-MM-DD. Overrides timeRange.
geo	string	US, GB, DE, a sub-region like US-CA or GB-ENG, or a plain country name like Germany. Case-insensitive — usa, UK and United States are all understood. Empty = worldwide.
compareTerms	boolean	ON = one request, values relative across terms (Google's comparison mode). OFF = each term on its own 0–100 scale.
category	integer	Google Trends category id. 0 = all.
maxItems	integer	Hard cap on delivered rows — your spend ceiling. 0 = no limit.
proxyConfiguration	object	Residential strongly recommended.

Example

{
  "searchTerms": ["bitcoin"],
  "dataTypes": ["TIMESERIES", "RELATED_QUERIES"],
  "timeRange": "today 12-m",
  "geo": "US"
}

What a run costs

You are billed per delivered row, so the row count is the price. Measured counts for one term:

dataTypes	timeRange	Rows per term	Cost per term
TIMESERIES	today 12-m	53	$0.16
TIMESERIES	today 3-m	93	$0.28
GEO_MAP (US)	any	51	$0.15
RELATED_QUERIES	any	50 (25 top + 25 rising)	$0.15
All three	today 3-m	194	$0.58

With compareTerms: false each term is its own request, so N terms costs about N × the above — three terms with all three types on today 3-m lands near 580 rows (~$1.75). Two levers keep that predictable:

• maxItems is a hard ceiling on delivered rows and therefore your spend cap. Set it.
• Drop GEO_MAP if you only care about trend direction — it is a quarter of the rows.

---

Understanding the numbers

Google Trends values are relative, not absolute search counts. Within a single request, 100 is the peak point and everything else is scaled against it. That means:

• Values for a term scraped alone are not comparable to the same term scraped in a comparison group. Use compareTerms: true when you need terms on one shared scale.
• isPartial: true marks a period that has not finished collecting yet — the last data point is usually partial and will rise. Exclude it from trend calculations.

---

Honest limitations

• Related topics are not available. Google's endpoint returns an empty list for every term we tested, so this actor does not offer that option rather than quietly charging you for nothing. Related queries work fine and are usually what people want.
• Google rate-limits aggressively. On a 429 the actor rotates to a fresh proxy session and re-establishes the cookie session before retrying — a fresh IP alone gets blocked again, which is the trap most Trends scrapers fall into. Large jobs still run faster and cleaner with residential proxies enabled. If everything is blocked, the run fails and bills nothing.
• A term with no data is a successful run, not a failed one. If Google has no chartable volume for your keyword, you get an empty dataset and a status message saying so — not a failure. Scheduled jobs will not page you because a keyword went quiet, and you are not charged.
• Hourly ranges (now 1-H, now 4-H) return far fewer points than daily ranges — that is Google's granularity, not a truncation.
• Google is rolling out an official Trends API (currently a closed alpha). If and when it opens, this actor will move to it.

---

Use it for

• SEO & content — find rising queries before they peak.
• Market research — compare brand or product interest across regions.
• Finance & crypto — retail attention as a sentiment input.
• Journalism & academia — reproducible search-interest series with real timestamps.
• LLM pipelines — flat rows, no HTML, no post-processing.

---

Scheduling

Point the Apify Scheduler at this actor to build your own history: run daily with timeRange: "now 7-d" and append to a dataset. Because you are only charged per delivered row, a scheduled watch on a handful of terms stays cheap.