A SaaS company usually runs four kinds of pages under one brand: a marketing site, in-app screens, documentation, and a blog. Left as one undifferentiated pile, they compete with each other for crawl budget, authority, and clicks. Good SaaS website architecture keeps these pieces distinct but connected, so search engines can find your product pages and users can move between them without hitting a dead end.
Marketing site vs the app: subdomain or subdirectory
| Approach | SEO effect | Best for |
|---|---|---|
| Subdirectory (yoursite.com/app) | Keeps authority on one domain | Most SaaS companies, especially early stage |
| Subdomain (app.yoursite.com) | Treated closer to a separate host, authority doesn’t fully carry across | Apps with a genuinely separate infrastructure, security, or compliance need |
A subdirectory keeps the marketing pages, blog, and app under one root domain, so links pointing at your content also strengthen the domain the app sits on. A subdomain is treated by Google as closer to a separate site, so authority the blog and marketing pages build doesn’t automatically flow across to it. Subdomains still make sense for real technical reasons: different hosting, a stricter security boundary, or a separate codebase. Without one of those, a subdirectory is the stronger default. The logged-in app screens are usually noindexed anyway, since there’s nothing there for a search engine to rank.
Where docs and the help centre belong
Documentation often gets bolted onto whatever platform is easiest: a third-party help widget, a separate subdomain, a tool with its own login. That’s a missed opportunity: docs answer exactly the how-to and troubleshooting queries prospects search before they buy. Keep docs on the main domain under a path like /docs/ wherever your stack allows it, so the pages contribute to the rest of the site instead of sitting in a walled-off tool. Docs also need their own flat vs deep structure: the articles prospects actually search for should sit two or three clicks from the docs homepage, not six levels deep in a category tree that only makes sense to your support team.
Feature pages vs use case pages
Feature and use case pages answer different search intents, and merging them is how SaaS sites end up with duplicate or thin content. A feature page describes what the product does, automated invoicing, say. A use case page describes who’s using it and the job they’re hiring it for, invoicing for freelance consultants. Written separately, each targets a distinct query. Written as one page with a different headline swapped on top, they cannibalise each other and neither ranks cleanly.
Treat each use case as its own small silo structure: a use case page links out to every feature it depends on, and each feature page links back to the use cases it serves, without either repeating the other’s copy.
Linking blog content into product pages
Blog posts answer questions prospects are already searching, but on too many SaaS sites they sit as an isolated pile with no path back to the product. Every post should link, in context, to the specific feature or use case page it supports, not just to a generic homepage or a “book a demo” button in the sidebar. That’s how blog traffic and authority actually reach the pages that convert, instead of stopping at the article itself.
SaaS architecture is site architecture applied to a product with a marketing site, a docs library, and an app bolted together. A site architecture audit maps how authority currently flows between your marketing pages, docs, blog, and product pages, then shows you exactly which links and pages need to change.