Every time I tell someone I write documentation, or any content published online, for a living, I get the same reaction. They picture a PDF that someone uploaded to a website. Click a link, download a file, read it top to bottom, done.
I keep running into that assumption, and it’s wrong. Online documentation isn’t a book that happens to live on a screen. It’s something else entirely, and once you understand the difference, you write completely differently, whether you’re publishing help articles, a knowledge base, or your organization’s public-facing pages.
Online Documentation Is a Network, Not a Book
A book has one path through it: front to back, page by page. Online content doesn’t work that way. It’s a web of small, connected pieces, what we call topics, and readers jump into that web wherever their question happens to land.
That’s the whole point. Nobody reads a help center, or a website, cover to cover. They land on one page from a search, get their answer, and leave. If that one page assumes they’ve already read three others, you’ve lost them.
I’ve seen content that was technically online, hosted on a website, searchable, mobile-friendly, and still built like a book underneath. Long pages. One topic bleeding into the next with no clear edges. Readers had to scroll past four unrelated sections to find the one sentence they needed. That’s getting lost, and it’s one of the most common failures in content that’s online in name only.
Three Types You’ve Probably Never Grouped Together
Ask most people to name a type of online documentation and they’ll say “help pages.” That’s one type out of many. Once you start looking, you notice the same underlying structure showing up everywhere, and I go through the full list in Types of Online Documentation, With Examples. Three you’ll recognize immediately:
- Help systems, the ones built directly into software, answering “how do I do this” in the moment someone’s stuck.
- Online encyclopedias, like Wikipedia, where thousands of short, linked entries add up to something far bigger than any single article.
- Product catalogs and knowledge bases, where a customer clicks through category, then product, then spec sheet, never reading the whole catalog at once.
Different products, same underlying shape: small pieces, connected by links, none of them meant to stand alone as a full read.
Where This Actually Came From
Here’s the part that surprised me when I first learned it. This idea isn’t new. It’s not even from the internet age. I’ve written up the full story in A Short History: Memex, Xanadu, Hypertext and Hypermedia, but the short version is worth knowing on its own.
In 1945, long before anyone had built a working computer, a scientist named Vannevar Bush described a machine called the Memex, a device for storing knowledge and linking related pieces of it together so you could jump between them instantly. He called it a “mesh of associative trails.” That’s a hyperlink, described decades before the word existed.
In the early 1960s, Ted Nelson and Douglas Engelbart picked up that thread and started actually building it, testing whether computers could hold webs of connected information instead of straight-through text. Nelson gave us the word for it: hypertext, non-sequential reading and writing, information you can branch through instead of only scroll through.
So when your help center, or your organization’s website, links one page to another, you’re not using a modern content trick. You’re using an idea that’s older than the personal computer.
Why This Actually Matters If You Publish Content for a Living
I bring this up because I still see teams treat “we put it online” as the finish line. It isn’t. Putting content on a website doesn’t make it work the way online content should. Structuring it as small, linked, self-contained pieces does. I go deeper into what’s actually at stake for writers and teams in Why Technical Communicators Need to Know This.
The test I use on my own writing: could someone land on this exact page from a search engine, with zero context, and get a complete answer? If the page needs three other pages read first to make sense, it’s not a topic. It’s a book chapter that got lost.
That’s the standard I hold every piece of content to now, mine included. Not “is it on the web,” but “does it actually work the way the web works.” Most content still doesn’t. The rest of what I write here is about closing that gap, one piece at a time.
For an organization, this isn’t an academic distinction. Content built as a book instead of a network is content your users abandon, your translators re-copy by hand, and your support team keeps re-answering by email, whether that’s technical documentation, your public website, or the guidance you publish for the communities you serve. If you’re weighing whether your own content is actually structured to work online, that’s exactly the kind of audit I do for organizations. See how I can help.
Related topics: