Google Trends Scraper

Give it keywords and get Google Trends back as flat, typed rows: interest over time, interest by region, and the top and rising related queries — one row per datapoint, ready to drop straight into a spreadsheet, a database or a chart. It can also pull the Trending Now list for any country. No account, no API key, no cookies, no browser.

• Up to 25 keywords per run, each scaled 0-100 against its own peak — the same numbers Google Trends shows you.
• Three data sets per keyword: interest over time, interest by region, and top + rising related queries. Tick only the ones you want and pay for nothing else.
• Every region Google supports: a country code like US, GB, DE or IN, a sub-region like US-CA, or worldwide.
• Time ranges from the past hour to 2004-to-now, plus any custom date range you type.
• Optional comparison mode puts up to five keywords on one shared scale, exactly like typing several terms into Google Trends at once.
• Optional Trending Now list for any country, with the top news story behind each spike.
• Runs with empty input return a labelled sample row, free, so you can see the shape first.

Price

$0.06 per 1,000 rows, plus a $0.001 start fee per run (billed per gigabyte of run memory, so exactly that on the default 1 GB).

This is the cheapest Google Trends scraper on the market, and it is the same rate on every plan, free or paid. There are no volume tiers, no minimum spend, no subscription and no add-on fees. What you read here is what you pay on day one and on day four hundred.

Rows	Total cost
100	$0.007
1,000	$0.061
10,000	$0.601
100,000	$6.001

What is actually charged

• One trend-scraped event per row row written to the dataset. Nothing else is metered per row.
• Free: the sample row an empty run returns, and every diagnostic row — a blocked target, a dead URL, a search that matched nothing. Those rows all carry "charged": false.
• Datapoints Google marks as having no data are dropped before they are charged, so a keyword with thin volume costs you nothing for the empty part of the series.
• Diagnostic rows — a keyword with no data, a rate-limited request, a region Google does not publish — are never charged.
• If you ask for city-level detail in a region where Google has none, the run quietly falls back to the level Google does publish. You are charged for the rows you actually get, never for the attempt.
• A run that finds nothing costs the start fee and nothing more.
• Rows never leave the dataset without a charge, and are never charged without a row. The billed event is a named one, so there is no price quietly attached to apify-default-dataset-item — the trick that makes some scrapers bill you for their own error messages.

Input

{
  "searchTerms": [
    "bitcoin",
    "ethereum"
  ],
  "geo": "US",
  "timeframe": "today 12-m",
  "dataTypes": [
    "interestOverTime",
    "interestByRegion",
    "relatedQueries"
  ],
  "maxItems": 500
}

Field	What it does
searchTerms	The keywords or phrases to look up. Up to 25 per run. Each one is looked up on its own and scaled 0-100 against its own peak.
geo	Two-letter country code (US, GB, DE, IN, BR), a sub-region (US-CA, GB-ENG), or empty for worldwide.
timeframe	One of now 1-H, now 4-H, now 1-d, now 7-d, today 1-m, today 3-m, today 12-m, today 5-y, all — or a custom range typed as 2024-01-01 2024-12-31.
dataTypes	Any of interestOverTime, interestByRegion, relatedQueries. Leave all three in to get everything; drop the ones you do not need and the bill drops with them.
maxItems	Total rows across every keyword and data set. Budget roughly 150 rows per keyword when all three data sets are on. Default 1,000, hard ceiling 20,000.
compareKeywords	Off by default. Turn it on to put the first five keywords on one shared scale so their interest-over-time values can be compared directly.
searchType	web, images, news, youtube or shopping — which Google surface the interest is measured on.
regionLevel	default, country, region, city or metro. Controls how finely interest by region is broken down. city and metro produce far more rows; when Google has no data at that level the run falls back to the level it does publish.
category	Optional Google Trends category id, for example 71 for Food & Drink or 7 for Finance. 0 means all categories.
language	Language code for region names and labels, like en-US, de or ja. It changes spelling, not data.
trendingNowGeos	Optional country codes for the Trending Now list. Independent of the keywords, and usable on its own.
proxyUrls	Leave empty. Fill it in only if you want the traffic to leave through proxy servers you already pay for, as http://user:pass@host:port.

Run it with empty input and you get one clearly labelled sample row, free, so you can see the output shape before you spend anything.

Output

One row per row. A real row from a real run:

{
  "ok": true,
  "charged": true,
  "keyword": "bitcoin",
  "geo": "US",
  "timeframe": "today 12-m",
  "searchType": "web",
  "category": 0,
  "trendsUrl": "https://trends.google.com/trends/explore?q=bitcoin&date=today+12-m&geo=US",
  "recordType": "interest_over_time",
  "date": "2025-08-10T00:00:00.000Z",
  "dateLabel": "Aug 10, 2025",
  "value": 36,
  "formattedValue": "36",
  "isPartial": false,
  "scrapedAt": "2026-08-15T21:58:30.942Z"
}

