Google Trends Scraper: Interest, Related Queries, Spikes

Pull Google Trends' own data for any keyword — the same numbers the /trends/explore page shows — straight from its JSON API. No login, no headless browser.

What you get

Real rows from the example dataset (keywords: ["python"], timeframe: "today 3-m"):

type	keyword	date / query	value	kind
interest_over_time	python	2026-06-26	78	—
interest_over_time	python	2026-09-26 (isPartial)	32	—
related_query	python	"python code"	100	top
related_query	python	"singapore reticulated python sighting"	7800 (Google calls this a "Breakout")	rising

Full row: id, url, type (interest_over_time | related_query | related_topic), keyword, geo, timeframe, date, value, isPartial, isSpike, rank, query, kind (top | rising), scrapedAt.

Use cases

• Content and SEO planning — pull today 12-m for a shortlist of topics and see which one is trending up before you commit a content calendar to it.
• Rising-query discovery — the related_query rows with kind: "rising" surface breakout queries around your seed keyword days before they show up in generic keyword tools.
• Spike monitoring — put a watchlist of keywords into monitor mode; get an alert the day search interest jumps (isSpike: true) or a brand-new rising related query appears.

Try it in 10 seconds

Hit Start/Try it — the input already works: keywords: ["python"], timeframe: "today 3-m", maxItems: 20.

Monitor mode — save the task, then set:

{
  "mode": "monitor",
  "monitorStateId": "my-watchlist",
  "keywords": ["python", "typescript"],
  "spikeThreshold": 2.0,
  "webhookUrl": "https://your-endpoint.example.com/hook"
}

and put it on a schedule (Apify → Schedules). Each monitor run charges one monitor-check event; only new or changed rows (a new day's point, a value change, a brand-new related query) are billed as change events.

Related actors

• Google News Scraper (search, headlines, alerts, no login) — see the actual headlines behind a spike in search interest.
• Reddit Scraper (subreddit posts, search, comments, no login) — community discussion signal to compare against search-interest spikes.
• Google Ads Transparency Scraper (advertiser, domain, alerts) — see who is buying ads around a rising topic.
• Yahoo Finance Scraper (quotes, key stats, history, alerts) — pair search-interest spikes with the underlying stock or ticker data.

How it works

1. Explore — up to 5 keywords per call go to Google Trends' own trends/api/explore endpoint (the same call the /trends/explore page makes), which returns a token per widget (interest-over-time chart, related queries, related topics).
2. Widget data — each token is exchanged for its data at widgetdata/multiline (interest over time) and widgetdata/relatedsearches (related queries/topics).
3. A warm-up request seeds a session cookie first; without it Google's explore endpoint answers the very first call of a session with a 429 regardless of keyword.
4. Spike flag — the latest interest-over-time point gets isSpike: true when its value is at least spikeThreshold (default 2.0) times the median of the trailing 30 points.

Input

Field	Meaning	Default
keywords	Keywords to track, up to 5 compared together per batch (more are split into batches automatically)	[]
geo	Region code, e.g. US, US-CA — empty for worldwide	"" (worldwide)
timeframe	Google Trends timeframe string, e.g. today 3-m, today 12-m, 2024-01-01 2024-06-01	"today 3-m"
includeRelated	Also fetch related queries and related topics per keyword	true
spikeThreshold	Latest value must be at least this many times the trailing 30-point median to flag isSpike	2.0
maxItems	Stop after this many rows	500
mode	scrape or monitor (only new/changed since last run)	scrape
monitorStateId, webhookUrl, telegramBotToken, telegramChatId	Monitor-mode state key and alert targets	empty

Pricing

Event	Price
result	$0.001 per row ($1 per 1,000)
monitor-check	$0.005 per monitor run
change	$0.001 per new/changed row

Charged only for rows actually pushed. An interest-over-time timeframe of today 3-m returns roughly 93 daily rows per keyword plus up to ~45 related-query rows when includeRelated is on.

Found it useful? A short review on the Store page helps other people find this actor and tells us what to improve. If a spike or interest score looks wrong, open an issue on the actor page — issues are answered within a day.

Why this actor

• Reads Google Trends' own API directly — the same numbers the site itself shows, not a scrape of rendered HTML.
• One row schema for interest-over-time, related queries and related topics, so a single dataset covers the whole picture for a keyword.
• Spike detection and a monitor mode built in — no separate script needed to notice when a term breaks out.
• A run that finds nothing pushes nothing and charges no result events; the run summary explains why instead of leaving you guessing.

Limits

• Up to 5 keywords are compared per batch (Google Trends' own limit for the interest-over-time chart); more keywords are split into sequential batches, one explore call each.
• Related topics (related_topic rows) come back empty for every keyword tried during development — Google's backend answers rankedList: [] on the none proxy tier for this widget right now. Related queries (related_query) are unaffected. The parser is ready for topic data the day it returns.
• value for interest-over-time is Google's own 0-100 relative score, not an absolute search count; for related queries it is 0-100 relative to the top query, or a large number (Google's UI labels these "Breakout" instead of showing the number) for a rising query with too little prior volume to compute a normal percentage.
• No person-level data of any kind — this actor never touches per-searcher data; Google Trends does not expose it.

FAQ

Does it need a Google account or cookies? No. The actor makes its own warm-up request internally; there is no login field.

What happens when a keyword has (almost) no search volume? It still returns rows — Google Trends' own near-zero score — rather than nothing. That is the real answer, not a block; the run summary only reports a block when the source itself refuses every request.

What does monitor mode actually save me? It keeps state per monitorStateId (or per saved task) across runs, so a schedule returns only the days/queries that are new or changed instead of the whole series again — you pay one monitor-check plus one change event per new/changed row, not a full result for every row every time.

Changelog

• 0.1: initial release — interest over time, related queries/topics, spike flag, monitor mode.

---

If this actor saved you time, a short review on its Store page genuinely helps other people find it. Found a bug or need a field that is missing? Open a ticket on the Issues tab.