Why Google Indexes the Wrong URL

Google may show a URL you did not expect even when the page’s content is correct. It might index a tracking-parameter version, an older URL, or a duplicate page instead of the address you prefer. The cause is often a mismatch between canonical tags, redirects, internal links, and sitemap entries—or simply that Google has selected a different canonical URL. This guide explains how to diagnose the problem and make your preferred URL clearer to search engines.

Key takeaways

Google can choose a canonical URL; a rel="canonical" tag is a signal, not a guarantee.
Make redirects, canonical tags, internal links, and sitemap entries agree about the preferred URL.
URL parameters can create multiple addresses for similar content. Keep parameters that affect the page’s meaning or function.
Use Google Search Console’s URL Inspection report to compare the declared and Google-selected canonical URLs.
Clean URLs carefully: removing a meaningful parameter can change the destination or break functionality.

What “Google indexing the wrong URL” means

A single page can be reachable at multiple URLs. For example, these addresses may display the same article:

https://example.com/guides/canonical-tags
https://www.example.com/guides/canonical-tags
https://example.com/guides/canonical-tags?utm_source=newsletter

Google may treat such addresses as duplicates and select one URL as the canonical—the version it considers the representative page. If that choice differs from your preference, search results may display an unexpected URL. The page can still be indexed; the issue is which URL represents it.

First decide which URL should be canonical. Choose a stable, accessible address that returns the intended content, then check whether your site consistently points to it.

Diagnose the selected URL in Google Search Console

For an affected page, open the URL Inspection report in Google Search Console. Compare the user-declared canonical with the Google-selected canonical, and review the indexing status and any reported crawl information. The report can help distinguish a canonical-selection issue from a page that has not been indexed.

Then check the page and its alternatives:

Open the preferred URL and confirm it loads the intended page successfully.
Check whether alternate versions redirect, display the same content, or differ in meaningful ways.
Inspect the page’s HTML for a canonical link element.
Review links pointing to the page and the URLs listed in your sitemap.
Check whether a redirect changes the URL before the page loads.

Search Console reports what Google observed during its processing; changes may not appear in search results immediately. After making corrections, request a recrawl when appropriate and allow time for Google to revisit the page.

Canonical tags: tell Google which duplicate is preferred

A canonical link element identifies the preferred URL for a page with duplicate or substantially similar content. It belongs in the document’s <head> and should use the full preferred URL.

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

A page can also have a self-referencing canonical pointing to its own preferred URL. This can help make the intended version explicit, including for pages that have alternate URL forms.

A canonical is a hint, not a command. Google may select another URL if other signals suggest that another version is a better representative. Check for conflicting signals such as:

A canonical tag points to one URL, but internal links consistently point to another.
The sitemap lists a URL that redirects elsewhere.
The declared canonical is unavailable, blocked from crawling, or serves substantially different content.
Multiple canonical elements or different canonicals are emitted by templates and client-side code.

Use one consistent canonical per page. Ensure it matches the URL you want indexed and that the target is accessible and returns the intended content. A canonical tag is not a substitute for a redirect when a URL should no longer be used.

Parameters: separate tracking variants from meaningful pages

Parameters commonly appear after a question mark, as in ?utm_source=email. Some only record campaign information; others change what a user sees, such as a product filter, sort order, language, or pagination state. Do not assume every parameter can be removed safely.

For a tracking-only variant that displays the same page, you can generally signal the clean URL as canonical while preserving the tracking URL for analytics. Check that the page’s canonical does not include temporary tracking values and that internal links and sitemap entries use the clean address.

For a parameter that changes the page’s content or purpose, decide whether that version should be independently discoverable. If it should, it may need its own stable URL and canonical. If it should not, use an appropriate canonical strategy or other site-level controls. The right choice depends on the content and how users should find it.

A URL cleaner can help you inspect or remove obvious tracking parameters, but review the result before using it. Do not strip parameters that identify a product, filter results, select a language, or otherwise affect the destination. You can clean a URL as a quick check, but a cleaned link does not configure your site’s canonical tags or redirects.

Redirects: consolidate URLs that should no longer be separate

Use a server-side redirect when an old URL has permanently moved or should always resolve to a new address. A temporary redirect is more appropriate when the move is temporary. Redirects help users and crawlers reach the destination, but they should lead directly to the final URL rather than through a chain of intermediate addresses.

Check that:

The redirect destination is the intended canonical URL and returns a successful response.
The destination does not redirect back to the original URL, creating a loop.
Internal links and sitemap entries are updated to point directly to the destination.
You keep redirects in place for old URLs that may still receive visits or links, according to your site’s migration plan.

Do not redirect every duplicate page to the home page. A redirect should lead to a relevant replacement; if there is no equivalent replacement, choose a suitable response rather than sending visitors to unrelated content.

A practical URL troubleshooting workflow

Use this sequence for one affected page before applying a site-wide fix:

Choose the preferred URL. Decide on the scheme, hostname, path, and whether a trailing slash is part of your convention.
Inspect variants. Compare the preferred URL with versions using www, alternate schemes, trailing slashes, capitalization, or query parameters.
Check responses and redirects. Confirm each variant either serves the intended page or redirects to the preferred URL without a loop or unnecessary chain.
Inspect the rendered page. Find the canonical element in the final HTML and verify it points to the preferred URL. If a JavaScript framework changes metadata, inspect the rendered output too.
Align site signals. Update internal links and sitemap entries to use the preferred URL. Check that alternate pages do not declare conflicting canonicals.
Verify in Search Console. Inspect the preferred URL and compare the user-declared and Google-selected canonicals. Recheck after Google has had time to process the changes.

For a small site, a spreadsheet with the affected URL, preferred URL, redirect behavior, canonical value, and sitemap status can make inconsistencies easier to spot. For a large site, inspect representative templates and URL patterns, then validate the fixes across affected page types.

Common mistakes that keep the wrong URL in search

Canonical points to a URL that redirects

Make the canonical point directly to the final destination where possible. A canonical that names one address while the server immediately sends visitors elsewhere creates an avoidable conflict.

The page is blocked from crawling

If crawlers cannot access a page, they may be unable to read its canonical element. Check robots rules and access controls before assuming the tag was processed.

A `noindex` directive conflicts with the intended outcome

A page marked noindex is not a reliable choice for a URL you want indexed. Review page-level robots directives and response headers, and ensure the preferred URL is eligible for indexing.

Canonical tags are copied across every page

A template error can make many pages point to one unrelated canonical URL. Check several pages, not just the homepage, and verify that each canonical matches that page’s preferred version.

Internal links and sitemaps use alternate URLs

A correct canonical tag can be undermined by inconsistent site signals. Link to the preferred URL in navigation, content, and structured site data, and list the preferred versions in your sitemap.

Removing all query parameters

Some parameters are essential to a page’s function or content. Removing them indiscriminately can produce the wrong destination, break links, or change what visitors see. Identify what each parameter does before cleaning it.

A concise checklist

The preferred URL loads the intended page and is eligible for indexing.
Duplicate versions have a clear, consistent canonicalization or redirect strategy.
Canonical tags, internal links, and sitemap entries agree.
Redirects are relevant, direct, and free of loops.
Tracking parameters are distinguished from parameters that change content or behavior.
Search Console shows the preferred URL as the selected canonical after recrawling and processing.

Conclusion

When Google indexes an unexpected URL, start by identifying the preferred version and comparing it with the URL Google selected. Then align canonical tags, redirects, internal links, and sitemap entries, paying special attention to parameters that change the page. These signals help clarify your intent, but Google makes the final canonical selection. Verify the result in Search Console and allow time for the updated signals to be recrawled and processed.