# Google Trends Scraper — Compare 100 Keywords on One Scale (`evanlin/google-trends-scraper`) Actor

Compare up to 100 search terms on ONE 0–100 scale, so the numbers are real ratios. Google compares only five per request; past five this anchors the requests together. One row per keyword, ranked most-searched first. $0.002 per keyword, no start fee, nothing charged for a keyword with no data.

- **URL**: https://apify.com/evanlin/google-trends-scraper.md
- **Developed by:** [Evan Lin](https://apify.com/evanlin) (community)
- **Categories:** SEO tools, Business
- **Stats:** 2 total users, 1 monthly users, 100.0% runs succeeded, 0 bookmarks
- **User rating**: No ratings yet

## Pricing

$2.00 / 1,000 keyword checkeds

This Actor is paid per event. You are not charged for the Apify platform usage, but only a fixed price for specific events.

Learn more: https://docs.apify.com/actors/running/actors-in-store.md#pay-per-event

## What's an Apify Actor?

An Actor is a serverless cloud program that runs on the Apify platform. It has two run modes.
In Batch mode, an Actor accepts a well-defined JSON input, performs an action which can take anything from a few seconds to a few hours,
and optionally produces a well-defined JSON output, datasets with results, or files in key-value store.
In Standby mode, an Actor provides a web server which can be used as a website, API, or an MCP server.

Apify vocabulary and the platform model are defined once, in the agent quickstart at https://apify.com/agents.md.

## How to integrate an Actor?

If asked about integration, you help developers integrate Actors into their projects.
You adapt to their stack and deliver integrations that are safe, well-documented, and production-ready.

Do not guess an integration path. Every one of them is in the agent quickstart at https://apify.com/agents.md: the Apify MCP server, Agent Skills with the Apify CLI, the JavaScript and Python clients, the REST API, and the account-free path for an agent with no human to sign in. It also carries the rule on stating cost before the first paid run.

For examples already wired to this Actor's own input schema, see the [API](#api) section below.

Each client library has reference documentation the quickstart does not restate: [JavaScript/TypeScript](https://docs.apify.com/api/client/js/docs.md) (`npm install apify-client`) and [Python](https://docs.apify.com/api/client/python/docs.md) (`pip install apify-client`).

# README

## 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](#compare-more-than-5-keywords-on-one-scale).

### 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

```json
{ "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

```json
{
  "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.

# Actor input Schema

## `keywords` (type: `array`):

Search terms, up to 100. All of them share one 0–100 scale: Google compares five per request, and past five the requests are joined by anchoring, so a 40-keyword comparison is still one scale rather than eight separate 100s.

## `compare` (type: `boolean`):

On (default): every term ends up on one 0–100 scale, so 'air fryer 64 vs slow cooker 14' is a real ratio — past five terms that takes about one extra request per five, which is never billed. Off: each term is fetched alone and peaks at its own 100 — correct when the terms are unrelated, wrong if you then compare them.

## `geo` (type: `string`):

Two-letter country code such as US, GB, DE. Leave empty for worldwide.

## `timeRange` (type: `string`):

Window to report on. Defaults to the past 12 months, the same default Google Trends itself uses.

## `category` (type: `integer`):

Google Trends category id. 0 is all categories.

## `includeRegion` (type: `boolean`):

Add the per-region breakdown for each keyword. One extra request per group of keywords; Google produces it relative to that group, which each row reports as `scaleGroup`.

## `includeRelated` (type: `boolean`):

Add the top and rising related queries for each keyword. One extra request per keyword.

## `includeTimeline` (type: `boolean`):

Keep each keyword’s full timeline in the output. It costs no extra requests, but it is about 4.5 KB per keyword — turn it off when you only need the comparison, the averages and the changes, and a 100-keyword run shrinks from roughly 1 MB to under 100 KB.

## `maxConcurrency` (type: `integer`):

Requests in flight at once, 1–4. Default 1: parallel requests share one address and one cookie jar, so a rate limit hits all of them together and the keywords in flight are lost. Raise it only when you would rather have the speed than the completeness.

## `proxyConfiguration` (type: `object`):

Google Trends limits requests per IP, both per second and cumulatively. A comparison of many keywords is several requests, so leave Apify Proxy on and the run rotates addresses instead of exhausting one.

## Actor input object example

```json
{
  "keywords": [
    "air fryer",
    "instant pot",
    "slow cooker"
  ],
  "compare": true,
  "geo": "",
  "timeRange": "today 12-m",
  "category": 0,
  "includeRegion": false,
  "includeRelated": false,
  "includeTimeline": true,
  "maxConcurrency": 1,
  "proxyConfiguration": {
    "useApifyProxy": true
  }
}
```

# Actor output Schema

## `records` (type: `string`):

One record per keyword, ordered most-searched first and numbered with rank, so reading only the top of the dataset reads the answer. Each holds the weekly timeline (omit it with includeTimeline to keep a 100-keyword run under 100 KB), averageValue, latestValue, peakValue and peakDate, a recentChangePercent that compares the last quarter with the one before it (seasonality included — no row claims a trend) plus a recentChangeVsGroup that measures it against the median of the comparison, which is where the season cancels out, and a trendsUrl that opens Google's own page for the same request so the row can be checked. Plus interestByRegion and related queries when requested. Every record carries sharedScale and comparedWith, which say whether its numbers may be compared with the other rows', and scaleAnchor, scaleGroup and scaleConfidence, which say how it got onto the shared scale.

## `recordsCsv` (type: `string`):

The same records as CSV, for spreadsheets and BI tools.

## `overview` (type: `string`):

Keyword, average, latest, change, peak and how the row was put on the shared scale — the comparison at a glance, without the per-week detail.

# API

You can run this Actor programmatically using our API. Below are code examples in JavaScript, Python, and CLI, as well as the OpenAPI specification and MCP server setup.

## JavaScript example

```javascript
import { ApifyClient } from 'apify-client';

// Initialize the ApifyClient with your Apify API token
// Replace the '<YOUR_API_TOKEN>' with your token
const client = new ApifyClient({
    token: '<YOUR_API_TOKEN>',
});

// Prepare Actor input
const input = {
    "keywords": [
        "air fryer",
        "instant pot",
        "slow cooker"
    ],
    "proxyConfiguration": {
        "useApifyProxy": true
    }
};

// Run the Actor and wait for it to finish
const run = await client.actor("evanlin/google-trends-scraper").call(input);

// Fetch and print Actor results from the run's dataset (if any)
console.log('Results from dataset');
console.log(`💾 Check your data here: https://console.apify.com/storage/datasets/${run.defaultDatasetId}`);
const { items } = await client.dataset(run.defaultDatasetId).listItems();
items.forEach((item) => {
    console.dir(item);
});

// 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/js/docs

```

## Python example

```python
from apify_client import ApifyClient

# Initialize the ApifyClient with your Apify API token
# Replace '<YOUR_API_TOKEN>' with your token.
client = ApifyClient("<YOUR_API_TOKEN>")

# Prepare the Actor input
run_input = {
    "keywords": [
        "air fryer",
        "instant pot",
        "slow cooker",
    ],
    "proxyConfiguration": { "useApifyProxy": True },
}

# Run the Actor and wait for it to finish
run = client.actor("evanlin/google-trends-scraper").call(run_input=run_input)

# Fetch and print Actor results from the run's dataset (if there are any)
print(f"💾 Check your data here: https://console.apify.com/storage/datasets/{run.default_dataset_id}")
for item in client.dataset(run.default_dataset_id).iterate_items():
    print(item)

# 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/python/docs/quick-start

```

## CLI example

```bash
echo '{
  "keywords": [
    "air fryer",
    "instant pot",
    "slow cooker"
  ],
  "proxyConfiguration": {
    "useApifyProxy": true
  }
}' |
apify call evanlin/google-trends-scraper --silent --output-dataset

```

## MCP server setup

```json
{
    "mcpServers": {
        "apify": {
            "type": "http",
            "url": "https://mcp.apify.com/?tools=fetch-actor-details,evanlin/google-trends-scraper"
        }
    }
}
```

The hosted server signs you in with OAuth on first connect, so no API token belongs in this config. Clients without OAuth support can send an `Authorization: Bearer <APIFY_API_TOKEN>` header instead, using a token from API & Integrations in Apify Console (https://console.apify.com/settings/integrations).

## OpenAPI specification

Download the OpenAPI definition: https://api.apify.com/v2/actors/kwmxQV6bpiBGC8Bly/builds/lSVVCf7hxhH1zJDXk/openapi.json