How to Fix Duplicate URLs and Canonical Issues

Duplicate URLs are the same page reachable at more than one address. Search engines treat each address as a separate page unless you tell them otherwise, which splits your ranking signals and wastes crawl budget. This guide shows how to find them, pick one canonical address, and consolidate everything else with redirects and canonical tags. The examples use WizeTool's own case, because it had exactly this problem.

If you want to check a single page for canonical and indexability issues, run it through the SEO Optimizer. It reports the canonical tag, robots directives, redirect chain and indexability status it observes.

Why duplicate URLs happen

Most sites accumulate duplicates without noticing. Common sources:

  • Protocol and host variants. http://example.com/, https://example.com/, https://www.example.com/ all serve the same content.
  • Trailing slash. /about and /about/ are often both valid.
  • Query parameters. /product?id=123&color=red and /product?color=red&id=123 are different URLs with the same content.
  • Case and default files. /About/ and /about/, or /index.html and /.
  • Renamed pages without redirects. /old-guide/ and /new-guide/ both resolve.
  • Printer-friendly or AMP variants. /page and /page?print=1.

Each variant can be indexed separately. Search Console then shows the same page under several addresses with scattered impressions and clicks.

How to find duplicates

Search Console shows duplicate problems as statuses, and each one means something specific. Here is what to look for and what to do:

Search Console statusWhat it meansWhat to do
Duplicate, Google chose different canonical than userGoogle picked a different canonical URL than the one you set.Accept Google's choice, or fix the signals so your preferred URL wins.
Duplicate without user-selected canonicalYou have not declared a canonical, so Google picked one.Add a self-referencing canonical tag to every page.
Duplicate, Google chose different canonical than user (non-canonical)A non-canonical variant is competing with your chosen URL.301 the variant to the canonical in one hop.
Alternate page with proper canonical tagA second page points its canonical at another page.Decide whether the second page should exist; if not, remove it or repoint it.
Submitted URL not found (404)A URL in your sitemap returns 404.Remove it from the sitemap or redirect it.
Crawled, currently not indexedGoogle crawled it but has not indexed it.Improve content quality and internal links, or remove the page.
  1. Search Console → Pages. Look for "Duplicate, Google chose different canonical than user" and "Duplicate without user-selected canonical". These are direct signals.
  2. Search Console → Performance. Filter by page and check whether the same content appears under several URLs.
  3. Site search. Search site:example.com and scan for repeated titles or near-identical snippets.
  4. Crawl your site. A crawler lists every URL it finds, which exposes parameters, casing and slash variants. The Dead Link Checker can crawl a site and report what it finds.
  5. Check redirects manually. Request each variant with curl -I and see where it goes.

Alternate page with proper canonical tag

An "alternate page with proper canonical tag" is a page whose <link rel="canonical"> points at a different page. The page itself is not the canonical — it defers to another URL. That is not necessarily an error; it is a deliberate signal. But it does mean the alternate page is a duplicate by definition, and its own authority will not accumulate.

Treat it as a decision point, not a permanent setup:

  • Keep both pages only when they are genuinely different. If the alternate has unique content worth ranking, give it its own canonical (self-referencing) instead of pointing at the other page.
  • Merge when the content overlaps. Fold the alternate into the canonical page, then 301 the alternate to the canonical.
  • Remove when it adds nothing. Delete the alternate page and 301 its URL to the canonical. Do not leave a page up that merely canonicalizes another page — it wastes crawl budget and can confuse which URL should rank.
  • Repoint when the target changes. If the canonical URL moves, update the alternate's canonical tag so it still points at the live page. A stale canonical pointing at a 404 or a redirect is worse than no canonical at all.

Check these in Search Console under the "Duplicate, Google chose different canonical than user" status, and in your crawl report by listing every page whose canonical URL differs from its own address.

Canonicalize your IP address

A site reachable by both an IP address and a domain name is a classic duplicate-host situation. https://192.0.2.1/ and https://example.com/ serve the same server, so search engines see two hosts. The IP address should never be the canonical — it is brittle, unbrandable, and rarely what you want to rank.

