URL Structure and Slugs: Rules, Examples and Risks

The address of a page is the first thing both readers and crawlers learn about it. A well-planned url structure keeps maintenance light as a site grows, while a careless one turns into redirect lists and reporting headaches years later. This article covers slug writing rules, folder depth and parameter decisions, and then the question many teams face: when is it worth changing an address that is already live?

Why URL Structure Matters

URL structure is often pitched as a ranking lever, yet its real value is order and predictability. A readable address lets a visitor guess where a link leads before clicking, understand what was shared in a chat, and trust the result in a listing. For a crawler, a consistent address scheme prevents the same content from being served through several doors.

Nothing here promises a ranking boost. Google's URL structure documentation (Opens in a new tab) treats addresses as a crawlability and readability matter, not a trick: use readable words, trim unnecessary parameters, avoid session IDs. It does not assign special weight to the slug, so polishing an address at the expense of producing content is the wrong priority.

The practical payoff shows up in three places:

• Maintenance: A regular scheme lowers the number of decisions each time a section is added.
• Measurement: With consistent folder names, one filter in your reports isolates an entire section.
• Sharing: A short, clear address survives email, social posts and messaging without breaking.

Traits of a Good URL

There is no single pattern for seo friendly urls, but good ones share a few traits. First, brevity: a few words that describe the topic are enough. Second, readability: words should be separate, meaningful and written in the language of the audience. Google's documentation likewise prefers readable words over long numeric identifiers.

You can test an address with five questions:

1. Could someone who has never seen the page guess its topic from the address?
2. Will the address stay valid even if the page title changes later?
3. Is the same page also reachable through another address?
4. Does the address stay in one piece when pasted into an email?
5. Does it follow the same pattern as similar pages on the site?

The last question is the one most often skipped. Individually tidy addresses, written in different patterns, give the site a scattered feel. So the answer to "what should a URL look like" is first found in your own site's rule, not in one perfect example. We turn that rule into a written standard in the section on setting and enforcing a URL standard.

Slug Rules: Hyphens, Lowercase and Brevity

The slug is the page-specific last part of an address, and in WordPress-style systems it is part of the permalink structure. Good slug practice comes down to three simple choices applied consistently.

Separate words with hyphens

Google recommends hyphens rather than underscores to separate words, and advises against running words together. "slug-writing-rules" reads well; "slugwritingrules" does not, and "slug_writing_rules" goes against the documentation's preference.

Pick one letter case

The same documentation notes that URL paths are treated as case sensitive and advises converting everything to one case if your server treats different cases the same. It does not say "lowercase" outright, but lowercase is the practical and widespread choice. That way "/Blog/Slug" and "/blog/slug" never circulate as two separate addresses.

Keep it short and free of filler

You do not need to carry the whole title into the slug. "how-to-build-url-structure" does the same job as "a-beginners-guide-to-building-url-structure-and-what-to-watch-for". No hard length limit is documented; the goal is an address that stays portable on screen and in messages.

Non-ASCII Characters and Slugs

Special characters in urls get two answers. Technically, addresses containing accented letters or other non-ASCII characters work: Google's documentation says non-ASCII characters in a link's href should be percent-encoded and lists unencoded forms as not recommended. An address that looks readable in the browser bar turns into sequences such as "%C3%BC" behind the scenes, which can become long and ugly when pasted into an email or an older tool.

That is why many sites transliterate slugs to plain ASCII: "über" becomes "uber", "café" becomes "cafe". It is a practical compatibility choice, not a rule, and it will not be right for every site. When you decide, look at the following:

• Which style already dominates your site? Mixing styles is the worst option.
• Do your tools (analytics, reports, email) display encoded addresses correctly?
• Does a system generate the slug or an editor type it? If automation is involved, the conversion table must be explicit.

There is a small trap in conversion: occasionally two different words collapse into the same ASCII slug. If you meet such a clash, add a word that preserves the meaning. For audiences who read a non-English language, the documentation's advice to write in the audience's language still applies alongside transliteration: the words stay in that language, only their spelling is adapted to the character set.

Folder Structure and URL Depth

