Website architecture SEO for B2B SaaS: how to structure pages, URLs, and links.

What is website architecture, and does it matter for search engine optimization and AI answers?

Website architecture is how a website's pages are organized, categorized, and linked to each other. You will also see it called site architecture, site structure, website structure, or site hierarchy, and all of them describe the same plan: which pages exist, how they are grouped, how they are named in the URL, and which page links to which. Architecture refers to that plan. The navigation, the URLs, and the internal links are how it shows up for visitors and for search engine bots.

Does it still matter? Yes, mostly through links and clarity, not as a ranking trick. Google says it primarily finds pages through links from other pages it already crawled. It also says that organizing a site in a logical way can help search engines and users understand how your pages relate to the rest of the site, and adds that search engines will likely understand your pages as they are, whatever the structure. So site structure is a discovery and clarity tool: it decides whether search engine crawlers can reach a page, whether that page can show up on search engine results pages, and whether a person can find it without help. That makes it one of the technical SEO factors worth getting right early, because changing it later means redirects and a re-crawl. Our post on SaaS technical SEO covers the wider checklist.

For website visitors, the same structure is the user experience. A buyer comparing vendors wants pricing, security, integrations, and proof within a click or two, and a clear structure lets them find those pages without using site search.

The same holds for AI answers. Google says there are no additional requirements to appear in AI Overviews or AI Mode and no special optimizations needed: a page must be indexed and eligible to be shown in Google Search with a snippet. Among its best practices is making content easy to find through internal links. Google also describes a "query fan-out" technique, in which its AI features issue several related searches across subtopics and data sources, so a site with a clear page for each subtopic gives those searches something to find. Microsoft says assistants such as Copilot parse content into smaller, structured pieces and use headings to see where one idea ends and another begins, and it advises against hiding important answers in tabs or expandable menus.

Treat that as evidence that a clear structure helps, not proof that one layout wins. Some vendor guides say good site architecture directly decides how search engines discover, evaluate, and rank your content, but the Google and Microsoft pages we read describe discovery and understanding, not a ranking mechanism. Architecture is groundwork for any SEO optimization that follows, not a ranking factor you can switch on, and it won't lift search engine rankings if the pages are thin. Google also says its AI features need no new machine readable files, AI text files, or markup, a point our post on whether you need an llms.txt file covers.

How do search engines crawl and index a B2B SaaS site?

Search engines use automated programs, called crawlers or bots, to fetch web pages by following links from one page to the next. A search engine then decides whether to add each page to its index, the stored copy it uses to answer queries. To crawl and index a page, it has to find the page first, and a link is the most common way. Five points from Google's documentation shape how a B2B SaaS site should be built:

1. Links are the main discovery path. Google says every page you care about should have a link from at least one other page on your site, and the link has to be crawlable. Google can't reliably extract URLs from anchor elements that have no href attribute, so a button that navigates with JavaScript alone is a risky way to link to an important page.
2. Orphan pages go unfound. An orphan page is a page that no internal link points to. They are easy to create in a CMS: a page is published but never added to a menu or a hub. Search engines may never find one unless a sitemap lists it or another site links to it.
3. A sitemap helps, but it doesn't replace links. A sitemap helps search engines discover URLs, but Google says it doesn't guarantee that every item will be crawled and indexed. Google lists two signs that you might not need one: a small site, about 500 pages or fewer, and a site that is comprehensively linked internally. Keep an XML sitemap anyway, because it gives crawlers a second route to every URL. An HTML sitemap is something else, an ordinary page of links for people, and a site with clear navigation rarely needs one. The HTML and XML sitemap serve different readers.
4. Robots.txt controls crawling, not indexing. A robots.txt file is used primarily to manage crawler traffic. Google says it isn't a mechanism for keeping a page out of Google, and a disallowed page can still appear in results if other sites link to it. To prevent search engines from showing a page, use a noindex rule or password protection.
5. Crawl budget is rarely your problem. Crawl budget is how many URLs a search engine will fetch from a site in a given period. Google's guide on it is written for sites with 1 million or more unique pages that change about weekly, or 10,000 or more that change daily. Below that, Google says keeping your sitemap up to date and checking the Page indexing report regularly is adequate.

