Most SaaS marketing sites are built by the same people who build the product, on the same framework, through the same deployment pipeline. That is usually a good thing. It also means the technical SEO problems these sites have are not the ones on a standard audit checklist.
A local contractor’s website underperforms because nobody thought about search. A SaaS site underperforms because someone thought about it very hard, in React, and shipped a marketing site that Google has to work to read.
The pattern repeats across nearly every B2B software site we look at. Content that only exists after JavaScript runs. Thousands of near identical programmatic pages competing with each other. Documentation stranded on a subdomain. A release cadence fast enough that something breaks in production on a Tuesday and nobody notices until traffic drops in October.
Here is what matters, roughly in the order we would fix it.
Rendering is the first thing to check, and the thing most teams assume is fine
Google handles JavaScript in three separate stages: crawling, rendering, then indexing. Its own documentation is blunt about the gap between them. Pages get queued for rendering, and that queue “may stay on this queue for a few seconds, but it can take longer than that” (Google Search Central).
For a static marketing page that delay is an inconvenience. For a client side rendered app where the pricing table, the feature copy and the internal links all arrive after hydration, it is the difference between a page Google understands and a page Google files as mostly empty.
The check takes two minutes. Open URL Inspection in Search Console, run a live test, and read the rendered HTML rather than the screenshot. If your H1, your body copy and your navigation links are not in there, nothing else in this article will help you yet.
Two related failures show up constantly. Single page apps that return a 200 status for routes that should be 404s create soft 404s, which Google explicitly warns about. And navigation built on hash fragments (/#/features) cannot be reliably resolved by Googlebot, which Google calls out as a bad practice by name.
The fix is almost always server side rendering or static generation for the marketing routes specifically. You do not need to rearchitect the product. You need the pages you want to rank to arrive complete in the initial HTML response.
Programmatic pages are where SaaS sites quietly go wrong
Every SaaS company eventually builds the integration directory, the alternatives pages, the templates library or the per industry landing pages. Generated from a database, a few hundred to a few thousand URLs, shipped in a sprint.
Some of these work extremely well. The ones that work share a trait: each page contains something that only that page could contain. A real screenshot of the integration, the actual fields it syncs, the setup steps, a known limitation. The ones that fail are a template with a variable swapped in, and Google treats them accordingly. You will see them pile up in Search Console under Crawled currently not indexed, which is Google saying it looked and decided not to bother.
The damage is not only that those pages do not rank. It is that crawl attention spent on four thousand thin pages is attention not spent on the forty pages that could actually bring in trials.
Our rule of thumb before shipping a programmatic set: if you cannot write two sentences about a given page that would be false on any other page in the set, do not publish that page. Ship the two hundred you can defend and generate the rest when you have something to put on them.
The same discipline applies to what the app itself exposes. Shared links, public profiles, generated reports and preview environments have a habit of ending up in the index. Check site: queries for your app subdomain occasionally. Most teams find something they did not expect.
Where the docs live is a real decision, not a religious one
Documentation is often the highest quality content a SaaS company produces, and it usually sits on docs.yourproduct.com, built in a different tool, owned by a different team, linked to almost nowhere from the marketing site.
Google can crawl and rank either arrangement, and anyone who tells you a subfolder is automatically worth more traffic is overselling it. The practical argument is quieter. A subfolder keeps one set of internal links, one crawl path, one analytics property and one set of templates to maintain. A subdomain means two of everything, and in our experience the second one gets neglected.
If the docs are already on a subdomain and ranking well, moving them is a project with real risk and a recovery period, and Google’s own site move guidance is worth reading before anyone commits. If you are choosing now, choose the subfolder.
Either way, do the cheap part first: link between them properly. Most SaaS sites have marketing pages that never link to the relevant doc, and docs that never link back to a pricing or demo page. That is free internal linking and a free conversion path, sitting unused.
What AI search changes, and what it does not
Plenty of people are selling AI search optimization as a new discipline requiring new files and new markup. Google’s position is the opposite. To be cited in AI Overviews or AI Mode, a page needs to be “indexed and eligible to be shown in Google Search with a snippet,” and Google states plainly that “you don’t need to create new machine readable files, AI text files, or markup to appear in these features” (Google Search Central).
What does change is the shape of the query. Google describes using a “query fan-out” technique, issuing multiple related searches across subtopics to assemble an answer. That rewards pages that answer a specific sub-question cleanly and in one place, rather than pages that bury the answer in paragraph nine of a 3,000 word guide.
So the technical work is the same work. If your comparison page renders only after hydration, it is not eligible for anything. If your integration pages are thin, they will not be cited. Rendering and indexing are the entry fee for both traditional rankings and AI answers, which is a reasonable argument for fixing them before doing anything clever.
A sensible order of operations
If you are starting from nothing, this is the sequence we use:
- Confirm the marketing pages render server side and appear complete in the rendered HTML.
- Clear out anything indexed that should not be, starting with app subdomains and preview environments.
- Audit the programmatic sets against the two sentence test, and prune rather than expand.
- Decide the docs question and fix internal linking between docs and marketing either way.
- Then, and only then, spend money on content.
Set expectations honestly while you do it. Rendering fixes can show up within weeks because you are changing what Google can see. Architecture and pruning work takes a quarter or more to settle, because Google has to recrawl and reassess pages it already has opinions about. Anyone promising faster is guessing.
One last thing worth saying out loud. Technical SEO for SaaS is not a one time audit, because your site ships continuously. The site that passed an audit in March has had eleven deploys since. The teams that stay ahead of this run automated checks on rendering and indexability in CI, the same way they run tests.
If you want a second pair of eyes on any of this, we do technical audits for B2B software companies across North America and will tell you plainly if the problem is not worth fixing. Sometimes it isn’t. Contact us today!
