WebCore Pro · Blog

SEO

Can You Really Do a Website Migration Without Losing SEO

By Rigo · 2026-10-07

Can You Really Do a Website Migration Without Losing SEO

Most agencies rush bulk 301 redirects during a website redesign. Here's why documenting every URL individually, the way we did for a real migration, is what actually protects your rankings.

Can You Really Do a Website Migration Without Losing SEO?

Quick answer: Yes, but not by handing a spreadsheet of old-URL-to-new-URL mappings to an intern and calling it done. The business owners who keep their rankings through a redesign are the ones who document every single URL before touching redirects, understand what's actually changing on the backend, and accept that this process takes longer than agencies tend to admit.

Most agencies treat redirects as a numbers game

Here's what usually happens when a business redesigns its site. The agency exports a list of old URLs, matches them to new ones as fast as possible, sets up bulk 301 redirects, and moves on. The pitch sounds reasonable: redirect everything, update the sitemap, submit it to Google, done.

The problem is that this treats every URL the same way. A page that drives half your organic leads gets the same five minutes of attention as a forgotten blog post from three years ago. Speed becomes the goal instead of accuracy, and accuracy is the only thing that actually protects rankings.

If you've put years into content, service pages, and location pages, that approach should make you nervous. It made us nervous too, which is why we did it differently.

What we did for the Clearly.ca migration

Before we touched a single redirect, we ran the entire existing site through Screaming Frog and documented every URL that existed. Not a sample. Not "the important pages." Every URL, individually, so nothing got lost in a bulk mapping sheet.

This mattered more than usual because the backend architecture was changing, not just the design on top of it. That kind of shift means URL patterns, content groupings, and even how pages get generated can all move at once. A quick bulk redirect approach assumes the old structure maps cleanly onto the new one. It rarely does.

The process felt slow. There were moments it felt like overkill to check URL by URL when a spreadsheet macro could have "finished" the job in an afternoon. But that documentation step was the deciding factor in landing the migration without losing rankings. We knew exactly what existed, what it mapped to, and why, before a single redirect went live.

Why bulk redirect mapping is the wrong default

The dominant advice online treats redirect mapping as essential and urgent, almost as if the URL itself is the thing carrying your rankings. It isn't. According to Google's Search Central community, URL is a very small ranking factor and typically makes no difference on its own.

That's a genuinely contrarian point against how most redesign checklists are written. Agencies push redirect mapping as the make-or-break step, when the real risk sits somewhere else entirely: in what you redirect to, how cleanly, and whether you understand the content and value behind each old page before you decide its fate.

This doesn't mean redirects don't matter. It means the panic around getting the mapping done fast is misplaced. The panic should be about getting the mapping done right.

The real danger is redirect chains, not redirect count

The same Google Search Central guidance is specific about where quantity actually becomes a problem: redirect chains. A redirect chain happens when URL A redirects to URL B, which redirects to URL C, and so on. That's where SEO damage shows up, not simply from having a lot of 301s in place.

There's a second piece of this that most redesign guides skip entirely. Redirects increase crawl demand, because both the old URL and the new URL need to be crawled. Google's own community guidance confirms this directly, and it's the kind of detail that only shows up when you've actually mapped a full site rather than skimmed a template.

If your site has thousands of URLs and you're not careful, that extra crawl demand can starve other pages from getting crawled at all. That's a real cost of sloppy migration work, and it's rarely mentioned next to the usual "don't forget your sitemap" advice.

What documenting every URL actually buys you

Running a full crawl before redirect planning isn't busywork. It's how you catch the pages that matter before they get flattened into a generic redirect rule.

- You see every URL that currently exists, not just the ones you remember
- You catch orphaned pages that still bring in traffic or links
- You understand which URLs are structurally similar enough for a clean rule-based redirect, and which need a one-to-one decision
- You avoid building accidental redirect chains because you can see the full map at once
- You know what's changing on the backend before redirects go live, not after

That last point is the one most redesign projects skip. If the backend architecture is changing, the way URLs get generated might change too. You need that understanding before you plan redirects, not as a surprise halfway through launch.

A simple framework for your own migration

You don't need an agency's internal process to get this right. You need patience and a system.

| Step | What it involves | Why it matters |
|---|---|---|
| Full crawl | Document every existing URL with a tool like Screaming Frog | Nothing gets missed or bulk-mapped by accident |
| Backend review | Understand what's actually changing in architecture, not just design | Prevents mismatched redirect logic |
| One-to-one mapping | Map high-value and structurally unique URLs individually | Protects pages that earn real business value |
| Pattern mapping | Use rule-based redirects only for genuinely identical URL structures | Saves time without sacrificing accuracy |
| Chain check | Verify no redirect points to another redirect | Avoids the crawl and ranking damage chains cause |
| Post-launch crawl | Re-crawl the new site to confirm every redirect resolves in one hop | Confirms the migration actually held |

This isn't a fast process. But if you've spent years building content and rankings, a few extra days of documentation is a small price against losing traffic you can't easily rebuild.

If you're also rethinking the underlying platform during this move, it's worth reading about turning a vibecoded site into a real business asset before you commit to a new structure. And if duplicate or overlapping content is part of what you're cleaning up, content cannibalization is worth understanding before migration, not after.

FAQ

Will a website redesign automatically hurt my SEO rankings?

Not automatically, no. Rankings get hurt when redirects are sloppy, URLs get lost without a plan, or redirect chains pile up during the move. A documented, careful migration can preserve rankings through a full redesign.

Do I need to redirect every single old URL?

You need to account for every old URL, which isn't quite the same thing. Some will get individual redirects, some can use rule-based pattern redirects if the structure is genuinely identical, and some truly dead pages may not need a redirect at all. The point is making that decision deliberately, not skipping the review.

Does changing my URL structure hurt rankings on its own?

According to Google's own Search Central community guidance, URL is a very small ranking factor and typically makes no difference by itself. The risk comes from how the change is executed, not from the URL format changing.

What's the actual danger with too many redirects?

The danger isn't the number of redirects you have. It's redirect chains, where one redirect points to another, and the added crawl demand since both the old and new URLs need crawling. That extra crawl load can pull Googlebot's attention away from other pages on your site.

How long should a proper migration take?

Longer than most agencies quote upfront. Running a full crawl, reviewing backend changes, and mapping URLs individually takes real time. Treat that time as insurance for rankings you've already earned, not as wasted hours.

Back to Blog