BotGuard: what our tests reveal
about Google’s protections

Google results pages are more than a service: they reflect what the world is searching for, minute by minute. An entire industry measures its visibility through them. The protections documented on this page decide who gets to look.

What people search for is produced by the public. Today, a single company decides who may observe it.

In the controlled trials, refusal follows the native value of navigator.webdriver. With Chrome, machine and network held constant, results appear when this property is false, even with --enable-automation. When it is true, the browser is refused, even without that setting. The launch setting and the signal exposed to the page can therefore be distinguished experimentally.

The dividing line follows the automation declaration. IP alone cannot explain the differences: on both native IP and VPN, Camoufox obtains results where Chrome driven by Playwright is refused, and the same Chrome launched normally gets through on the native IP.

The launch setting or the signal exposed to the page?

The comparison crosses two factors: the presence of --enable-automation and the native value of navigator.webdriver. The four combinations are repeated in two randomly ordered blocks, with a fresh profile for each navigation. Two ordinary Chrome controls bracket the series and both display results.

The JavaScript getter remains native: the browser controls the value without replacing the property in the page. The Blink AutomationControlled feature is disabled in all four combinations; a CDP command sets the signal independently of the flag. Knitsail and the YouTube VM read this property (see observed reads). The result supports a causal role for the native signal in this environment, without revealing the server score or establishing a universal rule.

The decision comes right after the verification page

Flow in the flag-only test, without intervention on the native value:

On the observed fresh profiles, Google serves a verification page before reloading the search with the data produced by the check. Traces from the flag-only test place this reload about 0.2 seconds after the response. The main document then leads either to results or to /sorry and a 429 response. Classification uses the main navigation, the presence of results and screenshots; a background request to /sorry alone does not classify a navigation as refused.

In the controlled matrix, the presence of the flag does not distinguish outcomes; the native webdriver value does in all our trials. Accepted controls and unchanged IPv4 and IPv6 addresses limit an explanation based on a network change.

Two trials per combination, on one machine, network and query: these counts do not yield a generalisable success rate. A JavaScript replacement getter returning false was also refused, so that intervention is not a neutral control. Protocol and supporting controls: automation signal and Chrome settings.

With a fixed browser configuration and network exit, we compared copies of the same profile, retaining or deleting the NID cookie. The contrast repeats: retaining the session avoids the challenge; deleting NID brings it back.

Starting with a fresh profile or deleting cookies can reintroduce a check that the retained session avoided.

A returning challenge is not a failure: results also arrive after it. NID is associated here with a session effect; SG_SS carries a challenge result. These observations do not make NID a universal pass or measure how long SG_SS remains valid.

Same query, same IP, two lists with no URL in common. This contrast raises suspicion of result poisoning by Google: plausible pages could be served to an automated client with deliberately altered content.

Query: musée du Louvre site officiel

On October 18, 2026, the two searches start 2 minutes apart. The profiles are two copies of the same source profile; only NID differs among transmitted cookies. The branch retaining NID receives results directly; the other goes through a challenge.

Blue background: the official homepage, in French on the left and in English on the right. These are two distinct URLs.

0 target URLs shared between the 6 and 9 results. The second list highlights educational resources, press content, the school, the shop and ticketing.

Across the October 18 series, the Louvre homepage usually ranks seventh, less often first, and is sometimes missing from the main results. In the branches that keep NID, the pages where it ranks seventh record a Validate call, 8 to 10 seconds after the page was received. The displayed order is already set by then: on every page, the order received matches the final order.

Protection expands without a new BotGuard major version: an intermediate page, background checks, request retries, then in 2026 new browser tests and a module that keeps data from one visit to the next. Technical dates mark the first available observations in our corpus, not necessarily deployment dates.

1. October 2024First observed

   BotGuard version 41

   BotGuard already uses version 41. That version number remains in use in October 2026 despite rotation of scripts and their cipher parameters.

2. January 2025First observed · confirmed by Google

   A flow requiring JavaScript

   Results code handles the sg_ss parameter and provides a redirect to /httpservice/retry/enablejs when JavaScript is disabled.

   Google confirmed the JavaScript requirement on January 17, 2025, presenting it as protection against bots and spam (TechCrunch).

3. May 2025First observed

   The SearchGuard intermediate page

   An intermediate page embeds knitsail, produces the SG_SS cookie and restarts navigation. This mechanism is established by May 2025 at the latest.

4. September 2025Press report
   Data access · Scraping costs

   The end of 100 results per request

   Google stops supporting num=100. Collecting the top 100 positions can now require about ten results pages instead of one.

   Stopped working late on September 11, 2025, reported on September 15 by Search Engine Land. On September 18, Google said it does not formally support this parameter.

5. October 2025First observed

   A separate delivery channel

   The /sgasync channel, associated with code BMW, delivers the script, its hash and its program together. It complements an existing protection flow.

6. November 2025First observed

   Background checks

   The sg_ck=QyE channel serves background checks, with a program distinct from the BMW program.

7. January 2026First observed

   A check during a request

   The sg_ck=ON4 mode can compute a token and retry a request with X-Sg-Ss. This flow is distinct from the intermediate page.

8. March 2026First observed

   Code for iframes

   Engines gain functions handling sandbox, srcdoc and script loading. Knitsail also receives these functions.

