URL structure: the decisions you make once

Three jobs, in order of importance: it identifies the page to search engines, it promises something to a person reading it in a result, and it tells a crawler where the page sits.

• Identity: every distinct URL is a distinct page. Two URLs for one page is a duplicate to be resolved.
• Promise: the reader sees the URL under the title in a result, and in a link somebody pasted in a chat.
• Structure: folders group pages, and the grouping is a weak but real signal of what belongs together.

What a URL is not is a place to put keywords. The words help a reader decide to click, which is worth having, and that is the whole of it.

Use a folder when the section is a real group with a hub page above it. Do not use one to decorate.

• Lowercase, always. Upper and lower case are different URLs on most servers.
• Hyphens between words, not underscores and not run together.
• Words a person would say: the subject of the page, two to five of them.
• No stop words unless the phrase needs them to read: /how-to-fix-duplicate-content is fine, /the-guide-to-a-url is not.
• No repetition of the folder: /guides/guide-to-canonical-tags says guide twice.
• Stable. The slug is the page's name, so pick the name you will still use next year.

Trim the slug to the subject, not to the title. A page titled "How to fix Crawled, currently not indexed in Search Console" lives happily at /guides/crawled-currently-not-indexed.

Each of these serves the same content at two addresses. Pick one form, redirect the other, and keep internal links on the chosen form.

Two of these have their own guides, because the choice has consequences beyond the URL: the www question and the trailing slash question.

• Dates: only where the content is genuinely dated, such as a changelog entry or a conference edition. A guide with 2026 in its URL is a guide you cannot refresh without a redirect.
• Ids: only where a human-readable slug cannot be unique, such as a marketplace listing. Prefer /listings/1234-blue-desk-chair to /listings/1234 so the URL still says something.
• Author, category and tag in the path: avoid. They change, and they turn one page into several when the taxonomy changes.
• Version numbers: fine in documentation, with the current version canonical and the old ones handled deliberately.

Changing a slug is a small migration. It is doable, it is sometimes right, and it is never free.

1. A 301 from the old URL to the new one, kept permanently.
2. Every internal link updated to the new URL, so nothing is reached through a redirect.
3. The sitemap updated, so Google is told the new URL directly.
4. Any external link you control updated: profiles, listings, documentation.
5. A period of fluctuation while Google recrawls and moves its signals across.

Worth it for a URL that is wrong, confusing or blocking a section you are building. Not worth it to add a keyword.

1. 1

   Decide the folder and build its hub

   If /section/ has nothing to say, the section does not need a folder.

2. 2

   Write three example slugs

   Say them aloud. If they are hard to read or repeat the folder, fix the pattern before there are forty of them.

3. 3

   Check the variants

   Request the new URL with and without a trailing slash, in mixed case, over http, with and without www. Each should reach one final URL in one hop.

4. 4

   Add it to the sitemap and the navigation

   A section that only the sitemap knows about is a section nothing links to.

5. 5

   Write down the pattern

   One line in the repository saying how URLs in this section are formed. That is what stops the next person inventing a second pattern.