The Google Trends live leaderboard updates on a rolling schedule. Polling it through get_top_trends returns ranked query strings, an as_of_ts freshness stamp, and pagination controls. This page covers poll intervals, request budgeting, snapshot diffing, and when to escalate a spotted term to historical growth checks.
The Google Trends website shows a ranked list of queries gaining traction right now. The same leaderboard is available programmatically through get_top_trends with type set to Google Trends. Unlike keyword history calls, this mode needs no keyword argument. One request returns the current board.
For the broader Google Search integration and MCP setup, see Google Trends data for AI assistants.
REST call:
{
"mode": "get_top_trends",
"type": "Google Trends",
"limit": 25,
"offset": 0
}
MCP equivalent: get_top_trends(type="Google Trends", limit=25).
A live response on 2026-07-25 returned:
{
"as_of_ts": "2026-07-25T04:01:42.229953+00:00",
"type": "Google Trends",
"limit": 10,
"offset": 0,
"count": 10,
"data": [
[1, "kaylee hottle"],
[2, "tropical storm bertha"],
[3, "shakira"],
[4, "andrew tate"],
[5, "avengers doomsday"],
[6, "alaska airlines boeing 787-9 emergency"],
[7, "tornado watch"],
[8, "weather"],
[9, "masters of the universe"],
[10, "nivea"]
]
}
Each data row is [rank, query_string]. Ranks are 1-indexed. The query string is the exact text to pass as keyword on downstream get_growth or get_time_series calls.
| Field | Type | Use |
|---|---|---|
as_of_ts | string (ISO 8601 UTC) | Freshness stamp for the snapshot |
type | string | Echo of the feed requested |
limit | integer | Max rows returned (default 25, max 200) |
offset | integer | Rows skipped for pagination (default 0) |
count | integer | Rows in this response |
data | array | Ranked [position, term] pairs |
Default limit is 25. Raise it to 50 or 100 when monitoring long-tail entries that enter below rank 25 before breaking into the visible board. Use offset to page deeper:
{"mode": "get_top_trends", "type": "Google Trends", "limit": 50, "offset": 50}
Each paginated call still costs one request. A job that fetches ranks 1-50 in two 25-row pages spends two requests per poll cycle. Prefer a single call with limit: 50 when the quota allows.
The upstream Google Trends board refreshes on its own schedule, not on every API call. Polling faster than the feed updates wastes quota without adding signal.
| Interval | Requests/day | Requests/month (30 days) | Best for |
|---|---|---|---|
| 5 minutes | 288 | 8,640 | Paid plans, breaking news desks |
| 30 minutes | 48 | 1,440 | Newsroom monitoring with growth confirmation |
| 1 hour | 24 | 720 | Daily brief automation |
| 6 hours | 4 | 120 | Free-tier discovery with manual follow-up |
| 1 per day | 1 | 30 | Free-tier trend scanning |
Store each response keyed by as_of_ts. If a new poll returns the same as_of_ts as the prior poll, skip diff logic until the timestamp advances.
Compare the data array from poll N against poll N-1:
New entry rule: Flag any query absent from the previous snapshot.
Rank jump rule: Flag any query that moved up five or more positions.
Exit rule: Note terms that dropped off the board. They may still hold elevated volume but lost relative rank to faster-rising queries.
Persist diffs in a table with columns for term, prior_rank, current_rank, as_of_ts, and alert_status. This table feeds downstream growth confirmation without re-polling the leaderboard.
Leaderboard presence alone does not prove sustained demand. After diffing, escalate flagged terms:
Step 1: growth snapshot
{
"mode": "get_growth",
"source": "google search",
"keyword": "tropical storm bertha",
"percent_growth": ["7D", "30D", "12M"]
}
One request returns all three periods. If google search returns data_unavailable, the upstream pipeline may be temporarily empty for that term. Retry on the next poll cycle or check news volume and google news for the same keyword.
Step 2: time series context
{
"mode": "get_time_series",
"source": "google search",
"keyword": "tropical storm bertha"
}
Five years of weekly points (~261 rows) show whether the spike is novel or a seasonal replay. Skip this step when quota is tight and the 7D growth already looks flat.
For spike threshold math and false-positive filters, see Google Trends breakout detection via API.
| Status / error | Meaning | Action |
|---|---|---|
200 with new as_of_ts | Fresh snapshot | Run diff logic |
200 with same as_of_ts | No upstream refresh | Back off interval |
| 401 | Invalid or missing API key | Fix Authorization header |
| 429 | Monthly quota exhausted | Upgrade plan or pause polls |
data_unavailable on growth follow-up | Temporary pipeline gap | Queue term for retry |
Production schedulers should treat data_unavailable as retryable, not as proof that interest is zero.
Inside Claude, Cursor, or ChatGPT with Trends MCP connected:
The assistant routes to get_top_trends and chains growth calls in one session. Cron jobs should use REST directly to avoid LLM latency on each poll.
Teams polling Google Trends alongside X, Reddit, and TikTok feeds multiply costs linearly. Each feed type is a separate get_top_trends call:
{"mode": "get_top_trends", "type": "X (Twitter) Trending", "limit": 25}
Four feeds polled hourly cost 96 requests per day. Batch feeds into one cron window and share the diff table schema across platforms. For cross-feed architecture, see the real-time trends API.
FAQ