URL Best Practices: Hyphens vs. Underscores, Length, and Casing

Hyphens vs. Underscores: The Definitive Answer

This question has a clear, official answer: use hyphens, not underscores.

Google's former head of search quality, Matt Cutts, stated in a 2011 Google Webmaster Help video that Google treats hyphens as word separators in URLs. The words red, ball, and gown in the URL /red-ball-gown are indexed as three separate words. Underscores do not get the same treatment — red_ball_gown is treated as one compound token, not three separate words.

This distinction matters for keyword matching. If someone searches for "red ball gown," a URL with hyphens provides a weak keyword signal. A URL with underscores provides no word-separator signal at all — the search engine sees one joined string.

Google's Search Central documentation (previously Google Webmaster Guidelines) explicitly recommends: "Use hyphens (-) instead of underscores (_) in your URLs."

URL Length

There is no official maximum URL length enforced by Google's crawler. However, several practical limits apply:

• Browser limit: Most browsers support URLs up to approximately 2,048 characters (Internet Explorer's old limit), and modern browsers handle much longer URLs. In practice, URLs are limited more by usability than technical constraints.
• Google's crawl behaviour: John Mueller (Google Search Advocate) has confirmed that Google can crawl and index very long URLs. There is no SEO penalty for URL length per se.
• Practical recommendation: Keep slugs to 3–7 words (roughly 50–90 characters) for readability, shareability, and trust. Long URLs with many path levels are harder to remember, share, and type correctly.

The optimal URL length is the shortest URL that clearly describes the page content. Removing stop words (a, an, the, and, or) typically reduces slug length without reducing clarity.

Casing: Always Lowercase

URLs are case-sensitive on most web servers (Apache and Nginx are case-sensitive by default on Linux; IIS on Windows is case-insensitive). This means /My-Article and /my-article can be treated as two different pages.

Use all-lowercase URLs for two reasons:

1. Prevent duplicate content: If both /My-Article and /my-article serve the same page, search engines may treat them as duplicate pages — splitting the "link equity" between them and potentially diluting rankings. Canonical tags can fix this, but it is better to avoid the problem entirely.
2. Consistency: Lowercase URLs are easier to type, share, and remember. They avoid the confusion of users guessing whether a URL is capitalised.

Redirect any accidentally created uppercase URLs (via 301 permanent redirects) to their lowercase equivalents.

Trailing Slashes

Whether to include a trailing slash (/my-article/ vs. /my-article) is a matter of server configuration, not SEO principle. Both formats are fine — but you must be consistent. /my-article/ and /my-article are technically different URLs. If your server serves the same content at both, set up a redirect so one canonically redirects to the other.

Most CMS platforms (WordPress, Shopify) enforce a trailing slash convention by default. Static site generators (Jekyll, Hugo, Next.js with static export) typically generate directory-based URLs with trailing slashes. Follow whatever convention your platform establishes consistently.

URL Depth (Number of Subdirectories)

Deeper URLs (more slashes) are not penalised by Google directly. However, very deep URL structures (/category/subcategory/sub-subcategory/article-title) can be indicators of over-complex site architecture, which may make crawling less efficient and link equity harder to flow from high-authority pages to deeper content.

The recommendation from most SEO practitioners is to keep important content within two to three levels of the root (/blog/article-title/ rather than /blog/category/year/month/article-title/). This is about crawl efficiency and site architecture, not a direct ranking factor.

Numbers and Dates in URLs

Including dates in URLs (/2024/01/15/article-title) is common in blog and news platforms but has significant drawbacks:

• The URL signals "this is old" to users looking at search results, which can reduce click-through rate on older articles
• If you update the article, the URL still shows the original publication date — creating a contradiction
• Changing the URL later (to remove the date) requires redirects and risks losing link equity

For evergreen content, date-free URLs (/blog/article-title) are generally preferable. For news content where publication date is editorially important, date-based URLs follow industry convention and are acceptable.

Special Characters: What to Avoid

RFC 3986, the standard defining URI syntax, distinguishes between "reserved" characters (which have special meaning in URLs) and "unreserved" characters (which can be used safely). In URL slugs, stick to:

• Lowercase letters: a–z
• Numbers: 0–9
• Hyphens: -

Avoid ampersands (&), question marks (?), hash symbols (#), periods (.), colons (:), parentheses, and other characters that have reserved meanings in URL syntax. Non-ASCII characters (accented letters, CJK characters, emoji) must be percent-encoded and should generally be avoided in slugs for reliability across different systems and sharing contexts.

Generate a clean URL slug →