Will a website migration hurt SEO?

Some short-term fluctuation is common, but a well-planned migration with complete redirects and preserved content usually recovers within weeks. Large, lasting losses almost always come from missing redirects, lost content or blocked crawling.

How long does it take for rankings to recover after a migration?

For a well-executed migration, most sites stabilise within two to eight weeks. Domain changes and large restructures can take longer while search engines process the redirects.

Should I use 301 or 302 redirects for a migration?

Use permanent redirects, 301 or 308, for every URL that has moved for good. Temporary 302 redirects signal that the old URL will return, which is not the case in a migration.

How long should redirects stay in place after a migration?

At least a year, and ideally indefinitely for URLs that had links or traffic. Removing redirects early sends returning visitors and link value to 404 pages.

Do migrations affect AI search visibility?

They can. AI engines cite specific URLs, and if old URLs break or new pages load their content with JavaScript, citations can disappear. Check AI crawler access and raw HTML content on the new site before launch.

Do I need to tell Google about a migration?

For a domain change, use the Change of Address tool in Search Console after redirects are live. For CMS or URL changes on the same domain, there is nothing to submit beyond new sitemaps; search engines discover the change through crawling and redirects, so complete, correct redirects are what matter.

Website Migration SEO Checklist: Replatforming Without Losing Rankings

Site migrations are where SEO value is most often lost in a single day. A domain change, a move to a new CMS, a redesign that changes URLs or a merger of several sites can wipe out years of rankings if redirects are missed or content is lost. They can also go almost unnoticed by search engines when done carefully.

This checklist covers migrations that change URLs, platforms or domains. For moving data between WordPress SEO plugins on the same site, see our plugin migration tool and the comparison in Yoast vs Rank Math vs AIOSEO.

Types of migration and their risk

Migration type	What changes	Typical risk
Redesign, same URLs	Templates and design	Low to medium: content, headings or internal links can change
CMS replatform	Platform, often URLs	Medium to high
URL restructure	Paths and hierarchy	High
Domain change	Domain, often everything else	High
HTTP to HTTPS	Protocol	Low if redirects are correct
Site merger	Several sites into one	High: redirects and content consolidation

The more that changes at once, the higher the risk. If possible, separate changes: move platform first with the same URLs, then restructure later.

Phase 1: Plan (4–8 weeks before launch)

Inventory every URL

Build a complete list of current URLs from several sources, because no single source has everything:

A full crawl of the current site.
XML sitemaps.
Search Console pages with impressions over the last 16 months.
Analytics landing pages over the last 12 to 24 months.
Backlink tool exports of URLs with external links.
Server logs for URLs that crawlers request.
URLs cited in AI answers for the client's prompt set.

Record the value of each URL

For each URL, note traffic, conversions, backlinks and rankings. This decides which pages need the most care.

Benchmark everything

Record a dated baseline before anything changes:

Rankings for tracked keywords.
Organic traffic and conversions by landing page.
Indexed page count.
Core Web Vitals by template.
AI visibility: mentions and citations for the prompt set. See AI share of voice.

Phase 2: Map redirects (3–6 weeks before)

The redirect map is the most important document in a migration.

Map every old URL to its most relevant new URL, one to one wherever possible.
Avoid mass redirects to the homepage. Search engines treat irrelevant redirects like soft 404s.
Redirect removed pages to the closest equivalent, or return 410 if there is genuinely no replacement and the page had no value.
Handle parameters, uppercase variants and trailing slashes consistently.
Include images, PDFs and other files that receive traffic or links.
Update old redirects so earlier redirect chains point straight to the final new URL.
Use permanent redirects (301 or 308).

Keep the map in a spreadsheet with old URL, new URL, redirect type, priority and test status.

Phase 3: Build and check staging (2–4 weeks before)

Check the new site before it goes live. Block staging from indexing with authentication, not just robots.txt.

Content

Key pages keep their main content, headings and internal links.
Titles and meta descriptions are carried over or deliberately improved.
Images keep their alt text.
Facts such as prices, services and locations are unchanged.

Technical

Canonical tags point to the new URLs.
Meta robots tags are correct: nothing important is noindexed.
Structured data is present and valid.
hreflang annotations, if used, point to new URLs.
Internal links point directly to new URLs, not through redirects.
XML sitemaps list new canonical URLs.
Core Web Vitals are no worse than on the old site.

AI readiness

Important content is present in the raw HTML. New front ends often move content into client-side JavaScript, which most AI crawlers cannot read. See can AI crawlers read JavaScript?.
The new robots.txt allows AI search and user agents as the client intends. See AI crawler user agents.
Bot protection on the new hosting does not block AI search crawlers.

