Website migrations can bring feelings of both excitement and impending doom. Why? Whenever major changes are made on a website, there is a risk that it can significantly impact organic traffic if not completed correctly. Fortunately, there are steps you can take to protect your rankings during the migration process.
I built this guide from lessons learned completing 23 website migrations across enterprise organizations, universities, SaaS companies, associations, and franchise systems, plus the work of cleaning up SEO for migrations other vendors handled badly.
Before we jump into the process, the top issues, the best practices, and the checklist, let’s first get a better understanding of what exactly an SEO migration is.
TL;DR: An SEO migration is the process of planning and executing the transfer of your existing domain authority, ranking signals, and search engine visibility to a new website or URL structure. In 2026, it also means preserving entity trust and AI citations, because a migration can cost you visibility in AI Overviews and LLM answers even when every redirect fires correctly. The approach is phased: plan, audit and benchmark, review pre-launch, execute on launch day, verify post-launch, then monitor for months rather than days.
What is an SEO migration?
An SEO migration is a process of creating a plan and executing the transfer of your existing domain authority, ranking signals, and search engine visibility to your new website or new website URL structure.
When completed correctly, you will see minimal traffic loss in the short term and the ability to increase your organic traffic numbers as time progresses.
In 2026, that definition needs one extension. You are no longer only transferring ranking signals. You are also transferring entity trust: whether AI systems still recognize your brand as the same thing after the move, and whether they still cite you when someone asks a question in your category. A migration can preserve every redirect and still cost you AI visibility, and almost nobody is measuring for it.
The technical case for careful redirect handling is well established. Zhukovskii et al. (2013) demonstrated empirically that the method used to account for redirects measurably affects PageRank and link-based ranking outcomes. That is the research foundation for why a clean, one-to-one 301 map preserves link equity and why sloppy redirect handling silently erodes ranking signals.
Now let’s look at some of the top SEO migration issues I see, and the stage-based approach to the migration process.
What are the types of website migrations?
There are eight common migration types, plus one that did not exist as a category concern until AI search arrived. The AI and entity risk column is the 2026 addition, and it is where most teams have no plan at all.
| Migration type | What changes | SEO risk | AI / Entity risk |
|---|---|---|---|
| Site protocol change | HTTP to HTTPS | Low | Low |
| Domain name change | Full URL change to a new domain | High | High. Off-page citations point at the old domain. AI systems may not connect the new one to your entity. |
| Subdomain change | Adding a section on your main domain | Medium | Medium. Entity association splits across two hostnames. |
| Top-level domain change | The TLD after the root domain | High | High. Same citation and recognition problem as a domain change. |
| CMS replatforming | Templates, URL structure, rendering method | High | High. Schema often does not carry over. New platforms frequently introduce client-side rendering that AI crawlers cannot read. |
| Site redesign | Layout, content, media, code | Medium | Medium. Template changes break extractable formatting and structured data. |
| Site structure change | Taxonomy, navigation, internal linking | High | Medium. Anchor text changes alter the semantic context AI systems use. |
| Hybrid combination | Any combination of the above | High | High. Risk compounds. |
| Entity or branding change | Company name, product names, rebrand | Medium | Highest. URLs can redirect perfectly while AI systems lose track of who you are entirely. |
As a word of caution: the more changes you make at once, the greater the risk of negative SEO impacts. That was true in 2021, and it is more true now, because you have added a second class of failure that does not show up in your rankings report. So at this point, you should have a solid understanding of what exactly an SEO migration is and the different types of website migrations.
Now let’s uncover the top migration issues and how to avoid them.
What are the most common SEO migration issues?
Twenty-three migrations, plus the cleanup work on migrations other vendors handled, surface the same problems repeatedly.
Technical SEO issues
Technical SEO is the foundation of any website and must be executed correctly if you want the opportunity to rank. Three issues account for most of the damage.
Internal linking issues. When websites are redesigned, there is always a desire to re-examine the main navigation. Changes there can drastically alter the internal linking structure and lead to organic traffic loss. Some changes are necessary, and there will always be changes during migrations. Just limit the number of them, especially in the main navigation.
Google views a site’s main navigation links as a strong ranking signal. Dramatic changes break existing link equity, which has adverse effects throughout the site.
Redirect issues. Make sure you are redirecting pages to the proper place. If a page no longer exists, find a closely related match. You want to pass as much link equity as possible from the old page to the new. Pointing a batch of unrelated pages back to the homepage is unacceptable and will lose link equity.
The scale of this problem across the web is worse than most practitioners assume. Garg et al. (2025) analyzed 11 million redirecting URLs, following each up to 10 hops. Half terminated successfully. The other half resulted in errors, with redirect chains, sink URLs, and soft 404s degrading both SEO performance and user experience. That is a coin flip on live production websites, which tells you how routinely this gets handled badly.
Canonical tag issues. The most common canonical problem is canonicalization pointing back to the old website. Doing this prevents search engines from indexing the new site. I recommend self-canonicalizing all pages on the new website, unless a page should legitimately be canonicalized to another page.
Content related issues
After technical problems, the next big mistake is content. Do not change your on-page content during the migration. Some minor changes are fine, but the bulk of your content should remain the same. Google already has to re-evaluate your new website and templates. Making content changes on top of that removes an important stable element.
You only want to change one thing at a time. That way it is easier to identify the cause of any organic traffic loss. If significant content changes are planned, wait three to four weeks after launch before making them.
New AI-era migration risks
These four did not exist as migration concerns in 2021. They are now among the most damaging, and the reason they are dangerous is that none of them show up in a rankings report.
Entity drift. Your brand name, product names, or positioning change during the migration, and AI systems stop recognizing you as the same entity. Redirects fire perfectly. Rankings hold. And ChatGPT starts describing a company that no longer exists.
Crawler parity failures. Your staging environment and production site serve different HTML, or your production site serves different content to different user agents. AI crawlers see something other than what Googlebot sees, and you have no visibility into the gap.
Schema and structured data loss. Structured data does not transfer automatically between platforms. FAQPage, HowTo, Organization, Product, and BreadcrumbList markup all need to be rebuilt explicitly in new templates. A migration that drops schema loses rich results and possible AI extractability in the same stroke.
JavaScript-rendered content invisible to AI bots. Googlebot renders JavaScript. Several AI crawlers do not, or do so with significant limitations. A replatform that moves your primary content into client-side rendering can leave your pages effectively blank to the systems generating AI answers.
Let’s now look at the best practices that prevent these problems.
SEO website migration best practices
Following these will lay the groundwork for the migration to be implemented properly, allowing your website to hold its current rankings and increase visibility after the new site launches. You will see these woven through the six stages below.
Build a technical SEO framework document
Define the SEO requirements the new website must meet to be successful. Once the document is complete, share it with the development team. This way, the site gets built with those requirements in mind instead of receiving them as a rushed afterthought.
Include structured data explicitly in this document. Schema is the most commonly forgotten requirement in a replatform, and adding it after launch costs several times what building it in costs.
Benchmark your organic keywords
Benchmark the current keyword footprint of your website for at least three months before migration. That gives you enough data to properly analyze keyword movement after the migration completes.
Benchmark your AI citation baseline
This is the 2026 companion to keyword benchmarking, and almost nobody does it. Take the 25 to 45 questions your best content answers. Ask each one in ChatGPT, Perplexity, Gemini, and Google with AI Overviews enabled. Record whether your brand is cited, which URL is cited, and which competitors appear alongside you. That record is your baseline.
Without it, you cannot tell whether a migration cost you AI visibility, because there is no report anywhere that will tell you. Gao et al. (2023) established the mechanism this baseline is measuring: AI systems retrieve supporting evidence and generate answers with citations, and citation quality is measurable.
Their ALCE benchmark exists precisely because whether a system cites a source correctly is a testable property, not a mystery. You can test it on your own brand in about 20 minutes.
Identify top-performing assets
Use these metrics to identify the assets that will play a vital role in the success of your migration:
- Pages with high organic traffic
- Pages with the strongest backlink profiles
- Pages with the highest conversion rates
- Pages with the most organic search impressions
You can find all of this using GA4, Google Search Console, Bing Webmaster Tools, and Ahrefs or your preferred backlink tool.
Document entity changes, not just URLs
If your migration involves a name change, product renaming, or a rebrand, build an entity change document alongside your redirect map. This includes, old name, new name, where the old name appears off-site, and which third-party sources need updating.
A redirect tells a crawler where a page moved. It does not tell an AI system that the company formerly called X is the company now called Y. That connection has to be built through consistent naming, schema, and updated off-page references.
Verify your analytics and Search Console setup
Make sure data is being tracked correctly in GA4 and Google Search Console for every property associated with the site being migrated. This data is necessary for evaluating whether the migration succeeded and how long it takes to return to pre-migration traffic levels.
If you are running separate properties for subdomains or country versions, verify each one independently. The first time you need this data is the worst possible time to discover it was not being collected.
Set your content approach
Once you are within three weeks of the migration, freeze all significant content changes on the live site. No page rewrites, no metadata overhauls, no structural content reorganization. If large portions of your content are changing as part of this project, make those changes post-migration, after search engines have had the opportunity to reindex the new site and results start to normalize.
Here is why the sequencing matters. A migration already introduces multiple variables at once: new platform, new templates, new URL structure, possibly a new domain. Layer significant content changes on top and, if rankings drop, you have no way to identify the cause. Was it the redirect map? A canonical issue? The template change? The content rewrite? When everything changes simultaneously, diagnosis becomes guesswork, and guesswork costs time and traffic.
The correct sequence is straightforward. Complete the migration, including any template changes, as one event. Let Google recrawl and reindex. Monitor until rankings and traffic stabilize, typically two to four weeks for a clean migration. Then make your content changes as a separate, deliberate phase. Each phase becomes its own controlled test, and every ranking movement becomes diagnosable.
Separate the variables whenever you can.
Build a complete redirect plan
There needs to be a complete redirection plan in place so search engines understand your content has moved and link equity passes to the new website. If either of those does not happen, your migration will fail.
One-to-one mapping. Every old URL to its specific new destination. No chains, no mass redirects to the homepage.
| Old URL | New URL | Status | Notes |
|---|---|---|---|
| /services/seo-audit | /services/technical-seo-audit/ | 301 | 42 referring domains, priority page |
| /blog/old-post-name | /resources/new-post-name/ | 301 | Consolidating two posts, both redirect here |
| /events/2021-conference | /resources/ | 301 | No equivalent page, zero backlinks |
Maintain descriptive internal anchor text
Internal link anchor text carries semantic context. “Click here” tells an AI system nothing about what it is about to read. “Our keyword difficulty baseline methodology” tells it exactly what the destination covers and how it relates to the current page.
Migrations frequently flatten anchor text when navigation gets rebuilt from a design file. Audit for it before launch.
Now let’s cover the entire process step by step.
The six-stage website migration process
I break the process into six distinct stages. Each stage informs the next, and each contributes to the overall success of the migration.
Stage 1: Preliminary strategy and planning
In the preliminary strategy and planning stage, it is imperative that you uncover the main objective and all secondary objectives of the migration. This lets you start building a strategy to accomplish those goals while setting expectations around risk versus opportunity.
Include all stakeholders at this stage: internal and external SEO strategists, creative designers, the analytics team, and solutions architects. You need to move into the next stage with a prioritized list of action items for the project.
2026 addition: define your AI visibility goals here alongside your ranking goals, and capture the AI citation baseline as a planning input rather than an afterthought. If leadership cares about being cited in AI answers, that requirement belongs in the technical requirements document the development team receives, not in a conversation three months after launch.
Stage 2: Audits and benchmarking
The audits and benchmarking stage gives you a clear picture of the website’s current SEO condition. The insights inform what needs to happen during the new build.
Technical SEO audit
Complete an in-depth technical audit to understand the site’s current condition. From it, create an SEO requirements document and provide it to the project manager and development team. Requirements to cover include:
- Proper URL structure
- Page titles
- Metadata
- Canonical directives
- Structured data markup
Structured data inventory
2026 addition. Document every page that currently carries schema and every schema type in use. FAQPage, HowTo, Article, Organization, Product, BreadcrumbList, LocalBusiness.
Run a Screaming Frog crawl with structured data extraction enabled and export the full inventory. This becomes a build requirement for the new templates and a verification checklist for launch day. Schema does not migrate on its own, and a rich result you lose is a rich result a competitor gains.
Full website content audit
Complete a content audit on all indexable pages for medium to large websites, or for any project combining multiple sites or subdomains. This uncovers keyword cannibalization, underperforming assets, and dead-weight content. The goals are:
- Identify dead weight content
- Eliminate cannibalization
- Consolidate link equity
- Flag key pages for improvement
Keyword visibility audit and tracking
A keyword audit must be completed to benchmark existing rankings. After launch, this data plays a key role in determining whether the migration succeeded, or in identifying what went wrong.
The goals of this audit:
- Establish your current keyword difficulty baseline
- Identify top-performing assets
- Export every keyword ranking in the top 10 positions
- Build a matrix of keyword counts by position bucket
| Position bucket | What it measures | Why it matters |
|---|---|---|
| Positions 1 to 3 | Your strongest ranking assets | These drive the majority of clicks. A drop here has immediate traffic impact. |
| Positions 4 to 10 | Page one rankings with growth potential | High value and recoverable quickly with proper execution. |
| Positions 11 to 100 | Indexation and topical presence | Lower priority, but important for tracking your overall ranking footprint. |
Record the exact keyword count in each bucket before launch. Pull the report from Ahrefs using the Organic Keywords filter segmented by position range. After launch, run the same report weekly for the first month. You are looking for those distributions to return, not just for total traffic to recover.
Pro Tip: Save your top 10 rankings as a keyword list in Ahrefs before launch. After the migration, you can run a rank comparison against the same list in one click and see exactly which keywords moved, by how much, and in which direction. This saves hours of manual comparison during post-launch monitoring.
Website performance benchmarking
Page load speed directly impacts rankings and organic traffic, so the current site’s performance must be benchmarked. In 2026, the measurement framework is Core Web Vitals, and one of the three metrics has changed since this guide was first published.
| Metric | What it measures | Good | Poor |
|---|---|---|---|
| Largest Contentful Paint (LCP) | How fast the main content loads | Under 2.5s | Over 4s |
| Interaction to Next Paint (INP) | How quickly the page responds to input | Under 200ms | Over 500ms |
| Cumulative Layout Shift (CLS) | Visual stability as the page loads | Under 0.1 | Over 0.25 |
Note: INP replaced First Input Delay in March 2024. If your benchmarking template still tracks FID, update it. You are measuring something Google no longer uses.
Use two tools together. Google PageSpeed Insights gives you lab and field data for individual URLs, and you should record mobile and desktop separately because a page that passes on desktop can fail on mobile. The Core Web Vitals report in Google Search Console gives you field data aggregated across real user sessions, which is the data Google actually evaluates.
Benchmark at minimum:
- The homepage, mobile and desktop
- Your top 20 performing assets, mobile and desktop
- Important category or product pages
- A representative sample of content pages from each template
Proposed wireframes review
By this point, wireframes of the new website should be available. An SEO specialist should review them and flag any potential issues for the team. The goals are to identify pitfalls and provide recommendations before anything gets built.
Add two checks to this review in 2026. Does the template surface primary content early in the page body, or does it bury it beneath navigation and decorative elements? And does the heading hierarchy hold up, with one H1 and a logical H2 and H3 structure? Both affect whether AI systems can extract your content cleanly.
Stage 3: Pre-launch review
About two weeks before launch, start pre-launch testing. Use a migration checklist to thoroughly review the new site and identify issues. Record every issue found, triage in order of importance, and hand the list to the project manager for correction.
What to review during pre-launch:
- Robots.txt file
- Canonical tags
- Sitemaps
- Metadata
- Internal linking
- All redirects mapped and tested
2026 additions:
- Crawler parity. Confirm staging serves identical content and HTML to traditional and AI crawlers. Fetch key pages with different user agents and compare the rendered output.
- Server-side rendering verification. View source on your priority pages, not the inspector. If your primary content is not in the raw HTML, JavaScript-limited AI crawlers cannot read it.
- Schema validation on staging. Run every template through Google’s Rich Results Test and compare against the structured data inventory from Stage 2.
- llms.txt prepared. If you are implementing one, have the file ready to deploy at launch rather than adding it weeks later.
Verify that staging itself is blocked from indexation: password protected, noindex tags in place, and robots.txt disallowing crawlers. I have seen staging environments accidentally indexed more times than I care to count.
Stage 4: Launch day review
Once the site goes live, it’s go time. Quickly check the following items.
- HTTP status codes. Do you see any server errors?
- Robots.txt. Make sure search engines can crawl the site.
- Check noindex tags. Make sure search engines have not been accidentally restricted.
- Verify canonicalization. Self-canonicalize all new site pages unless they should be canonicalized to another page.
- Test your redirects. Are they working as they should?
- High priority assets. Manually review every high-priority page for errors.
- GA4. Are you collecting data? Verify events are firing, not just pageviews.
- Search Console. Submit your updated sitemap, then use the URL Inspection tool to request indexing for your priority pages.
Update note: this guide previously recommended the “Fetch as Google” feature. Google retired it. URL Inspection is the current tool, and it has a daily quota, so work through your priority pages over several days rather than trying to submit everything at once.
2026 additions to launch day:
- Confirm AI bot access. Check that robots.txt permits the crawlers you intend to allow: GPTBot, Google-Extended, PerplexityBot, ClaudeBot. These are separate agents from Googlebot. A default robots.txt from a new host may block them, and nothing in your rankings will tell you it happened.
- Verify schema renders on production. Spot-check each template against the Stage 2 inventory using the Rich Results Test.
- Spot-check server-side rendering. View source on five priority pages and confirm the primary content is in the raw HTML.
- Spot-check internal links. Manually check links on your top 20 to 30 pages. They should point to new production URLs, not staging URLs and not old ones. Links pointing at staging after launch happens constantly.
Once you have completed the items above, recrawl the site and review any issues found. This is also a good time to run performance tests for desktop and mobile.
Important note: the day before and the day of launch, make sure Google is not currently running an algorithm update. If they are, postpone. Typically three to five days after the update finishes, which allows search results to re-settle. If you launch during an update and see a dramatic traffic loss, it will be extremely difficult to diagnose the cause.
Stage 5: Post-launch review
Re-run all the tests you completed on launch day. Test your redirects thoroughly. Screaming Frog makes auditing redirects straightforward: paste your old URLs into list mode, crawl against production, and verify every one returns a 301 to the correct destination.
Now that the site has been live for a few days and Google has had the opportunity to recrawl the old sitemap and notice changes, submit the new sitemap in Google Search Console.
While you are there, pull up the crawl stats report under Settings. You are looking for a noticeable spike in crawl requests per day after launch. That increase tells you Google has detected the changes and is actively reindexing. If you do not see that spike within the first 48 to 72 hours, something is likely blocking the crawler. Check robots.txt, verify noindex tags are not present on production, and resubmit your sitemap.
2026 additions:
- Re-check your AI citation baseline. Run the same 10 to 15 questions from Stage 1 through ChatGPT, Perplexity, Gemini, and Google. Are you still cited? Did the cited URL update to the new structure or is it still pointing at the old one?
- Verify AI bot access in server logs. Filter your logs for GPTBot, PerplexityBot, ClaudeBot, and Google-Extended. If they were hitting the old site and have gone silent, something is blocking them.
- Begin updating off-page citations. Third-party mentions, directory listings, partner pages, and press references pointing at old URLs. These are the authority signals feeding AI retrieval, and they do not update themselves.
That last point has research behind it. Masanneck et al. (2025), studying web-retrieval-assisted language models in a clinical context, found that restricting retrieval to authoritative sources improved correct-answer rates by 8 to 18 percentage points, and that including even one non-authoritative source halved the odds of a high-quality answer.
That study measured medical answer accuracy rather than brand visibility, so it does not tell us anything directly about marketing outcomes. What it does establish is that the authority of the sources an AI system retrieves measurably changes what it produces. Your off-page citations are part of that source pool.
Stage 6: Performance review and monitoring
Once the migration is complete, search engines take time to recrawl and reindex. During this period, it is common to see keyword fluctuations and some organic traffic loss. Don’t panic. Depending on the size of the site, it can take a few weeks to a few months for things to settle.
In most cases, after two months, you can start to measure and compare the new site’s visibility against previous numbers. This is when your Stage 2 benchmarking comes into play. Re-run:
- The technical SEO audit
- The keyword visibility audit, including the position bucket matrix
- Website performance metrics against your Core Web Vitals baseline
- Your AI citation baseline
Compare before and after in GA4. Note that the metrics changed with the move from Universal Analytics: bounce rate and average time on page have been replaced by engagement rate, engaged sessions, and average engagement time. Look at those alongside organic traffic, session counts, and 404 hits.
To isolate organic performance in GA4, go to Reports, then Engagement, then Landing Page. Set your date range to cover both the pre-migration and post-migration periods and filter by Session Default Channel Group matching Organic Search.
Finally, review your backlink profile. Use Ahrefs or Semrush to check for broken links and manage redirects accordingly.
Monitoring cadence
| Timeframe | Frequency | What to check |
|---|---|---|
| Days 1 to 3 | Multiple times daily | GSC coverage errors, redirect validation, crawl stats, indexation of priority pages |
| Week 1 | Daily | Organic traffic by page vs. baseline, ranking movement on priority keywords, new 404s |
| Weeks 2 to 4 | Weekly | Traffic recovery trend, position bucket comparison, 404 cleanup, AI citation spot-check |
| Months 2 to 3 | Monthly | Full benchmark comparison, backlink profile, Core Web Vitals, AI citation baseline re-run |
How do you protect AI search visibility during a migration?
This is the section that did not exist when I first published this guide, and it is now the difference between a migration that holds and one that quietly costs you visibility nobody is measuring.
Traditional migration checklists protect rankings. They do not protect citations. Those are different problems with different failure modes, and the AI failure mode is worse because it is invisible in every report you currently run.
Map entity changes, not just URLs: If your brand name, product names, or positioning are changing, document those changes alongside your redirect map. Old name, new name, where the old name appears across the web, and which sources need updating. A 301 moves a page. It does not tell an AI system that the company formerly known as X is now Y.
Benchmark AI citation baselines before launch: Covered in the best practices section above. Do it before you change anything, because you cannot measure recovery against a baseline you never captured.
Validate crawler parity: Staging and production must serve identical content and HTML, and production must serve the same content regardless of user agent. Fetch your priority pages as Googlebot, as GPTBot, and as a standard browser, then compare. Differences here are silent and severe.
Ensure server-side rendering for primary content: Googlebot renders JavaScript. Several AI crawlers do not, or do so with limits. View source on your key pages. If the content is not in the raw HTML, the systems generating AI answers may not see it at all. This is the single most common way a replatform destroys AI visibility while leaving rankings intact for a while.
Control crawler access deliberately: Update robots.txt with explicit rules for GPTBot, Google-Extended, PerplexityBot, and ClaudeBot. Decide whether you want each one, then write the rule. Inheriting a default file from a new host is how sites disappear from AI search without anyone noticing.
Set up llms.txt: A file at your root that routes AI crawlers toward your most important documentation and source content. Adoption is still early, and it is not a standard Google has committed to, so treat it as low-cost insurance rather than a critical path item. It takes an hour.
Maintain descriptive internal anchor text: Anchor text is semantic context. Rebuilt navigation frequently flattens it into generic labels.
Preserve off-page citation signals: Audit third-party mentions, directory listings, partner sites, and press coverage that link to your old URLs. Update the ones you can reach. These references are part of the source pool AI systems retrieve from, and letting them decay costs you more than it costs to fix.
Format content for extraction: Gao et al. (2023) showed that AI systems retrieve supporting evidence and generate answers with citations, and that citation quality can be measured directly. Content structured for clean extraction gets cited more reliably: answers up front, descriptive headings, short paragraphs, tables where the content is tabular, and explicit question-and-answer blocks.
Template redesigns routinely destroy all of this in the name of visual polish. Check it before launch, not after.
How much traffic will you lose, and how long until recovery?
Every migration produces a temporary dip. The question is how deep, how long, and whether what you are seeing is normal or a signal that something is broken.
| Migration type | Expected traffic dip | Expected recovery |
|---|---|---|
| Protocol change (HTTP to HTTPS) | Minimal, 0 to 10% | 2 to 4 weeks |
| Site redesign | 5 to 20% | 1 to 3 months |
| CMS replatforming | 10 to 30% | 2 to 4 months |
| Domain name change | 10 to 40% | 2 to 6 months |
| Hybrid combination | 15 to 40% | 3 to 6 months |
What is normal: a 5 to 10% dip in the first two weeks is ordinary reindexing behavior. Traffic trending upward week over week after that first fortnight means the migration is working.
What is not: a drop deeper than 30% that is not recovering after two weeks. Large numbers of priority pages showing as not indexed in Search Console. 404 errors that keep appearing rather than tapering off. Rankings for multiple priority keywords dropping more than 15 positions at once.
When you hit those thresholds, check in this order: robots.txt and noindex tags on production, then indexation status in Search Console, then the redirect map, then canonical tags. The cause is almost always one of those four.
Reporting cadence for stakeholders
Set expectations before you launch, not after the traffic graph moves. The dip is coming, and a stakeholder who was told to expect it reads it as a plan working. A stakeholder who was not reads it as a failure.
- Week 1, daily: crawl errors, redirect validation status, indexation progress, early traffic trend
- Month 1, weekly: recovery trend, ranking stability on priority keywords, 404 resolution, GSC coverage
- Months 2 to 3, monthly: full benchmark comparison against pre-migration numbers, including AI citation recovery
SEO website migration checklist
Use this checklist as you prepare for your migration. Working from a list is the most reliable way to make sure nothing gets missed.
Technical SEO checks
- Robots.txt file
- Canonical tags
- Meta robots attribute
- Sitemaps
- Open Graph protocol
- Structured data
- Page titles
- Meta descriptions
- Internal linking
Redirect testing
- Crawl your site
- Review redirects for top-performing assets
- Review server responses
- Check for and flatten redirect chains
Analytics and Search Console
- GA4 tracking tags in place and events firing
- Domain property verified in Search Console
- Sitemap submitted
- Priority pages submitted through URL Inspection
Update note: “Preferred domain” was retired in Search Console. Verify a domain property instead.
Performance review
- Core Web Vitals benchmarked: LCP, INP, CLS
- Mobile and desktop measured separately
- Mobile-friendliness confirmed
AI and GEO checks (new for 2026)
- Entity changes documented alongside the redirect map
- AI citation baseline recorded before launch
- Robots.txt rules set deliberately for GPTBot, Google-Extended, PerplexityBot, ClaudeBot
- llms.txt live
- Structured data inventory taken pre-launch and validated post-launch
- Crawler parity confirmed between staging and production
- Server-side rendering verified on priority pages
- Internal anchor text reviewed for descriptiveness
- Off-page citations audited and updated
[Download the Free SEO Migration Checklist and Template]
Now It’s Your Turn
I hope you enjoyed this step-by-step guide to SEO for migrations. Now I’d like to hear from you.
What section did you find the most helpful? Was it the six-stage process, the new AI visibility section, or the traffic expectation benchmarks you can take to your leadership team?
Whichever one worked, let me know by leaving a comment below. And grab the free checklist above before your next migration.
References
Gao, T., Yen, H., Yu, J., & Chen, D. (2023). Enabling large language models to generate text with citations. In Proceedings of the 2023 Conference on Empirical Methods in Natural Language Processing (pp. 6465–6488). Association for Computational Linguistics. https://doi.org/10.18653/v1/2023.emnlp-main.398
Garg, K., Nelson, M. L., & Weigle, M. C. (2025). Not here, go there: Analyzing redirection patterns on the web. In Proceedings of the 17th ACM Web Science Conference 2025 (pp. 380–390). Association for Computing Machinery. https://doi.org/10.1145/3717867.3717925
Masanneck, L., Epping, P. Z., Meuth, S. G., & Pawlitzki, M. (2025). Evaluating web retrieval–assisted large language models with and without whitelisting for evidence-based neurology: Comparative study. Journal of Medical Internet Research, 27, e79379. https://doi.org/10.2196/79379
Zhukovskii, M., Gusev, G., & Serdyukov, P. (2013). URL redirection accounting for improving link-based ranking methods. In Advances in Information Retrieval (ECIR 2013) (pp. 656–667). Springer. https://doi.org/10.1007/978-3-642-36973-5_55