Product Execution & Delivery

Routing & URL Structure Design

Description

Design a product website's routing and URL structure using clear information architecture and semantic rules. Balance user comprehension, SEO indexability, and long-term maintenance cost; avoid route explosion and reflect product boundaries.

Cursor / Claude Code Instruction

There is a prompt instruction at https://www.zangwei.dev/prompts/product-execution/routing-url-architecture-seo-prompt . Extract and follow the prompt to create file /docs/handbook/product/{version|feature}/url.md

Prompt Content

You are a senior Product Manager / SEO Strategist. Design the site's **Routing & URL Architecture**.

## Positioning
Routing is not just frontend implementation detail. It is:
- the externalized information architecture
- SEO infrastructure
- an expression of product boundaries

A good routing system should be understandable to users, indexable by search engines, and maintainable long-term.

## General requirements
- Serve core business and growth goals
- Avoid pre-reserving paths for hypothetical features
- Clarify which routes are durable assets vs temporary
- Avoid route sprawl and semantic confusion

---

## Output structure

1) Routing goals
- What goals does routing primarily serve? (brand / conversion / content / product usage / SEO)
- Which paths are core assets?
- Which paths can be retired or merged?

2) Overall hierarchy
- Top-level route categories (e.g., product / use-cases / content / pricing)
- Semantic rules for second-level routes
- Any dynamic routes? If so, boundaries

3) Core route types (must cover)
- Home and primary entry points
- Product/feature pages
- Use-case/scenario pages
- Landing pages (marketing/SEO)
- Content pages (blog/docs)
- System pages (login/settings, etc.)

For each type, specify:
- target users
- indexability (yes/no)
- expected lifecycle

4) SEO & semantic constraints
- Does the URL convey clear semantics?
- Risk of keyword stuffing or semantic duplication?
- Canonical/pagination/language strategy (if applicable)

5) Boundaries & anti-patterns
- Route forms that should not exist
- Forbidden ways routes should not expand
- Which needs should be solved via content/components rather than new routes

---

## Output requirements
- No framework implementation
- No UI design
- Every route must be explainable in one sentence (why it exists)

End with:
"Will this routing system remain controllable over the next 2–3 years?"