
/Blog/My-Post is 301'd to its lowercase form /blog/my-post. Having the rule is correct, because URL paths are case sensitive and you do not want both versions live. The real fix is to stop generating mixed-case links in the first place so the redirect rarely has to run.What a case redirect is
The path portion of a URL is case sensitive by spec. To a strict server, /Products/Shoes and /products/shoes are two different addresses, the same way two files with different capitalization are different files on a Linux disk. To avoid serving the same content at multiple casings, most sites add a rule that normalizes the path to lowercase with a 301. Request the mixed-case version, get redirected to the lowercase one, land on the real page. That redirect is the "case redirect" this check reports.
Only the path is affected. The scheme and host are case insensitive, so HTTPS://Example.com and https://example.com are already equivalent and do not need normalizing. Query string values may or may not be case sensitive depending on your app, so leave those alone unless you know better. The whole issue lives in the slug and folder names after the domain.
Why it matters, and why the rule is still right
Without normalization, capitalization variants become duplicate content. If /Blog/Guide and /blog/guide both return 200, Google can index both, split your link signals across them, and pick the wrong one as canonical. Internal analytics fragments, because the two paths log as separate pages. So you absolutely want a canonical casing, and lowercase is the sane default because it is predictable and it is what people type.
The catch is that the redirect is a patch, not a cure. Every time a visitor or a crawler hits a mixed-case link, they pay for an extra hop before the page loads. If your own site keeps emitting mixed-case internal links, or your sitemap lists them, you are routing your own traffic and Googlebot's crawl budget through that redirect on every request. The rule quietly does its job while the underlying sloppiness costs you a little speed on every affected click. Fix the source and the redirect goes back to being a rarely-used safety net, which is exactly what it should be.
Patch versus cure
How to detect it
- Screaming Frog: crawl, open Response Codes, filter to Redirection (3xx), and scan the Address and Redirect URL columns for pairs that differ only in casing. Frog also has a "URL" tab filter for "Uppercase" to list any internal links with capitals, which is how you find the source.
- curl:
curl -sI https://example.com/Some/Pathand check for a 301 whose Location is the lowercase equivalent. Quick spot check for a specific URL. - Search Console: the Pages report and URL Inspection show mixed-case URLs bucketed under "Page with redirect," which tells you Google discovered the capitalized form somewhere.
- Sitebulb: flags uppercase characters in URLs as a hint and separates internal links from the redirect rule, so you can prioritize the source fix.
- Server logs: grep the access log for 301s on paths containing uppercase letters to see how often the rule actually fires and from where.
Where the mixed-case URLs come from
| Source | Example | Fix at source |
|---|---|---|
| CMS slug generation | Title case kept in the slug | Force lowercase on slug save |
| Hand-coded internal links | Editor types /About-Us | Lowercase links in templates and content |
| Campaign and email URLs | Marketing shares /Summer-Sale | Publish lowercase canonical URLs |
| Sitemap generator | Sitemap lists capitalized paths | Emit final lowercase URLs only |
| Legacy migrated URLs | Old system used CamelCase paths | Update internal references to lowercase |
How to fix it, step by step
- Confirm a lowercase-normalization redirect exists and works. If it does not, add one, so any stray capitalized URL 301's to lowercase and you never serve duplicates. In Apache this is a
RewriteMaplowercase rule; in nginx you handle it in the location block or app; in a CMS a plugin or middleware can enforce it. - Pick lowercase as your one canonical casing and apply it everywhere, including the
rel=canonicaltag on every page. - Now attack the source. Set your CMS to lowercase slugs on save so new content cannot introduce the problem.
- Sweep existing internal links. Use the Frog uppercase filter to list mixed-case internal links and correct them in templates, navigation, and body content.
- Regenerate the XML sitemap so it lists only final lowercase URLs, and fix any capitalized paths in canonical tags and hreflang.
- Re-crawl and confirm your internal links resolve to 200 directly, with the case redirect firing only for external or old inbound links. That is the healthy end state.
Do and do not
- Keep a lowercase-normalization 301 as a safety net.
- Force lowercase slugs at creation in the CMS.
- Emit lowercase internal links everywhere.
- List only final lowercase URLs in your sitemap.
- Point rel=canonical at the lowercase form.
- Serve the same page at multiple casings with 200s.
- Rely on the redirect while shipping mixed-case links.
- Leave capitalized URLs sitting in your sitemap.
- Point canonical tags at a mixed-case URL.
- Chain a case redirect on top of another redirect.
What good looks like
Every internal link, sitemap entry, and canonical tag uses lowercase paths, so your own pages and Googlebot reach content in a single hop. The case-normalization rule still exists, but the logs show it firing only for the occasional external link or old bookmark. No capitalization duplicate is indexable, and no page returns 200 at two different casings. This is a low-severity item, but it is genuinely free to get right, and a clean URL set makes every other audit easier to read.
FAQ
Should URLs be lowercase or uppercase?
Are all URLs really case sensitive?
Does a case redirect hurt SEO?
Can I just delete the case redirect once links are lowercase?
How do I lowercase URLs in Apache?
RewriteMap lc int:tolower in the server config, then rewrite the path through it and 301 to the result when it differs from the request. Test carefully so you do not loop, and only redirect when the lowercased path is actually different.Claude Vincent is a technical SEO consultant focused on crawlability, rendering, and AI-search visibility. He writes the field guides and case studies at SEO ProCheck, with a bias toward the durable, unglamorous work that decides whether search engines and AI answer engines can actually read and cite a site.
About SEO ProCheck
Technical SEO consulting and GEO strategy with 20 years of enterprise experience. Case studies, resources, and tools for search and AI visibility.
Work With Me
Technical SEO audits, GEO strategy, site migrations, and international SEO. Hourly consulting for teams who need hands-on support, not just reports.







