Website Migration SEO Checklist: A Lean-Team Launch Runbook

A business owner considering a move from an aging WordPress site to a simpler website builder described the central migration risk plainly: search visibility drives sales, but the existing site is difficult to maintain. The concern, raised in a Reddit discussion about switching from WordPress to a builder, is not whether a builder is inherently bad for SEO. It is whether the move changes URLs, content, links, or access in ways search engines cannot follow.

This website migration SEO checklist gives a lean team a launch sequence, an owner for each critical decision, and evidence to save before anything changes. It applies to a WordPress rebuild, a move to a website builder, a domain change, or a restructuring of an existing site.

A website migration protects SEO by recording the current site, mapping valuable old URLs to relevant new destinations, testing permanent redirects and indexable pages before launch, then monitoring search data afterward. The essential launch gate is simple: important pages must load, old URLs must reach the correct destinations, and search engines must be allowed to crawl the live site.

What counts as a website migration—and why SEO needs a plan

A migration is any substantial change to how a site is hosted, addressed, built, or organized. Moving from WordPress to a hosting provider’s builder can be a migration even when the domain stays the same: the builder might produce different page paths, navigation, HTML, or canonical tags. A domain change introduces another layer because old-domain URLs must lead visitors and crawlers to the new domain.

The SEO risk depends on what changes, not the platform name. Match each change to a check:

• URLs change: create a URL map and test permanent redirects from old addresses.
• Content or templates change: compare important pages before and after the rebuild, including their main text, headings, and indexation settings.
• Hosting or DNS changes: confirm the live domain reaches the intended server over HTTPS and that pages do not return server errors.
• Navigation changes: crawl internal links and confirm valuable pages remain discoverable.
• Domain changes: verify both properties in Google Search Console and follow Google’s domain-move instructions.

Google’s site-move guidance says ranking fluctuations can occur while it recrawls and reindexes moved URLs. That is a reason to prepare evidence and checks, not a reason to stay on an unmanageable platform. A simpler editor may make future maintenance easier, but ease of editing alone does not preserve existing search signals.

Before you start: set scope, owners, and SEO baselines

The first planning decision is what the team is actually moving. Record the old and new domain, whether paths will change, whether content will be rewritten, which forms or sales pages are business-critical, and who can change redirects and DNS records. A WordPress-to-builder move with the same domain but new URL paths needs redirect work; a same-path hosting move primarily needs availability, content, and indexing checks.

For a small team, one named person must own the launch decision even if a developer or provider performs the technical changes. Assign an owner to four jobs: URL inventory and SEO checks, new-site content, redirects and hosting, and analytics or conversion tracking. One person may hold several roles. What matters is that a failed check has someone authorized to stop launch and fix it.

Save a baseline that can answer a real question

Before making changes, export Google Search Console data for the pages and queries that matter. Record organic clicks, impressions, and notable query positions over a recent representative period; use the same comparison period after launch and note any seasonal or campaign effects. Add analytics data for organic landing pages and conversions, such as submitted lead forms or completed purchases. Rankings alone cannot show whether a high-value page still generates sales.

Save the current XML sitemap, a crawl of the live site, and a list of the pages that receive meaningful organic visits or lead to conversions. Capture page titles, canonical URLs, indexability, status codes, and important internal links. For the most valuable pages, keep a copy or screenshot of their content so a rebuild does not silently omit a useful section.

Create a full recoverable backup of the old site, including its content and any settings needed to restore it. For WordPress, that ordinarily means files and database, not just an export of post text. Ask the hosting owner how the old site can be restored if the new deployment fails. Record the current DNS records before changing them, and choose a launch window when the owner and technical contact can both investigate problems.

Pass/fail check: the team can identify its important URLs, compare post-launch performance against a saved baseline, and describe how to restore access. If the only record of the old site is a browser tab, planning is not finished.

Crawl the old site and prioritize the URLs that matter

A site crawl turns a vague instruction to “keep the SEO” into a list of actual addresses. Crawl the live site with a crawler that can export URLs and status codes, then combine that list with the XML sitemap, Search Console landing-page data, analytics, and any known backlink data. No single source is a complete inventory: a sitemap can omit live pages, while a crawler can miss orphaned URLs that still receive search visits or external links.