Which page types does a B2B SaaS site architecture need, from landing pages to docs?

The commercial pages that buyers compare, plus content sections that grow over time. Our guide to B2B SaaS website pages covers what each page should say; the table below covers where each one sits and what it links to.

Each content page should link to the commercial page its topic supports. A guide about migration risk links to the migration service, and an integration page links to the use cases it enables. A few rules keep the set tidy:

• One job and one parent per page. Decide which pages exist before you write them. Start with keyword research: group the queries your buyers use by intent, such as what a product is, how it compares, and what it costs, and give each group one page, so that different pages don't compete for the same query. Then map the pages to your business objectives, so the ones that lead to demo requests get the most prominent links.
• Hub pages stand in for category pages. B2B SaaS rarely has a category page in the e-commerce sense. The closest equivalents are a solutions hub, an integrations index, and a customers page that lists every story. Each is a parent page that links to its children and is linked from the navigation.
• Names that match. Google's SEO starter guide says a good title element, which people often call the meta title, is unique to the page, clear and concise, and describes the page accurately, and that a good meta description is short, unique to one particular page, and covers its most relevant points. Keep the page titles, the H1, and the URL in agreement about the topic.
• Landing pages on purpose. Campaign landing pages are the usual source of near-duplicates. If one repeats a commercial page, point it to the main page with a canonical link or keep it out of the index. If it targets a query of its own, give it a proper place in the structure.

How should you plan URL structure: folders, flat URLs, or subdomains?

Use readable words in URLs, folders where a section grows, and a subdomain only when there's a practical reason. A clear URL structure also hints at what each page covers, though Google presents it mainly as a help for people.

• Readable, SEO-friendly URLs. Google recommends readable words rather than long ID numbers, hyphens rather than underscores between words, and no session IDs where you can avoid them. It also warns that overly complex URLs, especially ones with multiple parameters, can cause problems for crawlers. Keep user-friendly URLs short and descriptive, avoid symbols and long strings, and write them in your audience's language. Many content management systems fill the slug from the page title, so edit it before you publish. Parts of the URL can appear in search results as breadcrumbs.
• URLs that reflect hierarchy. A path such as /integrations/hubspot tells a reader the page sits under integrations, and a section name in the path gives the page a parent. Leave dates and author names out of URLs, because a URL that changes later needs a redirect.
• Folders for growing sections. Google says that on a site with more than a few thousand URLs, grouping similar pages in directories can help it learn how often each directory changes and crawl directories at different frequencies. Below that size, folders mainly help people and the team that maintains the site. Google adds that search engines will likely understand your pages as they are, so there is no need to reorganize a working site only for this reason.
• Subdomain or subfolder. Google's URL documentation states no general preference between them outside its international guidance. One practical difference is that Google treats a subdomain, such as docs.example.com, as its own site for site names. Decide by who maintains the content and which platform it runs on, then link the two sets of pages both ways.

How should your internal linking structure connect a website's pages and share page authority?

With real links, descriptive anchor text, and a reason for each link. Internal links guide both visitors and crawlers to your high-value pages, and they are the part of your link profile that you fully control.

SEO tools report a "page authority" or similar score for each page, an estimate of how strong its links make it look. Google doesn't report that score in Google Search Console, so don't chase the number. What you can steer is where your own internal links point: the pages that receive the most of them are the ones your structure tells visitors and crawlers matter most.

• Descriptive anchors. Google says good anchor text is descriptive, reasonably concise, and relevant, and that for an image link it uses the alt text as the anchor. "See how pricing works" beats "click here". Anchor text with the topic words helps search engines understand the target, but repeating one exact keyword in every link reads as stuffing.
• No quota. Google says there's no magical ideal number of links a page should contain, and that if you think it's too many, it probably is. Link where it helps a reader understand the page they're on.
• Hub and spoke. A pillar page, such as a guide or solution page, acts as the hub: it links to each detailed page on the topic, and each detailed page links back to the hub, to related pages, and to one commercial page. Pillar pages earn their place when a topic is broad enough for several detailed pages; for a topic with one article, a pillar page just repeats it.