Field notes

• recordType — which of the four kinds of row this is: interest_over_time, interest_by_region, related_query or trending_now. Filter on it to split the dataset into its parts.
• value — Google's own 0-100 relative interest number. 100 is the peak of the series you asked for, not an absolute search volume — Google never publishes absolute volumes.
• formattedValue — the label Google shows next to the value. For rising related queries this is where Breakout and +450% appear, which the numeric value cannot express.
• date — ISO 8601 in UTC, for interest_over_time rows and for the publication time of a trending_now row. Null on regional and related-query rows.
• dateLabel — the same instant as Google prints it on the chart axis, kept because a weekly point covers a range that the timestamp alone hides.
• isPartial — true on the final point of a series, where the period has not finished yet and the value will still move. Drop those rows before charting a trend line.
• geoName — the region name in your chosen language, on interest_by_region rows. geoCode carries the machine-readable code where Google publishes one.
• latitude / longitude — only present on city-level regional rows, where Google returns coordinates instead of a region code.
• relatedQuery — the related search, on related_query rows. queryType is top (consistently searched alongside your keyword) or rising (growing fastest right now), and rank is its position in that list, 1 being the strongest.
• trendsUrl — the Google Trends page the row came from, so any number can be checked by eye in one click.
• trafficEstimate — on trending_now rows only — the approximate search count Google publishes for the spike, such as 20K+.

Every real row carries "charged": true. Sample rows carry "_sample": true and diagnostic rows carry "_diagnostic": true with an errorCode you can filter on, and neither is ever billed.

How it works

• It talks to the same JSON endpoints the Google Trends website itself calls, and asks for only the data sets you ticked — no page rendering, no headless browser, no login, no API key.
• The endpoint hands any first-time visitor a short-lived guest session before it will answer. The run mints its own, keeps it for the run, and throws it away at the end. Nothing is stored between runs and no account is ever involved.
• Requests leave through a large pool of rotating addresses. Google throttles per address, so when one is throttled the run simply continues from the next one rather than waiting — and because the data request is not tied to the address that opened it, nothing has to be redone.
• Every response is parsed straight into flat rows. A datapoint Google marks as empty is dropped before it becomes a row, so you are never billed for a gap in the series.
• The Trending Now list comes from Google's own public feed for that country, which needs no session at all.

What people use it for

• SEO and content planning: pull the rising related queries for a topic every week and write against the ones that are climbing rather than the ones that already peaked.
• Demand forecasting and seasonality: five years of weekly interest for a product term, in one table, ready to plot or to feed a model.
• Market entry and localisation: run the same keyword across a dozen country codes and compare where the interest actually is before committing a budget.
• Brand tracking without the guesswork: comparison mode puts several names on one shared scale, so the lines are directly readable against each other instead of each being scaled to its own peak.
• Newsroom and social monitoring: the Trending Now list for a country, with the top story behind each spike, on a schedule.
• PPC keyword expansion: the top and rising related queries are a ready-made list of terms real people type around yours.
• Academic and analyst work: flat, typed, deduplicated rows with an ISO timestamp on every one, so a dataset built over months stays comparable.

The four kinds of row

Everything is one flat table, and recordType tells you which part of Google Trends a row came from:

• interest_over_time — one row per point on the chart. Carries date, dateLabel, value and isPartial. A 12-month range gives about 53 weekly points; the past day gives minute-level points; all gives monthly points back to 2004.
• interest_by_region — one row per region, carrying geoName, geoCode and value. Worldwide runs break down by country; a single country breaks down by state or province, or by city or metro area if you ask for it.
• related_query — one row per related search, carrying relatedQuery, queryType (top or rising), rank, value and formattedValue. Up to 25 of each per keyword.
• trending_now — one row per search spiking right now in the country you asked for, carrying rank, trafficEstimate and the top news story behind it.

Because it is one table, keyword, geo, timeframe, searchType and category are repeated on every row. That is deliberate: you can filter or group the dataset without joining anything back together.

Reading the output

Every run writes three kinds of row, and they are easy to tell apart:

