How to Migrate a Website Without Losing SEO: Complete Checklist

A website migration can look like a design project.

From the outside, you may be changing the platform, rebuilding the layout, moving content, or launching a new domain.

From an SEO perspective, the risk is different.

Google already knows a set of URLs, topics, links, dates, and page relationships. A successful migration preserves those signals while moving the site to a new technical structure.

I learned this while moving AI Workbench Lab content from Blogger into a modern Next.js site.

The visual rebuild was not the difficult part.

The higher-risk work was making sure old URLs still led somewhere useful, important content stayed discoverable, metadata remained clear, and Google could understand the new site without starting from zero.

This is the migration process I would use again.

Quick answer: how to migrate a website without losing SEO

Before launch:

1. Record current clicks, impressions, rankings, indexed pages, and top landing pages.
2. Export or back up every important page, post, image, and metadata field.
3. Create a one-to-one map from old URLs to new URLs.
4. Keep existing URLs where possible.
5. Use permanent 301 redirects when URLs must change.
6. Preserve search intent, titles, headings, dates, canonical signals, and important content.
7. Update internal links so they point directly to final URLs.
8. Launch with robots.txt, canonical tags, structured data, and an XML sitemap already working.

After launch:

1. Submit the sitemap in Google Search Console.
2. Inspect priority URLs and monitor indexing, 404s, clicks, impressions, and rankings.
3. Fix migration errors before making large unrelated content changes.

The platform can change.

The relationship between each important old URL and its replacement should remain clear.

1. Establish a baseline before the migration

The first mistake is migrating without recording what is already working.

If traffic drops after launch, you need to know whether the change is normal short-term movement or a real technical problem.

Before migrating, record:

• organic clicks and impressions for the last 28 and 90 days
• top landing pages
• top search queries
• average positions for important queries
• indexed page count
• pages receiving backlinks
• known 404s and crawl errors
• Core Web Vitals or performance data where relevant

For a small site, a spreadsheet is enough.

For a larger site, export the data from Search Console, analytics, and your crawler.

The point is simple:

Do not measure the migration from memory.

Measure it against a saved baseline.

2. Decide exactly what is changing

Not every migration has the same risk.

You may be changing:

• hosting only
• CMS or framework
• URL structure
• domain
• site architecture
• design
• content
• several of these at once

The more things you change at the same time, the harder it becomes to diagnose a drop.

If possible, separate the changes.

For example:

Lower risk: move from one platform to another while preserving URLs and content.

Higher risk: change platform, domain, URL structure, navigation, article copy, and page titles in the same launch.

When several changes are unavoidable, document them before launch so you know what to investigate later.

3. Back up the content and metadata

A platform export is useful, but I would not assume it contains everything in the form I need.

For my Blogger migration, I wanted to preserve more than article text.

Back up:

• page and post content
• titles
• meta descriptions
• publication dates
• updated dates
• categories or labels
• images
• image URLs
• internal links
• important external links
• author information
• old URL paths
• comments if they matter to the project

If you are leaving an older platform, keep the export even after the new site is live.

Migration problems are easier to fix when the source material is still available.

4. Build the URL migration map before launch

This is the most important document in the migration.

Create a table like this:

| Old URL | New URL | Action | Final status | Notes | | --- | --- | --- | --- | --- | | Old article | Same article on new site | 301 | 200 | Direct equivalent | | Old About page | New About page | 301 | 200 | Same purpose | | Removed article | Relevant replacement or 410 | Review | Review | Do not send blindly to homepage |

Every valuable old URL should have an intentional outcome.

If the URL can stay the same, that is usually simpler.

If it must change, map it directly to the closest equivalent page.

Avoid redirecting every old page to the homepage. A homepage is usually not a relevant replacement for a specific article and broad redirects can be treated as soft 404s.

5. Use 301 redirects and avoid redirect chains

When a page has permanently moved, use a permanent redirect.

Then verify:

• old URL returns a permanent redirect
• destination returns 200
• destination is the correct replacement
• destination is indexable
• canonical points to the final URL
• there is only one redirect hop

Avoid this:

old URL → temporary URL → another redirect → final URL

