SaaS site architecture for SEO

A pricing page sitting four clicks behind a hover menu gets crawled less often, receives almost none of the authority your blog earns, and ranks the way you would expect. No amount of writing fixes that. Most SaaS sites carry the same shape: a heavily linked homepage, a heavily linked blog, and a set of feature, use case and integration pages that nothing points at except a navigation menu the crawler may not even see.

Architecture sets the ceiling on everything else you do. Get it wrong and you spend two years publishing into a building with no corridors.

The five surfaces of a SaaS web estate and where each one belongs

Most software companies run five distinct web surfaces, and only three of them should share a host with your commercial pages. Marketing site, blog and documentation go on the root domain. The application goes on a subdomain and stays out of the index. Community is the only genuine judgement call.

Surface	Where it goes	Indexed	Reason
Marketing site	domain.com root	Yes	Every commercial page lives here and inherits host authority directly
Blog and resources	domain.com/blog/	Yes	Links earned by posts lift the same host that serves pricing and features
Docs and help centre	domain.com/docs/ via proxy, else docs.domain.com	Yes	Earns developer links, ranks for error, API and integration queries
Product app	app.domain.com	No	Authenticated, unstable HTML, session parameters, no link value
Community forum	domain.com/community/ if you control the template, else community.domain.com	Selectively	High URL count and low quality per URL, so it needs its own index rules

The subfolder preference is not theory. Every link a docs page or a blog post earns is a link to your host, and hosts are how Google accumulates trust in practice. Split those links across three hostnames and you are asking one brand to earn authority three separate times. The full argument, including the cases where a subdomain is the right answer, sits in the subfolder vs subdomain comparison.

Docs are the surface people get wrong most often. Teams proxy help.domain.com into /docs/, feel good about it, then discover the help centre article outranks the feature page for the product’s own category term. That is a query-level decision, not a hosting decision.

Why app.domain.com should never host marketing content

The app subdomain is the worst possible home for a page you want ranked. It sits behind authentication, so Googlebot sees a login screen rather than content. It generates session and state parameters that bloat any crawl that reaches it. Unknown routes return a 200 with an empty shell instead of a 404, which is the classic soft 404 pattern.

None of that is fixable without engineering work that would be better spent elsewhere. Put nothing indexable on app.domain.com, disallow the whole host in robots.txt, and stop treating it as free real estate.

There is one real exception and it is worth naming precisely. Public share surfaces, the kind Loom uses for recorded videos and Figma uses for community files, are genuine product-led SEO assets: real content, real URLs, real external links. Those belong on their own hostname with their own template, their own canonical policy and their own noindex rules for private or expired items. They do not belong mixed into the authenticated product.

URL rules that survive a rebrand

SaaS companies rename products, merge tiers and reposition categories roughly every 18 to 30 months. URLs that encode the current naming die on that schedule. Write slugs that describe the durable thing: the job, the integration, the category, the comparison.

Three more rules that save arguments later. Pick a trailing slash convention once and 301 the other version permanently. Cap path depth at three segments for anything commercial. Never put a version number, a year or a quarter in a slug you intend to keep.

If you are already carrying bad URLs, the question is whether the fix is worth the risk, which is a different exercise entirely. Work through the SaaS website migration playbook before you touch a single redirect rule.

Three clicks is the limit for any page that can convert

Click depth is the shortest path a crawler can take from the homepage to a URL using in-body and navigation links. It is the single number that best predicts how often your commercial pages get crawled, and you can measure it in about ten minutes with any crawler in the SaaS SEO tools set.

The working rule for a SaaS estate:

• Pricing, the main product page, the primary use case hub and the integrations hub sit at depth one
• Individual feature, use case, comparison and integration pages sit at depth two
• Blog posts and supporting content sit at depth two or three
• Programmatic page sets sit at depth three maximum, reached through a paginated hub with real links

Anything deeper needs a reason you would say out loud in a meeting. Depth five on a page that converts is not a nuance, it is a defect.

Two things make depth worse than it looks on a diagram. Mega menus rendered on hover through JavaScript often produce no crawlable links at all in the raw HTML, so the real depth is far greater than the design implies. And paginated hubs that use infinite scroll with no <a href> fallback strand everything past page one.

A before and after from a real estate rebuild

This is an anonymised composite drawn from several audits of the same shape. A workflow automation company at roughly 9M ARR had 41 feature and use case pages, all reachable only through a hover mega menu and a /product/ overview page. Twelve of those URLs had never been indexed. Screaming Frog with JavaScript rendering disabled found links to exactly four of them.