Folders are the topic map of a site: "/seo-guide/url-structure-and-slug-rules" says the page belongs to the SEO guide section. No upper limit on depth is documented, but two principles help.

First, the number of folders should mirror the page's real hierarchy. A page two clicks from the home page should not be buried five folders deep. Second, folder names should be general enough not to change; folders named after a temporary campaign or a person are poor homes for lasting content.

For multilingual sites, the documentation offers two examples: a country-specific domain, or a country or language directory on a generic domain (such as "/de/"). Once a language prefix is chosen, apply it identically on every page.

A practical depth test: can someone looking at the address describe where the page sits on the site? For "/seo-guide/url-structure-and-slug-rules" the answer is yes; for "/content/2/general/page-17" it is no, and that misleads both users and your own team. Structural issues on category pages are covered in our pagination and category pages guide.

Parameters, Session IDs and Tracking Tags

Parameterised addresses (everything after the question mark) easily undo the tidiness a clean slug provides. Google's documentation advises trimming unnecessary parameters, avoiding irrelevant ones such as referral IDs, sorting and session IDs, and using cookies instead of session IDs in URLs. For format it recommends the standard "=" and "&" pattern, and a comma when one key has several values.

Separate three kinds of parameters:

• Parameters that change content: Filters and sorting that genuinely alter the list. This is its own topic, covered in filter URLs and faceted navigation.
• Parameters that do not change content: Session IDs and referrer codes. Letting them circulate creates duplicate URLs.
• Tracking tags: Campaign parameters such as UTM. They are needed for measurement but should not appear in the site's own internal links, because a tag added to an internal link puts several addresses for one page into circulation.

A healthy habit for tags: use them only in campaign links that live outside your site, and leave the plain address in your own menus, cards and in-content links.

