"Poisoned results" have become one of the most talked-about problems in Google scraping. The idea: instead of blocking an automated client, Google quietly serves it a normal-looking results page for a different query. No captcha, no error code - just wrong data that slides into your dataset.
We had been collecting Google results for a while for our own benchmarks, so we went back through about 10,000 results pages, gathered through real Chrome browsers and around 160 residential proxy IPs, to see what poisoning looks like in practice. Three things stood out.
1. Poisoning is real, but it is not random noise
It happened. On one proxy IP, after a few normal searches, Google started answering with pages that had nothing to do with the query:
- "how to set up a fish tank" returned Oracle, Mozilla and Wikipedia pages
- "best coffee makers under 100" returned Under Armour's store and a dictionary entry for "under"
- "mortgage calculator with taxes" returned generic calculator sites
Two things about it are worth knowing.
It is rare. About 0.3% of all the pages we looked at were poisoned, and all of them came from a single proxy IP. On US proxy IPs we did not see it at all.
It sticks to an IP. Once that proxy IP started getting junk, it kept getting junk for dozens of searches in a row. Poisoning looked like a state the IP was put into, not a coin flip on each request.
That second point is what makes it catchable.
2. How to tell a poisoned page from a normal one
The tell is simple: on a poisoned page, almost no result title contains the words you searched for. On a normal page, most of them do.
We measured it as the share of result titles that carry at least half of the query's meaningful words (after dropping words like "how", "to", "best"). On normal pages this was usually 80-100%. On poisoned pages it was mostly 0-10%.
The catch is that about 1% of perfectly normal pages also score low. Brand queries are the typical case: titles say "Costco" and "Costco Wholesale" but not "what time does Costco open". Local queries answered with business names do the same.
So a single low page proves nothing. Three low pages in a row on the same proxy IP do. Across the whole dataset, that rule flagged exactly one proxy IP, the poisoned one, and nothing else. When it fires, the fix is cheap: drop the IP and ask the same query again on a fresh one. And since the check runs on a page you already downloaded, it costs no extra requests.
3. There is no such thing as "the" Google results page
While checking for poisoning, we compared the same queries across several sources: our own browser, five commercial SERP APIs, and repeated requests to each.
Take the top 10 result domains for a query and compare two sources. The overlap between any two of them averaged only 26-56%. Even a single API asked the same question twice, minutes apart, agreed with itself only 38-77% of the time.
Two browser searches from the same proxy IP at the same moment, on the other hand, matched 97%.
The difference is location. Google's US results depend heavily on which city the request appears to come from and when it is made. Two sources that use different IPs are, in effect, asking two different Googles.
The practical takeaway: if you compare rankings across tools or days, keep the proxy location fixed, or you will be measuring geography, not ranking changes. And "my results don't match what a SERP API returns" is not by itself a sign that either one is wrong.
Two smaller observations from the same comparison:
- AI Overviews are now the norm. For everyday queries, Google showed an AI Overview on most pages. Two of the five APIs we tried did not return it at all.
- Map places show up on a small share of queries, mostly ones with "near me" or a city in them.
4. Do you need a browser for every page?
A real browser is the most reliable way past Google's checks, and also the most expensive: every page pulls scripts, images and fonts, and on residential proxies you pay for every byte.
We tested a hybrid: let the browser pass Google's checks, then fetch results pages directly over HTTPS with the browser's own cookies and headers, falling back to the browser whenever Google asks again. We ran 300 side-by-side pairs, the same query through the browser and through HTTPS on the same IP. The results were not identical - the top 10 overlapped 86%, against 97% for two browser searches - but they were just as good: the same number of results, equally relevant titles, and the same AI Overview every time.
What it saved:
| Browser for every page | Hybrid | |
|---|---|---|
| Traffic per search | 0.8 MB | 0.4 MB |
| Time per search | ~9 s | ~1.4 s |
The tool behind the numbers
All of this was collected with Google Browser Scraper, an open-source tool we maintain. Version 0.1 ships both findings: hybrid mode is on by default, and the three-in-a-row poisoning check drops affected proxy IPs automatically. It runs as a CLI, a Python library, a local SERP-style API, or an MCP server for AI agents, and returns JSON with organic results, "People also ask", AI Overview and map places.
pip install google-browser-scraper
patchright install chromium
google-browser-scraper search "best running shoes" \
--proxy "http://USER-session-{session}:PASS@gate.example.com:7000"
It works with any residential proxy that supports sticky sessions. It has built-in support for NodeMaven, and the code GOOGLENM gives new accounts 2 GB of free traffic.
If you have seen poisoned results yourself, especially on non-US IPs, we would like to hear what they looked like.
Top comments (0)