Canonical URLs, redirects and internal links should support a coherent decision about where each piece of content belongs. Conflicting signals make a website harder to maintain and can make search evidence difficult to interpret.
This guide covers preferred addresses, duplicate content and site moves. Begin with the page's purpose and the reader's destination, then choose the appropriate technical implementation.
Inventory the addresses representing each page
List protocol and hostname variations, parameters, legacy paths and other addresses showing the same or very similar information. Distinguish genuine alternatives from separate pages serving different needs. A shared topic or phrase does not make two articles duplicates automatically.
Record the intended public URL and the reason for that choice. Review examples with the content and technical owners. Ordinary duplicate versions can arise through site mechanics; their existence is different from a finding that the content violates search policies.
Understand what a canonical preference does
A canonical annotation indicates a preferred representative URL for duplicate or very similar content. Search engines can select a different representative. In Google Search, redirects and canonical annotations are stronger signals than sitemap inclusion.
Check that the preference makes sense for visitors. Declaring one URL cannot create a meaningful distinction between interchangeable pages. If two proposed pages serve no separate need, review their editorial purpose before adding technical annotations.
Keep the signals consistent
Inspect the canonical annotation, redirects, sitemap and internal destinations together. Avoid specifying one preferred URL in page metadata while promoting another duplicate through the sitemap. Link directly to the intended address where the site controls the link.
Review the actual generated page and relevant headers, not just a CMS field. Themes, plugins or custom components can supply conflicting annotations. Verify that the final target is accessible and contains the expected information.
Choose redirects for the actual move
A permanent move and a temporary change have different meanings. Use a suitable server-side redirect for a settled page move where the environment supports it. Map the old address to a relevant replacement rather than sending every retired page to the homepage.
Test the complete route and avoid unnecessary chains or loops. Inspect response status, destination and any caching controls. A previously cached redirect can complicate diagnosis, so check the real configuration instead of assuming one universal cache lifetime.
Plan domain and platform changes deliberately
A domain move, CMS replacement and layout redesign introduce different dependencies. Sequence major changes where practical, so their effects can be checked. A rebrand deadline does not remove the need to test each workstream.
If close coordination is necessary, maintain separate acceptance criteria and a shared launch decision. Include DNS, certificates, email, application configuration and URL mapping. Agree which failures would delay the public announcement and who can resolve them.
Prepare a reviewed URL mapping
Inventory important old pages, including addresses receiving enquiries or useful external traffic. Assign a destination based on the retained information and user need. Record pages that are genuinely retired with no similar replacement.
Test representative paths and any rules that generate destinations. Check downloads, language variants and deep links where relevant. A general redirect rule should not quietly send a whole section to an unrelated page.
Monitor observed outcomes after launch
Compare public routes, server evidence and search inspection results with the accepted mapping. Stored search information may reflect an earlier crawl. Record the date and scope of each observation rather than treating every report as an immediate mirror of the live site.
Review affected traffic and enquiries over an appropriate period. Search fluctuations during a move need investigation without assuming that every change has one cause. Keep the old routing arrangements and follow-up ownership under review.
Checks for a coherent migration
- Approve the purpose and preferred address of each retained page.
- Review canonical annotations, redirects and sitemap entries together.
- Map old pages to relevant destinations.
- Test chains, loops, caches and important deep links.
- Verify domain, certificate and application dependencies.
- Record launch evidence and follow-up responsibilities.
Our crawling and indexing guide explains access and search evidence. The hosting migration checklist covers the environment and operational checks behind a move.
