Google Preferred Sources is a feature that lets readers explicitly mark your domain as a source they trust, increasing the odds your content shows up — with a distinct badge — in Top Stories, AI Mode, and AI Overviews. You add it with two lines of HTML: a script tag and a button div. It only works for domain-level or subdomain-level sites, not subdirectories.
Google rarely ships a feature this simple to implement and this direct in what it asks for: let the reader tell Google which sources they want to see more of. No verification queue, no Publisher Center account, no waiting for approval. If your domain qualifies, you can ship the button today.
This guide covers what the feature actually does, who’s eligible, the three ways to implement it, and the rollout checklist I’d run before shipping it to production.
What Preferred Sources actually does
When a reader adds your domain as a preferred source, Google is more likely to surface your content — carrying a visible badge — across three surfaces:
- Top Stories, in every language Google Search supports
- AI Mode, where it’s available
- AI Overviews, where it’s available
That’s a distribution signal layered on top of ranking, not a replacement for it. A page that wouldn’t rank on its own merits doesn’t suddenly qualify for Top Stories because a handful of readers preferred the domain. What changes is the tiebreak: among sources Google already considers relevant and trustworthy for a query, the ones a reader has explicitly preferred get a visibility edge and a badge that sets them apart in the results.
That AI Mode and AI Overviews are named alongside Top Stories tells you where this is headed. Preferred Sources isn’t a legacy news feature bolted onto old Search — it’s Google building an explicit trust signal for an index that increasingly answers queries directly instead of just listing links. For anyone doing AI search optimization, this is a new lever worth pulling, and one that costs almost nothing to test.
Who’s actually eligible
Eligibility comes down to one structural rule: only domain-level and subdomain-level sites qualify.
https://example.com/— eligiblehttps://blog.example.com/— eligiblehttps://example.com/blog/— not eligible
If your content lives in a subdirectory of a larger site — a common setup for SaaS blogs hosted at company.com/blog or company.com/resources — this feature isn’t available to you yet, regardless of how well-optimized that subdirectory is. That’s consistent with a decision I’ve flagged before when weighing subdomain vs. subfolder architecture: platform-level features increasingly key off the domain boundary, and subdirectories inherit whatever the root domain qualifies for — nothing more, nothing less.
Beyond that structural requirement, Google doesn’t publish a separate approval process. There’s no Google News enrollment step and no Publisher Center account to set up — this feature runs on its own, simpler eligibility model. You can check whether your domain already shows up correctly in the mechanism Google uses internally by entering your URL into the source preferences tool.
Three ways to implement it
Google gives you three implementation paths, in order of effort.
1. Standard JavaScript implementation (recommended for most sites)
This is two lines of HTML. Drop the script tag in your <head>:
<script async src="https://news.google.com/swg/js/v1/publisher.js"></script>Then place the button wherever you want it to appear — typically near the byline, publish date, or share icons:
<div google-add-preferred-source-btn></div>That’s it. Google renders an auto-localized button matching the visitor’s language, and clicking it lets the reader register your domain without leaving the page. The async attribute means the script downloads without blocking render, so it’s safe to add without a Core Web Vitals penalty.
Two optional attributes let you match the button to your design:
<div google-add-preferred-source-btn data-theme="dark" data-lang="en"></div>data-theme accepts "light" or "dark". data-lang overrides Google’s automatic language detection with an explicit language code — useful on a bilingual site where you want the Spanish page to always render the Spanish button regardless of browser settings.
2. Advanced JavaScript with custom design
If the default button doesn’t fit your design system, Google exposes the underlying library so you can build your own trigger — a custom-styled button, a menu item, whatever fits — and call the library programmatically, either via ES module imports in a modern build pipeline or through a standard script callback queue. This is more setup for the same outcome: full control over the visual, none over the underlying mechanism.
3. Deeplink implementation (no JavaScript required)
If you can’t or don’t want to add JavaScript, link directly to Google’s source preferences tool with your domain pre-filled as a query parameter — a plain anchor tag, or an anchor wrapping one of Google’s official translated badge images. It sends the reader off your page to complete the action, which is a worse experience than the inline button, but it’s the right fallback for sites on locked-down CMS platforms where adding a script tag isn’t realistic.
Rollout checklist
Here’s the sequence I’d run before shipping this to production:
- Confirm domain-level eligibility. Check that your site is a full domain or subdomain, not a subdirectory of a larger property. Subdirectories are excluded outright, so there’s no implementation that works around this.
- Check the source preferences tool. Enter your URL at Google’s source preferences tool to see how your domain currently appears before you add anything.
- Add the script tag once, site-wide. Put
<script async src="https://news.google.com/swg/js/v1/publisher.js"></script>in your global head/layout template so it loads on every page, not just the ones with a button. - Place the button where readers actually decide to trust you. Near the byline or publish date on article pages works better than burying it in a footer — the moment someone finishes an article they liked is the moment they’re most likely to click it.
- Verify rendering and performance. Load the page, confirm the button renders in the right language and theme, and re-run PageSpeed Insights or Lighthouse to confirm the async script hasn’t touched your Core Web Vitals.
What this means for AI search visibility
The reason this is worth doing now rather than filing it under “nice to have” is the AI Mode and AI Overviews mention in Google’s own documentation. Search is splitting into two behaviors: the classic list of blue links, and a generated answer that cites a handful of sources directly. Preferred Sources is Google’s first explicit mechanism for readers to influence which sources get pulled into that second behavior for topics they follow.
In my experience auditing sites for AI visibility, the sites that show up consistently in generated answers are almost always the ones with the strongest combination of topical depth and reader trust signals — not necessarily the highest-authority domain in a generic sense. A reader-driven preference signal fits that pattern exactly: it rewards depth on a specific beat over general size. If you publish consistently in a specific niche — technical SEO, a vertical, a specific industry — this is a low-cost way to convert loyal readers into a ranking signal Google didn’t offer a year ago.
It’s also nearly free to test. The implementation is two lines of code, it doesn’t touch your existing schema or content strategy, and it has no downside if adoption turns out to be low. Ship it, give it a quarter, and check whether it moves the needle on your AI Overviews and Top Stories appearances using whatever AI visibility tracking you already have in place.
Frequently Asked Questions
Does adding the Preferred Sources button guarantee I’ll appear in Top Stories or AI Overviews?
No. The button only lets readers register your domain as a preference — it doesn’t change your ranking, crawlability, or content quality signals. Google still decides eligibility for Top Stories and AI Mode the same way it always has. Think of it as a distribution boost on top of rankings you’ve already earned, not a replacement for them.
Can a blog running on a subdirectory, like example.com/blog, use Preferred Sources?
No. Google restricts the feature to domain-level and subdomain-level sites — example.com or blog.example.com qualify, but example.com/blog does not. If your content lives in a subdirectory of a larger site, this feature currently isn’t available to you no matter how you implement the script.
What’s the difference between the standard embed and the deeplink method?
The standard JavaScript embed (two lines: a script tag plus a div) renders an official, auto-localized button that lets readers add your site without leaving the page. The deeplink method is a plain link to Google’s source preferences tool with your URL pre-filled — no JavaScript required, but it sends the reader off-page and requires a manual click-through instead of an inline widget.
Will the preferred sources script slow down my site or hurt Core Web Vitals?
It shouldn’t, if implemented correctly. The script tag uses the async attribute, so it downloads without blocking rendering and doesn’t compete with your largest contentful paint element. As always, verify with PageSpeed Insights or Lighthouse after adding any third-party script — but this one is designed to be lightweight.
Is this the same as Google News or Publisher Center?
No. Preferred Sources is a separate, newer mechanism that doesn’t require Google News enrollment or a Publisher Center account. It works off simple domain eligibility, which is what makes it accessible to sites that were never part of the traditional Google News ecosystem.
