What Is a URL Slug? SEO-Friendly Slug Rules and 301 Guide

What is a URL slug and what does it do?

A URL slug is the last part of a web address that identifies a page in short, readable words. In "example.com/url-slug-explained/", the slug is "url-slug-explained". It tells users and search engines what the page covers at a glance.

Think of the slug as the page's ID card; in short, it stays with the page for good. Once you publish it, links, sitemap entries and social shares all depend on that address. So you should get it right the first time.

Our team starts most site audits with the URL structure. Also, a messy structure makes pages hard to manage, even when the content itself is strong. So readable addresses make reports much easier to scan.

In this guide, we cover writing rules, special characters and the real risks of changing a slug. We also show you how to set up a 301 redirect step by step.

Where does the URL slug sit in a web address?

An address has several parts: the protocol, the domain, the folder path and the slug. In "https://example.com/blog/url-slug-explained/", "https" is the protocol and "example.com" is the domain. "blog" is the folder, and "url-slug-explained" is the slug.

The slug usually sits at the very end of the path. Some teams also call folder names slugs, so "blog" can count as a category slug. The term stays flexible in everyday use.

Content management systems such as WordPress generate a slug from the title when you save a draft. However, the automatic version often comes out long and full of filler words. For that reason, we recommend you edit it before you publish.

• Protocol: https shows a secure connection.
• Domain: this is the main address of your site.
• Folder path: it groups the content inside your site.
• Slug: the readable, page-specific final part.

What does Google say about URL structure?

Google Search Central's URL structure guide asks you to keep addresses simple and readable. It says you should use readable words instead of long ID numbers. It also recommends hyphens to separate words.

Besides, the guide covers other points. It says non-ASCII characters should use percent-encoding, and it treats uppercase and lowercase as different URLs. It also tells you to avoid session IDs and to use words in your audience's language. You can read the full text in Google's URL structure guide.

One point matters here. Google does not claim that a keyword in the slug decides your ranking on its own. So treat the slug as a small signal and, above all, as a usability tool. Instead, avoid any promise of quick wins.

Still, a solid slug does two jobs. Users see the address in search results and understand the topic. Search engines also see a consistent structure, which makes crawling easier.

How do you write a good URL slug?

A good slug is short, descriptive and consistent. You take two to five words that describe the main topic, write them in lowercase and separate them with hyphens. You do not copy the full title.

For example, the title "A Step by Step Guide for Beginners on How to Set Up a Google Ads Campaign" works better as "google-ads-campaign-setup". Because you drop the filler words, the address gets shorter and clearer.

Our pre-publish checklist looks like this:

• The main keyword appears in the slug.
• Every letter is lowercase.
• Accented and special letters use plain ASCII forms.
• Hyphens separate the words.
• Dates, years and other fast-aging words stay out.
• Anyone reading the address can guess the topic.

If you apply this list to every new page, your structure stays tidy for years. Also, a tidy structure saves time in internal linking and reporting.

How long should a URL slug be?

Google gives no strict character limit for slugs. In practice, we keep slugs to three to five words and under roughly 60 characters. That is a starting range from field experience, not a guarantee.

A short slug has three advantages. First, it shows in full in search results. Second, it looks clean when you share it. Third, it breaks less often in email and messaging apps.

That said, cutting too far causes trouble too. A one-word slug like "seo" leaves the page's purpose unclear. It may then clash with another page that needs the same address later.

You strike the balance by keeping the core words and dropping the helpers. "url-slug-explained" is short and clear. "url-slug-explained-with-examples-tips-and-best-practices" is needlessly long.

Should you use hyphens or underscores in a slug?

Use hyphens. Google recommends hyphens to separate words and advises against underscores. A hyphen reads as a word separator, while an underscore can join words together.

For example, some systems may read "url_slug_explained" as one long word. In contrast, "url-slug-explained" clearly shows three separate words. Again, treat the official URL structure guide as your reference.

First, do not chain several hyphens in a row. A single hyphen between words is enough. Second, avoid a hyphen at the start or end of the slug.

