URL Design: How to Build URLs That Last

A website’s addresses are the most permanent thing about it. Designs change every few years, content is rewritten, platforms are replaced, but the addresses are printed, bookmarked, linked from other sites and stored in search indexes. Change them and every one of those references breaks. Design them well and they outlive everything else.

This article explains how to design URLs that last. It is part of our guide to site architecture.

What a URL is for

A URL does several jobs at once. It locates the page for browsers and crawlers. It tells people what to expect before they click, in search results, in a shared link or in a printed reference. And it is an identifier: other sites, search engines and AI assistants record it as the name of that piece of content.

The last job is the one most often forgotten. An address is not just a route to a file; it is the page’s identity on the web. That is why changing it is so costly.

Cool URIs don’t change

In 1998 Tim Berners-Lee, who invented the web, published a short W3C note called “Cool URIs don’t change”. Its argument still holds. URIs, he wrote, don’t change: people change them. Most reasons for changing an address are organizational, not technical, and every broken link damages the trust people place in the site that owns it.

His practical advice was to design addresses for the long term by leaving out information that is likely to change. The note lists the usual suspects:

The principle behind the list is the separation of the address from the implementation. The server should map a stable address to whatever happens to produce the page, so the technology underneath can change while the address stays the same.

What makes a good URL

Google’s documentation on URL structure gives the practical rules that follow from this:

• Descriptive words, not IDs. /url-design/ says what the page is about; /?p=1842 says nothing.
• The words your readers use, in their language.
• Hyphens between words, not underscores, which programs often treat as joining words together.
• One consistent case. Google treats /Guide and /guide as different addresses, so pick lower case and keep it.
• Few or no parameters. Remove parameters that do not change the content, such as tracking codes, so the same page does not live at many addresses.
• No fragments for content. Google generally does not support using the part after # to show different content.

To which experience adds:

• Short enough to read aloud. If you cannot say it, it is too long.
• No stop words that add nothing, but not so trimmed that the address stops making sense.
• No dates unless the date is the point, as with news or a dated report.

Flat or nested addresses

The biggest structural choice is whether addresses show the site’s hierarchy, as in /site-architecture/url-design/, or stand alone, as in /url-design/.

Nested addresses show where a page sits, which some readers find helpful. But they bake the category into the address, which is exactly what the W3C note warns against: reorganize the categories and every nested address changes. Flat addresses never need to change when a site is restructured, because a page’s place is expressed by its links, its breadcrumbs and its navigation rather than its address.

On sites expected to grow and evolve, we prefer flat addresses for that reason, and that is how this site is built. What matters most is that the choice is made once, deliberately, and applied everywhere.

Design the pattern, not each address

The most reliable way to get consistent URLs is to design the pattern before the pages. A URI template describes a whole family of addresses with variables in braces. The format is standardized in RFC 6570, published by the IETF in March 2012, whose own example is a template like http://example.com/~{username}/ describing every user’s personal space at once.

You do not need the formal syntax to use the idea. Writing down the templates for a site makes its address rules explicit:

With the templates written down, every new page gets an address by rule rather than by mood, and any address that breaks the pattern stands out.

Slugs

In WordPress, the slug is the part of the address that names a single page or post. WordPress creates it from the title, which is a reasonable start but rarely the best result. A good slug:

• keeps the words that carry the meaning and drops the rest
• matches the page’s main subject, not a clever headline
• stays the same when the headline is rewritten later

Decide the slug when the page is created and treat it as permanent. Rewriting a title is free; rewriting a slug means a redirect.

When a URL has to change

Sometimes it must: a merge of two pages, a mistake in a slug, a move from another platform. When it does:

1. Redirect permanently from the old address to the new one, with a 301 redirect.
2. Redirect to the closest match, not to the home page. A redirect to an unrelated page helps nobody, and search engines may treat it much like a missing page.
3. Update internal links so your own site points to the new address directly.
4. Keep the redirects for as long as anyone might use the old address, which in practice means indefinitely.
5. Avoid chains: if an address changes twice, point the oldest address straight at the newest.

Redirects preserve most of what the old address had earned, but each one is a small risk and a small delay. The best redirect is the one a well-designed URL never needs.

A checklist for a URL scheme

• Write down the templates for every type of page before building.
• Use descriptive words, lower case and hyphens.
• Leave out categories, dates, authors, status words and file extensions unless they are the point of the page.
• Keep parameters for things that really are filters or searches.
• Decide each slug at creation and treat it as permanent.
• Redirect any change permanently, to the closest page, and update internal links.