Turn any title into a clean, SEO-friendly URL slug.
A slug is the human-readable part of a URL that identifies a page — the how-to-bake-bread in example.com/blog/how-to-bake-bread. Generating one means converting a title into lowercase, replacing spaces with hyphens, stripping punctuation and handling accented or non-Latin characters.
Google has been explicit about this for years: a hyphen is treated as a word separator and an underscore as a word joiner. So red-shoes is indexed as two words, while red_shoes is indexed as the single token "red_shoes" and will not match a search for "red shoes". Hyphens are also easier to read and to dictate. There is no good reason to use underscores in a URL.
A slug should carry the meaning of the page and stop. Long slugs get truncated in search results, are awkward to share, and dilute rather than concentrate the keywords they contain. Dropping stop words is standard practice:
| Title | Weak slug | Better |
|---|---|---|
| How to Make the Best Sourdough Bread at Home | how-to-make-the-best-sourdough-bread-at-home | sourdough-bread-recipe |
| 10 Tips for Improving Your Sleep Quality | 10-tips-for-improving-your-sleep-quality | improve-sleep-quality |
| What Is Compound Interest and How Does It Work? | what-is-compound-interest-and-how-does-it-work | compound-interest-explained |
Three to five meaningful words is a good target. Words like the, a, and, for, of and to add length without adding meaning, though removing them should never make the slug read as nonsense.
URLs technically support Unicode through percent-encoding, and a slug in Cyrillic, Arabic or Devanagari will work in modern browsers. The practical difficulty is that the encoded form is unreadable when copied into a plain-text context — a short phrase can become a hundred characters of percent escapes — and some older systems mangle it.
The two viable approaches are to transliterate into ASCII, which keeps the URL portable but loses meaning for readers of the original script, or to use native script, which reads naturally for the intended audience and is what most large sites now do for non-English content. Neither is wrong; the choice depends on where your links will be pasted.
This is the practical rule that matters most. Changing the slug of a live page changes its URL, which breaks every existing link, discards accumulated search ranking and returns 404 to anyone following a bookmark or a citation. If a change is unavoidable, set up a 301 permanent redirect from the old URL to the new one and leave it in place indefinitely.
For that reason, avoid putting anything time-sensitive in a slug. Dates and years age badly — best-laptops-2026 looks stale in January and cannot be updated without breaking links, whereas best-laptops can be revised each year and keeps its ranking. The same applies to prices, version numbers and anything else that will change.
Two posts titled "Monthly Update" produce the same slug. The usual resolutions are to append a number, prefix with a date segment such as /2026/03/monthly-update, or require a distinct title. Whichever you choose, decide it deliberately rather than letting a system silently overwrite one page with another.
Hyphens. Search engines treat a hyphen as a word separator and an underscore as a joiner, so "red_shoes" will not match a search for "red shoes". Hyphens also read more clearly.
Three to five meaningful words is a good target. Long slugs get truncated in search results and dilute the keywords they contain. Drop stop words like "the", "and" and "for" unless removing them makes the slug nonsensical.
You can, but every existing link to that page breaks and its accumulated ranking is lost. If you must change it, add a 301 permanent redirect from the old URL and keep it in place indefinitely.
Generally no. A slug containing a year looks outdated within months and cannot be refreshed without breaking links. Keep the date in the page content where it can be updated freely.
They are transliterated to the closest ASCII equivalent, so an accented e becomes e. If your audience reads a non-Latin script, using the native script in the URL is also valid — modern browsers handle it, though the percent-encoded form is unreadable when pasted as plain text.