Pricing

from $4.00 / 1,000 completed keyword groups

Try for free

Go to Apify Store

Google Trends Scraper API & Breakout Monitor

Try for free

Google Trends scraper and API for keywords or pasted Trends links: interest over time, regions, related and rising queries, Trending Now topics. Schedule a watchlist to catch new Breakout signals. No Google account or API key needed.

Pricing

from $4.00 / 1,000 completed keyword groups

Rating

0.0

(0)

Developer

Vadim Bezrukov

Actor stats

Bookmarked

Total users

Monthly active users

2 days ago

Last modified

Changelog

2026-11-02: Short runs start with 512 MB again (1.10.25)

Fixes

Runs start with 512 MB of memory again, as they did before 1.10.23. With 256 MB, some short runs on a busy Apify server took up to 22 seconds instead of about 4, so a run with a short timeout (for example 25 seconds) could stop as TIMED-OUT. The memory fixes from 1.10.23 stay: large batches still need far less memory than before. Runs, schedules and Tasks that set their own memory keep it, and 256 MB is still available in the run options.

2026-10-31: A run moved to another server finishes its batch (1.10.24)

Fixes

When Apify moves a run to another server while it is delivering results, the run no longer fails with PREVIOUS_ATTEMPT_INTERRUPTED. In snapshot mode it saves which keyword groups and Trending Now feeds it has delivered, continues on the new server with the rest, and finishes with one row set and one charge per group, as if it had not moved. Long batches are moved more often simply because they run longer. Monitor runs, and restarts without Apify's notice, keep the previous behavior: delivered output stays, and the status message asks for a new run.

2026-10-31: Large batches use less memory, lower platform usage per run (1.10.23)

Fixes

Large batches need much less memory. A run no longer keeps the data points of every finished keyword group in memory until it ends, returns freed memory to the system, and reads fewer saved results ahead when it has 256 MB. The largest batch the Actor accepts (200 groups of five keywords over five years) used up to 511 MB of 512 MB and could stop with an out-of-memory error at 256 MB; it now peaks at about 120 MB. Rows, charges and RUN_SUMMARY counts are unchanged.

Improvements

Runs now start with 256 MB of memory instead of 512 MB, which roughly halves the compute part of a typical run's platform usage. Results are the same, and runs with one or a few groups take as long as before. Very large batches take longer: 200 groups of five keywords took about 27 minutes instead of 14. They still fit the default one-hour timeout; if you set a shorter timeout for a batch that large, raise it or choose 512 MB in the run options. Runs, schedules and Tasks that set their own memory keep it.

2026-10-30: Search terms from a public Google Sheet, clearer input form (1.10.22)

Features

spreadsheetId from the official Google Trends Scraper's input now works: give the ID or link of a Google Sheet shared as "Anyone with the link can view", and the terms in its first column below the header row are checked like searchTerms (with isMultiple and maxItems). A sheet that is not public, not found or empty is one explained INVALID_INPUT row; nothing is requested from Google or charged for it.

Improvements

The input form is easier to scan: the optional settings sit in collapsed sections named Comparison groups, Monitoring, Google refusals and Dataset format, and Proxy, instead of three sections all called "Advanced". Comparison groups moved into their own section. Field names, defaults and results are unchanged, so saved Tasks and API calls keep working.
The README is shorter to read: the long list of earlier updates is now a short "What's new" with a link to this changelog.

2026-10-30: A finished run stays successful after a server move (1.10.21)

Fixes

Apify sometimes moves a run to another server a moment after it has finished. The restarted copy then marked the finished run FAILED with PREVIOUS_ATTEMPT_INTERRUPTED, although every result, charge and monitoring baseline was already saved. Such a run now ends SUCCEEDED with its original RUN_SUMMARY, and nothing is written or charged twice. Resurrecting a finished successful run works the same way. A move during delivery is still refused as before. Inputs, output formats and prices are unchanged.