Sort the inventory by business risk rather than alphabetically. A practical three-tier scheme works for a lean team:

1. Tier 1 — must work at launch: homepage, organic landing pages that generate leads or sales, core service or product pages, and pages with important external links.
2. Tier 2 — preserve and check promptly: useful articles and category pages with search impressions, relevant internal links, or a clear role in the new site.
3. Tier 3 — decide deliberately: obsolete announcements, duplicates, and pages that no longer serve a user need.

For example, a service page with modest visits but frequent form submissions belongs in Tier 1. An old event notice with no relevant replacement may belong in Tier 3. Low traffic alone is not proof that a URL has no value: check whether it has backlinks, assists navigation, or is newly published before retiring it.

Add a column for existing problems. If an old URL already returns 404, identify whether it has links or visits before deciding whether it deserves a destination. If two old pages compete for the same topic, the rebuild may consolidate them—but the mapping must point each old URL to a genuinely useful replacement. Do not use a migration as an excuse to redirect every uncertain URL to the homepage.

Pass/fail check: every Tier 1 URL appears in the inventory with an owner, intended outcome, and launch test. The crawler export and performance data should be saved where the launch team can use them, not left in one person’s account.

Build and validate the URL map and redirect plan

A URL redirect map is the migration’s working record. It pairs an old address with the address that best serves the same visitor intent. Make it before configuring redirect rules, because an apparently successful 301 can still send a valuable page to an irrelevant destination.

A compact spreadsheet can use these columns: old URL, current status, priority, new URL, decision, redirect configured, tested status, final URL, and owner. Include a note when a page will retain its address, be consolidated, or intentionally disappear. Someone reviewing the sheet should be able to tell what happens to an old URL without guessing from a redirect rule.

Choose the destination, then choose the response

If example.com/wordpress-support/ becomes example.com/services/wordpress-support/, map the first URL directly to the second. If the new site keeps example.com/contact/ at the same address, it does not need a redirect; it needs a content, status, and tracking check. If an obsolete page has no relevant successor, do not manufacture relevance by sending it to the homepage. Let the site return an appropriate not-found response rather than presenting an unrelated page as its replacement.

For lasting URL moves, Google recommends server-side permanent redirects, such as 301 or 308. Confirm that the new builder or hosting setup can implement the required redirects before committing to it. A simple page editor does not solve a migration if the team cannot route old paths reliably.

Test the route, not just the rule

Request each Tier 1 old URL and record the response and final destination. The expected result is a permanent redirect to the mapped, working page, followed by an indexable 200 response where appropriate. Check HTTP and HTTPS forms and relevant www variants so an old link does not fail because it uses a different hostname.

Avoid loops and chains such as old-page → interim-page → new-page. Google advises redirecting straight to the final destination where possible; extra hops add delay and make faults harder to spot. Update internal links on the new site to point directly to final URLs rather than relying on redirects to repair its navigation.

Keep the old domain and redirect rules under the team’s control after launch. Google advises keeping migration redirects for at least one year, and longer can help visitors using old bookmarks or links. The pass/fail check is a saved test result for every Tier 1 URL: old address, redirect status, final address, and final page status.

Prepare the new site in staging

Staging is where the team should discover that a builder changed a URL pattern, dropped a paragraph, or inserted a noindex directive—not after the domain points to the new site. Restrict public access to staging while it is under construction, for example with authentication where the platform permits it. Record every staging-only control so the launch owner knows what must be removed from the live deployment.

Check the pages search engines will need

Crawl the staged site and compare its intended URLs with the map. On Tier 1 pages, confirm that the main content and purpose survive the move; titles and headings describe the correct page; canonical tags point to the intended live URLs; and navigation links reach the new destinations. If a builder generates unexpected paths, update the map and redirect rules before launch rather than assuming search engines will infer the relationship.

