SEO Website Redesign

Treat a redesign as a full site migration, not a facelift. If you change the structure, the CMS, the navigation, or any URL, you are effectively telling Google to rediscover your content from scratch. The common mistake is to focus on the new design and treat SEO as a checklist you tack on at the end. I have done that. The result: a beautiful site with half the traffic.

Here is the rule I use now: before I change a single line of code, I crawl the live site with a tool like Screaming Frog. I export every URL, the title tags, meta descriptions, status codes, internal links, and page depth. That crawl becomes my map. I also pull three months of data from Google Search Console and Google Analytics so I know which pages drive traffic and conversions. Without those baselines, you cannot tell whether a drop is a normal fluctuation or a redirect you missed.

The decision is simple: if the redesign touches URLs, navigation, or the CMS, you run a full [SEO audit](/seo-audit/) before launch. I once skipped the redirect map for a site that moved from /blog to /resources. The result was 40% less organic traffic for three months. Never again. You build the redirect map in staging, test it with a crawl, then deploy.

This matters every time the redesign changes where content lives. Specific triggers: you are switching CMS (e.g., from WordPress to a custom build), restructuring URLs (e.g., flattening a deep folder structure), redesigning navigation or information architecture, merging or removing large sections of content, or adding features that change how pages are served (e.g., moving from server-rendered to client-side JavaScript). In each case, the risk of losing indexed pages is real. I have seen 60% of a 50,000-page site drop out of the index after a CMS migration because the new system generated different paths and the old 301s were not mapped.

Counter-argument: some practitioners say if you keep the same URLs, you can skip the redirect map. I disagree. Even with the same URLs, internal links, navigation menus, and sitemaps change during a redesign. You need to check that every internal link still points to a 200, that [canonical tags](/canonical-tag/) are correct, and that the [sitemap](/sitemap/) is updated. If you do not, you risk [duplicate content](/duplicate-content/) issues or broken navigation. The moment you touch the code, the crawl behaviour can shift. I always run a pre- and post-launch crawl diff, regardless of URL changes. That is the only way to catch hidden 404s.

I launched a redesigned site on a Monday morning three years ago. By Wednesday, 30% of our top landing pages were returning 404s. The redirect map had typos in the source URLs — I had written /old-path when the actual URL was /old-path/ with a trailing slash. That cost us thousands of pounds in lost bookings over two months. Now I test redirects in staging with a full crawl that compares the old and new server responses.

Another mistake: I assumed high-performing pages would be fine if I kept the content. I moved a page that ranked number one for its main keyword, kept the body text, but changed the internal link anchor text and removed the contextual links. The page dropped from position 1 to position 8 within a week. The content was the same, but the internal linking signal changed. Now I preserve the anchor text and link profile for every top-10 page during a redesign.

I also used to launch without staging. I thought "it is just a visual refresh, the server stays the same." But staging caught a [robots.txt](/robots-txt/) change I had not noticed — a developer had added a disallow for the new section. If I had launched that, the entire redesigned section would have been blocked from crawling. Now staging is non-negotiable.