Good URLs vs bad URLs: see the difference, learn how each CMS handles slugs, and master clean URL creation.
The URL is one of the first things both users and search engines see when encountering your page. A clean, descriptive URL communicates trust, relevance, and professionalism. A messy, cryptic URL does the opposite. This comparison guide shows you exactly what separates a good URL slug from a bad one, how different content management systems generate slugs by default, and how to handle the tricky edge cases that trip up even experienced developers.
Let's start with the most instructive format: direct comparisons. For each example, the good URL follows SEO best practices while the bad URL demonstrates a common mistake.
/blog/website-screenshot-tool
Short, descriptive, keyword-rich, uses hyphens, no unnecessary words.
/p?id=12345&cat=tools
No descriptive text, query parameters instead of clean paths, meaningless to humans and search engines.
/blog/how-to-choose-running-shoes
Clear topic, includes target keyword, readable, and shareable.
/blog/post_144_How%20to%20Choose%20the%20Best%20Running%20Shoes%20for%20You%20in%202026
Too long, includes date and post ID, spaces encoded as %20, over-optimized with filler words.
/products/blue-running-shoes
Logical hierarchy, product-specific, easy to remember.
/catalog/view/item/Blue+Running+Shoes_Nike_Air_Max_2026_SKU-8837421
Nested catalog structure, plus signs, underscores, includes SKU, impossible to read or remember.
/seo-guide/beginner
Logical category structure, clear hierarchy, no unnecessary elements.
/category/seo/guide/beginner?ref=homepage&utm_source=newsletter
Overly nested path, tracking parameters create multiple URLs for the same content.
The pattern is clear: good URLs are short, descriptive, use hyphens, avoid parameters, and include meaningful keywords. Bad URLs are long, cryptic, use encoded characters, include IDs, and provide no context about the page content.
Different content management systems have different default behaviors for URL generation. Understanding these defaults helps you set up your CMS correctly and avoid common pitfalls.
WordPress generates slugs from the page title automatically when you create a new post or page. By default, it converts the title to lowercase, replaces spaces with hyphens, and removes most special characters. However, WordPress keeps stop words ("a," "the," "is," "in") by default, which can make slugs longer than necessary. The popular Yoast SEO plugin can be configured to automatically remove stop words from slugs. WordPress also supports custom permalink structures via Settings, letting you choose between formats like /%postname%/, /%category%/%postname%/, or /%year%/%month%/%postname%/.
Shopify generates product and collection slugs from the product title. It handles special characters well, converting accented characters and removing problematic symbols. Shopify automatically appends a unique suffix to duplicate slugs (e.g., /products/blue-shirt-1), which prevents conflicts but can look unprofessional. Shopify also creates "handle" fields that serve as URL slugs, and these can be edited manually after creation.
Ghost generates clean slugs by default, converting titles to lowercase hyphenated strings. Ghost has a built-in feature to edit slugs directly in the post editor, and it shows a live URL preview as you type. Ghost slugs are relatively short by default because the platform was designed with SEO in mind from the start. It does not include dates or IDs in URLs by default.
Historically, Wix generated poor URLs with numeric IDs and no descriptive text. Since 2016, Wix has improved significantly and now generates readable slugs for new sites. However, legacy Wix sites may still have old-style URLs. Wix allows custom URL editing, and the platform automatically creates 301 redirects when you change a slug, which is a best practice for preserving SEO value.
Drupal uses the Pathauto module for automatic URL alias generation. It is highly configurable, supporting tokens, patterns, and transliteration for multilingual sites. Drupal's default pattern is typically /content/[node:title], but administrators can create custom patterns per content type. Drupal also handles path aliases and redirects well, making it a strong choice for sites that need granular URL control.
Special characters in URLs are one of the most common sources of broken links, encoding issues, and SEO problems. Here is how to handle every category of special character.
Spaces in URLs are encoded as %20 or +, both of which look ugly and are harder to share. Always replace spaces with hyphens in URL slugs. This is the single most important URL formatting rule.
Characters like cafe (with accent), resume (with accents), or Spanish characters like n-tilde should be converted to their ASCII equivalents. "Cafe" becomes "cafe," "resume" becomes "resume," and "nino" becomes "nino." This ensures URLs work correctly across all browsers, email clients, and social media platforms. Many URL slug generators handle this automatically using Unicode normalization.
Remove all punctuation except hyphens from URL slugs. Commas, periods, exclamation marks, question marks, semicolons, colons, and parentheses should all be stripped. Apostrophes can either be removed or replaced with nothing (so "don't" becomes "dont" rather than "don-t"). The ampersand (&) should be replaced with "and" (so "R&D" becomes "r-and-d").
This is one of the most debated URL formatting questions. The answer is clear: use hyphens, not underscores. Google's Matt Cutts confirmed in 2007 that Google treats hyphens as word separators but underscores as word connectors. So red-shoes is interpreted as two words ("red" and "shoes"), while red_shoes is interpreted as one word ("red_shoes"). This distinction directly affects how Google understands your URL and its relevance to search queries.
URLs are case-sensitive in some web servers (Linux/Apache) and case-insensitive in others (Windows/IIS). To avoid confusion and potential duplicate content issues, always use lowercase letters in URL slugs. /Blog/My-Post and /blog/my-post might be treated as different URLs on some servers, creating duplicate content problems.
Numbers are fine in URLs when they add meaning (e.g., /html-minifier or /top-10-tools). However, avoid auto-generated numbers that serve no purpose (like WordPress post IDs or timestamp-based slugs). If your CMS generates /post/12345 by default, change the permalink structure to include the post name instead.
Stop words are common words like "a," "an," "the," "is," "are," "in," "on," "at," "to," "for," "and," "but," and "or." The question of whether to remove them from URL slugs has no universal answer, but here are practical guidelines.
Remove stop words when: the slug is getting too long (over 60 characters), the URL reads naturally without them, or you want to make the URL more concise for sharing. For example, "the-best-way-to-learn-python" becomes "best-way-learn-python" when stop words are removed.
Keep stop words when: removing them would make the URL ambiguous or grammatically incorrect. For example, "men-vs-women" is clear, but "how-wire-money" is confusing without "to" (it should be "how-to-wire-money"). The key is readability: if the slug reads like a coherent phrase, it is fine.
Most SEO professionals recommend removing stop words from URL slugs by default, then adding them back in if the result is unclear. A URL slug generator with a stop word filter handles this automatically.