Check mobile layouts for obscured content, unusable navigation, and forms that cannot be completed. Test page loading on representative templates, including the homepage, an article, and a conversion page. A Lighthouse audit can help identify performance and usability issues, but its score is not a substitute for checking that users can reach content and complete the site’s key action.

Rehearse what can be tested before launch

Where the hosting arrangement allows it, test proposed redirects against the staged destination or a controlled preview. If redirects cannot be activated until launch, test the configuration on representative paths and reserve time to check every Tier 1 rule immediately afterward. Preview forms, analytics tags, canonical tags, XML sitemap output, and internal links rather than assuming settings will carry over from WordPress.

The most dangerous staging error is copying a block to production. A staging noindex rule, robots restriction, password prompt, or canonical pointing to a preview domain can prevent the live site from behaving as intended. Put removal of those controls on the launch checklist with an owner and a live-URL test.

Staging gate: Tier 1 content is present, intended URLs and internal links work, the redirect plan is implementable, and the team knows precisely which protections must not reach production. Cosmetic issues on lower-priority pages can be scheduled; an absent sales page cannot.

Migration day: run the website migration SEO checklist in order

Treat launch as a sequence of checks, not a single publish button. The launch owner should keep the URL map, DNS record copy, backup location, and contact details open during the change. Record when each check passes so later traffic changes can be matched to an actual event.

1. Make the new site reachable. Deploy the intended production version and confirm the live domain resolves to it. The hosting owner checks DNS records, HTTPS, and whether the homepage and a Tier 1 page load from outside the staging environment.
2. Activate old-to-new routes. The redirects owner tests representative rules first, then every Tier 1 old URL. A passing test reaches the mapped final page rather than an error, a loop, or an unrelated homepage.
3. Remove staging restrictions from production. The SEO owner checks live responses and page source for unintended noindex, robots blocks, password requirements, and preview-domain canonicals. Staging itself should remain protected.
4. Check critical user journeys. The content or operations owner opens the homepage, top landing pages, navigation, and a lead or purchase path on a mobile device. The destination should contain the expected information, not merely return 200.
5. Verify measurement. The analytics owner confirms that visits and the business’s key conversion event can be observed on the new site. Tracking should not wait for a later SEO report.

Do not declare launch complete while critical URLs or site access fail. A broken Tier 1 redirect, inaccessible domain, widespread server error, or live-site noindex needs immediate correction. If the team cannot restore access or fix the failure promptly, the designated launch owner decides whether to roll back using the prepared recovery plan. The exact rollback method depends on the host and platform, which is why it must be settled before migration day.

Submit the new sitemap and notify search engine tools

Once the live pages and redirects pass, open the production XML sitemap. It should list the intended canonical, indexable new URLs—not staging addresses, redirected old URLs, or pages deliberately excluded from search. A browser opening the sitemap is only a first check; spot-check entries against the live page and its canonical tag.

Submit the new sitemap in the appropriate Google Search Console property and inspect important URLs there. Confirm that the property covers the live site; when moving domains, verify access to both old and new properties so their data can be monitored separately. A sitemap helps discovery, but submission does not confirm that every listed page has been indexed.

Google’s Change of Address tool applies to a move between domains or subdomains. It is not needed merely because a WordPress site becomes a builder site on the same domain, paths change within that domain, or the site switches between HTTP and HTTPS. Use the tool when the move qualifies and the required redirects are in place. If the team uses Bing Webmaster Tools, verify the relevant site there and submit the new sitemap as part of the same post-launch handoff.

A failed sitemap fetch needs investigation rather than repeated submissions. Start with the sitemap URL, HTTP status, access restrictions, and whether the file contains live canonical URLs; this sitemap-fetch troubleshooting guide covers that check in more detail.

Post-launch monitoring: find and fix problems early

Monitoring should follow the risk list, not just a sitewide traffic chart. During the first days, check Tier 1 pages and old URLs daily, alongside Search Console reports, analytics, and conversion events. After the immediate launch period, review the same signals regularly over the following weeks and keep a dated record of fixes. A small team can do this with one shared sheet; it does not need a migration dashboard to recognize a failing sales page.

Watch three different kinds of evidence

