pytrends Is Dead: A Google Trends API Alternative That Actually Works

If you just ran the first example from pytrends' own README and got a 429 Too Many Requests error, you haven't been rate-limited. You've run into a library that stopped working two years ago and nobody fixed it, and you're now looking for a Google Trends API alternative that actually works.

pytrends was archived by its maintainer on April 17, 2025. The repository is read-only now: a banner says so at the top of the page, next to an open issue asking for anyone willing to take over maintenance. The library wraps Google Trends' internal, undocumented API, and when Google changed its consent flow sometime after that, nothing was left to patch the fix in. The error isn't Google blocking you for scraping too much. It's pytrends never acquiring the NID cookie that the current flow expects, so every request looks malformed before it even leaves your machine. Scrapfly's own September 2026 test found the interest_over_time and related_queries calls still working that day, but all three of the trending-search methods returning a flat 404, because Google moved that endpoint entirely. Results vary by the week you test, which is itself the problem: a library with no maintainer can't tell you which parts still work.

This post is for anyone who had pytrends in a requirements.txt file and is now deciding what replaces it. Three real paths exist if you want to patch this yourself or pay someone else to, and one maintained option, Wire's own google_trends actions, that skips the patching entirely. Here's what each one actually costs you, starting with the two that don't involve a vendor at all.

Path 1: fix the session yourself

The actual bug is narrow enough to patch by hand. One writeup shows the same endpoint pytrends fails on returning a clean 200 once the NID cookie is warmed correctly first, about 15 lines of request code, no library required. trendspy, a maintained alternative on PyPI, handles that cookie exchange out of the box and also reaches the newer trending-search surface that pytrends can no longer see.

Both options work today. Neither comes with a warranty. Google doesn't publish this API, it's the same JSON endpoint the Trends website itself calls, and the entire category of unofficial wrapper breaks again the moment Google's frontend team changes a cookie name or a request shape without telling anyone. That's exactly what killed pytrends the first time.

Path 2: apply for Google's own alpha

Google announced an official Google Trends API in alpha in July 2025, open to researchers, journalists, and developers through an application form. It's a real improvement in one specific way: the numbers it returns are consistently scaled across requests, which the public Trends website and every unofficial wrapper are not. Ask the same keyword twice on the public UI and the 0-100 index can shift, because it's rescaled against whatever else happened to be in that batch.

It comes with three limits worth knowing before you apply. Access is gated and granted on a rolling basis, so not every applicant gets in, and not immediately. Data lags by roughly 48 hours. And it doesn't cover trending-now search, only the historical interest-over-time and regional surfaces. If your use case needs real-time trending topics, the alpha API can't do it even once you're approved.

Path 3: pay someone else to maintain the wrapper

This is the most crowded shelf in the whole space, and crowded in a way that's itself a signal. A search for "Google Trends scraper" on Apify alone turns up more than half a dozen competing actors for what is, underneath, the same undocumented endpoint everyone is calling, priced anywhere from $0.49 per 1,000 results to $5 per 1,000 keywords depending which one you pick. One of the mid-priced options is literally named "Reliable, Never Charges for Empty Runs", and its own README addresses "a recurring complaint from competitor reviews: ran for 20 minutes, didn't return anything." That's not a hypothetical reliability pitch; it's a vendor responding directly to how often the category burns people. Scrapfly, SerpApi, DataForSEO, and Bright Data all sell the same underlying data as a managed line item too, each with its own pricing and its own SLA, separate from whatever else you're already paying for scraping infrastructure.

Apify's own official actor for this, not a third-party one, has pulled 14,800 users at $0.30 per 1,000 results and counting, which says more about how much demand pytrends breaking created than about how good any single option is. None of that is Wire. Wire isn't a solo actor published by an anonymous Apify account, hoping you don't read the one-star reviews first. It's one maintained action inside infrastructure Anakin already runs across 940+ sites, billed and supported the same way as everything else you call through it.

What you're actually trying to get

Strip away the plumbing and nearly every pytrends use case reduces to five data shapes: how interest in a keyword moved over time, how that breaks down by country or city, what else people search alongside it, what's trending right now, and the category taxonomy Trends uses to scope all of the above. pytrends covered these with interest_over_time(), interest_by_region(), related_queries(), trending_searches(), and categories(): the exact five, under different names.

Wire's catalog carries a maintained google_trends action set that covers the same five, plus two more: a direct multi-keyword comparison and keyword autocomplete with topic-entity IDs attached (useful if you need to disambiguate "jaguar" the car from "jaguar" the animal before you pull a trend line).

None of it needs a cookie you have to warm, a session you have to keep alive across requests, or a GitHub issue to check before you deploy. It's one action in a catalog you're probably already calling for something else: Wire covers 940+ sites behind the same contract, so this isn't a second vendor relationship, it's seven more rows in a table you already have access to.

Calling it

Every Wire action runs through the same two-step async pattern: submit the task, poll for the result.

curl -X POST https://api.anakin.io/v1/wire/task \
  -H "Authorization: Bearer $ANAKIN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "action_id": "gt_interest_over_time",
    "params": {
      "keyword": "pytrends",
      "timeframe": "today 12-m"
    }
  }'

