--- title: "Redesign a Website Without Losing SEO" source: https://refact.co/insights/publishing-growth/redesign-website-without-losing-seo author: "Masoud Tahsiri" date: "2026-06-09" --- # Redesign a Website Without Losing SEO You won’t find a redesign to have failed on account of a bad new design. The trouble is that the team has gone about it as a visual exercise, whereas search engines see it for what it is: a site migration. Tinker with enough of the moving parts at once – your URLs, templates, CMS, navigation and content – and the index will let go of what your site was. Case studies in the mid-market are full of examples where a launch is followed by an organic traffic drop of 20 to 60 per cent in as little as two weeks, leaving you with three to nine months of cleanup. If you want to keep your SEO intact, you have to be about protecting certain signals through the change, not the look of your homepage. That is the premise of this guide. It is for operators who are set to restructure or replatform a site that is already pulling in search traffic. The work itself is simple; the discipline required is not. ## Why a Redesign Is a Migration, Not a Makeover There is a myth that Google penalises a new design. What it penalises is a lack of continuity. Make no mistake, the [site move guidance](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes) from Google is plain on the matter: if you are changing URLs you put permanent 301s in place from every old address to its nearest match and leave them there until the index has settled. The real danger is broken mapping between the site that had the rankings and the one you put in its stead. Lose any of the five signals below and the traffic goes with it: - **URL identity.** Down to the exact path of an indexed page. - **Content intent.** The historical answer each URL has given to a searcher. - **Internal link topology.** The way equity is channeled from the homepage to the deeper pages. - **Crawlability.** Do the bots get real HTML or an empty shell dependent on JavaScript? - **Off-page authority and entity signals.** Your brand, NAP, schema, backlinks and organisation markup. If your plan doesn’t put an owner on each of these, you are already in trouble. Refact’s [website redesign process](https://refact.co/insights/digital-product/website-redesign-process) is designed to safeguard them in order, rather than trying to bolt on SEO at UAT. ## The Inventory You Need Before Anyone Opens Figma Get a clear picture of the site as it stands before you even think of a wireframe. Otherwise, post-launch will be nothing but arguing over whether something has dropped or merely been restyled. You need a map of what to defend, so pull together the following and put it somewhere your leads can see it: - All indexable URLs (old campaign landers, PDFs, author pages, faceted product URLs, blog archives). - A year or more of Search Console data on impressions and queries for each URL. - Which pages are your top organic performers in terms of revenue and sessions. - Page-level backlinks ranked by the quality of the referring domain. - The state of your canonicals, H1s, meta descriptions and titles. - Inbound internal link counts. - Any orphaned pages that are still ranking. Teams tend to skip this and then wish they hadn’t. When we did the rebuild for [Teton Gravity Research’s publishing platform](https://refact.co/work/teton-gravity-research), the inventory alone was a matter of weeks. The old ExpressionEngine site had thousands of articles with all manner of inconsistent URLs and uneven metadata. That inventory made the migration safe; without it we would have been guessing at how to handle a decade’s worth of content. We also provide [SEO auditing services](https://refact.co/insights/publishing-growth/seo-auditing-services) for those who want to run this stage cleanly before decisions are finalised. ### Freeze your money pages With the inventory done, you mark the URLs that are vital to the business. The service pages with backlinks, the category pages that convert, the top blog posts. They get a label that is non-negotiable: the URL, the key copy and the core intent are staying put. Let the engineers and designers do what they like around them, but nobody is to rename or delete them without a redirect plan and a paper trail. ## The Redirect Map Is the Document That Saves You Should you have to change URLs, the redirect map is the single most important document in the project. Each old indexable URL is to have a 1:1 with the closest semantic equivalent on the new site, not some broad archive or the homepage. We know the shortcuts that will undo a redesign: 302s, meta refreshes, JavaScript redirects or letting the registrar forward a domain. Google reads those as soft errors. Un-redirected URLs and lost traffic have an almost 1:1 relationship. A map that can stand up to scrutiny will have: - A destination for everything in the inventory, down to image files and old paginated URLs. - No chains. The old URL goes straight to the final one. - A manual pass over the top 50 to 200 pages for backlinks and conversions. - A plan to remain live for 12 months at a minimum; high-value ones for years. In cases of consolidation, pick a canonical and put the best copy from the merged pages into it. Don’t spread your authority thin across a few replacements and watch a number one spot become three page-two listings. ## Architecture Changes Are Where Most Damage Hides The conventional wisdom is to hold onto your metadata and URLs. But that is predicated on the structure not moving, which is seldom the case in a real redesign. Whether you are consolidating duplicate content, paring down an overblated nav, or making the switch from a legacy CMS to something with better information architecture, you are making a structural change the index will have to relearn. And in my experience, two things tend to go wrong more than anywhere else. Internal link collapse is the first. A new, streamlined navigation will often do away with the sidebars and footer blocks that made deep pages just two clicks from home. Once you launch, those important pages can end up three or four clicks out, or worse, become orphans. You need to map your inbound internal link counts when you take inventory and make sure the new design doesn’t leave key pages high and dry. Beware of mega menus built in JavaScript; if Googlebot can’t see the link in the rendered HTML, it isn’t there for it. Then there is the matter of rendering. Even with Google’s advances, a single-page app that lacks server-side or pre-rendering is going to send an empty initial HTML to the bots. Meta tags set on the client side are unreliable at best. If you are running React, Next or the like, the prudent thing to do is deliver your links, metadata and content as HTML first. Put it to the test with the URL Inspection tool against what a real Googlebot fetch would show. If you want a closer look before you go live, the [technical SEO checklist for founders](https://refact.co/insights/publishing-growth/technical-seo-checklist) is a good way to cover the crawl and indexation items engineering teams have a habit of overlooking. ## Staging Is Where the Real QA Happens Don’t let the new site sit on an unauthenticated staging environment until the last minute. That is where you should be finding the trouble your users would otherwise find for you. The QA gate is important because a couple of small oversights here are what lead to most of the post-launch panic. Here is what you should check before the switch: - Do a full crawl of both the live and staging sites with Screaming Frog or Sitebulb. You want to see how titles, H1s, canonicals, crawl depth and the like stack up. - For any JavaScript-heavy templates, compare the raw HTML to the rendered version to be sure of what the bot sees. - Test your redirect map end to end against the inventory, don’t just sample it. - Regenerate the sitemap for the new URLs and have a plan to put it in front of Google on launch day. - Make sure robots.txt and meta robots are right. A noindex directive on staging has derailed more launches than almost anything. - Get a baseline on Core Web Vitals for some representative templates under actual network conditions. Siteimprove has a [good piece on the errors common to a redesign](https://www.siteimprove.com/blog/eight-common-seo-errors-during-a-website-redesign/) that bears out what you hear in the forums: mobile speed and rendering are table stakes at staging, not something to optimize later given half the traffic is mobile. ## Launch Day Is the Handoff, Not the Finish Line Make it a Tuesday or Wednesday morning for the launch. Not a Friday, and certainly not a holiday. Get the team in one room or one Slack channel for the day. Before you push the release or flip DNS, run through the list one last time: is production robots.txt permissive? Are the redirects in place and spot-tested on the top 50 URLs? Do the canonicals point to the new domain? Is the new sitemap ready in Search Console and are your analytics firing? On a big site, a phased rollout is less risky than a big-bang approach. Migrate by locale or section. It lets you isolate cause and effect; if you see a dip in one area you know why. When everything goes live at once you are left reading tea leaves. We saw this with the [Keck School of Medicine of USC project](https://refact.co/work/keck-school-of-medicine-of-usc). You can’t move a decade of medical research in a weekend without breaking the visibility clinicians rely on. In that case the release plan was the project. ## The First 90 Days Decide the Outcome When you have to do an SEO recovery it is a matter of weeks, sometimes months. And the post-launch window is when teams are most apt to misread their numbers. What looks like a fall in conversions may simply be a broken event tag or an ecommerce snippet that lost its order ID variable. You need to separate these questions and use the right tools for each: - **Visibility:** Is Google doing its job with the new URLs? Check GSC coverage, 404 reports and impressions per URL every day for the first fortnight. - **Measurement:** Is the old funnel still working? End-to-end test the key paths on launch day and 48 hours after to confirm your forms and revenue tracking are still active. I would suggest a 90-day cadence: - **First two weeks, daily.** Top-page rank, 5xx and 404 errors, any changes in GSC. - **The following eight weeks, weekly.** Look at section-level traffic against your baseline. Review server logs for bot activity and make internal link adjustments where deep pages have been short-changed. - **After that, monthly.** Make the hard call on low-value holdovers that never came back. Set your acceptable-loss threshold in stone before you start. “Down 30 percent on our top-10 revenue pages by day 10” is a trigger. “It feels off” is not. ## What Changes in 2026 You could say the stakes have been put on a few particular signals by AI Overviews and answer engines. For content you want cited, structured data is not an option anymore. Then there is entity consistency, NAP, organization schema, author markup and knowledge graph alignment; these serve as a buffer against redesign risk since the AI will look to brand mentions and citations to determine who to quote. And if you have done your off-page authority work in the run up to the redesign, it will act as a stabilizer. A site with a solid link profile and clean entity signals will stand up to a redesign far better than one that is propped up by a handful of top pages and nothing more. But don’t let that obscure the fundamentals. The AI layer puts some emphasis on things, it doesn’t do the work for you. URL identity, crawlability, internal links, content intent and authority are what still carry the day. ## Where to Get Help Before the Build Starts When it comes to replatforming, we leave the finer points of the data, redirect and QA work to our [website migration service](https://refact.co/services/website-migration) and the [WordPress migration guide](https://refact.co/insights/wordpress/wordpress-migrate-website-guide). You will find the pattern holds true no matter the CMS: take inventory, put a freeze on your high-value URLs, map out the redirects, test on staging and then launch in phases while you monitor for 90 days. The costliest errors in a redesign are made in the planning, not the development. If you wait until UAT to bring in SEO, the IA, templates and URL structure are set in stone. It is much cheaper to sort out your URL governance and measurement design before any of the design has even started. That is the purpose of Refact’s discovery phase, which is why we back it with a money-back guarantee. Those early decisions are what will safeguard the traffic your new site is meant to be growing. ## FAQ ### Will redesigning my website hurt my SEO? Not on its own. A redesign is risky in proportion to how many things change at once: URLs, content, internal links, templates, CMS, and domain. Cosmetic changes to CSS or imagery are low risk. The traffic drops people remember usually come from poor redirect mapping, content pruning without analysis, or JavaScript-only rendering, not from the redesign itself. ### How long should I keep 301 redirects in place after a redesign? At minimum 12 months. For high-value URLs with backlinks, keep them indefinitely. Google warns against removing redirects too early because the index can still be consolidating signals months after launch. Removing them prematurely is one of the most common ways to lose recovered rankings. ### Can I change URLs and content at the same time? You can, but you make recovery harder if something goes wrong. Conservative practice is to change URLs in the redesign, then revisit content in a separate phase so cause and effect stay readable. If you must combine them, freeze the highest-traffic pages' titles, H1s, and key copy at launch and iterate later. ### How long does SEO take to recover after a botched redesign? Anywhere from two weeks for minor volatility to three to nine months for severe cases. Recovery time depends on how quickly the underlying issues are diagnosed and fixed. The most common accelerator is finding missing or wrong redirects in the first two weeks and shipping corrections immediately. ### Should I prune low-traffic content during the redesign? Only after scoring each page on traffic, rankings, backlinks, and conversions. Mass pruning during a redesign collapses long-tail traffic and breaks internal link patterns that supported stronger pages. Treat pruning as a separate, measured project after the redesign has stabilized. ### What is the single most common cause of redesign traffic loss? Redirect mapping that is missing pages or sends them to generic destinations. Bulk redirects to the homepage, redirects from specific product pages to broad categories, and overlooked PDFs or campaign URLs are the recurring offenders. A complete 1:1 map built from the URL inventory eliminates most of this risk before launch.