Website Redesign SEO

I start every redesign by crawling the current site with a tool like Screaming Frog or Sitebulb. I export every URL, the title tag, meta description, status code, word count, internal links pointing to it, and the last crawl date. That single export is my baseline. Without it I cannot measure what changed or what broke.

Next I pull data from Google Analytics and Google Search Console for the last 12 months. I combine the two to rank pages by organic traffic, conversions, and impressions. The top 20% of pages usually drive 80% of the value. I tag each of them with a decision: keep, re-optimise, merge, remove, or redirect. For pages I keep, I preserve the URL slug if possible, or at least the content structure. For pages I merge, I create a [301 redirect](/301-redirect/) from each old URL to the most relevant new URL — never to the homepage unless the page had no value.

Then I build the redirect map. I row it out in a spreadsheet: old URL, new URL, status code, and a note on why. I aim for one-to-one redirects. I avoid redirect chains of more than one hop. I also update internal links across the site so they point directly to the new URLs, not through the old ones. That step alone cuts crawl budget waste and passes link equity cleanly.

Before launch I set up a staging environment that is blocked from search engines via a robots.txt disallow and a password. I run a crawl on the staging site to check for missing metadata, broken links, and canonicalisation issues. I also test the [website structure](/website-structure/) by hand: the homepage, a category page, an article, and a product page. I check that the [canonical tag](/canonical-tag/) on each page points to itself and that the [sitemap](/sitemap/) includes only the new URLs.

On launch day I submit the new sitemap in Google Search Console and request re-crawling for the top pages. I monitor the indexation report and the coverage report for the next two weeks. If I see a spike in 404s or redirected pages, I fix them within hours. I have done this for nine redesigns now, and only one of them lost traffic — and that was because I skipped the baseline crawl.

The biggest trap I have seen is redirecting everything to the homepage. It kills the searcher's intent and signals to Google that the old page no longer exists. A 301 redirect to a page that matches the topic and query is far better. I once saw a client lose 60% of their organic traffic in two weeks because they redirected 500 product pages to their homepage. We fixed it by mapping each product to a new category page, but the recovery took months.

Another watch-out is the [JavaScript SEO](/javascript-seo/) pitfall. If your redesign introduces a new JavaScript framework or a heavy client-side rendering layer, Google may not see the content for weeks. I always test the new site with a text-only browser like Lynx, or use the URL inspection tool in Search Console to see what Google renders. If the content is not visible without JavaScript, I either server-side render it or add a static fallback.

A third one is forgetting to update your [robots.txt](/robots-txt/) and removing the staging block. I have personally done this — pushed the redesign live, updated DNS, but the robots.txt still said Disallow: / on the production server. The site was deindexed for three days. Now I make a checklist item specifically for that.

Canonicalisation can also go wrong. If you have multiple versions of the same page (e.g., with and without trailing slash, or with session IDs), you need to [canonical tags](/canonical-tags/) consistently. During a redesign, it is easy to introduce duplicate content because the old pages are still indexed while the new ones are live. I always set up 301s for the old URLs and ensure the new pages have self-referencing canonicals.

Finally, do not ignore mobile. A redesign that looks great on desktop but fails on mobile will hurt rankings because Google uses mobile-first indexing. I test every page on a real device, not just the Chrome DevTools resize. I also check Core Web Vitals on the staging site using Lighthouse. If LCP or CLS are worse than the current site, I delay the launch until the performance team fixes it.

I once launched a redesign for a news site where I thought I had everything covered: redirect map, sitemap, canonicals, even a staged rollback plan. But I missed one thing: the internal search results pages. The old site had a search feature that generated URLs like /search?q=keyword. The new site changed the parameter to /search?query=keyword. The old URLs were not redirected, and they were all indexed. Google found thousands of 404s for those search pages, which hurt the site's overall crawl budget and trust. I lost about 15% of organic traffic for two months. Now I always include parameterised URLs in my inventory.

Another mistake I made was being too aggressive with page merging. I took 30 low-traffic blog posts and merged them into one long article. The problem was that each old post had its own backlinks and topical authority. I redirected all 30 to the new article, but the new article did not cover the same range of sub-topics. The backlinks were diluted, and the rankings for those keywords dropped. I should have kept the best-performing posts separate and only merged the ones with zero backlinks.

I also learned that a technical SEO audit after launch is not enough. I now run a full audit one week before launch and a second one on the day of launch. The first audit catches structural issues, the second catches last-minute content changes. I use a checklist that includes checking the hreflang tags if the site is multilingual, verifying the pagination markup, and ensuring that the 404 page actually returns a 404 status code. That last one is embarrassing: I once launched a site where the 404 page returned a 200 OK because the developer had set up a custom error page without the correct status header. Google indexed it, and I had to clean up the mess.

My biggest admission is that I still get nervous before every redesign launch. The checklist helps, but I have learned to expect the unexpected. The best insurance is a full backup of the old site — files, database, and redirects — so I can roll back in under an hour if needed.