BlogFindings
Google shipped a preferred sources button, and a plain URL for sites that block third party scripts
Google Search Central updated its preferred sources documentation on 20 August 2026 to add an interactive button that loads a script from news.google.com, and named a plain URL alternative for sites that cannot run third party scripts.
This is a reporting post rather than a measurement. Lantad measures whether an AI crawler can obtain and read a page, which is one layer of the AI visibility chain. A preferred sources button is a user action rather than a crawl signal, so nothing below is a finding by us about whether the button lifts anyone's citation rate. What we can add is what changes on the page a crawler reads and what does not, and which surfaces Google names for the badge.
In short
- Google's Search Central documentation update log carries an entry dated 20 August 2026 UTC that adds instructions for a new interactive preferred sources button publishers can embed on their own pages.
- The button is one div carrying the attribute google-add-preferred-source-btn plus one async script loaded from news.google.com/swg/js/v1/publisher.js, with two documented data attributes on the div, data-theme and data-lang.
- The same docs page names a plain URL alternative for sites that cannot use JavaScript, of the form https://www.google.com/preferences/source?q=Your_Website's_URL, which opens the source preferences tool without embedding any third party script.
- Only domain-level and subdomain-level sites are eligible per Google's own wording, so a publication that lives at a subdirectory such as example.com/blog is not eligible as its own source.
- The preferred badge appears in Top Stories, AI Mode and AI Overviews per Google's docs page dated 20 August 2026, and the effect is a per-user preference stored on a reader's Google account rather than a signal a crawler could read from your server.
Flow: Publisher page to google-add-preferred-source-btn; Publisher page to Deeplink to www.google.com/preferences/source; google-add-preferred-source-btn (loads) to publisher.js from news.google.com; publisher.js from news.google.com (on click) to Google source preferences tool; Deeplink to www.google.com/preferences/source (on click) to Google source preferences tool; Google source preferences tool (reader confirms) to Preferred badge in Top Stories, AI Mode, AI Overviews.
What Google's changelog said and what the docs page shows
The changelog entry itself is one sentence. Google's Search Central documentation updates page, read on 20 August 2026, records under that day's date, verbatim: "Updated the preferred sources documentation to include instructions on how to add the new custom, interactive button to your site." The entry heading and the docs page footer carry the same date, 2026-08-20 UTC.
What preferred sources is has been in Google's documentation since summer 2025 for one surface and since spring 2026 for two more. The original preferred sources launch post on blog.google is dated 12 August 2025 and states that "Preferred Sources is available starting today for all users in the U.S. and India" as a Top Stories treatment that a user can opt into after a Search Labs experiment. A follow-up post on blog.google dated 27 May 2026 extended the feature to AI Overviews and AI Mode, and states that "people are twice as likely to click through to a Preferred Source, and people have already selected more than 345,000 unique sources". Both figures are Google's own, attached to that May 2026 post and repeated here on that attribution.
What today's update adds is on the publisher side rather than the reader side. The preferred sources documentation page, as it stood on 20 August 2026, describes an embed a publisher can drop into their own pages so that a reader can add the site with one click without navigating to Google's source preferences tool first. The mechanism is HTML, and it comes in two forms that are documented on the same page as alternatives rather than as a preferred form plus a fallback.
developers.google.com, preferred sources docs pair
- /search/updates entry, 2026-08-20 adds new interactive button instructions
- /search/docs/appearance/preferred-sources footer Last updated 2026-08-20 UTC
- docs section, add a script tag to your page's head JavaScript implementation
- docs section, use a deeplink if you can't use JavaScript plain URL alternative
One div, one script, and two attributes
The JavaScript form is a two-line embed. The docs page names one script tag, added asynchronously to the page's head, and one div, added to the page body carrying the attribute google-add-preferred-source-btn. The script is loaded from news.google.com/swg/js/v1/publisher.js, a Google-owned host that ships the Subscribe with Google client library. That library reads the div, renders a button in place, and handles the click.
Two attributes on the div are documented, both optional. data-theme takes light or dark and picks a palette. data-lang takes a language code and overrides the button label. The docs give no restriction on button size, no ceiling on how many buttons a page may carry, and no guidance about pairing the button with anything else on the page. The button is a self-contained widget that runs wherever the publisher puts the div.
Two properties of this form are worth naming for a site owner deciding whether to add it. First, it loads and runs a third party script from a host outside the site's own origin. That is a script src that a Content Security Policy must allow, either by naming news.google.com in the script-src directive or by using a hash or a nonce. A site with a strict CSP that does not currently list news.google.com will fail to render the button until the policy is updated, and the failure mode is silent because the div stays but the library never attaches. Second, because the script runs on the client, the widget does not exist in the initial HTML that an AI crawler receives without a browser. A JavaScript-blind fetch of the page returns the div and nothing to fill it. That changes nothing about whether Google itself can see the page, because Google's own crawler renders, and it changes nothing about whether an assistant will cite the page, because the button is a user control rather than content. But it does mean the button chrome is invisible to any client reading the page as raw HTML. That is the same client stance that produced the case where hydration JSON scored the same as no text at all in our July capture, and the reason JavaScript added no new crawl paths on the pages we walked in the same window.
preferred sources button, JavaScript implementation
- <script async src="https://news.google.com/swg/js/v1/publisher.js"></script> third party script, loaded async
- <div google-add-preferred-source-btn></div> empty div, rendered by the library
- data-theme="dark" or data-theme="light" optional palette
- data-lang="en" or another supported code optional button language
- CSP script-src must allow news.google.com or the button fails silently
The plain URL alternative for sites that block third party scripts
The alternative is one link. The docs page states, verbatim: "If you can't use JavaScript on your website, you can alternatively use a deeplink to direct your users to the source preferences tool." The URL format follows: https://www.google.com/preferences/source?q=Your_Website's_URL. Substituting a publication's domain for the placeholder gives a link that opens Google's source preferences tool with that publication preselected. This post cites the URL in plain text rather than as a link because google.com is not among the outbound hosts our methodology registers as followed; the classification of every outbound host on this site is data in one file rather than a decision typed per link, and www.google.com sits outside that register.
The two forms are not equivalent for the reader. The JavaScript button renders in place and does not require the reader to leave the page they are on. The deeplink is a hyperlink that opens Google's own tool, from which the reader confirms and then returns. That is one extra step, and it is the cost of not shipping a third party script on your own domain. It is also the form that any site with a strict CSP, a no-third-party-script principle, or an audience that runs a blocker on Google's script infrastructure can offer without a policy change or an exception.
For a site already comfortable running Google-hosted scripts, both forms will work, and the button is the shorter path for a reader. For a site whose engineering standards or regulatory posture rules out embedded third party code, the deeplink means the feature is still available with a single anchor tag. Either way the effect is a per user preference stored on the reader's Google account. The button and the deeplink both hand the reader to the same tool. What Google decides to do with the resulting preference sits inside its own product, and neither form affects whether Googlebot can crawl the page, whether an AI crawler receives the text at all, or whether the structured data on the page parses.
JavaScript button
- One div plus one async <script> from news.google.com
- Renders in place, no navigation for the reader
- Third party script src, needs CSP allowance
- Two optional attributes: data-theme, data-lang
- Silent failure when the script is blocked
Deeplink
- One <a href> to www.google.com/preferences/source?q=DOMAIN
- Opens Google's source preferences tool for the reader
- No third party script on your page
- Works when CSP or a blocker rules out the button
- One extra step before the preference is stored
Three surfaces, one badge
The preferred badge is not one surface. The docs page lists three, and the reach on each is described in Google's own words. Verbatim: "The preferred sources feature is available globally for the 'Top Stories' feature in all languages where Google Search is available." Top Stories is the news carousel that appears above traditional Search results on eligible queries. Verbatim: "Preferred sources can also appear in AI Mode and AI Overviews in all languages and locales where those features are available." AI Mode is Google's conversational Search surface, and AI Overviews is the generative summary block above the ten blue links.
The two AI surfaces are the ones that map to the visibility work this blog is about. Getting cited by Google AI Overviews is a distinct problem from getting cited by ChatGPT search or by Perplexity, because each of those engines picks retrievals under its own rules and each publishes its own crawler token list, which we render on our AI crawlers reference. Preferred sources is a Google-only mechanism. Its badge and its selection tool live inside Google, and no click on the button on your page affects whether any other engine retrieves you, cites you, or notices you at all.
The docs describe the badge as a treatment for readers who have already chosen the source rather than a change to ranking or eligibility for anyone else. On the docs page as it stood on 20 August 2026, there is no statement that the presence of the button on your site or the volume of button clicks feeds any ranking model, and there is no statement that opting in tips retrieval in your favour for readers who have not opted in. The lever the button offers a publisher is opt-in reach on already-interested readers, not more retrievals by any crawler.
| Surface | What it is | Availability per the docs |
|---|---|---|
| Top Stories | News carousel above Search results | All languages where Google Search is available |
| AI Mode | Conversational Search surface | All languages and locales where AI Mode is available |
| AI Overviews | Generative summary above the ten blue links | All languages and locales where AI Overviews is available |
Domain and subdomain, never a subdirectory
The eligibility rule is one sentence and it matters for anyone whose publication lives on a subpath rather than a subdomain. The docs state, verbatim: "Only domain-level and subdomain-level sites are eligible to appear in the source preferences tool. For example, https://www.example.com/ and https://code.example.com/ are eligible for preferred sources, but the subdirectory https://www.example.com/blog isn't eligible." The example URLs are Google's, not ours.
That granularity has consequences. A brand that runs its magazine at brand.example.com can be selected as a preferred source separately from the rest of the site, and a reader who wants the magazine but not the marketing home page has a way of saying so. A brand that runs the same magazine at example.com/magazine cannot be selected at that grain, and a reader who chooses the domain gets everything on it. From the reader's side the two URL shapes look interchangeable. From this feature's side they are not. It is the sort of URL-shape decision that used to be about SEO taxonomy alone and is now also about which reader-facing controls Google will honour for your content.
The eligibility rule interacts with a second line from the same May 2026 post on blog.google: "Any website that publishes fresh content is eligible." Read together, the two say that the fresh-content bar governs whether a domain is ever a candidate, and the domain-or-subdomain rule governs the granularity at which a candidate can be picked. Neither rule is a schema check, a robots setting, or anything that shows up in the HTML a crawler receives. Both are administrative properties of the URL shape and the publication cadence, and both are decided long before the button or the deeplink comes into it. If those two conditions are met, a site is choosing between the JavaScript form and the plain URL form. If they are not, neither form has anything to attach to, because the source will not appear in the picker for the reader to confirm.
-
https://www.example.com/Eligible Root of a domain. Selected as a preferred source at the domain grain. -
https://code.example.com/Eligible A subdomain. Selectable separately from the parent domain. -
https://www.example.com/blogNot eligible Subdirectory of an eligible domain. Google's own example of what does not qualify. -
Any website that publishes fresh contentDomain candidate The May 2026 blog.google post states the freshness bar. Not a schema, robots or markup check.
A user preference is not a crawl signal
This blog has written before about the gap between a feature a publisher can add markup for and the feature actually shipping. When Google deleted the FAQ rich result documentation in June 2026, the FAQPage markup on millions of pages did not stop parsing and did not stop being credit-worthy in our scanner's schema check, because the check credits FAQPage as one of five recognised business types and its required property, mainEntity, is what the type has to have to be well formed at all. The feature moved. The markup did not, and the site owner had to decide whether to keep it, remove it, or leave it alone.
Today's preferred sources update is close to the mirror image. There is no schema-level change and no crawler-level change; there is a new user-facing lever that a publisher can put on their own page. Our robots.txt tester will return the same verdict for a page whether or not the div is present. Our prose parity reading of that page will return the same score. Our bot documentation will still declare the same LantadBot user agent, and nothing in the score composition changes for this. That is not a limitation to work around; it is the honest shape of the change. A user preference stored in someone's Google account is invisible from outside their session, and no page-level scanner can tell you whether any given reader has flipped the switch in your favour.
What is worth doing with the update is small and concrete. Decide which form fits your Content Security Policy and your third party script principles. Add the div or add the deeplink. Confirm you meet the two prior conditions, freshness and a domain-or-subdomain URL shape. And treat the button as one channel among several rather than a substitute for the AEO and GEO work that decides whether an engine has anything worth citing in the first place. A reader who never saw your page does not get to press your button, and no widget makes up for the layer below it.
- The div, once the page is fetched with a browser Rendered HTML contains the div and the button chrome the library attaches to it.
- The script tag in the head One <script async src> pointing at news.google.com/swg/js/v1/publisher.js, visible in the initial HTML.
- Whether the button is visible to a JavaScript-blind client The div is in the HTML; the button chrome is not, because the library runs on the client.
- Whether any given reader has selected the source Preference stored on the reader's Google account. Not observable from outside the reader's session.
- Whether the site meets the eligibility rules Freshness and domain-or-subdomain URL shape are administrative properties of the publication, not markup on the page.
- Whether the badge shows for readers in Top Stories, AI Mode or AI Overviews Rendered by Google on Google surfaces, decided per reader. No page-side scan can tell you.
Lantad
Published .
Google Search Central's documentation update log carries one entry dated 20 August 2026 UTC, and its subject is a widget rather than a specification. The preferred sources documentation now carries a section on adding an interactive button that a publisher can embed on their own pages so that a reader can click once to mark that site as a preferred source. The docs page also names a plain URL alternative for sites that cannot or will not run third party scripts.
Common questions
Does Lantad measure whether readers have selected my site as a preferred source?
No. The selection is stored on each reader's Google account and only affects surfaces Google renders for that reader. No page-level scan of your site can read another user's account state, and nothing in Lantad's scoring is changed by adding the preferred sources button or the deeplink to a page.
Do I need to add the JavaScript button to be eligible for preferred sources?
No. Eligibility is decided by the domain-or-subdomain URL shape and by publishing fresh content, both stated in Google's own documentation and blog posts. The button is a shortcut that lets a reader select your site from your own page rather than from Google's source preferences tool. The deeplink is a plainer shortcut that works without any third party script.
Does the preferred badge appear in AI Overviews?
Yes, per Google's preferred sources documentation dated 20 August 2026, which states that preferred sources can appear in AI Mode and AI Overviews in all languages and locales where those features are available, in addition to Top Stories. The badge shows for readers who have already selected your site; it is not shown to readers who have not.
Can a page hosted at a subdirectory such as example.com/blog be a preferred source?
No. Google's docs state that only domain-level and subdomain-level sites are eligible, and use example.com/blog as their own example of a subdirectory that does not qualify. A publication hosted at a subdomain such as blog.example.com is eligible; the same publication hosted at example.com/blog is not.
See what AI can read on your site
Run a free scan and get a graded report of exactly what AI crawlers can and cannot read, with ranked fixes.
AI crawler
An AI crawler is an automated bot, such as GPTBot, ClaudeBot, or PerplexityBot, that fetches web pages so an AI system can read, train on, or cite what those pages contain.
AI visibility
AI visibility is whether AI systems can access, read, and faithfully represent your web pages, the prerequisite for being cited in an AI answer.
Structured data for AI (schema markup)
Structured data is schema.org markup, usually written as JSON-LD, that labels a page's facts in a machine-readable format so AI systems can extract and attribute them without having to interpret the surrounding prose.
Google deleted the FAQ rich result documentation, and we still score FAQPage
Google's documentation changelog records the FAQ rich result leaving Search on 7 May 2026 and its documentation being removed on 15 June 2026. Read on 5 August 2026 the old URL answers 301, schema.org still defines FAQPage, and Lantad's schema check still counts it as a recognised business type.
JavaScript added no new crawl paths, and rendering dropped nine locale links
Counted with an HTML parser over five real pages this scanner captured and stored on 15 July 2026, the raw HTTP response held 991 distinct same-host URLs and the rendered DOM held 982. Three URLs existed only after JavaScript ran, and every one of the three was a rewrite of a link already present. Nine of the twelve that disappeared were one page's translations of itself.
Text in hydration JSON scored the same as no text at all, both F at 34.4
Two golden fixtures stored in this repository produce an identical composite of 34.4, an identical grade of F, and identical access, structure and schema sub-scores. One of them ships zero words in its initial HTML. The other ships all 485 of them, inside a JSON payload. The only stored number that separates the two is retrievability, and retrievability is worth nothing in the grade.
