Google SERP Poisoning: How to Get Relevant Search Results With Fast Search

Google SERP poisoning is a problem that can make scraping search results less reliable. Instead of the results you'd normally expect, automated requests may return unusual or misleading search rankings. This can affect SEO monitoring, competitor research, and any workflow that depends on accurate search data.

But how serious is the problem, and what can we do about it? In this article, we'll explore how Google SERP poisoning works, look at findings from existing research, and see whether ScrapingBee's Fast Search API can help. I'll also share the results of my own week-long experiment, where I collected and analyzed Google search results to evaluate their relevance and stability.

What is Google SERP poisoning?

Google SERP poisoning occurs when automated search requests return misleading search results in which many of the websites normally associated with a query have been replaced. Instead of a familiar set of websites, a scraper might receive an unusual mix of pages, sometimes including results that barely relate to the original query.

Imagine you're scraping Google search results for "white label local SEO" to analyze competing services. You run your scraper, open the results, and find a local pizza restaurant, a burger joint, and a plumbing company.

Wait, what? Did Google lose its mind, or did your scraper break? Well, you might be looking at Google SERP poisoning.

The tricky part is that poisoned results don't necessarily look broken. Your scraper may complete the request successfully, return perfectly valid URLs, and extract titles and descriptions without a single error. Yet the data itself may be misleading.

And it isn't always as obvious as a burger restaurant showing up in an SEO search. Sometimes the results are still related to your query, but the usual websites have been replaced by a completely different set of domains.

That's why SERP poisoning matters for SEO rank tracking, competitor analysis, and other workflows built around scraped Google search results. If the data you're collecting doesn't reflect the search landscape you're trying to measure, even a technically successful scraping job can lead you to the wrong conclusions.

Is Google SERP poisoning actually happening?

Unfortunately, yes. And we're not talking about a handful of strange search results that someone spotted by accident.

In October 2026, the team at Nozzle published a detailed investigation into poisoned Google SERPs. They analyzed 29.9 million SERPs collected since September 13, 2026. Among approximately 4.7 million desktop SERPs evaluated on both pages, 22.6% showed signs of poisoning on page one or two. At the peak on September 30, that figure reached 43.5%.

One of their examples is particularly amusing, although probably not if you're running an SEO agency. When searching for "white label local seo," Nozzle initially received the expected results from SEO service providers. Three days later, the same query returned completely different websites, including a WordPress development tool, a steakhouse in Jackson Hole, and a directory of local health departments.

So yes, the steakhouse example wasn't far from reality after all.

But Nozzle uncovered something even more concerning. Poisoned SERPs didn't always contain obviously unrelated websites. Sometimes the results still addressed the search query, but the familiar domains had disappeared. According to their research, affected organic results retained just 22.3% of the previous SERP's websites, compared with 88.1% before the problem emerged.

This particular example illustrates a related problem: Google appeared to answer only the word "local" instead of the full search query. Nozzle distinguishes this behavior from SERP poisoning, where the results may still address the original query but the usual websites have disappeared.

And that's what makes Google SERP poisoning particularly troublesome for rank tracking. A scraper might report that a client's website has suddenly dropped out of the top results, when the apparent ranking change is actually caused by an unusual search response.

You can explore the examples, comparisons, and methodology in Nozzle's original research. Their findings also raise a practical question: can we still collect relevant Google search results reliably? That's what I wanted to investigate using ScrapingBee's Fast Search API.

How to scrape search results with Fast Search API

So, how can we collect search results without building and maintaining an entire scraping infrastructure?

One option is ScrapingBee's Fast Search API. It's a lightweight API that retrieves live search results and returns them as structured JSON, including titles, URLs, descriptions, and ranking positions. You don't need to manage proxies, solve CAPTCHAs, or parse search engine HTML yourself.

Fast Search is designed for workflows that need quick access to search data, from SEO monitoring and competitor research to AI applications. In our case, we'll use it to retrieve Google search results and later examine their relevance.

Getting started is straightforward. You'll need Python, the requests library, and a ScrapingBee API key. Install the dependency with:

pip install requests

Next, save your API key in the SCRAPINGBEE_API_KEY environment variable:

export SCRAPINGBEE_API_KEY="your_api_key"

or