Third, stay away from spaces, dots, commas and special symbols too. These characters either get encoded or cause broken links. A plain run of letters, numbers and hyphens is the safest choice.

How do you handle accents and special characters in a URL slug?

Convert accented letters to their plain ASCII forms: é becomes e, ü becomes u, ç becomes c, ñ becomes n. That way the address looks clean everywhere and does not fill up with encoded characters when you share it.

Technically, Google says non-ASCII characters should use percent-encoding. Your browser often shows the readable form in the address bar. However, when you copy the link, you may get codes like "%C3%A7". That looks messy in messages and reports.

However, conversion can change the meaning now and then. Some words become identical once you strip the accent. In that case, pick a synonym. For quick conversion, you can use our slug generator.

Should you remove stop words from the slug?

Most of the time, yes. Filler words such as "a", "the", "and", "of" and "for" lengthen the slug without adding meaning. Still, this is a readability choice, not a hard rule.

You should not cut blindly, though. In "seo-for-beginners", the word "for" keeps the meaning clear. If the address stays short, you can instead leave it in.

Then weigh question words as well. "how" or "what" can stay when it matches how people search. Our practice is simple: keep the topic words and one question pattern, then drop the rest.

• Drop: a, an, the, and, of, in, to and similar fillers.
• Keep: words that change the meaning, plus brand and product names.
• Watch out: do not remove negations or comparisons.

Should you put a date or year in the slug?

In most cases, no. A slug with a year looks outdated once you update the content. So you either live with a misleading address or change it and manage redirects.

For example, "seo-guide-2020" looks odd when you refresh the article in 2026. Because users may think the page is old, they may skip it. So a timeless slug pays off more.

News and event pages are the exception. For content tied to a specific date, the date belongs to the context. Even then, putting the date in the page content and structured data gives you more flexibility.

Likewise, avoid time-bound words such as "best", "new" and "latest". If the page will stay at the same address for years, the address should stay accurate for years.

How does folder structure shape the slug?

The folder structure forms the path before the slug and shows where the content sits on your site. A logical structure guides users. For instance, "/blog/seo/url-slug-explained/" tells readers the article belongs to the SEO category of the blog.

However, deep folder chains add needless complexity. You rarely need more than three levels. Also, if a category name changes, every child address changes too, and you need many redirects.

For that reason, some sites keep posts directly under "/blog/slug/". They signal the category through tags and internal links instead. So when you reorganize categories, the addresses stay stable.

Consistency matters in folder structure. Mixing singular and plural names confuses people. Also, decide on the trailing slash early; our trailing slash guide explains the topic in detail.

Why do uppercase letters, parameters and session IDs cause problems?

Because Google treats uppercase and lowercase addresses as separate URLs. "/Apple" and "/apple" can count as two different pages. That raises the risk of duplicate content and split signals.

So write every slug in lowercase. Then set your server to redirect uppercase addresses to the lowercase version. Otherwise, the same content answers at two addresses, and that splits signals.

Parameters create a similar problem. Add-ons like "?sort=price&color=blue" produce many variations of one page. Meanwhile, session IDs create a new address for every visitor. Google's guide suggests cookies instead of session IDs.

We covered how parameters affect search visibility in our URL parameters guide. When your slug structure is clean, parameter problems get easier to manage.

Can you change a URL slug after you publish?

Yes, but only with a real reason. If the page gets traffic, earns links or sits in the index, changing the slug carries ranking risk. If you do change it, you must set up a 301 redirect from the old address to the new one.

These situations justify a change:

• The address contains a typo or a misleading word.
• The topic changed completely and the address no longer fits.
• The address consists of meaningless ID numbers.
• You are in the middle of a site migration or restructure.

Outside of these, do not touch the slug just to make it "look better". A small wording gain rarely covers the cost of redirect management. In short, do not break an address that works.

When you write a new page, choosing the right slug from the start removes the need for later changes. So take the pre-publish check seriously.

Here is a practical test: read the address out loud. If it sounds natural and describes the topic, you probably chose well. If a stranger can guess the page topic from the address alone, that is an even better sign.

