Canonical Tags After a Rebuild: The Silent Rankings Killer Nobody Checks

Q: How do I check canonical tags on a Next.js site?

The most reliable method is to fetch the raw HTML with `curl -s https://your-domain.com/your-page/ | grep -i canonical`. This shows the canonical tag as it appears in the server-rendered HTML response — exactly what Googlebot reads. Avoid checking canonical tags only through browser dev tools, as JavaScript-side modifications may not be visible to Googlebot during its initial crawl.

Broken redirects get flagged. Missing title tags are obvious in a crawl report. But canonical tag errors after a CMS rebuild? Those fail silently. There is no immediate alert, no dramatic traffic cliff on launch day. Instead, rankings slip gradually over weeks and months as Google consolidates ranking signals to the wrong URLs — often the old WordPress URLs that no longer exist, or duplicate versions of pages that should be unified under a single canonical.

By the time the traffic loss is visible in Search Console, the damage has been accumulating for weeks. And because canonical errors are not always obvious in a quick page-source check, they often get missed in even thorough pre-launch QA.

This guide covers exactly what canonical tags do, the five specific error patterns that appear most often in CMS rebuilds, how to audit them before and after launch, and a checklist you can work through on your own site right now. If you are preparing a WordPress to Next.js migration or have recently completed one, the full SEO migration checklist pairs directly with this post as part of a complete pre-launch verification process.

Quick Checklist

