pytrends Is Dead. Here's What Still Gets You Google Trends Data in 2026

If you pip install pytrends today and run the first example from its README, you get a TooManyRequestsError before you finish your coffee. Not after a hundred calls — on call number one. Search the issue tracker and you'll find hundreds of people hitting the same wall, and no one merging the fix, because the repository was archived by its owner on April 17, 2025 and is now read-only.

The reflex is to assume Google finally killed the unofficial Trends endpoint, or that your IP is blocked, and to go shopping for a paid API. We tested that assumption on July 22, 2026 — every route, live, from a normal residential IP — and it's wrong. The data is still there, still free, and the endpoint pytrends fails on returns a clean 200 when you call it correctly. pytrends didn't get blocked. It rotted.

First, proof: what pytrends does now

Let's not argue from screenshots. Here is pytrends 4.9.2 — the current and final release — installed fresh in a clean virtualenv and pointed at the two calls every tutorial opens with:

# pip install pytrends  (installs 4.9.2, last published April 13, 2023)
from pytrends.request import TrendReq

pt = TrendReq(hl="en-US", tz=360)
pt.build_payload(["python", "javascript"], timeframe="today 12-m", geo="US")
pt.interest_over_time()
# pytrends.exceptions.TooManyRequestsError:
#   The request failed: Google returned a response with code 429

pt.trending_searches(pn="united_states")
# pytrends.exceptions.ResponseError:
#   The request failed: Google returned a response with code 404

Two different failures, and the difference matters:

The 404 on trending_searches() is the one thing Google actually changed: the old daily-trends URL pytrends calls no longer exists. Everything else is a 429, and a 429 is not "you are banned" — it's "this request wasn't allowed as sent." That distinction is the whole story.

It's not your IP — it's the cookie

Google Trends' unofficial API works in two hops: a call to /trends/api/explore that hands back a short-lived widget token, then a call to /trends/api/widgetdata/multiline that uses the token to return the actual time series. pytrends does both. It 429s on the first hop.

So we replayed those exact two hops by hand, changing one variable at a time: whether we first loaded the Trends homepage (which sets an NID cookie), and whether we sent a browser User-Agent or the default python-requests one. Same IP, same endpoint, four combinations:

The result is unambiguous. With no cookie warm-up, both variants 429 on the very first request — even the token hop. With the homepage loaded first, both return 200 and the data comes back — and the User-Agent makes no difference at all; the plain python-requests default works fine. The single deciding variable is the NID cookie.

That's the diagnosis. pytrends' session bootstrap — the bit that's supposed to acquire that cookie before it starts making API calls — no longer matches Google's current consent flow, so it never gets the cookie, so every call is rejected. Nobody's fixing it because the repo is frozen. The endpoint, meanwhile, is completely healthy: warm the cookie and it answers on the first try.

The drop-in fix: trendspy

You don't have to hand-roll cookie handling. trendspy is a maintained library that targets Google Trends' current endpoints — including the new trending surface that pytrends 404s on. Latest release is v0.1.6 (December 2024), and in our tests it did the cookie dance correctly and returned data every time, seconds after pytrends had 429'd from the same machine.

# pip install trendspy
from trendspy import Trends
tr = Trends()

df = tr.interest_over_time(["python", "javascript"], timeframe="today 12-m", geo="US")
print(df.tail(1))
#             python  javascript  isPartial
# time [UTC]
# 2026-07-19      43           5      False

tr.trending_now(geo="US")      # -> 273 live trending topics, each with a
                               #    search-volume band, related keywords and a category
tr.related_queries("python")   # -> top + rising related queries
tr.suggestions("python")       # -> entity disambiguation (Google 'mid' + type)

That interest_over_time call is the same request that returns 429 through pytrends. Here it returns a full 53-week series. Plotted, the free data looks like this — a year of US search interest for two languages, collected with nothing but trendspy:

trendspy also brings back the trending feed pytrends lost: trending_now(geo="US") returned 273 live topics in one call, each tagged with a search-volume band and a category — the shape of a single item looks like [US] toluca - pumas: 100,000 searches, 12 related keywords, topics: Sports. If your only reason for reaching for pytrends was interest-over-time or trending, this is a one-line swap and you're done.

Two honest caveats. It's a smaller project (~115 stars) than pytrends was, so treat it like any unofficial client: pin the version, wrap calls in retries, and don't hammer it. And it's still riding the same unofficial endpoints — if Google changes them, trendspy needs an update too. That's the nature of every free Trends route, which is exactly why we also show you the raw calls next.

Or roll your own in ~15 lines

If you'd rather not add a dependency — or you want to understand the failure well enough to fix it yourself when an endpoint shifts — the whole thing is short. Warm the cookie, get a token, pull the series. This ran clean, twice, from the same IP that had just 429'd pytrends:

import json, requests

s = requests.Session()
s.headers["User-Agent"] = "Mozilla/5.0"   # any UA works; the cookie is what matters

# 1. Warm the NID cookie — the step pytrends no longer does correctly
s.get("https://trends.google.com/trends/?geo=US", timeout=20)

# 2. explore: get the widget token for the time series
req = {"comparisonItem": [{"keyword": "python", "geo": "US", "time": "today 12-m"}],
       "category": 0, "property": ""}
