Designing for the Copy That Leaves Your Site
When designing content, the version of a page that appears on screen is not the only format that matters. Readers can also access a clean text version in a browser’s "reader…

When designing content, the version of a page that appears on screen is not the only format that matters. Readers can also access a clean text version in a browser’s "reader mode", any browser stores a print output version, and Google itself indexes a version of its own for search. These renderings can create multiple conflicting versions of a page–here's how to design content that survives canonicalization, print, and “reader mode”.
A page’s screen layout isn’t the only version of its content., Google Chrome's Reader Mode, Firefox's Reader View, Safari's Reader — all browser variants share this classic remove-distractions feature.
That means any boring marketing-text headers, outdated blog sidebar ads, or overall page layout can theoretically be skipped by a browser's built-in text extraction features. This includes print output, which has to download a stylesheet separate from the visible screen layout.
That's the problem: The version of content that stays with the page, that doesn't get sliced off, is the representative canonical copy — and its integrity is worth defending, as Google, the IETF, and browser vendors all define "canonical" in the first place.
Canonical links are the extraction control
[A screen snapshot of Canonical Link Tag in Service Worker Standard] Image from ServiceWorker Standard
That's because the canonical link tag, a meta tag, is not merely an SEO contrivance. It is a formal Web standard. The canonical link is a site's representative copy, the source of truth that the extensible Web should in theory render to browsers.
...as the Internet Engineering Task Force's specification on the link relation says, "the <link> element with rel="canonical" is used to specify the preferred URL for the content on the page. It helps search engines reduce duplicate content."
Structured data and duplication
Image from Google's structured data markup guide
The problem with canonicalization is that not all supplement tags for browsers are "lightweight" like it. Schema.org structured data also claims to be designed to follow its canonical page, but it's a lot bigger than a meta tag.
As Google's structured data policy I verified, "structured data should be put on the page it describes, and keyword density guidelines do not apply. Where documentation specifies otherwise, the structured data should go to that page or section of content."
Furthermore, the guidelines go on to say, "If you have duplicate content, you should use the rel="canonical" attribute to indicate the representative copy. As long as you place the same structured data on each page that uses the rel="canonical" attribute, Google will see that as your preferred URL."
Clearly, as Google says, "when you have duplicate content you can use the canonical link element as a hint to indicate which version should be indexed by Google... The rel="canonical" element is designed to communicate this preference when you have no dedicated mechanism for instances of duplicate content, such as URLs for printer-friendly products, versions tailored to different devices, or URLs with query parameters."
Canonicalization takes precedence in Google's algorithm, but it also requires structured data to be placed on all pages if it is to have any effect.
Print copy, reader mode
This problem is even clearer when considering the distinction between screen, print, and reader modes. The division between screen and print is carved out in browser extensions for CSS already, of course [ ].
But the canonical is also designed to deliver the page to browser reader modes now — these box out the bloat, removing all content except the whitespace itself.
In theory, Google's rendering of reader modes should follow the canonical. But in practice, you can't just check a single page and declare it canonical.
Verification is only possible with an indexed version of the page, as Google Search Consoles and MDN link docs both attest to.
The upshot is that print, reader, and browser modes are all means of indexing webpage content. The goal should be for each form of publishing to share one single canonical version, and adhere to schema rules wherever they are placed. [] [to summarise] ```
- 01Web & Browsers
How Online Gaming Changed the Way We Interact with Digital Content
Online games are now part of daily life. We play on phones, tablets, laptops, and game consoles. We do not just look at a screen anymore. We touch, tap, speak, and…
- 02Web & Browsers
What user-select: none Really Does, and the Accessibility Bill It Runs Up
The CSS user-select property sets whether the user can select text with their mouse or keyboard. At none, it is intended to block direct text selection by the user. But…
- 03Web & Browsers
How a Browser Decides a Page Is Ready, and Why Your Metric Disagrees
When you navigate to a webpage, how do browsers determine when it's ready? After all, web browsers have a well defined moment in time when they say they are done loading a…
- 04Web & Browsers
The Clipboard in the Browser: What a Page May Read, Write and Ask For
Access to the clipboard is governed by a split between read and write, with reading being gated more tightly than writing. The Clipboard API Gives pages the ability to access…



