Two case variants serve the same content
path_case_variant_duplicate · Issue
Both path spellings answered 200 with matching main content. Choose a consistent address and redirect the other spelling to it, or use a supported canonical between this pair.
Severity: Medium. Both addresses serve the same recorded main content without supported consolidation; the audit does not establish that Google indexed both.
Why it matters
Google describes canonicalization as choosing a representative URL among duplicate pages. This finding records a duplicate response pair; it does not measure a ranking loss.
What to do
- Read the two requested addresses and their recorded response/canonical evidence.
- Choose a consistent path spelling. Use a permanent redirect or a qualified canonical to the checked counterpart, and update internal links accordingly.
- Run a new full audit of the pair.
When to leave it as it is: Review before changing a case-sensitive route or an address intended for a distinct view. Content that only differs after scripts run needs a browser check.
What we read
We lowercase literal ASCII letters in the path of an observed address. Query spelling and percent-encoded bytes are preserved; we do not assume the observed spelling is uniquely intended.
We compare the two recorded requested addresses. Both must return direct HTTP 200 with complete server HTML and one complete, unique, nonempty main, role=main or article region. Their main-text hashes must match exactly after the existing whitespace and letter-case normalization.
The pair is not reported when a qualified canonical from either member points to the matching checked peer, whose canonical is absent or points to itself. Ambiguous, invalid or third-target canonicals and noindex scope exits remain unknown.
Already captured peers are reused. Additional path variants use the existing governed, robots-aware request budget, with at most 20 selected variant reads per site. Missing responses, partial HTML and content that needs browser execution are not clean comparisons.
Example & evidence
Illustrative example, not a live audit.
/Tea → 200, main text: Tea guide
/tea → 200, main text: Tea guide
No supported canonical consolidates the pair.Confirm & check again
Check for yourself: Open both recorded addresses, inspect their HTTP status and source canonicals, and compare their main content. Confirm the chosen redirect or canonical still lets visitors reach the intended page.
Check again: Full audit — Run a new full audit. The same two requested addresses must be checked. A qualified permanent 301 or 308 to the checked counterpart, a qualified 404 or 410 at one address with a checked peer, a supported canonical between the pair, or genuinely distinct complete main content can resolve the observation. Temporary redirects, missing peers, uncertain canonicals, noindex and insufficient coverage leave it unresolved.
Limits & sources
Only captured server responses are compared. Identical main text does not prove identical HTML, browser output, intended URL form or a Google indexing decision.
Confidence: High The response pair and exact normalized main-text equality are recorded; choosing the preferred address remains a site decision.
Sources
- Google, What is canonicalization — Explains canonical selection and duplicate pages. The literal path-pair and hash predicates are product policy. Checked 13 October 2026.
Editorial review: 2 November 2026