URLs are the addresses of the web. They appear in browser bars, in shared links, in SERPs, in citations from AI engines, and in every internal link on your site. A clean URL structure is a small but real ranking signal, a meaningful UX signal, and a foundational architectural decision that becomes harder to change the longer you wait. Get it right at launch and the cost of growth is low. Get it wrong and you spend years untangling it.

“The URL is the only piece of metadata about your page that lives in the address bar, the SERP, the share preview, and the citation. Treating it as cosmetic is one of the most expensive mistakes a site makes early on.”

What makes a good URL slug

A good slug is short, descriptive, lowercase, kebab-case, and matches the page's primary keyword. Five attributes:

• Short. 3–5 words is ideal. Past 6 words the slug starts truncating in some surfaces and adds noise without adding signal.
• Descriptive. The slug should let a human reading just the URL guess what is on the page.
• Lowercase. Case-sensitive servers treat /Title-Tags and /title-tags as different URLs. Lowercase everywhere prevents accidental duplicates.
• Kebab-case. Words separated by hyphens (title-tags), not underscores (title_tags) and not concatenated (titletags). Hyphens are the only separator search engines reliably treat as word boundaries.
• Keyword-matched. The slug should contain the primary keyword verbatim, per the H1 = URL = Title rule.

Kebab-case vs underscore vs camelCase

Hierarchical paths vs flat URLs

Two competing patterns: hierarchical (/seo/on-page/title-tags) and flat (/title-tags). Both can work; the right choice depends on the size and structure of the content.

Use hierarchy when:

• You have multiple topical clusters (SEO, CRO, paid) and want the URL to reflect cluster membership.
• You have so many articles that flat URLs become hard to manage.
• The hierarchy reinforces the internal linking structure (pillar at the parent path, clusters under it).
• Users benefit from being able to lop off the slug and land on a parent index (/seo/on-page/ as a real page).

Use flat URLs when:

• The site is small and the cluster is implicit, not visible.
• You expect to refactor topics frequently and don't want the URL to commit to a hierarchy.
• The flat slug is significantly shorter and the cluster name adds no UX value.

The mistake is flat URLs that mimic hierarchy through prefixes (/seo-title-tags) or hierarchy that is so deep nobody would ever construct it manually (/blog/category/sub-category/2026/04/title-tags). The first wastes the slug; the second is unmanageable.

Length: shorter is almost always better

Shorter URLs rank slightly better, get clicked through more often in SERPs, and are far easier to share. Studies of top-10 SERP results have shown a small but consistent correlation: shorter URLs occupy higher positions on average. Causation is debated; the practical advice is unambiguous — aim for under 60 characters total URL length when possible, and certainly under 100.

The H1 = URL = Title rule applied to slugs

For any page targeting a single primary keyword, three structural elements should match: the H1, the URL slug, and the title tag. The slug carries the keyword in kebab-case; the H1 and title tag carry it in natural prose. Same words in the same order, different formatting:

• URL slug: /title-tags
• H1: Title tags
• Title tag: Title tags

The slug should not include filler words (a, the, of, for) unless they are part of the canonical phrasing of the keyword. “/the-best-title-tags-of-2026” is bloated. “/title-tags” is correct.

Multi-locale URL structure

Multi-locale sites need a URL pattern that signals locale to crawlers and to users. Three valid patterns:

For most multi-locale sites, subdirectories are the right answer. The locale path (/es-mx/) prefixes the slug, the slug itself is in the locale's language for Romance/Germanic languages, and hreflang ties the locales together (per canonical tags).

Localised slug vs English slug

For Spanish, French, German, etc., the slug should be in the locale's language: /es-mx/seo/estructura-de-url, not /es-mx/seo/url-structure. The exception is industry-standard English terms that the localised audience actually searches in English (title tag, meta description, anchor text, snippet, SEO). For those, keeping the English slug in es-MX is correct because it matches the keyword the audience types.

EN and en-AU (or any two English variants) share the same slug because the keywords are identical.

Trailing slash vs no trailing slash

Pick one and stick to it across the entire site. Both /title-tags/ and /title-tags work; mixing them creates duplicates that need canonical tags or 301s to consolidate. Most modern frameworks handle the redirect automatically, but the choice has to be explicit at launch and consistent in every internal link.

The redirect rule when changing URLs

Don't change URLs casually. When you have to:

1. 301 redirect from the old URL to the new URL. Preserves nearly all the authority. Permanent (301), not temporary (302).
2. Update every internal link to the new URL. Don't rely on the redirect — each redirect drops a small fraction of authority and slows the page.
3. Update the sitemap. Remove the old URL, add the new one.
4. Update the canonical tag on the new URL to match itself.
5. Monitor Search Console for “Page with redirect” reports and crawl errors over the next 30 days.
6. Don't redirect-chain. If URL A previously redirected to B and now B is moving to C, update the A redirect to point directly at C. Chains lose more authority and slow down crawl.

Query parameters and crawl waste

Query parameters (?utm_source=..., ?sort=price, ?ref=...) create URL variants that crawlers may treat as separate pages. Three rules:

• Self-canonical the parameter-free version. Each parameterised URL canonical-points to the clean URL.
• Avoid building site navigation on parameters. Filters, sorts, and pagination should use clean paths when possible.
• Block known noisy parameters from indexing via robots.txt or meta robots when they create infinite combinations.

How AI engines parse URL slugs

AI answer engines read the URL slug as one of the strongest topic signals at retrieval time. Three observations:

• The slug is read before the body. When the engine decides which pages to retrieve for a query, the slug + title + meta is what it scans first. A clean slug accelerates retrieval; a meaningless slug (/p/12345) delays it.
• The slug is part of the citation. When ChatGPT or Perplexity cites your page, the URL is visible to the user. /seo/title-tags looks credible. /blog/post?id=4519 looks transactional.
• The slug reinforces topical clustering. Pages under /seo/on-page/ are clustered by the engine more reliably than scattered flat URLs on the same topic.

Common URL structure mistakes

• Including the date in the URL. /2024/04/title-tags ages your content visibly and forces a redirect every time you update.
• Including the category in the URL when categories change. Once a piece of content moves between categories, the URL is wrong and you face a redirect or a lie.
• Auto-generated slugs from titles. Many CMSs default to using the H1 verbatim, which produces slugs like /the-2026-guide-to-writing-better-title-tags. Edit the slug at publish time.
• Numeric IDs. /p/12345 is invisible to humans and AI engines. Use descriptive slugs even for product pages.
• Random capitalisation. /Title-Tags works only on case-insensitive servers and breaks on case-sensitive ones. Lowercase everywhere.
• Spaces, accents, special characters. Encoded as %20, %C3%A9, etc., these break in shares and look broken in citations.
• Stop words that add no value. Drop “the”, “a”, “of”, “for” unless they are essential to the keyword.

The bottom line

URL structure is a launch decision that becomes a maintenance liability if you get it wrong. Use kebab-case, lowercase, short, keyword-matched slugs. Pick hierarchical or flat consistently. Lock trailing-slash behaviour at launch. Localise slugs into the audience's actual search language. 301-redirect with discipline when URLs do change. Block noisy query parameters from creating duplicate index entries. Get this right and the slug becomes a quiet ranking signal that compounds over years; get it wrong and you spend the same years explaining why the migration is taking so long.