The short answer
Choose the intended public URL for each article and make its canonical metadata consistent with that destination. A canonical identifies the preferred equivalent version; it is not a shortcut for merging unrelated pages. Review URL choices before migration rather than relying on whatever route happens to render first.
A worked example
A fictional guide can be reached at both an old category path and a new blog path. The migration team first confirms that the content is genuinely equivalent, then records the preferred destination and checks its response. If the old page covered a different subject, pointing both canonicals at one guide would hide an unresolved content decision.
A practical checklist
- List the old URL, new URL and equivalence reason in a mapping sheet. Mark ambiguous matches for editorial review instead of assigning the home page as a default.
- Inspect the destination's title, main heading and canonical value. Use a complete public URL without tracking parameters or a fragment.
- Test the final deployment separately from the preview. Keep redirect activation, sitemap updates and indexing approval as coordinated release steps.
What to avoid
Avoid canonicalizing all paginated pages or filtered views to an unrelated article. A hint does not guarantee that a search engine will select that URL. This rebuild remains noindex during development; canonical metadata does not override that restriction or activate a migration.
A useful follow-up
Does a canonical tag replace a redirect?
No. They serve different purposes. Decide equivalence and migration behavior explicitly before enabling either strategy.