2026-10-24: Fewer storage writes per run (1.10.20)

Improvements

Each run writes two fewer records to its key-value store, which lowers the platform usage of short runs. Results, statuses, RUN_SUMMARY and charges are unchanged, and a run moved to another server before its first result still resumes.

2026-10-24: Large official-scraper inputs never fail the run (1.10.19)

Fixes

An input in the official Google Trends Scraper's format that adds up to more than 200 groups (for example searchTerms split by isMultiple, or searchTerms plus startUrls) stopped the run with "Invalid input", even with maxItems set. Now the first 200 groups are checked and the rest are INVALID_INPUT rows that are not requested from Google or charged.
startUrls takes up to 200 links, like searchTerms; a longer list is refused before the run starts instead of failing it.

Improvements

Terms that isMultiple splits into charts of five now leave one input note instead of one per term, so the status message stays readable.

2026-10-24: Resume a server migration before result delivery (1.10.18)

Fixes

If Apify moves a run to another server while it is still collecting its first result, the Actor can repeat that collection within the remaining time. Previously it stopped even when delivery had not started. Once delivery has started, the existing restart guard still prevents duplicate rows or charges. Inputs, output formats and prices are unchanged.

2026-10-24: The official Google Trends Scraper input, read as is (1.10.17)

Features

The JSON input of the official Google Trends Scraper runs unchanged: searchTerms, isMultiple, timeRange, customTimeRange, startUrls, geo, category (also as text, such as "71") and maxItems map onto this Actor's fields, with that scraper's defaults (worldwide, past 12 months) when they are left out. maxItems checks the first N terms; the rest are INVALID_INPUT rows and are not charged.
spreadsheetId and the official scraper's tuning fields are accepted without failing the run; what was not honored is listed in the new RUN_SUMMARY.inputWarnings and at the end of the status message.

Compatibility

Nothing changes for inputs of this Actor: same groups, rows, status message and charges. In Console, category becomes a small JSON box so it can take the official scraper's text; numbers work as before. An input written for the official scraper produces the same groups, rows and charges as the equivalent input of this Actor.

2026-10: Keyword summaries, Google Trends links, run completeness and event IDs (1.10.16)

Features

Paste a Google Trends explore link into Keywords, one per line, next to plain keywords. The run checks that view: its terms (up to 5, compared together), location, time range, category and search type. Settings the link leaves out use the Google Trends defaults (worldwide, past 12 months), not the run settings. A link that compares different regions or periods, names a topic by its id, or is not a Trends explore page becomes one INVALID_INPUT row with the reason and is not charged.
A one-row keyword_summary for every keyword of a checked group, right after the group's status row: direction (UP, DOWN, STABLE), change_pct between the latest complete periods of the chart and as many periods before them, the peak, the latest value, the top rising query and an explanation sentence. Without a direction, summary_status says why (INSUFFICIENT_DATA, NOT_REQUESTED, NO_DATA, SOURCE_FAILED). Built from data the run already collected: no extra requests, no price change, and it does not count toward a group's 250 included rows. New Keyword summary view. Runs started in Console or by AI agents get summaries by default; API and scheduled runs get them with the new keywordSummaries: true input. In compact storage each summary is its own stored item, like a status row, so a CSV export with unwind=rows keeps every column.
Status rows carry data_freshness (FRESH, CACHED, NONE) and last_verified_at.
RUN_SUMMARY.completeness counts fresh, cached, partial, failed, not checked and invalid groups, the oldest cache age and up to 50 groups without fresh data. Its line is added to the end of the run's status message; the first sentence ("N/M groups completed; ...") is unchanged. A PARTIAL group is reported as partial.
Signal rows carry a stable event_id (monitor, query or topic, change type, growth level). Re-reading a run or a repeated webhook gives the same ID, so a sheet or table can upsert on it. The README shows Sheets, SQL, Python and Node.js examples.
A ready n8n daily digest with a Google Sheets template: topics from a sheet, one monitor run a day, Summary, Signals, Errors and Runs tabs written by summary_id, event_id and run, and one message per run. It turns keyword summaries on itself. The earlier "changes to Google Sheets" workflow keeps working unchanged.

