B2B Website Design: The Page Inventory Before the Pixels

B2B website design is the set of decisions about which page templates a business software site needs, what each of those templates has to contain, and which of them are supposed to earn search traffic. It is easy to skip, because a moodboard is easier to react to than a page list. This guide is for the founder, CMO or Head of Growth commissioning or rebuilding a B2B software marketing site, and it works through the page inventory first: twenty-one page types, which are one template and which are many instances of one, which should be indexed, and what ships in which phase. Visual design matters. It matters after this.

The short version

• A B2B site is a template count, not a page count. Two sites with identical page counts can be completely different amounts of work.
• Six of the twenty-one page types below should carry a no-index decision. The two rows worth checking first are the thank-you page, which gets indexed by accident, and the demo page, which gets noindexed when it should rank.
• Build order should follow the questions sales already gets asked, not the left-to-right order of the navigation bar.
• The design decision that costs the most to reverse is the navigation, not the hero.
• The guides ranking for this query do list page types. What none of the ones I read attaches to that list is which types are one template versus many instances, which should be indexed, and what ships first.

How is B2B website design different from B2C?

In the number of people it has to satisfy, and in how long it has to keep satisfying them. A consumer site usually persuades one person inside one session. A B2B software site gets read by an evaluator, forwarded to a manager, skimmed by a finance or security reviewer, and then reopened weeks later by someone who was not in the original conversation.

That single structural fact drives almost every design decision worth arguing about.

Decision	Consumer commerce site	B2B software site
Who decides	One person, usually in one visit	Several people in different roles, rarely at the same time
What a page has to do	Complete a purchase	Survive being forwarded to someone who has no context
What conversion means	A transaction	A form fill that starts a sales conversation
Where the content ends up	Nowhere, the session ends	In a Slack thread, a comparison doc, a procurement review

The practical consequence: a page that only makes sense in sequence, after the hero and the three feature blocks above it, does not survive B2B. Each page has to be a standalone argument, because each one is somebody's entry point. Our guide to how B2B buying committees search covers the demand side of the same problem.

Where B2C thinking still applies: speed, clarity, and form friction. Nothing about a long sales cycle makes a slow page acceptable or a fourteen-field form reasonable.

What pages should a B2B software website have?

Twenty-one page types, though a launch needs fewer than half of them. The inventory below is the article. Every row carries three decisions that the ranking guides I read do not attach to their page lists: whether the type is one template or a template with many instances behind it, whether it should be in the index, and which build phase it belongs to.

Read the phases this way: Phase 1 is what has to exist on launch day. Phase 2 is the first ninety days after launch. Phase 3 is built when there is evidence you need it, not before.

Page type	One template or many instances	Index it?	Phase
Homepage	One template, one instance	Index	1
Solution or use-case page	One template, many instances	Index	1
Product or feature page	One template, many instances	Index	1
Pricing	One template, one instance	Index	1
Contact	One template, one instance	Index	1
About	One template, one instance	Index	1
Demo request	One template, one instance	Index, it answers a real query	1
Thank-you or confirmation	One template, many instances	No index: no query to answer	1
Legal set (terms, privacy, DPA, security)	One template, few instances	Index, low priority	1
Integration page	One template, many instances	Index once each has real content	2
Comparison page	One template, many instances	Index	2
Case study, plus the story index	Two templates, many story instances	Index	2
Resources or blog index, plus the post template	Two templates, many post instances	Index	2
Trial or signup marketing page	One template, one instance	Index, it answers a real query	2
Gated resource landing page	One template, many instances	Index the page, never the file	2
Paid campaign landing page	One template, many instances	No index: competes with organic	2
In-product signup or login	One template, one instance	No index: no public content	2
Docs entry point	One template, one instance	Index	3
Blog tag or category archive	One template, many instances	No index: thin, duplicates index	3
Internal search results	One template, unlimited instances	No index: unbounded URL space	3
Careers, plus the role template	Two templates, many role instances	No index on expired roles	3

Count the Phase 1 rows and you get nine page types. Three of them, about, contact and the legal set, can share one simple content template, so the real build is closer to seven. That is a launchable B2B software site. Everything else is an argument you can have after you have a site.

The row worth arguing about is comparison pages, and the argument tends to be about brand safety rather than architecture. It sits in Phase 2 here for a practical reason: a comparison page written before you have heard the objection from real prospects is a guess, and a guessed comparison page is worse than none.

Which page types are one template and which are many instances of one?

Eight of the twenty-one are single instances, and the rest are templates with a variable number of pages behind them. That distinction decides three things at once: how the content model in the CMS is shaped, whether the page type can be scaled without a designer, and whether it is a candidate for generation at all.

A single-instance page can be a bespoke layout. The homepage, the pricing page and the about page are argued over individually, and building each as its own thing is defensible. A many-instance page cannot work that way. The moment a solution page is a bespoke layout, adding the seventh solution costs the same as adding the first, and the team stops adding them. That is how sites end up with a handful of solution pages and a sales deck listing far more.

The content model is the real deliverable: a many-instance template needs named, typed fields in the CMS, so a marketer can add an integration page without opening a design tool. If the CMS field for a solution page is a single rich-text blob, you do not have a template. You have a page builder, and the eleventh solution page will look nothing like the first.

The cost dimension sits in a separate article; what a B2B software marketing site costs to build works through pricing by template rather than by page. This piece stays on what each template contains and whether it should rank.

Where generation stops being appropriate: integration and comparison pages tempt teams into generating hundreds of near-identical URLs from a database. The boundary is not the technique, it is whether each page has something of its own. Google's spam policies documentation defines scaled content abuse as generating many pages primarily to manipulate rankings rather than to help users, and describes the problem as large amounts of unoriginal content with little value, however it was produced. Generating forty integration pages where each one has a real setup procedure, real limitations and real screenshots is a content model. Generating four hundred where the only variable is a company name is the thing that policy describes.

Which pages should rank, and which are conversion endpoints?

A page earns a place in the index when there is a query it is the best answer to. Everything else on a B2B site exists to convert, confirm, or serve a logged-in user, and those pages should be kept out of search deliberately rather than by accident.

Two rows are worth checking before any of the others, and they point in opposite directions.

• Demo and trial pages get noindexed when they should rank: "book a demo" and "free trial" for a named product are real queries with real intent behind them. A team that treats every form page as a conversion endpoint removes its highest-intent page from search.
• Thank-you pages get indexed when they should not be: a confirmation page answers no query, and once it is in the index it pollutes conversion measurement and occasionally outranks the page that should have been found.

The instrument is noindex, and the one trap worth naming is that it only works if the crawler can reach the page. Google's documentation on blocking indexing states that for the rule to be effective the page must not be blocked by robots.txt and has to be otherwise accessible to the crawler, because a crawler that cannot fetch the page never sees the rule. Blocking a directory in robots.txt and putting noindex on the pages inside it is how teams end up with neither.

Our guide to whether a page should be indexed at all sets out the decision tree for an individual landing page. The inventory above applies that same rule across the whole page set at once, which is the version you need when you are scoping a build rather than fixing one URL.

The check that catches most of this: before launch, list every template and write the intended robots directive next to it. Then compare that list against what the staging build actually serves. The gap between the two is where launch-day indexation damage lives.

In what order should you build them?

In the order sales needs them, which is almost never the order the navigation implies. The navigation reads left to right and tempts teams into building it that way: Product, Solutions, Pricing, Resources, Company. The build order that works starts from the questions a prospect asks before they will take a call.

From my experience, the page type teams build last is the one sales needed first. Comparison and integration pages get deferred into a phase that never arrives, while the about page gets three rounds of revision. Meanwhile the sales team is answering "how are you different from X" and "does it work with Y" by hand, in email, several times a week.

A sequence that holds up:

• Phase 1, launch: homepage, one solution template with two or three instances live, product or feature pages, pricing, demo request, contact, about, legal, and the thank-you template. Nine page types, roughly seven templates.
• Phase 2, first ninety days: the case study template and its index, the blog index and post template, integrations, comparisons, the trial page. This is the phase where the site starts earning search traffic rather than receiving it.
• Phase 3, on evidence: docs entry point, careers, archives, anything programmatic. Build these when the demand is measurable, not when the sitemap looks incomplete without them.

When this order is wrong: a developer-tools company selling to engineers should move the docs entry point into Phase 1. If the product is evaluated by reading the API reference, docs are not a Phase 3 nicety, they are the product page. Our website development work starts with exactly this scoping question rather than with a design concept.

How should navigation work when four roles are evaluating you?

With one menu organised by problem, not four menus organised by role. Role-based navigation sounds right in a workshop and tends to fail in practice, because a visitor rarely identifies with the label you gave them, and because every role you add multiplies the paths you have to maintain.

Two publicly checkable examples, read on 23 September 2026. Stripe's primary header carries five items: Products, Solutions, Developers, Resources and Pricing. HubSpot's carries five: Products, Solutions, Pricing, Resources and About. Neither splits the top level by job title. Stripe's one distinctive decision is elevating Developers to the top level, which tells you who it thinks is in the room.

In our implementation work, the pattern that survives is a shallow top level with depth inside the dropdown: a small set of durable categories in the bar, and role or industry entry points one level down where they can be added and removed without redesigning anything.

Three rules that hold up in practice:

• Keep the top level small and durable: if a top-level item will be renamed when the product roadmap changes, it belongs one level down.
• Make the URL path match the menu path: Google's URL structure guidance recommends organising content so URLs are constructed logically and are intelligible to humans, and using hyphens rather than underscores between words. A menu hierarchy that the URLs contradict confuses both readers and crawlers.
• Give every template one canonical parent: a page reachable from four places in the menu and from none in the URL hierarchy is a page nobody can describe.

The cost of getting this wrong: navigation is the hardest thing on the list to change later, because changing it means changing URLs, and changing URLs means redirects, lost signals and a recovery period. The hero image can be replaced on a Tuesday afternoon.

What does good B2B website design look like in practice?

It looks like a site where you can tell what each page type is for within five seconds of landing on it. That is a harder standard than it sounds, and it is more useful than a gallery of screenshots, because a screenshot cannot show you a content model.

When you look at a B2B site you admire, four structural things are worth reading rather than the visual style:

• Count the top-level navigation items: both examples above sit at five, and a bar that keeps growing is a sign the categories were never really decided.
• Find the many-instance templates: open two solution pages and two integration pages. If they share a skeleton with different content, there is a template. If they are visually unrelated, there is not, and the site will stop growing.
• Check what sits at the top level that you would not expect: Stripe putting Developers beside Pricing is a positioning statement rendered as information architecture.
• Follow the conversion path from a deep page: land on a blog post or an integration page and see how many clicks it takes to reach a demo. If the answer is more than two, the conversion endpoints were bolted on rather than designed in.

What not to copy: the visual language of a company at a completely different stage. A site built to be read by procurement at a bank and a site built to convert self-serve signups are solving different problems, and borrowing the layout of one for the other copies the surface and none of the decisions underneath.

What breaks after launch?

Navigation, templates and redirects, all of them slowly and none of them visibly. A B2B site rarely fails at launch. It degrades through small changes that nobody logged.

• Navigation drift: items get added to the menu one at a time, each addition reasonable, until the top level has nine items and no category means anything. The fix is a scheduled review, not better judgement in the moment.
• Orphaned templates: a template built for a campaign stays in the codebase with two pages on it, unmaintained and usually still indexed. Every template needs a named owner or a deletion date.
• Redirect debt: each small restructure adds redirects, chains form, and eventually a redirect points at a redirect that points at a 404. Audit the chain, not just the endpoints.

The launch-day and ongoing technical work sits in a companion piece: what goes in an SEO build spec covers rendering strategy, the pre-launch checklist and the foundations this inventory assumes are in place.

When does the inventory tell you not to rebuild?

When the inventory you write down and the inventory you already have are close to the same list. That result is common and it is worth taking seriously, because a rebuild that changes the paint and keeps the structure is an expensive way to get a new hero image.

Three signals that the answer is a set of targeted additions rather than a rebuild:

• The templates are right and the instances are missing: you have a working solution template and three solution pages where you need nine. That is a content project, and it will ship faster than a rebuild.
• The problem is measurable and local: one slow template, one broken form, one page type that was never noindexed. Fix the named thing.
• Nobody can state what the new site would do that the current one cannot: if the brief is "it looks dated", the honest scope is a design refresh on the existing structure.

The case for a genuine rebuild is structural: the content model cannot express the page types you need, the URL hierarchy contradicts how the product is now organised, or the platform cannot serve a template you have to have. Our breakdown of when a redesign is the wrong purchase works through the scoping side of that decision.

The habit worth building is simple and slightly unglamorous: write the page inventory before the moodboard, and make it a table rather than a list, because a table forces the two columns a list lets you leave out. A page list is a wish. An inventory with a template decision and an index decision on every row is a scope.

This week, open a spreadsheet and list the page types your current site actually has. Mark each one as a single instance or a template, and write index or noindex beside it. The rows where you hesitate are the ones to fix first.