IA & Routing
Service-Hub Information Architecture With Child Pages
A nested hub structure where each service has consistent child routes (proof, case studies, systems, scope) generated from one config, so the URL tree stays predictable as services grow.
HMX Zone
TypeScript discriminated unions
Verified HMX-owned case
Outcome signals
These are the real outcome statements attached to this HMX case study.
- Predictable
- every service shares the same URL tree
- Type-safe
- invalid service or child kind fails to compile
- Crawl-clear
- breadcrumb schema exposes the hierarchy
- Scales
- new service inherits all child pages free
Case architecture
Service-Hub Information Architecture Architecture
6 nodes
Enumerate service slugs and
a parent hub scaffold and a
Next
TypeScript discriminated
Fallback Path
Predictable every service
- 01Enumerate service slugs and
A nested hub structure where each service has consistent child routes (proof, case studies, systems, scope) generated from one config, so the URL t...
- 02a parent hub scaffold and a
Build a parent hub scaffold and a child scaffold that both read from that config
- 03Next
Next.js App Router nested segments supports the route, form, or data boundary for Service-Hub Information Architecture so public UX and backend state stay connected.
- 04TypeScript discriminated
Generate per-child metadata and canonical URLs from the slug and child kind
- 05Fallback Path
When automation confidence is low, route the record to a manual owner with the source, stage, and last action attached.
- 06Predictable every service
Predictable every service shares the same URL tree; Type-safe invalid service or child kind fails to compile; Crawl-clear breadcrumb schema exposes...
Problem
The operating gap
Service content sprawls into inconsistent one-off pages. Some services have proof, some have pricing, none follow the same pattern, and the navigation cannot be reasoned about. Adding a new service means hand-building five mismatched pages.
Build
What gets built
Define services and a fixed set of child page kinds as typed data, then drive a parent hub scaffold and a child scaffold from that config. Every service automatically gets the same predictable child segments with correct breadcrumbs, metadata, and internal links — the IA is enforced by the type system, not by discipline.
Build steps
Service-Hub Information Architecture With Child Pages uses a web app route, data, and conversion layer for Full-Stack Websites. A nested hub structure where each service has consistent child routes (proof, case studies, systems, scope) generated from one config, so the URL t... The architecture connects enumerate service slugs and, next, typescript discriminated, and predictable every service with an explicit control path.
- 01Enumerate service slugs and the allowed child-page kinds as typed constants
- 02Build a parent hub scaffold and a child scaffold that both read from that config
- 03Generate per-child metadata and canonical URLs from the slug and child kind
- 04Emit breadcrumb structured data so the hierarchy is machine-readable
- 05Cross-link parent and children with consistent internal links and back-paths
- 06Add a mapping test so every service resolves all its declared child routes
Stack
Tools and layers
- Next.js App Router nested segments
- TypeScript discriminated unions
- Dynamic generateMetadata
- Breadcrumb JSON-LD
- Tailwind CSS v4
- Vercel
- Experience layer: Enumerate service slugs and the allowed child-page kinds as typed constants
- Server layer: Build a parent hub scaffold and a child scaffold that both read from that config
- Database layer: Next.js App Router nested segments supports the route, form, or data boundary for Service-Hub Information Architecture so public UX and backend state stay connected.
- Automation layer: TypeScript discriminated unions handles routine steps while define services and a fixed set of child page kinds as typed data, then drive a parent hub scaffold and a child scaffold from that config.
- Measurement layer: Predictable every service shares the same URL tree; Type-safe invalid service or child kind fails to compile; Crawl-clear breadcrumb schema exposes...
Data flow
- 01Enumerate service slugs and the allowed child-page kinds as typed constants
- 02Build a parent hub scaffold and a child scaffold that both read from that config
- 03Generate per-child metadata and canonical URLs from the slug and child kind
- 04Emit breadcrumb structured data so the hierarchy is machine-readable
- 05Cross-link parent and children with consistent internal links and back-paths
- 06Add a mapping test so every service resolves all its declared child routes
Controls
- Service content sprawls into inconsistent one-off pages.
- Define services and a fixed set of child page kinds as typed data, then drive a parent hub scaffold and a child scaffold from that config.
- When automation confidence is low, route the record to a manual owner with the source, stage, and last action attached.
Research basis
A route assembles through form, data, metadata, and deploy checks.
The same website operating path
Full-stack websites for service businesses and operators: route architecture, service pages, lead capture, metadata, proof boundaries, blog/database paths, analytics, and deployment checks.
Route map
Service architecture
Clear service routes
01active
Progress72%
Lead capture
Form and context flow
Lead capture that saves context
02active
Progress86%
Public metadata
SEO and schema layer
SEO and schema on public pages
03active
Progress64%
Launch QA
Analytics and deployment checks
Analytics events tied to CTAs
04active
Progress91%