What are the risks of changing a URL slug?

First, there are three main risks: lost rankings and signals, broken links and measurement gaps. Without a redirect, the old address returns a 404 and the link value it earned goes to waste.

Even with a redirect, Google needs time to process the new address. Google's site move documentation says large changes can cause temporary ranking fluctuations. So avoid timing a change during your busiest campaign weeks.

In addition, links on other websites keep pointing at the old address. Only a redirect preserves their value. For that reason, keep your redirects permanent.

How do you set up a 301 redirect?

A 301 redirect sends visitors and bots from the old address to the new one permanently. You set it up on the server, so the server replies with a 301 code and names the new address in the header. Google recommends server-side permanent redirects when possible.

The method depends on your stack. On Apache, you add a rule to the .htaccess file. Meanwhile, on Nginx, you edit the server configuration. For WordPress, a redirect plugin also works. For details, see Google's redirect documentation.

1. Note the old and new address as full paths.
2. Confirm that the new page returns a 200 response.
3. Add a single-step 301 rule from the old address to the new one.
4. Update internal links so they point straight at the new address.
5. Switch the canonical tag and the sitemap entry to the new address.
6. Test the redirect and record the result.

For testing, our redirect checker does the job. Enter the address, and then you see the response code and every redirect step.

How long should you keep the redirect?

As long as you can, and generally at least one year. Google's site move documentation recommends keeping redirects for at least a year so the signals can transfer to the new URLs.

In practice, leaving the redirect in place indefinitely is usually healthier. The cost is very low, so sites that linked to the old address may keep doing so for years.

Watch out for redirect chains. If an address changed twice, send the oldest one straight to the newest. Chains slow pages down; also, they waste crawl budget. Our redirect chain guide walks through examples.

Do not redirect to unrelated targets either. Sending a deleted page to the homepage may look like a soft 404 to Google. Choose the closest matching page instead.

What should you check after a slug change?

First, confirm that the redirect works. Then check internal links, the sitemap and canonical tags. Finally, watch the new address in Search Console.

For example, our team follows this order:

1. Does the old address reach the new one through a 301?
2. Does the new address return 200 and stay open to indexing?
3. Do any internal links still show the old address?
4. Does the sitemap list only the new address?
5. Do the canonical and hreflang tags point at the new address?
6. Do analytics and ad goals use the new address?

To refresh your sitemap, try the XML sitemap generator. Also, keep watching impressions and clicks over the following weeks.

For example, if clicks do not recover on the new address, look for a redirect chain or a canonical mismatch. The problem often sits there.

How do you plan a bulk slug change?

For a bulk change, you first build a mapping table. The table lists the old address, the new address and the redirect type. Then you validate it in a test environment, because mistakes cost more after launch.

Redesigns and migrations make this work unavoidable. You must match every page to its new address one by one. We cover the whole process in our website migration SEO checklist.

When you have many addresses, tools can speed up the mapping. Our redirect mapping tool helps you match old and new addresses by similarity. Even so, you still need to review the result by hand, because tools can match the wrong pages.

If you plan a redesign, also read how to protect SEO during a website redesign. It includes practical points about keeping your address structure.

Is the slug the same as the page title?

No, it does not have to match exactly. The title (H1) speaks to the reader and can run longer and more descriptive. The slug is a short, simplified summary of it. Both should describe the same topic, but they should not share the same word count.

For example, your title might read "What Is a URL Slug? SEO-Friendly Writing Rules". Your slug can stay "url-slug-explained". Question marks, colons and long explanations suit a title. You use none of them in the address.

If you change the title later, you do not need to touch the slug. In fact, leaving it alone is safer, because a title update carries far less risk than an address change. For title writing, see our meta title and description guide.

Do product, category and blog slugs differ?

Yes, because each content type calls for different priorities. On a blog post, a short phrase that names the topic is enough. Then, on a category page, you use a general word for the product group. Finally, on a product page, the brand, model or key feature comes first.