Compatibility

Nothing to change in an existing API or scheduled integration: it gets the same rows and the same first sentence of the status message as with 1.10.15. If you turn summaries on, filter rows by record_type: signals are observation rows with a signal change_type, and keyword_summary rows are neither.

2026-10-11: Complete CSV exports (1.10.15)

Fixes

CSV exports of API and scheduled runs keep every column again. Rows are now stored in smaller row_page items of a few dozen rows, because Apify's CSV export dropped nested columns such as source_scaling_context/... from larger pages. Rows, their order, JSON exports and prices are unchanged. Larger runs stored by 1.10.13 and 1.10.14 keep their old pages: export those as JSON with unwind=rows if you need every field.
When the spending limit stopped a Trending Now feed at delivery, the run summary counted it as delivered while its status row said FAILED (BUDGET_LIMITED). The summary now agrees with the row. This was rare: the limit is usually checked before the feed is fetched.

Documentation

New Output contract section: record types, the fields on every row, identifiers, order, paging, and the promise that fields, record types and values are only added.
New "In development" section in the README, without dates.

2026-10-11: Compact storage for large exports (1.10.14)

Changes

API and scheduled runs now store rows in compact row_page items, up to 500 rows each, instead of one Dataset item per row. Every row keeps its fields and order. The Output tab, the run's results link and any API request or export with unwind=rows return the same flat rows as before.
Action needed only if your integration reads raw Dataset items: add unwind=rows to the request, or set the new input datasetFormat to flat to keep one item per row. limit and offset count stored items, so do not page with unwind=rows: read the run in one request, or page through raw items and read each page's rows.
Runs started in Console or by AI agents through Apify MCP or Apify AI keep one item per row unless the input sets datasetFormat: Console's Export button and the MCP dataset tool read stored items as they are.
If you imported the n8n Google Sheets workflow from this page before October 11, 2026, import it again or set datasetFormat to flat: the old copy reads raw items and would report no changes for compact runs.
The previous version stays available as build old until November 10, 2026: pass build=old in the API, or choose it under Run options > Build in Console. It is the unchanged 1.10.12 build: one item per row, and it rejects inputs that contain datasetFormat.
Prices are unchanged and still follow rows, not stored items: a group includes its first 250 rows, and from October 20, 2026 each further row costs $0.00002 in either format.

Known issue

Found after this release: a CSV export with unwind=rows of a larger API or scheduled run can miss nested columns, such as source_scaling_context/... and source_metadata/.... Top-level columns, JSON exports, the Output tab, runs started in Console and the n8n workflow are complete. If you need every column in CSV, set datasetFormat to flat for those runs. A fix is in development.

2026-10-10: Short batch runs finish in time (1.10.12)

Fixes

A batch run with a short timeout, for example 20 keyword groups in 12-15 seconds, could be stopped by Apify as TIMED-OUT after its time ran out. Once the run is stopping it no longer writes a progress summary for every remaining group, so it finishes about a second earlier and keeps its final summary and all rows.

2026-10-10: A refused check no longer fails your run (1.10.11)

Changes

When Google refuses or does not answer any check in time, the run now ends SUCCEEDED instead of FAILED. Nothing changes in the data: every check is still a group_status row with status FAILED and its reason (THROTTLED, SOURCE_UNAVAILABLE or RUN_DEADLINE), never a zero, and it is not charged. The status message says Google gave no data and, for a short timeout, what would help. Read each group's status before using the results.
Action needed only if your integration retries failed runs: set the new input failRunOnRefusal to true to keep the previous behavior.
A changed Google response format or an error in the Actor still fails the run.

Fixes