Fragments (#) deserve a note too: the documentation advises against using "#" to change content, and recommends the History API on the JavaScript side. The role of the canonical tag for duplicate-producing parameters is covered in the canonical tag audit article.

Should Dates and Categories Be in the Slug

Google's documentation neither recommends nor forbids a date or category in the slug; the choice depends on the site's structure and the lifespan of the content. The useful criterion is the permanence of the address.

For dates, ask: will this content be updated? If an updatable guide carries "2022" in its address, it looks stale years later and is either misleading or must be changed, which means a redirect. For inherently dated content such as news or announcements, a date in the address is natural.

For categories, ask: could this page move to another category? If so, baking the category into the slug forces an address change at every move. Where the category is a permanent section (for example "/seo-guide/"), using it as a folder makes sense.

Example scenario: imagine a small software company that built its blog addresses as "/2023/05/12/slug". Two years on, it updates its old guides, but the dates in the addresses make fresh content look old. The company either simplifies the addresses with redirects or lives with the dated look. Building without dates from the start avoids that cost entirely.

The Decision to Change an Existing URL

Changing urls is a different matter from naming new content, because a live address already has links, records and habits attached. The default stance: unless the reason is strong, leave it. The reason must outweigh the redirect and update work.

You can sort the decision into three cases:

• Leave it: The address is a little long or imperfect but works, earns links and causes no trouble. Cosmetic improvement is not worth a move.
• Move it: The address is misleading, cannot be used for legal or brand reasons, creates duplicates, or conflicts with the site's new scheme.
• Move in bulk: You are changing the whole scheme. That is a site migration and is planned separately.

Count the costs before choosing: every move means a redirect record, internal link updates, external link owners who still point to the old address, and a broken measurement series. We offer no absolute verdict on redirect value transfer; Google's documentation says a permanent redirect is a strong signal that the target should become canonical, but it does not say rankings will stay the same. That is why you would not make a risky move without need.

For protecting external links, follow the steps in preserving backlink value during site migration.

301 Redirects and Update Lists After a URL Change

If you have decided to change an address, order matters. According to Google's redirect documentation (Opens in a new tab), 301 and 308 signal a permanent move, while temporary redirects such as 302 and 307 do not make the target canonical. So choosing a temporary redirect for a permanent slug change states the wrong intent. A server-side redirect has the highest chance of being interpreted correctly, and JavaScript redirects are a last resort. The site move documentation (Opens in a new tab) also asks for a one-to-one mapping from old addresses to new ones, no chains, and keeping redirects as long as possible, generally at least a year.

The update list runs like this:

1. Mapping table: Old address, new address and reason.
2. Server redirect: A single-step 301 from old to new. The risk of chains and loops is explained in the redirect chains and loops article.
3. Internal links: Menus, in-content links, breadcrumbs and image links are updated to the new address; relying on the redirect and leaving the old address in internal links is an unnecessary step.
4. Canonical and sitemap: The canonical tag and the sitemap should show the new address.
5. Verification: Does the old address return 301, does the new one return 200, and does the canonical on the target point to itself?

How to check the sitemap is in the sitemap audit guide. Do not rush to remove a redirect; the documentation's "at least a year" is a lower bound.

Setting and Enforcing a URL Standard

Instead of keeping the rules in everyone's head, a one-page written standard is among the most useful investments once a team grows. Keep it short and full of examples; nobody opens a long document at every publish.

A good standard covers these headings:

• Character rule: lowercase, hyphen separator, ASCII or special-character choice.
• Length rule: how many words, which small words to drop.
• Folder rule: permitted folders and maximum depth.
• Parameter rule: which parameters may appear in internal links.
• Change rule: who may touch a live address, and on what grounds.

Two mechanisms make it work. The first is a pre-publish check: a simple checklist that reminds editors of the rule when they type a slug, or automatic formatting in the content management system. The second is a periodic crawl: export the site's addresses and filter for uppercase letters, underscores, excessive length and parameters. If findings appear, apply the three-way split from the section on changing an existing URL to each; most of the time the answer will be to leave it.

Sample Template: Slug Decision and Rename Table

A working table that makes decisions about live addresses easier follows. The values are example values, not from a real site; fill it in with your own addresses.

In this example scenario, the team of a small service site fills in five rows and decides to move two addresses, monitor one and leave two alone. The total work is a handful of redirect records, and the "let's change everything" proposal from the first meeting becomes a reasoned choice. The table's value is that each decision is written down and can be traced back.

Frequently Asked Questions

What does an SEO friendly URL look like?

An SEO friendly URL is short, readable and made of words that describe the page. Words are separated by hyphens, one letter case is used and the address is built to stay permanent. Avoiding unneeded parameters and session IDs is also a core recommendation in Google's documentation.

Can URLs have uppercase letters?

They can, but it is not recommended, because URL paths can be treated as case sensitive. If the same page opens with both cases, two separate addresses can form. Choosing one case and redirecting the other is the safest approach, and in practice lowercase is usually the preferred choice.

What should I do after changing a slug?

Set up a server-side, single-step 301 redirect from the old address to the new one. Then update internal links, the canonical tag and the sitemap to the new address. Keep the redirect for at least a year and test that the old address redirects and the new one returns 200.

Should URLs include stop words?

Not necessarily; when the meaning stays clear, connecting and filler words can be dropped to shorten the address. The address should still read naturally, so keep a word if removing it changes the meaning. No word-count limit is documented, and the goal is a short, understandable address.

Should the category be in the URL?

It depends on the site. If the category is a permanent section, using it as a folder makes sense. If pages can move between categories, putting the category in the address means redirects later. Whichever you choose, apply it consistently across the site and record it in a written standard.

Do URL parameters hurt SEO?

Parameters can cause trouble when they spread one piece of content across several addresses. Avoid parameters that do not change content, such as session IDs and referral codes, use one consistent address in internal links, and state your preferred version with a canonical tag where needed. A parameter alone is not harmful.

Conclusion and Next Step

An address structure exists to make a page findable and manageable; it promises no ranking. A sound framework is to write down a short, lowercase, hyphenated slug rule for new content, settle parameter and date questions once, and touch live addresses only when the reason is strong. If you do, the single-step 301, the internal link update and the verification must all be completed.

For fresh articles with planned topic titles that fit your new slug rule, pick one of the content writing products, complete cart and payment, follow seller approval and the delivery notification, and use the objection route if something goes wrong. Decide on the few addresses in the table first; once the standard settles, ordered content slots straight into the scheme.