Website Migration QA Checklist: 40 Checks Before and After Launch

Website migration QA verifies that the new site still works for users, search engines and the business after a redesign, CMS move, domain change, URL restructure or hosting migration.

A successful migration is not simply one where the new homepage loads. Priority URLs must resolve correctly, search engines must be able to crawl the intended pages, forms and integrations must still work, and conversions must still be measurable.

This 40-point checklist covers what to verify before launch, during go-live and after the migration.

What is website migration QA?

Website migration QA is the process of testing whether a migrated website preserves its important content, URLs, search signals, functionality, tracking and business journeys.

It comes after planning but continues through launch.

Planning defines what will change.
Migration moves or rebuilds it.
QA proves the result works.

A CMS migration, for example, can be technically complete while important old URLs return 404 errors or lead forms stop reaching the CRM.

That is a failed migration even if the new design looks correct.

Which website migrations need QA?

Different migrations create different risks.

Migration	Main QA risk
Website redesign	Content, templates, links and conversions
CMS migration	Metadata, content and technical settings
Domain change	Redirects, indexing and external signals
URL restructure	Mapping, redirects and internal links
Hosting move	DNS, SSL, server behaviour and performance
HTTP to HTTPS	Redirects, canonicals and mixed resources
Ecommerce replatform	Products, checkout, payments and integrations

Google treats site moves that change URLs differently from infrastructure moves where the URLs remain unchanged. The checklist should therefore be applied according to the migration being performed rather than mechanically treating every project the same.

How should you use this migration QA checklist?

Do not record only whether a task was “checked.”

For every test, record:

Status: PASS / FAIL / Not Tested / N/A
Severity: Blocker / High / Medium / Low
Owner: Person responsible for resolving it
Evidence: Crawl export, screenshot, transaction, log or test result

This turns the checklist into a launch-control document rather than a list everyone assumes somebody else completed.

Phase 1: Establish the baseline

1. Define exactly what is changing

Document whether the project changes the domain, URLs, CMS, hosting, CDN, design, content, analytics, ecommerce platform or integrations.

Also document what is not changing.

This makes later troubleshooting much easier.

PASS: Migration scope is written and agreed.

2. Assign owners and a rollback decision-maker

Name the people responsible for SEO, development, QA, analytics and business sign-off.

One person should also have authority to hold or reverse the launch if a blocker appears.

A migration issue without an owner usually becomes a post-launch issue.

3. Crawl and export the current site

Create a crawl of the live website before migration.

Capture useful fields such as:

• URLs
• status codes
• titles
• H1s
• canonicals
• indexability
• internal links

Save the export.

It becomes the reference point for comparing the new site.

4. Save your organic-search baseline

Record important organic landing pages, clicks, impressions and search queries before launch.

You do not need to export every metric available.

The objective is to know which pages and search journeys matter enough to watch after migration.

5. Save the business-performance baseline

Capture the business metrics the site is expected to produce.

Depending on the website, this may include:

• enquiries
• demo requests
• registrations
• purchases
• revenue
• bookings
• quote requests

Stable traffic does not prove migration success if lead generation stops working.

6. Build a priority URL list

Identify pages that deserve deeper testing because they have significant:

• organic traffic
• backlinks
• rankings
• revenue
• leads
• strategic importance

These URLs should receive manual checks in addition to automated crawling.

Phase 2: Pre-launch SEO and content QA

7. Crawl the staging or new website

Create a crawl of the new environment before launch.

Compare it with the old-site crawl.

Look for unexpected changes in:

• URL count
• indexability
• metadata
• headings
• canonicals
• internal linking
• status codes

This catches template-level problems before production.

8. Verify content parity on priority pages

Compare important old and new pages.

Do not ask whether every sentence survived.

Ask whether the information that made the page useful still exists.

Check important service details, product information, trust signals, tables, FAQs, imagery and conversion content.

A redesign can look cleaner while accidentally removing information that supported rankings or conversions.

9. Finalize the old-to-new URL map

Every changing URL should have an intentional outcome:

Keep → Move → Merge → Redirect → Remove

Map old URLs to the most relevant new destinations.

Do not automatically send removed pages to the homepage.

Google specifically recommends creating an old-to-new URL mapping before migrations involving URL changes.

10. Test permanent redirect rules

For URLs that move permanently, test the intended redirects before launch where the environment permits it.

Google recommends server-side permanent redirects such as 301 or 308 when URLs permanently change.

PASS

Old URL reaches the correct final destination.

FAIL

Old URL:

• returns 404 unexpectedly;
• reaches an unrelated page;
• creates a loop; or
• follows an unnecessary chain.

Severity: BLOCKER for priority URLs.

11. Remove redirect chains, loops and irrelevant mappings

Prefer:

Old URL → Final URL

instead of:

Old URL → Intermediate URL → Another URL → Final URL

Google recommends redirecting directly to the final destination where possible and warns against redirecting many unrelated pages to an irrelevant destination such as the homepage.

12. Verify expected status codes

Not every old URL requires a redirect.

