Website Migration SEO Checklist: URLs, Redirects and Measurement
A website migration SEO checklist starts before launch. Inventory URLs, map each important page to its destination, preserve or improve metadata, test redirects, annotate the analytics change and monitor search and lead journeys after release. Treat the migration as a controlled change to an information system, not as a design handover.
The safest plan gives every old URL a deliberate outcome: an equivalent new URL, a relevant replacement, a considered response, or a documented retirement decision. It also gives the team an owner for each check and a way to distinguish a ranking change from a broken measurement setup.
Start with a complete URL and asset inventory
Export URLs from the current CMS, XML sitemap, analytics reports, search data, server logs and campaign documents you can access. These sources describe different parts of the site. The sitemap may include pages nobody visits; analytics may reveal a useful landing page omitted from the sitemap.
Record the current URL, status code, indexability, canonical target, title, meta description, heading focus, organic visits where available, conversions or enquiries where available, backlinks if known, page type and proposed destination. Include PDFs, important image URLs, parameter variations and URLs with no internal links.
- Mark pages that must survive because they serve a current search need or customer journey.
- Group duplicates, thin variations and obsolete campaigns for a review decision.
- Record language and market versions separately; do not collapse a useful English page into an unrelated translation.
- Give a named owner to uncertain mappings instead of quietly guessing.
A spreadsheet is sufficient for many migrations if it has clear status columns and change history. For a large or frequently changing site, use a crawl export or database view that can be refreshed. Freeze the inventory close to launch, then record anything added after the freeze.
Map old URLs to the right new destinations
Build a one-to-one redirect map for pages that have an equivalent destination. A service page should normally lead to the corresponding service page, not to a generic homepage. An article should lead to a closely related article or a useful category only when the original subject is genuinely covered there. Relevance matters more than creating a redirect for every retired URL.
Prefer a single permanent redirect from the old URL to the final destination. Avoid chains created by redirecting an old address to an intermediate address that redirects again. Check both HTTP and HTTPS, host variants, uppercase behaviour where relevant, trailing slashes and common historical paths. Keep query parameters deliberately: campaign tags may need to pass through, while tracking or sorting parameters may need a defined canonical treatment.
Review pages with no obvious replacement
Do not force an obsolete page into the nearest-looking destination. Ask whether the content should be rewritten, merged into a stronger page, replaced with a useful category, or retired. A retired page may return the response that fits the situation, but that decision should be documented with its reason and owner. The aim is to help users and crawlers reach a relevant answer, not to maximise the number of redirects.
Test the map with a crawl of the old site and a crawl of the staging or new site. Look for redirect loops, chains, unexpected 404 responses, soft error pages, mixed hosts and links that still point to the old structure.
Protect titles, metadata and page meaning
A visual redesign can change the words that explain a page. Compare old and new titles, meta descriptions, primary headings, introductory copy, structured content and internal link context. Preserve a page’s search intent when the URL remains the same. If the page is being merged or repositioned, decide whether the destination actually answers the original question.
Check canonical tags, robots directives, XML sitemaps, pagination where used, hreflang or language annotations where used, and structured data supported by the new templates. Make sure staging controls are removed only from the production release, while accidental noindex directives do not travel with copied templates.
Review internal links after the move. Update navigation, related articles, breadcrumbs, footer links, image links and downloadable resources to use final URLs rather than relying on redirects. A clean internal link structure makes the new site easier to crawl and easier for visitors to follow.
Make staging useful without treating it as production
Staging is the place to test the migration logic, page rendering and measurement implementation before public release. It should contain representative templates and content, including error pages, forms, search, multilingual paths, redirects and any authenticated or restricted areas that affect the public journey.
Use a crawl that follows links and a separate request list built from the URL inventory. Compare status codes, canonical targets, robots behaviour, titles, headings, word content and asset loading. Test mobile layouts, forms, confirmation pages and consent choices on critical journeys.
Keep staging out of search through access controls or an appropriate noindex approach. Verify production independently after release; a successful staging crawl is not proof that live DNS, cache, redirects or analytics configuration is correct.
Plan measurement before the DNS or hosting change
Write down the events and journeys that matter before changing templates. Examples include contact submissions, click-to-call actions, WhatsApp starts, bookings, downloads and important navigation steps. Define the event name, trigger, destination or confirmation signal, owner and test method. Keep the vocabulary stable where possible so a migration does not create a false break in reporting.
Export or snapshot the relevant reports from the current site. Note the reporting timezone, filters, consent settings, attribution conventions and any dashboards that depend on URL paths. If the platform or domain changes, document the property, tag, data stream, conversion configuration and access required to verify them. Do not assume that a tag visible in source code is firing correctly.
Coordinate the release window with people responsible for paid campaigns, CRM routing, email notifications and sales follow-up. A page can return a successful status while a form silently fails or an enquiry reaches the wrong queue.
Run a launch-day SEO and journey checklist
Before switching traffic, take a final backup or content snapshot, confirm the redirect file is the approved version and record the rollback decision-maker. Confirm DNS, certificates, hosting, cache rules and deployment access. Keep a short list of critical URLs and conversion journeys for immediate testing.
- Open the homepage, priority service pages, articles, contact page and key campaign landing pages.
- Request representative old URLs and confirm they reach the mapped final destination without a chain.
- Check response codes, canonical tags, robots directives and sitemap location on the live host.
- Submit test forms and test phone, email and WhatsApp links where they are part of the journey.
- Confirm analytics events, conversion signals and CRM notifications using a real test record.
- Check that important images, PDFs and other critical assets load correctly.
Keep the old system available according to the rollback plan. Record the deployment time and emergency changes so later analysis has a reliable timeline.
Monitor the weeks after migration
Post-launch monitoring should combine technical crawling, search data, analytics and business feedback. Crawl the new site to find broken internal links, unexpected status codes, redirect errors, canonical changes and pages that lost their content. Compare important templates rather than relying only on an overall traffic total.
Watch indexed-page patterns, impressions, clicks and landing pages as the new URLs are discovered. Investigate changes by URL group and date. Check high-value old paths for errors, and compare lead volume and routing with the measurement snapshot while allowing for normal demand changes.
Maintain a migration issue log with the URL, symptom, owner, fix and verification date. Prioritise broken customer journeys and lost page coverage before cosmetic issues.
When to bring in specialist migration support
Consider a structured SEO review when the migration includes a domain change, a new CMS, major architecture changes, multiple languages, ecommerce functionality or several teams controlling different systems. The work is easier when SEO, design, development, analytics and sales operations share the same URL map.
Parsis can help review the content and search side of a migration through SEO content services, while web design support can address the templates, user journeys and implementation context. This article is practical guidance, not a substitute for legal, privacy or technical advice appropriate to your systems.
Frequently asked questions
Should every old URL redirect to the new homepage?
No. Redirect to a relevant equivalent when one exists. Sending unrelated pages to the homepage can confuse visitors and makes the migration map harder to interpret. For pages with no useful replacement, document the retirement decision and choose the response that fits the content and user need.
How early should the redirect map be prepared?
Start as soon as the new information architecture is stable enough to compare. Build it before the final content freeze, then recheck it after templates, slugs and navigation are locked. Last-minute URL changes are easier to catch when the map has an owner and version history.
What should be checked first after launch?
Check priority pages, old-to-new redirects, indexability, forms and other conversion events first. These tests reveal whether users can reach the right content and whether the business can see and handle enquiries. Follow with a broader crawl and search monitoring.
Want to apply this to your business?
Tell us where your current customer or lead flow is getting stuck.
