Documentation hosting where search is the navigation.
Nobody reads documentation from the beginning. They search, land in the middle, and decide within seconds whether the answer is here - which makes search the product and the page merely where it lands.
Answers, not pages.
Documentation traffic is anonymous, repetitive and search-first, which makes it unusually cheap to serve well.
Search across everything, instantly
In-site search is the primary navigation, so it is indexed rather than run as a database LIKE across every post. Results arrive while somebody is still typing.
Pages that are pure cache hits
Documentation changes rarely and is read constantly by anonymous visitors, which is the ideal case for full-page caching. Almost every request is answered at the edge.
Old versions stay online
People run last year's release and need last year's documentation. Older versions stay published and cached rather than being something you delete to keep the site tidy.
Draft a rewrite on a copy
Restructuring a documentation set is a big change. Clone the site, reorganise there, and push it back once the new structure is right.
Publishing is nearly free
Updating a page purges that page. There is no rebuild step and no deploy queue, so a correction is live in seconds.
The page they land on is rarely the front one.
Almost all documentation traffic arrives from a search engine or a search box, deep in the middle. Everything about the site should assume the reader has no context.
- Search indexed rather than queried live
- Every page cached for anonymous readers
- Older versions kept published
- Corrections live in seconds
Almost every request is a cache hit.
Documentation is the friendliest workload there is: anonymous, repetitive, and changing far less often than it is read.
What we change for documentation
This workload asks for very little, and the little it asks for is unusual: search that behaves like a product feature rather than a WordPress afterthought.
| Setting | What we do | Why |
|---|---|---|
| Site search | Indexed rather than run as a live database query | Search is the primary navigation here, and WordPress's default search is a pattern match across post content that gets slower with every page added. |
| Page cache TTL | Long, with purge on edit | Documentation changes far less often than it is read, so long cache lifetimes cost nothing and a targeted purge handles corrections. |
| Archived versions | Kept published and cached | Readers running an older release need the documentation that matches it, and unpublishing it turns their search result into a 404. |
| Anchor-heavy pages | Served whole rather than paginated | Deep links into a section are how documentation is shared, and splitting a long page breaks every link anyone has saved. |
| Asset caching | Long expiry on code-highlighting and diagram assets | Documentation ships the same handful of static assets on every page, and re-fetching them is pure waste. |
Simple, transparent pricing.
Every plan includes free migration, daily backups, SSL and 24/7 support.
- 1 WordPress site
- 10 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Support tickets
- 5 WordPress sites
- 50 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Priority support tickets
- 20 WordPress sites
- 200 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Dedicated support
Questions, answered.
Is WordPress search good enough for documentation?
Can I keep documentation for old versions online?
How fast does a correction go live?
Do you support docs plugins and custom post types?
Make the answer easy to find.
Move the documentation across. Migration is free, every version included.