What Is a URL Slug?

A good slug follows a few rules, but it follows all of them at once. It should be short: the fewer words needed to describe the page, the better it reads in a browser and in a search result. It should be descriptive: someone who sees only the URL, before opening the page, should be able to guess what they'll find. And it should include the page's target keyword, the two or three words that sum up what the page covers, without piling on synonyms or variants around it.

This page demonstrates that with its own URL structure. In Spanish: https://zds.es/que-es-url-slug. In German: https://zds.es/de/was-ist-url-slug/. In English: https://zds.es/en/what-is-url-slug/. In all three cases, the final segment is short, entirely lowercase, free of accents or special characters, and its words are separated by hyphens rather than underscores. Google treats the hyphen (-) as a word separator and reads "url" and "slug" as two distinct terms; it treats the underscore (_) as a joining character, so "url_slug" would be read as a single word, diluting the relevance of each term on its own.

The /de/ or /en/ prefix that comes before the slug in the German and English versions isn't part of the slug itself, it's the path segment marking the page's language. The slug is only the final piece, the part that changes from one article to the next within the same language.

The third case deserves its own note, because it isn't always an obvious mistake. Capital letters and underscores don't break the page, but they do create a real problem: most servers treat /Cordless-Drill-Guide and /cordless-drill-guide as two different URLs, not the same one with different formatting. Depending on how the URL was built, that can quietly produce a duplicate that neither version was meant to have.

A short, clear slug also earns its keep somewhere no analysis tool ever checks: in a search result list, the URL sits visible right under the title, and anyone skimming it decides in a split second whether the click is worth it. A slug like /cordless-drill-review reads as trustworthy because it announces exactly what's waiting on the other end. A long string of IDs or parameters, by contrast, looks like a technical roll of the dice, even when the page behind it is genuinely good.

On trimming filler words, it's worth looking at this glossary's own pattern: every English slug on this site starts with "what-is-", as in "what-is-url-slug". That isn't an exception to avoiding filler, it's a deliberate, consistent convention across the whole site, one that signals the question-and-answer format of each article right in the URL. Avoiding filler means not adding terms that add nothing to a specific URL, not breaking a pattern the site itself keeps on purpose across every article.

Changing the slug of an already-published page isn't a simple text edit: it changes the entire URL, and a new URL is, to both the server and Google, a different resource from the one before it. If an article moves from /drill-guide-2024 to /best-cordless-drill, the first address stops existing in that form. Anyone who tries to visit it, whether a person with a saved link or Google's crawler, hits an error if nothing else is done.

That's where the Redirect 301 comes in: the tool that signals the URL has permanently moved to the new address, carrying with it both visitors and the ranking signal built up through links and crawl history. Without that redirect, the slug change isn't neutral: the page loses the trail of whatever it had built under the old URL and largely starts over under the new one.

This matters even more for external links. Internal links can be updated by hand, one by one, in a few minutes. Backlinks that other sites have pointed at the old URL aren't under your control: nobody is going to open a three-year-old blog post and fix a link just because you changed a slug. That backlink keeps pointing at the original address indefinitely, and only a Redirect 301 on that exact address makes sure the value of that link actually reaches the new page.

The mechanics of the redirect itself, how to set it up, the difference from a temporary 302, how to check the server is really returning a 301, are covered in detail in the dedicated article on Redirect 301. Here, the conclusion that matters directly for a slug is this: changing it without setting up the matching redirect isn't a minor detail, it's giving up whatever ranking that URL had already earned.

It's common to mistake the Canonical Tag for the fix to a slug change, and it isn't one. Canonical exists for a different situation: when the same content, or something very close to it, is available at multiple URLs that both need to keep working, for example a product page reachable with and without a color parameter. There, canonical tells Google which of the two versions it prefers, but leaves both accessible.

A slug change is the opposite case: the old URL doesn't need to stay accessible, it needs to genuinely disappear and make way for the new one. Putting a canonical on the old URL that points to the new one, instead of a redirect, keeps that old URL alive and depends on Google choosing to honor the signal, which Google treats as a strong hint, not an order. A Redirect 301 leaves no such gap: the old URL stops responding on its own, and traffic lands directly on the new one.

The practical rule separates the two cases without ambiguity. If both URLs need to keep existing, use canonical. If the old URL needs to stop existing because the slug genuinely changed, use a Redirect 301.

One more detail helps keep the two tools straight: every page should carry a self-referencing canonical, pointing to its own URL, this one included. That confirms its reference address as long as nothing changes. The day the slug genuinely changes, that self-referencing canonical starts pointing to the new URL because the page now lives there, and it's the Redirect 301, not the canonical, that makes sure the old URL stops responding on its own.

Using both tools at once usually adds confusion rather than safety: a canonical from the old URL to the new one, combined with a 301 redirect on that same address, is redundant, because once the redirect kicks in, Google never even gets to evaluate the old URL as its own entity. For a genuine slug change, the Redirect 301 on its own is all it takes.

• Settle on the final slug before publishing, not after: changing it once it's live always costs more than getting it right the first time.
• Include the page's main keyword, but only that one; don't stack synonyms or variants into the same slug.
• Use lowercase only, hyphens to separate words, and no special characters, accents, or other symbols.
• Drop articles, prepositions, and filler words that add no meaning, unless they're part of a convention already established across the rest of the site.
• Keep it short: if the slug doesn't fit whole, without being cut off, in a line of search results, it probably has words to spare.
• If you do have to change it, set up the Redirect 301 from the old URL to the new one the moment you publish the change, not days later.
• Check internal links pointing at the old URL and update them to the new address, instead of leaving them to pass through the redirect.

• Changing a slug to "improve" it without setting up the matching Redirect 301, leaving the old URL with no owner.
• Using underscores instead of hyphens to separate words, which makes Google read the slug as a single word.
• Stuffing a date, an internal ID, or session parameters into the slug, producing a URL that ages badly or changes on every visit.
• Cramming too many keywords into one slug on the assumption it will rank for all of them at once, when it mostly just makes it harder to read.
• Mistaking a slug change for a duplicate-content situation and using a canonical where a Redirect 301 was actually needed.
• Leaving capital letters or accented characters in the URL, generating two reachable variants of the same address for no real reason.