Prefer this:

old URL → final URL

Redirect chains make crawling and troubleshooting unnecessarily complicated.

They also make future migrations harder because old rules accumulate.

6. Preserve search intent before rewriting the article

A migration is not the best moment to completely reinvent every page that already has search visibility.

If a page ranks for a useful query, preserve the elements that explain why Google understands it:

• topic
• title meaning
• H1
• major headings
• useful sections
• publication history
• internal-link context
• important entities and terminology

You can clean up formatting and improve readability.

I would simply avoid rewriting every migrated article at the same time as the technical move.

Otherwise, if rankings change, you have two variables:

Did the migration cause it?

or

Did the content rewrite cause it?

Stabilize the migration first, then make larger editorial changes deliberately.

7. Clean old HTML without destroying structure

Legacy CMS exports often contain presentation markup that does not belong in the new system.

Blogger content, for example, can contain:

• inline styles
• unnecessary spans
• old font markup
• empty paragraphs
• inconsistent headings
• layout HTML

When I moved content into MDX, I kept the semantic structure:

• one H1 supplied by the page template
• H2 for primary sections
• H3 only for real subsections
• standard paragraphs
• proper lists
• descriptive links
• useful image alt text

The goal is not to preserve old markup.

It is to preserve the meaning of the content in a cleaner structure.

8. Check canonical tags before launch

Every important new page should point to the preferred version of itself.

For a typical migrated article:

https://www.example.com/new-article

should have a canonical pointing to that final URL.

Watch for common migration mistakes:

• canonical still points to the old domain
• every page points to the homepage
• HTTP canonical on an HTTPS page
• canonical includes a non-preferred hostname
• canonical points to a redirect
• multiple equivalent URLs remain crawlable without a clear preferred version

A redirect tells Google where an old URL moved.

A canonical helps identify the preferred version of the new content.

You often need both during a migration.

9. Update internal links to the final URLs

A 301 redirect protects old links.

It should not become your permanent internal-link strategy.

After migration, links inside the new site should point directly to the final URLs.

That reduces unnecessary redirect hops and gives search engines a cleaner picture of the site structure.

Review:

• navigation
• article-to-article links
• homepage links
• category or hub pages
• resource pages
• footer links
• image links
• old absolute Blogger URLs inside imported content

Internal linking also becomes an opportunity to improve topic clusters.

For example, AI Workbench Lab now uses My AI Website Stack in 2026 as a hub connecting related v0, Cursor, Supabase, and Vercel guides.

10. Migrate images carefully

Images are easy to forget because the article text may render correctly while old image URLs are still doing the work.

Before retiring the old platform, verify:

• every important image loads
• HTTPS is used
• image paths are stable
• alt text is useful
• image dimensions are appropriate
• large images are optimized
• pages no longer depend on temporary or private source URLs

If old image URLs have search or referral value and cannot be preserved, consider how they should be redirected or replaced.

Do not shut down the old host before confirming the new pages are no longer dependent on it.

11. Launch the technical SEO foundation at the same time

The new website should not go live first and receive its SEO foundation later.

At launch, confirm:

• XML sitemap works
• robots.txt allows important pages
• no staging noindex remains
• canonical tags are correct
• titles and descriptions are present
• one clear H1 exists
• Article structured data is valid where appropriate
• Breadcrumb structured data is valid where appropriate
• HTTPS is consistent
• preferred hostname is consistent
• 404 page works
• redirects work
• mobile pages are usable

I use the Google SEO Checklist for this final technical pass.

12. Submit the new sitemap in Google Search Console

After the production site is live:

1. Verify the correct Search Console property.
2. Submit the XML sitemap.
3. Inspect the homepage.
4. Inspect the highest-value migrated pages.
5. Confirm Google can crawl them.
6. Confirm the expected canonical is selected.
7. Review indexing reasons for URLs that remain excluded.

Manual indexing requests can help with priority pages.

They are not a substitute for a crawlable internal-link structure and a correct sitemap.

13. Monitor the first few weeks

Some movement after a migration is normal.

The goal is not zero fluctuation.

The goal is to see discovery and visibility stabilize without technical loss.