The table shows where each type of link lives and what it does.

To check the result, open the Links report in Google Search Console. Under Internal links, the Top linked pages table shows which pages receive the most links from within your own site, and Google suggests using it to confirm that core pages, such as the home page and the contact page, are properly linked. The report isn't a complete list of every link, so read it as a sanity check, not an audit. If a key commercial page sits near the bottom, your structure is pointing attention elsewhere. After any change, also check for broken links and redirect chains.

How many pages should a site have, and how many clicks from the home page should a page be?

There is no right number of pages. A B2B SaaS marketing site can work with 15 pages or 150, as long as each page has a job, a place in the hierarchy, and at least one link pointing to it. Google treats about 500 pages or fewer as small in its sitemap guidance, and its crawl budget guide targets sites with far more, so for most B2B SaaS companies the page count is not a crawling problem. Add more pages when a distinct buyer question needs its own answer, and merge pages that answer the same one.

Click depth is how many clicks it takes to reach a certain page from the home page. Much of the advice you will find repeats a three- or four-click rule, and the Google documentation we read sets no such limit. In a 2018 Google Webmaster Central hangout, as Search Engine Journal reported it, John Mueller said Google doesn't count slashes in URLs and that the number of clicks needed to reach content matters more than the URL structure; he named no number. Google's sitemap guidance describes a comprehensively linked site as one where Googlebot can find all the important pages by following links from the home page.

A flat structure, with few levels between the home page and any page, suits a B2B SaaS marketing site; a deep structure stacks folders and menus until pages are hard to reach. Vendor guides often add that flat is better for SEO, and the Google pages we read don't say so. The plain reason to stay flat is that fewer clicks make pages easier to find. Two practical rules follow:

1. Put every commercial page in the navigation or one link away from a hub, and aim for shallow crawl depth for the rest. On a well structured website of a few dozen pages, almost everything sits within two or three clicks anyway.
2. Keep an XML sitemap with accurate dates. Google says it uses the lastmod value only if it's consistently and verifiably accurate, and Bing asks site owners not to set lastmod to the time the sitemap was generated unless the content actually changed.

Several vendor guides claim that a clearer structure, or a breadcrumb trail, lowers bounce rates and raises conversion rates. We found no controlled study behind those figures, so test it on your own site by comparing engagement rate and demo requests for the pages you restructure, before and after.

How do navigation and breadcrumbs support user experience (UX) and a logical hierarchy?

Website navigation makes sections findable, and contextual links in the body carry meaning. A clear navigation menu helps buyers reach pricing, security, and proof in a click or two, which is a user experience result first and an SEO result second. Google's SEO starter guide describes the benefit of a logical structure as helping search engines and users understand how pages relate. Keep the top level short and make the mobile menu match the desktop one: Google uses the mobile version of a site's content for indexing and ranking, so a link that exists only in the desktop menu may be missing from what Google sees.

Every site has a hierarchical structure, planned or not: the home page at the top, sections beneath it, and detail pages beneath those. Breadcrumbs make that hierarchy visible. A breadcrumb trail shows the path from the home page to the current page, and it usually sits near the top of the page, above the title. Google recommends breadcrumbs that represent a typical user path to a page, instead of mirroring the URL structure. BreadcrumbList markup needs at least two list items, each with a position and a name, plus a URL for every item except the last, and Google uses it to categorize the information from the page in search results. A logical hierarchy gives each page one parent and each parent one hub, which also lets people move up a level and find content faster.

Entity markup tells search engines who the site belongs to. Google says Organization markup can help it understand your organization's administrative details and disambiguate your organization in search results; it goes on your home page or on a single page that describes the organization, and no properties are required. For your site name in Google Search, WebSite structured data must be on the home page, and Google supports one site name per domain or subdomain, not per subdirectory. Author pages in their own folder, such as /authors/name, give every byline somewhere to point. Whatever you mark up has to match what's visible on the page.

