How Long Should a URL Slug Be?

The short answer

Keep the slug — the part of the URL after the domain — short, lowercase, hyphenated, and carrying the words someone would use to describe the page. Three to five words is the working range for most pages. Anything longer is usually a sentence that escaped into the address bar, and anything shorter usually says nothing at all.

There is no official limit, and no ranking bonus for hitting a particular character count. The reasons to keep slugs short are practical: people can read them, remember them, paste them without breaking them, and tell what the page is about from the URL alone. A slug is a label, and labels work best when they are short.

What a slug is, precisely

For a URL like https://example.com/guides/how-long-should-a-url-slug-be, the slug is how-long-should-a-url-slug-be — everything after the last slash that identifies this one page. It is distinct from the domain, which identifies the site, and from any folders before it, which identify the section.

Search engines display the slug in results, browsers show it in the address bar, and people copy it into emails, documents, and chat messages. It is one of the few parts of a page that is seen by readers, crawlers, and linkers alike, which is why a small amount of care here pays off in three places at once.

The working rule

Three to five words, and never more than you need. A guide about meta descriptions can live at /meta-description-length. A guide about robots.txt mistakes can live at /robots-txt-mistakes. Both slugs say exactly what the page covers, and neither wastes words. If your slug needs a sixth word to be accurate, take the sixth word — the rule is a guide, not a limit — but ask first whether one of the first five is doing no work.

Lowercase only. URLs are case-sensitive after the domain, so /Guide and /guide are two different addresses. Mixed case creates duplicates that are invisible in a browser and confusing to everyone who links to the page. Pick lowercase once and never vary it.

Hyphens between words, never underscores or spaces. Search engines treat a hyphen as a word separator and an underscore as a joiner, so url-slug reads as two words and url_slug reads as one. Spaces are worse: they get encoded into unreadable percent sequences. Hyphens are the only separator that is readable by people and machines alike.

Words a person would use. The slug should contain the topic words of the page — the words someone would type to find it, and the words a reader would expect to see. This is not keyword stuffing; it is labelling. A slug of /page-47 tells nobody anything, while /url-slug-length tells everybody what the page is.

What to leave out

Dates. A slug containing /2024/ or october-update dates the page the moment it is published, and every later update makes the URL look stale. Dates belong in the page metadata, where they can be updated, not in the address, where they cannot be changed without breaking links.

Meaningless IDs. Numbers from a database, session tokens, and tracking parameters are not part of the page's identity. They make URLs unshareable — nobody pastes a link full of digits with confidence — and they create duplicate addresses for the same content, which is the canonical problem described in our canonical survey.

Stopwords you do not need. Words like "the", "and", "of", and "a" add length without adding meaning, and most slugs read better without them. But do not strip so aggressively that the slug stops making sense: /how-long-url-slug-be is shorter than /how-long-should-a-url-slug-be and harder to read. Remove the words that carry no information, keep the ones that hold the phrase together.

Repeated words and keyword lists. A slug of /seo-url-slug-seo-length-seo-guide is not more descriptive than /url-slug-length, it is just longer. Repeating a word does not make the page more relevant to it; it makes the URL look generated, and generated-looking URLs get fewer clicks and fewer links.

Changing a slug: the 301 rule

A slug is part of a page's address, and changing it breaks every link pointing at the old one. So the rule is simple: never change a slug without a 301 redirect from the old URL to the new one. A 301 tells search engines and browsers that the page has permanently moved, and passes the old URL's accumulated links and history to the new one.

That means a slug change is a small migration, not a typo fix. Before you change one, check what links to the old URL — internal links, external links, bookmarks, social posts, and any printed material. Update the internal links to point at the new URL directly, so they do not rely on the redirect, and leave the 301 in place indefinitely: removing it later breaks the external links you cannot update.

The other consequence is that a bad slug on a page nobody links to yet is cheap to fix, and the same bad slug on a page with years of links is expensive. This is the real argument for getting slugs right at publication time. The cost of a good slug is thirty seconds of thought before publishing; the cost of fixing a bad one later is a redirect, a link audit, and months of waiting for search engines to consolidate the two addresses.

Common mistakes

Letting the title become the slug. Most content systems generate the slug from the title automatically, and a long title produces a long slug. A title of "How Long Should a URL Slug Be, and Does It Even Matter for Rankings in 2026?" becomes a slug nobody can paste. Edit the generated slug down to the words that matter before publishing.

Using a different slug for the same page in different places. A page linked as /guide from the navigation and /Guide from an email is two addresses for one page. Pick one canonical form — lowercase, hyphenated, no trailing variation — and use it everywhere, including in your sitemap and your canonical tag.

Putting the whole category path in the slug. Folders are fine for organisation, but a URL like /blog/seo/technical/on-page/urls/how-long-should-a-url-slug-be buries the page under four levels of hierarchy. Two levels are usually enough; deeper than that, the folders are doing the labelling that the slug should be doing.

Changing slugs during a redesign. A redesign is the moment slugs get "tidied up" in bulk, which is also the moment hundreds of redirects get created at once. Redesign the design; leave the addresses alone unless a slug is actively wrong, and if you must change them, change them one at a time with a redirect each.

What to do

For a new page, write the slug after the draft is finished, when you know what the page actually covers. Three to five words, lowercase, hyphens, topic words only — then read the full URL out loud. If you can say it to someone and they can type it from memory, it is right.

For an existing page, audit the slugs that matter: the homepage's children, the pages with the most links, and the pages that appear in search results. Fix the ones that are unreadable, dated, or full of IDs — with a 301 each — and leave the rest alone. A slug that is merely inelegant is not worth a migration; a slug that misleads readers or breaks when pasted is.

And add the slug to your pre-publish check. The pre-publish checklist covers the canonical, the title, and the description; the slug belongs on the same list, because it is set at the same moment and is just as hard to change afterwards.

Limitations

Slug length is not a ranking factor, and this guide does not claim otherwise. A long slug will not push a page down, and a short one will not lift it up. What a short slug does is make the page easier to read, share, and link to — and links and clicks are the things that do move rankings, one step removed.

The three-to-five-word range is a working habit drawn from practice, not a measured threshold. Pages with longer slugs rank perfectly well, and pages with one-word slugs can be cryptic. Treat the range as a default to deviate from deliberately, not a rule to enforce blindly.