Back to blog
Website Redesign SEO: How to Rebuild Without Losing Rankings
Papi Petrou, SEO & Content Writer Specialist
A redesign is the one marketing project that can move a business backward on the day it ships. The design is signed off, the build goes live, and six weeks later organic traffic is down by a third with nobody able to name the change that caused it. The design is almost never the culprit. The plumbing underneath it is.
This guide covers the execution side: what to record before anyone opens a design file, how to map URLs, how to keep a staging build out of the index, what to check on launch day, and what to watch for 90 days afterward. Several of the examples come from a migration we ran ourselves, moving a WordPress site to a Next.js build, including the parts that went wrong.
Why do website redesigns lose search rankings?
Redesigns lose rankings because they change most of the signals a search engine uses to identify a page, all at the same time. A URL changes. An H1 is rewritten for the new hero layout. Three paragraphs of body copy are cut because the section looked crowded. Internal links are rebuilt around a new navigation. Any one of those is survivable. Arriving together, they read as a different site. Website redesign SEO is the work of carrying a site's existing search equity through a rebuild: mapping every old URL to exactly one new URL, preserving the on-page elements search engines already rank, and verifying both against the live site after launch rather than against the design file. It is a data exercise, and it runs in parallel with the creative work rather than after it. Four failure classes account for most of the damage. URLs that no longer resolve or resolve through a chain. Pages whose content quietly shrank. Assets that stopped loading in a way a browser check will not reveal. And a staging environment that either got indexed, or kept its blocking directive after going live.What should you benchmark before anyone touches the design?
Benchmark before the build starts, because after launch you cannot prove what you lost. At minimum: a full crawl of the current site with status codes, the title, meta description, H1 and word count for every URL, internal link counts per page, and a Search Console export of queries and pages covering at least the last 16 months so you have a year-on-year comparison available later. Two exports are skipped more often than the rest, and both matter more than they look.- A backlink report at URL level, not domain level. You need to know which individual pages hold referring domains, because those are the URLs whose redirects you cannot get wrong. In our own migration, five dead URLs were still holding 79 referring domains between them. They were redirected to topically close pages instead of being left to 404 or swept to the homepage.
- Two separate counts of indexed URLs, one from your sitemap and one from Search Console. When they disagree before the redesign, they will disagree worse afterward, and you want to know the gap was already there.
How do you build a URL map that actually holds up?
Build it from a crawl, not from the sitemap. A sitemap lists only the URLs the old system chose to advertise. A crawl finds the ones it forgot, and those are frequently the older URLs that other sites have linked to. One row per old URL, one new URL beside it, three rules applied to every row. Redirect in a single hop, old URL straight to final destination, never through an interim page. Redirect to the closest topical match rather than the homepage, because an irrelevant redirect is treated as a soft 404 and passes nothing. And handle both URL forms if your old system served a page at more than one path. Consolidation decisions belong in this document too. Our own rebuild reduced 43 service pages to 21, because nine near-identical pay-per-click pages, ten SEO pages and twelve web development pages were competing for the same queries and splitting internal link equity between them. Every retired page redirects in one hop to its survivor. The redirect file grew from 48 rules to 95, and 19 pre-existing chains were flattened along the way, some of them three hops deep. Planning that in a spreadsheet is cheap. Discovering it after launch is not, which is why our website redesign services start with the URL map rather than the wireframes.What can go wrong with redirects even when the map is right?
Three things, and none of them are visible in a browser. The status code can be wrong. The rule can fire on a URL you never meant it to touch. And the redirect can be removed before the search engine has finished acting on it. On the status code: our redirects were returning 308 rather than 301, because the framework maps a "permanent" flag to 308. Google's documentation recommends "301 and 308" without preference, so this changed nothing for Google. Many third-party link and audit tools still special-case 301, and on a site whose whole problem was equity failing to reach its destination there was no reason to let any tool guess. We set the status code explicitly. On the rule firing where it should not: one retirement redirect shadowed a live blog post. The path /custom-website-development-services/ existed both as a retired service URL and as a real published article. The redirect took precedence and the article became unreachable, returning a redirect instead of content. It surfaced only when all 21 retired paths were checked against the live content store, not by clicking around the site. On duration: Google's site move documentation says to "keep the redirects for as long as possible, generally at least 1 year", because that is the window in which signals transfer and other sites' links get recrawled. Treat a year as the floor, not the plan.Which on-page elements must survive the redesign?
Title tag, H1, body copy volume, internal links, canonical tags, structured data and image alt text. A redesign that halves the word count on a page currently ranking has changed what that page is about, whatever the brief said about reducing clutter. Record these per URL before the build and diff them after launch. Content damage during a rebuild is more common than most teams expect, and it does not announce itself. In our own migration, copy was spliced between pages during the content import and nobody noticed for months. The single highest-impression page on the site, with 38,427 impressions in 90 days, was carrying a different page's H1, eyebrow, subtitle and opening section. Six separate pages shared one identical generic heading. Fragments of one service page's copy had been welded onto the front of card text across six others. Every one of those pages rendered perfectly. The check that catches this is a field-by-field diff of old content against new, not a visual review. Reviewing a page in a browser tells you it looks finished. It does not tell you the H1 belongs to a different page. This is standard scope on our technical SEO services, and it is worth running whether or not the redesign is ours.The failure that passes every spot check
The most expensive fault in our own migration could not be seen in a browser at all. A deploy script created a symbolic link from the application's public directory to the old WordPress uploads folder. When WordPress was removed from the server, that directory went with it, leaving the link pointing at nothing. The web server was still serving /wp-content/uploads/ from a different path that survived, so pasting any image URL into a browser returned 200 and showed the picture. The framework's image component resolves from the public directory instead, and could not read a single file. The result was 431 broken images across 187 pages. An Ahrefs crawl on 31 July 2026 returned a site health score of 31, with 681 of 984 crawled URLs carrying errors. Because the offending line ran on every deploy, fixing the link by hand would have been undone by the next release. After the script was corrected and a guard added that fails the deploy if the link resolves to nothing, a re-check found 909 images across the site with zero broken. The transferable lesson is short. Verify assets the way a crawler sees them, not the way a browser does. A raw image URL returning 200 does not prove the rendered page can load it, and a spot check of five pages will pass while hundreds are broken.How do you keep the staging site out of the index?
Put HTTP authentication in front of the staging host. A password prompt is the only method that cannot fail open, because a crawler that cannot fetch the page cannot index it or link to it. Blocking with robots.txt alone does not work, and it makes a noindex tag useless. Google's own documentation is explicit: "For the noindex rule to be effective, the page or resource must not be blocked by a robots.txt file, and it has to be otherwise accessible to the crawler." If the crawler is blocked, it "will never see the noindex rule, and the page can still appear in search results, for example if other pages link to it." The mirror-image failure is the one that actually costs traffic. A noindex directive added to staging and carried through to production on launch day will deindex the site quietly, and the site will look completely normal while it happens. Add an explicit launch check that production returns no noindex header and no noindex meta tag on every page template, and repeat it the following morning.Sequence launch day so nothing depends on memory
Write the order down and work through it. In our experience the steps most often skipped are the last three, because by that point the site is up and everybody assumes the job is finished.- Freeze content changes on the old site, then take the final reference crawl.
- Deploy, then immediately remove staging blocks and confirm robots.txt and the robots meta tag on production.
- Test redirects with a command line request that prints status codes, on a sample that includes every rule type and every URL holding backlinks. Browsers follow redirects silently and hide chains.
- Submit the new sitemap in Search Console and remove the old one.
- Crawl the new site end to end and diff it against the pre-launch crawl: status codes, titles, H1s, word counts, canonical tags.
- Re-verify images, structured data and canonical tags against rendered HTML, not against the templates that produced it.
Does the sitemap still tell the truth after launch?
Usually not, and it needs checking on its own because a sitemap on a modern site is generated code rather than content. It can drift from the routing configuration without anyone editing it. Ours did exactly that. When 21 service paths were retired, removing them from the routing configuration made an internal "is this a service page" check return false, so the sitemap generator fell through to a fallback URL form and began advertising every retired page under a different path. Twenty-one redirecting URLs sat in a sitemap that an earlier check had reported clean, because that check only looked for one of the two possible URL forms. Once the generator was told to skip retired paths explicitly, the sitemap went from 173 URLs to 152. A sitemap should contain only canonical, indexable, 200-returning URLs. Anything that redirects, 404s or carries a noindex tag is telling Google two contradictory things at once.Point internal links at destinations, not redirects
Every internal link landing on a redirect still works, which is exactly why it survives a redesign unnoticed. It also spends crawl budget on a hop that does not need to exist and passes a weaker signal to the page you are trying to rank. Consolidating pages to concentrate authority and then linking through redirects gives part of the benefit straight back. Our audit found 107 internal links pointing at redirects, inherited from the old site rather than created by the rebuild, plus 11 genuinely broken links to pages that had moved to a different URL form. The footer was the worst of it: hardcoded rather than generated from the live page list, it was linking five retired pages on every single page of the site. Rebuilding it to cover all 21 surviving pages exactly once also gave several pages their first sitewide inbound link.How long does it take for rankings to settle after a redesign?
Google's site move guidance says "a small to medium-sized website can take a few weeks for most pages to move, and larger sites take longer". Expect a visible dip in the first fortnight regardless of how clean the migration was, because Google is recrawling and reassigning signals across every URL that changed. Judge the migration on whether the trend returns to its pre-launch line, not on week-two numbers. If impressions recover but clicks do not, look at titles and meta descriptions, which are frequently rewritten during a redesign without anyone treating the rewrite as an SEO change. If neither recovers by week eight, go back to the URL map and the redirect status codes before touching anything else.What should you monitor in the first 90 days?
Six things, checked on a schedule rather than when somebody panics. The Search Console Pages report broken down by reason, watching "Page with redirect" and "Not found (404)" for anything unexpected. Sitemap submitted-versus-indexed counts. Query and page level comparison against the same window last year. Crawl stats, where a spike in 404s means the URL map missed something. Core Web Vitals field data, which lags by 28 days. And a full recurring crawl, monthly, so regressions surface without a person remembering to look. One caution about automation. A green build check is not proof of correctness. During our own migration an automated internal link check reported clean immediately after a script had corrupted three content files, because the corruption had destroyed the very links the check inspected. The build failing is the only reason it surfaced. Verify against rendered output, not only against the gate that is supposed to protect it.Plan the migration before the design starts
Almost everything on this page has to happen before or during the build. A URL map assembled after launch is an incident report. The practical split is simple: the design work answers what the new site should look like, and the migration work answers what must not change about it. If you are commissioning a rebuild, ask whoever is quoting for it to show you their URL map, their redirect testing method and their post-launch monitoring plan before you sign anything. If the answer is that redirects will be handled at the end, that is the answer to a different question. Our website redesign services cover the migration alongside the design work, and if your site has already been rebuilt and traffic has not come back, a redesign recovery audit will usually find the cause in the redirect map or the rendered HTML rather than in the design.Sources
- Google Search Central. Site moves with URL changes. Retrieved 3 August 2026. https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes
- Google Search Central. Block search indexing with noindex. Retrieved 3 August 2026. https://developers.google.com/search/docs/crawling-indexing/block-indexing
- Invisio Solutions. First-party migration record: crawl and deployment figures from a WordPress to Next.js rebuild completed July and August 2026. Site health score, broken image counts and crawled URL totals are from Ahrefs Site Audit, crawl dated 31 July 2026.
FAQ
Frequently asked questions
- A redesign only hurts SEO when the migration is handled poorly. Rankings drop because URLs change without single-hop 301 redirects, because title tags, H1s and body copy are rewritten or shortened on pages that were already ranking, or because a staging directive survives to production. Keep those three under control and a redesign is neutral to positive, since page speed and internal linking usually improve.
