URL Case Sensitivity

Why /Apple and /apple are two different URLs to Google — the Linux vs Windows/IIS filesystem mechanism behind it, the robots.txt case trap, server-level fixes for Apache, Nginx, and IIS, and how to find case duplicates in the wild.

First published: Jul 3, 2026 · Last updated: Jul 18, 2026 · Advanced
demand #3 in URL Structure#16 in Website Structure#257 in Technical SEO#347 on the site
1 evidence signal on this page

URL paths, filenames, and query parameters are case-sensitive to Google (the hostname isn't) — so /Apple and /apple are two different URLs that can spawn duplicate content, and a robots.txt Disallow for /Private/ won't block /private/. The mechanism is your filesystem: Linux/Unix (and Apache/Nginx on it) treat paths as case-sensitive byte strings; Windows/IIS is case-insensitive by default, so the same request can 404 on one host and 200 on another. The fix is picking one case (lowercase is the convention) and enforcing it with a server-level redirect, or rel=canonical as a fallback.

TL;DR — Hostnames are case-insensitive; path and query comparison may be case-sensitive and ultimately depends on server and application routing. Filesystem defaults often influence behavior, but do not define URL semantics by themselves. Google can crawl differently cased paths as distinct URLs; it can canonicalize them together when content matches, but “usually… not always ideal” is not a strategy. robots.txt values are case-sensitive too, so a Disallow for one casing silently misses the others — a distinct access problem, not just a duplicate-content one. Fix priority: prevent variants at the source, then a server-level 301 to lowercase (Apache RewriteMap tolower, Nginx map, IIS URL Rewrite), with rel=canonical as a fallback when you can’t touch the server.

Evidence for this claim URI schemes and hosts are case-insensitive, while path and query components may be case-sensitive depending on the server and application. Scope: Generic URI comparison rules. Confidence: high · Verified: IETF RFC 3986: Syntax-based normalization Evidence for this claim Google recommends consistent URL casing and treats URLs that differ by path case as potentially distinct crawlable URLs. Scope: Current Google URL consistency guidance. Confidence: high · Verified: Google Search Central: URL structure best practices

What is (and isn’t) case-sensitive

Start with the exact boundary, because casual phrasing (“URLs are case-sensitive”) gets it wrong half the time. John Mueller drew the line cleanly: “URL path, filename, and query parametersThe `?key=value` data tacked onto the end of a URL after a question mark — used for tracking, sessions, filtering, sorting, and search — and one of the biggest sources of duplicate URLs and wasted crawling in SEO. are case-sensitive, the hostname / domain name aren’t. Case-sensitivity matters for canonicalizationHow search engines pick one canonical URL among duplicates and consolidate signals onto it., so it’s a good idea to be consistent there.”

So:

URL partCase-sensitive?Why
Scheme (https://)NoFixed protocol tokensA token is the smallest unit of text (or image/audio/video) an LLM processes — roughly 4 characters, or about ¾ of an English word. A context window is the maximum number of tokens (input plus output) a model can hold at once, like its short-term memory.
Hostname (example.com)NoDNS resolution is case-insensitive at the protocol level
Path (/Products/Shoes)YesResolved against a filesystem/router that compares casing
Filename (/Logo.png)YesSame — it’s part of the path
Query string (?Color=Red)YesParameter keys and values are compared as-is

EXAMPLE.com/page and example.com/page are the same URL. example.com/Page and example.com/page are not. This is the same class of “one page, many URLs” problem that trailing slashesA trailing slash is the forward slash (/) at the end of a URL — example.com/page/ versus example.com/page. Except at the bare root domain, the two versions are different URLs to search engines, so you pick one format and enforce it., www vs non-www, and query parameters create — the URL structure and canonicalizationHow search engines pick one canonical URL among duplicates and consolidate signals onto it. deep dives cover those variants, and I won’t re-derive them here; casing is one more axis in the same duplicate-URL grid.

That table is the URL-handling default engines like Google follow, per the spec — not a promise about what your specific origin server, CDN, or application will actually return. Treat it as where to start testing, not as a substitute for testing: request the path in both casings and read the real response (the Scripts tab has a copy-paste curl check) before you assume the rule applies to your stack.

One more edge case worth flagging rather than glossing over: Unicode slugs. Two visually identical characters — a Latin “a” and a Cyrillic “а,” for example — can be different code points that survive ASCII-style lowercasing completely untouched, because lowercasing operates on the characters you have, not the ones a reader perceives. If you generate slugs from non-English titles, decide your encoding and normalization policy up front rather than assuming a .toLowerCase() call catches everything international.

Why this happens: it’s your filesystem

Most write-ups state “URLs are case-sensitive” as received wisdom and move on. The useful part is why, because it explains the single most confusing symptom — the same URL working on one server and 404-ing on another.

Linux/Unix filesystems are case-sensitive. On the ext4, XFS, and similar filesystems that run the overwhelming majority of the web, Apple and apple are literally different directory entries — different inodes. When Apache or Nginx maps an incoming request path to a file or a route, it compares the casing byte-for-byte. Ask for /Apple when only /apple exists and you get a genuine 404.

Windows/NTFS is case-insensitive by default — but case-preserving. It stores Apple with its capital A intact (so it displays “correctly”), yet when it looks the name up, it ignores case. IIS, Microsoft’s web server, inherits that behavior: request /Apple or /APPLE or /apple and IIS serves the same file. It doesn’t fix the SEO problem — Google still sees distinct URLs — but the server itself will happily 200 all of them.

The consequence is the classic dev-to-prod bug: a developer on Windows/IIS types a path with the wrong case, it works fine locally because Windows doesn’t care, then the same request 404s the moment it hits a Linux/Apache/Nginx production server that does. Nothing in your CMSA content management system (CMS) is software that lets users create, manage, and publish digital content — like blog posts and pages — without writing raw code. WordPress, Drupal, and Joomla are the most common open-source CMS platforms. or SEO plugin caused it — the two machines’ operating systems just disagree about whether case matters. (Microsoft documents this behavior directly in its Windows case-sensitivity guidance.)

This is worth knowing during any platform migration: move a site between a case-insensitive host and a case-sensitive one and mixed-case URLs that “always worked” can suddenly start breaking or duplicating.

The filesystem is the bottom of the stack, not the whole stack. Everything above it — a reverse proxy, a CDN edge, a load balancer, or the application’s own router — gets a chance to normalize, rewrite, or short-circuit a request’s casing before it ever reaches the filesystem the origin server sits on. A Linux origin doesn’t guarantee case-sensitive behavior at the URL you actually request if something in front of it is already folding cases together, and an application router can just as easily impose its own case rules independent of the OS underneath it. “Linux + Apache/Nginx = case-sensitive” is the right default assumption, not a substitute for checking the actual response on your stack.

How Google actually treats case-different URLs

Google isn’t inventing case sensitivity — it’s following the URL spec that every compliant HTTP client follows. From the docs: “Like any other HTTP client following IETF STD 66, Google Search’s URL handling is case sensitive (for example, Google treats both /APPLE and /apple as distinct URLs with their own content).” That STD 66 groundingGrounding is anchoring an AI model's answer to source documents it retrieves at the moment you ask — not to the patterns frozen into its weights during training. Retrieval-Augmented Generation (RAG) is the most common way to do it. matters: this is standards behavior, not a Google quirk.

Google’s own advice is to normalize: “If upper and lower case text in a URL is treated the same by your web server, convert all text to the same case so it’s easier for Google to determine that URLs reference the same page.” Note the “if” — that’s aimed squarely at case-insensitive servers (IIS) that serve every casing, which is exactly where the duplicate risk lives.

Can Google merge case-duplicates on its own? Often, yes — through canonicalization, casing is one of the common duplicate-URL patterns it groups. Mueller: “If a website still shows the same content in these cases, search engines will try to figure it out on their own and usually that works out well. But it’s not always ideal.” And in a separate exchange about mismatched canonicals on uppercase URLs, he was sharper: “If it serves the same content, it’ll probably be seen as a duplicate and folded together, but ‘hope’ should not be a part of an SEO strategy.”

That’s the honest framing. This isn’t a five-alarm fire — but relying on Google to guess right is a choice you don’t have to make when the fix is a redirectA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. rule.

There’s also a crawl-efficiency cost. Mueller: “Search engines will try to crawl all variations of the URL that they find. This can make it a bit slower for them to find other useful content on your website.” If your site is spraying case-variant URLs into the link graph, botsA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. waste fetches re-crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. the same content in different casings instead of discovering your real pages — the same crawl-waste dynamic the parameters and crawl-budget topics describe, just with casing as the multiplier.

How Bing treats case-different URLs

Bing behaves differently, and honesty about sourcing matters here: there is no dedicated Bing documentation page on URL case sensitivityURL case sensitivity is the rule that uppercase and lowercase letters in the path, filename, and query string are treated as different characters — so /Apple and /apple are two distinct URLs — while the hostname is not case-sensitive. comparable to Google’s STD 66 callout, so this is based on webmaster reports and Microsoft community threads, not a formal spec.

What those reports consistently describe: BingbotBingbot is Microsoft Bing's primary web crawler — the bot that discovers, fetches, and renders pages to build the Bing index. That index also powers Yahoo, DuckDuckGo, Ecosia, and Microsoft Copilot, so Bingbot's reach is far wider than Bing's own search-market share. tends to normalize toward lowercasecrawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. and indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. the lowercase version of a URL it discovers, and Bing Webmaster ToolsMicrosoft's free portal for monitoring and improving how a site appears in Bing search — the peer to Google Search Console, plus IndexNow instant indexing, richer backlink data, and keyword volumes. Because Bing's index also feeds Microsoft Copilot, it doubles as a window into AI-search visibility. has been observed auto-lowercasing URLs submitted in sitemapsA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing.. Webmasters have raised both behaviors on the Microsoft Community Hub. So Bing appears to do more of the case-collapsing for you than Google’s strict distinct-URL treatment does.

Caveat: this is Bing’s practical behavior per webmaster reports and community threads, not an official policy statement. I’m not going to invent a Bing spokesperson quote — none exists for this specific topic. Treat it as “behaves differently, less formally documented,” and verify against your own Bing Webmaster Tools data if it matters to you.

Either way, the fix is the same. Standardizing on lowercase satisfies Google’s distinct-URL model and aligns with whatever Bing is normalizing toward — you don’t optimize for one engine’s behavior at the expense of the other.

The robots.txt case trap

This deserves its own section because it’s a different kind of failure from duplicate contentThe same or very similar primary content reachable at more than one URL. There's no general duplicate content penalty — the real costs are possible signal dilution, the wrong URL getting chosen, and less-efficient crawling.. Duplicate content splits signals; a broken robots.txt rule is an access-control failure — a path you meant to keep bots out of gets crawled anyway.

The rule, straight from Google’s robots.txtA plain-text file at the root of a host that tells crawlers which URLs they may and may not request. It controls crawling, not indexing — a blocked URL can still be indexed if it's linked from elsewhere. spec: the directive name is case-insensitive, but its value is case-sensitive. “The field name (disallow) is case-insensitive, but its value is case-sensitive.” And: “The path value must start with / to designate the root and the value is case-sensitive.” Google’s own example spells it out — a rule for /fish “Matches any path that starts with /fish. Note that the matching is case-sensitive.”

So Disallow, disallow, and DISALLOW all work identically — the directive name casing is irrelevant. But the path value is matched exactly. Mueller confirmed the practical implication directly: “The robots.txt file also uses exact URLs, so if you have entries there which refer to one version of a URL they would not apply to other versions.”

Two concrete ways this bites — the second is the more dangerous:

Example 1 — the classic. Your robots.txt has:

User-agent: *
Disallow: /Private/

That blocks /Private/. It does nothing for /private/. If anything on your site links to the lowercase version, it’s fully crawlable despite your rule.

Example 2 — the post-migration mismatch. You replatform, and the new CMS generates cart and admin paths in lowercase. Your old robots.txt, copied over verbatim, still says:

Disallow: /Checkout/
Disallow: /Admin/

The live URLs are now /checkout/ and /admin/. The disallows silently miss them, and thin, no-value (or sensitive) paths get crawled and can end up indexed. This is exactly the scenario migration teams walk into, because robots.txt almost never gets audited against the actual casing of the new URLs.

(To be clear, this rarely causes catastrophic problems in practice — Mueller has said case mismatches in robots.txt are rare to see cause real issues. But “rare and silent” is precisely the kind of bug that sits unnoticed for months, so it’s worth a five-minute check.)

The fix for the trap is the same discipline as everywhere else: write your robots.txt rules in the casing your URLs actually use, and enforce a single casing so there’s only one version to block.

Fixing case-duplicate URLs

Standard technical-SEO remediation hierarchy, most to least preferred:

1. Prevent variants at the source

The best fix is never generating mixed-case URLs in the first place — this is a CMS/URL-generation-layer concern, and it varies by platform (verify current behavior on your own stack rather than trusting a blanket claim):

  • Shopify lowercases product and collection handles automatically, so native URLs are largely safe — but app-generated or legacy-imported URLs can still introduce case variants.
  • WordPress permalinks are lowercase by convention, but custom post types, tags, and manually entered slugs can introduce mixed case; Yoast and RankMath don’t natively force-lowercase URLs.
  • Enterprise, custom, and Java/.NET-backed platforms are the most exposed — casing often falls out of the routing framework and hosting OS with no deliberate policy, especially on Windows/IIS stacks where nothing forces the issue locally.

2. Server-level lowercase redirect (the definitive fix)

A 301 to the canonical lowercase URL is the hard fix — it consolidates signals and sends users/bots to one address. The implementation differs by server (full copy-paste config is in the Scripts tab):

  • Apache has a native lowercasing tool — RewriteMap with int:tolower — so you can convert an entire path to lowercase in a rewrite rule.
  • Nginx has no built-in string-lowercasing function, so it’s genuinely more involved than Apache’s one-liner: you either use the njs/Lua module to lowercase the URI, or build an explicit map lookup that catches uppercase characters. Don’t let anyone tell you it’s a like-for-like map one-liner — it isn’t.
  • IIS uses the URL Rewrite module with a rule condition and the {ToLower:...} function. Since IIS serves every casing by default, this is where enforcement matters most.

Don’t ship a blanket sitewide rule blind. Lowercase is the right convention for new paths, but a mixed-case-to-lowercase redirect is not automatically safe on an existing site — inventory your actual case variants first (crawl export, access logs, sitemap, internal linksAn internal link is a hyperlink from one page on a website to another page on the same website. Internal links help search engines discover your pages and pass ranking signals (PageRank and anchor-text context) between them.), and specifically check for paths where the case is legitimate and load-bearing: uploaded filenames, generated tokens, anything a CMS or app produced with intentional mixed case. Confirm each route actually returns equivalent content in both casings before you fold it into the rule, roll the redirect out in a bounded way rather than flipping every path at once, and watch error rates and the GSC Page indexing reportThe Google Search Console report (formerly Index Coverage) showing how many of your URLs are indexed vs. not indexed, and grouping the not-indexed ones by reason. afterward — there’s no guarantee a lowercase cleanup recovers lost rankings or crawl coverage, only that it stops the signal-splitting going forward.

3. rel=canonical as a fallback

When you can’t touch server config — shared hosting, a platform that won’t let you add rewrite rules, or a case where legitimate case-variant URLs must stay live — a rel=canonical pointing every variant at the lowercase version is the safety net. It’s a hint, not a directive, and weaker than a 301 — but far better than nothing. Mueller’s recommendation: “Using internal linkingLinks between pages on the same site. to link to a consistent version makes your preference clear. Adding a link rel=“canonical” element also helps to confirm that.”

That said, canonical only works once you’ve confirmed the variants actually serve duplicate content. If a case variant returns genuinely different content, or an error, a rel=canonical element can’t merge it — a hint can’t consolidate two different resources into one. Verify the response before you point a canonical at it, not after.

Whatever casing you choose, your own links have to agree with it. Every internal link, navigation entry, and sitemap URL should use the canonical (lowercase) version. A perfect redirect rule undermined by menus that still link to /Products/ just makes bots follow redirect hops they didn’t need to.

How to find case-duplicate URLs on your site

Three complementary methods — GSC shows what Google actually did; crawlersA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. let you catch variants before they become an indexing problem:

  • Google Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. → Page indexing report. Look for Duplicate without user-selected canonicalA Google Search Console Page Indexing status: Google found this page to be a duplicate, you didn't declare a canonical, so Google chose a different page as the canonical — and this URL isn't indexed. and “Duplicate, Google chose different canonical than user” statuses, then eyeball the flagged URL pairs for case differences. GSC won’t label the cause as “casing” — it reports every duplicate cause the same way — so you have to spot the case-only pairs yourself.
  • Ahrefs Site Audit. A crawl surfaces near-duplicate URLs; casing differences show up as separate crawled URLs with identical or near-identical content, worth cross-checking under the duplicate-content reporting.
  • Screaming Frog. Export the full crawl, lowercase the URL column, and sort/filter to spot pairs that differ only in case. You can also test specific known paths in both casings to confirm server behavior — does /Apple return 200, 301, or 404? That single test tells you whether your server is case-insensitive (IIS-style 200), already enforcing lowercase (301), or case-sensitive with no variant (404).
TIP Verify what each case variant actually returns

A spot-check establishes whether a mixed-case path is live, redirected, or missing. It does not discover every variant, so pair it with a crawl export or log analysis.

Trace known case variants with my free Redirect Checker Free

  1. Test the canonical lowercase URL and the same path with one or more uppercase characters.
  2. Confirm any redirect lands directly on the lowercase HTTPS and preferred-host URL.
  3. After changing the rule, update internal links and rerun the variants to rule out chains or loops.

Where this sits

Case sensitivity is one axis in the broader duplicate-URL problem this cluster keeps circling — it compounds with trailing slashes, www vs non-www, and query parameters, and it’s one of the roughly 40 signals that feed canonicalization. The URL structureURL structure is how the parts of a web address — scheme, domain, path, query string, and fragment — are organized and formatted. It mostly affects crawling, usability, and how engines understand a page, not rankings directly. hub, the trailing slashA trailing slash is the forward slash (/) at the end of a URL — example.com/page/ versus example.com/page. Except at the bare root domain, the two versions are different URLs to search engines, so you pick one format and enforce it. and URL parametersThe `?key=value` data tacked onto the end of a URL after a question mark — used for tracking, sessions, filtering, sorting, and search — and one of the biggest sources of duplicate URLs and wasted crawling in SEO. deep dives, and the canonicalization article each cover their own axis; the discipline is identical across all of them — pick one clean version and enforce it with redirects, canonicals, consistent internal links, and matching sitemaps.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.