If content has genuinely been removed and there is no suitable replacement, the expected outcome may be a proper 404 or 410.

On the new site, pages intended to remain accessible should generally return the expected successful response rather than redirects or errors.

Google specifically recommends returning appropriate 404 or 410 responses for deleted content that is not being moved.

13. Compare titles, H1s and important page signals

Check priority pages for:

• missing titles;
• duplicate template titles;
• accidental title rewrites;
• missing H1s;
• broken heading structure.

This is primarily a parity check.

Do not delay an entire launch because one low-value page needs a slightly better meta description.

14. Verify canonical URLs

Check that canonicals point to the intended production URLs.

Watch especially for:

• staging domains;
• old domains;
• HTTP versions;
• wrong URL variants;
• template-wide canonical mistakes.

Google recommends updating canonical references to the new URLs during URL-changing migrations.

A wrong canonical across hundreds of pages can be far more serious than one missing description.

15. Prepare production robots and indexability settings

Staging environments are often deliberately blocked from search engines.

Before launch, know exactly which restrictions must be removed.

Check:

• noindex
• robots.txt rules embedded resources and updating hreflang annotations when URLs change. citeturn517173view0

20. Check access for search and AI-search crawlers

Googlebot access should be part of normal indexability QA.

If the business also wants its public content discoverable in AI search products, review those crawler rules during the migration rather than assuming the old configuration carried over.

OpenAI says sites that want content included in ChatGPT search summaries and snippets should not block OAI-SearchBot. citeturn419271search0

Perplexity similarly recommends allowing PerplexityBot when a site wants to appear in Perplexity search results. citeturn419271search1

This is optional according to the business’s AI-search policy; it should not override intentional crawler restrictions.

Phase 3: Functional QA

21. Test navigation, footer and breadcrumbs

Use the website like a visitor.

Open:

• desktop navigation;
• mobile navigation;
• dropdowns;
• footer links;
• breadcrumbs.

Look for dead ends and unexpected redirects that automated SEO reports may not make obvious.

22. Submit important forms end to end

Do not stop when the browser displays a success message.

Confirm the full journey:

Form submission → notification/CRM → correct team

Test required fields, validation, confirmation messages, automation and thank-you pages.

A lead form that appears to work but never reaches sales is a migration blocker for a lead-generation website.

23. Test primary conversion paths

Follow the journeys the business depends on.

Examples include:

Landing page → Book Demo

Service page → Request Quote

Product page → Buy

Pricing → Start Trial

Check the complete path rather than individual buttons in isolation.

24. Test site search, filters and sorting

Where applicable, verify:

utocomplete;

• filters;
• sorting;
• pagination;
• empty-result states.

CMS and JavaScript changes can break these functions without creating an obvious page error.

25. Test login and account journeys

For websites with user accounts, test:

• registration;
• login;
• password reset;
• account pages;
• protected content;
• logout.

Use real test accounts rather than assuming a page loading means authentication works.

26. Complete a real checkout and payment test

For ecommerce sites, test:

Product → Cart → Checkout → Payment → Order Confirmation

Also verify relevant taxes, shipping, coupons, emails, payment responses and order creation.

Broken checkout = BLOCKER.

27. Test integrations and webhooks

Review systems connected to the website, such as:

• CRM;
• email marketing;
• booking platform;
• payment gateway;
• live chat;
• APIs;
• webhooks.

Domain or platform changes can affect callback URLs, authentication, allowed origins and environment settings.

28. Verify cookie and consent behaviour

Where applicable, confirm that consent controls still behave according to the site’s intended configuration.

Test the initial state, choices, preference updates and their effect on relevant tracking.

A visible banner is not evidence that its underlying behaviour is correct.

29. Test critical journeys on mobile and major browsers

This check is intentionally narrow.

The purpose is to identify migration-related breakage in key journeys, not duplicate a full responsive-design audit.

Verify the site’s main navigation, forms and conversion flows on representative mobile and desktop environments.

For deeper mobile QA, StartDesigns already has a dedicated Responsive Web Design Checklist covering responsive layout, touch targets, forms, navigation and device testing. citeturn170169search1

30. Check accessibility blockers on important journeys

Prioritize failures that can prevent somebody from completing a task.

Examples include:

• inaccessible navigation;
• keyboard traps;
• unusable form labels;
• missing focus behaviour;
• inaccessible checkout controls.

A full accessibility audit is broader than migration QA.

The migration check asks whether the move introduced or exposed serious barriers in critical workflows.

Phase 4: Measurement, infrastructure and rollback

31. Verify analytics and conversion events

Perform real interactions and confirm the production measurement system receives them correctly.

Check relevant:

• page views;
• form events;
• purchases;
• lead events;
• demo bookings;
• ecommerce revenue.

Do not assume analytics survived because the same tag container exists.

32. Verify DNS, SSL, CDN and server readiness

Depending on the migration, verify:

• DNS;
• HTTPS certificate;
• redirects to the preferred protocol;
• CDN configuration;
• caching;
• production host response.

For hosting moves where URLs stay the same, Google specifically recommends testing the new infrastructure, checking Googlebot access, changing DNS and monitoring traffic to the old and new hosts. citeturn517173view1