Every page must have a self-referencing canonical tag pointing to its own URL
Canonical URLs must use the exact same protocol and domain (https://seoparity.com, not http://)
Canonicals must point to indexable, 200-status pages (never to redirects or 404s)
Crawl both WordPress and Next.js staging — compare canonical tags line by line
Check that paginated pages use rel=canonical correctly (not all pointing to page 1)
Verify canonical tags in server-rendered HTML (not just client-side JS)

What Canonical Tags Actually Do (and Why Google Trusts Them)

The rel=canonical tag is a signal — not a directive — that tells Google which URL should be treated as the authoritative version of a page's content. When Google encounters a canonical tag, it uses it as a strong hint to consolidate indexing signals: PageRank, backlinks, and crawl priority are attributed to the canonical URL, not to the URL that was actually requested.

According to Google's documentation on canonical tags, Google respects canonical tags in the vast majority of cases, but reserves the right to override them when other signals strongly contradict the tag's instruction. This is important: if your canonical tag points to a URL that does not exist, is blocked by robots.txt, or returns a redirect, Google is likely to ignore the tag and make its own determination about which URL is canonical. That determination may not be the one you want.

Used correctly, canonical tags serve three purposes in a migration context. First, they consolidate duplicate content — staging URLs, parameter variants, HTTP vs HTTPS versions — into a single indexed URL. Second, they preserve accumulated authority when content is consolidated from multiple old URLs into a single new page. Third, they protect pages from being diluted by near-duplicate variants created by CMS systems that generate multiple accessible paths to the same content.

The 5 Canonical Mistakes That Kill Rankings After a Rebuild

1. Canonicals Still Pointing to Old WordPress URLs

This is the most common and most damaging canonical error in a CMS migration. During the build process, developers often copy content and metadata from the old WordPress site to the new framework. If the canonical tag is copied alongside the metadata and not updated to reflect the new URL, the new Next.js page will declare its old WordPress URL as the canonical.

From Google's perspective, this is an instruction: "The authoritative version of this content is at the WordPress URL." If that WordPress URL is no longer live — or if it now redirects to the new site — Google faces a contradictory signal set. In practice, Google often continues indexing the old URL or delays full authority transfer to the new one, depending on how quickly it recrawls and how it resolves the conflict.

The fix is straightforward in principle but requires systematic verification: every page's canonical tag must point to the page's own URL on the new domain and path structure, not to any legacy URL. In Next.js, this is typically configured in the metadata export for each page or in a layout-level component — check wherever the framework generates the <link rel="canonical"> tag and verify it is using the current page's URL dynamically.

2. Missing Self-Referencing Canonicals on New Pages

When a page does not have a canonical tag at all, Google is left to determine canonicalization on its own based on other signals. On a site with a consistent URL structure and no duplicate content, this often works without visible problems. On a site that was recently migrated — where multiple URLs may have historically pointed to similar content, where HTTP and HTTPS variants exist, or where www and non-www versions are both accessible — the absence of a canonical tag creates ambiguity that Google resolves inconsistently.

In a Next.js rebuild, it is common for canonical tags to be implemented in some templates but not others. A developer adds canonical support to the blog post layout but forgets the landing page template, the tag archive template, and the author pages. Those untagged pages are now vulnerable to canonicalization decisions Google makes without your input.

Audit every template type in your new site, not just the primary content templates. Verify that every template that generates a publicly accessible page includes a canonical tag pointing to the correct, self-referencing URL.

3. Conflicting Canonical + Redirect Signals

A canonical tag and a 301 redirect are both instructions to Google about URL relationships, and they can conflict in ways that create confusion rather than clarity. The most problematic pattern: a page's canonical tag points to URL A, but URL A is a redirect that points to URL B.

Google's documentation is clear that canonical tags should point to accessible, indexable URLs — not to redirects. When a canonical points to a redirect, Google must follow the redirect to find the actual destination, and the signal may be discounted or ignored. The result is that Google makes its own determination about which URL is canonical, which may not align with your intended structure.

This conflict is most common when redirect maps and canonical tags are implemented independently by different team members without cross-checking. The redirect map correctly points old URLs to new ones, but some canonical tags in the new templates were hardcoded to old URLs that are now themselves redirecting. The fix requires auditing both systems together: for every URL in your canonical tags, verify that URL returns a 200 response, not a redirect.

For more on building a correct redirect map, see redirect map best practices.

4. Canonical Pointing to a Non-Indexable Page

If a canonical tag points to a page that is blocked by robots.txt, marked with noindex, or returns a non-200 response code, the canonical signal is effectively invalid. Google cannot index the target URL — which means it cannot treat that URL as the authoritative canonical — and will typically fall back to its own determination of which URL to index.

This error pattern appears most often during phased migrations, where some pages are live on the new site while others are still on the old platform. If a page on the new site has a canonical pointing to its old WordPress equivalent, and the WordPress equivalent has since been taken down or redirected, the canonical is pointing to a non-accessible URL.

The fix is to ensure every canonical target URL is accessible, returns a 200 response, and is indexable (not blocked by robots.txt or noindex). This needs to be verified programmatically — you cannot check hundreds of canonical targets manually.

5. HTTP vs HTTPS Canonical Mismatches

HTTPS is a confirmed ranking signal, and Google strongly prefers HTTPS URLs as canonical. If your new site is HTTPS but some canonical tags include HTTP URLs — either because they were copied from legacy configurations or because the canonical generation logic does not enforce HTTPS — Google receives a mixed signal.

This is particularly insidious because the pages may appear to work correctly in a browser (which automatically upgrades HTTP to HTTPS), but the canonical tag itself specifies the HTTP version. Google may index the HTTP version as canonical, which does not carry HTTPS as a trust signal and may be treated as a separate URL from the HTTPS version.

Similarly, if your site is accessible at both www.example.com and example.com, canonical tags must consistently specify the same version — not alternate between them. Pick one, redirect the other at the server level, and ensure every canonical tag uses the chosen version.

How to Audit Canonicals Before and After Launch

A canonical audit requires crawling the site and inspecting the raw HTML of each page — not the JavaScript-rendered output, and not just what appears in browser dev tools. Here is the process.

Pre-launch audit on staging. Before the new site goes live, crawl the staging environment with Screaming Frog or Sitebulb configured to render and extract canonical tags from the raw HTML response (not JavaScript-rendered). Export the canonical tag for every URL. Then compare this export against your expected URL structure. Flags to look for: any canonical that does not match the page's own URL, any canonical that uses the wrong protocol, any canonical that uses the old domain, and any page with no canonical tag at all.

Cross-site comparison. Crawl the old WordPress site and extract its canonical tags as well. For each page that will exist on both the old and new site during the migration period, verify the new canonical matches the intended new URL, not the old one. This is the comparison that catches the "copied from WordPress" error described above.

Post-launch validation. After launch, run another full crawl against the live production site. Verify canonical tags again against the live URL structure. Then check Google Search Console's URL Inspection tool for your top 20 to 30 pages — inspect the canonicalized URL Google has selected and confirm it matches the page's own canonical tag. If Google is choosing a different canonical than the one you specified, that is a signal of a conflict that needs investigation.

Server-rendered vs client-side tags. In Next.js, canonical tags generated via the metadata export or next/head are typically rendered server-side and visible in the initial HTML response — which is what Googlebot reads. But if your site uses any client-side-only metadata injection, Googlebot may not see those tags during its initial crawl. Always verify that canonical tags appear in the raw HTML by fetching a page with curl and checking the <head> output, rather than relying on what you see in browser dev tools after JavaScript execution.

Canonical Parity Checklist

Work through each of these items on your staging environment before launch. Treat any item that fails as a blocker.

Protocol consistency. Fetch 10 pages from your new site using curl -I and verify the canonical tag uses https:// in every case. Confirm your Next.js metadata configuration enforces the HTTPS protocol in all canonical tag generation.

Domain consistency. Verify every canonical tag uses the same domain variant — either with or without www — consistently across all pages. Confirm the opposite variant redirects at the server level.

Self-referencing on all templates. Identify every page template type in your Next.js application: home page, blog post, blog archive, tag page, author page, landing page, product page, contact page. Fetch a representative URL for each template type and confirm a canonical tag is present and correctly self-referencing.

No canonicals pointing to old WordPress domain. Search the canonical export from your crawl for any occurrence of your old WordPress domain. Every result is a misconfiguration that must be fixed before launch.

No canonicals pointing to non-200 URLs. Take your list of canonical target URLs and run a bulk status check. Every canonical target must return a 200 response. Any that return a 301, 302, 404, or 500 are invalid and must be corrected.

Pagination handling. If your site has paginated archives (/blog/page/2/, /blog/page/3/), verify each page has a canonical pointing to itself, not to page 1. Pointing all paginated pages to page 1 is a canonicalization pattern that can suppress the indexing of legitimate paginated content.

Comparison crawl complete. After running through the above items, perform a final comparative crawl: old site canonical export vs new site canonical export. Every page that exists in both should show the canonical migrated from the old domain/path to the new domain/path. Any discrepancy is a finding.

FAQ

Do canonical tags pass the same value as 301 redirects?

No. A 301 redirect is a stronger, more definitive signal — it eliminates the old URL from the response entirely and transfers all authority to the new URL. A canonical tag is a consolidation hint that Google respects but may override. For a full migration where old URLs should no longer be indexed, a 301 redirect is the correct tool. Canonical tags complement redirects by reinforcing the canonical URL on the new site, but they do not replace the redirect.

What happens if my canonical tag conflicts with a redirect?

Google will attempt to resolve the conflict by following the redirect and evaluating the signals at the final destination. In most cases, it will select a canonical based on the overall signal picture rather than the conflicting tag alone. The practical consequence is unpredictability: Google may index the wrong URL, split authority between multiple URLs, or delay indexing the correct one. Resolve conflicts by ensuring canonical tags always point directly to 200-status, indexable URLs — never to redirects.

Can I use canonical tags to handle www vs non-www?

Yes, but canonical tags alone are not sufficient for www vs non-www consolidation. You should implement both a server-level 301 redirect (non-www to www, or vice versa) and consistent canonical tags on all pages. The redirect ensures Googlebot always arrives at the correct variant; the canonical tag reinforces which URL is authoritative on every page.

How do I check canonical tags on a Next.js site?

The most reliable method is to fetch the raw HTML with curl -s https://your-domain.com/your-page/ | grep -i canonical. This shows the canonical tag as it appears in the server-rendered HTML response — exactly what Googlebot reads. Avoid checking canonical tags only through browser dev tools, as JavaScript-side modifications may not be visible to Googlebot during its initial crawl.

Next Steps

Canonical errors are invisible in normal browsing and easy to miss in a code review. They only become visible when rankings start dropping weeks after launch — at which point the cause is difficult to trace without a systematic audit. The right time to catch them is before the site goes live.

Related posts:

Services: