Case-sensitive URL paths: testing normalisation across CDN and origin

Mixed-case paths can behave differently at the CDN, application and origin. Learn how to diagnose URL identity, compare request states and roll out safe normalisation.

Requests for /Guide/ and /guide/ may look like minor variations of the same URL. In a production stack, they can pass through different routing rules, occupy separate CDN cache states, reach different origin resources or return different responses.

That makes mixed-case paths a cross-layer diagnostic problem. A canonical element may point to the preferred form while the CDN still caches both variants. The application may treat the paths as equivalent while a case-sensitive origin returns a 404. An edge redirect may look correct from the outside but never reach the origin, leaving an underlying routing problem undiscovered.

This methodology is designed to establish what is actually happening before a normalisation rule is deployed. It covers case variation in path segments only. It does not extend to hostnames, query parameters, trailing slashes or percent-encoded variants.

Separate URL identity from server behaviour

URI path components are generally treated as case-sensitive unless the relevant scheme or server defines different behaviour. In practical terms, /Guide/ and /guide/ should initially be treated as different URL inputs rather than assumed to be aliases.

That does not mean they necessarily represent different application resources. A framework may route both paths to the same controller. A reverse proxy may fold case before forwarding the request. A CDN may preserve the raw path in its cache key. An origin filesystem or router may distinguish the paths and return different content or a 404.

The first question is therefore not “which URL is canonical?” It is:

At each layer, does this path variant identify the same resource, a different resource, an alias or an error?

This distinction matters because URL equivalence is an observed outcome, while case sensitivity is a property of a particular component. Two variants can produce identical 200 responses and still occupy separate cache entries. They can return the same page with different canonical elements. They can redirect at the edge but return different responses when tested against an origin-representative environment.

The safest diagnostic treats the application, CDN and origin as separate systems that must be compared rather than inferred from one browser response.

Define the intended URL identity before testing

Normalisation should not begin with a global lowercasing rule. First establish which casing convention the site intends to use and whether any valid exceptions exist.

For many content and commerce sites, lowercase paths are the intended convention because URL generation, navigation and sitemap output already use them. That is a site decision, not a universal technical requirement. Some systems use case-sensitive identifiers or filenames. A global case-folding rule could make a valid route unreachable, redirect to the wrong resource or create a collision between two existing paths.

Create a route inventory that distinguishes at least:

• HTML page paths, including nested paths such as /Guide/Setup/;
• static assets such as JavaScript, CSS, images and fonts;
• feeds, downloads and other file-like endpoints;
• API routes and documented resource identifiers;
• health checks, callbacks and operational endpoints;
• known case-sensitive routes, filenames or identifiers;
• routes that already redirect, return 404 or vary by case.

For each route family, record the intended preferred form. The normalisation function should be idempotent: applying it to an already normalised path should produce no further redirect. If lowercase is selected, /guide/ should remain /guide/, while /Guide/ should redirect directly to it.

This inventory is often where the main risks become visible. A rule that appears safe for editorial URLs may be inappropriate for an API or file path.

Model the request across the stack

Trace one requested path through each processing layer:

1. Client request: the exact path sent by a crawler, browser, monitoring tool or other client.
2. CDN or edge: cache lookup, edge function, redirect rule, rewrite and cache-key construction.
3. Reverse proxy: host and path handling, rule ordering, upstream selection and forwarded path.
4. Application: framework routing, middleware, canonical generation and response creation.
5. Origin: web server, filesystem, upstream service or application server that ultimately handles the request.
6. Response path: status, headers, body, cache storage and any redirect returned to the client.

These layers can agree, disagree or hide one another. A CDN can serve a cached 200 without contacting the origin. An edge rule can return a redirect before application routing occurs. An application can generate a canonical link for /guide/ while the requested mixed-case path remains directly accessible. An origin can return a 404 even though the edge has a previously cached 200.

CDN cache keys commonly include the requested path. If the active configuration preserves the raw path, /Guide/ and /guide/ may occupy separate cache states. That is an inference about a particular configuration, not something provider defaults can establish. Confirm it through cache-key configuration, response headers, cache status and logs.

Build a request-state matrix

Do not test only the preferred URL and one mixed-case variant. Select representative paths that reveal how the rules behave at different depths and boundaries.

