&num=100 was a short string you could add to a Google search address to get up to 100 organic results on one page instead of the usual 10. Since September 2025 it no longer works. Pulling positions 1 to 100 now takes ten page fetches where it used to take one.
Optimizely's field notes and Logical Position's retirement note describe it the same way: a simple parameter that let a tracker load the top 100 with a single request. Removal notes from Botify, Seobility, and several agencies date the change to the same month.
What the &Num=100 Parameter Was
A Google results page normally shows 10 organic listings, the unpaid results. With &num=100 at the end of the search address, Google returned up to 100 on the same page.
That made deep data cheap. Rank trackers, the tools that record where pages sit for a keyword (the removal coverage names Semrush and Ahrefs as the typical examples), and scrapers, code that requests the results page and reads its HTML, both relied on it. One request returned the whole top 100, and with it the full competitive picture for a keyword.
What Google Removed, and Why
Google deprecated the parameter in September 2025. Queries now return the standard 10 results per page, and deeper data means paging through, one request per page.
The removal coverage gives three reasons: improving server efficiency, blocking mass scraping, and matching how people actually search, since ordinary users rarely look past the first page or two. The first two explain the timing. The third explains why the change is unlikely to be reversed: Google has little reason to serve 100 results to a human who reads ten.
What One Request Becoming Ten Means
Optimizely's field notes put the invoice version in one line: what used to take one server request now takes ten, multiplying bandwidth, processing, and API costs across the board.
The same notes describe the transition. Rank reports showed temporary data blackouts, missing positions, and phantom rankings while platforms adapted, which made client reporting unreliable for a while. And some tools absorbed the cost by tracking less, cutting default depth from 100 positions to 50 or 20.
That last change matters even if you never touched the parameter yourself. If your rank reports quietly got shallower after September 2025, this is probably why. A keyword that used to show at position 64 may now simply show as not ranking.
What to Do with Reports from Before the Change
A rank history that spans September 2025 has a seam in it. Positions beyond your tool's new default depth were measured before the change and are simply absent after it, which can read as a sudden collapse that never happened.
Mark the date in any report that crosses it. Compare positions only within the depth both periods measured, usually the top 20. And if a client or a manager asks why dozens of keywords "dropped out" that autumn, check whether they dropped or whether the tool stopped looking that far down.
It Did Not Die Overnight
The usual story is that &num=100 died in a single day. People who scrape for a living tell a slower one. In a public thread about SERP APIs, they describe the workarounds being shut down one by one over time, not all at once, and the same hardening now arriving around goto links, the redirect wrapper Google put in place of direct destination addresses in its result HTML. The cost effect is the same each time: a results page that used to be one request becomes several.
The practical lesson is to budget for a sequence, not a single event. Assume the next closure will add requests the way pagination did, and keep enough margin that it does not break your plan.
How to Budget Depth Now
Count pages, not keywords. The arithmetic is simple, and the full version with queue, live, and per-thousand pricing is in how to calculate SERP API cost per 1,000. In short: every ten positions of depth is one more page fetch per keyword, per location, per check.
A worked example shows how quickly that adds up. Say you track 200 keywords in three cities, checked once a week:
| Depth | Pages per keyword | Fetches per week | Fetches per month |
|---|---|---|---|
| Top 10 | 1 | 600 | about 2,600 |
| Top 20 | 2 | 1,200 | about 5,200 |
| Top 50 | 5 | 3,000 | about 13,000 |
| Top 100 | 10 | 6,000 | about 26,000 |
Before September 2025, the top-100 row cost the same as the top-10 row. Now it costs ten times as much, and daily checks multiply every row by seven.
Which Depth for Which Job
Most work does not need 100 positions. Set depth by the decision it feeds.
- Tracking your own rankings. The top 20 covers every position that sends meaningful traffic, plus the page-two terms you are trying to move up.
- Watching competitors. The top 20 to 30 shows who is closing in on you. Deeper positions are mostly pages that will never matter for the keyword.
- Researching a new niche. One deep pull of 50 to 100 on a handful of seed keywords, once, shows the whole field. There is no need to repeat it weekly.
- Catching sudden drops. A shallow daily check of the top 10 costs little and shows a fall out of page one the day it happens.
If you pay per page, confirm how the endpoint you use bills before modeling depth 20, 50, or 100 as separate budget lines; some providers charge each page as its own unit.
Keep full depth only where movement outside the top ten changes what you ship, and model those keywords at ten fetches each from the start. Everything else runs cheaper, and usually better, as a shallow check done often: a fall from position 8 to 15 shows up the next day at depth 20, while a weekly depth-100 pull can miss it for a week.
