Website migration SEO checklist

Combine the CMS export with sitemap URLs, relevant analytics, search reports and known customer links. Include downloadable documents and valuable image destinations where applicable. For each old URL, record its purpose, current status, intended new destination and decision owner. Classify it as retained, moved, meaningfully combined or removed. This makes gaps visible before launch: an unassigned product guide is a content decision waiting to happen, not merely a redirect rule that a developer can guess.

A moved page should reach the most relevant replacement directly. When several pages become one genuinely equivalent resource, document that consolidation. If no suitable replacement exists, keep an intentional not-found response instead of sending the visitor to an unrelated homepage. Google recommends permanent server-side redirects, avoiding chains and irrelevant destinations. Check both the old request and the final page; receiving a redirect proves little if its target is missing, private or about a different subject.

Before cutover, compare the intended canonical URL, page title, heading, robots directive and internal links for representative templates. Prepare the exact switch from protected staging to public production. Private environments should remain private; production must not inherit an accidental noindex. Verify images, CSS and scripts needed to understand the page. Keep a written list of intentionally excluded utility pages so correcting a blanket restriction does not make every route indexable.

Consider an old service page covering both portal development and portal support. The new site separates these offers. Do not automatically redirect the old URL to whichever new path has a similar name. Review the old page’s main purpose and existing links, choose the closest destination, and provide a clear route to the other service there. Retain a record of that judgment. If both subjects remain inseparable for visitors, a useful overview page may be a better destination than forcing either detailed page to carry the whole meaning.

Assign a person to each release check and record the result from public HTTPS. Verify important redirects, final 200 responses, canonical destinations and a sitemap containing the intended live URLs. Confirm site-verification mechanisms still work. Keep the preceding deployment and the conditions for technical rollback available, but distinguish a release defect from normal search processing time. Avoid reversing a healthy migration solely because search reports have not updated immediately.

After launch, investigate unexpected not-found responses, redirect loops, blocked assets and canonical mismatches first. Compare important landing pages and relevant queries over meaningful periods rather than interpreting a single day. Record deliberate removals separately from defects. Google advises retaining redirects for a substantial period, generally at least a year; customer bookmarks can justify keeping useful redirects longer. Keep ownership of the old domain and redirect configuration in the operating plan. Neither correct redirects nor a submitted sitemap guarantees stable rankings throughout the move.

Moving from Joomla or WordPress to Django, Laravel, Next.js or Astro involves more than old and new URLs. Keep a separate record of content types, media, custom fields, accounts and extension behavior. Connect that record to the URL map so a page is not marked complete merely because its destination returns 200.

Before launch, save comparable Search Console landing-page and query reports, the sitemap and an important-URL checklist. Record changes to analytics consent or source handling separately from the migration: better measurement can change reported channels without changing actual traffic. After launch, investigate errors first and compare complete reporting periods before drawing conclusions about rankings.