// B2B SaaS
Technical SEO for B2B SaaS: Docs, Versions and the Login Wall
In B2B SaaS the crawlable estate is mostly documentation. It is published by a different team, on a platform the growth team cannot commit to. The product everyone is evaluating sits behind a login where no crawler goes. The ranking problem is a two-codebase problem before it is a content problem.
What changes in B2B SaaS
- Documentation usually lives on a vendor-hosted docs platform, so robots.txt, canonicals and redirects are configured outside the repository your engineers work in
- Versioned docs publish the same page under /v1/, /v2/ and /latest/, manufacturing near-duplicates faster than any writer can produce originals
- The product is behind a login, so the pages a buyer can be ranked to are documentation, pricing, the changelog and a short marketing site
- An integrations directory and a per-release changelog are already a programmatic layer inside the client's own site, carrying the same scaled-content exposure
- Marketing site and app often share one framework and build, so an app route or preview deployment can reach the index through a shared sitemap
A B2B SaaS company publishes two websites and calls it one. The marketing site sits in a repository the growth team can reach. The documentation sits on a docs platform, usually on its own subdomain, owned by engineering or a technical writer. It has its own robots file, its own canonical logic and its own release process. Buyers cross between them without noticing. Search engines do not, and neither does the org chart.
That split decides the shape of the engagement. A crawl of the marketing site covers perhaps eighty pages. The docs can run to several thousand pages, and they answer the questions an evaluator types. The fixes for them land in a system your marketing pull request cannot touch. So the audit runs across both properties and the fix list comes back sorted by who is able to merge it. A recommendation aimed at a team with no ticket for it is a recommendation that never ships.
The crawlable company is smaller than the company
Everything your product does happens after a login. None of it is indexable and none of it should be. What is left to rank is a short list. The marketing pages, pricing, the documentation, the changelog, the integrations directory. And whatever the blog has accumulated since the last rebrand. That is the whole surface.
Two things follow. Value per page is higher here than on a site with a large public catalogue, so a bug in one template costs more. The application and the marketing site frequently share a framework. So an app route can end up in a sitemap, or a preview deployment in the index. We look for both in the first week. A login screen ranking for your own brand stays invisible until a customer mentions it.
Version trees make duplicates faster than anyone writes originals
Versioned documentation publishes the same page three or four times, under /v1/, under /v2/, under /latest/, sometimes under a date. The text is close to identical by design, because the endpoint did not change between releases. That is a canonical problem, and on a hosted docs platform the canonical behaviour is a config setting somebody else controls.
The decision is a product decision as much as a search one. Which version should an engine treat as the page? Usually the current one, with older trees pointed at it or dropped from the index while staying reachable for the customers still on them. Get it wrong and authority scatters across four URLs, leaving the engine to pick, and what it picks is often a version you stopped supporting.
You are already running a programmatic layer
An integrations directory is programmatic content. So is a changelog that emits a page per release, and so is any template rendering one page per supported connector. Those sets usually get built before anyone reads Google’s spam policies, and they carry the same site-wide exposure that this page is held noindex for.
We measure them the way we measure our own. Does the page for connector two hundred say anything the page for connector three does not? If it does, it stays and it gets better. If it does not, the honest fix is fewer pages: one directory page built properly, and noindex on the rest. That conversation is uncomfortable because somebody shipped those pages as a project with a launch date. It is still cheaper than the alternative.
What the first month looks like on a SaaS estate
Search Console for both properties, which often starts with verifying the docs subdomain nobody claimed. A crawl of each, with findings grouped by the template that causes them. A rendering check. A marketing site built on the same client-rendered framework as the app can hide its own copy from anything that does not execute JavaScript. Then a split list. The fixes that go through your marketing repo, and the ones that go through the docs platform. Each is tied to the Search Console number it should move.
The engagement ends with pull requests in both places. Or with a written answer on why the docs platform will not accept one, and what we did instead. Both are useful outcomes. Only one of them is the one people expect to buy.
This is the B2B SaaS view of Technical SEO. That page covers how the work runs whatever the sector.