{
  "status": "processing",
  "job_id": "7c3f1a2b-4d5e-6f7a-8b9c-0d1e2f3a4b5c",
  "poll_url": "/v1/wire/jobs/7c3f1a2b-4d5e-6f7a-8b9c-0d1e2f3a4b5c"
}

Poll the poll_url until status flips to completed:

curl https://api.anakin.io/v1/wire/jobs/7c3f1a2b-4d5e-6f7a-8b9c-0d1e2f3a4b5c \
  -H "Authorization: Bearer $ANAKIN_API_KEY"

Here's what that specific call actually returned when we ran it while writing this post, interest in the keyword "pytrends" itself over the last 12 months (the real response has 53 weekly points, trimmed here to the ones that make the point):

{
  "status": "completed",
  "data": {
    "keyword": "pytrends",
    "geo": "worldwide",
    "timeframe": "today 12-m",
    "data": [
      { "formatted_date": "Apr 5 – 11, 2026", "value": 90, "is_partial": false },
      { "formatted_date": "May 31 – Jun 6, 2026", "value": 100, "is_partial": false },
      { "formatted_date": "Aug 23 – 29, 2026", "value": 0, "is_partial": false },
      { "formatted_date": "Sep 20 – 26, 2026", "value": 0, "is_partial": false },
      { "formatted_date": "Oct 4 – 10, 2026", "value": 3, "is_partial": true }
    ]
  },
  "credits_used": 3,
  "execution_ms": 12463
}

Worldwide interest in the term "pytrends" peaked the first week of June 2026, then fell to zero for five straight weeks from late August into September: people stopped searching for a tool once it stopped being worth searching for. That's not a hypothetical about why this post exists. It's the same action returning the literal data that proves the premise, pulled live, not reconstructed from a cached dashboard.

The related-queries action makes the same point from a different angle. Querying gt_related_queries for "google trends api" right now surfaces "google trends api python" as a top-associated query and "api design principles" as a breakout riser: real people hitting the same wall mid-search, in real time, as this post goes up.

What it costs

There's no separate subscription here. Wire actions draw from the same credit pool as every other Anakin product: the 300 one-time credits on the free Starter tier, or the metered tiers above it (Scale: $100/mo for 100,000 credits). A single gt_interest_over_time call is 3 credits; the category tree lookup is 1. Credits deduct only on a completed job, so a failed or timed-out call costs nothing, the same success-only billing that applies across the rest of the catalog.

Where this leaves you

pytrends isn't coming back. Its maintainer said as much when they archived it, and the gap between "archived April 2025" and 908,810 PyPI downloads in the last month alone is exactly the kind of gap that keeps producing posts like this one. Patching the cookie flow yourself works until Google changes it again. The official alpha API is the most durable long-term answer if you can get in and don't need trending-now data. Paying a single-purpose scraper vendor works, but you're now tracking uptime and pricing changes on a second tool.

Wire's google_trends catalog is the option built to actually last: the same data, inside infrastructure you already run other sites through, with no cookie logic for you to maintain when Google changes the underlying flow again, and it will. That becomes Wire's maintenance burden, not yours, which is the difference that matters once you've read the first three paths above. Browse the full catalog or jump straight to the Wire API reference to see every action's exact parameter schema before you wire it in.

This isn't the only Google-adjacent API that quietly stopped being a safe default this year. The Custom Search JSON API's own shutdown followed the same arc: works fine for years, then closes to new usage with limited warning. Worth a read if you're auditing what else in your stack depends on an undocumented or soon-to-sunset Google endpoint.

FAQ

What's the easiest replacement for pytrends?

Wire's google_trends catalog, if you don't want to maintain cookie-handling code yourself. It covers the same five core methods pytrends had (interest over time, regional breakdown, related queries, trending searches, the category tree) plus keyword comparison and autocomplete, billed from the same Anakin credit pool as everything else on the platform and maintained the same way Wire's other 940+ site actions are. Patching pytrends' session bug yourself or applying for Google's alpha API both work too, but neither is maintained for you the way Wire's catalog is.

Is pytrends completely broken, or does it sometimes still work?

It's inconsistent, not uniformly dead. Some calls succeed depending on the day and your IP's cookie state; the trending-search methods return a hard 404 because Google moved that endpoint. Treat any pytrends call in production as unreliable rather than debugging it as a configuration problem on your end.

Does the official Google Trends API alpha replace pytrends entirely?

Not yet. It covers interest-over-time and regional data with consistently scaled numbers, but access is application-gated with no guaranteed approval timeline, data lags about 48 hours, and it has no trending-now surface at all.

Is Google Trends data actual search volume?

No. On the public site, the alpha API, and every unofficial wrapper including Wire's, it's a relative interest index (0-100) scaled against the time range and region you query, not an absolute query count. Nothing in this category, free or paid, publishes true search volume.

What does trendspy fix that pytrends doesn't?

It handles Google's current cookie-based session requirement correctly and reaches the newer trending-search surface. It's still an unofficial wrapper around the same undocumented endpoint, so it carries the same long-term maintenance risk pytrends did.

How much does Wire's Google Trends action cost per call?

3 credits for interest-over-time, interest-by-region at 2, related queries and comparison at 3 each, trending searches at 2, suggestions at 3, and the category tree at 1. All billed from the same Anakin credit pool as every other Wire and URL Scraper call, deducted only on success.