Slugs and Permalinks in 2026: why URL structure still matters

A URL is more than a technical address — it's a tiny piece of brand communication, an SEO signal, a trust lever in a shared tweet, and a page's first impression in Google's search results. Even so, the 'slug' — the human-readable bit after the final slash — is, in many editorial workflows, just whatever the CMS auto-generates, never touched again. This article shows why that is an avoidable mistake, what makes a good URL, which RFC standards underpin it all, and how to build a permalink structure in 2026 that still works five years from now.

Anatomy of a URL: host, path, query — where the slug lives

A URL is split into several parts by RFC 3986: scheme (https), host (calcsi.com), optional port, path (/blog/slugs-permalinks-seo), optional query (?utm_source=twitter), and fragment (#section). The 'slug' in the narrow sense is the final segment of the path — what comes after the last slash, with no extension like .html. In a classic WordPress setup, the slug is what you edit next to the 'Permalink' field in the editor.

RFC 3986 distinguishes between 'unreserved' characters (letters, digits, and - . _ ~) that may appear in URLs unchanged, and 'reserved' characters (such as : / ? # [ ] @ ! $ & ' ( ) * + , ; =) that have syntactic meaning and must be percent-encoded outside that meaning. Anything that is neither unreserved nor syntactic — spaces, umlauts, emojis, Cyrillic letters — must be percent-encoded. A space becomes %20, the German ü becomes %C3%BC. Browsers often hide this prettily for the user, but technically they are very different strings.

Why slugs still matter for SEO

It has become fashionable to claim that URLs don't matter to Google. That isn't quite true. In its 'URLs in Search' documentation, Google explicitly lists URL structure as one of many small factors. John Mueller of Google has confirmed in several office-hours sessions: keyword-in-URL is a light signal, not a dominant one. But if you have two comparably good pages, one at /tools/p?id=4711 and one at /tools/percentage-calculator, the second wins measurably in snippets, backlink profile, and click-through.

Beyond SEO, there are hard UX reasons for clean slugs. A URL you can read aloud on a phone call ('calcsi dot com slash tools slash bmi-calculator') builds trust. Screen readers pronounce meaningful URLs intelligibly, whereas cryptic hash IDs are read letter by letter. Analytics reports become at-a-glance interpretable with readable paths, without joining slug IDs against a lookup table. And in Slack, Teams, or Discord previews, human-readable URLs simply look more professional.

Anatomy of a 'perfect' slug

There is no official SEO rulebook, but two decades of practice (and many Google statements) have produced a robust pattern:

• Length: 3 to 6 words is the sweet spot. Below 3, the slug feels too generic (/blog/seo), above 6 it becomes unwieldy and the important terms slip to the end, where Google weighs them less.
• Case: lowercase only. Linux servers treat /Blog and /blog as two different paths, which causes duplicate-content issues. If you allow both, normalize via a 301 redirect from uppercase to lowercase.
• Separator: hyphens, never underscores. In 2008, Matt Cutts (then Google's web spam lead) was unambiguous that Google reads hyphens as word separators and underscores as word joiners. The behavior hasn't changed: my_calculator is indexed as a single token 'my_calculator', whereas my-calculator becomes two tokens 'my' and 'calculator'. For SEO that's a big difference.
• Stop words: drop them for tighter URLs. /how-to-calculate-vat becomes /calculate-vat or, better, /vat-calculator. English articles (the, a, an), German articles, and prepositions add little meaning but bulk.
• Transliteration: turn umlauts, accents, and special characters into ASCII. ü becomes ue, é becomes e, ß becomes ss. This avoids encoding hiccups when sharing and stays readable in every context.

Non-Latin scripts: Punycode, percent-encoding, and the pragmatic route

For domains, RFC 3492 defines Punycode: München.de is encoded internally as xn--mnchen-3ya.de. Browsers show the original; DNS speaks Punycode. For the path, percent-encoding under RFC 3986 applies — ü in the path becomes %C3%BC. Both work technically — but in shared snippets, mail clients, Slack previews, and hand-typed URLs, the transliterated ASCII variant is simply more reliable.

The same trade-off applies to Arabic, Cyrillic, Chinese, or Japanese content. An Arabic URL keeps its original script when opened in the browser but, when pasted into a Latin-1 environment, looks like %D8%A7%D9%84%D9%82%D8%B1%D8%A2%D9%86. For multilingual sites, the safer approach is a locale prefix (calcsi.com/ar-eg/tools/...) with transliterated slugs instead of non-Latin characters directly in the path. Our own slug generator works exactly along these lines.

Practical examples

From original title to clean slug — these transformations are a good rule of thumb for editorial workflows:

• "Über uns!" becomes ueber-uns or, more compact, uber-uns. The exclamation mark drops (no semantic value), the ü is transliterated, everything lowercase.
• "Müller's Café" becomes muellers-cafe. The apostrophe drops, ü becomes ue, é becomes e — none of the three operations harms readability.
• "C++ Tutorial" becomes cpp-tutorial. The plus signs are reserved characters, percent-encoding (c%2B%2B-tutorial) is ugly, and the established ASCII convention 'cpp' for 'C++' has been understood for decades — exactly what you want.
• "5 Tips for Better Sleep" becomes better-sleep-tips or sleep-tips — never the literal version with a leading number. Numbers in the slug telegraph listicle clickbait and age badly the moment someone extends the article to 7 tips.

Moving a URL: the 301 dance ritual

If you change an existing slug, you must redirect the old path to the new one with a 301 ('moved permanently'). Otherwise three things happen: (1) every backlink from external sites points into the void and you lose link equity; (2) Google eventually drops the old URL from the index and starts the new one at zero trust — rankings can crater; (3) bookmarks and internally shared deep links from your regulars become 404 errors and you lose return visits. A 302 redirect ('temporarily') passes link equity less reliably — for a permanent move, 301 (or 308) is mandatory.

Another hard design choice: the trailing slash policy. /blog/slugs-permalinks-seo and /blog/slugs-permalinks-seo/ are, by web standards, two different URLs. Pick exactly one and 301 the other to it. Which one is up to you — consistency is what matters, otherwise you end up with two versions of every page in the index. A similar choice concerns www vs. non-www: both should normalize via 301 to a single canonical.

Practical permalink structures for 2026

A flat hierarchy works for most sites: /blog/slug, /tools/slug, /about, /pricing. Deeply nested paths like /blog/2024/06/04/category/slug look historically WordPress, but every URL change becomes a redirect chore and mobile search snippets render them unreadably. Chrome on the phone has long shown only the domain — a long path isn't displayed at all. If category matters for content architecture (e.g. /tools/finance/vat-calculator), use it — but never deeper than two levels beneath the root.

Dates in the URL path are a bad idea for evergreen content in 2026. A URL like /blog/2024/seo-tips tells the reader two years on: outdated. Even if you update the article, the path looks old — and switching to evergreen URLs means redirecting every page. For high-frequency content (live coverage, election results, daily sports), a date slug is honest and sensible. For content dominated by a database ID (e.g. 100,000+ products), a hybrid slug of ID and human name is a good compromise: /product/12345-running-shoes-nike-air stays unique but is human-readable and contains keywords.

Frequently asked questions

Should I include the date in URLs?

For evergreen content: no. A date in the path ages visibly the moment it's published, and updating the article later doesn't help. For news, live coverage, or daily events, a dated slug is sensible — it honestly says 'as of June 4, 2026'. Rule of thumb: if the content should still be relevant in three years, no date in the slug.

Should the category appear in the URL?

It depends. Pro: a category like /finance/vat-calculator clarifies site structure and provides a weak contextual boost for long-tail keywords. Con: if you later move the article to a different category (say /taxes/vat-calculator), you must 301 and lose a bit of equity. Practical recommendation: at most one category level beneath root, and only if the category is stable. If you need categories as CMS filters but not in URLs, make them an internal tag.

How do WordPress permalink codes work?

WordPress uses a small templating language with percent variables in its permalink settings. The main ones: %postname% for the slug, %year%, %monthnum%, %day% for date parts, %category% for the primary category, %post_id% for the numeric ID, %author% for the author slug. The most SEO-friendly default is /%postname%/ — flat hierarchy, slug only, no date. For a category level, use /%category%/%postname%/. Important: changing permalinks retroactively always means a wave of redirects — decide once, properly, and don't touch it again.