33. Compare performance with the old site

Compare representative templates rather than chasing one perfect score.

Look for meaningful regressions in loading, responsiveness and visual stability.

Google’s current Core Web Vitals are LCP, INP and CLS, and Google recommends good Core Web Vitals as part of a strong page experience. citeturn749618search3

The question during migration QA is not:

“Did Lighthouse reach 100?”

It is:

“Did the migration create a significant performance problem that wasn’t there before?”

34. Confirm backup and rollback procedures

Know the answer before go-live:

If the migration fails, what exactly happens next?

Document:

• available backup;
• restoration procedure;
• rollback owner;
• estimated restoration time;
• systems affected;
• decision authority.

“Roll back if necessary” is not an actionable rollback plan.

Phase 5: Launch-day verification

35. Verify the live site is crawlable and indexable

Now repeat the indexability test against production.

Check the actual live responses for:

• robots.txt;
• noindex;
• X-Robots-Tag;
• canonical domain;
• expected status codes.

This is intentionally separate from Check 15.

Check 15 prepares the correct settings.

Check 35 proves those settings actually reached production.

Accidental production-wide noindex = BLOCKER.

36. Crawl the production website

Run a fresh crawl after go-live.

Do not treat the staging crawl as final evidence.

Production can introduce different:

• redirects;
• caching;
• environment variables;
• canonicals;
• blocked resources;
• internal links.

Compare the live crawl with the approved pre-launch version.

37. Retest the priority old URLs

Run the priority legacy URL set against production.

Verify each changing URL reaches the destination approved in the redirect map.

This is the final redirect sign-off, not another redirect-planning exercise.

Investigate incorrect destinations, chains, loops, 404s and 5xx responses immediately.

38. Complete real production conversions

Test the real website after deployment.

For a lead-generation website:

Landing page → form → CRM/email

For ecommerce:

Product → checkout → payment → order

For SaaS:

Landing page → signup/demo → confirmation

A successful staging transaction does not prove the production journey works.

Phase 6: Post-launch monitoring

39. Monitor Search Console, errors and indexation

During the first days after launch, review:

• unexpected 404s;
• server errors;
• sitemap processing;
• indexation;
• priority URLs;
• crawler activity where logs are available.

For domain migrations, Google also recommends using Search Console’s Change of Address process. It is not required for an HTTP-to-HTTPS move. citeturn517173view0

Google notes that ranking fluctuations can happen temporarily while a significant site move is recrawled and reindexed, so a small immediate change should not automatically trigger panic. citeturn517173view0

40. Compare Day 1, Week 1 and Month 1 performance

Use the baseline created before migration.

Day 1

Look for technical, tracking and conversion failures.

Week 1

Review crawl errors, indexing, organic landing pages and major conversion changes.

Month 1

Look for broader trends in traffic, rankings, leads and revenue.

Do not declare the migration successful solely because nothing went wrong on launch day.

For URL-changing migrations, Google recommends keeping permanent redirects for as long as possible and generally for at least one year so signals and visitors continue reaching the new URLs. citeturn517173view0

When should a website migration launch be held?

Not every failed QA item should stop a launch.

Use a severity model.

Severity	Meaning	Typical action
BLOCKER	Core search, infrastructure or business journey is broken	HOLD
HIGH	Significant business/search risk	Fix before launch where practical
MEDIUM	Limited impact	Assign owner and deadline
LOW	Minor/cosmetic	Document and continue

Examples of likely blockers include:

Production-wide noindex

Primary lead forms do not deliver submissions

Checkout cannot complete

Critical domain/DNS/SSL failure

Priority URL redirects are materially broken

A missing description on one low-value page is not in the same category.

The severity system prevents two common QA mistakes: launching with a serious problem because “most checks passed,” or delaying launch because every minor defect is treated as critical.

What should your migration QA sheet contain?

Use one shared migration record with these fields:

Field	Purpose
Check	What is being tested
Phase	Pre-launch / Launch / Post-launch
Owner	Responsible person
Severity	Blocker / High / Medium / Low
Pass criteria	Expected result
Status	PASS / FAIL / Not Tested / N/A
Evidence	Screenshot, crawl, transaction or log
Issue	What failed
Fix owner	Who will resolve it
Retest	Final verification

The Evidence field is particularly useful.

“Redirects checked” is an opinion.

A saved redirect-test export is evidence.

“Forms working” is an opinion.

A production test submission visible in the CRM is evidence.

Final migration sign-off

Before calling a website migration complete, confirm five things:

Users can reach the pages they need.

Search engines can crawl and understand the intended production URLs.

Important old URLs resolve to the correct destinations.

Critical forms, payments and integrations work end to end.

Traffic and conversions can still be measured after launch.

If one of those statements is false, investigate the failure before treating the migration as complete.

For teams planning a redesign or platform move, StartDesigns’ website redesign process already includes SEO-aware structure, QA, launch support and post-launch checks. A migration QA review can be used to identify technical, SEO and conversion risks before they become production problems.