Canonicalizing the IP address means making the domain the single source of truth:

  • Set the canonical host. Declare example.com (or www.example.com) as the canonical host and use it in every canonical tag, sitemap entry, and internal link.
  • 301 the IP address. Configure your server or DNS so that requests to the raw IP address redirect in one hop to the equivalent page on the domain. For example, https://192.0.2.1/about/ → https://example.com/about/.
  • Block the IP from being indexed. If you cannot redirect the IP immediately, serve a noindex robots meta directive or a robots.txt disallow on the IP-served version so Google does not waste crawl budget on it.
  • Check what Google sees. Request the IP address directly with curl -I https://192.0.2.1/ and confirm the response is a redirect (or blocked), never a 200 that duplicates the site.
  • Watch for server-configured defaults. Some hosting panels respond to requests hitting the IP directly with a default site, which is why the duplicate appears in the first place. Verify that the default virtual host does not mirror your production content.

This is the same pattern as the www vs apex decision: pick one host, redirect the rest, and never let two hosts serve the same page.

Choose one canonical form

Pick one address and make everything else point to it. The usual choice:

  • HTTPS, not HTTP.
  • One host: apex (example.com) or www, consistently.
  • Trailing slash on every page.
  • Lowercase paths.
  • No query parameters in canonical URLs for content pages.

Write this down as a rule. Every redirect, canonical tag, sitemap entry and internal link should follow it.

Step 1: Redirect the variants

Set up 301 redirects so every non-canonical variant points to the canonical one in a single hop. No chains. The redirects you need at minimum:

  • http:// → https://
  • www. → apex (or the reverse, but pick one)
  • no trailing slash → trailing slash
  • retired URLs → their replacement
  • IP address → domain (see Canonicalize your IP address)

Verify each with curl -I. A correct redirect returns 301 Moved Permanently with a Location header pointing at the canonical URL, and no further hops.

Step 2: Add self-referencing canonical tags

Every page should declare its own canonical URL in the <head>:

<link rel="canonical" href="https://example.com/guides/your-guide/">

Even when there is only one version, the tag confirms which one is preferred. When duplicates exist, point all variants at the chosen canonical.

Internal links should use canonical URLs only. A link to /about that 301s to /about/ wastes a hop and can confuse crawlers. Audit your navigation, footer and in-content links.

Step 4: Clean up the sitemap

The sitemap should list only canonical URLs. Remove parameter variants, retired URLs and non-HTTPS addresses. Submit the cleaned sitemap in Search Console.

Step 5: Handle parameters

For pages where parameters change content (filters, pagination), either:

  • Give each meaningful variant its own canonical URL with distinct content, or
  • Canonicalize all variants to the base URL and use noindex on parameter pages you do not want indexed.

For pure tracking parameters (utm_source, fbclid), canonicalize to the clean URL.

WizeTool's own case

WizeTool had this exact problem: the same pages appeared under http, https, www and without a trailing slash, and /privacy competed with /privacy-policy. The fix was to choose https://wizetool.com/ with a trailing slash, 301-redirect every variant in one hop, and make every internal link and sitemap entry canonical. After consolidation, Search Console started attributing impressions to one URL per page instead of scattering them.

Common mistakes

  • Redirect chains. /a → /b → /c wastes crawl budget and dilutes signals. Always redirect straight to the final URL.
  • Canonical pointing to a redirect. The canonical URL should be the final, 200-status address.
  • Forgetting the sitemap. A sitemap full of non-canonical URLs keeps the duplicates alive.
  • Mixing signals. A canonical tag pointing one way while internal links point the other confuses search engines.

Checklist

  • One canonical form chosen and documented.
  • 301 redirects in place for protocol, host, slash, IP address and retired URLs.
  • Self-referencing canonical tag on every page.
  • Internal links use canonical URLs only.
  • Sitemap lists only canonical URLs.
  • Redirects verified with curl -I, no chains.
  • IP address redirects to the domain in one hop.

Where to go next

Run the SEO Optimizer on your most important page and check the canonical and indexability findings. For a broader review, read the on-page SEO checklist and How to Check On-Page SEO Manually in 10 Minutes. For the redirect side, see 301 vs 302 Redirects Explained. For the sitemap side, see XML Sitemaps: What They Do and Do Not Do. Google's consolidate duplicate URLs documentation covers the official guidance.

Try it on your own content

The SEO Optimizer checks content against these practices in seconds. Free and no sign-up; see the tool page for how analysis works.

Meet the SEO Optimizer