Google Preferred Sources: The One AI Search Lever You Can Actually Pull

Almost everything people sell you as "AI search optimization" is a guess about what Google's models like. Nobody has the weights. Nobody has the logs. It is astrology with a Slack channel.

Then there is Preferred Sources, which is the opposite. A reader clicks a button, Google writes it down, and from that moment your articles get treated differently for that specific person in Top Stories and get a visible label in AI Overviews and AI Mode. No signal to earn, no schema to invent, no consultant required. You just have to ask.

Over 600,000 sites have already been picked by somebody. Since August 20, 2026 you can put the ask directly on your own page instead of hoping readers find a settings screen they have never heard of. I built it for a client last month, it took about half an hour, and one of those thirty minutes was me staring at a page that looked perfectly fine while the whole thing was silently dead. More on that later.

600,000 Sources, and 255,000 of Them Since May

Here is the growth curve, because it tells you whether this is a feature Google is committed to or one that gets quietly retired.

During the limited test that started in August 2025, readers had selected close to 90,000 unique sources. By late May 2026 that was 345,000. By August 20, 2026, when Google shipped the publisher button, it was over 600,000. Roughly 255,000 of those arrived in under three months, and the jump lines up almost exactly with Google extending the feature into AI Mode and AI Overviews on May 27.

The mechanic itself is simple. A reader goes into Google's source preferences, or clicks your button, and marks your site as one they want more of. The setting sticks to that reader, on their account, until they change it. It is not a site-wide ranking property. There is no API, no markup, no score. Which means nobody can sell you a "Preferred Sources strategy," and if somebody tries, you now know enough to say no.

What Google Actually Documents, and What It Doesn't

This is the part I want to be careful with, because the number that gets quoted everywhere is doing more work than it should.

Google's documentation says two different things about two different surfaces, and people keep merging them into one claim. For Top Stories, the wording is that your content "is more likely to appear." That is a surfacing effect. For AI Mode and AI Overviews, the wording is that your content "can be highlighted with a 'preferred' badge for users who have selected your site as a preferred source." That is a labelling effect, not a surfacing one.

The distinction matters. When Google extended the feature into AI Mode in May, the change did not alter which sources the AI picks. It put a badge on links from sources the reader had already chosen. So if you are hoping Preferred Sources gets you cited in an AI Overview you were not going to appear in anyway, that is not what Google has said, and I have not seen anything that shows otherwise. For that problem you are back to the ordinary work I wrote about in How to Get Cited by ChatGPT (What a 1.4M Prompt Study Actually Found).

Then the famous number. Nick Fox, Google's SVP of Knowledge and Information, said people are 2 times more likely to click through to a site after marking it as a preferred source. That is Google's own study, not an independent one, and read the denominator: twice as likely, among readers who liked you enough to opt in. Those are people who were already inclined to click you. The honest reading is not "double your traffic." It is "your existing readers stop losing you in the noise."

Which, if you have watched an AI summary quietly absorb the traffic that used to reach your page, is actually the thing you wanted. I went through those symptoms in 6 Signs Your Traffic Drop Is an AI Overview Problem, Not a Ranking Problem. This does not fix the algorithm. It puts your name back in front of the people who already chose you once.

My own inference, labelled as inference: the badge is probably worth more than the Top Stories lift for most non-news sites, because a badge is a trust cue at the exact moment a reader is deciding whether to click a link inside an AI answer. I cannot prove that. Google has not published a badge-specific number that separates the two surfaces.

Check Eligibility Before You Write a Single Line of Code

Only domain-level and subdomain-level sites appear in the source preferences tool. Google's own example: https://www.example.com/ and https://code.example.com/ are eligible. https://www.example.com/blog is not, has never been, and there is no workaround.

I nearly scoped this for a client whose entire editorial output sits in a subdirectory. Twenty seconds of checking would have saved me a conversation I had to walk back. So do the twenty seconds: sign into a Google account, open google.com/preferences/source, search your domain. If it does not show up, stop. There is nothing to build.

Two things people get wrong here. First, it is not news-only. Google's docs never restrict it to news publishers, and any site publishing fresh content can qualify. Second, appearing in that tool generally means Google already treats you as a publication. For a five-page plumber site, that is a goal, not a Tuesday afternoon task. If you publish two posts a year, fix that first and come back.

You also cannot check this from a terminal or while signed out. It needs a real signed-in Google account, which is mildly annoying and worth knowing before you promise a client an answer in five minutes.

The Whole Implementation Is Two Lines

Google's stock version:

<script async src="https://news.google.com/swg/js/v1/publisher.js"></script>
<div google-add-preferred-source-btn></div>

That gives you Google's button in Google's styling, which you cannot restyle. On a site with an actual design language it reads as an ad and gets scrolled past. So most projects want the manual mode, where you load the SDK with an attribute and bind your own element:

<script async preferred-sources-control="manual"
  src="https://news.google.com/swg/js/v1/publisher.js"></script>

One rule I would not bend on, whatever your framework: make the button a real <a> with a real href pointing at the deeplink, and only call preventDefault() in the click handler once the SDK has genuinely bound. Not href="#" plus an onClick. The script is async, ad blockers target news.google.com, and your own security headers might kill it. A link that always works and sometimes gets upgraded beats a button that sometimes does nothing.

The other thing that bites: load the SDK once per page, not once per button. Two buttons, end of article plus footer, is the normal layout. In Next.js, next/script with a stable id dedupes, and use onReady rather than onLoad so the callback re-registers on client-side navigations. In Astro, a processed <script> is hoisted and bundled once no matter how many times the component renders. Adding is:inline is what duplicates it, and then the queue callback registers twice and every click fires twice.

My CSP Ate the Script and Nothing Told Me

This is the hour I lost, and it is the single most practical thing in this post.

If your site ships a Content-Security-Policy header, and every site I have built in the last three years does, the browser refuses to load Google's script and the page looks completely normal. No layout break. No error toast. The button still renders, because it is just an anchor tag. It simply never becomes the in-page flow. Forever.

Three directives need editing, not one:

script-src  … https://news.google.com
connect-src … https://news.google.com
frame-src   … https://news.google.com https://www.google.com

frame-src is the one everybody misses, because you only discover you need it after fixing script-src and finding out the flow opens a service iframe and a popup. Find the CSP before you write the component, not after. It hides in public/_headers on Cloudflare Pages, in netlify.toml, in vercel.json, in the headers block of next.config, in a middleware with a per-request nonce, or in a <meta http-equiv> in the base layout. This settles the argument in one second:

curl -sI https://yoursite.com/ | grep -i content-security-policy

A project with no CSP at all is a valid answer. Then there is nothing to change and you say so, instead of inventing a policy because it felt thorough. And if you do have one, the rest of it probably deserves a look too, which is roughly the checklist in The Website Security Hardening Checklist (No Plugins, No BS).

Verifying is four checks in a real browser, in this order. Console for a CSP violation, that is usually your answer. Then confirm the tag landed with its attribute intact. Then wait a few seconds and check typeof window.PREFERRED_SOURCE: "object" means the SDK drained the queue and you are fine, "array" means the SDK never loaded, "undefined" means your registration code never ran. Three different bugs. Then click it, and the page must not navigate. On localhost the SDK reports publicationId=publication-id-free, which looks alarming and is not. Google resolves the real publication from the live domain.

The Link You Can Paste Anywhere Matters More Than the Button

The on-site button only reaches people who are already on your site. Which, if you are worried about AI search intercepting your readers, is exactly the group you are least worried about.

The other deliverable takes no JavaScript at all:

https://www.google.com/preferences/source?q=example.com

That goes in your newsletter footer, your social bios, the end of a podcast description, the bottom of a LinkedIn post. It works everywhere you cannot inject a script, which is most of the places your returning readers actually spend time. UTM-tag it and you get the only click data you are ever going to have on this feature.

Copy matters more than placement here. My one real data point is that a bare English label reading "Add to Preferred Sources" means nothing to a normal human. Something closer to "if these posts are useful, tell Google you want more of them" at least explains what you are asking for. I do not have enough volume through it yet to prove that is better. I am telling you it is a guess because it is one.

Nobody Can Measure This, Including Google's Own Tools

Search Console has no Preferred Sources dimension. Not hidden, not delayed. It will not tell you how many readers selected you, how often the badge showed, or what share of your Google clicks came through the mechanic. GA4 buckets every one of those clicks as google / organic like any other.

Given how much Search Console has been adding lately, including the AI traffic numbers I dug through in Google Search Console Now Reports AI Traffic. Here's What My Numbers Say., that absence is conspicuous rather than accidental.

So you get two weak proxies. UTM-tagged deeplink clicks, which measure the ask and not the outcome. And branded search trends over a window long enough to mean something, which measure a dozen things at once. I am watching both anyway, and I will not pretend either one proves causation.

Here is where I land. This is a 30-minute job on an eligible domain. It does not require guessing at Google's intentions, which puts it in a very small category right now, and I said as much about the rest of the field in GEO Is the New Snake Oil (Or Is It?). It will not get you cited where you were not going to be cited. It will not show up in a report. What it does is give the readers who already like you a way to tell Google that, and stop the AI layer from quietly replacing you for the people who chose you in the first place.

If you want someone to check whether your domain is even eligible before quoting you for the work, get in touch. I will tell you honestly if the answer is no, which for a subdirectory blog it always will be.