The n100 Google update: why rank tracking just got expensive

The “100 results per page” hack is dead.

For 15 years, SEOs, data scientists, and rank tracking tools relied on a simple, undocumented URL parameter: &num=100.

By appending these eight characters to a Google search URL, you could bypass the standard pagination limit and retrieve the top 100 results in a single HTTP request. Fast, cheap, and the foundation of almost every SEO tool on the market.

In September 2025, Google quietly killed it.

The so-called “n100 Google update” didn’t change the ranking algorithm or penalize sites. It changed the access mechanism, and in doing so threw the SEO software industry into chaos. The reckoning will likely bankrupt smaller tools and push enterprise platforms to double their prices.

This guide breaks down the n100 Google update end to end. You will see what changed at the URL level, why Google pulled the parameter, and the exact math that turned one request into ten. We also cover how it corrupted Search Console impressions and the pagination tactics that keep rank data accurate.

If your rank tracker has been acting weird since September 2025, showing “Not Found” for keywords you know you rank for, flashing volatile “Average Position” metrics, or suddenly introducing strict credit limits, this is why.

What was the n100 Google update?

The “n100 Google update” wasn’t an update in the traditional sense (like a Core Update or a Spam Update). It was an infrastructure change on the Google Search frontend.

Pre-September 2025, a developer could send a GET request to google.com/search?q=keyword&num=100. Google’s server would return a single HTML document containing rankings 1 through 100. That meant:

• 1 proxy request.
• 1 CAPTCHA challenge (maybe).
• 1 HTML parse.

Post-September 2025, Google ignores the &num=100 parameter entirely when you send that same request. It redirects you (302) or serves the standard 10-result page.

To get the top 100 results now, a scraper must:

1. Request Page 1 (start=0).
2. Parse the pagination token.
3. Request Page 2 (start=10).
4. …Repeat until Page 10 (start=90).

This sounds like a minor annoyance. It’s a 10x multiplication of effort.

Why the &num=100 parameter mattered

The n100 Google update stings because &num=100 was never an official, documented feature. It was a quirk of the results page that the entire tooling industry quietly standardised on. Nearly every major rank tracker, and hundreds of smaller ones, built their crawlers around that single call.

A one-request-per-keyword model is cheap, fast, and easy to reason about. A ten-request-per-keyword model is none of those things. That single change in access is why the fallout has been so wide and so expensive.

Why Google did it: The AI scraping war

Google didn’t do this to annoy SEOs, or to stop you from checking if you rank #1 for “best pizza in austin.” They did it to starve the AI crawlers.

In 2026, the most valuable commodity on the internet is training data. Large Language Models (LLMs) like GPT-5, Claude 3, and Llama 4 need massive amounts of fresh data to understand “current events” and maintain their factual accuracy.

The &num=100 parameter was the most efficient way for these AI companies (and the scraping armies that feed them) to harvest Google’s index. It allowed them to grab high-density lists of relevant URLs without “clicking” through pages and pages of ads.

Killing the parameter achieved three strategic goals for Google:

1. Increased latency. Scraping 100 results now takes 10x longer. Real-time RAG (Retrieval Augmented Generation) systems that rely on scraping Google are noticeably slower.
2. Increased cost. Proxy costs for scrapers have exploded. A query that cost OpenAI $0.01 to scrape now costs $0.10. At the scale of billions of queries, this destroys margins.
3. Protected ad revenue. Bots and scrapers have to load 10 pages (and 10 sets of ads) to see the deep results. Even if they don’t click, they register impressions.

It’s a defensive moat. If you want to build a search engine on top of their search engine (like Perplexity), you’re going to pay a heavy tax. Seen this way, the n100 Google update is less an SEO story than a front in the platform war over training data.

The mathematical impact: 1x vs 10x

Our analysis models the unit economics of the n100 Google update for a typical data provider. This explains why your favorite “Lifetime Deal” SEO tool is about to send you an email about “pricing adjustments.”

The cost of tracking 10,000 keywords per day:

Metric	Old Way (&num=100)	New Way (Pagination)	Impact
Requests per keyword	1	10	10x Load
Proxy Bandwidth	100 KB	1.2 MB	12x Data
Time to Complete	~2 seconds	~15-20 seconds	8x Slower
Ban Rate	Low (1 hit)	High (10 hits)	Exponential Risk
CAPTCHA Cost	$0.002	$0.02	10x Cost

