URL Normalization: Trailing Slashes, Uppercase, and www
· 2 min read
example.com/Blog/ and example.com/blog might be the same page, two different pages, or one page and one 404 — and nothing in the URL standard decides which. Every site answers these questions through configuration, deliberately or by accident. Answering them deliberately is called URL normalization, and it's a one-time decision that prevents years of duplicate-content leaks.
The four questions
1. Trailing slash or not? Historically /blog/ meant a directory and /blog meant a file, but on modern sites the distinction is pure convention. What matters: search engines treat them as two distinct URLs. If both return 200 with the same content, you're publishing duplicates and splitting inbound links between them. Pick one form — no-slash is the common modern default; frameworks like Next.js enforce it out of the box — and 301 the other to it. The one hard rule: the root / always keeps its slash, because https://example.com and https://example.com/ are defined as equivalent.
2. www or bare domain? www.example.com and example.com are different hostnames that both conventionally serve your site. Technical nuance exists (a bare apex domain constrains some DNS/CDN setups; www is a normal subdomain with full flexibility), but for SEO the only wrong answer is both: choose one, redirect the other at the edge, and make certificates cover both.
3. Case? Scheme and host are case-insensitive by spec — HTTPS://EXAMPLE.COM is fine. Everything after the host is case-sensitive, and platforms disagree on how to treat that: Linux servers 404 on wrong case, Windows-heritage servers serve the page anyway (creating duplicates). The escape from the whole mess is a convention you already want for slug quality: lowercase everything, always, and 301 mixed-case requests down to lowercase.
4. Protocol? This one's decided for you: https, with http 301-redirected and HSTS set. In 2026 the http→https redirect is table stakes; its only interesting property is that it's one more hop in your redirect chains if your other normalizations each redirect separately.
One hop, not four
That last point deserves its own rule. A request to http://www.example.com/Blog/ that triggers protocol, host, case, and slash normalization sequentially takes four redirects to land. Well-configured edges collapse all normalization into one 301 to the final URL. Check your worst-case URL with curl -sIL and count the Location headers — more than one hop for pure normalization is config debt.
Normalizations that are automatic (and one that isn't)
Browsers and well-behaved crawlers already normalize a few things before comparing URLs: percent-encoding case (%3A = %3a), unnecessary encoding of unreserved characters (%7Euser = ~user), default ports (:443 on https), and dot-segments (/a/../b → /b).
What's not automatic: query parameter order. ?a=1&b=2 and ?b=2&a=1 are distinct URLs to every cache and crawler, despite being semantically identical. You can't redirect your way out of this one — it's prevented by generating links consistently (one link builder, one parameter order) and mopped up by canonical tags. To see how a messy URL actually decomposes before deciding its normal form, the URL parser shows every component — including the parameter order you're about to standardize.
The meta-rule across all of it: one page, one URL, everything else redirects. Decide each question once, write it in the infrastructure, and duplicate-content problems stop being a category you think about.