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.mdPrompt 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?"