Redirect testing

Test the redirect map against staging, checking every high-value URL and a sample of the rest.
Confirm no chains, loops or redirects to 404s.

Phase 4: Launch day

Launch at a low-traffic time with the team available for several hours.
Deploy redirects at the same moment the new site goes live.
Remove staging protection and any noindex or robots.txt blocks from the live site.
Crawl the old URL list immediately and confirm every URL redirects to the right place with one hop.
Submit new sitemaps in Search Console.
Use the Change of Address tool in Search Console for domain changes.
Keep the old sitemap available briefly so crawlers discover the redirects faster, then remove it.
Check analytics and tag manager are firing on the new site.
Spot-check priority pages for content, titles, canonicals and schema.

Phase 5: Monitor (launch to 3 months)

First week, daily

Search Console coverage and indexing reports for errors.
404s in Search Console and server logs; fix missing redirects immediately.
Server errors and response times.
Organic traffic and conversions against the baseline.

First month, weekly

Rankings for tracked keywords.
Indexed page count for old and new URLs.
Crawl stats and log data for Googlebot and AI crawlers.
AI visibility on the prompt set: are citations moving to the new URLs?

Months two and three

Compare traffic, rankings and conversions with the baseline and with seasonal trends.
Update external links you control, such as social profiles, directories and partner sites.
Ask key referring sites to update links to new URLs where it matters.

Migration timeline at a glance

When	Key tasks
8 to 4 weeks before	URL inventory, value per URL, baselines, scope and freeze rules
6 to 3 weeks before	Redirect map, content and template mapping
4 to 2 weeks before	Staging build and full QA, including raw HTML and crawler access
1 week before	Redirect test on staging, launch plan, rollback plan, sign-off
Launch day	Deploy, remove staging blocks, crawl old URLs, submit sitemaps, Change of Address if needed
Week 1	Daily monitoring and fast fixes
Weeks 2 to 12	Weekly monitoring, external link updates, reporting

Who does what

Migrations involve several teams, and gaps between them are where problems hide. Agree ownership in writing.

Task	Typical owner
URL inventory and redirect map	SEO lead
Redirect implementation	Developers or hosting team
Content migration and checks	Content team, reviewed by SEO
Staging QA	SEO and QA together
Launch go or no-go	Project lead with SEO sign-off
Post-launch monitoring	SEO lead, reporting to the client

A clear rollback plan, agreed before launch, means a serious problem on launch day can be reversed quickly instead of debated.

What to tell the client

Set expectations before launch: a short dip in rankings and traffic is normal and usually recovers within weeks for well-executed migrations. Agree what level of change would trigger an investigation, and report weekly for the first month.

Common migration mistakes

Launching without a complete redirect map.
Redirecting everything to the homepage.
Leaving noindex or robots.txt blocks from staging on the live site.
Losing content in the redesign, particularly text that supported rankings.
Moving content into client-side JavaScript, making it invisible to AI crawlers.
Changing everything at once, making problems hard to diagnose.
Removing redirects a few months later.

A worked example

A fictional retailer moved from one e-commerce platform to another, changing product URL structures. The team built a redirect map of 14,000 URLs from crawl, Search Console, analytics and backlink data, tested it on staging, and found that the new theme loaded product descriptions with JavaScript. They fixed that before launch. On launch day, a crawl of the old URL list found 230 URLs redirecting to the homepage because of a pattern error, which was corrected within the hour. Organic traffic dipped 8% in the first two weeks and recovered fully by week five, and AI citations moved to the new product URLs within the first month.

How Rankwyn helps

Rankwyn records a pre-migration baseline across rankings, traffic and AI citations, checks staging for missing content, canonicals, schema and AI crawler access, tests redirect maps, and monitors the new site daily after launch. For WordPress SEO plugin changes, the migration tool imports and verifies data automatically.

Key takeaways

Inventory every URL from several sources and record each one's value before planning.
Build a one-to-one permanent redirect map and test it on staging and again on launch day.
Check content, titles, canonicals, schema, crawler access and raw HTML on staging before launch.
Monitor daily in the first week and weekly for the first month, including AI citations.
Keep redirects in place for at least a year, ideally indefinitely for valuable URLs.

The bottom line

Migrations fail because of what gets missed, not because search engines punish change. Inventory everything, map every URL, test before and after launch, check that the new site is readable by AI crawlers, and watch closely for three months. Done that way, most migrations recover quickly and some come out ahead.