A user types a question into Google. They get a documentation page. They land in the middle of a multi-page guide, on the page about configuring error handling. The page assumes they’ve already read the setup page, the authentication page, and the overview. It references “the token you created in step 2” without explaining what step 2 was or linking to it. The user has no idea what token. They back out of the page and find a blog post that explains the same thing without assuming prior context.
This is the central problem that Mark Baker identified in his book “Every Page Is Page One”: readers don’t start at the beginning anymore. They arrive through search, through links from Stack Overflow, through a colleague’s recommendation of a specific section. Every page in your documentation is a potential first page for some user.
Baker’s work, published at everypageispageone.com, draws out what this means in practice. A page that can’t be understood without the preceding pages fails the user who didn’t read the preceding pages. Given that most users arrive that way, failing those users is failing most of your readers.
The consequences for writing are specific. Every page needs to establish enough context to orient a new reader. Not a complete reexplanation of everything — that would make each page exhausting — but enough orientation that the reader knows what this page covers, what knowledge it assumes, and where to go if they’re missing that knowledge. A brief note that says “this page assumes you’ve set up authentication — see the authentication guide if you haven’t” takes twenty words and saves users twenty minutes.
Every page also needs clear links to related pages. Not a generic “see also” section at the bottom, but contextual links embedded in the text at the moment when the reader might need them. If you mention a concept that’s explained elsewhere, link to it. Don’t assume the reader already found it.
The web made this true for all documentation, not just online help systems. Print manuals could assume linear reading because the physical format enforced it. You opened the book at chapter one and progressed. On the web, everybody skips to chapter seven. The format gives them no reason not to.
This doesn’t mean that documentation structure is irrelevant. Structure matters for users who choose to read linearly, and for communicating what the documentation covers. But structure alone can’t substitute for self-contained pages. Both matter: a clear information hierarchy and pages that work as entry points.
The test is practical. Pick any page in your documentation. Imagine arriving at it from a Google search, with no prior context. Can you figure out what the page is about? Can you accomplish your goal without having to open six other pages first? If the answer to either question is no, the page is missing something.
Write pages that work as starting points. Some of your users will read everything in order. Most won’t.