Redesigning Your Website Without Neglecting SEO: What to Plan Before the Switch
Reduce migration errors while preserving useful signals and content.
SqualiOnline editorial team · 2026-09-07
The damage from a poorly done migration doesn’t show on launch day. It shows a few weeks later, when the pages that generated inquiries are no longer at the same addresses and no one can say which ones they were. This guide exists to prepare the switch before the new site goes live — while the old one can still be inventoried.
The general rule is easy to state and hard to carry out: every address that exists today must have a decided destination, and the decision has to be made by someone who knows what was on that page.
The inventory: every URL, not just the ones in the menu
A site almost always has far more addresses than the ones shown in navigation. They need to be gathered from different sources, because no single one contains them all.
- The pages the site declares: the sitemap, the content list in the management system, an automated crawl of the site.
- The pages that receive visits, taken from analytics tools. These include forgotten addresses that someone keeps reaching.
- The pages search engines know about and that bring in visits from search.
- Files that aren’t pages: downloadable documents, spec sheets, price lists, images referenced by other sites.
- Addresses used in campaigns, emails, printed materials, and QR codes: they’ll keep being opened even after launch, for years.
The merged list, with duplicates removed, is the working document. The rest of the migration comes down to deciding one row at a time.
Which pages deserve attention
Not every page deserves the same amount of work. Three criteria, to look at together.
- Visits received, especially from search: if they disappear, it’s noticed right away.
- Links received from other sites: they’re hard to rebuild and need to be preserved with a relevant destination, not a generic redirect.
- Inquiries generated: a page with few visits that produces contacts is worth more than a heavily visited one that produces none.
Pages that meet none of the three criteria are candidates to be merged or removed. It’s an opportunity not to waste: a new site that carries over every old page also inherits its problems.
The before-and-after matrix
The working document is a table with one row per address. Four cases cover nearly everything.
| Case | What happens | Destination | Watch out for |
|---|---|---|---|
| Page moved | Same content at a new address | The corresponding new page | The content must stay equivalent: if the text changes too, the two changes stack up and it becomes impossible to tell what produced what |
| Pages merged | Several pages become one | The page that covers both topics | The destination must genuinely cover the topics of the source pages, or visitors won’t find what they were looking for |
| Page removed | Content no longer valid or service no longer offered | The closest category page, if a relevant one exists | Redirecting everything to the homepage is the shortcut that defeats the purpose: visitors don’t understand and leave |
| Page unchanged | Same address, same content | No redirect to set up | Still verify it’s reachable after launch: when the system changes, address details can change without anyone asking for it |
It’s worth adding two more columns: who decided and on what date. A few months later, someone will ask why a certain page ended up in one place instead of another.
Redirects: the mistakes that keep happening
- The redirect must be permanent. A redirect declared temporary keeps the old address alive and transfers nothing: use it only when reverting back is genuinely planned.
- Chains: an address that redirects to a second one that redirects to a third. This happens when there have been previous migrations. They need to be shortened by pointing every old address directly to the final destination.
- Internal links must be rewritten to the new addresses, not left to pass through redirects. Redirects are for visitors arriving from outside, not for holding the site together with itself.
- Address details — with or without www, capitalization, trailing slash, parameters — must have one single form. Two addresses that show the same page are two pages, as far as a search engine is concerned.
- Downloadable file addresses count as much as pages: a spec sheet linked from another site is a received link in every sense.
Launch day, and the weeks after
- Before publishing, verify the new site hasn’t been left closed to search engines: the block used during development, if it’s still active, is the costliest and most trivial mistake in the whole migration.
- Check a sample from the list by opening the most important old addresses, and look at where they actually land, not where they’re supposed to.
- Update the sitemap and submit it to search engine tools, so crawling finds the new structure right away.
- In the following days, watch for errors: addresses not found, pages excluded from the index, redirects that don’t work. The first few weeks are when fixes cost almost nothing.
- Keep the old list on hand for a few months: requests for forgotten addresses trickle in over time, not all on day one.
What this guide doesn’t cover
This prepares the switch from old to new. Whether it’s worth redesigning the site or improving the existing one is a decision that comes earlier and has its own dedicated guide. Nor does this cover gaining rankings that weren’t there before: a well-done migration preserves what works, it doesn’t increase it. And if the site already doesn’t show up in search today, the first thing to establish is whether it isn’t indexed or is indexed and poorly ranked.
Frequently asked questions
Should I keep the same page addresses?
If there’s no reason to change them, keeping them is the least risky choice: no redirects to set up and nothing to lose. Addresses should change when the site’s structure genuinely changes, not to make them prettier.
How long should redirects be kept?
As long as possible, and well beyond the first few months either way. Old addresses stay in emails, printed documents, bookmarks, and links on other sites that no one will update. Removing redirects is something to do only after verifying that no one arrives from those addresses anymore.
How far ahead of launch should the migration be prepared?
The inventory needs to be done while the old site is still online and complete, and destination mapping should be built alongside the new structure, not at the end. The worst work is the kind done the night before launch, when decisions get made by eye across hundreds of rows.
Let’s plan your site’s SEO migration.
If you’d like to talk it through, the service that handles this is GEO & SEO.