$env:SCRAPINGBEE_API_KEY = "your_api_key"

You can find it in your ScrapingBee dashboard after creating an account.

Now create a file named fast_search.py:

import os

import requests

API_URL = "https://app.scrapingbee.com/api/v1/fast_search"


def main():
    api_key = os.getenv("SCRAPINGBEE_API_KEY")

    if not api_key:
        raise SystemExit("Set the SCRAPINGBEE_API_KEY environment variable.")

    params = {
        "search": "white label local seo",
        "country_code": "us",
        "page": 1,
    }

    try:
        response = requests.get(
            API_URL,
            params=params,
            headers={"Authorization": f"Bearer {api_key}"},
            timeout=30,
        )
        response.raise_for_status()
        data = response.json()
    except (requests.RequestException, ValueError) as exc:
        raise SystemExit(f"Fast Search request failed: {exc}") from exc

    results = data.get("organic", [])

    if not results:
        print("No organic results found.")
        return

    for result in results:
        rank = result.get("rank", "?")
        title = result.get("title", "Untitled")
        link = result.get("link", "")
        description = result.get("description", "")

        print(f"{rank}. {title}")
        print(f"   URL: {link}")
        print(f"   Description: {description}")
        print()


if __name__ == "__main__":
    main()

Run the script:

python fast_search.py

The script sends a GET request to the Fast Search endpoint with three parameters:

• search: The query we want to look up, in this case white label local seo.
• country_code: The country used to localize the results. We're using us, but you can switch to gb, ca, or another supported country code.
• page: The search results page to retrieve. We're starting with page one.

The API returns a JSON response containing an organic array. Our script loops through these results and prints each page's ranking position, title, URL, and description.

That's all we need to start collecting search data. If you want to experiment with other queries or countries, just change the request parameters. To learn more about the feature, check out our dedicated blog post: Fast Search API.

Want to try it yourself? Sign up for ScrapingBee for free and get 1,000 API credits with no credit card required. Each Fast Search request costs just 10 credits, so you can run up to 100 searches with your free credits. That's plenty to experiment with different queries, compare results across countries, and get a feel for the API before committing to a larger project.

How I tested Fast Search API for Google SERP poisoning

Now for the fun part. I wanted to see how Fast Search would perform in practice, particularly when retrieving Google search results for queries that might be affected by SERP poisoning. Rather than run a few searches and call it a day, I put together a small Python project to collect results repeatedly, evaluate their relevance, and track changes over time.

I ran the experiment from October 20 to October 27, 2026, using eight search queries across the US, Canada, and the UK. Some were taken from the examples discussed in Nozzle's research, while others were added to cover different search intents.

The queries included:

• SEO-related searches: white label local seo across three countries, plus what is local SEO as an informational control.
• Local business searches: jewellery buyers near me and gold buyers near me in Canada.
• Commercial service searches: personal injury lawyer in the US and emergency plumber in the UK.

This gave me a mix of informational, commercial, and location-sensitive queries. I deliberately included searches with different intents because SERP poisoning might not affect every type of query in the same way.

Collecting search results

I wrote a Python script that reads the queries from a CSV file and sends them to Fast Search API. Each request targets the first page of Google search results with a specified country code.

The script saves the original JSON responses without modifying them, along with timestamps, query details, HTTP status codes, and other metadata. This way, I could revisit any particular result later instead of relying entirely on the analysis output.

I repeated the collection process 15 times over the week, at different times of day. That produced 120 search result sets containing 1,075 organic results in total.

Learn more about scraping with Python in our dedicated tutorial.

Evaluating relevance with AI

Next, I needed to determine whether the returned results actually matched their search queries. Manually checking more than a thousand entries would have been rather tedious, so I used a local AI model to help. I ran Qwen3.5 9B through Ollama and asked it to evaluate each organic result using its title, URL, and description. The model assigned one of four labels:

• relevant: Directly answers the query or matches a reasonable search intent.
• partial: Related to the topic but missing an important part of the query.
• irrelevant: Clearly unrelated to what the user searched for.
• uncertain: Not enough information to make a reliable judgment.

I also asked the model to explain each classification, making it easier to inspect questionable decisions.

