Skip to main content
Every page in a Webstorio CLI project is a React module registered with a slug in webstorio.config.ts. The slug is the URL path on both webstorio dev and the published site.

Register a route

webstorio.config.ts
  • Slugs are path segments separated by /. Do not include a leading slash except for home ("/").
  • Exactly one page should use slug: "/".
  • Header and footer are components (_header, _footer), not pages — they wrap every route and are not visited as their own URLs.
Full field reference: Configuration → pages.

Nested routes

Use multiple segments for hierarchy:
That serves /docs/getting-started. Nesting is only in the slug string — you do not need a matching folder tree under pages/ (flat files are fine).

Dynamic routes (wildcards)

A path segment wrapped in {…} is a wildcard. One page module handles every URL that matches the pattern:
Rules:
  • Param names must be {name} where name starts with a letter or _, then letters, digits, _, or -.
  • Segment count must match exactly (no optional trailing segments).
  • Exact static routes win over wildcards when both could apply.
  • The same rules apply in webstorio dev and on the live site.

Read params in page code

pages/blog-detail.tsx
getPathParams() returns an object of param name → decoded path segment. It is available in local preview and on published pages. See Client SDK → Dynamic routes.

Feature page conventions

Dashboard create-page and webstorio generate use stable slug patterns so SDK helpers and deep links stay consistent: You can use custom slugs (for example blog/{content_entry_id}) — just keep list links and getPathParams() keys aligned with the names you chose.

Linking between pages

Use normal <a href="…"> (or your own router helpers). Paths are site-relative:
For store product detail, the platform often uses slug--id in the {product_slug} segment so the page can resolve by slug or id.