How do site speed, Core Web Vitals, and mobile design fit into website architecture?

Speed isn't architecture, but architecture decisions shape it: how many templates you maintain, which scripts load on every page, and how images are served. A fast loading website also keeps the structure you built from frustrating the people who use it.

Google's page experience documentation says Core Web Vitals are used by its ranking systems, that there is no single page experience signal, and that Google always seeks to show the most relevant content, even if the page experience is sub-par. So treat page speed as a foundation, not a substitute for a useful page. The three metrics are Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). Google sets "good" at an LCP of 2.5 seconds or less, an INP of 200 milliseconds or less, and a CLS of 0.1 or less, measured at the 75th percentile of page loads. If the largest element on a page is an image, web.dev's advice is to compress images, use modern image formats, serve the optimal image size, and never lazy-load the LCP image.

Mobile design belongs in the same plan. Google uses the mobile version of a site's content, crawled with its smartphone agent, for indexing and ranking, which is what mobile-first indexing means. It recommends responsive design, which serves the same HTML on the same URL on every device, and says the mobile site should contain the same content as the desktop site, with equivalent titles, meta descriptions, and structured data. Check key pages on mobile devices after every template change.

How do you fix a messy site structure?

Map what exists, decide where each page belongs, and move pages with redirects, not deletions. A messy structure usually shows up as orphan pages, duplicate pages, and menus that grew one request at a time. If you are the digital marketer who inherited the site, do the first step before anything else, and don't touch a URL until you have the list. An SEO expert or an agency should start in the same place, so ask to see the URL map before anyone changes the navigation.

1. Export every URL. Combine the CMS export and the XML sitemap, and add clicks and impressions per page from Google Search Console. That gives you a baseline for measuring SEO progress later.
2. Give each page a type and a parent. Every page should belong to one section and one hub. Pages that fit nowhere are candidates to merge or remove.
3. Find weak spots. List orphan pages, important pages with few internal links, and near-duplicate pages that compete for the same query. For duplicate content, Google's guidance is to pick a canonical URL for each page and mark it with rel="canonical", redirect the duplicates with permanent redirects, or list only canonical URLs in the sitemap. Google also says not to use robots.txt for canonicalization.
4. Redirect every change. Google's site-move guidance says to map each old URL to its new one, use permanent server-side redirects such as 301 or 308, and send each old URL straight to its final destination instead of chaining redirects. Keep the redirects for as long as possible, generally at least one year, and change internal links to point to the new URLs directly.
5. Update navigation, breadcrumbs, and the sitemap. Then submit the new sitemap in Search Console.
6. Watch the moved pages. Google says it can take a few weeks or more for new URLs to show, so check the Page indexing report and the performance of the moved URLs over several weeks, and compare them with your step 1 baseline before you judge the SEO efforts.

Treat it as a small technical SEO project with its own redirect list, so search engines and users never meet a dead end. Our website redesign SEO checklist covers the rules for a larger change.

What does this site architecture look like on a real site?

Here is benormedia.com's own structure, from its sitemap on October 19, 2026.

Service and solution pages sit at the root, with no /services/ or /solutions/ folder, even though the footer groups them under Services and Solutions. At eleven pages, that is fine: the grouping lives in the navigation, and the URLs stay short. Folders do their job where content grows, in /blog/ and /guides/. If integration pages or customer stories were added, each would get a folder of its own for the same reason.

Three details show the hub-and-spoke pattern in practice. The headless CMS SEO post carries a breadcrumb trail of Home, Blog, and the post title, with the current page not linked. It ends with related-resource links to the headless CMS page, the Webflow vs custom code guide, and the technical SEO post, so one post points to a service, a guide, and another post. And every URL in the sitemap has a lastmod date, the newest dated October 20, 2026.

We plan site architecture as part of B2B SaaS website builds, so we have an interest in this topic. For how we approach structure in a build, see our B2B SaaS web design page.

Questions about website architecture