How to redesign your website without losing your SEO rankings

You can redesign or re-platform a website without losing rankings, but only if you treat search equity as an asset you deliberately carry over — not something that follows the brand automatically. The work comes down to four disciplines: a complete redirect map, genuine content parity, a faithful technical and schema migration, and close monitoring in Google Search Console before and after launch. Teams that skip any one of these usually find out weeks later, when traffic has already fallen and the old site is gone.

Why do redesigns lose rankings in the first place?

Search engines do not rank websites; they rank URLs. Each URL on your current site has its own history: the content on it, the internal links pointing at it, the external links it has earned, and the record of how searchers have interacted with it. A redesign or re-platforming threatens that history in three ways at once.

First, URLs change. A new CMS or a new information architecture almost always reshuffles paths, and every changed URL without a redirect is a dead end — the equity it held simply evaporates. Second, content changes. Designers trim "walls of text", merge pages, and cut the FAQ nobody on the team liked, without checking which of those words were the reason the page ranked. Third, the technical layer changes: rendering method, page speed, canonical tags, robots directives, structured data. Any of these can quietly tell search engines that the new site is a different, less trustworthy thing than the old one.

Rankings do not belong to your brand. They belong to your URLs, your content and the links pointing at them — move any of those carelessly and the rankings stay behind.

None of this argues against redesigning. Old platforms accumulate real costs, and a well-executed rebuild often improves organic visibility because it fixes speed, mobile usability and crawlability in one pass. The point is that the outcome is decided by process, not luck.

How do you build a redirect map that holds up?

The redirect map is the single most important artefact of the migration. Build it before anyone writes a line of the new site, and build it from data rather than memory.

Start by assembling a complete inventory of old URLs from several sources, because no single one is complete: a full crawl of the live site, the XML sitemap, the pages and queries reports in Search Console, analytics landing pages, and a backlink export so you know which URLs have external links pointing at them. De-duplicate the list and mark each URL with its traffic, its ranking queries and its inbound links. That marking matters: when trade-offs appear late in the project, you need to know instantly which URLs are load-bearing.

Then map every old URL to its closest equivalent on the new site, one to one wherever possible. A few rules keep the map honest:

• Use permanent 301 redirects, not temporary 302s, so equity is passed rather than parked.
• Redirect in a single hop. Chains of redirects waste crawl budget and dilute signals, and they multiply quietly across successive migrations.
• Never bulk-redirect everything to the home page. Search engines commonly treat an irrelevant redirect as a soft 404, and users bounce off it.
• If a page genuinely has no successor, let it return a clean 404 or 410 rather than redirecting somewhere misleading — but check its links and traffic first.
• Keep the map under version control and test it against the staging site before launch, then again on the live site within the first hour.

Plan for the redirects to stay in place for years, not months. External links to old URLs will keep arriving long after launch, and each one still needs somewhere to land.

What does content parity actually mean?

Content parity is the discipline of making sure the new page can do the same job for the same query as the old one. It is not the same as covering the same topic. A service page that ranked because it answered a long list of specific questions will not keep ranking as a hero image with three lines of copy, however good the design looks.

For every page that earns meaningful organic traffic, compare old and new side by side: the title tag and meta description, the heading structure, the body copy, the internal links in and out, the images and their alt text, and any structured data. Where the redesign deliberately shortens or merges content, make that a decision someone signs off on with the ranking data in front of them, not a by-product of a template change.

Internal linking deserves particular attention because it is invisible in mockups. Navigation menus, footers, related-content blocks and in-copy links are how equity flows from your strongest pages to the rest of the site. If the new design drops a links block that used to appear on every page, a large share of the internal link graph disappears at once. Our SEO and content team treats the internal link graph as part of the content inventory for exactly this reason.

Which changes carry the most SEO risk?

Not every rebuild is equally dangerous. It helps to be clear about which kind of change you are actually making, because the safeguards differ.

The last row is worth underlining. Changing domain, platform, design and content in a single launch means that when something goes wrong, you cannot tell which change caused it. Wherever the schedule allows, separate the domain move from the redesign by a comfortable margin.

Schema deserves special care in any re-platform, because structured data often lives in plugins, theme files or hand-placed scripts that nobody inventories. Before the build starts, crawl the old site and record every page's schema types — Organization, LocalBusiness, Article, FAQPage, BreadcrumbList and the rest — then make reproducing them an explicit requirement, validated with a testing tool on staging. Apply the same inventory approach to canonical tags, hreflang, robots directives, XML sitemaps and image URLs, which carry their own equity in image search. Performance is the quiet win: a rebuild is your best chance in years to improve Core Web Vitals, and modern web development practice — clean markup, optimised images, restrained scripts — costs little when designed in from the start.

What should launch week and the month after look like?

Benchmark before you launch: export your ranking keywords, top landing pages, indexed page count and Search Console performance data. Without a baseline, every post-launch wobble becomes an argument about whether it is real.

1. Launch at a quiet time for your business, with the developer who wrote the redirect rules available.
2. Within the first hour, spot-check the redirect map on live URLs, confirm the noindex and robots.txt state, and submit the new XML sitemap in Search Console.
3. In the first week, watch the page indexing and crawl reports in Search Console (named as they are at the time of writing) for spikes in 404s, redirect errors or excluded pages, and use the URL inspection tool to confirm key templates render and index as expected.
4. Over the first month, compare clicks, impressions and average position against your baseline at the page level, not just site-wide, so a handful of damaged pages cannot hide inside a healthy average.
5. Crawl the live site weekly at first, looking for redirect chains, broken internal links and orphaned pages.

Some movement after a migration is normal while search engines re-crawl and re-evaluate the site; treat the first few weeks as a settling period. What should trigger action is a loss that persists and concentrates: specific pages that fell, specific queries that vanished. Those almost always trace back to a mapping gap, a parity gap or a technical directive, and they are fixable if you catch them early.

What are the common ways teams destroy their own traffic?

The failures we see are rarely exotic. They are ordinary oversights under deadline pressure:

• Launching with no redirect map at all, on the theory that search engines will "figure it out".
• Redirecting every old URL to the home page to save time.
• Shipping the staging noindex tag to production, or blocking the whole site in robots.txt.
• Cutting the copy that ranked because it did not fit the new design.
• Moving to a client-side JavaScript front end without checking what search engines can actually render.
• Dropping schema, metadata and alt text because the new CMS had no field for them.
• Changing domain, design and platform simultaneously, then having no way to isolate the problem.
• Declaring the project finished at launch, with nobody assigned to watch Search Console.

Every one of these is avoidable with an inventory, a map and a named owner for post-launch monitoring.

How OlDevs approaches migrations, and how to start yours

OlDevs is a full-stack technology studio in Vancouver, building and migrating websites since 2014. Redesigns and re-platforms are core work for us: the same accountable team handles the build, the redirect map, the schema migration and the post-launch monitoring, so nothing falls between a design agency and an SEO vendor. You see a working demo every week, you own all code, designs, accounts and IP, and we build to WCAG 2.2 AA accessibility as standard. Our delivery process treats the SEO migration plan as a first-class deliverable, reviewed alongside the design.

If a redesign or re-platform is on your roadmap and you want it to add organic visibility rather than gamble with it, request a quote — we reply to every enquiry within one business day.