A run whose timeout ends before the proxy connection is ready now reports its checks as RUN_DEADLINE rows, and can still deliver your cached result, instead of a proxy error that asked you to check your proxy access. No request is sent without the proxy.

2026-10-06: Large repeated batches stay within memory (1.10.10)

Fixes

A large batch that you run again in snapshot mode no longer loads every cached result into memory at the start. Before, a repeat of up to 200 five-keyword groups with every data type could run out of the 512 MB default memory. Small batches and single checks work exactly as before.

2026-10-06: Pricing for very large exports (1.10.9)

Pricing

From October 20, 2026, 22:18 UTC, a completed keyword group still costs $0.004 and includes its first 250 data rows; each further row in the same group costs $0.00002 (1,000 extra rows: $0.02). Most groups, with one or a few data types, stay under 250 rows and cost the same as before. Trending Now stays $0.002, and failed or partial groups remain free. If a run's spending limit cannot cover a whole group, that group is not charged and is marked BUDGET_LIMITED.

2026-10-06: Steadier cached results (1.10.8)

Fixes

When your result cache opens slowly, the run now simply continues without it. Before, a slow cache could interrupt a run after Google had already answered.
A damaged cache record that claims a result but holds no rows is ignored, so a refused check stays an honest FAILED instead of an empty success. A verified "no data" result is still delivered from the cache as before.

2026-10-05: More time for Google in short runs (1.10.7)

Improvements

A run now asks Google first and opens its result cache in the background. Before, the cache store was opened before the first request, which took a short run about half a second it needed for Google.
Cached results are read in the background at the start of the run, so a check Google refuses in the last seconds of a short run can still get your last verified result. Before, that read had less than a second and could miss.

Fixes

A gracefully aborted run is reported as aborted even when it delivered a cached result, and keeps rows a check had fully collected when the abort arrived.
If saving a cached result fails part way, the saved rows are counted and the run reports the write error, instead of adding a second, failed status for the same group.

2026-10-04: Safer cached results and charges (1.10.6)

Improvements

When Google refuses most checks of a batch but some are verified, the run now succeeds with those results instead of failing. The status says how many checks were verified (for example "2 of 20 checks verified (10%)"), every refused check stays a FAILED row, never a zero, and monitoring state is not advanced. A batch without a single verified check still fails.
A graceful abort now stops the run within seconds: no new requests to Google, unfinished checks are marked RUN_ABORTED, everything already saved stays with its charge, and the final run summary is written.

Fixes

A keyword group or Trending Now feed is now charged only after its status row and observations are saved. If a write fails or the run is stopped in between, you keep what was saved and are not charged for that group.
A group your spending limit cannot cover now shows BUDGET_LIMITED with nothing charged, instead of a status row without its observations.
A damaged record in the google-trends-monitor-cache store is now skipped, and the check keeps its normal status, instead of failing the whole run.
Cached rows now carry the externalId of the run that delivers them, not the one of the earlier run that verified them.
The cache never uses the last seconds a run needs to write its results, and one slow or failed store call switches it off for the rest of the run, so a large batch cannot wait on a slow store group after group.

2026-10-03: The last verified result when Google refuses (1.10.5)

Features

When Google refuses a fresh check for a few minutes, which a run with a short timeout cannot wait out, the Actor now delivers your account's last verified result of the same check instead of failing the run. Every such row keeps its original time, is marked CACHED with its age, and the group is not charged. Results up to 24 hours old are used (less for hourly timeframes, never for the last hour or four hours), in snapshot mode only. Set cachedResultOnRefusal to false to get a failed status instead.

2026-10-03: Slow connections work again in short runs (1.10.4)

Fixes

Version 1.10.3 gave each connection in a short run at most half of the remaining time. When the proxy connections themselves were slow (six seconds or more to open), every attempt was cut and the run failed, although the same run finished in time on 1.10.2. That limit is removed, and timeouts are reported as before. Short runs again get every retry that fits in their timeout.

2026-10-02: A stuck connection no longer uses up a short run (1.10.3)