9. July 2026First observed

   A module that keeps data in the browser

   A share of requests receives the background-check program extended with a module of about 6 KB. The module retains an interaction history in the browser (localStorage) and reads it back on the next run (structure and content). Both versions are served at the same time, for the same request URL.

   Observed from July 8 to October 17, 2026. In July, 10.5% of captures contain this module, all between July 8 and 16; afterwards, around 1%. The data is only read back by the program copy that wrote it. A/B test, sampling or server-side targeting: our corpus cannot tell which.

10. August 2026First observed

    Four new tests in the background check

    The QyE check program reads settings declared by the browser (platform, “Do Not Track”), measures the height of a text block with and without hyphenation, tests pointer precision (mouse or touchscreen) and queries the graphics card via WebGPU. The decoded program grows by about 13% (+2.6 KB); the engine that runs it does not grow.

    Appearance dated between August 20 at 12:06 and August 22 at 20:58 UTC: our corpus holds no capture between those two moments, and the four tests arrive together. Program size says nothing about execution cost or effectiveness against bots.

11. August 2026Confirmed by Google
    Data access · URL resolution

    Result URLs go through /goto

    Google rolls out /goto redirect links in its results pages. The final URL sometimes has to be resolved separately. An ordinary HTTP request is still enough in documented cases.

    Rollout confirmed by Google to Search Engine Land on August 26, 2026, after several months of testing according to the publication.

12. September 2026First observed

    A channel associated with Google Flights

    The /sgasync channel associates sg_ck=QyE with sg_fe=flights.

13. October 2026First observed

    The graphics card test disappears

    The background check stops querying the graphics card via WebGPU. The other three tests added in August remain in place. The change coincides with a new version of the JavaScript engine.

    Removal dated between 06:53 and 14:07 UTC on October 5, 2026. Our live session on October 17 confirms it: navigator.gpu is no longer read. The program loses about 320 bytes.

Orange milestones concern result collection and are separate from BotGuard mechanisms. “Confirmed by Google” refers to confirmation reported in the linked source; “First observed” refers to our code and page captures.

SearchGuard is Google’s name for its Search protection. BotGuard is a browser-side attestation engine: its virtual machine (VM) runs a Google-supplied program. The engine and the program are separate objects that can evolve independently.

Up to four VMs coexisted on an observed page. They do not all serve the same role: advertising and YouTube have their own flows. The homepage engine copy was analysed separately, without a trace of its reads in these sessions.

Checks can occur before results, on an already displayed page or during an additional request. These three flows are distinct, not a mandatory sequence.

If the flow ends in refusal: a redirect to /sorry can lead to reCAPTCHA. In the studied captures, this redirect clears SG_SS. The server remains the decision-maker; an HTTP 200 page can also be a challenge.

The retry with X-Sg-Ss was actually captured. However, neither an empty Validate response nor token production reveals the server’s internal verdict.

This matrix summarises reads and listeners observed during instrumentation. “Not observed” does not mean the engine cannot do it: the received program and session determine what runs.

Knitsail and the YouTube VM inspect the environment more broadly than the other two VMs. But these reads reveal neither Google’s weights, thresholds nor decision model.

What the background check reads since late August

Since August 22, 2026, the background-check program also reads settings declared by the browser (navigator.platform, navigator.doNotTrack, window.doNotTrack). It creates hidden text blocks in a monospace font and compares their height with and without automatic hyphenation (hyphens). It asks the browser whether the pointer is fine or coarse (any-pointer: fine and coarse): mouse or touchscreen. Until October 5, it also queried the graphics card via WebGPU (requestAdapter, then vendor and architecture).

These reads were recorded by running the collected programs offline, from November 2025 to October 17, 2026. Our live session on October 17 confirms the settings reads and the pointer test, as well as the absence of WebGPU. Details: background check, November 2025 to October 2026.

The controlled matrix separates the launch setting from the native navigator.webdriver signal: across all our trials, the outcome follows the signal value. It cannot attribute the server verdict to a particular read by a VM (see access trials).

An interaction history in the browser

The background-check variant equipped with the localStorage module retains interaction records and reads them back on a subsequent execution. On the August 18 program, a chain of 21 runs with distinct clicks leaves exactly the last 20 records in order: the oldest is removed. These are twenty program executions, not twenty clicks within a page.

The structure is observed in all the decoded programs; click, counter and twenty-run queue interventions concern the August sample. These results demonstrate neither a stable personal identifier, cross-site tracking, nor use of this history in the server score. Background-check and storage details.

Instrumentation can itself modify inspected properties. Control comparisons and replays document some perturbations; they do not prove that observation is invisible to Google.

The engine can execute instructions; the received program specifies the work. A token is the result transported to Google. By itself, it is not an access authorisation.

1. Receive

   In the studied knitsail flow, /sgasync transports the script, its hash and the encoded program.

2. Decode

   The client transforms the bytes, decodes UTF-8 and reads the JSON envelope. This step is separate from token encryption.

3. Execute

   The VM runs the program, reads signals and produces an output. Roles vary by program.

4. Transmit

   The output uses the flow’s transport: a cookie, a request header or a service call.

This contrast repeats across all our tested samples. It supports source-text sensitivity without locating a specific integrity mechanism or establishing server-side detection of modifications.

n = n + 1
delta = x - mean
mean = mean + delta / n
M2 = M2 + delta * (x - mean)
standard_deviation = sqrt(M2 / n)