tooldura

RFC 3986 splits URI characters into two groups. Unreserved characters are letters, digits, and exactly four punctuation marks: hyphen, period, underscore and tilde. They mean themselves, everywhere, and they never need encoding.

Everything else is either reserved, meaning it has a job somewhere in the URI (/ separates path segments, ? opens the query, # opens the fragment, & and = structure query parameters), or it is outside the allowed set entirely. Reserved characters can appear in a path, but only percent-encoded, and at that point they stop looking like punctuation and start looking like %26.

This is the whole reason a slug generator strips rather than preserves. A title like "Q&A: 50% Off?" contains three characters that each mean something structural in a URL. Keeping them produces a path that either breaks or reads as hex. Spelling them out produces q-and-a-50-percent-off, which survives being pasted anywhere.

Both characters are unreserved. Both work. The recommendation for hyphens comes from Google's own documentation on URL structure, which asks for hyphens between words and specifically discourages underscores.

The reason is historical and mechanical: Google's tokeniser treated a hyphen as a word break and an underscore as part of the word, so /blue_widgets was read as one token, bluewidgets, rather than two. Matt Cutts explained this publicly as far back as 2005, and while Google has since said the difference is minor, the recommendation in the documentation has never changed.

The practical case is simpler than the algorithmic one. Hyphens are easier to read, they are what every mainstream CMS produces by default, and they do not disappear under the underline that browsers, chat clients and email apps draw through link text. That last one alone has caused more mis-copied URLs than any ranking effect ever will.

Non-ASCII characters are legal in a modern URL. RFC 3987 defines IRIs, which allow the full Unicode range, and browsers display them as typed. This makes a Cyrillic or Greek slug look perfectly clean in the address bar, which is where the trouble starts.

The moment that URL leaves the browser, it converts to its ASCII form. /статья becomes /%D1%81%D1%82%D0%B0%D1%82%D1%8C%D1%8F. That is what gets pasted into an email, logged in your server access log, shown in analytics, and sometimes what a chat client displays instead of the pretty version. A six-letter word becomes 36 characters of hex.

So the choice is not about correctness. Both forms work. It is about whether the audience for a URL is people who read that script, in which case the native form is friendlier despite the encoding, or a general audience who will mostly see the encoded version. Transliteration gives up the exact spelling to keep the URL legible everywhere it travels.

Slugs must be unique within a site, and titles are not. "Part 1: Setup" and "Part 1 - Setup" produce the same slug, as do a category page and a post that happen to share a name.

Every CMS resolves this the same way, by appending a counter: part-1-setup-2. WordPress has done it since the beginning, and it is why the internet is full of URLs ending in -2 that nobody chose.

The counter is a fallback, not a fix. A slug ending in -2 tells a reader nothing and looks like a mistake, which it usually is: two posts that slug identically are often two posts that should have had more distinct titles in the first place. Converting a batch of titles at once is useful precisely because the collisions show up before anything is published, while the titles are still cheap to change.