Disable Google AI Overviews: udm=14, Browser Settings, and uBlock Filters

Quick answer: Google doesn’t offer a setting to turn AI Overviews off; its own help page says the feature “cannot be turned off.” Three workarounds exist outside that: append &udm=14 to a search URL to force the plain “Web” filter for that query, save a custom search engine in your browser so udm=14 applies to every search automatically, or enable EasyList’s opt-in “AI Widgets” list in uBlock Origin to hide the rendered block. None of these stop Google from generating the Overview server-side, and none of them change what reaches your own site’s analytics — AI Overview rendering is entirely client-side on google.com, so nothing about disabling it shows up in your GA4 data. For how Google’s AI features behave on the measurement side, see Tracking Google AI Overviews: What opi and ved Can’t Tell You.

Is there an official way to turn off AI Overviews?

No. Google’s own Search Help page is explicit about it:

“AI Overviews are a core Google Search feature, like knowledge panels. Features cannot be turned off. However, you can select the Web filter after you perform a search. This filter displays only text-based links without features like AI Overviews.” — Google Search Help

That’s the whole sanctioned option: a filter tab you click after every search, not a persistent preference. Everything below is a workaround that reconstructs a permanent version of that filter, none of it documented or supported by Google.

The udm=14 parameter

Appending &udm=14 to a Google Search URL forces the same “Web” filter Google’s help page describes, for that one query:

https://www.google.com/search?q=your+query&udm=14

udm isn’t documented in any Google Search Central or developer reference. It surfaced through reverse engineering shortly after AI Overviews launched at Google I/O in May 2024, and the trick was first written up by Tedium before being picked up by Ars Technica, 9to5Google, and, as recently as February 2025, The Verge — meaning it has stayed necessary for well over a year since launch, with no official replacement.

Because it’s undocumented, Google can change or remove it without notice. There’s precedent for exactly that: &num=100, a parameter rank-tracking tools relied on for years to pull 100 results per page, stopped working in September 2025 after Google quietly changed how the parameter is handled — confirmed by Google in its own support forum and covered by Search Engine Journal. Treat udm=14 the same way: it works today, but build nothing durable on it.

Making it the default

A single udm=14 query only affects that one search. To apply it everywhere, set a custom search engine in your browser whose URL template includes it:

https://www.google.com/search?q=%s&udm=14

Chrome: go to chrome://settings/searchEngines, add a search engine under “Site search,” and enter the URL above with %s where the query goes. Set it as default. Chrome’s own help page documents this flow generically — adding a search engine by giving it a results-page URL with %s as the placeholder — without any Google-specific wrinkle. (Chrome Help)

Brave: go to Settings → Search Engine and add a custom entry with the URL above, replacing the query with %s as Brave’s own help page documents. (Brave Help) By Chromium convention the same screen is also reachable at brave://settings/searchEngines, though Brave’s own doc doesn’t name that address directly.

Firefox: Firefox also supports adding a custom search engine with a %s URL template; the exact steps have moved around between versions, so check Mozilla’s current support article for your version rather than relying on a fixed set of menu steps here. A version-independent fallback that always works: bookmark https://www.google.com/search?q=%s&udm=14, then set a keyword (e.g. g) in the bookmark’s properties. Typing g your query in the address bar runs the search through that template regardless of how the search-engine settings UI looks in your release.

Blocking the AI Overview block with uBlock Origin

uBlock Origin’s default filter lists — EasyList, EasyPrivacy, the uAssets lists — have no AI Overview rule in them. The rule exists, but it ships in a separate, opt-in list: EasyList’s “AI Widgets” list, internally named fanboy-ai-suggestions, which uBlock Origin’s own asset manifest marks "off": true by default.

To turn it on: open uBlock Origin’s dashboard → Filter lists → Annoyances, and check EasyList – AI Widgets. uBO fetches the list and applies it on the next page load.

The rules currently in that list, as published upstream, are procedural cosmetic filters targeting google.com:

www.google.com#?##Odp5De:has-text(/AI Overview|Übersicht mit KI/)
www.google.com#?##main > [data-ved]:has-text(AI Overview)

The syntax is standard uBO: ## is a cosmetic (element-hiding) filter scoped to the listed hostname, and :has-text() is a procedural operator that matches an element containing specific text rather than relying on a fixed selector alone — documented in the uBlock Origin static filter syntax wiki. The second rule is written against DOM structure (main > [data-ved]) rather than a class name, specifically because the first kind of rule breaks often.

Expect this to break. Odp5De is one of Google’s generated, non-semantic class names, and it rotates. One open issue reports the rule failing on non-English UIs; two pull requests attempting to update the selector were opened and closed unmerged in January 2026; and the commit history shows edits as recent as the day before this post was published. If the filter stops hiding the block, that’s the maintainers chasing a renamed class, not a sign you did something wrong — check the commit history for a newer version before writing your own rule.

Why hiding the block doesn’t stop the generation

It’s worth being precise about what each method actually does, because they operate at different points in the request:

Method	What it changes	When it acts
udm=14	The request Google’s results page sends	Before the server decides what to render
uBlock Origin filter	The DOM after the page loads	After Google has already generated and sent the Overview

udm=14 tells Google’s backend to serve the Web filter for that query, so in the cases I’ve tested, the AI Overview doesn’t get generated for that request at all. uBlock Origin’s filter does something narrower: the HTML for the Overview still arrives in the response, and the cosmetic rule hides the element client-side after it renders. If you care about not having Google process the query through its generative pipeline at all — rather than just not seeing the box — udm=14 is the one that does that; the filter is a display-layer fix.

This matters for the privacy-conscious framing some people reach for these workarounds with: blocking the element in your own browser doesn’t opt you out of Google generating a response server-side, and it has no effect on what Google logs for that query. For what AI Overview clicks do and don’t expose to the destination site’s analytics — referrer behavior, the opi and ved parameters, and why neither identifies an AI Overview click — see the full breakdown.

One mechanism worth naming here because it explains why a client-side filter is even possible: cross-origin navigations from google.com send only the origin — https://www.google.com/ — in the Referer header, never the full URL with its query string. The underlying spec’s own baseline default is actually the looser no-referrer-when-downgrade (W3C Referrer Policy, §3.2); the stricter behavior comes from Chrome itself overriding that baseline to strict-origin-when-cross-origin starting in Chrome 85, as Google announced, with other Chromium browsers and Firefox and Safari making similar moves on their own. See MDN for how the policy mechanism itself works. That’s a platform-wide default, not something specific to AI Overviews, but it’s the same reason neither udm=14 nor anything else about how a visitor got to Google’s results page ever shows up in your server logs.

What this means if you’re measuring AI Overview impact on your own traffic

If you’re a web analyst rather than someone trying to avoid AI Overviews yourself, none of the above shows up in your own data, for the same reason:

• udm=14 never reaches you. It’s a parameter on Google’s results-page request, not on the link Google serves to a result. Your landing pages, GA4 sessions, and server logs never see it, with or without a visitor using it.
• A visitor’s browser-level workaround is invisible to you. Whether someone has udm=14 baked into their default search engine or is running the uBlock Origin filter, your analytics stack has no way to tell. There is no segment to build for “visitors who’ve disabled AI Overviews.”
• What you can actually track is the inverse: how often your pages show up in AI Overviews at all, via Search Console’s generative AI performance report, and whether that’s trending up or down for pages you care about. That report, and the GA4 setup for the proxies you can measure (text-fragment landings, AI assistant referrers), is covered in detail in the opi/ved post rather than repeated here.

If you want to sanity-check your own exposure before investing in any of this, pull the generative AI performance report trend for your top pages over the last 90 days before and after a known AI Overview rollout change, rather than assuming blocking behavior on the visitor side has any bearing on what Search Console reports. Setting up that kind of before/after measurement is part of my analytics work.