Google’s Preferred Sources embed is the closest thing yet to a one-click follow button for a news publication. A reader lands on your site, taps the embedded button, confirms their choice on a Google screen that already has your publication identified, and lands back on the article. For publishers trying to build loyal audiences inside Google’s search surfaces, removing that extra confirmation step can meaningfully change how many readers actually finish the action.
The embed is a JavaScript-rendered control that works with Google’s existing Preferred Sources setting. When a signed-in Google user taps it, Google opens a publication-specific confirmation page. The reader only has to tap Add, and Google returns them to the page they were reading. Previously, the closest alternative was a deeplink to Google’s Source preferences tool, which left the reader with more decisions and no automatic return path. The difference seems small at first, but it is precisely the kind of friction reduction that improves completion rates for low-effort actions.
What the Google Preferred Sources Embed Does for Repeat Visibility
Preferred Sources tells Google that a particular user wants to see more from a specific publication when it is relevant to a query. It does not change rankings for every user, and it does not force your content into Top Stories. It increases the likelihood that the person who selected your publication will continue to encounter it in Top Stories, AI Overviews, and AI Mode, depending on what those surfaces support in their location.
What is the Google Preferred Sources embed? The embed is a JavaScript button that opens a publication-specific preferences page. The reader taps Add and is returned to the page they were reading. It reduces the process of adding a publication as a Preferred Source to a single action after the reader taps the button on your site.
Google’s documentation places the setting within personalization rather than core ranking. That distinction matters for publishers. The feature does not replace relevance thresholds or content quality requirements. What it does is create an audience-level affinity signal between a reader and a publisher. For smaller newsrooms, this can be more useful than a temporary traffic spike, because it builds repeat exposure among readers who intend to come back. The embed simply lowers the cost of making that intention concrete.
Confirm Your Publication Is Eligible Before Adding the Button
Start by searching for your publication in Google’s Source preferences tool at https://www.google.com/preferences/source. If your publication does not appear in the results, adding the embed to your site will not make it eligible. The button is a control for an existing feature, not a way to force Google to recognize a domain that is not available in the preferences system.
Google supports full domains and subdomains, but not subdirectories.
- Valid: example.com
- Valid: news.example.com
- Not valid: example.com/news
If your publication is served from a subdomain, use that subdomain in your testing and in any deeplink. Do not assume the root domain is interchangeable with a newsroom subdomain, because Google’s preferences system treats them as different hosts.
Why the Standard Embed Beat the Deeplink in My Mobile Test
I tested both routes on mobile. With the embedded button, Google opened a page that already identified the publication. The page presented a single Add control. After tapping it, Google returned me to the article. The flow felt like a native app confirmation rather than a web-based settings screen.
The deeplink opened the general Source preferences screen. The publication name was pre-filled in the search box, but the checkbox next to it was still unchecked. I had to select the box, and Google did not automatically navigate me back to the article. That extra step is enough to make a casual reader abandon the flow.
The standard JavaScript button should be your default because it is localized automatically and returns the reader to the page where they started. The deeplink is still useful in email, social posts, or a CMS where you cannot add JavaScript. Just do not expect the same completion rate from it.
How to Add the Standard Preferred Sources Button
Load the Google publisher library once across your site, ideally in the application shell, theme, or a small site plugin. Place it in the document head so the button can render as soon as the container appears.
<script async src=”https://news.google.com/swg/js/v1/publisher.js”></script>
Then place the button container wherever you want the control to appear.
<div google-add-preferred-source-btn></div>
The library detects the attribute and renders the interface. You do not need to hard-code the publication’s domain into the standard button. The library uses the page’s host to determine which source to show.
Choose a Light or Dark Theme
The light theme is the default. If your page uses a dark background, add the data-theme attribute.
<div google-add-preferred-source-btn data-theme=”dark”></div>
Override Language Only When Necessary
The button uses the reader’s browser language by default. If a page requires a specific supported language, add the data-lang attribute.
<div google-add-preferred-source-btn data-lang=”fr”></div>
Use the language override sparingly. Matching a reader’s interface language creates less friction than forcing a site-wide language, especially on internationally distributed websites.
Use the Deeplink When You Cannot Load JavaScript
The deeplink is a normal URL that works without JavaScript in any CMS, email, or HTML editor.
https://www.google.com/preferences/source?q=example.com
You can present it as an ordinary link labeled Add Example as a Preferred Source, or drop it directly into a social post. The same URL works in page content and promotional materials because it carries the publication’s domain as a query parameter.
The deeplink preserves the search query, so the reader does not have to type the domain. It just does not save them from selecting the source or navigating back to your page. That makes it a useful fallback rather than an equal alternative.
A WordPress Widget That Loads the Button Only When Needed
WordPress sites can wrap the Preferred Sources button in a native widget. The widget described here registers a new widget area control, lets editors choose between light and dark themes, and offers left, center, or right alignment. It loads the Google publisher library only when the widget is active, so sites with multiple page templates do not pay a script cost everywhere.
The widget class is registered with a name such as Google Preferred Sources. In the widget form, the editor selects the color theme and alignment from dropdown menus. The widget output renders the standard button container with the selected data-theme attribute and a wrapper class that controls alignment.
The essential rendering logic follows the same pattern used elsewhere on the page:
$theme = isset( $instance[‘theme’] ) && ‘dark’ === $instance[‘theme’] ? ‘dark’ : ‘light’;
$alignment = isset( $instance[‘alignment’] ) && in_array( $instance[‘alignment’], array( ‘left’, ‘center’, ‘right’ ), true ) ? $instance[‘alignment’] : ‘center’;
echo $args[‘before_widget’];
echo ‘<div google-add-preferred-source-btn data-theme=”‘ . esc_attr( $theme ) . ‘”></div>’;
echo $args[‘after_widget’];
A companion script loader checks whether the widget is active before enqueuing the publisher library. That keeps the front end light on pages where the button does not appear.
How to Track Preferred Sources Button Clicks in GA4 and GTM
Because Google renders the button after the page loads, normal click tracking can miss the interaction. A delegated click listener catches the event after it bubbles up from the dynamically rendered button. The listener looks for an element with the google-add-preferred-source-btn attribute and then fires an analytics event.
Choose a single event name and stick with it. A practical choice is preferred_source_button_click.
If a Google Tag Manager container is present, the listener pushes one event to the default dataLayer:
window.dataLayer.push( { event: ‘preferred_source_button_click’ } );
In GTM, create a Custom Event trigger named preferred_source_button_click and use it to fire a GA4 Event tag with the same event name. If GTM is not detected but gtag.js is installed, the listener falls back to the gtag event command:
window.gtag( ‘event’, ‘preferred_source_button_click’ );
The click event confirms that the reader entered the Preferred Sources flow. It does not confirm that the reader finished the selection inside Google. Treat the data as a measure of engagement with the button, not as a substitute for Google’s own reporting. Use GTM Preview or GA4 DebugView to validate the event before publishing the change.
Why This One-Click Change Matters for Audience Strategy
The bigger shift here is subtle. Google is not giving publishers a better ranking lever; it is giving them a better relationship lever. The embed turns a generic settings screen into a confirmation that feels attached to the publisher’s own site. When readers can opt in with a single tap, they are more likely to act, and that act of choice is exactly the kind of signal Google’s personalization systems are designed to use.
For publishers, the practical step is straightforward: confirm that the domain appears in Google’s Source preferences tool, load the publisher library once, place the button in a visible location, and measure how often readers start the add flow. The light and dark themes make it easy to match existing design patterns, and the deeplink covers email and social channels where script-based controls cannot run.
Preferred Sources was never designed to override content quality or relevance. It was designed to let readers say who they want to see more from. The embed lowers the effort required to say that, which makes it a small but genuinely useful addition to the toolkit of any publisher that values returning readers over one-time visits.