• Real rows carry "charged": true. These are the rows you paid for, one billed event each.
• The sample row carries "_sample": true and "charged": false. There is exactly one, it only appears when the input had no keywords and no trending-now regions, and it exists so you can look at the output shape before you spend anything.
• Diagnostic rows carry "_diagnostic": true, "charged": false and an errorCode you can switch on: NO_RESULTS when Google has no data for a keyword in that region and range, RATE_LIMITED when Google throttled a request and the run could not recover it, BLOCKED when a request was refused, TIME_BUDGET when the run ran out of time before reaching a keyword, NETWORK when the target could not be reached. Each carries a plain-English error and the keyword or geo it belongs to.

If you only want the data, filter on charged == true. The count of those rows always equals the number of events you were billed for, so the dataset is its own invoice.

What the 0-100 number actually means

Google Trends never publishes absolute search volumes. Every value is relative: 100 is the highest point of the exact series you asked for, and everything else is scaled against it. Change the time range, the region or the category and the whole series is rescaled.

Two consequences worth knowing before you build on it:

1. Two separate runs are not directly comparable. "bitcoin" at 100 and "ethereum" at 100 in two runs does not mean they are equally searched — each was scaled against its own peak. When you need them on one scale, turn on compareKeywords and run them together; that is exactly what the shared scale is for.
2. A keyword with low volume returns little or nothing. Google suppresses series it considers too sparse, and you get an uncharged NO_RESULTS row rather than a flat line of zeroes. Broaden the region, lengthen the time range, or use a more common phrasing.

Limitations

• Related TOPICS are not offered. Google returns an empty list for that particular widget to callers who are not signed in, so shipping the field would mean shipping a column that is always empty. Related QUERIES — top and rising — are unaffected and come back in full.
• Values are Google's relative 0-100 index, never absolute search volumes. Nobody can scrape absolute volumes from Google Trends because Google does not publish them.
• A series is rescaled whenever the region, time range or category changes, so numbers from runs with different settings cannot be compared point-for-point.
• Keywords with low search volume return no data at all rather than low numbers. You get an uncharged diagnostic row saying so.
• The final point of a series is usually partial — the period has not finished — and is flagged with isPartial: true. It will move if you re-run later in the day.
• City-level and metro-level breakdowns are best-effort. Google publishes dense city data for high-volume terms in large countries and nothing at all in many other combinations; when there is nothing, the run falls back to the level Google does publish. Metro areas exist for the United States only.
• Comparison mode takes at most five keywords, which is Google's own limit; extra keywords are dropped with a warning.
• The Trending Now list is whatever Google currently publishes for that country — typically around ten entries — and it is a live snapshot, so two runs an hour apart will differ.
• Google throttles heavy use per address. The run answers a throttle by continuing from a different address, but a very large run can still end with some keywords carrying an uncharged RATE_LIMITED row instead of data.
• Hard ceilings: 25 keywords per run, 20 trending-now regions per run, 20,000 rows per run. Split larger jobs across runs.
• Category ids are Google's own numeric ids. There is no lookup built in — pick the number off a Google Trends URL when you narrow a search by category there.

Questions

Do I need a Google account or an API key?

No. The run mints its own short-lived guest session against Google's public endpoints and discards it when it finishes. No account is created, no credentials are stored, and nothing carries over between runs.

Why does one keyword produce so many rows?

Because the output is flat. A single keyword with all three data sets over twelve months is about 53 interest-over-time points, about 50 regions and up to 50 related queries — roughly 150 rows. That is the same data Google shows you on one page, unpacked so it can be sorted, filtered and charted without any parsing. If you want fewer rows, untick data sets in dataTypes or lower maxItems; you are only charged for rows you actually receive.

Can I compare two keywords directly?

Yes — set compareKeywords to true and put both in searchTerms. Up to five keywords are then put on one shared 0-100 scale, so their value numbers can be read against each other. Leave it off and each keyword is scaled against its own peak instead.

What happens if a keyword has no data?

You get one uncharged diagnostic row for it with errorCode: "NO_RESULTS", and the run carries on to your other keywords. You are never billed for a keyword that returned nothing.

Will the run fail if Google throttles it?

No. A throttled request is retried from a different address automatically. If a data set still cannot be fetched you get an uncharged RATE_LIMITED diagnostic row for it and the run still finishes as succeeded — a failed run would still bill you the start fee, which would mean paying to be told something went wrong.

Can I run this on a schedule?

Yes. Nothing is held between runs. Schedule the same input daily or weekly and use keyword plus recordType plus date as a key to work out what changed. Remember that the last point of each series is partial and will move.

Do I need a proxy?

No. The run brings its own egress and its cost is already inside the price you see. The proxyUrls field exists only for callers who specifically want traffic to leave through servers they already own.

How do I get exactly the rows I paid for?

Filter the dataset on "charged": true. Sample and diagnostic rows are always false, and the number of charged rows always equals the number of billed events.