Ecommerce adds a variation problem. If you create separate slugs for each color and size, similar pages multiply. In that case, one main product address with a canonical tag is often healthier. You decide the structure based on catalog size.

Also, do not delete the address of an out-of-stock product. If you remove the product for good, set up a 301 redirect to the closest alternative or to the category. For more detail, read our ecommerce SEO guide for product and category pages.

How do you write slugs on a multilingual site?

You write a separate slug for each language, using that language's own words. Google's guide also tells you to use words in your audience's language and gives a German example, "lebensmittel/pfefferminz". So an English page gets English words and a Spanish page gets Spanish words.

You then link the language versions with hreflang tags. Even when every version has a different slug, the tags keep the pairing correct. Therefore, a missing slug translation can cause problems such as hreflang errors.

Do not translate word for word. Pick the phrase people actually search for in the target language. Before you build the structure, read our multilingual website SEO guide.

Which slug patterns can you reuse?

You can reuse a few patterns by page type. Also, patterns keep the whole team consistent. They also stop each new editor from deciding everything from scratch.

• Definition post: /topic-explained/ or /what-is-topic/, such as /url-slug-explained/.
• How-to post: /how-to-do-topic/.
• Comparison: /a-vs-b/ puts two concepts at one address.
• Service page: a short, noun-led address like /services/seo-consulting/.
• Product page: /category/brand-model/.
• Tool page: an address that names the function, like /tools/slug-generator/.

All of these patterns follow the lowercase, hyphen and ASCII rules. If you write the pattern into a team document, new people follow the same order. On our own site, for example, tools, services and the blog sit in separate folders.

However, sometimes you must step outside the pattern. If two posts collide on one pattern, add a distinguishing word. That word must truly separate them, so avoid a random number.

How do you monitor a slug change in Search Console?

In Search Console, you inspect the new address with the URL Inspection tool and resubmit the sitemap. Then you compare clicks and impressions for the old and new address in the performance report. The old address should lose share while the new one gains it.

This handover often takes several weeks. So do not panic over small swings in the first few days. On the other hand, if the drop continues after two weeks, recheck your redirect and canonical settings.

On the analytics side, update any goals that use the old address. Also fix destination URLs in ad campaigns. Even when the redirect works, pointing ads straight at the new address gives better speed and cleaner measurement.

The same habit helps when you prune content. When you merge or delete pages, plan the redirects together with any slug change, and monitor both in one report.

What are the most common URL slug mistakes?

The most common mistakes are overly long addresses, accented characters, underscores, uppercase letters, years and ID-based addresses. A pre-publish check prevents most of them.

Another mistake, for example, is never editing the slug at all. The address that the CMS generates carries every word of the title. So that makes a long, fragile address.

Also, very similar slugs compete for the same terms. We call this cannibalization. If the pages serve different intents, the slugs should show that split.

How does a slug generator speed up the process?

A slug generator converts accents, lowercases letters and turns spaces into hyphens as you type the title. So you get an error-free draft address. Then you shorten and simplify it by hand.

You can use our slug generator for this. You paste the title and the tool builds a clean address. However, the output is only a starting point, and you still strip the filler words yourself.

On sites with many pages, the tool can become part of the workflow. When the whole publishing team follows the same rule, the address structure stays consistent. In short, consistency is the most valuable gain on large sites.

Beyond slugs, do not forget titles and descriptions. Our meta title guide covers that part.

How does our team audit URL slugs?

Our team first crawls the site and lists every address. Then we separate long, repeated, encoded or parameter-heavy addresses. Then we keep the ones that need changes and the ones to leave alone in separate tables.

For every page, we look at traffic, links and index status. We do not recommend a slug change on a page with traffic unless a real problem exists. So this measured approach keeps you away from needless risk.

The audit ends in an action plan. It shows which address changes and why, where the redirect goes and in what order to apply it. You see the technical side and the content side in one table.

If you want to review your address structure together, look at our SEO consulting service. We also suggest a quick check with the free SEO checker first.

To rebuild the technical basics, our technical SEO tips make a good starting point.