BEFORE
Home
 └ /product/ depth 1 (mega menu, JS rendered)
    └ /product/workflows/ depth 2
       └ /product/workflows/approvals/ depth 3
          └ /use-cases/approvals-for-finance/ depth 4 not indexed

AFTER
Home
 ├ /product/approvals/ depth 1
 ├ /use-cases/ depth 1 (hub, 41 HTML links)
 │ └ /use-cases/approvals-for-finance/ depth 2
 └ /integrations/ depth 1 (hub, 88 HTML links)

Three changes did the work. The mega menu got a server-rendered HTML fallback so the links existed without JavaScript. A real /use-cases/ hub replaced the overview page and linked every child in plain markup. And 60 existing blog posts received contextual body links pointing at the relevant use case page, chosen by topic rather than by rota.

Be honest about the distribution. Three pages produced about 70 percent of that traffic gain, and eleven pages barely moved at all. Flattening depth does not make a weak page good. It gives an already-decent page the crawl frequency and internal anchor text it should have had from the start. The way those hubs should be organised by topic rather than by product taxonomy is covered in the SaaS topic clusters guide.

Canonicals, pagination and hreflang belong in the template, not the page

Set these rules once per template and they stop being a recurring cleanup task. Set them per page and they will be wrong within a quarter.

Canonical tags: every indexable template emits a self-referencing canonical with an absolute URL, one per page, matching the trailing slash convention exactly. Parameter URLs canonicalise to the clean version. A page with a canonical pointing somewhere else should also be missing from your sitemap, and if those two disagree, the template is broken.

Pagination: give page two a self-referencing canonical, not a canonical back to page one. Google retired support for rel=prev and rel=next in 2019, so the working pattern is plain <a href> links between pages, self-canonicals throughout, and paginated URLs excluded from the sitemap while remaining crawlable. Avoid noindex on paginated hubs, because a long-term noindex is eventually treated as nofollow and the children lose their crawl path.

Hreflang: every locale variant references every other variant including itself, plus an x-default. Use subfolders such as /de/ rather than country domains unless you have a genuine legal or entity reason to split. Keep the slug identical across locales where the product name is identical, and translate the slug where the query is genuinely different in that market.

Navigation, footer and body links do different jobs

A link in the primary navigation appears on every page, which sounds powerful and mostly is not. Site-wide links are common, predictable and heavily discounted. A contextual link inside the body of a relevant article carries more relevance signal, because its surroundings describe what the target page is about.

The practical allocation for a SaaS site:

• Primary navigation: 20 to 25 links maximum, covering hubs and the pages you want at depth one
• Footer: 30 to 40 links, used for integration hubs, comparison hubs, legal and locale switching
• Body content: unlimited, chosen by topical relevance, and the main mechanism for lifting individual pages

Mega menus with sixty entries are the usual failure. Every link dilutes the others, the design team eventually hides half of it behind hover states, and the pages you actually want promoted end up sharing attention with a careers link. Cut the menu to hubs, then let the hubs do the distribution.

What an architecture rebuild costs, and when not to do one

Restructuring is not free and the industry undersells the risk. For a 400 page SaaS site, expect roughly three to six weeks of engineering plus two weeks of SEO time to map redirects, rebuild hubs, add HTML fallbacks and update sitemaps. Redirect mapping alone usually takes one to three days for a site that size.

Then expect a dip. A carefully executed URL change on a healthy site commonly costs 10 to 25 percent of organic traffic for four to eight weeks. A sloppy one costs more and sometimes never fully recovers, particularly where redirect chains stack up or the new URLs change meaning as well as address.

So here is the position: if your commercial pages are already at depth two, already indexed and already receiving contextual links, do not restructure. The diagram in your head is not worth a quarter of recovery. Spend the same effort on content and links instead, and use the SaaS SEO ROI calculator to compare the two options honestly before you commit budget.

Restructure when one of these is true: commercial pages are not indexed, crawl depth exceeds three for pages that convert, the same content is reachable at multiple URLs, or a rebrand has already made the current URLs wrong. Those are structural failures, and content cannot outrun them.

Architecture also fixes nothing about demand. A perfectly organised site for a product nobody searches for still returns nothing, which is a forecasting question rather than a structural one. Run the numbers in the organic traffic forecast calculator before you assume flattening depth will produce a pipeline.

Do these five things this month

None of this needs a redesign, and none of it needs new content. It needs someone to open a crawler, look at the actual depth of the pages that pay for the team, and fix the shortest paths first. If you would rather work through it with a structured sequence and deadlines, the SaaS SEO Sprint covers architecture in week one, and the wider SaaS SEO hub explains where architecture sits relative to content, links and measurement. The next thing to fix after the map is the plumbing, which is where technical SEO for SaaS picks up.