Fixes

In runs with a short timeout, one slow or stuck proxy connection could take all the remaining seconds, so the retries never happened. Opening a connection and waiting for its answer now each get at most half of the time left (never less than 5.5 seconds, which covers normal slow connections); a stuck one is closed and the next attempt starts on a new connection. Runs with longer timeouts are unchanged.
When a check fails because its connections kept timing out rather than because Google refused it, the result now reports a timeout instead of rate limiting.

2026-10-01: More retries for runs with a very short timeout (1.10.1)

Fixes

Runs with a timeout under about two minutes, for example 25 seconds from an API integration, now spend their remaining seconds on several quick retries through different connections when Google refuses a request. Previously such a run tried twice and failed.

Improvements

When a short run still fails because Google refused it or the time ran out, its status message names the timeout and suggests 300 seconds or more, which lets the Actor wait out most refusals. A failed group is still not charged.

2026-10-01: Steadier recovery for short timeouts, watchlists and comparisons (1.9.1)

Fixes

Runs with a timeout between about two and three and a half minutes now use all of their remaining time to wait out a Google refusal. Previously a run with 179 seconds left gave up after about a minute, while one with 181 seconds kept trying.
When several keyword groups were refused at the same time, they used up the shared retry allowance within about three minutes and all failed. Retries are now spaced further apart, so every group keeps a try for the end of the refusal wave. The total number of requests is still capped.
In a comparison of several keywords, one refused keyword no longer stops the others: each remaining keyword is still checked once, and its related queries are delivered. The comparison is still reported as partial and is not charged until every keyword is complete.

2026-10-01: Riding out Google's refusal waves (1.8.1)

Improvements

Google sometimes refuses related-query requests for a minute or more, for every connection at the same moment. Switching to a new connection does not help during such a wave, but waiting does. With the default run timeout the Actor now keeps retrying a refused request for up to five minutes instead of three, and with a 300-second timeout for up to three minutes instead of two. The number of attempts is unchanged, and they are spaced further apart. A group that is still refused is reported as failed and is not charged.
Runs with a timeout below about three and a half minutes keep the previous one-minute window. If you use related queries on a schedule at the top of the hour, the default timeout gives the Actor the most room to recover.

2026-09-29: Longer recovery when Google refuses a group's first request (1.7.1)

Improvements

