Google Preferred Sources: Add the Button, Measure It
Google's preferred sources button takes two lines to install. Knowing whether it did anything takes real work. Here's both, minus the hype.
Google will now let you ask for the follow
Since April 2026, anyone searching Google in any language can mark a site as a preferred source, which tells Google to show them more of that site in the places where it curates results. And since August 20, the button you put on your own site to prompt that choice got noticeably better: a reader clicks it, confirms in an overlay, and stays right where they were on your page instead of being bounced through Google's settings and (maybe) finding their way back. Google's own numbers suggest this is worth caring about. By the end of April more than 200,000 sources had been selected, and readers who mark a site as preferred are, in Google's words, "twice as likely to click through to a site after marking it as a Preferred Source."
The install genuinely takes two lines, and that part of the story has been written up dozens of times already. What almost nobody has written is how to tell whether the button earns its place on your page once it's there. That's the part a tracking company is actually qualified to cover, and since we put the button on attri.io this week, we can show you the wiring along with the pitch.
What it actually does, which is less than the hype says
If you read Google's publisher documentation instead of the coverage about it, the feature turns out to be specific and fairly modest. Being someone's preferred source affects three surfaces, and the promise is different on each one.
In Top Stories, your content becomes "more likely to appear" for that reader, marked with a small "preferred" badge. This is the real inclusion effect, and if your audience overlaps with news-style queries it's the reason to bother. In AI Mode and AI Overviews, the promise is thinner: your content "can be highlighted with a 'preferred' badge" when it shows up for someone who picked you. A badge is nice, but notice what Google isn't saying there. Nothing in the documentation promises your content gets into AI answers more often, only that it gets labeled when it's already in.
And then there's Google Discover, which is all over the LinkedIn commentary about this feature and entirely absent from Google's documentation of it. As far as we can tell, the confusion started because Google announced a separate Discover feed-refinement feature on the same day as the button update, and the two stories merged as they traveled. If someone tells you preferred sources boosts your Discover traffic, they read a summary of a summary.
One more correction worth making, because it changes how you should think about the whole feature. Search Engine Journal ran a May headline calling preferred sources "a global SEO signal," and the phrase stuck. What actually happened is geographic: the feature rolled out from the US and India in August 2025 to every language by April 2026. It is not a ranking signal in any general sense. Google's own line is that selections work alongside its ranking systems and don't override relevance, which means this is per-user personalization. The people who pick you see more of you, and nobody else's results change at all.
That's still worth having. The readers most likely to click the button are your newsletter subscribers and repeat visitors, exactly the people whose Top Stories you'd want to live in. Just go in knowing you're deepening loyalty, not buying reach.
The ten-minute install
Google gives you three ways in, documented on the preferred sources publisher page. The standard button is two lines:
<script async src="https://news.google.com/swg/js/v1/publisher.js"></script>
<div google-add-preferred-source-btn></div>
The script goes in your head, the div goes wherever the button should render, and Google draws an auto-localized button in place. It accepts data-theme="dark" and data-lang attributes if your page needs them.
If you'd rather not load Google's JavaScript at all, there's a plain deeplink: https://www.google.com/preferences/source?q=yourdomain.com. It opens the source preferences tool with your site pre-searched, and because it's just a URL, it works in the places a script can't run, like newsletters and social bios.
Before you ship anything, two eligibility catches from the documentation are worth checking. Only domains and subdomains qualify, so blog.example.com can be a preferred source while example.com/blog cannot be one on its own. And Google warns that "sources that aren't updated regularly may not be available," so search for your site in the preferences tool first to confirm you're actually in it.
One implementation note from our own install this week: if your site does client-side navigation between pages (Astro view transitions, Next.js routing, anything single-page-app-shaped), the auto-rendered button will quietly fail to reappear after the first soft navigation, because Google's script only scans the page once. The fix is the advanced integration, where you render your own button and call preferredSource.addPreferredSource() from your own click handler. Ours took about twenty minutes, most of which was discovering the problem.
The part nobody measures
Here's where every guide we swept simply stops: button installed, job done. Which is odd, because you've just added a UI element whose entire payoff happens inside Google's results where you can't see it. Selections don't appear anywhere in Search Console. The downstream lift, if it ever comes, lands as ordinary google / organic sessions that look identical to every other search click. We wrote about this same visibility problem with AI assistant traffic, and Google's own surfaces are even more opaque.
So instrument the two things you can see.
The first is clicks on the button itself. If you're using the advanced integration anyway, you already have a click handler, so fire an analytics event from it with a placement label. We push a preferred_source_click event with placement: blog or placement: footer, which turns "should the button live in the post footer or the site footer?" from a design debate into a question our own data can answer in a few weeks.
The second is the deeplink, which is just a URL and can therefore be tracked like any other link. We minted one short link for the newsletter and a separate one for social bios, both pointing at the same Google preferences page. When the click counts diverge, we'll know which placement actually moves people, which is ordinary campaign tagging discipline applied to a link Google happens to own.
Then put a note in your calendar for eight weeks out. Pull your Top Stories impressions from Search Console now as a baseline, and compare when the reminder fires. That's the whole system: two events, two tagged links, one calendar entry.
What we expect, honestly
Probably a small effect, concentrated in our most loyal readers, and we won't be able to fully separate it from everything else that moves search traffic. That's fine. The button costs nothing to run, carries no ranking risk, and the measurement rig around it cost us an afternoon. Most sites will install it without any of that rig, which means most sites will never know whether it did anything, and "we have the button" will quietly become another cargo-cult SEO checkbox.
Ours is live in the blog and the site footer as of this week. When the numbers say something either way, we'll write it up.