Site Migration SEO Checklist: Redesign Safely

Site migrations are among the highest-risk SEO events a website can undergo. Done correctly, a migration is transparent to search engines — rankings hold, traffic continues, and the new site inherits the authority of the old one. Done incorrectly, a migration can cause traffic losses of 30% to 80% that take six to eighteen months to recover from.

The risk is real and frequently underestimated. Philippine businesses in particular often migrate platforms — WordPress to a custom stack, shared hosting to cloud infrastructure, HTTP to HTTPS — as part of growth phases, without fully accounting for the SEO consequences. This checklist addresses every major migration type with the specific steps needed to protect organic performance.

Types of Site Migrations

Not all migrations are equivalent in SEO risk:

Domain migration: Moving from one domain to another (e.g., from oldbrand.com to newbrand.com). Highest risk. All accumulated domain authority must transfer via redirects, and Google must process the domain change before rankings stabilize.

Platform migration: Moving from one CMS to another (e.g., WordPress to Next.js, Shopify to a custom stack). High risk if URL structures change or if the new platform has technical differences in rendering, crawling, or structured data.

Redesign: Visual and structural overhaul within the same domain and CMS. Moderate risk. Risk comes primarily from URL structure changes and unintentional removal of optimized content elements.

HTTP to HTTPS: Lower risk when executed correctly. Requires proper redirect implementation and Search Console property reconfiguration.

Subdomain migration: Moving from a subdomain to the root domain (e.g., blog.example.com to example.com/blog). Moderate risk. Accumulated subdomain authority must transfer through redirects and canonical signals.

Each type shares common requirements — pre-migration audit, redirect mapping, post-launch monitoring — but has distinct considerations that are covered below.

Pre-Migration Checklist

Completing this checklist before any migration launch is non-negotiable. The pre-migration phase is where the risk is controlled.

1. Crawl the Existing Site

Use Screaming Frog, Ahrefs' Site Audit, or a comparable crawler to generate a complete list of all indexed URLs. This becomes the master reference for redirect mapping. Do not skip this step even for sites you think you know well — crawlers regularly surface URLs that do not appear in navigation.

Export the crawl as a spreadsheet with columns for: URL, HTTP status code, title tag, H1, canonical tag, inbound internal links, and page indexation status.

2. Pull Google Search Console Data

Export twelve months of Search Console data: all queries, pages, click counts, impressions, and average positions. This establishes the performance baseline and identifies the highest-value pages that cannot afford traffic disruption. Bookmark these pages as Priority 1 for redirect accuracy.

3. Analyze Backlink Profile

Use Ahrefs or Semrush to export all external backlinks. Identify the pages with the highest link equity — these must receive exact-match 301 redirects. A page with 50 referring domains pointing to it that gets a broken redirect loses that link equity permanently.

4. Audit Current Technical Foundations

Before migrating, run a full SEO audit on the current site. Migrating a technically broken site propagates those issues to the new environment. Fixing them pre-migration is always easier than diagnosing them post-migration under traffic-loss pressure. The cost of a thorough SEO audit before migration is consistently recovered through avoided post-migration recovery work.

5. Document All Existing Meta Data

Export title tags, meta descriptions, H1s, schema markup, canonical tags, hreflang tags, and robots directives for all pages. This is the source of truth for replicating or improving on the existing site's on-page optimization in the new environment. See on-page vs technical SEO for the full scope of what needs auditing.

6. Create the Redirect Mapping Spreadsheet

Build a two-column mapping: old URL → new URL. Every indexed URL from the crawl that is changing address needs an entry. Prioritize:

• Pages with significant organic traffic
• Pages with external backlinks
• Pages linked from important external sources (press, directories, partner sites)

URLs that are being removed permanently (discontinued products, deleted content) map to the most relevant alternative page — never to the homepage unless no better alternative exists.

Redirect Rules: 301 vs 302

301 (Permanent Redirect): Use for all permanent URL changes in a migration. A 301 tells search engines that the content has permanently moved to the new URL and that link equity should transfer. Google passes approximately 98–99% of PageRank through 301 redirects, though this transfer takes time to process.

302 (Temporary Redirect): Use only when content will genuinely return to the original URL within a short timeframe — for example, during A/B testing or temporary maintenance. Using 302 for permanent migrations delays or prevents the authority transfer that makes redirects valuable.

Redirect chains: Each additional redirect in a chain (e.g., A → B → C) introduces latency and reduces the link equity that passes through. Migrate redirects to point directly from old URL to final destination URL. Chains of more than two hops should be cleaned up.

Avoid redirect loops: A → B → A creates an infinite loop that search engines and users cannot resolve. Test all redirects with a crawler before launch to catch loops.

