The SaaS marketing website stack

The CMS argument is almost never about the CMS. It’s about how many marketing changes require an engineering ticket, and SaaS companies routinely pick the option that maximises tickets, because engineers make the decision and engineers optimise for the codebase they enjoy. Six months later the content lead is waiting four days to change a headline and nobody can explain how that happened.

So score the options on publish speed first. Architecture second.

The four patterns, scored on what matters

There are really only four shapes a SaaS marketing site takes. Everything else is a variation.

Pattern	Marketer publish speed	Programmatic pages	Annual cost	Dev dependency
Webflow	Minutes, no engineer	Good to low thousands via CMS Collections	500 to 3,000 dollars	Very low
WordPress	Minutes, no engineer	Good with custom post types and a plugin	200 to 1,500 dollars plus maintenance	Low, but ongoing upkeep
Headless (Contentful or Sanity) on Next.js	Minutes to publish, hours to build a new template	Excellent, tens of thousands	3,000 to 15,000 dollars	High and permanent
In-repo MDX (Astro or Next.js)	A pull request, so engineer or technical marketer only	Excellent	Near zero in licences	Total

Webflow is the default recommendation for SaaS companies under roughly 500 pages, and I’d pick it for most teams between seed and 20 million ARR. Vanta, Attio and a long list of Series A and B SaaS companies run marketing sites on it precisely because a designer and a content lead can ship a landing page on Tuesday afternoon. The costs are real: the CMS item limits bite eventually, the localisation story is workable but not excellent, and you will fight it if you want deeply computed pages.

WordPress is underrated in 2026 and over-criticised. HubSpot’s own blog ran on a coupled CMS for years and outranked everything. The plugin ecosystem solves problems the other three make you build. The tax is maintenance: plugin updates, security patching, and the performance work that a decent theme still requires. If nobody owns that, WordPress degrades quietly.

Headless is right when you have a specific requirement, not when it’s fashionable. In-repo MDX is right when your marketing team is technical, which is rarer than engineering leaders think.

Can it handle 500 template-driven pages?

This is the test that separates the patterns, because programmatic page sets are where SaaS content strategies now live: integration pages, comparison pages, alternatives pages, template galleries, location pages.

Webflow’s CMS Collections handle template pages well up to its per-site item limits, which sit in the low thousands on higher plans. For an integration directory of 300 pages or a comparison set of 150, it’s completely adequate, and you build the template once in the designer. Past several thousand, or where the page data comes from an API that updates weekly, you’ve outgrown it.

WordPress with custom post types handles the same volumes and goes further, but performance at scale needs real caching work and the editorial experience on 2,000 near-identical pages is poor without custom admin work.

Headless on Next.js or Astro is the right answer above roughly 500 generated pages. The content lives in a structured source, the build generates the pages, and you can regenerate the whole set when the data changes. This is also the only pattern where staged indexation is straightforward: publishing 3,000 pages at once is a reliable way to get a thin-content problem, so you want to release in batches of 50 to 200 and watch which ones earn impressions before releasing the next batch.

Localisation and hreflang, which is where most stacks break

If you sell in more than two languages, this is the requirement that eliminates options.

Webflow supports localisation natively now, and it’s serviceable for two or three markets with a shared structure. It becomes awkward when markets need genuinely different page sets rather than translations of the same pages, which is the usual state after 18 months.

Headless wins here clearly. Locale is a field, hreflang tags are generated from the content model, and each market can have its own editorial workflow and its own pages. That’s the strongest single argument for headless, stronger than the page count argument.

Whatever you pick, the hreflang implementation has to be reciprocal: every locale version of a page must reference every other, including itself, and the x-default must point somewhere sensible. Broken reciprocal tags are the most common international SEO fault and they’re silent, so nobody finds them until traffic in one market has been flat for a year.

Subdomain or subfolder for blog, docs and help centre

Subfolder. Almost always, for all three.

The case for subdomains is convenience: docs.yoursite.com can be a separate deploy on a separate stack with separate permissions, and if your docs are generated by an engineering toolchain that’s genuinely easier. The case for subfolders is that search engines treat a subdomain as a partly separate property, so authority earned by docs pages supports your commercial pages less than it would from a subfolder.

For a SaaS company, docs are often the highest-authority content you own, because developers link to them. Stripe’s documentation is a good example of docs as a serious acquisition surface. Putting that on a subdomain means giving away the internal link value to your pricing and product pages.

The practical setup: run the marketing site on your chosen CMS, and reverse-proxy the docs and help centre into subfolders at the CDN or edge layer. Vercel, Netlify and Cloudflare all support path-based rewrites, so /docs can serve from an entirely different origin while remaining a subfolder to a crawler. It costs an afternoon of configuration and it’s the right architecture.

The replatform checklist, and the traffic dip nobody warns you about

Replatforming is the highest-risk thing a marketing team does to its own site. Even executed well, expect a 20 to 40 percent organic traffic dip for two to three months, with recovery to baseline around month three or four. Budget for that in the forecast or someone will panic in week six and start reverting things.

The detailed version of this sequence, including the schema and internal link steps, is in the SaaS website migration SEO playbook.

What this fits into

The website stack is one component of a larger set of decisions, and the right choice depends on stage: a seed-stage company on Webflow with a Zapier and HubSpot back end is correctly configured, and the same setup at 50 million ARR is not. The stage-by-stage view is in the martech stack at every ARR band, and the broader tool landscape sits in the SaaS marketing stack.

Two adjacent decisions worth settling at the same time. First, whether you buy an all-in-one suite or assemble specialists, which is argued in all in one or best of breed and which changes the CMS calculus if you’re considering HubSpot’s CMS alongside its CRM. Second, what the whole stack actually costs per acquired customer, which the martech cost per customer calculator will tell you and which is usually higher than anyone expects.

If you’re early and cost-constrained, the free and cheap end of the market is genuinely viable now, covered in free and near free SaaS marketing tools. And before any replatform decision, run an inventory of what you already own using the martech stack audit template, because a meaningful share of replatform projects turn out to be solving a problem that a configuration change fixes. The head-to-head detail on the two most common choices is in Webflow versus WordPress for SaaS, and if your team also runs customer programs, the tooling overlap is set out in the customer marketing and advocacy stack.

What to do next

Count the tickets. That one number, marketing site changes that required engineering in the last quarter, decides the pattern more reliably than any feature matrix. Under five tickets and your current setup is fine. Over twenty and you have a publish speed problem that a platform change will fix.

If you’re replatforming, start the crawl and the URL-level performance export before anyone writes a line of code, because those two artefacts are what make the redirect map possible and they cannot be recreated after cutover. Everything else in the project is recoverable. That part is not.