The technical SEO problems that only show up on SaaS marketing sites

Fetch your homepage with JavaScript disabled. Right now, before reading further. If what comes back is a div with an id and nothing else, everything below the fold of this article matters more to you than any content strategy.

I have run about ninety technical audits on B2B software sites in the last five years. The same six problems account for most of the damage, and none of them are the ones that show up in a Lighthouse score.

Rendering, which is still the big one

The client-side rendering problem was supposed to be solved. Google renders JavaScript, everyone moved to frameworks with server rendering built in, and the industry moved on.

What actually happened is that framework defaults changed several times, teams upgraded partially, and a lot of marketing sites now exist in a hybrid state nobody fully understands. A Next.js app where the marketing routes were correctly static until someone added a client-side auth check to the layout in March. A Nuxt site where the blog renders server-side and the product pages do not because of a third-party widget.

The Verityn case we write about elsewhere was exactly this: a rewrite eight months prior had shipped client-side rendering across the whole marketing site. Every page looked perfect to a human. To a crawler it was an empty shell. Four hundred pages, effectively invisible, for eight months, and the engineering team had no idea because nothing was broken from their perspective.

Check it properly by comparing the raw HTML response to the rendered DOM, on a sample of every template type, every month. Not once during an audit. Every month, because it regresses on deploy.

Canonical tags from a headless CMS

The second most common, and the most quietly destructive.

Headless setups generate canonicals from a field somewhere, and that field gets populated by a preview URL, a staging domain, or a default that points at the homepage. I have found canonicals pointing to localhost:3000 on a live production site with 90,000 monthly visitors.

The symptom is pages that get crawled, are technically fine, and never rank. Google is being told, by you, that the real version of the page is somewhere else.

Crawl your whole site and check that every canonical is self-referential unless you deliberately chose otherwise. Then add it to a pre-deploy check, because manual audits catch it once and it comes back.

The docs subdomain fighting the marketing site

Almost every developer-focused SaaS has this. Documentation at docs.example.com, marketing at example.com, and both have a page about your API.

The docs page usually wins, because it has more inbound links from Stack Overflow and GitHub, and it is a terrible landing page for a buyer. It has no pricing, no CTA, no positioning, and a navigation designed for someone already using the product.

There is no single right answer here. What we generally do is decide, per query cluster, which surface should own it, then reinforce that with internal links and differentiate the content so the two pages are not competing for the same intent. Docs pages get a small, non-intrusive link back into the marketing funnel. Marketing pages targeting technical queries get genuinely technical, with code samples, rather than being a sales page with the word “developer” in it.

Moving docs onto a subdirectory is worth considering and is a bigger project than it sounds. I would not recommend it purely for SEO unless the rest is already in order.

Faceted and parameter explosion

Less common in SaaS than in ecommerce, but it appears in integration directories, template galleries, and resource libraries. A filter UI that generates a crawlable URL for every combination produces tens of thousands of near-identical pages.

On one client, a template library with four filter dimensions had generated 41,000 crawlable URLs from about 600 actual templates. Crawl budget went almost entirely to filter combinations, and the genuinely useful category pages were crawled every three weeks.

The fix is deciding explicitly, per parameter, whether it should be crawlable, canonicalised, or blocked. Then implementing that in robots.txt, canonicals, and link rel attributes consistently, which is more work than it sounds because the three mechanisms do different things.

Core Web Vitals, in the order that matters

Most CWV advice for SaaS sites is generic. The specifics that actually move the numbers on a B2B marketing site, roughly in order of impact:

Third-party scripts are almost always the problem. A typical B2B marketing site loads a chat widget, an analytics tag, a heatmap tool, a marketing automation script, an A/B testing snippet, and two ad pixels. Each was added by a different person and nobody owns removing them. Auditing this list and deleting half of it does more for your LCP than any image optimisation.

Font loading is second. Self-host, subset, use font-display: swap, preload the one face used above the fold. Blocking web fonts from a third-party host on a slow connection produces a blank hero for two seconds.

Hero images third. Correctly sized, modern format, fetchpriority="high", no lazy loading on the element that is the LCP.

Then layout shift, which on marketing sites is almost always a cookie banner, an announcement bar, or an image without dimensions.

Actual JavaScript execution time comes last for marketing pages, though it dominates in the app.

Migrations, where the real damage happens

Every large traffic loss I have investigated in the last three years traced back to a replatform. The pattern is consistent enough to write a checklist.

Before launch: crawl the existing site completely and export every URL with its traffic and links. Map every URL with meaningful traffic or links to a destination, one to one where possible. Redirect chains longer than one hop get flattened. Crawl the staging site and compare templates, meta data, structured data, and internal link counts against production. Check robots.txt on staging is not going to ship as-is, which happens more than anyone admits.

At launch: verify redirects fire as 301 rather than 302 or a JavaScript redirect. Submit the new sitemap. Keep the old sitemap available for a few weeks so Google discovers the redirects.

After launch: monitor index coverage daily for a fortnight, watch for 404 spikes in server logs, and compare rankings for the top 200 keywords weekly. Most migration damage is recoverable if you catch it inside three weeks and much harder after three months.

The single most common failure is redirecting everything to the homepage. It is technically a redirect, it passes almost nothing, and it is what happens when nobody was given time to build the map.

What to do with all this

If you only do one thing: set up an automated weekly check that fetches ten representative URLs without JavaScript and alerts if the rendered content drops below a word count threshold. That one check would have caught the most expensive problem on this list eight months earlier.