Best Google Trends Scraping Tools: Tested & Ranked
We tested 3 web data scrapers across 1,500 requests on Google Trends explore pages to see how they handle the page’s Angular-based widgets that only appear after JavaScript runs. For each provider we tracked the success rate and completion time.
Google Trends scraping benchmark
You can read our benchmark methodology for more details on our testing process.
Google Trends scraping benchmark results
Bright Data had the highest success rate on Google Trends at 61%, with a mean completion time of 105 seconds.
We used Bright Data’s Web Unlocker zone for Trends URLs and got back rendered HTML containing the related topics, rising values, and geo-chart widgets. The long completion time matches what we’d expect when waiting for Angular to populate these widgets.
SerpApi offers a dedicated Google Trends API that takes a search term as input and returns parsed JSON. You pass a keyword along with parameters like geo, date, and cat, and the API returns interest over time, regional breakdowns, related topics, and related queries as structured fields, with no HTML parsing required on the client side.
We didn’t include SerpApi in Google Trends scraping benchmark because it works on a query-based model rather than a URL-based one.
Zyte completed Google Trends requests in a mean of 8 seconds, but only 6% of responses contained the widget content.
URLs were sent through the Extract API with browserHtml: true, which loads each page in a real headless Chromium and returns the HTML after JavaScript runs. In most cases the response came back before the data widgets had finished rendering, so the validation selectors didn’t match.
Nimble returned HTTP 500 (“can’t download the query response”) on all 500 Google Trends requests in this run, so the mean completion time logged as 0 seconds with no successful responses.
We used the Extract API with render: true and the vx10 stealth driver, and every request failed at Nimble’s rendering stage before any HTML could be returned.
How Google Trends loads its data
Google Trends loads most of its content on the client side. The first HTTP response from trends.google.com/trends/explore is a small HTML shell of around 60 KB containing the page title and meta tags, but none of the actual widget data.
The visible content loads in stages:
- Initial shell: the static HTML response arrives with no Trends data.
- Angular framework loads: JavaScript runs and the page title updates to include “Explore.”
- Widgets populate: the related topics, rising values, and geo chart fill in once Angular finishes its client-side work.
Where scrapers struggle with Google Trends
Web data scrapers mostly faced challenges for one of three reasons:
Wait-vs-ban trade-off: adding extra wait actions to give Angular more time backfires. When we added waitForSelector and waitForTimeout to Zyte’s requests, the response flipped to HTTP 520 Website Ban with the error “could not get a ban-free response in a reasonable time.”
Shell-only captures: the response comes back before Angular has populated the widgets. The page title is correct but the widget DOM elements aren’t there yet, so CSS selectors find nothing to match.
No JS rendering at all: routing google.com URLs through a Google-specific scraper mode returns the static HTML shell without running a browser, so the widgets never appear.
What is Google Trends data?
Google Trends does not report raw search counts; it normalizes search data so users can compare relative popularity across time and place.
Google also notes that some Google product searches, including internal searches made through AI Mode and AI Overviews, are excluded from Trends data. That makes Trends best used as one signal among many rather than a full measure of total demand.
- Trending now data: Near-real-time trend views for the last 4 hours, 24 hours, 48 hours, or 7 days.
- Historical data: Long-term relative search-interest data dating back to 2004.
- Geographical insights: Global, country, region, and in some cases, city/subregion-level analysis.
- Topic and query breakdowns: Related topics, top queries, and rising queries for broader demand analysis.
- AI-assisted exploration: On the redesigned Explore page, Gemini can generate and compare up to eight suggested search terms and propose follow-up prompts.
Is it legal to scrape Google Trends?
Scraping publicly accessible Google Trends pages is not automatically unlawful in every jurisdiction, but compliance depends on more than public availability.
- Review Google’s Terms of Service and machine-readable instructions, such as robots.txt, before automating access.
- Treat legality and Terms-of-Service compliance as separate issues: a page may be public while certain automated access patterns are still restricted by contract or site policy.
Google Trends scraping benchmark methodology
We benchmarked 3 web scraping providers on Google Trends explore pages. Each provider ran the same set of 500 URLs spread across different keywords and country codes.
Every provider returned rendered HTML, which we parsed locally with CSS selectors aimed at Trends’ widget DOM. The four selector targets covered the related topics header, individual topic names, the rising-percentage badges, and the geo chart heading. Validation passed when at least one of these matched content in the returned HTML.
Data validation steps
A request had to clear three sequential steps to count as fully successful:
- The submission needed an HTTP status in the 200-399 band or a clean 404.
- An async execution (where applicable) needed to finish within the 10-minute ceiling without errors.
- The validation step needed at least one of the four widget selectors to match.
HTTP 429 responses triggered a 30-second back-off and up to 3 retries before being logged as a failure.
Non-200 handling
Status codes outside 200 were handled with a different validation path. A 201-399 response or a 404 auto-passed the validation gate on the assumption that the provider had correctly handled a non-200 case (redirect, missing page, etc.), so CSS matching only ran on HTTP 200 responses.
To make sure none of these auto-passes were hidden failures, we ran a cross-provider check after the benchmark: if another provider had successfully pulled widget data from a URL while this provider auto-passed without content, the auto-pass would have been reclassified as a failure. None of the Trends URLs needed that flip.
End-to-end completion time was measured in wall-clock seconds from the moment a request was sent until the final response came back.
Be the first to comment
Your email address will not be published. All fields are required.