You should first read about the article Chrome experiment to let you Follow websites before you keep reading this one. This article goes deeper into the technical details of how Chrome WebFeed works.
Chrome detects all Atom and RSS feeds on webpages using the feed auto-discovery mechanism. Here’s a quick refresher if you’re unfamiliar or have forgotten it in the last decade:
<link rel="alternate"
type="application/atom+xml"
<!-- or type="application/rss+xml" -->
href="/news-feed.atom">When any feeds are detected on a page, Chrome sends the feed addresses and page address to a Google server. This server then tells Chrome which of the feeds Google recommends and whether that feed is actively updated. Chrome uses this information to decide on whether to prompt the user to follow the website.
Chrome also receives the site’s name for use in user interfaces related to feed management from Google’s servers. It uses the site’s domain name as a fallback. Chrome will also try to detect the largest icon from the page (<link rel="icon" […]>) instead of using icons specified in the feed. Chrome never actually downloads the feed locally.
The client-side implementation is open-source and available to other Chromium-based web browsers such as Brave, Microsoft Edge, and Vivaldi. However, don’t expect any of the other browsers to introduce a feed aggregator in a future release. They’d have to invest in and reimplement the server-side component that makes WebFeed work. Brave and Edge already have their own news feed systems and are unlikely to build on Chrome’s implementation. Brave is notably working on support for adding custom syndication feeds, but it requires manual entry of feed addresses (with all the usability issues that entail).
Web authors and content management systems — including the ever-popular WordPress — often publish two identical syndication feeds. These feeds represent the same updates in the newer Atom and the legacy RSS formats. As Nick Bradbury put it to web authors over a decade ago: “Pick a Format (Any Format)”. Most feed aggregators support both formats (and more to boot), so it doesn’t matter which one you pick.
Websites also frequently publish multiple feeds, e.g. one per category or author, which can confuse things further. Chrome solves the multi-feed problem by letting Google’s servers decide which feed to follow based on its knowledge of the website.
The current implementation restricts websites to one feed per domain. For example, individual topic pages here on Ctrl blog use the feed auto-discovery mechanism to point to a topic-specific feed. Google’s servers currently always return the main/everything feed for the whole site even though it’s not even included on the topic pages. This may change in the future, however. I find it likely that Chrome will want to enable people to only subscribe to the Sports section of their favorite newspaper, for example. Chrome needs to find a better solution for this to tackle social media websites with multiple feeds and creators. The current user experience on sites like YouTube, Twitter, and Facebook is underwhelming and confusing.
Feeds commonly include tracking parameters in their links to help the websites measure the popularity of their feeds. Google’s FeedBurner service was built to serve that tracking need. Instead of presenting the link in the feeds, Chrome replaces it with a canonicalized links. It also sets the HTTP Referer (sic) request header to https://www.google.com/. Clicks from WebFeed are indistinguishable from clicks from Google Discover and Search. Websites can still track their clicks and impressions under the Discovery Performance tab in the Google Search Console.
Google announced last month that it would blow new life into FeedBurner after ignoring the service for over a decade. Chrome’s renewed interest in the technology is likely why Google rediscovered it owned one of the web’s largest feed service providers. FeedBurner’s existing click-through and impression tracking will presumably be augmented with data from Google Search Console in the future.
Chrome doesn’t act like a traditional feed aggregator. Your feed subscriptions are processed on Google’s servers, and Chrome just gets a sanitized presentation of your feeds. There’s nothing wrong with this architecture per se, but Google remains in control of your feed. Google prioritizes the order of items that appear in your aggregate feed. The aggregated news feed is — for the most part — sorted chronologically. However, Google does move some things around to ensure that one chatty feed doesn’t dominate your aggregate feed.
There isn’t much you can do to optimize your syndication feeds to work with Chrome WebFeed. Your feed must meet the format requirements for your chosen feed format. Each feed entry must contain a link, title, and the date it was published or updated. Google only uses the feed to detect when you publish new content on your website.
There’s one small optimization you can deploy, however. You can make your feeds update faster for Chrome users by building in support for WebSub. WebSub is an open standard that turns syndication feeds from a pull to a push media.
Google will pull images, titles, and the lead paragraph or description from your webpages. Make sure to mark up your pages with semantic HTML and use structured metadata. Proper semantics will help Googlebot understand your pages and help make sure they’ll appear in Chrome WebFeed. Any type of webpage is eligible for inclusion, it’s not just for news articles and videos.