Launch Day Checklist

The launch day itself should be the calmest part of the migration if pre-migration work is thorough.

• [ ] Implement all redirect rules (verify with crawler, not just spot-checking)
• [ ] Verify no important pages are returning errors (404, 500, 403)
• [ ] Confirm robots.txt does not accidentally block crawlers
• [ ] Confirm canonical tags point to the correct URLs
• [ ] Confirm XML sitemap is updated and accessible
• [ ] Submit updated sitemap in Search Console
• [ ] If domain migration: add new domain in Search Console and use Change of Address tool
• [ ] If HTTP to HTTPS: ensure HTTPS is properly configured, HTTP redirects to HTTPS (not the other way), and HSTS header is set
• [ ] Test structured data on key pages with Google's Rich Results Test
• [ ] Verify page speed is comparable to or better than pre-migration
• [ ] Verify mobile rendering on multiple device sizes

Post-Migration Monitoring Protocol

The first 90 days after a migration are the critical monitoring window.

Week 1: Daily checks of Google Search Console for crawl errors, redirect errors, and indexing issues. Any 404 errors on URLs that should have redirects must be fixed within 24–48 hours. Monitor Ahrefs or Semrush for rank movement on top-traffic pages.

Weeks 2–4: Weekly Search Console and rank tracking reviews. Organic traffic typically shows fluctuation as Google re-crawls and re-indexes the new site. Some ranking volatility is normal; sustained drops on Priority 1 pages require investigation.

Months 2–3: Monthly analysis comparing current traffic and rankings against the pre-migration baseline. A well-executed migration should have traffic within 85–95% of baseline by the end of month two, trending back to or above baseline by month three.

Indicators that require immediate action: Any page with significant traffic dropping to zero, large-scale crawl errors in GSC, drastic changes in indexed page count, or redirect errors on high-value pages.

Common Migration Mistakes

Launching a staging site in noindex: Staging environments are correctly kept out of Google's index. The mistake is failing to flip the noindex directive to allow indexing on launch. This is among the most common and easily avoided migration disasters.

Redirect mapping that skips low-traffic pages: It is tempting to only redirect pages with significant traffic. But low-traffic pages with strong backlink profiles carry link equity that matters for domain authority. All externally linked pages need redirects.

Ignoring internal link updates: After URL changes, internal links that still point to old URLs create unnecessary redirect chains. Update internal links to point directly to new URLs post-migration.

Not testing the redirect implementation with a crawler: Manually spot-checking redirects catches only a fraction of problems. Running a post-launch crawler against the full URL list is the only reliable verification method.

Failing to account for JavaScript rendering: Platforms like Next.js, Nuxt, or SvelteKit may render content client-side. If Google's crawler cannot render JavaScript on the new platform, content it previously indexed may become invisible. Server-side rendering or static generation is strongly preferred for SEO-critical content.

Redesigning without considering content elements: Visual redesigns sometimes remove or relocate heading tags, modify URL structures, strip schema markup, or remove internally linked content. The technical SEO service work of a redesign is not just about the visual layer — every SEO element on the page must be audited as part of the new design's specification. The relationship between dynamic and static website choices is particularly relevant here: platform migrations that change rendering architecture introduce additional technical risk on top of the standard migration checklist.

Traffic Recovery Timeline

A realistic recovery timeline for a well-executed migration:

Migration Type — Normal Recovery Timeline

HTTP to HTTPS only — 1–4 weeks

Platform migration (same URLs) — 2–6 weeks

Platform migration (new URLs) — 4–12 weeks

Domain migration — 3–6 months

Domain + platform + redesign — 4–9 months

Recovery can be accelerated by:

• Submitting updated sitemaps promptly
• Requesting indexing of key pages via Search Console's URL Inspection tool
• Earning new links to the new domain during the transition period
• Fixing technical issues within days rather than weeks

When to Engage Technical SEO Experts

Most migrations benefit from technical SEO oversight at minimum for the pre-migration audit and redirect mapping phases. Migrations that definitely require expert involvement:

• Domain migrations for sites with significant traffic (10,000+ monthly sessions)
• Migrations involving hreflang across multiple languages or regions
• E-commerce platform migrations with tens of thousands of product URLs
• Migrations involving server-side rendering architecture changes

A web design agency that does not include SEO in its migration process is creating risk for clients. Similarly, a technical SEO specialist who is not involved until after launch is engaged too late to prevent the most common issues.

For Philippine businesses — where platform migrations from WordPress to modern stacks are increasingly common as the local tech ecosystem matures — the investment in pre-migration SEO planning is consistently recovered many times over in avoided traffic losses and the consultation cost of post-migration recovery.