Website Architecture for SaaS Sites

Website architecture is how your pages are organized and connected: the URL folders, the navigation and the internal links between them. For a B2B SaaS site, good architecture gives every page type a predictable home, keeps your commercial pages a click or two from anywhere, and lets the site grow from fifty pages to five thousand without a redesign.

Most SaaS sites don't get designed this way. They accumulate. A /features folder appears, then /solutions, then someone publishes comparison posts under /blog because that was the only template available. Fixing this later is possible, but it's easier when you know what you're aiming for.

The page types a SaaS site needs a place for

Say you run a 40-person SaaS for managing vendor risk. Your site will eventually hold most of these, and each works best in its own folder:

Page type	Example URL	Job
Product and features	/features/vendor-assessments	Explain what the product does
Solutions by role or industry	/solutions/healthcare	Match the product to a buyer's situation
Integrations	/integrations/okta	Confirm requirements and capture "X integration" searches
Comparisons	/compare/acme-vs-rival	Serve shortlisting buyers
Alternatives	/alternatives/rival	Serve people leaving a competitor
Pricing	/pricing	Close the decision
Blog	/blog/vendor-risk-questionnaire	Teach and attract
Glossary	/glossary/fourth-party-risk	Answer definition searches
Templates and tools	/templates/vendor-questionnaire	Earn links and leads
Docs	/docs/api/webhooks	Help users and support evaluation
Customers	/customers/northwind	Provide proof

Folders tell people and crawlers what a page is. They also make reporting far easier. When your comparisons all live in /compare/, you can filter Search Console by that folder and see at a glance how the group is doing. If they're mixed into /blog/, you can't.

Keep URLs simple and stable

Google's URL structure guidance recommends simple, descriptive URLs, using words and hyphens. For SaaS sites, a few further rules will save future pain.

Don't put product names in folders that might change. /features/pulse-reports becomes a problem when "Pulse" gets renamed. Describe what it does if you can: /features/live-reports.

Leave dates out of URLs. /blog/vendor-risk-2024 announces its age forever, even after a refresh.

Keep it shallow, within reason. /solutions/healthcare is better than /company/solutions/industries/healthcare. URL depth itself isn't the issue. What matters is how many clicks it takes to reach a page, though long URLs tend to reflect a structure that's become complicated.

Avoid changing URLs for the sake of it. A rename means a redirect and updated internal links. Don't do it just for tidiness unless the benefits are clear.

Decide on subfolders or subdomains deliberately. Your blog and docs can live on example.com/blog or blog.example.com, and Google has said it can handle both. In practice, a subfolder is often simpler to manage, since it shares one site's links and analytics setup. A subdomain may be justified by a separate platform. Most teams just pick the simplest option their stack will support.

Navigation does two jobs

Your main menu is for buyers, but it's also the set of links that appears on every page. That makes it the strongest internal link signal you have.

Put commercial pages in it. Features, solutions, pricing and customers belong there. Use plain labels: "Solutions" with "Healthcare" and "Financial services" underneath is better than an inventive name. See SaaS website navigation best practices.

Use the footer for the long tail. Your footer can link to your comparison hub, integration directory, glossary and templates, which might not earn a place in the main menu.

Make sure the links are real. Menus built so that their links appear only after a click or hover may be missing from the initial HTML. Check the page source. See our crawlability guide.

Add breadcrumbs on deeper pages. They help people get back up a level and add useful internal links. Marking them up with breadcrumb structured data can make them eligible for display in search results.

Hubs connect the long tail to the money pages

Directory-style hub pages are the part most SaaS sites underbuild. /integrations, /compare, /templates and /glossary should each be a real, crawlable page linking to everything in that set, with useful categories.

Then link across the types, which is where the structure really starts to pay off. For the vendor risk SaaS:

• A blog post on vendor questionnaires links to the questionnaire template and to the assessments feature.
• The healthcare solution page links to the HIPAA glossary entry, healthcare customer stories and related integrations.
• Each comparison page links to pricing and to the features in question.
• The glossary entry for fourth-party risk links to the feature that handles it.

This creates clear pathways from pages that attract readers to pages that convert them. Topic clusters are the same idea applied to content. Our internal linking strategy explains how to do the linking itself.

Handling the blog and pagination

A blog ordered only by date buries older posts, however good they are. Add topic pages that collect related posts, and link from them to your best work. Paginated archives should use real URLs that crawlers can follow, with each page having its own canonical. Don't try to fix this by pointing them all at page one.

Avoid a tag system in which each post gets a dozen tags, each producing a thin page with one or two articles. A small number of well-maintained categories usually does more good.

Keeping the product separate from the marketing site

The logged-in app has no place in your search-facing architecture. Serving it from app.example.com makes it easy to apply different rules, keeping it out of the index and separate from the marketing site. It also means a bug in the app is less likely to affect your marketing pages.

Publicly shared customer content needs a decision, too. Shared boards, forms and reports can create large numbers of URLs. Put them in a clearly defined path, so that you can apply noindex rules as a group. See our meta robots guide.

Docs often sit between the two, and they deserve thought. They can attract a lot of qualified traffic, so they should be crawlable and linked to and from the marketing site. See SEO for SaaS docs and help centers.

Why this matters for AI answers

A clear structure helps with AI search too, though not through any special trick. Plainly named pages, each covering one subject, are easy for any system to interpret. A page at /solutions/healthcare that says who it's for gives an answer engine something usable. Important content in text, in the initial HTML, is what Google's guidance on AI features asks for as well.

Changing an existing structure

If your site has grown messy, resist the urge to reorganize it all at once. A full restructure is a kind of migration, and it carries risk. A safer sequence looks like this:

1. Map what exists with a crawl, and mark what each page is for.
2. Fix internal links first. It doesn't change URLs, it's low risk, and it often brings the most benefit.
3. Add missing hubs, so that orphaned groups of pages get a home.
4. Use the new structure for all new pages. Comparisons go into /compare/ from now on.
5. Move old pages only when the case is clear, such as comparison posts stuck in /blog/. Use 301 redirects, and update internal links and the sitemap.

Going back to the vendor risk SaaS, the first month would probably involve no URL changes at all: only a proper integrations hub, a comparisons hub and better links from the blog to the product. Reassess after that, as you may find there's little need to move anything.

If you're planning a restructure and want a second pair of eyes before you start, book a call with Comppound.