If you've ever inherited a corporate marketing site as a dev and thought "who architected this?" — this post is for you. Spoiler: usually, nobody did. It grew page by page, request by request, until the sitemap looked like unmanaged tech debt with a nav bar on top.
We build and maintain corporate websites for clients at https://softwin.io/, and the pattern is remarkably consistent: sites that convert well were structured deliberately before a single component was built. Sites that convert poorly grew organically and got "fixed" with design later.
Here's the framework we actually use, written for people who think in systems, not just page layouts.
Structure ≠ sitemap
A sitemap is a static artifact. Structure is the system made up of three layers:
1. Information Architecture (IA)
→ how content is grouped/labeled/hierarchized
2. Navigation
→ how users traverse that hierarchy (nav, footer, breadcrumbs, in-content links)
3. Conversion pathways
→ the sequence of pages/actions that move a visitor toward a goal state
You can have a perfectly normalized IA and still convert badly if the navigation doesn't match the user's mental model, or if there's no clear "next state" from any given page. Think of it like a well-indexed database with no sane query patterns — technically correct, practically useless.
Search engines effectively "crawl the graph" of your site the same way — internal links are edges, pages are nodes, and PageRank-style signals propagate through that graph. A shallow, well-connected graph concentrates authority on your priority pages. A flat, disconnected one dilutes it. This isn't just an SEO platitude — it's graph theory applied to your <a> tags.
Why this is an engineering problem, not just a marketing one
If you're the dev (or dev-adjacent person) responsible for the corporate site, structure decisions affect you directly:
- Routing complexity. A sloppy IA means an ever-growing pile of route exceptions and one-off redirects.
- Migration cost. Restructuring URLs on a live, indexed site means building and QA-ing a redirect map — get the taxonomy wrong up front and you'll be doing this again in 12 months.
- CMS/content model design. Your structure should inform your content model (collections, taxonomies, relationships) — not the other way around. Retrofitting a content model onto an accidental structure is painful.
- Performance and crawl budget. Bloated, redundant page structures waste crawl budget on low-value pages instead of the ones that drive pipeline.
Basically: bad IA becomes your problem eventually, whether or not you were in the room when it was decided. Better to be in the room.
The framework
1. Start from goals, not pages.
Every page should map to a business outcome: generate a demo request, rank for a specific query, support a sales conversation. If a page can't answer "what business goal does this serve," cut it or merge it.
2. Map audiences and journeys before wireframes.
Prospects, existing customers, candidates, partners — different entry points, different first questions. Do this before anyone opens Figma, or the nav ends up shaped by internal politics instead of user intent.
3. Design the hierarchy by topic, not by team.
The most common anti-pattern: nav structured around internal departments instead of buyer intent. Group by use case / industry / product line. Target a max depth of 3 clicks from homepage to any conversion-critical page — treat it like you'd treat API depth: shallower is almost always better.
4. Core page types to model in your content system:
/ → homepage, single value prop, routes by audience
/solutions/{use-case}/ → grouped by buyer use case, not internal team
/case-studies/{slug}/ → proof content, linked FROM solution pages
/about/ → credibility: team, story, certifications
/resources/{slug}/ → top-of-funnel content, links INTO commercial pages
/pricing/ or /get-started/ → low-friction next step
/contact/{intent}/ → segmented by visitor intent, not one generic form
5. Treat internal links as a directed graph you're actively optimizing.
Every resource/blog page should link to at least one relevant commercial page. This is the cheapest conversion lever most teams ignore — it's just link placement, no redesign required.
6. Lock URL taxonomy before development starts.
/solutions/healthcare-data-integration/ over /page?id=214. Decide this at the planning stage. Changing it later means a redirect map, a crawl audit, and monitoring for ranking drops — all avoidable with 30 minutes of planning up front.
7. Structured data and semantic markup aren't optional anymore.
Schema.org markup (Organization, Product, FAQPage, BreadcrumbList) helps search engines and AI answer engines parse your hierarchy correctly. If you're already thinking in structured data for your app, apply the same rigor here.
8. Build for mobile-first navigation patterns.
A meaningful share of B2B research happens on mobile at some point in the journey. If your IA only "works" with a desktop mega-menu, you're losing a segment of visitors before they see your content.
9. Instrument before you ship, not after.
Analytics and event tracking should exist before launch, not get bolted on when someone asks "why isn't this converting" three months in. Structure decisions should get revisited quarterly against real navigation and conversion data.
What we've seen in practice
When we scope a corporate site rebuild, the first deliverable isn't a wireframe — it's a content and conversion map: every planned page, its audience, its primary search intent, and the one action it should drive. This one exercise typically eliminates 30–40% of "must-have" pages that don't actually serve a distinct purpose, and it surfaces gaps — usually mid-funnel proof content — that nobody noticed were missing.
The recurring failure mode we fix: teams want to add pages to look more comprehensive, when the actual fix is consolidating pages and reinforcing internal links between the ones that remain. A tight 25-page structure with strong internal linking will outperform a sprawling 90-page structure with weak connections, every time — same as a clean, well-indexed schema beats a denormalized mess with the same data.
Common mistakes (a.k.a. anti-patterns)
- Nav mirrors the org chart, not the buyer's mental model
- Multiple competing CTAs per page — no clear primary action
- Orphaned pages — strong content (case studies especially) with zero inbound internal links
- Excessive click depth — key pages 4–5 clicks from home
- One generic contact form for every visitor intent
- Redesigns that change URLs with no redirect plan — silently torching years of accumulated SEO equity
FAQ
How many pages should a corporate site have?
No fixed number. The real test: does each page serve a distinct search intent or buyer question? Prefer fewer, stronger pages over many thin ones.
Where should CTAs live on a page?
Above the fold, repeated after key proof points, and again at the bottom — matched to that page's position in the funnel, not identical site-wide.
Does structure actually affect SEO rankings?
Yes. Internal linking and hierarchy are how search engines infer topical relevance and page importance. Concentrated structure = concentrated authority.
How often should structure be reviewed?
At least annually, or after any meaningful shift in product lines, target markets, or conversion/bounce metrics.
What tools are useful for planning this?
Card-sorting/sitemap tools (Miro, Whimsical) combined with real analytics and keyword data — plan from actual behavior, not assumptions.
Wrapping up
A corporate site that converts isn't a design problem first — it's an information architecture problem that design and copy inherit. Get the structure right — goals-first hierarchy, clean taxonomy, deliberate internal linking — and everything built on top of it gets measurably easier to make effective.
At https://softwin.io/, this is literally the first thing we map before writing a line of front-end code on a corporate site project.
Top comments (0)