Access and routing: revisit old high-value URLs for redirect failures, new URLs for server errors, and the production site for accidental blocking. A fresh crawl can expose broken internal links that a manual check missed. Server logs, if available, can help identify repeated crawler requests to failing addresses.

Search discovery: in Search Console, watch indexing reports, sitemap processing, URL Inspection for selected pages, and query and page performance. A redirected old URL being replaced by its new counterpart is different from a valuable page disappearing without a working destination. Separate those cases before changing content.

Business impact: compare organic landing-page visits and conversions with the saved baseline. Check whether a form or checkout change—not a ranking change—explains fewer recorded leads. Segment the review by Tier 1 pages so a sitewide average does not conceal one broken service page.

Short-term ranking movement can happen during recrawling. Google says medium-sized sites may take a few weeks or more to begin showing new URLs in place of old ones, with larger sites potentially taking longer; it gives no fixed completion time. That guidance is not a waiting period for technical faults. Widespread 404 errors on mapped URLs, production blocking, or a sustained drop concentrated on important pages calls for investigation as soon as it appears.

When a problem is fixed, record the affected URLs, the change made, and the next check. This prevents a lean team from repeatedly diagnosing the same symptom without knowing whether a redirect rule, canonical, or page content has already changed.

Common migration mistakes and how to troubleshoot them

A useful troubleshooting list starts with the first test to run, not a speculative cause. Use the URL map and the saved pre-migration crawl to narrow each symptom.

One problem can have several causes. A 200 response does not prove that the right page loaded, and a 301 does not prove that its target is relevant. Check the user-facing destination as well as the status code. Likewise, a decline after a redesign is not automatically a redirect problem: compare content and page purpose before changing rules that already work.

Prioritize repairs using the same tiers established before launch. Fix a blocked service page or broken redirect from a valuable article ahead of a missing link on an obsolete notice. That ordering keeps the team focused on recoverable business risk rather than the largest raw error count.

Copyable website migration SEO checklist template

The following compact runbook can live in a spreadsheet or project board. Replace role names with actual people and attach a link to the evidence for each pass. A task is not complete simply because someone remembers doing it.

For a small WordPress-to-builder move, the safest economy is fewer simultaneous changes, not fewer checks. Keeping the same useful page paths can reduce redirect work; retaining strong page content can make a traffic change easier to diagnose. If URLs and content both must change, the map and saved page copies provide the evidence needed to distinguish one problem from the other.

Once the site is stable, the team can return to its normal publishing workflow. Seovyn’s SEO content agent uses Google Search Console data in its content workflow, checks drafts before review, and publishes approved content to the customer’s own site. Editorial approval remains the default; it is not a substitute for migration redirects, access checks, or a verified launch. Teams ready to resume source-grounded publishing can Start free.

FAQ

Can a move from WordPress to a website builder hurt SEO if the domain stays the same?

Yes. Keeping the domain does not prevent a builder from changing /services/ to another path, omitting content, altering internal links, or adding an unintended canonical or noindex rule. Compare the old-site crawl with the new URLs and test the important pages. If the addresses remain unchanged, redirects may not be needed for those pages, but content and access checks still are.

Should every old URL redirect to the new homepage?

No. A redirect should lead to the closest relevant page for someone who requested the old URL. For example, an old service detail page should reach its replacement service page, not a general homepage. If there is no useful successor for an obsolete URL, an appropriate not-found response is preferable to an unrelated destination. Record that decision in the URL map.

How long does SEO recovery take after a website migration?

There is no fixed recovery date. Google says it can take a few weeks or more for new URLs on a medium-sized site to begin replacing old ones in search, and larger moves can take longer. Recrawling varies by URL and site. A working redirect, accessible destination, and clean indexing signals deserve monitoring; critical errors deserve immediate repair rather than waiting for rankings to settle.

What if a critical redirect fails after the new site goes live?

The launch owner should treat a failed Tier 1 redirect as a launch incident. Check the old URL’s response, hostname, configured rule, and intended destination; repair the route and retest the final page. If the domain or a large group of critical pages is inaccessible and the team cannot correct it promptly, use the rollback decision and contacts agreed before launch.