Online documentation is the public, browser-accessible help content that lets customers and prospective customers find answers without opening a support ticket. Done well, it deflects 30 to 60 percent of repetitive support requests and becomes a meaningful organic-search surface for the product. Done poorly, it becomes a polished-looking corpus of articles that are quietly wrong, that mobile users cannot navigate, and that nobody on the team trusts. The gap between the two outcomes is almost never about the editor or the hosting platform. It is about the maintenance discipline after launch.
This pillar covers the three jobs that online documentation requires: creating content that answers real customer questions, hosting it in a way that performs and ranks, and keeping it accurate as the product changes. Most guides on this topic cover the first job and stop. The maintenance dimension is what separates documentation that pays for itself from documentation that becomes a liability.
What online documentation actually means
Online documentation is help content published to a public-facing surface that customers can reach through search, a help link inside the product, or a direct URL. It overlaps with knowledge bases, help centers, and product documentation but is broader than any one of them. The categories that count as online documentation include customer-facing help centers, public knowledge bases, product documentation for end users, API references for developer audiences, and step-by-step guides for procedures.
The economic case is straightforward. SuperOffice's customer service benchmark report puts the cost of a self-service interaction at around ten cents against eight to thirteen dollars for a live ticket. A knowledge base that answers 40 percent of customer questions without a ticket saves the support team meaningful headcount. The trap is that the Knowledge-Centered Service methodology finds the useful life of a typical knowledge article is around six months. Online documentation that is not actively maintained becomes a misinformation surface within a year, and the misinformation looks authoritative because it lives on the brand's own domain.
The three jobs: create, host, maintain
Most documentation projects allocate 70 percent of effort to creation, 20 percent to hosting decisions, and 10 percent to maintenance. The breakdown should usually be reversed.
Create
Write the article. Determine who the audience is, what question they are trying to answer, what level of detail to include, what to leave out, and which other articles to link. This is the job AI drafting tools are now largely good at, though the architecture decisions (what to leave out, which user types to serve) still need human judgment.
Host
Put the article on a URL that loads fast, ranks in search, works on mobile, supports the team's branding, and integrates with the rest of the support stack. This is the job that documentation platform vendors compete on.
Maintain
Keep the article accurate as the product changes, the policies update, the team grows, and customer expectations shift. This is the job that decides whether the documentation is still useful two years in. It is also the job that gets underweighted in evaluation and overpays for in operation.
How to create online documentation
Quality online documentation starts from real customer questions, not from internal feature lists. Two patterns consistently produce documentation customers actually find useful.
Mine support tickets for the first 20 articles
Pull the last 90 days of tickets, group them by issue, and rank by frequency. The top 20 issues become the first 20 articles. This sounds obvious and is rarely done. The alternative (writing one article per product feature) creates a corpus that mirrors the feature list and answers very few of the questions customers actually ask. See how to build a SaaS knowledge base for the operational pattern.
Write to the specific question, not the general topic
Article titles that include the exact phrasing a customer would search ("How do I cancel my subscription?" not "Subscription management") rank better and convert better. The customer is searching for the answer, not the category. Writing knowledge base articles covers the specific patterns that work.
Use media variety where it earns the cost
Video tutorials, screenshots, GIFs, and step-by-step screenshots each help different learners and different question types. The cost is that media gets stale faster than text. A screenshot of a UI from six months ago looks confidently wrong when the UI has changed, in a way that out-of-date text does not. Use media generously at first, then track which articles drift fastest and adjust the media discipline accordingly.
Structure for scanning, not for reading
Customers scan first, read second. Use H2 and H3 headings as decision points, lead each section with the answer, and put the supporting detail in the body. Bullet lists and numbered steps for procedures.
How to host online documentation
The hosting decision splits into three honest options. Each has trade-offs.
Build it on a documentation platform
Document360, Help Scout Docs, Intercom Articles, Zendesk Guide, GitBook, Mintlify, HappySupport. These platforms handle the hosting, the editor, search, analytics, themes, and basic integrations. Pricing ranges from $20 per user per month for some tools up to $500 per month flat for others. Best for teams that want the documentation surface to be a product feature rather than a project. The trade-off is platform lock-in: migrating away later involves re-platforming.
Build it on a static site generator
Docusaurus, MkDocs, Sphinx, Nextra, VitePress. These tools produce static HTML from markdown source files stored in a Git repository. Free or low-cost, fully customizable, no vendor lock-in. Best for engineering-heavy teams that already work in Markdown and Git. The trade-off is operational cost: search, analytics, theming, and access control all need to be wired up by the team.
Build it as part of the marketing website
Some teams put help content on the main marketing site under a /docs or /help path, using whatever CMS the website runs on. Cheap and integrated. The trade-off is usually a worse editor for the content team, worse search, and worse analytics than a purpose-built tool delivers.
How to keep online documentation accurate
The maintenance dimension is where most projects fail and where the time savings of self-service get clawed back through support requests over wrong information.
Build a schedule that ties to product releases, not the calendar
Quarterly review reminders catch some staleness and miss most of it. Documentation should be reviewed when the product ships, not on a fixed cadence. Teams shipping weekly need a review process that runs weekly. The GitLab DevSecOps Report finds that 65 percent of teams ship weekly or more frequently, which means quarterly review is wrong for the majority of the year.
Watch search analytics every week
The highest-leverage maintenance signal is dead-end search: a customer typed something into the search bar and got no results, or got results but did not click any. Every documentation platform with credible analytics surfaces this. A weekly look at the top dead-end searches produces a backlog of articles to write or fix that maps directly to what customers actually want to know.
Tie content to product state where possible
The most reliable maintenance signal is a watch on the system being documented. Keeping docs up to date when you ship weekly covers the operational pattern: every code change triggers a check against the documentation set, and articles that touch the changed surface get flagged for review before the release ships. This is what HappyAgent does for customer-facing help content; the same pattern shows up in Mintlify for developer documentation tied to code.
Tool categories and where each fits
Online documentation tools split into four practical categories.
Customer-facing help center platforms
Document360, Help Scout Docs, Intercom Articles, Zendesk Guide, Freshdesk Knowledge Base, HappySupport. Built for support and customer success teams. Strong on customer-facing aesthetics, SEO, AI search integration, ticket-deflection analytics. See the best help center software comparison for the deeper view.
Developer documentation platforms
Mintlify, GitBook, ReadMe, Redocly, Docusaurus. Built for engineering-led docs teams. Strong on markdown, OpenAPI integration, Git workflows. Less strong on ticket-deflection analytics or customer-facing chat. See the best AI documentation tools for the deeper view.
Internal team wikis
Confluence, Notion, Guru, Slite, Tettra. Built for internal teams. Sometimes used to host customer-facing documentation by exposing a public area, which generally compromises on SEO and search compared to purpose-built customer-facing tools.
General-purpose CMS
WordPress, Webflow, custom builds on Next.js or similar. Used by teams that want documentation embedded in the marketing site. Strong on brand integration, weak on documentation-specific features (article hierarchy, search analytics, ticket integration).
Common mistakes
Three recurring mistakes cost teams more than any tool choice.
Treating launch as the end of the project
The launch is the start of the work, not the end. A documentation set without a maintenance discipline degrades quickly. Plan for ongoing investment, not a one-off project. The documentation maintenance trap covers why this is the most common failure mode.
Ignoring mobile
Mobile traffic to help content is typically 30 to 50 percent of total traffic and often higher for consumer-facing products. Documentation that does not work on mobile (long unwrapped tables, screenshots cropped wrong, navigation hidden behind hover states) loses half the audience silently.
Skipping search analytics
Dead-end searches are the most useful feedback signal in online documentation, and most teams never look at the search log. Even a weekly five-minute review produces a high-leverage backlog of content to fix.
What to measure
Four metrics cover the useful surface.
Ticket deflection rate
The percentage of would-be tickets resolved through self-service. Hard to measure precisely; proxies include the article-to-ticket ratio in user journeys and surveys asking customers whether the article answered their question.
Dead-end search rate
The percentage of internal searches that returned no results or no clicked result. Should be falling over time as content fills gaps.
Article freshness percentage
The percentage of articles reviewed within the last N days, where N is set to the product release cadence. Teams shipping weekly should target weekly freshness; teams shipping quarterly can target longer windows.
Time to find
How long a customer spends searching before reaching the answer (or giving up). Measured through search analytics and on-site behavior tracking. Falling time to find is the cleanest signal that the documentation is improving.
The HappySupport approach to online documentation
HappySupport is built for the customer-facing online documentation surface, with the maintenance dimension as the primary design goal rather than an afterthought. HappyRecorder captures workflows as DOM and CSS selectors at article creation, which gives every article a structured tie to the live product. HappyAgent GitHub Sync reads the product repository, links code changes to affected articles, and surfaces what needs review before customers hit a stale page. The result is online documentation that stays accurate at the speed the product ships, instead of the speed the support team can manually audit. For teams shipping weekly without a dedicated documentation team, see how self-updating help centers work and the weekly-release documentation playbook.