Most budget rank trackers operate on razor-thin margins. They rely on cheap residential proxies and high efficiency. When the n100 update hit, their operational costs didn’t go up by 20% or 30%. They went up by 900%.

This forces them to choose between three options:

1. Raise prices and pass the 10x cost to you.
2. Reduce depth: stop tracking Top 100, only track Top 20.
3. Go out of business.

Option #2 is happening everywhere. Tools that used to give you deep insights are silently capping their crawl depth at Page 2. In effect, the n100 Google update reset the entire industry’s cost floor overnight, and users are footing the bill.

The technical fallout: a developer’s nightmare

If you’re a developer building internal tools or scrapers, you need to rewrite your collection logic.

The old Python logic:

# The good old days
def get_rankings(keyword):
    url = f"https://google.com/search?q={keyword}&num=100"
    html = requests.get(url, proxies=proxy).text
    return parse_100_results(html)

The new Python logic:

# The headache of 2026
def get_rankings(keyword):
    all_results = []
    start = 0

    while start < 90:
        url = f"https://google.com/search?q={keyword}&start={start}"

        # 1. New Request
        response = requests.get(url, proxies=get_rotating_proxy())

        # 2. Check for bans/captchas
        if "CAPTCHA" in response.text:
             solve_captcha(response) # $$ Cost $$

        # 3. Parse just these 10 results
        results = parse_10_results(response.text)
        all_results.extend(results)

        # 4. Check if we actually have a "Next" button
        if not has_next_page(response.text):
            break

        # 5. Sleep to act human
        time.sleep(random.uniform(1, 3))

        start += 10

    return all_results

The new logic is longer, and it’s brittle.

Every extra request is another chance for a network failure, a proxy timeout, or a Google ban. If the request for Page 4 fails, do you retry? Scrap the whole batch? If you retry Page 4 with a new proxy, Google might serve you a different datacenter with slightly different rankings, corrupting your dataset.

Retry logic becomes a data-integrity problem

Pagination after the n100 Google update doesn’t just cost more requests. It quietly threatens the quality of your data. A single dropped page mid-crawl leaves you with a partial SERP that still looks complete.

Say Page 4 times out on one keyword. You now face a bad trade. Retry with a fresh proxy and you risk stitching together two inconsistent snapshots from different datacenters.

Skip the page instead, and positions 31 through 40 silently vanish from your report. Neither failure mode existed under the old model, where a single response was internally consistent by definition. The n100 Google update turned a clean data pull into an exercise in error handling.

How this breaks “Average Position”

The most dangerous consequence of the n100 update isn’t the cost. It’s the data integrity.

Many SEO reports rely on “Average Position” or “Visibility Score.” These metrics assume you have a complete picture of the SERP.

Say you track 1,000 long-tail keywords and usually rank around position #45 for many of them.

Pre-update, your tracker saw the Page 4 rankings and reported “Keyword A: Rank 45”. Average position: 45.

Post-update, your tracker (trying to save money) stops scraping after Page 2 (Rank 20). It reports “Keyword A: Not in Top 20” and assigns a default value of “100” or “NULL”. New average position: 100.

You walk into your Monday morning meeting. The chart shows your SEO visibility crashing by 60%. The CMO is screaming. “Did we get hit by a Core Update?” “Did the site crash?”

You didn’t lose rankings. You lost observability. Your pages are still sitting at #45, getting the same (low) traffic they always did. But your tool has gone blind to anything below the fold.

Ask your data provider explicitly: “What is your crawl depth post-n100? Are you still fetching all 10 pages?”

How the n100 Google update warped Search Console

The &num=100 parameter didn’t only feed third-party trackers. It also inflated the impression counts Google reported back to you inside Search Console.

Before September 2025, a single &num=100 fetch loaded results 1 through 100 in one page view. Google logged an impression for every one of those results, including the listing sitting at position #98 that no human ever scrolled to. Those synthetic impressions padded your reports for years.

When the n100 Google update landed, that padding disappeared overnight. Impressions fell, and average position often improved, because the deep, never-seen listings stopped being counted. The numbers looked alarming even though real visibility hadn’t changed.

The scale of the correction was industry-wide. In an analysis of 319 Search Console properties published by Search Engine Land, 87.7% of sites lost impressions and 77.6% lost unique ranking keywords after the parameter was removed. Short- and mid-tail terms took the biggest hit.

Read that carefully before you panic about a Q4 traffic drop. If your impressions cratered in September 2025 but clicks held steady, you didn’t lose visibility. You lost the phantom impressions the parameter had been quietly inflating all along.

Auditing your reporting after the n100 Google update

Before you rebuild any tooling, run a short audit on the numbers you already have. The goal is to separate real ranking changes from measurement artifacts.

Start with clicks rather than impressions across the September 2025 boundary. Clicks reflect real users, so they are largely unaffected by the parameter change. Impressions are the metric the n100 Google update distorted most.

Then re-baseline your average-position charts from October 2025 forward. Any trend line that straddles the update is comparing two different measurement systems. A sudden “improvement” usually means phantom impressions were removed, not that you climbed the rankings.

Finally, ask every third-party tool one blunt question. What is your crawl depth today, and did it change in September 2025? If the vendor cannot answer clearly, assume your deep-ranking data is now incomplete.

The economic ripple effect

The n100 Google update is bifurcating the SEO data market into three tiers.

The cheap tier relies on caching and shallow crawls. They serve data that’s 3-4 days old (cached) or limited to Top 10 results. Affordable but inaccurate.

The premium tier pays the “Google Tax.” They charge $200+ for what used to cost $50, but provide accurate, deep, daily data.

The DIY tier: companies bringing scraping in-house to control costs, only to realize that managing residential proxies and solving CAPTCHAs at scale is a full-time engineering job.

Adapting your scraping strategy

You cannot brute-force your way past the n100 Google update. Sending 10x more requests through the same proxies will just get you blocked 10x faster. You need to be smarter about which pages you fetch and which you skip.

1. Smart pagination (the “look ahead” heuristic)

Do not scrape Page 2 unless Page 1 indicates you might be on Page 2.

• Analyze the domains on Page 1. Are they authoritative (Wikipedia, Amazon) or weak (forums, spam)?
• If Page 1 is weak, your chance of ranking on Page 2 is higher. Crawl it. If Page 1 is solid, stop.
• If your domain isn’t on Page 1, is it worth paying to find it on Page 4? For most brands, if you aren’t in the Top 20, you’re invisible anyway. Stop paying to track Rank #85.

Look-ahead pagination is the single biggest cost lever after the n100 Google update. Fetch Page 2 only when the evidence justifies it, and you cut most of the added expense while keeping the rankings that actually convert.

2. Use high-efficiency endpoints

The URL parameter is gone for the standard frontend, but Google has other interfaces.

• Mobile Light: specialized endpoints for low-bandwidth devices sometimes return different structures.
• Images/News: vertical-specific searches sometimes still respect deeper pagination parameters.
• AI Overview: scraping the AI Overview endpoints can yield citation lists that function as a “Top 10” shortcut.

3. Shift to “share of voice”

The strategic pivot. Stop obsessing over Position #47. Start tracking Pixel Share of Voice on Page 1.

The n100 Google update forces us to admit a hard truth: the deep SERP doesn’t matter. In an era of AI answers and zero-click searches, users rarely go past result #5. Tracking result #88 was always a vanity metric. Now it’s an expensive one.

The cloro advantage

At cloro, we anticipated the n100 Google update before it shipped. We figured the war between Google and AI scrapers would close off open access, so we built the infrastructure differently.

1. Distributed agent network. We don’t use simple requests.get. We use a network of headless browsers that behave like real users. They click “Next,” scroll, and interact. That makes them immune to the &num=100 deprecation because they never relied on it.
2. Hybrid tracking. We give you the rank and the AI visibility. While other tools struggle to find your link on Page 4, we tell you if you’re being cited in the Google AI Overview or mentioned in the ChatGPT Search results.

The n100 Google update is a wake-up call. The era of cheap, infinite data is over. The web is becoming a walled garden, and you need tools that can climb the wall.