On August 20, Google announced three personalization changes across Search, Discover and News. Nearly every write up led with the fun one: you'll soon be able to tell your Discover feed what you want in plain English, like texting a friend. That's the consumer story, and it's real.
Buried under it is the part that ships code. Google Preferred Sources now has an official embeddable button, and it takes two lines of HTML. When a reader clicks it, your site gets pinned to their Top Stories, their AI Overviews and their AI Mode results, with a "preferred" badge attached.
The documentation gives away more than the announcement does. The button loads from Google's Subscribe with Google library, and the badge it earns you is visible only to the one reader who clicked it. Both facts are in the Search Central doc. Neither made the coverage.
Key Takeaways
Google shipped an embeddable "Preferred Sources" button on August 20, 2026. Two lines of HTML: one script tag, one empty div.
It affects Top Stories, AI Overviews and AI Mode, but only for the individual reader who clicked it. It is not a ranking signal and it does not raise your visibility to anyone else.
Subdirectories aren't eligible. If your writing lives at
example.com/blog, you can only claim the whole domain.The library loads from
news.google.com/swg/js/v1/publisher.js. SWG is Subscribe with Google, which tells you which team built this and how Google is thinking about it.Google says people have selected more than 600,000 unique sources. That counts sources, not people, and Google didn't publish the second number.
On my own site the honest math came out to roughly five clicks a month, so I'm using the deeplink instead of widening my Content Security Policy for a Google script.
What did Google actually announce on August 20?
Google announced three separate personalization features in one post written by Mrinalini Loew, General Manager of Google Search Ecosystem, and only one of the three requires a publisher to do anything at all. The other two are consumer settings that change how readers reach you.
Here's the split, because the coverage blurred it:
| Feature | Who acts | Status | Surface affected |
|---|---|---|---|
| Natural language Discover tuning | Reader | "Coming days" in the Google app | Discover feed |
| Preferred Sources button | Publisher embeds, reader clicks | Live now, documented | Top Stories, AI Overviews, AI Mode |
| Customizable audio briefings | Reader | Live on Android | Google News app |
ZDNET listed all three and then spent the article on the Discover chat interface. The Verge led with the same thing and gave the button one paragraph near the end. Neither is wrong. Both were writing for readers, not for the people who own the sites in those feeds. It's the same shape as two days ago, when everyone wrote iMessage and OpenAI's own docs said SMS and RCS too. The headline is written for readers. The documentation is written for you.
What is the Preferred Sources button, and what does installing it take?
The standard implementation is two lines, which is the whole reason this is worth reading the week it shipped rather than a quarter from now when someone sells you a course about it. One script tag, preferably in the head, and one empty div wherever you want the button to render.
<script async src="https://news.google.com/swg/js/v1/publisher.js"></script>
<div google-add-preferred-source-btn></div>
The library scans the DOM for that attribute and renders a Google styled button, translated automatically into the reader's language, with a light or dark theme option. Click it, and the reader adds your domain as a preferred source and lands back exactly where they were on your page. No new tab, no lost scroll position.
The doc lists three implementations. The deeplink at the bottom is the one most sites will actually be able to ship, because it needs no third party JavaScript.
There are two other paths. An advanced JavaScript route lets you bind the flow to your own UI elements through an ES module or a script callback queue, which matters if you're on a framework that fights with DOM scanning. And a deeplink route, which is just a URL:
https://www.google.com/preferences/source?q=example.com
Google names social posts, email newsletters and promotions as sanctioned homes for that link, on top of a text link or clickable image on your own pages. So a newsletter footer is fair game. Keep it in your back pocket, because I'll come back to why it's the version I'd actually deploy.
Now look at the script URL again. It's served from news.google.com/swg/js/v1/publisher.js. SWG is Subscribe with Google, the publisher monetization library Google has shipped since 2018. Preferred Sources didn't get its own endpoint. It got bolted onto the subscriptions stack, and the working demo Google links from that same page is hosted at reader-revenue-demo.ue.r.appspot.com. Reader revenue. What that internal ownership means is my inference, not a Google statement, but it is a loud one: this is a reader relationship feature, not a Search ranking feature. Which turns out to be exactly right.
Does being a preferred source make you rank higher in AI Overviews?
No, and this is the sentence that most of the SEO commentary over the next fortnight is going to get wrong, so read Google's own wording carefully rather than anyone's summary of it. The effect is scoped to one person at a time, and it does nothing for the rest of the internet.
Google's documentation says that when a user selects your site, your content is "more likely to appear" in Top Stories with a preferred badge, and that in AI Mode and AI Overviews your content "can be highlighted with a preferred badge for users who have selected your site as a preferred source." That last clause is the entire ballgame. Nothing here is a domain level signal. Nothing here reaches a reader who has never heard of you.
So Preferred Sources is not an acquisition channel. It's a retention channel that happens to run through Google's surfaces instead of through an inbox. If you already have readers, it deepens what they see. If you don't, it does nothing, and no amount of embedding the button will change that. The same asymmetry shows up in how AI assistants pick citations at all, which I dug into when Anthropic published its multi agent failure data.
That's a real gap between how this will be marketed and what it does. Expect "get into AI Overviews with two lines of code" posts by the weekend. The two lines are real. The "get into AI Overviews" is not, unless the person reading already chose you.
Why is a /blog subdirectory not eligible?
Domains and subdomains only. That single restriction quietly excludes a large slice of the internet's actual publishing, because most company blogs live one directory deep instead of on their own hostname. The doc is blunt about it.
https://www.example.com/ and https://code.example.com/ are eligible. https://www.example.com/blog is not. If your content strategy is a blog attached to a product site, a reader can't prefer your writing. They can only prefer your company, pricing pages and all. For a SaaS company whose blog is genuinely good and whose marketing site is generic, that's a real mismatch.
The source preferences tool is also the eligibility check. If your domain doesn't autocomplete in that search box, no button will help you.
Before you write a ticket, put your domain into that search box. If it doesn't come up, you're not eligible yet, and the button will render for a source Google can't attach anyone to. Google adds a quiet caveat at the bottom of the tool too: sources that aren't updated regularly may be unavailable. Publishing cadence is a gate here, not just a nice to have.
600,000 unique sources have been selected. That number is smaller than it looks.
Google's exact words are "people have already selected more than 600,000 unique sources." Read that again. It counts sources, not humans. Those are two entirely different measurements of the same feature, and Google published the one that flatters it.
Six hundred thousand distinct websites have been picked by at least one person each. That could be six hundred thousand people picking one site apiece, or a much smaller group of enthusiasts picking dozens each. Google published the flattering half. It's the same move I flagged when Gemini and ChatGPT both announced a billion users and one of those numbers turned out to be weekly while the other was monthly.
I'm not calling it dishonest. Preferred Sources launched around a year ago, and 600,000 distinct domains getting picked is genuine adoption of the long tail, which is the good news for small sites. But if you're building a business case off this, the number you need is average sources per active user, and Google didn't give it to you.
What changes when Discover takes stated preferences instead of inferred ones?
Discover has always been built from behaviour, which means pages you visited, terms you searched, and cross ecosystem signals like what you watched on YouTube, all inferred without you ever telling Google anything directly. The new chat interface flips that, and the negative instructions are the interesting half.
You do it by tapping the three dot menu on any card, which is the mechanic most of the coverage flattened into the word "chatbot." Google's own examples are "kitchen reno ideas (eco-friendly only)" and "Videos about weekend road trips (but no camping)." Read the parentheses as a publisher. Both examples are exclusions, and a reader can now rule out a slice of a topic by describing it once, in advance, and have Google remember it.
ZDNET led on the Discover feature and gave the button a bullet, then ran the deeplink under this byline as a plain "Add us as a preferred source" link pointing at google.com/preferences/source?q=zdnet.com. The fallback implementation, shipped day one, by the outlet that buried the story.
"But no camping" is a death sentence for whoever writes the camping posts. Not because Google demoted them, but because a reader asked them to go away and finally has a working way to say so. ZDNET's Artie Beaty was honest about the old controls in the same article: he does not bother telling Google he is uninterested, because it feels insignificant to turn off. Lowering the cost of saying no changes how often people say it.
But notice this also cuts the other way. If someone asks for long form deep dives and yours are the good ones, you just got a durable slot that no competitor can outbid. Stated preference is stickier than inferred preference, because the user typed it and can see it.
One caveat on timing. The Discover feature is still "in the coming days," which is an announcement rather than a shipped thing, and Google does walk announcements back. It did exactly that this month when it pulled a generative feature out of Google Earth after the guardrails didn't hold. The button is documented and live. The chat interface is a promise.
I ran the math for my own site. Here's why I'm not shipping the button.
My blog gets roughly 260 real sessions a month once I strip out my own country and datacenter traffic, which is a small enough number that any feature requiring an existing reader to take an action has a very short ceiling. Two percent of 260 is about five people.
Five readers a month would get a preferred badge on my content in their own AI Overviews. That's the realistic top end, and it's probably generous. Meanwhile 65% of my Google impressions are AI assistant shaped queries running at effectively zero click through, and my best performing post earned 6 clicks against 14,093 impressions last month. Preferred Sources doesn't touch any of that, because none of those readers have ever chosen me.
There's a second ceiling that has nothing to do with my traffic. Preferred Sources is a Google surface and only a Google surface. My first party logs cover 268,000 agent requests, and OAI-SearchBot pulled the markdown twin of a post on 26% of its reads while GPTBot did it on 31%. Not one of those requests can see a preferred badge, because ChatGPT and Perplexity don't have one. If your AI visibility problem is assistants other than Gemini, this button is not the fix.
Then there's the engineering cost, which is the part I actually got stuck on. This site runs a strict Content Security Policy defined in next.config.ts. Loading publisher.js means adding news.google.com to script-src, so a Google origin gets to execute arbitrary JavaScript on every page for as long as the tag exists. For five clicks a month, that's a bad trade, and I'd rather keep the CSP tight the way I did when I audited my own SEO tooling stack.
So I'm using the deeplink. A plain <a href> to google.com/preferences/source?q=jahanzaib.ai costs zero bytes of third party script, zero CSP surface, and converts about as well as a Google styled button does when your audience is a couple hundred technical readers who already know what they're clicking. I was wrong about which implementation mattered when I started reading the doc. The recommended one is not the right one for most sites.
Who should install this, and who should skip it?
The dividing line isn't traffic volume. It's whether you have repeat readers who would recognize your name in a list. Everything this feature does depends on somebody deliberately choosing you, and then continuing to search Google afterwards.
| Your situation | Ship it? | Which version |
|---|---|---|
| News publisher, daily cadence, returning audience | Yes, immediately | Standard JS button, above the fold |
| Newsletter with an engaged list | Yes | Deeplink in the footer of every send |
| Company blog on a subdirectory | Can't | Not eligible. Move to a subdomain first, or skip |
| Small technical blog, strict CSP | Marginal | Deeplink only. Don't widen script-src |
| New site, no returning readers | No | Nothing to convert. Spend the hour elsewhere |
Here's my actual opinion, and it's the kind that can be wrong. Preferred Sources will be oversold as an AI search play for about six months, then quietly become standard furniture in news site templates, the way RSS icons and Apple News badges did. The sites that get value from it are the ones that already had an audience relationship and just gained a cheaper way to formalize it. Everyone else is installing a button that nobody clicks.
Google shipping this on the Subscribe with Google library is the tell. This is a loyalty product. Treating it as a distribution product is the mistake, and it's the same category error I wrote about when Google Maps started assembling dinner orders it couldn't pay for: the demo shows the surface, and the constraint lives one layer down in the docs.
Frequently asked questions
Is Google Preferred Sources a ranking factor?
No. It changes what an individual reader who selected you sees in their own Top Stories, AI Overviews and AI Mode results. It does not affect your position for anyone else, and Google's documentation scopes the AI surface effect explicitly to "users who have selected your site as a preferred source."
How do I add the Preferred Sources button to my site?
Add <script async src="https://news.google.com/swg/js/v1/publisher.js"></script> to your head, then place <div google-add-preferred-source-btn></div> wherever the button should render. If you can't load third party JavaScript, link to https://www.google.com/preferences/source?q=yourdomain.com instead.
Can I make just my blog a preferred source?
Only if it lives on its own domain or subdomain. Google restricts eligibility to domain and subdomain level sites, so blog.example.com works and example.com/blog does not. Check by typing your domain into Google's source preferences tool.
Where is Preferred Sources available?
Top Stories support is global, in every language Google Search runs in. AI Mode and AI Overviews support follows wherever those two features have already launched, so availability there depends on your readers' locale rather than on anything you configure.
Does the Discover natural language feature affect my traffic?
Probably, over time. Readers can now exclude formats by describing them, and Google's own examples include skipping product news and press releases. It also works in your favour if you publish the format someone asks for by name, because a stated preference persists in a way that inferred behaviour doesn't.
Does adding the button carry a security cost?
The standard implementation does. It loads executable JavaScript from news.google.com on every page it appears on, which means widening script-src if you run a strict Content Security Policy. The deeplink implementation is a plain link and carries none of that.
How many people actually use preferred sources?
Google says more than 600,000 unique sources have been selected. That figure counts distinct websites chosen by at least one person, not the number of people doing the choosing, and Google has not published the second number.
If you're trying to work out whether any of Google's AI surfaces are worth engineering time for your business at all, that's a question about your current setup rather than about the feature. The AI readiness assessment walks the same ground I used to reach the "five clicks a month" answer above, and takes a few minutes.
Google announced natural language Discover tuning, an embeddable Preferred Sources button and customizable Google News audio briefings on August 20, 2026, and stated that people have already selected more than 600,000 unique sources. Google's Search Central documentation confirms the two line standard implementation, the
google.com/preferences/source?q=deeplink, and that only domain and subdomain level sites are eligible. Mrinalini Loew, Google (Aug 20, 2026) · Google Search Central, Preferred sources documentation (updated Aug 20, 2026) · Google, news AI pilot program · Emma Roth, The Verge (Aug 20, 2026) · Artie Beaty, ZDNET (Aug 20, 2026).
Top comments (0)