# The Strategic Value of Every Page Is Page One > Mark Baker's Every Page Is Page One principle is more than a topic design pattern — it is a strategic argument about where organizational assumptions collide with how users actually find and use content. Here is the business case. ## The Assumption Nobody Questions There is an assumption baked into the way most documentation teams work, and it goes unexamined because it has always been there. It shapes how topics are titled, what context is included or omitted, how a help system is structured, and why so many writers feel uneasy about a topic that seems to start in the middle. The assumption is that your users are reading in order. That they started at the beginning, absorbed the prerequisites, and arrived at this topic having read everything that came before. They didn't. Most of them never will. **Users arrive via search.** They find a topic through a Google result, a chatbot citation, a colleague's Slack link, a bookmark three months stale. They arrive mid-guide. They have no idea what is in chapter one. And when the page they land on assumes context it never provides, they leave. The content existed. It failed anyway. Mark Baker named this pattern in [*Every Page Is Page One*](https://everypageispageone.com): on the web, every page is page one for the user who arrives at it. This is not a new observation. It is one that most documentation programs have not yet organized themselves around. ## What Failure Actually Costs The stakes are measurable, and they compound. The most direct consequence is support cost. When users cannot find what they need, or find it and cannot use it, they open tickets. [Heretto's 2024 benchmark](https://heretto.com/resource/self-service-content-experience-report/) found that 57% of support calls originate from customers who visited the help site first. They tried to self-serve. The content failed them. What looks like a support cost is often a content design cost. **Forty-four percent of B2B customers choose self-service as their first contact point.** In software, that number rises to 67%. Those users encounter your documentation before they encounter your sales team or your support organization. When the content assumes prior context they don't have, the first impression is a dead end. The downstream costs are less obvious but significant. Documentation that depends on reading order cannot be localized efficiently. Every context-dependent topic carries implicit prerequisite content that must be resolved in translation. Reuse rates drop. Time-to-market for new product releases stretches because the update cycle inherits the cost of unresolved dependencies. And at the emerging edge of the problem: **AI retrieval systems that ingest context-dependent topics produce unreliable answers**, because the fragments they assemble lack the self-containment needed to be interpretable in isolation. The structural assumption about reading order doesn't just inconvenience users. It erodes deflection rates, complicates localization pipelines, and compromises the quality of AI-assisted customer experiences. ## The Problem Is Solvable If you are in a documentation leadership role, you have probably seen some version of this problem without naming it. Topics that perform poorly in search. Users who open tickets for things that are documented. Content that theoretically covers the full product surface but fails users in practice. The typical response is to add more content, restructure navigation, or improve search. These interventions miss the root cause. Baker's diagnosis is precise: **the content was designed for a reader who doesn't exist.** The notional reader of book-form documentation starts at page one, reads systematically, and arrives at any topic having absorbed everything before it. The real user arrives from search, brings only what they know, and needs the page they land on to work completely. The path forward is a design pattern change, not a technology change. It does not require a new CMS. It does not require a complete rewrite. It requires a clear-eyed audit of what your content actually assumes and a disciplined practice of eliminating those assumptions. ## A Strategy for Self-Contained Content Baker's framework defines seven characteristics of a well-formed topic. Most content programs have gaps against most of them. A productive starting sequence: **Start with purpose, not structure.** The most critical characteristic is that a topic has a specific and limited purpose, defined by a unit of human-scale work. Not "an answer to one question" — questions can scale to any size. A topic about configuring an API gateway should cover configuring an API gateway, including the context a practitioner needs to complete the task successfully. Not more. Not less. Not a fragment of a procedure that only makes sense after reading the overview. **Establish context without requiring prior reading.** Every topic needs to locate itself in the world. What product? What version? What user role? What task is this part of? A topic that opens with "Now that you have completed the initial setup..." fails every user who skipped the initial setup or arrived here first. **Link by subject affinity, not document hierarchy.** Traditional cross-references say "See Chapter 4 for more information." EPPO links say "This task depends on the permissions model" and link to the permissions model topic, because that is the subject the user may need next, regardless of where it sits in the documentation set. **Subject affinity linking is navigation architecture.** It determines whether users can orient themselves on landing. **Govern metadata with the same discipline as content.** A topic titled "Configuration" is nearly impossible to retrieve correctly, either by users in search or by AI systems retrieving fragments for synthesis. Specific, accurate titles and short descriptions are not SEO hygiene. They are the mechanism by which content reaches the users who need it. ## What the Other Side Looks Like Organizations that have made this shift describe a recognizable before and after. Support ticket deflection improves, because users can actually use the documentation they find. Localization costs decrease, because self-contained topics don't carry implicit prerequisite debt. Content scales: new product releases can be updated with surgical precision rather than cascade revisions. And documentation begins to appear in conversations about AI readiness, because a corpus of well-formed, self-contained, richly linked topics is precisely what an AI retrieval system needs to produce reliable answers. More visibly: **documentation stops being invisible to leadership.** When content deflects tickets, accelerates onboarding, and supports pre-sales evaluation — and when those outcomes are measurable — the argument for treating documentation as a strategic asset rather than a production cost makes itself. [Research on B2B buying behavior](https://heretto.com/resource/self-service-content-experience-report/) puts 34 million pre-purchase documentation sessions in the annual baseline. These are not post-sale interactions. They are evaluation touchpoints. Baker's observation, made in 2013, has become more consequential, not less. Every page still is page one. And the organizations that design for that reality are building content that works: for users, for support, for AI, and for the business. --- If you want to understand where your current content stands against these principles, the most direct first step is a conversation about what you have and where the gaps are. [Schedule a call](https://calendly.com/intuitive-lief/discovery-initial-consultation) to work through the distance between where your documentation is and where it needs to be.