Site Redesign SEO Checklist

I start every redesign by crawling the live site with a tool like Screaming Frog. I export every URL, status code, meta title, description, and internal link. That inventory becomes my baseline. Next I pull organic traffic data from Google Search Console and analytics—clicks, impressions, CTR, top landing pages. I identify the 20 to 50 pages that drive most of my traffic and backlinks. Those pages I treat as non-negotiable: they must stay, redirect correctly, or be re-optimised. For each URL I decide: keep, merge, remove, or redirect. I map every [301 redirect](/301-redirect/) from old to new, not just the obvious ones. I also update [internal links](/website-structure/) on the site to point to new URLs directly rather than relying on redirect chains. I block the staging environment from indexing with a [robots.txt](/robots-txt/) disallow and a meta noindex tag. I test everything in staging: crawl, check status codes, verify that [canonical tags](/canonical-tag/) point to the right versions. After launch, I submit an updated [XML sitemap](/sitemap/) to Google and Bing. I watch Search Console daily for the first week for any indexation drops or coverage errors. This list is not optional—I have seen teams skip one step and lose weeks of traffic.

You should stop a redesign if you have not completed a full redirect map. I have a hard rule: no go-live until every URL with any search presence has a 301 destination. If the staging site is visible to search engines, stop and fix the indexation block. If you have not communicated the launch timeline to your team and aligned on rollback procedures, stop and schedule a meeting. If you are introducing a new URL structure or changing the site architecture significantly, stop and run a pilot test on a small section first. A counter-argument I hear is that small redesigns don’t need this level of caution. But I have seen a single broken redirect on a low-traffic page cause a cascade of internal linking issues that affected pages further up the funnel. Also, if your analytics or Search Console data shows a sudden drop in crawls or impressions during staging testing, that is a red flag. Pause, investigate, and only proceed when the metrics stabilise. The cost of delaying a launch by a week is far lower than the cost of losing rankings for three months.

This is my most honest section. I once launched a redesign for a client without a complete redirect map. I had mapped the top 50 pages but assumed the rest would not matter. They did. The site lost 30% of organic traffic for three months. It took that long to rebuild. Another mistake: I forgot to update internal links in old blog posts. After the redesign, those links pointed to old URLs that redirected to new ones—users and crawlers hit a redirect chain. It slowed down page load and diluted link equity. The worst mistake was leaving the staging environment indexable. I had set a noindex tag but forgot to block it in robots.txt. Google indexed the staging version, saw [duplicate content](/duplicate-content/), and ranked the wrong one. It took weeks to clean up. Each of these errors taught me to build checklists and to test, test, test before launch. Now I always do a post-launch crawl and compare the indexation report to the pre-launch baseline.