Watch:

• indexed pages
• discovered but not indexed pages
• crawled but not indexed pages
• 404 errors
• redirect errors
• canonical mismatches
• impressions
• clicks
• average position
• priority landing pages
• old URLs still receiving backlinks

Compare those numbers with the baseline.

Do not only watch total traffic.

A total can look stable while one important page disappears.

14. Fix migration errors before adding more variables

If a migrated page loses visibility, I check in this order:

1. Does the old URL redirect correctly?
2. Does the new URL return 200?
3. Is it indexable?
4. Is the canonical correct?
5. Is it in the sitemap?
6. Is it internally linked?
7. Did the page content or title change significantly?
8. Did Google crawl the new URL?
9. Is Google choosing another canonical?

Only after those checks would I start making broader content changes.

That sequence prevents a technical migration problem from turning into an unnecessary rewrite project.

My Blogger-to-Next.js migration lesson

The most useful lesson from moving AI Workbench Lab was that migration work is mostly about continuity.

The new site did not need to look like Blogger.

It did not need to use the same technology.

It needed to preserve the relationship between what Google already knew and where that content lived now.

That meant:

old URL → correct destination

old topic → same search intent

old content history → preserved dates and context

old internal relationships → rebuilt cleanly

Once I thought about the migration that way, the work became much easier to prioritize.

Common website migration SEO mistakes

Avoid these where possible:

• changing platform, domain, URLs, content, and design simultaneously
• deleting old URLs without mapping them
• redirecting everything to the homepage
• using temporary redirects for permanent moves
• leaving redirect chains
• forgetting pages with backlinks
• leaving staging noindex enabled
• blocking important paths in robots.txt
• publishing redirected URLs in the sitemap
• retaining canonicals to the old site
• deleting old images too early
• leaving internal links pointed at old URLs
• judging the migration after one or two days
• ignoring Search Console after launch

Website migration SEO FAQ

Can you migrate a website without losing SEO?

You can reduce the risk significantly by preserving URLs where possible, using correct 301 redirects, maintaining search intent, launching with clean technical signals, and monitoring Search Console closely. No migration can guarantee zero ranking movement.

How long does SEO take to recover after a website migration?

There is no fixed period. Google needs time to crawl redirects, process new URLs, and reassess pages. A small, clean migration may stabilize relatively quickly, while technical errors or major content changes can take longer to recover from.

Should I keep the same URLs during a migration?

Keep established URLs when the new platform allows it. If a URL must change, redirect the old URL directly to the closest equivalent new page.

Will changing from Blogger to another platform hurt SEO?

The platform change itself does not have to cause a loss. The larger risks are broken URLs, missing redirects, changed search intent, incorrect canonicals, blocked crawling, and lost internal links.

Should I request indexing for every migrated URL?

No. Submit a clean sitemap, make the site internally crawlable, and manually inspect the highest-priority pages. Repeated manual requests are not a replacement for correct site architecture.

Can I redesign the website during a migration?

Yes, but changing many variables at once increases diagnosis risk. Preserve important content meaning, URLs, metadata, and crawlability, then make larger editorial changes once the migration is stable.

Final migration checklist

Before calling the migration complete:

• [ ] Baseline search data was saved.
• [ ] Important content and metadata were backed up.
• [ ] Every valuable old URL has an intentional outcome.
• [ ] Permanent redirects point directly to final destinations.
• [ ] Important search intent was preserved.
• [ ] Canonicals point to preferred new URLs.
• [ ] Internal links point directly to final URLs.
• [ ] Images load from stable locations.
• [ ] robots.txt allows important pages.
• [ ] No accidental noindex remains.
• [ ] Sitemap contains canonical indexable URLs.
• [ ] Structured data is valid.
• [ ] Search Console property is verified.
• [ ] Sitemap is submitted.
• [ ] Priority URLs are inspected.
• [ ] Indexing and search performance are being monitored.

A successful website migration is not measured by how modern the new site looks.

It is measured by whether users and search engines can still find the content, understand it, and follow the move from each old URL to the right new destination.

Practical AI. Real Experience. Built in Public.