Feature
Embed Google’s Preferred Sources Button Without Misreading the Results
Check site eligibility, install Google’s Preferred Sources button, choose a deeplink fallback, and measure flow starts without claiming completed additions.
Impetuous · · 4 Min Read

Use Google’s standard JavaScript button on a website that supports it; use a deeplink in newsletters, social posts or a CMS that cannot load the library. The embedded button lets readers add your publication as a preferred source and return to the page they were reading. It is a reader-personalization control, not a site-wide ranking upgrade.
As of October 5, 2026, Google’s publisher documentation says selected sources are more likely to appear in that reader’s Top Stories, with a preferred badge. Selected sources can also receive a preferred badge in AI Mode and AI Overviews where those features are available. Selection does not guarantee an appearance in Top Stories, as Search Engine Journal explains.
Check the publication’s host first
Before changing a template, search for your publication in Google’s source preferences tool.
Google supports domains and subdomains, not subdirectories. For example:
example.comis an eligible site format.news.example.comis an eligible site format.example.com/blogis not a separately eligible source.
A publication under /blog therefore needs to promote its eligible host, not the blog path. If it operates on a subdomain, check that specific host. Eligibility by URL format does not establish that the publication actually appears in the tool. Search Engine Journal’s walkthrough warns that adding the button does not resolve an absent site’s eligibility problem.
Google also says eligibility for preferred-source display in AI Mode and AI Overviews requires the site to be included in Search generative AI features through Search Console. Keep that setting separate from the button installation.
Install the standard button
The standard integration has two parts: Google’s asynchronous publisher library and a container marking where the button should render. Copy the two installation lines from Google’s standard implementation instructions, then:
- Load the library once through the shared site template, application shell or a small CMS plugin. Google recommends placing it in the document head.
- Place the button container in the article template where readers will see the invitation. The library finds the
google-add-preferred-source-btnattribute and renders Google’s interface. - Match the background. The default theme is light; set
data-themetodarkfor a dark background. - Leave localization automatic unless there is a reason to override it. The standard button uses the reader’s browser language. Set
data-langto a supported language code when an explicit override is needed.
The standard button does not require a hard-coded publication domain, as Search Engine Journal’s implementation guide notes. In WordPress, keep the shared library loading separate from the widget or template placement; avoid installing multiple integrations for the same control.
For a custom interface or framework application, Google documents an advanced SDK with ES module and callback-queue options. Its init and addPreferredSource methods provide programmatic control. Use that route when custom triggers are necessary, rather than adding complexity to an otherwise straightforward template.
Use a deeplink where embedding is unavailable
A deeplink sends readers to Google’s source preferences tool with your publication identified by the q query parameter. For a hypothetical publisher, this example targets example.com. Replace that target with the publication’s eligible domain or subdomain.
The flows are not identical. In Search Engine Journal’s reported mobile test, the embed opened a publication-specific confirmation, required an Add action and returned the reader to the article. The deeplink still required selecting the publication’s checkbox and did not automatically return the reader. That supports choosing the embed for web pages and retaining the link for email and social distribution.
Verify the flow, then measure starts—not additions
Before rolling the button out across every article, test a representative production page:
- Confirm that the button renders on mobile and desktop, with readable contrast.
- Check that the flow identifies the intended publication and returns to the article after confirmation.
- Inspect failed network requests, console errors and layout movement if rendering breaks.
- If tracking clicks, use GTM Preview or GA4 DebugView to verify that one activation produces one analytics event.
Treat preferred_source_button_click as a flow-start event, not a completed source selection. Search Engine Journal explicitly makes that distinction in its GA4 example. The event records activation of the invitation; it does not prove that Google’s flow loaded successfully or that the reader completed it. A click, or a return to your article, should not be reported as a confirmed addition.
A proposed placement test could compare an end-of-article invitation with a sidebar placement. Record button exposures and flow starts, and monitor loading and layout regressions. Use a predeclared content experiment to keep the decision rule clear. Even a higher flow-start rate demonstrates more reader engagement with the invitation—not a measured search-traffic lift.