To keep the experiment consistent, I used the same model, prompt, and temperature setting of zero throughout all 15 runs. I also tested the classifier separately with synthetic search results containing deliberately unrelated pages to check whether it could recognize obvious mismatches. These synthetic results were excluded from the real-world statistics.

One important limitation: the model evaluated search snippets, not the full contents of the websites. It also judged topical relevance rather than geographical proximity. For example, a gold buyer in Toronto could be considered relevant to a Canadian search, even though we hadn't specified Toronto as the user's location.

Comparing search results over time

Finally, I wrote another Python script to compare consecutive runs for each query. The idea was simple: if a search returns ten websites today, how many of those same websites will appear the next time I run it? I tracked the percentage of previously seen hostnames that remained in the next result set, calculated Jaccard similarity between the two sets, and recorded changes in ranking positions.

I also flagged comparisons where fewer than 50% of the previous hostnames remained. These flags weren't automatic evidence of SERP poisoning. They simply identified unusual changes worth examining more closely. Unlike Nozzle's historical baseline approach, my comparison used consecutive runs rather than a long-term reference set, so these flags should be interpreted as indicators of instability rather than confirmed poisoning.

The comparison script then generated CSV and JSON reports summarizing relevance, ranking stability, and changes in the returned websites.

If you'd like to reproduce the experiment or explore the implementation, I've published the complete Python project on GitHub. It includes the query definitions, data collection script, Ollama-based relevance analyzer, and comparison tools.

With the setup explained, let's see what the results actually showed.

Fast Search API test results: What did I find?

After a week of collecting and analyzing Google search results with Fast Search API, I had 15 completed runs, 120 search result sets, and 1,075 organic results to examine.

So, did I encounter any poisoned search results? Let's look at what the data tells us.

Search result relevance

The first finding was encouraging: the AI classifier didn't identify a single irrelevant result across all 1,075 entries.

Here's the breakdown:

All eight queries returned results that Qwen3.5 considered either directly relevant or at least related to the original search.

For example, searching for white label local seo returned SEO agencies, white-label service providers, industry articles, and relevant discussions. Searches for gold buyers near me produced jewellery buyers, precious metal dealers, and directories of businesses offering these services.

I also reviewed the model's classifications and explanations, paying particular attention to results marked as partially relevant. These generally involved pages that addressed a broader topic or only part of the search intent.

It's worth emphasizing what these numbers mean, though. The AI evaluated titles, URLs, and descriptions rather than visiting every website. So the findings tell us about the apparent topical relevance of the returned results, not whether every page contained accurate or useful information.

Still, finding no obviously unrelated results across more than a thousand observations was a promising outcome.

Search result stability

Next, I examined how the search results changed between runs. This is where things got more interesting.

Across 112 consecutive comparisons, 39 were flagged for low host overlap. In other words, fewer than half of the domains from the previous search appeared in the next one.

Here are the average hostname retention rates for each query:

The differences are pretty striking. The US results for white label local seo were relatively stable, retaining an average of over 90% of their domains between runs. Meanwhile, what is local SEO, a straightforward informational query, had the lowest average retention rate at just over 40%.

I also found 16 consecutive comparisons where not a single domain appeared in both result sets.

That sounds alarming, but there's an important distinction: a dramatic change in search results isn't necessarily evidence of SERP poisoning. All the results in these comparisons were still classified as topically relevant.

An unexpected pattern: Completely different search results

One example stood out during the final days of testing. On October 26, a search for what is local SEO returned eight domains, including Semrush, Ahrefs, BrightLocal, Wikipedia, Mailchimp, and Yoast.

The following day, at 13:45 UTC, the same query returned an entirely different set of domains, including InMoment, LocaliQ, Quora, HubSpot, and DesignRush. Not one of the previous eight domains appeared.

Then, at 15:03 UTC, I repeated the query. And guess what? All eight domains from the October 26 search were back. This wasn't simply a matter of a few websites moving up or down in the rankings. The results switched between two distinct sets of domains, both of which appeared relevant to the query.

I observed similarly substantial changes for other searches, including personal injury lawyer and emergency plumber.

What caused these switches? I can't say for certain. The experiment wasn't designed to identify the underlying mechanisms responsible for changes in search results, so I don't want to speculate about their origin.

