Architecture & Governance
SaaS Content Taxonomy & Information Architecture Standard
A practical standard that names, groups, and routes every page type in a SaaS site. Use this to build a clear information architecture, consistent URL taxonomy, robust internal links, and schema that search systems understand.
Objective and scope
This standard gives your SaaS site a predictable structure that users and systems can navigate without friction. It covers naming, page types, URL patterns, hubs and spokes, breadcrumbs, schema, internationalization, routing, and governance.
Structure should be simple and consistent. Google’s guidance favors clean information architecture, crawlable links, and helpful content. See the SEO Starter Guide and Search Essentials.
Core principles
One idea per URL
Each canonical URL owns a single concept or task. Avoid near duplicates and parameterized content for core pages. Use canonicals to consolidate variants. See duplicate URL consolidation.
Shortest clear path
Prefer short, human-readable slugs over nested depth. Keep routes flat where possible and describe content with the fewest words that still make sense.
Consistent names
Use canonical names for entities: product, features, roles, industries, and integrations. Define synonyms once inside the page, not in the URL.
Crawlable links
Use standard anchors with href. Avoid JS-only click handlers for primary navigation. See Google’s note on crawlable links.
Structured signals
Use Breadcrumb, Article, Product, FAQ, and Organization schema where it matches visible content. Follow markup policies. See structured data overview.
Performance and readability
Fast LCP, stable CLS, and clear headings improve outcomes. Targets are defined at web.dev. Use short paragraphs, meaningful subheads, and scannable tables.
SaaS page inventory
These are the standard page types most SaaS sites need. Treat each as a template with defined fields, CTAs, and internal link rules.
Home
- Purpose: orient and route
- Key fields: positioning, primary proof, top paths
- Links: features, solutions, pricing, demo
- Slug: /
Features
- Purpose: show capabilities and outcomes
- Fields: problem, feature, proof, CTA
- Links: related features, pricing, demo
- Slug: /features/[capability]
Solutions
- Purpose: align to role, industry, or use case
- Fields: pains, outcomes, proof
- Links: features, case studies, pricing
- Slug: /solutions/[role|industry|use-case]
Pricing
- Purpose: clarify plans and next step
- Fields: plans table, FAQs, legal notes
- Links: demo, compare plans, security
- Slug: /pricing/
Integrations
- Purpose: show ecosystem and workflows
- Fields: directory filters, integration profiles
- Links: documentation, features
- Slug: /integrations/[vendor]
Security & Trust
- Purpose: reduce risk and answer due diligence
- Fields: SOC 2, ISO, architecture, data handling
- Links: status page, DPA, pentest summary
- Slug: /trust/, child: /trust/security
Docs & KB
- Purpose: help users self-serve
- Fields: tasks, steps, parameters, code samples
- Links: product, in-app help
- Slug: /docs/[area]/[task]
Case studies
- Purpose: show proof
- Fields: problem, solution, outcomes, metrics
- Links: solutions, demo, pricing
- Slug: /customers/[company]
Resources
- Purpose: host standards, tools, templates
- Fields: catalogs, filters, CTAs
- Links: related guides and tools
- Slug: /resources/[type]/[name]
Keep page types discrete. A feature is not a solution. A solution is not a case study. Discrete templates improve clarity and reporting.
Naming and URL rules
Names and slugs are the spine of your IA. Pick rules and apply them everywhere.
| Item | Rule | Example | Rationale |
|---|---|---|---|
| Case | lowercase | /integrations/salesforce | Prevents duplicates and errors |
| Separators | hyphens | /features/role-based-access | Readable and standard |
| Stop words | avoid unless needed | /pricing not /the-pricing-of-our-product | Simplicity |
| Trailing slash | enforce one style | Prefer /pricing/ | Consistent canonicals |
| Dates | avoid in slugs | Use on-page updated note | Evergreen URLs |
| Versioning | use child paths for docs | /docs/v2/api/ | Clear upgrades |
Google encourages simple, human readable URLs. See the relevant sections in the Starter Guide.
Hubs, spokes, and breadcrumbs
Hub pages
- Group by theme or audience: Learn, Compare, Implement
- List spokes with short descriptions and consistent anchors
- Add FAQ or short definitions for key terms
Spoke pages
- Link back to the hub near the top and bottom
- Link laterally to adjacent spokes when relevant
- Use anchor IDs for sections to enable deep links
Breadcrumbs
Use visual breadcrumbs and BreadcrumbList schema. Keep labels short and match the navigation. See Google’s breadcrumb guidance.
<script type="application/ld+json">
{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[
{"@type":"ListItem","position":1,"name":"Resources","item":"https://accordcontent.com/resources/"},
{"@type":"ListItem","position":2,"name":"Standards","item":"https://accordcontent.com/resources/standards/"},
{"@type":"ListItem","position":3,"name":"SaaS Content Taxonomy & IA"}
]}
</script>Routing and redirects
Routing defines which template serves which path, and how old paths resolve. Clean routing avoids duplicate content and broken journeys.
Template routing map
- /features/* → Feature template
- /solutions/* → Solution template
- /integrations/* → Integration profile
- /customers/* → Case study
- /docs/* → Docs layout
Redirect rules
Use 301 for permanent moves. Keep rules declarative in code or at the edge, and prefer path based patterns to reduce maintenance.
# Netlify _redirects examples
/feature/* /features/:splat 301
/solutions/industry/ /solutions/ 301
/docs/v1/* /docs/v2/:splat 301Keep internal links pointed at the canonical destination to avoid chains.
Schema and knowledge signals
Use schema that matches visible content. Never mark up what users cannot see. Validate before publishing.
Organization
Publisher details and sameAs profiles improve clarity. Add once sitewide.
Product or SoftwareApplication
Feature pages can use Product when they describe a sellable plan or module. Developer focused product pages may use SoftwareApplication. Ensure fields like name, description, offers, and operatingSystem fit your reality.
Article, FAQ, HowTo
Standards and guides can use Article. Use FAQ for on-page Q and A. Use HowTo only when steps are the main content. Policies live in Google’s schema policies.
Validate in the Rich Results Test. Keep markup aligned with user-visible content.
Internationalization and hreflang
If you localize, plan locales, slugs, and hreflang at the start.
Locale strategy
- Subfolders per locale: /en/, /de/
- Mirror IA across locales where possible
- Keep slugs translated or transliterated consistently
Hreflang basics
- Reciprocal links between alternates
- One x-default for fallback
- Include in head, sitemap, or HTTP headers
See Google’s localized versions guidance.
Accessibility and UX writing
Headings and landmarks
One H1 per page. Logical H2 and H3. Use semantic regions like <nav>, <main>, and <footer>. WCAG guidance is on the W3C site.
Links and anchors
Make link purpose clear in the text. Avoid “click here”. Use accessible anchor targets and avoid hidden content that is essential for understanding.
Microcopy standards
Use concise headlines, informative labels, and consistent term choices. NN/g research shows readers scan, so clarity wins. See NN/g’s note on the F-pattern.
Measurement and governance
Content taxonomy field
Create a GA4 custom dimension such as content_group to tag pages by type: Feature, Solution, Pricing, Case Study, Docs, Resource. Register in GA4 and send with page_view. See GA4 docs for custom dimensions.
Governance sheet
- Page type, owner, route, schema used
- Canonical URL, alternates, last updated
- Inbound links from hubs and outbound to BOFU
Track impact with Search Console’s Performance report, Page indexing, and Enhancements. Pair with GA4 events and conversions to show how structure affects outcomes.
Templates and examples
Feature page
| Field | Requirement | Notes |
|---|---|---|
| H1 | Outcome led name | Align with nav label |
| Problem | Short paragraph | Use customer language |
| Feature | What it does | Bullets or short list |
| Proof | Metric or quote | Link to case study |
| CTA | Primary action | Demo, trial, or talk |
| Internal links | Related features | Crawlable anchors |
| Slug | /features/[capability] | Lowercase, hyphens |
| Schema | Product | Reflect visible fields |
Solution page
| Field | Requirement | Notes |
|---|---|---|
| H1 | Role or industry | Match nav category |
| Pains | 3 to 5 bullets | Use their words |
| Outcomes | 3 to 5 bullets | Map to features |
| Proof | Logo + metric | Link to customer story |
| CTA | Primary action | Clear and simple |
| Links | Features, pricing | Descriptive anchors |
| Slug | /solutions/[role|industry] | Short and stable |
| Schema | Article or Product | Match content |
Integration profile
| Field | Requirement | Notes |
|---|---|---|
| H1 | Brand + “integration” | Consistent format |
| What it connects | Short summary | Use cases first |
| Setup | Steps or link to docs | Numbered list |
| Limits | Edge cases | Be transparent |
| Slug | /integrations/[vendor] | No punctuation |
| Schema | SoftwareApplication | Where relevant |
Implementation checklist
- Inventory pages by type and owner
- Pick URL rules: case, hyphens, trailing slash
- Define hubs and spokes with descriptive anchors
- Add breadcrumbs visually and in JSON-LD
- Route templates by path patterns
- Write redirects for legacy paths and test
- Add schema that matches visible content
- Configure GA4 content_group and key events
- Connect Search Console and submit sitemaps
- Publish a governance sheet and review quarterly
FAQ
Should I use subfolders or subdomains
Use subfolders for most marketing content and docs unless a separate platform is required. Subfolders usually consolidate signals more cleanly.
How deep should my paths be
Two levels is a good default for marketing pages. Docs can be deeper for version and area. Avoid unnecessary nesting.
Can I change slugs later
Yes, but minimize changes. When you must, 301 redirect, update internal links, and keep the old slug out of nav and sitemaps.
What if a page fits two types
Pick the dominant intent and template. Link to the other context rather than mixing two templates into one URL.