When Google refuses the first request for a keyword group, the Actor now spreads its retries over the same recovery window it already uses for timeline, regional and related-query data, instead of giving up within about a minute. The number of attempts is unchanged. A group that is still refused is reported as failed and is not charged.
A failed run that your input cannot fix now asks you, in its status message and at the end of its log, to open an Issue with the link to the run. Apify then shares that run with me automatically, so there is no need to paste your input.
The RUN_SUMMARY record now states why a run or check failed (for example rate limiting, a timeout or the run's own time limit), counts checks by outcome and records the run's timeout and memory. Your keywords are not included.
The status message shows what the run is checking while it works.

2026-09-28: Where to report a failed run (1.6.1)

Improvements

When a run fails for a reason you cannot fix in your input, for example Google refusing every request or the proxy not connecting, its status message now ends with a link to this Actor's Issues tab. Paste the message and the run ID into an Issue so the failure can be matched to its cause. Runs rejected for invalid input or proxy settings keep their correction message without the link. Run statuses, results, charges and monitoring state are unchanged.

2026-09-27: Retry after redirected requests, startup and storage recovery (1.5.1)

Improvements

Google sometimes redirects a request from one connection instead of answering it. The Actor still never follows such redirects, but it now repeats the request through a new connection, as it already does for rate limits, instead of failing the keyword group at once. A group that stays redirected on every attempt is reported as failed and is not charged.
Calendar dates are checked before the platform starts a run.
Temporary failures reading or replacing storage records receive bounded recovery. Dataset appends and charges are never blindly replayed.
An interrupted startup may resume only when a persisted marker from the same build proves output has not begun. Once output might have started, restart protection remains in force to prevent duplicate delivery or billing.

Fixes

A nonempty batch whose groups are all invalid returns explicit INVALID_INPUT records and an ALL_INPUTS_INVALID summary, without querying Google, charging or changing monitoring state. This is a completed validation report, not collected data. Empty requests and invalid global settings still require correction.
A final summary error no longer hides the original failure, and a temporary failure to update advisory Console text does not discard a completed result.

2026-09-26: Reliable monitoring state and input checks (1.3.1)

Fixes

Rising queries now keep separate monitoring history for each seed keyword. TOP rankings cannot overwrite rising-growth bands. Existing monitors establish one fresh related-query BASELINE on their next successful check; trending-topic history is unchanged. Failed checks do not advance this migration.

Improvements

Repeated keywords within a comparison are collapsed ignoring case and whitespace. Repeated groups with the same ordered keywords and settings are reported as INVALID_INPUT, with their externalId preserved, and are not requested or charged again.
Custom date windows are checked for real dates and chronological order before contacting Google. A bad per-group date does not discard valid groups.

Documentation

Matching scaling-context IDs identify the same settings, but do not make separately collected scores directly comparable. Relative date windows move, and Google can sample and scale each request independently. Keep each request as a separate snapshot when analyzing past results. Existing inputs, IDs and monitoring events are unchanged.

Fixes

Related Queries returned for different keywords in the same comparison now have distinct source_id values, even when the related query text is identical. This prevents separate observations from overwriting each other in exports or integrations keyed by ID. Single-keyword IDs are unchanged. This update does not change retries, pricing or monitoring event classification.

Migration

For older multi-keyword exports, match records using source_scaling_context.id, keyword, related_type and related_query; the old ID alone can be ambiguous. Existing stored rows are not rewritten.

2026-09-22: Fixes for interrupted runs (1.0.35 and 1.0.37)

Fixes

Some runs spent too long retrying Related Queries when Google would not return that data. We've shortened the extra retry and moved timeline and regional lookups ahead of it. If Related Queries still fails, you keep the other results with a clear partial status. Your last complete monitoring snapshot stays intact. Your existing Tasks and API inputs work as before.

Improvements

Added a short retry for temporary connection problems at startup. Persistent connection failures are still reported before any checks are charged.

2026-09-18: Better handling of refused requests (1.0.33 and 1.0.34)

Improvements

Added a fresh connection attempt for Related Queries when ordinary retries do not help. The 22 September update reduces the time spent on this step.
If Keywords and Comparison groups together exceed 200 groups, the first 200 can still run. The extra groups are marked as invalid.
Trending Now lists with more than 50 countries are caught by input validation before a run starts.

Fixes

Fixed runs that described rejected search settings as a Google outage. Results now explain which groups Google rejected.

2026-09-17: Catch blank keywords before starting (1.0.32)

Improvements

Empty or whitespace-only keywords in Comparison groups now show an input error before the run starts, just like empty entries in the main Keywords field.

2026-09-14: Keep useful results from larger runs (1.0.28)

Fixes

Fixed a case where a large batch was marked as failed even though timeline and regional data had been collected. Missing Related Queries alone no longer causes that outcome.

Improvements

Runs that reach their time limit after verifying at least one check can now finish with the results collected so far. The summary shows which checks were completed, partial or unfinished, so you can decide what to run again.
Retries also leave a pause between temporary Google refusals without fetching successful results again.

2026-09-13: A dedicated regional results view

Features

Added an Interest by region view with region names, codes, keywords and relative interest, including an indicator for unavailable data.
You can now use UK and UK regional codes in place of the corresponding GB codes, or worldwide and global for a worldwide search.

Improvements

Added retry attempts for Related Queries within the existing time limit.

2026-09-11: Custom dates and settings for each group

Features

You can enter a date range such as 2025-11-01 2026-01-31 in the input form or API. Each Comparison group can also have its own country, timeframe, category and search property. A mistake in one group's settings affects that group only.

Improvements

The run summary now distinguishes checks skipped at a time or spending limit from actual source failures.

Fixes

Fixed valid Trends and Trending Now responses being rejected because their response type was labelled incorrectly.

2026-09-09: Safer handling of spending limits and interruptions

Improvements

Completed groups are delivered as they finish, so a later error does not discard data you've already received.
Errors in one group are isolated from other groups. Failed checks free up their reserved budget for later work.
Interrupted monitoring runs keep the last complete snapshot. Restarting the same interrupted run stops safely to avoid repeating potentially paid work. Start a new run when you want to check again.

Fixes

Fixed delivery of the last paid group or feed when it reaches the spending limit. A smaller remaining budget can still cover a Trending Now feed.

2026-09-08: Clearer results when Google asks us to wait

Improvements

Retries now coordinate their pauses instead of repeatedly requesting data while Google asks the Actor to wait.
The run summary shows the outcome for each requested data type, making incomplete results easier to spot.

2026-09-02: Updated connection defaults (1.0.13)

Improvements

Updated the default connection settings for keyword searches. Inputs using automatic Apify Proxy settings pick up the new defaults without changes.

2026-09-01: First release (1.0)

Features

Collect timelines, regional interest, related and rising queries, Breakouts and Trending Now topics. Use a snapshot for one-off research or monitor a watchlist for new signals, then browse the results or export them to your workflow.
Every group has a status, including partial and failed checks. Only fully answered keyword groups and Trending Now feeds are charged.

To get these updates, use the latest build in your run or Task settings. If you've pinned an older build, choose a newer one when you're ready to upgrade.

Google Trends Scraper — Interest, Regions & Queries

khadinakbar/google-trends-scraper

Extract all 5 Google Trends data types: keyword interest over time, by region, related queries, related topics & daily trending searches. No API key. MCP/API-ready.

Khadin Akbar

756

Google Trends Scraper

apify/google-trends-scraper

Scrape data from Google Trends by search terms or URLs. Specify locations, define time ranges, select categories to get interest by subregion and over time, related queries and topics, and more. Export scraped data, run the scraper via API, schedule and monitor runs, or integrate with other tools.

Apify

18K

3.7

(32)

Google Trends Scraper

leadsbrary/google-trends-scraper

FAST & CHEAP — $1 / 1,000 results. Scrape Google Trends by keyword or URL: trends over time, subregions, related queries/topics, locations, time ranges and categories. Export data, run via API, schedule and monitor runs.

Alexandre Manguis

113

5.0

(1)

Google Trends Scraper

data_xplorer/google-trends-fast-scraper

✅ 99%+ success rate: the reliable Google Trends API alternative. Get 🔥 daily trending searches by country and analyze Google Trends keyword search trends. Built for developers and data scientists who need programmatic Google Trends data without limitations.

Data Xplorer

6.8K

4.9

(4)

Amazon Scraper

automly/amazon-products-scraper---fast-efficient-with-sales-data

Amazon product scraper: Scrape Amazon products by keyword, product link or ASIN in 20 Amazon stores: price, Best Sellers Rank, monthly sales and revenue estimates, rating, review count, badges, variants and specs. No login. Export to CSV, JSON or Excel, schedule runs or use the API.

Automly

1.7K

5.0

(2)

Google Ads Transparency Scraper

solidcode/ads-transparency-scraper

[💰 $0.80 / 1K] Affordable and effective | Extract ad creatives from Google Ads Transparency Center. Search by keyword, domain, or advertiser ID with filters for platform, region, and date range.

SolidCode

2.7K

1.9

(4)

Google RealTime Trends Data Scraper

easyapi/google-realtime-trends-data-scraper

Real-time Google Trends data scraper that monitors trending search keywords across 40+ countries worldwide. Updated every 10 minutes, perfect for market research, content planning, and trend analysis. Get instant access to what's trending globally! 🌍🔍

EasyApi

222

5.0

(1)

Amazon Reviews Scraper

junglee/amazon-reviews-scraper

Amazon scraper to extract reviews from Amazon products. Scrape and download detailed reviews without using the Amazon API, including rating score, review description, reactions and images. Download your data as HTML table, JSON, CSV, Excel, XML.

Junglee

17K

2.7

(46)

Bulk File Downloader - URLs, Images, Pages & Datasets

automa-flow/parallel-bulk-file-downloader

Bulk file downloader and bulk image downloader: download hundreds of public files, or every image on a list of web pages, in parallel from URL lists or another Actor's Dataset. Get one manifest row per file with checksums, status, size and download URL.

Vadim Bezrukov

Google Trends Scraper – Interest Over Time & Related Queries

maged120/google-trends-scraper

Google Trends Scraper: get interest over time, interest by region, related queries and trending searches for any keyword. Compare keywords and pick country, timeframe, category and Google property (web, YouTube, news, images, shopping). Clean rows for CSV, Excel, JSON or API.

Maged

Google Trends Scraper API & Breakout Monitor

Changelog

2026-11-02: Short runs start with 512 MB again (1.10.25)

Fixes

2026-10-31: A run moved to another server finishes its batch (1.10.24)

Fixes

2026-10-31: Large batches use less memory, lower platform usage per run (1.10.23)

Fixes

Improvements

2026-10-30: Search terms from a public Google Sheet, clearer input form (1.10.22)

Features

Improvements

2026-10-30: A finished run stays successful after a server move (1.10.21)

Fixes

2026-10-24: Fewer storage writes per run (1.10.20)

Improvements

2026-10-24: Large official-scraper inputs never fail the run (1.10.19)

Fixes

Improvements

2026-10-24: Resume a server migration before result delivery (1.10.18)

Fixes

2026-10-24: The official Google Trends Scraper input, read as is (1.10.17)

Features

Compatibility

2026-10: Keyword summaries, Google Trends links, run completeness and event IDs (1.10.16)

Features

Compatibility

2026-10-11: Complete CSV exports (1.10.15)

Fixes

Documentation

2026-10-11: Compact storage for large exports (1.10.14)

Changes

Known issue

2026-10-10: Short batch runs finish in time (1.10.12)

Fixes

2026-10-10: A refused check no longer fails your run (1.10.11)

Changes

Fixes

2026-10-06: Large repeated batches stay within memory (1.10.10)

Fixes

2026-10-06: Pricing for very large exports (1.10.9)

Pricing

2026-10-06: Steadier cached results (1.10.8)

Fixes

2026-10-05: More time for Google in short runs (1.10.7)

Improvements

Fixes

2026-10-04: Safer cached results and charges (1.10.6)

Improvements

Fixes

2026-10-03: The last verified result when Google refuses (1.10.5)

Features

2026-10-03: Slow connections work again in short runs (1.10.4)

Fixes

2026-10-02: A stuck connection no longer uses up a short run (1.10.3)

Fixes

2026-10-01: More retries for runs with a very short timeout (1.10.1)

Fixes

Improvements

2026-10-01: Steadier recovery for short timeouts, watchlists and comparisons (1.9.1)

Fixes

2026-10-01: Riding out Google's refusal waves (1.8.1)

Improvements

2026-09-29: Longer recovery when Google refuses a group's first request (1.7.1)

Improvements

2026-09-28: Where to report a failed run (1.6.1)

Improvements

2026-09-27: Retry after redirected requests, startup and storage recovery (1.5.1)

Improvements

Fixes

2026-09-26: Reliable monitoring state and input checks (1.3.1)

Fixes

Improvements

Documentation

2026-09-26: Distinct IDs for related queries in comparisons (1.2.1)

Fixes

Migration

2026-09-22: Fixes for interrupted runs (1.0.35 and 1.0.37)

Fixes

Improvements