What matters for this study is that large changes in domain composition didn't necessarily correspond to a loss of topical relevance.

What do these findings tell us about SERP poisoning?

Based on the relevance checks, I didn't find any clearly off-topic results during the experiment. That's encouraging, especially given the concerns around Google SERP poisoning.

However, I wouldn't interpret this as proof that Fast Search prevents every form of SERP poisoning. My tests covered a limited selection of queries and countries, and the results weren't compared against a verified baseline of ordinary Google searches.

The stability analysis also revealed substantial variations in which domains appeared between runs. Those changes deserve attention, even when the individual results look relevant.

For now, the most useful takeaway is that Fast Search consistently returned topically relevant results throughout my week-long experiment, while the composition of those results was sometimes surprisingly unstable.

Limitations of the experiment

Before drawing any conclusions, it's worth keeping a few limitations of my testing approach in mind:

• Limited scope: I tested eight search queries across three countries over one week. While 1,075 organic results provided a useful dataset, different queries, locations, or testing periods could produce different outcomes.
• AI-based relevance analysis: Qwen3.5 evaluated titles, URLs, and descriptions rather than the full contents of each website. I reviewed the classifications and tested the model with deliberately irrelevant examples, but it could still have missed less obvious cases of SERP poisoning.
• No verified Google SERP baseline: I didn't compare the collected results against a verified set of regular Google search results. Without that reference, I couldn't determine whether unusual changes in domain composition were caused by SERP poisoning or other factors.
• Country-level targeting: The experiment used country codes rather than precise locations. This is particularly important for "near me" queries, where geographic relevance depends on the searcher's actual location.

These limitations don't invalidate the findings, but they do define what we can reasonably conclude. The experiment suggests that Fast Search can retrieve topically relevant Google search results under the tested conditions, without guaranteeing that every result will always be accurate or free from SERP poisoning.

Conclusion

Google SERP poisoning is a real concern for anyone relying on scraped search results. As Nozzle's research demonstrated, automated tools can encounter unexpected search rankings, making it harder to trust the data behind SEO monitoring, competitor analysis, and other workflows.

My experiment with ScrapingBee's Fast Search API produced encouraging results. Across 15 runs and 1,075 organic results, the AI-based relevance analysis didn't identify a single clearly irrelevant page. That's a promising outcome for anyone looking to collect useful Google search data.

At the same time, the experiment revealed something interesting: search results can change dramatically between requests without becoming less relevant. In some cases, entire sets of domains disappeared and later returned. That's a good reminder that topical relevance and ranking stability are two different things, and both deserve attention.

Does this mean Fast Search eliminates Google SERP poisoning? Not necessarily. My experiment was limited in scope, and I didn't compare the results against a verified Google SERP baseline. Still, the findings suggest that Fast Search can be a useful option for retrieving relevant search data.

If you're working with search results yourself, give ScrapingBee's Fast Search API a try. You can start with free credits, run a few queries, and see how the results hold up in your own workflow.

Frequently asked questions

What is Google SERP poisoning?

Google SERP poisoning occurs when automated tools receive unusual or misleading search results that differ significantly from what regular users would normally see.

Why is Google SERP poisoning a problem?

It can distort SEO rankings, competitor analysis, and other workflows that rely on accurate search data, potentially leading to incorrect conclusions and business decisions.

How can I detect poisoned Google search results?

Look for unrelated websites, unexpected ranking changes, or sudden drops in domain overlap between repeated searches. Comparing scraped results with regular Google searches can also help identify suspicious differences.

Does Google SERP poisoning affect all search queries?

Not necessarily. Its occurrence can vary depending on the query, location, timing, and how search results are retrieved.

Can ScrapingBee's Fast Search API help with SERP poisoning?

Fast Search returned topically relevant Google search results throughout my experiment, with no clearly irrelevant results identified by the AI classifier. However, this doesn't guarantee protection against every form of SERP poisoning.

Are frequent changes in Google search rankings a sign of SERP poisoning?

Not always. Search rankings change naturally, and even substantial differences between result sets don't necessarily indicate poisoning. Additional verification is needed.

How can I scrape Google search results with Python?

You can use ScrapingBee's Fast Search API with Python's requests library to retrieve structured search results without manually parsing Google's HTML.