Routing
This page describes routing in the Accelerator boilerplates. If your CMS owns routing (the CMS-led variant of Approach B), these conventions do not apply.
Each boilerplate splits routing between file-system routes for commerce pages and an optional CMS catch-all for content pages. The mechanics follow the framework (Next.js App Router, Nuxt pages and route rules, Vue Router), but the model is the same across all three.
Commerce routes
Commerce pages (product, category, cluster, search, cart, checkout, account) are file-system routes that ship with the boilerplate. They render with server-side data fetching where it helps SEO, and hydrate the interactive parts on the client. See Accelerator for the rendering model per stack.
Content routes and the CMS catch-all
When a CMS is wired in, a catch-all route resolves any URL that is not a commerce route by looking up a page in the CMS by slug. If the CMS has a matching page it renders, otherwise the route returns 404. Commerce routes always take priority: a CMS page cannot override /cart or /login. See CMS integration. CMS support currently ships in the Next.js boilerplate.
URL patterns
The boilerplates centralize URL patterns so you change a commerce URL in one place and every generated link follows. For example, a Dutch storefront can serve categories under /categorie/... instead of /category/.... The boilerplate's own README and config document the exact file for your stack.
Revalidation
All three boilerplates cache anonymous catalog and content pages and support on-demand revalidation. A POST /api/revalidate endpoint, gated by a shared secret (REVALIDATE_SECRET), lets a backend webhook invalidate a single tag (for example product:42), so one product refreshes without rebuilding the site.
See also
- Accelerator for the rendering and caching model per stack
- CMS integration for how content pages are resolved
- Categories and navigation for the category data model behind the URLs