Website, docs, and blog from one CMS: the content architecture for your SaaS

I know this starting position from almost every SaaS project: the marketing website lives in Webflow or another page builder, the developer docs in GitBook or ReadMe, the blog in a WordPress somebody set up at some point. Three logins, three designs, three invoices. And nobody feels responsible for the whole.

How it gets there is understandable: each system was the fastest solution at the moment it was introduced. Marketing wanted to build pages without developers, the developers wanted to write Markdown, and the blog ran where blogs traditionally run. According to W3Techs, WordPress still powers 40.2 percent of all websites in September 2026.

The invoices themselves are not the problem. GitBook Premium costs 65 US dollars per site per month plus 12 US dollars per additional editor, ReadMe Pro 250 US dollars per month; both prices apply with annual billing (as of September 2026). Any funded SaaS can carry that. The real price appears on no invoice.

It lies in the fractured presence: the docs at docs.yourproduct.com never link into the blog, the blog never into the docs, and the website knows neither. The internal link graph that shows search engines your topical authority simply does not exist. And a prospect who moves from the polished homepage into docs with an outdated logo feels the break immediately.

This article is part of our series on the anatomy of a B2B SaaS website. Today we go one layer down: the content architecture that decides whether your presence is cut from one cloth or from three.

To the core of the problem: the three systems don't store content, they store pages. An example makes the difference tangible. You launch a new feature, say a Slack connector. That spawns a section on the integrations page, a docs chapter, an announcement blog post, and a changelog entry: the same information four times, copied by hand into three systems.

When the feature's name or a price changes later, the search begins: which of the four places did we forget? Exactly these forgotten copies produce the outdated prices on landing pages and the dead links in the docs your customers complain about.

A content model turns this around. You store content as structured documents with fields and references, not as finished pages. The Slack connector is then one document: name, description, logo, category, a reference to its docs chapter. Website, docs, and blog become three renderings of the same content.

What that gives you in practice:

The technical foundation for this is a headless CMS with a content model built on references: a content lake like Sanity's, which stores structured documents instead of finished pages.

A warning up front: the docs are the most demanding of the three content types. Putting website and blog into a CMS is routine. Developer docs make three demands that naive CMS setups regularly fail at. If you know them, you can plan for them.

Add to that their weight in sales: developers check the docs before they book a demo. Public, indexable docs pages also rank for long-tail queries your marketing pages will never cover. Every documented error message, every endpoint is a potential entry page.

As soon as your API runs on version 3 but paying customers still develop against version 2, you need both docs states in parallel. In the content model, you solve this with a version field per chapter and a version switcher in the frontend. What matters is the boundary: version only the API-adjacent chapters, not half the docs. Every versioned page is a page you maintain twice.

Developers judge your docs by the code examples. In concrete terms: syntax highlighting, a copy button, and the same example in several languages as tabs, say cURL, TypeScript, and Python. In Sanity's Portable Text, code blocks are structured blocks of their own with a language attribute; how they look is decided by your frontend.

One exception belongs in the definition from day one: the API reference itself has no place in the CMS. It gets generated from your OpenAPI specification, otherwise it will lie at some point. Hand-maintained endpoint lists go stale with the first release someone ships under deadline pressure.

Nobody reads docs front to back; whoever searches for error code 429 wants to land on the right chapter in seconds. The standard for this is Algolia DocSearch: free for technical documentation, in use by over 9,000 projects from React to Laravel. If your docs live structured in the CMS, you have an alternative: your own search via the query API, weighting headings and code separately.

Before you pull everything into the CMS, one counterproposal deserves a serious look: docs-as-code. The idea, shaped by the Write the Docs community: you treat documentation like source code. It lives as Markdown next to the code in the Git repository, changes go through pull requests, and CI builds a static site from it, with Docusaurus for example.

I'll say it openly: for pure developer teams, this is often the better choice. The docs change in the same pull request as the code, reviews are built in, the tools cost nothing. If you live this workflow, don't give it up for an architectural ideal.

The limits show as soon as non-developers are supposed to contribute. Support staff who first have to learn Git and pull requests stop writing docs. There is no preview for editors, no references to prices or features, and the blog in the marketing system stays cut off. The overview:

My advice is therefore often a hybrid: the API reference is generated from the OpenAPI specification, guides, tutorials, and concept articles live in the CMS, and the same Next.js frontend renders both under one domain. The line doesn't run between the tools, it runs between the authors: whoever writes determines the system.

As proof that I'm not just selling theory here: happycoding.agency runs entirely on Sanity and Next.js, hosted on Vercel. No page builder, no WordPress, no separate docs tool. Every landing page, every blog post, every FAQ lives as a structured document in the same content lake.

In concrete terms: a blog post here is not a lump of HTML but a document with separate fields for body text, key takeaways, FAQ, and sources. The frontend renders the page from it, plus structured data as JSON-LD, such as FAQPage and Article for search engines. Categories are references, from which topic pages emerge automatically.

In everyday work, this changes the division of labor: I write content in the studio without needing a developer; layout changes are code and go through Git. Both sides work in their own tool, neither blocks the other. This separation of content and presentation is exactly where page builders and WordPress themes fail.

I recommend the same mechanism for SaaS content that has to stay current. The subprocessor list in the trust center is the prime example: maintained once as structured content, it appears on the trust page and in the DPA annex always in the same state, instead of going stale in three PDFs.

On costs: the Sanity free plan carries 20 users, 10,000 documents, and 250,000 API requests per month; the Growth plan costs 15 US dollars per user per month (as of September 2026). Our site, with well over 100 blog posts, runs far below those limits. My assessment from our own projects: the budget goes into building the frontend, not into licenses.

Honest consulting includes the counter-list: there are constellations in which I'd advise you against the one-CMS architecture.

The rule to remember: a content model nobody maintains is worse than three systems that run. The architecture has to fit your team, not the other way around.

If the three-systems problem is bugging you right now, start with an inventory: for one week, note every place where the same information is maintained twice. That list is your business case, more precise than any debate over CMS vendors.

The second step is a question about authors: who is supposed to maintain docs, blog, and website in twelve months? If only developers write, little speaks against docs-as-code. If support, product, and marketing are supposed to contribute, there is hardly a way around a content model.

As a B2B website agency we build exactly these architectures: a content model in Sanity, one Next.js frontend for website, docs, and blog, migration including redirects. If you want to know whether this pays off for your SaaS, book a free intro call: 30 minutes, a concrete assessment, no slides.