Google’s “Alternate page with proper canonical tag” message means Google found a URL that points to another URL as its preferred version. In most cases, Google is intentionally excluding the alternate URL and indexing the canonical one.
In this guide
The status becomes a problem when Google chooses the wrong canonical URL, the canonical page is inaccessible, or important content is being excluded accidentally. This guide shows how to investigate the report without deleting pages or adding random redirects.
What “alternate page with proper canonical tag” means
A canonical tag is an HTML link that tells search engines which URL represents the primary version of substantially similar pages. It looks like this:
<link rel="canonical" href="https://example.com/preferred-page/">
Google may classify a URL as an alternate when it is a duplicate or variation of another URL and contains a valid canonical pointing to the preferred version. Common examples include:
- HTTP and HTTPS versions of the same page.
- URLs with tracking parameters such as
?utm_source=newsletter. - Several URL formats created by filters, searches, or sorting controls.
- Attachment, print, feed, or archive URLs that repeat page content.
- A trailing-slash and non-trailing-slash variation.
- Product or post URLs accessible through more than one site path.
This is different from a missing canonical tag or a canonical that points to an unrelated page. The word proper indicates that Google believes the alternate URL’s canonical is valid, although you should still confirm that the selected page is correct.
Decide whether the status needs a fix
Do not try to make every URL indexable. A site can contain many useful URLs that should not appear separately in search results. First decide whether the reported URL is supposed to have its own search presence.
No fix is usually needed when:
- The reported URL is a duplicate of the canonical page.
- The canonical page loads successfully with a
200status. - The canonical page contains the same primary content.
- The alternate URL is created by tracking, filtering, or another intentional variation.
- Internal links and your XML sitemap use the preferred URL.
Investigate further when:
- A valuable article, product, or landing page is treated as an alternate.
- The canonical points to a different topic, language, or product.
- The canonical URL redirects repeatedly, returns an error, or is blocked.
- The page has unique content that should be indexed independently.
- Different pages all declare the same canonical because of a theme or plugin mistake.
If you are seeing broader duplicate-URL behavior rather than this specific status, compare the symptoms with our guide to fixing broken canonical tags and duplicate URL issues.
Check the reported URL in WordPress and Google
Open the URL inspection tool for the exact address shown in the report. Inspect both the reported URL and the URL Google identifies as canonical. Record the differences, including protocol, hostname, path, capitalization, query parameters, and trailing slash.

- Confirm the page is real. Open the reported URL in a private browser window and make sure it does not require an administrator session.
- Inspect the source. View the page source and search for
rel="canonical". A browser inspector can show the live DOM, but source code is useful for identifying what WordPress initially sent. - Compare canonical values. The canonical should normally be an absolute URL using the site’s preferred HTTPS hostname.
- Test the canonical destination. It should resolve to the intended page, not a login screen, 404 page, unrelated article, or redirect chain.
- Review Google’s selected canonical. Google may choose a different canonical from the one declared by the site. Treat that difference as a signal to investigate content, links, redirects, and accessibility.
For background on how to manage WordPress safely while troubleshooting, use the official WordPress Documentation.
Fix the most common WordPress causes
1. A duplicate URL is intentionally canonicalized
If the alternate URL is only a tracking or filtered variation, leave the canonical relationship in place. Remove accidental internal links to the variation and use the preferred URL in menus, content, breadcrumbs, and XML sitemaps.
2. WordPress has the wrong site URL
Go to Settings → General and compare WordPress Address (URL) with Site Address (URL). They should reflect the correct HTTPS domain. Do not change these values casually on a live site; an incorrect change can make the dashboard inaccessible.
If the values are controlled in wp-config.php, look for definitions such as:
define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );
Only use the real preferred domain, and preserve the existing formatting. Ask your host or a WordPress professional for help if the site uses a reverse proxy, CDN, or unusual multisite setup.
3. An SEO plugin or theme outputs conflicting canonicals
Canonical tags should generally be generated by one clear system. Multiple SEO plugins, a theme function, custom code, or a migration tool can produce competing values. Temporarily identify which component outputs each tag, then disable or remove the duplicate source after taking a backup.
Do not solve this by manually inserting another canonical into every post. That can create the multiple-canonical problem you are trying to prevent.
4. A unique page inherits a canonical from a template
Some custom post types or theme templates mistakenly canonicalize every item to an archive, parent page, or homepage. Review the template and the SEO plugin’s post-type settings. A unique, indexable page should normally canonicalize to its own final URL.
5. The preferred URL is not accessible
Make sure the canonical page is not blocked by a password prompt, firewall rule, accidental noindex directive, or robots configuration. Check the page while logged out and test it from a normal external connection. If the canonical destination is unavailable, fix that destination before requesting validation.

Use redirects only when URLs should permanently merge
A canonical tag and a redirect serve different purposes. Use a permanent redirect when the old URL should no longer be visited and there is one clear replacement. Keep the page accessible with a canonical when users may still need the alternate URL, such as a tracked campaign address or a useful filtered experience.
Avoid redirect chains. Redirect the old URL directly to the final preferred URL, and ensure internal links already use the final address. If HTTPS or proxy changes are involved, see our guide to WordPress redirect problems after SSL or Cloudflare changes.
Clean up internal signals
Google uses more than the canonical tag when selecting a URL. Make the site’s signals consistent:
- Link internally to the preferred URL.
- Use the preferred URL in the XML sitemap.
- Use one consistent HTTPS hostname.
- Update menus, breadcrumbs, pagination, and image links after a migration.
- Remove accidental links containing tracking parameters where tracking is unnecessary.
- Keep the title, main content, structured data, and language information appropriate for the canonical page.
Do not block a duplicate URL in robots.txt as a substitute for canonicalization. If Google cannot crawl the page, it may be unable to see the canonical relationship.
Validate the correction safely
- Clear the relevant page, plugin, server, and CDN caches.
- Recheck the page source as a logged-out visitor.
- Confirm that the canonical URL resolves directly and successfully.
- Inspect the URL again in Google’s URL inspection tool.
- Request validation only after the underlying issue is corrected.
Validation is not an instant indexing command. Google may recrawl the URLs later, and its selected canonical can differ when pages remain very similar or conflicting signals persist.
If the page still shows as an alternate after the fix, compare the content and internal-link patterns of both URLs. The status may be accurate even when the declared canonical is technically valid.
When to get professional help
Get assistance before making database-wide URL replacements if the issue affects a migration, multisite network, WooCommerce catalog, multilingual setup, or hundreds of pages. Broad search-and-replace changes can break media, links, redirects, and serialized WordPress data.
For a site-wide canonical or URL-selection problem, WordPress Site Repair can be a practical next step. If the symptoms appeared after a hack or unexpected redirect, treat that as a security incident rather than only an indexing issue.
Quick checklist
- Identify whether the alternate URL is intentionally duplicated.
- Check the canonical tag in the page source.
- Test the canonical destination while logged out.
- Look for plugin, theme, migration, and site-URL conflicts.
- Keep internal links and sitemaps consistent.
- Use redirects only when the old URL should permanently resolve elsewhere.
- Clear caches and validate after the technical correction.
In short, “Alternate page with proper canonical tag” is often an informational status, not an error. Fix it only when Google is excluding a page that deserves its own indexable URL or when the declared canonical does not represent the page correctly.