• /guide/ — the intended preferred path;
• /Guide/ — a case change in the first segment;
• /GUIDE/ — an upper-case variant;
• /guide/Setup/ — a case change in a nested segment;
• /Guide/Setup/ — changes in more than one segment;
• a known page that should return 404;
• a static asset with a case variation;
• a feed, download, API or other non-page endpoint;
• a path containing a valid case-sensitive exception, if one exists.

For every request, capture the complete response chain rather than just the final page. The minimum record should include:

• requested path and host;
• status code at every hop;
• every Location header;
• total redirect count and final URL;
• cache status, age and relevant cache-control headers;
• edge or CDN result, where exposed;
• origin status and whether the origin was contacted;
• canonical element in the final HTML, if present;
• final content title, key body markers and a body comparison;
• response headers that identify the serving layer or request ID.

Run the matrix from outside the CDN and, where operationally possible, against the origin or an origin-representative environment. Direct-origin testing must preserve the relevant host and forwarding headers. Otherwise, it may test a different virtual host or application route.

A simple classification helps turn the matrix into a decision:

• Convergent: every non-preferred variant reaches the preferred URL through one redirect and the origin confirms the same intended route.
• Equivalent but unnormalised: variants return the same content and status but remain separately accessible or separately cached.
• Layer divergence: the edge, application and origin disagree on status, body, redirect target or canonical output.
• Collision: two case forms identify different valid resources, or one form becomes unreachable under the proposed rule.
• Failure: a variant loops, drops a path segment, returns an unexpected 404 or exposes stale content.

Use each evidence source for the question it can answer

No single SEO signal proves cross-layer URL convergence. Treat internal links, sitemaps, canonicals and logs as independent evidence sources.

Internal links

Internal links show which URL forms the site is actively generating and recommending to users and crawlers. Extract links from templates, navigation, structured content, related-item modules and JavaScript-generated routes.

They can show that a mixed-case path is being created internally. They cannot prove that the CDN uses the same cache key, that the origin treats the path as equivalent or that a crawler has not discovered other variants externally.

Update URL generation so new links use the preferred casing. Correcting links is not a substitute for redirecting historical variants, but it reduces the creation of new mixed-case requests.

XML sitemaps

Sitemaps should contain the preferred URL form. They provide discovery and consistency evidence, but they do not demonstrate that a non-preferred case variant redirects, shares a cache state or reaches the same origin resource.

Canonical elements

Extract the canonical element from every tested response. A canonical pointing from /Guide/ to /guide/ is useful evidence of the page’s preferred identity. It does not prove that both requests are server-equivalent, use the same CDN cache key or reach the same application route.

Canonical signals should align with internal links and sitemap URLs. They should not be used to conceal unresolved routing or caching differences.

CDN and origin logs

Logs provide the evidence needed to determine whether a request reached the origin and what happened there. Correlate records using fields such as timestamp, request path, request ID, user agent, edge status, cache status, origin status and final response status where available.

Expect practical complications. CDN and origin logs may be delayed, incomplete or affected by internal subrequests. A request that appears absent from the origin log may have been served from cache or blocked at the edge. Timestamps may need alignment, and different systems may record the original path, rewritten path or both.

Use the logs to test specific hypotheses:

• Are mixed-case variants being requested by crawlers or users?
• Are they reaching the origin or being answered at the edge?
• Do they create distinct cache entries or repeated misses?
• Are origin 404s hidden by cached 200 responses?
• Does the same case variant produce different outcomes by region, user agent or cache state?

Design the normalisation policy

Once the evidence confirms the intended identity and valid exceptions, choose one authoritative enforcement point wherever possible. This may be the CDN edge, reverse proxy or application, depending on where the team can apply a reliable rule with adequate logging and rollback.

The policy should be:

• Scoped: it applies only to route families confirmed safe to normalise.
• Preserving: it keeps every valid path segment and does not alter unrelated parts of the request.
• Single-hop: a non-preferred path redirects directly to the final preferred URL.
• Idempotent: the preferred URL does not trigger another redirect.

Select the redirect status with the platform team. A permanent 301 or 308 may be appropriate, but method handling, existing infrastructure and compatibility constraints matter. The important behaviour is that the redirect is deliberate, direct and stable rather than a chain through several intermediate forms.

