Routing and URL design

URL structure is part of the product. It affects navigation, search behavior, analytics, redirects, and how easy a site is to maintain.

URLs should describe the site

We prefer clear routes such as /services/web-development, /portfolio/project-name, /blog/article-name, and /docs/topic-name. A visitor should have a reasonable idea what a page contains from the URL.

Dynamic routes reduce duplicated code

When a page type repeats, we use one route template and load the relevant content by slug. That keeps the layout consistent and makes metadata, schema, and error handling easier to manage.

We avoid artificial URL sprawl

A business does not need hundreds of thin pages simply because a CMS makes them easy to create. We only create route families when the content can support them.

Redirects are treated as infrastructure

If a URL changes after launch, the old route should be mapped deliberately. Redirects are not housekeeping. They preserve user paths, inbound links, and search signals.

Stable URLs are valuable

When a route already has traffic, links, or history, we prefer to keep it unless there is a good reason to change it. Clean architecture includes knowing when not to move things.

Our route families come from the content model

When a site has a repeatable content type, the route usually reflects that type directly. Services can live under /services/[slug], locations under /locations/[slug], articles under /blog/[slug], and docs under /docs/[slug]. The valid slugs are generated from the same registries or content directories that supply the page data. That keeps routing tied to real content instead of maintaining a separate list of URLs by hand.

Invalid routes should fail cleanly

Dynamic routing does not mean every possible slug deserves a page. The route looks up the requested item, and if the content model does not know it, the application returns a not-found state. This is important for both usability and search. We do not want empty templates rendering a 200 response for arbitrary URLs.

URL stability has business value

Once a route is public, it can accumulate backlinks, search history, analytics, customer bookmarks, and references in documents we do not control. Changing it creates migration work, so we choose slugs with durability in mind. That is why we avoid URLs built around temporary campaigns, internal jargon, or unnecessarily long keyword strings unless the page itself is temporary.

Route depth should reflect real hierarchy

A deeper URL is useful when it communicates a meaningful parent-child relationship. It is not useful merely because a CMS happens to organize files that way. We prefer public URLs that a person can read and predict. The internal repository can have whatever folders make development clear without forcing every internal detail into the public address.

Dynamic routes do not justify page proliferation

The ability to generate a hundred city or service pages cheaply is an implementation capability, not a content strategy. Each route still needs enough distinct value to deserve indexing. That is why location pages are content models, not city-name swaps, and why route families are designed to share implementation without flattening the content.

Good routing gives the site a stable address system. It should make the information architecture easier to understand, not create more URLs than the business can support.