Should you really remove canonical tags from pages that are 301 redirected?

What does this statement from Google really mean?

A 301 redirect is a permanent instruction indicating that the original URL has moved permanently. Googlebot receives this signal at the HTTP level, even before parsing the HTML of the page.

The canonical tag, on the other hand, is a suggestion inserted in the HTML to indicate which version of a piece of content should be indexed. Google reads it after fetching the document and may choose to ignore it if conflicting signals exist.

When a 301 is in place, the bot never accesses the content of the source page: it immediately follows the redirect. The HTML of the redirected page is therefore never crawled or analyzed, which makes any tags present in this HTML completely invisible to Google.

Why do some SEOs still add a canonical tag?

Out of ignorance or over-caution. Some imagine that stacking 301 and canonical strengthens the signal, like a double safety. Others believe they are covering the case where the 301 might be misconfigured or ignored.

In reality, if the 301 is functioning correctly, the canonical tag will never be read. If the 301 malfunctions (misconfigured, server returning a 200 instead of a 301), then the canonical can serve as a safety net, but the real issue remains the faulty 301 that needs fixing, not masking.

When is the canonical tag still relevant?

The canonical tag remains meaningful for duplicate content accessible under multiple URLs that all stay active (sort variants, filters, session parameters). In these cases, there’s no 301: all URLs return a 200 and the content is crawlable.

The canonical then indicates to Google which version to prioritize for indexing. It serves as a consolidation signal without HTTP redirection, useful when wanting to keep multiple active URLs for UX while avoiding dilution of indexing.

• 301 redirect: permanent HTTP signal, prevents crawling of source HTML, transfers indexing and authority
• Canonical tag: HTML suggestion for accessible duplicate content, read only if the page returns a 200
• Redundancy: adding a canonical tag on a 301 page is unnecessary since the HTML is never crawled
• Use case: the canonical shines when multiple active URLs (200) point to the same content, without redirection
• Diagnosis: if you find a canonical on a redirected page, it’s probably a technical oversight with no negative consequence, just unnecessary

Is this statement consistent with field observations?

Yes, and it’s even a welcome reminder. In the field, we regularly see sites stacking 301 and canonical by default, often because a CMS or SEO plugin systematically inserts a canonical, even on redirected pages. Google does not penalize this redundancy; it simply ignores it.

The real question is not whether it’s harmful (it’s not), but to understand that it is technically unnecessary and sometimes indicates a misunderstanding of signal priorities. The 301 is a strong signal, at the protocol level, whereas the canonical is a weaker HTML hint.

What nuances should be added to this rule?

First point: if your 301 is faulty (server returns a 200, or poorly configured redirect chain), then the canonical can indeed be read and serve as a temporary workaround. But this is not a solution: fixing the 301 remains the priority. [To be checked] on your own sites if 301s that are supposed to be active are actually returning a 200 due to a bad server configuration.

Second nuance: in the context of a multi-phase migration, some temporarily leave the canonical in place before switching to a definitive 301. This is an acceptable transitional approach, but this step should be documented to prevent it from becoming permanent due to oversight.

Third point: JavaScript or meta refresh redirects (not recommended) can coexist with a canonical if they are poorly implemented and the HTML is still crawled. But again, the real issue is the use of these weak redirect methods instead of a clean 301 at the server level.

In what situations could this rule be bypassed?

Let’s be honest: there is no legitimate case where it would be beneficial to intentionally add a canonical tag on a 301 redirected page. If you find this configuration on a site, it’s either a remnant of an outdated strategy or an unfiltered automatic generation by the CMS.

The only scenario where this redundancy may persist without an urgent need for correction is when the site is technically sound, the 301 is working, and removing the canonical would require significant template refactoring for no gain. In this case, let it go and focus on higher-impact SEO projects. Google will ignore it anyway.

What should you do concretely on an existing site?

Start with a redirect audit. List all the URLs in 301 and check if they still contain a canonical tag in their source HTML (even if Google doesn’t read it). This is not critical, but often reveals improperly configured CMS templates or overly zealous SEO plugins.

If you manage a modern CMS or framework, ensure that redirected pages do not even generate complete HTML: a properly implemented 301 at the server level (Nginx, Apache, CDN) circumvents page generation. This saves server resources and speeds up response time for both the bot and the user.

For large e-commerce or editorial sites, this check can quickly become complex. Tools like Screaming Frog or OnCrawl can help detect pages in 301 that still carry a canonical, but interpreting the results and prioritizing fixes requires solid expertise.

What mistakes to avoid during a migration or redesign?

Classic mistake: switching all old URLs to 301 without removing the old canonicals inserted in templates. The result: new pages are indexed correctly (the 301 does the job), but the source code of the old redirected URLs remains cluttered with unnecessary tags. No negative SEO impact, just a lack of technical diligence.

Another trap: confusing canonical and hreflang. Some international sites stack 301, canonical, AND hreflang on migrated pages. The 301 always takes precedence, but this accumulation of signals can complicate diagnosis in case of indexing issues. Simplify the signal stack: a clean 301 is enough.

Third mistake: testing redirects only in the browser. A modern browser silently follows 301s, so you never see the source HTML of the redirected page. Use curl, an SEO audit tool, or the network DevTools to verify that the server returns a 301 status code and not a 200 with a JS redirect.

How to check if your configuration is optimal?

Use the Search Console to pinpoint URLs flagged as redirected but still generating indexing errors or canonical warnings. If you see inconsistent messages (canonical pointing to a different URL than the destination of the 301), it’s a sign of a server or CMS configuration that needs to be revisited.

Test a sample of redirected URLs with a SEO crawler configured to follow redirects and extract canonicals. If canonicals appear in the source HTML of pages in 301, document them without panicking: it's not blocking, but indicates technical debt to clean up during the next refactoring.

• Audit 301 URLs to check for the residual presence of canonical tags in their source HTML
• Verify that the 301s are properly implemented at the server level (Apache, Nginx, CDN) and return an HTTP 301 status code, not a 200 with a JS redirect
• Clean CMS templates to avoid automatic insertion of canonicals on pages meant to be redirected
• Test a sample of URLs using curl or a crawler to confirm the status code and absence of HTML crawled by Google
• Document instances of coexistence of 301 and canonical during gradual migrations, with a plan for cleanup post-migration
• Prioritize fixing faulty 301s over adding temporary canonicals