Before implementation, test rule ordering. A lowercasing rule can conflict with a route-specific redirect, a locale rule, an asset policy or an authentication boundary. Redirects that strip segments, change valid identifiers or apply page logic to APIs and assets are more dangerous than leaving a verified equivalent variant accessible temporarily.

Roll out in stages

Begin with a small, representative route cohort. Include a normal page, a nested path, a known 404, an asset and each important non-page endpoint. Do not rely solely on a development environment: case-insensitive local filesystems can hide failures that appear on a case-sensitive production origin.

Before enabling the redirect, update the URL generators, internal links, canonical elements and sitemap output. Then test:

• preferred URLs return the expected status without another redirect;
• mixed-case page variants redirect directly to the preferred path;
• redirect targets preserve every valid segment;
• there are no loops or rule-order conflicts;
• assets continue to load and are not redirected into HTML page logic;
• feeds, downloads, APIs and health checks follow their intended policy;
• CDN invalidation or expiry removes unsafe cached responses where necessary;
• the origin still receives and routes requests as expected;
• cache headers and cache keys behave consistently after deployment.

Expand the rollout only after the first cohort passes external and internal checks. Keep the previous configuration available for rollback, and record the exact rule version, propagation time and cache-purge action. CDN configuration changes may propagate at different speeds by region, so agreement from one location is not sufficient.

Common failure modes

Redirect loops

An edge rule may redirect to a lowercase path while an application rule redirects back to a preserved-case route, or two layers may apply different canonicalisation functions. Test the full chain from an external client and inspect each Location value.

Mixed-case cache fragmentation

If the raw path remains part of the cache key, each case variant can create a separate cache state. This may cause repeated misses, inconsistent freshness or different responses during a deployment. A redirect policy reduces new variants, but existing cache objects may require controlled invalidation.

Origin 404s hidden by the edge

A cached 200 can make an origin 404 invisible. Compare cache status and origin logs, and test after cache expiry or purge. Do not conclude that the origin supports a path based on one edge response.

Case-colliding routes

Two valid routes may differ only by case, particularly where identifiers or filenames are meaningful. Global lowercasing can redirect one resource onto another. Collision testing must happen before the rule is made broad.

Rule-order conflicts

Case normalisation can interact with locale prefixes, authentication, file handling and application rewrites. A rule that works for /Guide/ may alter the intended processing of /api/Guide/ or a signed download path.

False confidence from SEO signals

A consistent canonical and sitemap entry can coexist with separate cache keys and inconsistent origin behaviour. Conversely, Google may cluster accessible variants and select the intended canonical without measurable ranking loss. The defensible reason to normalise is control, consistency and observability. Site-specific search impact must be measured rather than assumed.

Validate after release

Post-release validation should combine several forms of evidence over a defined observation window.

• Run a sampled crawl of preferred and historical mixed-case variants.
• Check status codes, redirect counts, targets and canonical output.
• Review CDN logs for edge responses, cache hits, misses and unexpected variants.
• Review origin logs for 404s, unexpected routes and requests that should have been handled at the edge.
• Monitor redirect volume and identify loops, chains or altered path segments.
• Recheck internal links, sitemap URLs and generated canonical elements.
• Test assets, feeds, downloads, APIs and operational endpoints separately.
• Use Search Console or indexation observations where available, while allowing for sampling and reporting delay.

Compare the results with the pre-release baseline. The most useful measures are not simply the number of redirects. Look for fewer internally generated mixed-case requests, stable preferred URLs, fewer unexpected origin errors, consistent cache behaviour and no new endpoint failures.

Conclusion

Mixed-case URL paths should be diagnosed as a URL-identity convergence problem across the application, CDN and origin. The important distinction is between what a URL string looks like, what each server layer does with it and what search engines may infer from the resulting signals.

A request matrix establishes the observable differences. Correlated edge and origin logs explain where those differences arise. Internal links, sitemaps and canonicals help align the preferred form, but none replaces direct server testing.

Only after route collisions and valid exceptions are understood should normalisation be deployed. Use one casing convention, generate it consistently, redirect non-preferred variants in a single hop and validate cache, routing and non-page behaviour in stages. That approach treats the problem as an infrastructure change with SEO consequences, rather than as a canonical-element adjustment alone.

For a related reverse-proxy investigation, see how to trace wrong SEO hostnames through a reverse proxy.