Website migration: an SEO plan before, during and after launch

Define what is actually changing

A new design, a different CMS and a move to a new domain are different changes. Record which URLs, content, navigation, assets and technical components will change. Where practical, make major changes independently verifiable.

A careful plan reduces avoidable mistakes but does not guarantee unchanged rankings or traffic. Google may need time to process new URLs. Agree a baseline, checkpoints and someone responsible for the period after launch.

Google: moving a site with URL changes

Inventory the current website

Collect existing URLs from a crawl, sitemap, analytics and Search Console where access is available. Include useful downloads, important images and pages with external links. A page outside the navigation may still matter.

Describe what visitors are trying to do on each important page. Mark information to retain, inaccurate content to improve and pages that can genuinely be retired. A cleaner design should still answer the questions people need answered.

• Record current response codes, titles, canonicals and indexing settings.
• Record enquiries or other relevant goals for important pages where data is available.
• Keep a copy of content and configuration before making changes.

Give each old URL an intentional destination

Keep the current URL when a page retains its purpose and content. If it must change, redirect the old URL directly to the most relevant new page using a permanent server redirect. Avoid unnecessary redirect chains.

Do not send every removed page to the homepage. When no relevant replacement exists, a real 404 or 410 response may be appropriate. Update internal links so your own website points directly to final destinations.

Google: redirects and their meaning

Check the new version before publishing

Review both the visible website and server responses. A page can look correct while its canonical points to a staging domain or an indexing block remains in place. A protected test environment helps keep work in progress out of public access.

Test the agreed routes with real content on mobile, tablet and desktop. Use test data and agreed recipients for form checks, so fictional enquiries do not enter normal customer follow-up.

• Important pages return intended status codes and have their own title and canonical.
• Language variants link to the right pages and the sitemap uses final URLs.
• Images, internal links and downloads work; headings and forms support keyboard use.
• Measurement is checked and cookie choices remain respected.

Google: specifying canonical URLs

Use a checklist during launch

Agree the publishing time, the person making the change and a recovery procedure. Immediately check a selection of old and new URLs, important forms and any tracking. Confirm that staging restrictions have not reached production.

Publish the new sitemap and check processing through the available management tools. A sitemap helps search engines discover URLs; inclusion does not promise that every page will be indexed.

Google: building and submitting a sitemap

Investigate differences beyond total traffic

After launch, review indexing reports, incorrect URLs, relevant queries and enquiries. Compare equivalent groups of pages where possible, accounting for seasonality and campaign changes. A single day of total traffic rarely provides a complete diagnosis.

Investigate each affected URL: was useful content removed, is a redirect missing, does a setting block access, or does the enquiry route fail? Record the issue, repair and verification. Keep redirects while old references need them and follow the current migration guidance.

Investigate post-migration problems

Website development and migration at Fixels

Our SEO approach