How to Become a Preferred Source in Google Search: A Practical Publisher Guide
Google Preferred Sources is a reader choice, not a ranking switch. Here is the practical implementation: eligibility, the official deeplink, what the badge can change, and how to measure whether useful readers are returning.
Google Preferred Sources gives readers a way to tell Google that they want to see more from a publication. It is not an SEO switch, a paid placement, or a way to force a result into an AI Overview. It is a preference a reader makes.
That distinction matters. The durable work is still publishing material people return to because it answers a real question better than a generic summary can. Preferred Sources is a useful bridge between that returning reader and the place where they search for the next answer.
What the feature actually changes
When a reader selects a publication as a preferred source, Google may highlight that source in Top Stories. Google also says the preference can be reflected in AI Mode and AI Overviews where those features are available. The important verbs are may and can: eligibility and reader choice improve the chance of discovery; they do not replace relevance, crawlability, or editorial quality.
The feature is domain- and subdomain-level. A site can be eligible as https://2run.be/; a path such as https://2run.be/en/blog is not a separate preferred source. That is why the right implementation points at the root domain, even when the call to action lives beside articles.
Start with the reader, not the badge
The best placement is where a visitor has already received value: on a blog index, after an article, in a newsletter, or on a topical landing page. The copy should be plain:
- explain that it opens Google’s preference tool;
- name the publication the reader is adding;
- keep the action optional; and
- return the reader to the article or let them continue browsing.
We use Google’s official deeplink format on the 2Run blog. It sends the reader to Google’s source-preferences tool with the 2Run domain already selected:
https://www.google.com/preferences/source?q=https%3A%2F%2F2run.be
This approach does not add a third-party script to every page and keeps the final selection in the reader’s hands. Publishers that want Google’s native localized button can use the official JavaScript integration instead.
The editorial work comes first
For a technical studio, a preferred source is earned through a body of work that makes a clear promise and keeps it. That means:
- Publish specific, dated engineering decisions instead of generic trend summaries.
- Link to the primary source when writing about a standard, security bulletin, or platform change.
- Show the trade-off and the verification step, not only the finished architecture.
- Give each article a descriptive title, canonical URL, author, publication date, and a useful excerpt.
- Keep related articles discoverable through internal links, RSS, and a sitemap.
The goal is not to write for a crawler. It is to make the next reader’s decision easier: can this team explain a complicated production concern clearly and back it with evidence?
What to measure
Do not infer success from a badge appearing in a screenshot. Track the things a publisher can actually control:
- Search Console impressions and clicks for the article cluster.
- Returning visitors to the blog and newsletter sign-ups after a useful article.
- Referral sessions from the Preferred Sources deeplink, with privacy-respecting analytics.
- Whether article pages remain indexable, canonical, fast, and valid after deployment.
Google’s documentation is explicit that a site does not need to implement a button or deeplink in order to be eligible. The implementation is an audience-development tool, not an indexing requirement. Treat it that way and it stays useful even as Search presentation evolves.
Sources: Google Search Central: Preferred Sources, Google source-preferences tool.