Alternate Page With Proper Canonical Tag: Crawl Budget and SEO

“Alternate page with proper canonical tag” is not an error. Google is telling you it found a duplicate URL, read the canonical tag on it and indexed the page the tag pointed to instead. The system worked. So why bother? Because every URL in that report is a page Google chose to crawl instead of one you want ranked. When the count climbs into the thousands, it signals wasted crawl budget, mixed signals about which pages matter and, on WooCommerce stores, real load on the server.

The video walks through this report on several live sites, including a WooCommerce store with close to 2,500 URLs listed, and shows the robots.txt rules used to clean it up. The notes below focus on why it matters for search and how to tell whether the fix has worked.

One topic, one page, one URL

The underlying SEO rule is simple: to rank for something you need a page for it, and only one page. A dentist who wants to rank for teeth whitening needs a teeth whitening page. With none, there is nothing to rank. With two, Google has to choose between them, the ranking signals are split, and both tend to rank poorly. That is duplicate content.

The catch is that one page can load at many addresses. Uppercase and lowercase letters, a trailing slash or none, and query strings added to the end all count as different URLs. The canonical tag solves this by naming the single URL that should rank. Add ?utm_source=newsletter to a page and the address changes, but the canonical still points to the clean URL, so Google knows which version to index.

Check this report in the domain property in Search Console, not a URL-prefix property. The domain property covers http, https, www and non-www together, so it shows every affected URL in one place.

Why the report keeps growing

The video notes that Google appears to be crawling sites far more aggressively than it used to, and this section of the Pages report has grown on many sites as a result. Each URL in it is a crawl spent on a duplicate. On a small brochure site that is trivial. On a store with thousands of product variations it means Google spends its time on junk, and gets mixed signals about which pages deserve attention.

Where the duplicates come from

WooCommerce cart and attribute URLs

Add-to-cart links are the most common culprit. When Googlebot follows one, the store adds the product to a cart and reloads the page. On some sites Google is adding and removing items several times a second, which chews up server resources as well as crawl time. Product attribute URLs (such as a pack size or colour selection) and wishlist links do the same on a smaller scale.

Search result pages

WordPress search can load at ?s=term or /search/term/. These pages should never be indexed, and they are a known negative SEO vector: a malicious crawler generates thousands of search URLs, Google discovers them, burns its crawl budget on them, and the site starts to look like spam.

Login redirects

Where content is protected, crawlers are often redirected to wp-login.php, which then gets crawled over and over. The video shows this happening on a live site.

Marketing parameters

UTM tags, Facebook’s fbclid and affiliate strings create a new URL for every tagged link. One or two are harmless. Hundreds are not.

Genuine mistakes

A canonical tag set manually and set wrong points Google at the wrong URL. In the video, one page had a canonical containing a capital letter while the real URL was lowercase, which counts as a different address. Older sites that still load over both http and https, or with and without www, produce the same symptoms. Choose one version, redirect everything else to it, and enable HSTS.

The fix: tell Google what not to crawl

For query strings and search pages, block crawling in robots.txt. Use wildcards rather than starting a rule with a question mark, because a parameter does not always come first in the query string. A starting point for a WooCommerce site:

User-agent: *
Disallow: /wp-login.php
Disallow: /search/
Disallow: *?s=*
Disallow: *add-to-cart=*
Disallow: *attribute_*
Disallow: *utm_*
Disallow: *fbclid=*

Adjust it to your site, and before publishing make sure no real page URL contains any of these strings.

Then open Settings, Crawl stats. It shows requests that never appear in the Pages report because they are not full pages: .well-known paths, JSON URLs and the cart fragment refresh requests WooCommerce uses to update the header cart. Several of these are worth blocking for the same reason: they burn crawl time and hit the hosting without adding anything to search.

Validating the fix

Once the rules are live, open the report and click Validate fix. If the rules work, URLs move out of “Alternate page with proper canonical tag” and into “Blocked by robots.txt”. That is the expected outcome, not a new problem: the Pages report lists reasons pages are not indexed, and you do not want these indexed. Do not expect the entries to disappear quickly. The video points out it can take months, sometimes years, for them to clear entirely.

How to tell it is working

• The count in this report falls as URLs shift into “Blocked by robots.txt”.
• Crawl stats show a larger share of requests going to real pages and fewer to cart, search and parameter URLs.
• On WooCommerce stores, server logs show fewer bot hits on add-to-cart and cart fragment URLs.
• In the Performance report, the intended URL is the one earning impressions for each target term, rather than several variations sharing them.

Keep a dated note of the robots.txt change. When someone later asks why “Blocked by robots.txt” jumped, the answer is already written down.