Afield

Afield resources

Fix conflicting canonical URLs after a blog migration

Trace an old-to-new article move through redirects, HTML canonicals, internal links and the sitemap, then correct the generator that still emits the old address.

In this article

An article can move successfully for people and still send conflicting address signals to a search engine. The old URL redirects to the new one, but the new page’s canonical tag points back. Meanwhile, the sitemap lists one version and the blog index links to the other.

Start by writing down the one address you intend to keep. Then make the redirect, final HTML, internal links and sitemap agree with that decision. These checks are about duplicate versions of the same content; two different articles on the same topic need a different decision.

Conflicting state: the old page redirects to the new one, but the new canonical points back. Consistent state: the redirect, canonical, sitemap and internal links all point to the new article.
The conflict is directional. More canonical tags do not fix it; consistent signals do.

Diagnose the loop before changing anything

Consider an illustrative move from /posts/import-checklist to /blog/import-checklist. A request to the old path returns a permanent redirect. The new path returns 200, but contains:

<link rel="canonical" href="https://example.com/posts/import-checklist">

The new page is pointing at an address that sends visitors straight back. This often survives a visual review because the article itself looks fine. Check the delivered HTML, not only the title field visible in a CMS editor.

Also inspect response headers for a canonical Link header and robots directives. If the template and a plugin emit competing declarations, fixing one field may leave the other in place. Keep the first response and final response in your audit so you can distinguish the redirect from the destination.

A real public example of the intended result

On October 11, 2026, Afield’s old English comparison address returned the following public response:

https://afieldai.io/compare/afield-vs-semrush
  → 301 Location: /blog/compare-afield-vs-semrush

https://afieldai.io/blog/compare-afield-vs-semrush
  → 200
  → canonical: https://afieldai.io/blog/compare-afield-vs-semrush

The English entry in the public sitemap also names the blog address. You can inspect the destination and sitemap. Localized comparisons remain separate language pages. This check confirms the site’s declarations at that date; Google’s chosen canonical must be checked separately.

Repair the place that generates the wrong address

Follow the stale value back to its source. A canonical can come from a global base URL, the CMS permalink, a per-page override, an imported SEO field or a rendering template. Check these in that order of scope: a global setting can affect hundreds of pages, while a page override may affect only one.

For the illustrative import article, the final declaration should be:

<link rel="canonical" href="https://example.com/blog/import-checklist">

Remove the stale declaration rather than appending another one. Preserve the publication date. A migration is not a reason to make an old article appear newly written, although a substantive accompanying revision can justify updating its modification date.

SurfaceAcceptance check
Old addressA permanent redirect reaches the equivalent article directly.
New addressThe intended article returns 200 and can be read without a login.
CanonicalThe final page declares its intended preferred address consistently.
Internal navigationThe blog index and relevant article links use the new address.
SitemapThe preferred address is listed; the redirected old entry is removed.

Verify the deployed response, not just the source file

curl -sS --max-time 20 -D - -o /dev/null https://example.com/posts/import-checklist
curl -sS --max-time 20 -L -o /dev/null \
  -w '%{http_code} %{url_effective}\n' https://example.com/posts/import-checklist
curl -sS --max-time 20 https://example.com/blog/import-checklist

If the deployed page still contains the old value, check which release produced it and whether a cached response is being served. Rebuilding the local page again cannot invalidate an unrelated production cache. Save the final response and release reference with the migration map so the next editor can reproduce the check.

Once the public response is consistent, use Search Console URL Inspection to compare the user-declared and Google-selected canonicals. Record the crawl date: a result from before the deployment does not describe the repaired page. Recrawling is not immediate, and a request to recrawl is not a confirmation of indexing.

When a canonical is the wrong repair

A short import checklist and a detailed import-error troubleshooting guide may share product terms while serving different readers. Keep both if each contains a distinct answer. Give each its own canonical and link between them where the reader’s next question warrants it.

If one article is a thin copy of the other, make an editorial decision first: combine the useful material or write the missing answer. Canonicalizing unrelated or substantially different content is not a substitute for deciding what deserves to remain published.

Google describes redirects and canonical annotations as stronger signals than sitemap inclusion, and it may select a different canonical from the one you declare. Its canonicalization documentation is the reference for those signals. For the inventory work around a move, use the sitemap audit and worksheet.

Related reading

Audit a page and review the correction

Open an editable starting task. Add your details before running it.

Audit a page