r = s.get("https://trends.google.com/trends/api/explore",
          params={"hl": "en-US", "tz": "360", "req": json.dumps(req)}, timeout=20)
widget = next(w for w in json.loads(r.text[r.text.find("{"):])["widgets"]
              if w["id"] == "TIMESERIES")

# 3. multiline: the actual data (the endpoint pytrends 429s on)
r = s.get("https://trends.google.com/trends/api/widgetdata/multiline",
          params={"hl": "en-US", "tz": "360",
                  "req": json.dumps(widget["request"]), "token": widget["token"]},
          timeout=20)
points = json.loads(r.text[r.text.find("{"):])["default"]["timelineData"]
print(len(points), "points; last:",
      points[-1]["formattedAxisTime"], "->", points[-1]["value"][0])
# 53 points; last: Jul 19, 2026 -> 42

Three things worth knowing before you build on this. Google prefixes these JSON responses with a )]}', junk line — that's the r.text[r.text.find("{"):] slice. The token from step 2 is short-lived, so fetch it right before you use it. And notice the last point reads 42 here but 43 in the trendspy run above: Trends rescales its 0–100 index on every request, so the same query minutes apart can wobble by a point. That's not a bug in either tool — it's a property of Trends, and it's the specific thing Google's official API is built to fix. More on that now.

Running this at any volume? Space the calls out and handle the inevitable 429s gracefully — the same discipline any Google endpoint needs, which we cover in how to fix "unusual traffic" 429s when scraping.

The official Google Trends API (and its catch)

Google announced an official Trends API in July 2025, and a year on it is still application-gated alpha, not general availability. You apply through a form; Google says it prioritizes developers with a concrete use case who can give feedback. If your project can wait on an approval you don't control, it's worth the application. Here's what you're applying for, from Google's own docs:

The headline feature is that "consistently scaled" line: unlike the website (and the unofficial endpoints), which re-normalize 0–100 on every request, the API scales consistently across requests so you can join and compare pulls — it fixes the exact 42-vs-43 wobble from the last section. The catch is what it still won't give you: it is not a search-volume feed, and today's alpha drops Trending Now entirely. If your use case is real-time trending topics, the official API can't serve it yet — trendspy or the raw calls can.

Paid options, if you'd rather not maintain a scraper

If Trends data is load-bearing for a product, you may not want a free, unofficial endpoint in your critical path. Several providers sell Google Trends data with their own infrastructure behind it. We did not independently benchmark these — the figures below are from each vendor's own pricing pages, read on July 22, 2026, and are here so you can compare orders of magnitude:

Note the split in what they sell. SerpApi, DataForSEO and Bright Data resell the same relative-interest data you can get free — you're paying for reliability, geo coverage and support, not for different numbers. Glimpse is the outlier: it layers an estimated absolute volume on top of Trends, which is a genuinely different thing and the natural segue to the last section.

A word on "search volume"

The single biggest misconception about Google Trends is that the numbers are searches. They aren't. Every route in this post — pytrends, trendspy, the raw calls, even Google's official API — returns a 0–100 relative interest index, where 100 is the peak of whatever window and keyword set you asked for. A value of 43 doesn't mean 43 anything; it means "43% of this series' own peak."

That's perfect for shape — seasonality, breakouts, is-this-rising-or-falling, A-vs-B — and useless if you need "how many people search this per month." For that you need an actual volume estimate, which is a different data source and a different technique; we walk through the honest options in estimating keyword search volume without Google Ads. Trends tells you the trend; it was never going to tell you the total.

FAQ

Why does pytrends return 429 errors in 2026?

Because the library is unmaintained, not because you were blocked. pytrends was archived on April 17, 2025 and its last release was 4.9.2 in April 2023. Its session bootstrap no longer acquires the NID cookie Google's current flow expects, so the first data call returns 429. We proved the endpoint still works: a hand-rolled request to the same URL returns 200 once the cookie is warmed.

Is pytrends still maintained?

No. GitHub shows it archived by the owner on April 17, 2025, now read-only. The last PyPI release is 4.9.2 (April 2023) and the README openly asks for new maintainers. It still has 3,700+ stars and 130+ open issues, but nothing is being merged.

What's the best pytrends alternative?

For Python, trendspy (v0.1.6, December 2024) is the maintained successor and worked in every test here. You can also roll your own in ~15 lines, apply for Google's official alpha API, or pay a provider like SerpApi, DataForSEO or Bright Data to skip maintenance entirely.

Is there an official Google Trends API?

Yes, but it's application-gated alpha as of July 2026 (announced July 2025). It returns consistently scaled interest across a rolling ~5-year window, but not absolute search volumes, and the alpha excludes Trending Now.

Can I get absolute search volume from Google Trends?

No. Trends — and the official API — return a 0–100 relative index, not raw counts. For volume-style numbers you estimate from another source; see our guide to estimating search volume without Google Ads.

Will scraping Google Trends get me blocked?

The endpoints are unofficial and rate-limited, so at volume you'll see 429s. Warming the cookie and spacing requests kept single queries working from a normal IP in our tests. For scale, use a maintained library with sensible delays or a paid API — and read our 429 troubleshooting guide.