Why Google Indexes the Wrong URL: Canonicals, Parameters, and Redirects

Google can show an unexpected version of a page in search results: a URL with tracking parameters, a different hostname, or a duplicate page you meant to consolidate. This can happen even when your site has a canonical tag. Google chooses which URL to index based on the signals it can discover, and those signals may conflict or be unclear. This guide explains how to diagnose the mismatch and make your preferred URL clearer without accidentally redirecting visitors or hiding useful pages.

Key takeaways

• A canonical tag is a hint, not a command. Google may select a different canonical URL.
• Redirects, canonical tags, internal links, and sitemap entries should consistently point to the version you want indexed.
• Query parameters are not automatically bad: some change page content or functionality, while others only track visits.
• Use Search Console to compare your declared canonical with Google's selected canonical and check the indexed URL.
• Do not block a duplicate URL from crawling before Google can see the canonical or redirect that consolidates it.

How Google chooses which URL to index

A website may serve the same or substantially similar page at multiple URLs. For example, these URLs might show the same article:

• https://example.com/guides/canonicals
• https://www.example.com/guides/canonicals/
• https://example.com/guides/canonicals?utm_source=newsletter

Google groups duplicate or very similar pages and selects a canonical URL to represent them in search. Its selection can differ from the URL a site owner declares. Canonicalization helps consolidate signals and reduce duplicate versions in search results; it does not guarantee that every duplicate URL disappears immediately.

Google can use several signals to determine the preferred version. These include redirects, rel="canonical" annotations, internal links, and sitemap entries. When signals disagree, the preferred URL is less clear. A canonical tag that points to one URL while internal links and redirects favor another may not produce the result you expect.

Diagnose the wrong URL in Google Search Console

Start with the exact URL shown in search results and the URL you want indexed. Then inspect both in Google Search Console:

1. Open URL Inspection and enter the URL Google is showing.
2. Review the indexing information, including the user-declared canonical and Google's selected canonical, when available.
3. Inspect the preferred URL separately. Check whether it is indexable and whether Google can access it.
4. Use the live test to check what Google can fetch now. A live test does not replace the indexed-version report: the two can differ because Google's stored information may not yet reflect recent changes.
5. Check the page's response, robots directives, and rendered HTML. Confirm that the canonical is present where intended and points to the correct, accessible URL.

If Google has selected another canonical, compare the two pages and their signals rather than changing the tag repeatedly. The alternative may be a genuine duplicate, an older URL receiving stronger internal links, or a version that Google can crawl while the preferred one is blocked or unavailable.

Make canonical signals consistent

Use a canonical tag for duplicate pages that should remain accessible

If multiple URLs need to load for visitors but should be represented by one preferred URL in search, place a canonical link in the page's HTML head. Use an absolute URL and make sure it points to the preferred page, not a redirecting or error URL.

<head>
  <link rel="canonical" href="https://example.com/guides/canonicals">
</head>

The canonical target should be accessible, indexable, and a close match for the duplicate page. A self-referencing canonical on the preferred page can make your intent clearer, though it does not guarantee Google's selection. Avoid specifying multiple conflicting canonical elements or pointing unrelated pages at one destination.

Redirect URLs when visitors should use one version

If an old URL has been permanently replaced and should no longer serve its former page, use a permanent server-side redirect to the final destination. Redirects are often a clearer choice than leaving two equivalent pages available. Use a temporary redirect only when the move is genuinely temporary.

Keep redirects direct: send each old URL to its final destination rather than creating a chain. Check that there are no loops and that the destination returns a successful response. Do not redirect unrelated pages to a homepage simply to remove them from search; the destination should make sense for the original URL.

Align links and sitemaps

Update internal links so they point directly to the preferred URL. Include the preferred version, rather than its duplicates, in your sitemap. These changes reinforce the intended URL and help visitors and crawlers encounter a consistent address.

If you are unsure which parts of a URL differ, you can clean and inspect URL parameters to compare versions. Treat the result as an aid to review: removing a parameter is only appropriate if that parameter is not needed to identify or serve the intended page.

Handle query parameters carefully

Parameters such as utm_source or utm_campaign are commonly used for campaign measurement and may leave the page content unchanged. Other parameters can change the page, such as a product filter, sort order, language, pagination, or search query. Do not assume that every parameter should be removed or canonicalized to the same URL.

For tracking-only variants, decide which clean URL represents the page and use consistent canonical, internal-link, and sitemap signals. Keep tracking parameters on links when analytics requires them; the page can still declare its preferred canonical separately. For parameters that produce meaningfully different content, consider whether each variant should be indexable and useful as a search landing page before consolidating it.

A URL-cleaning tool can show how query strings differ, but it cannot determine the correct indexing policy for your site. Test parameter behavior on the actual page, and avoid removing values that are needed for navigation, filtering, attribution, or application functionality.

A practical troubleshooting workflow

Use this sequence when Google indexes the wrong URL:

1. Write down the preferred URL. Decide on the protocol, hostname, path format, and whether a trailing slash is part of your convention.
2. Compare the pages. Confirm whether the indexed URL and preferred URL are duplicates or serve different content.
3. Choose the right consolidation method. Use a canonical for accessible duplicate pages; use a permanent redirect when the old URL should send visitors to a replacement.
4. Check technical accessibility. Make sure the preferred page returns the intended successful response and is not blocked from crawling or marked noindex unintentionally.
5. Unify signals. Update canonical tags, internal links, redirects, and sitemap entries so they agree.
6. Validate both URLs. Inspect the old and preferred URLs in Search Console. Fix errors before requesting recrawling or indexing for the preferred URL.
7. Allow time for recrawling. A change to your site does not instantly update Google's indexed results. Recheck the indexed information after Google has revisited the pages.

Common mistakes and pitfalls

• Expecting a canonical tag to force indexing. Google may select another URL when its other signals or page assessment point elsewhere.
• Canonicalizing pages with substantially different content. A canonical is for duplicates or very similar pages, not a way to make unrelated URLs share one search result.
• Blocking duplicate URLs in robots.txt too early. If Google cannot crawl a page, it may not be able to see its canonical tag or page-level noindex directive. Use a suitable consolidation method and make sure crawlers can access the signals they need.
• Using noindex as a substitute for canonicalization. noindex asks that a page not be indexed; it does not identify the preferred duplicate URL. Choose the directive that matches your goal.
• Redirecting every variant without checking functionality. Some parameters are necessary for the page to work or represent distinct content. Test redirects with real use cases before deployment.
• Leaving conflicting references in the site. A correct canonical may be undermined by links or sitemap entries that consistently promote another URL.
• Changing several URL rules at once. Make controlled changes and test representative pages, including parameterized pages, before applying rules site-wide.

Recommendations for site owners and developers

Document your preferred URL format and apply it consistently across templates and routing rules. Generate canonical tags from the final, intended page URL rather than copying the current request URL wholesale; otherwise tracking parameters or alternate hostnames may leak into canonicals. Test redirects and canonical output on a small set of representative pages before broad deployment.

Keep a distinction between normalization and content identity. Lowercasing a path, removing a trailing slash, or stripping a query parameter is safe only when your server treats those versions as equivalent. For application pages, verify that URL changes do not break navigation, analytics, or user-selected state.

Conclusion

When Google indexes the wrong URL, the cause is often a mismatch among the site's preferred URL, its canonical tags, redirects, internal links, sitemap, or crawlability. Compare Google's selected canonical with your intended URL, decide whether duplicates should remain accessible, and align the signals accordingly. Then validate the result in Search Console and allow time for Google to recrawl the updated pages.