Google Trends Scraper with Top and Rising Searches

Google Trends Scraper with Top and Rising Searches

Scrape Google Trends' interest-over-time curve for your keywords — exactly like the base scraper — and get Google's own related-search lists for each keyword: the phrases people search most (Top) and the phrases whose search volume is growing fastest (Rising, where Google's own "Breakout" label shows up). Filter to only Breakout phrases, choose either list, or cap how many phrases come back.

This is a variant of the base Google Trends Scraper actor. Every base input field and output field still works exactly as before; this variant adds the related-search lists on top.

---

What it does differently from the base scraper

The base actor calls Google Trends' interest_over_time endpoint only — it never sees the "Related queries" panel that Google's own Trends UI shows next to every keyword. This variant adds that second call per keyword: Google's relatedsearches widget, read from the same explore-token handshake Google's UI uses internally.

• Top & Rising related searches — for each individual keyword in your search terms (or in an isMultiple comparison group), pulls up to 25 of the most-searched phrases and up to 25 of the fastest-growing phrases, each with Google's own value, formattedValue and Trends explore link.
• Breakout filter — onlyBreakoutQueries keeps only Rising phrases where Google itself printed the literal string "Breakout" in formattedValue (a jump too large for Google to express as a percentage) — never a percentage or threshold we compute.
• Choose which list — relatedQueriesType returns Top only, Rising only, or both (default). The list you don't ask for still appears as an empty array, so the output shape never changes between runs.
• Cap list size — maxRelatedQueries (1–25) caps each list. Google's own ceiling is 25 per list, so 25 is the practical maximum either way.
• Related topics, best effort — includeRelatedTopics (off by default) also asks Google for related topics (entities, not phrases) on the same widget family. Measured across multiple keywords/regions/time windows, Google's RELATED_TOPICS widget consistently returns an empty list for automated requests — so this is shipped defensively: relatedTopics stays null unless Google actually returns something. The Top/Rising query lists above are the reliable deliverable.

Never fabricated: every phrase, score and link in relatedQueries/relatedTopics is read verbatim from Google's own JSON response (default.rankedList[0] = Top, default.rankedList[1] = Rising). Nothing is computed, ranked, or estimated by this actor. If the fetch fails for a keyword (rate limit, no data), that keyword's list comes back empty rather than guessed.

---

Input

All 15 base fields still work unchanged (searchTerms, isMultiple, timeRange, geo, viewedFrom, skipDebugScreen, startUrls, spreadsheetId, category, maxItems, customTimeRange, maxConcurrency, maxRequestRetries, pageLoadTimeoutSecs, proxyConfiguration). New fields:

{
  "searchTerms": ["coffee"],
  "timeRange": "today 12-m",
  "geo": "US",
  "includeRelatedQueries": true,
  "relatedQueriesType": "both",
  "onlyBreakoutQueries": false,
  "maxRelatedQueries": 25,
  "includeRelatedTopics": false
}

New field reference

• includeRelatedQueries (boolean, default true) — pulls the Top and Rising related-search lists for every keyword. Turn off to skip the extra request entirely and get only the base's interest-over-time output.
• relatedQueriesType (string enum, default "both") — "both", "top", or "rising". Picks which list is populated; the other list is still present in the output, just empty.
• onlyBreakoutQueries (boolean, default false) — keeps only Rising phrases Google labelled "Breakout" in its own formattedValue. Applied before maxRelatedQueries.
• maxRelatedQueries (integer, default 25, 1–25) — how many phrases to keep in each list, applied after the Breakout filter.
• includeRelatedTopics (boolean, default false) — best-effort related-topics fetch. Off by default because Google reliably returns an empty list for this surface; see above.

Unchanged base fields: searchTerms, isMultiple, timeRange, geo, viewedFrom, skipDebugScreen, startUrls, spreadsheetId, category, maxItems, customTimeRange, maxConcurrency, maxRequestRetries, pageLoadTimeoutSecs, proxyConfiguration — all read and behave exactly as in the base actor, including the three fields that are accepted but do nothing in the base code (skipDebugScreen, maxConcurrency, pageLoadTimeoutSecs — inherited from the base, unchanged here).

---

Output

One record per keyword group, exactly as the base produces it, plus relatedQueries and relatedTopics. Real example from a live run (searchTerms: ["coffee"], geo: "US"):

{
  "inputUrlOrTerm": "coffee",
  "searchTerm": "coffee",
  "timeRange": "today 12-m",
  "geo": "US",
  "category": "0",
  "interestOverTime_timelineData": [
    { "date": "2025-08-17", "coffee": 68 },
    { "date": "2025-08-24", "coffee": 71 }
  ],
  "relatedQueries": {
    "coffee": {
      "top": [
        { "query": "coffee shop", "value": 100, "formattedValue": "100", "hasData": true, "link": "/trends/explore?q=coffee+shop&date=today+12-m&geo=US" },
        { "query": "coffee near me", "value": 87, "formattedValue": "87", "hasData": true, "link": "/trends/explore?q=coffee+near+me&date=today+12-m&geo=US" }
      ],
      "rising": [
        { "query": "how to remove coffee stain from carpet", "value": 7250, "formattedValue": "Breakout", "link": "/trends/explore?q=how+to+remove+coffee+stain+from+carpet&date=today+12-m&geo=US" }
      ]
    }
  },
  "relatedTopics": null
}

Field reference

• inputUrlOrTerm, searchTerm, timeRange, geo, category, interestOverTime_timelineData — unchanged base output, same values the base actor would produce for the same input. (geo shows the literal string "worldwide" when no geo is set; category is always a string.)
• relatedQueries (object, keyed by each individual keyword in the group) — {"top": [...], "rising": [...]} per keyword. Each item carries whatever subset of query, value, formattedValue, hasData, link Google's own response included (Top items normally carry hasData, Rising items normally don't). Present as {} when includeRelatedQueries is off.
• relatedTopics (object or null) — same {"top": [...], "rising": [...]} shape as relatedQueries when Google actually returns topic data; null when includeRelatedTopics is off or Google's response is empty for every keyword (the expected outcome — see above).

For an isMultiple comparison group (e.g. "coffee, tea" with isMultiple: true), relatedQueries carries one entry per keyword in the group — relatedQueries.coffee and relatedQueries.tea — mirroring how interestOverTime_timelineData keys each row's value by keyword.

---

Notes

• Related-search data is read from the same Google Trends explore-token handshake the Trends website itself uses (trends.google.com/trends/api/explore → .../widgetdata/relatedsearches), via one extra request per keyword. It uses the same proxy tier as the base's interest-over-time call for that run — no separate proxy setup.
• A failed related-search fetch for one keyword (rate limit, no data) logs a warning and leaves that keyword's lists empty; it never fails the row's base interest-over-time data.
• Google's related-topics surface has consistently returned an empty list for automated requests during testing. includeRelatedTopics is shipped for completeness and stays off by default.