A website redesign is one of the most common causes of sudden, severe ranking drops. Not because redesigns are bad — but because most agencies and freelancers treat SEO as an afterthought. Use this checklist to protect everything you've built before, during, and after launch.

The most dangerous part: traffic often holds steady for the first 2–4 weeks after a bad launch, while Google reindexes. By the time the drop shows up in your analytics, the damage is already done and harder to fix. Prevention is the only reliable approach.

Phase 1: Before the redesign

The work you do before a line of code is written determines how much you have to protect and what you must preserve.

Crawl and document the existing site

Before anything changes, run a full crawl of the current site using Screaming Frog (free up to 500 URLs) or a similar tool. Export a complete list of every URL, its title tag, meta description, H1, and whether it's indexed. This is your baseline — you'll need it to build redirects and verify nothing was lost.

Also download a full export from Google Search Console → Performance → Pages. This tells you which pages are actually generating organic traffic and should be treated as highest priority to protect.

Identify your top-performing pages

Not all pages are equal. Some are driving the majority of your organic traffic and leads. In GSC, sort pages by clicks and export the top 20–50. These are non-negotiable — their URLs must either stay the same or receive proper 301 redirects, their content must be preserved, and their title tags and meta descriptions should be carried over.

Document your backlink profile

Export your backlinks from Google Search Console (Links → External Links → Top linked pages). These are URLs on your site that external sites link to. If those URLs change without redirects, every one of those backlinks becomes broken — and you lose all the authority they pass. Use Ahrefs Free for a more complete backlink view.

Record all existing redirects

If the current site already has 301 redirects in place, document them. A redesign is an opportunity to fix redirect chains (redirect → redirect → redirect), but only if you know what you're replacing. Losing existing redirects during a migration can break pages that have been working correctly for years.

Agree the URL structure before any development starts

The biggest SEO mistake in redesigns is changing the URL structure. Agree on the final URL structure with your designer and developer before any development starts. If any URLs must change, document every mapping (old URL → new URL) so you can build redirects from day one — not as an afterthought after launch.

Phase 2: During development

Block the staging site from crawlers

Your staging or development site should be blocked from search engines — either with a noindex meta tag on every page, a robots.txt that disallows all crawlers, or password protection. If Google indexes the staging site, it may treat the staging URLs as duplicates of the production URLs and cause indexing conflicts.

Preserve existing meta tags and headings

Every page's title tag, meta description, and H1 should be carried over from the existing site — or actively improved. Don't leave them blank, don't let the CMS auto-generate generic ones, and don't let the design process reset them to placeholders that never get filled in before launch.

Preserve existing content

If a page is ranking and generating traffic, don't delete or thin out its content without understanding the ranking risk. Redesigns often result in content being "cleaned up" — long, detailed pages replaced with shorter, prettier versions — and then traffic drops because the original content was what Google was rewarding. If the design calls for shorter pages, at minimum check whether those pages are ranking before trimming them.

Build the redirect map

If any URLs are changing, build a redirect map before launch — a spreadsheet with every old URL and its corresponding new URL. Every URL from the existing crawl should be accounted for. This map becomes the instruction set for whoever implements the redirects on the server.

Add schema markup from the start

A redesign is the best time to add or improve schema markup, since you're touching the HTML of every page anyway. At minimum: LocalBusiness or Organization on the homepage, FAQPage on content pages, Article on blog posts, Service on service pages. Use the schema generator to create the JSON-LD code.

Optimise images at source

New designs tend to introduce new imagery. Set up the image workflow correctly from the start: WebP format, compressed to under 150KB for standard images, explicit width/height attributes, lazy loading on below-fold images. Starting with unoptimised images means a slow site from day one. See the full page speed guide for the correct process.

Test on mobile throughout

Google indexes the mobile version of your site. Any design element that works on desktop but breaks on mobile — text too small, buttons too close together, horizontal scrolling — is an SEO and UX issue. Test on real devices throughout development, not just in browser emulation.

Phase 3: Pre-launch checks

Run through this before any traffic is switched to the new site.

  • Crawl the staging site and compare the URL list against the old site. Every old URL should either exist at the same address on the new site or have a redirect entry in your map.
  • Test all redirects: use a bulk redirect checker to confirm every old URL returns a 301 to the correct new URL — not a 302 (temporary), not a 404 (broken), not a redirect chain.
  • Check canonical tags: every page should have a <link rel="canonical"> pointing to itself. No page should canonicalise to another domain or to a staging URL.
  • Verify robots.txt: the production robots.txt must NOT contain a blanket Disallow:/ — a common mistake when copying the staging robots.txt to production. Use the robots.txt generator to create a clean production version.
  • Check the sitemap: the sitemap should list only the canonical, indexable URLs on the new site. Update it to reflect any URL changes. Use the sitemap generator if building from scratch.
  • Run PageSpeed Insights on the staging site. A redesign that launches with poor Core Web Vitals scores is a missed opportunity — fix issues before launch rather than after.
  • Check all internal links: every internal link in the new design should point to the correct new URL — not to the old URL that will redirect. Redirects add latency and can cause issues; direct links are cleaner.
  • Check Open Graph tags: the og:image, og:title, and og:description tags should be set correctly on every key page. These control how the page looks when shared on social media. Use the OG tag generator to build them correctly.
  • Test forms and conversion paths: contact forms, lead magnets, and any conversion action should be tested end-to-end on the new site before launch.

Phase 4: Launch day

Don't launch on a Friday

If something goes wrong — redirects not working, pages returning 404s, indexing blocked — you want your developer available to fix it immediately. Launch on a Tuesday or Wednesday morning so there's a full working day (and week) to respond to issues.

Switch DNS and verify immediately

After the DNS switch, verify that the site is live, SSL is working, and the homepage loads correctly on both www and non-www. Check that the robots.txt is accessible and correct at yoursite.com/robots.txt. Check the sitemap at yoursite.com/sitemap.xml.

Test a sample of old URLs

Manually test 10–20 old URLs to verify they redirect correctly to the new URLs. Pay particular attention to your highest-traffic pages from the pre-launch GSC export. Use an HTTP header checker to confirm each returns a 301, not a 302 or 404.

Submit the updated sitemap to GSC

Go to Google Search Console and submit the new sitemap immediately. This prompts Google to begin recrawling the new site structure. It won't happen instantly — Google crawls on its own schedule — but submitting tells it to prioritise your site.

Request indexing on key pages

In GSC, use the URL Inspection tool to request indexing on your most important pages: homepage, main service pages, top blog posts. This is not guaranteed to speed up crawling but it's a signal of priority.

Phase 5: Post-launch monitoring

Watch GSC daily for the first two weeks

Check the Coverage report (now called Indexing → Pages) for any spike in 404 errors — these mean URLs that were supposed to redirect aren't doing so. Every 404 on a page that used to rank is a lost ranking.

Check the Performance report to see if impressions and clicks remain stable. A gradual reindexing over 2–4 weeks is normal. A sudden drop in impressions after launch usually means pages aren't being discovered or indexed correctly.

Monitor for crawl errors

GSC's Coverage report flags specific URLs returning errors. Go through these systematically — fix 404s with redirects, resolve soft 404s (pages returning 200 but with no useful content), and check any redirect errors.

Check Core Web Vitals

The CWV report in GSC takes 4–6 weeks to show real-world data for the new site. Once it's available, check for any pages that have moved from "Good" to "Needs Improvement" or "Poor" — the new design may have introduced performance issues not visible in lab testing.

Verify backlinks still resolve

After 2–3 weeks, check your top-linked pages in GSC or Ahrefs. External links pointing to old URLs should be resolving to the correct new URLs via 301. If any backlinks are returning 404s, the redirect was missed — add it immediately.

Common redesign SEO disasters

No redirects for changed URLs. Every URL that changes without a redirect loses its ranking history, all backlinks, and any direct traffic from bookmarks or shared links. The fix after the fact is to implement the redirects — but crawl authority doesn't recover quickly.
Blocking the live site in robots.txt. Copying the staging robots.txt (which often has Disallow: /) to production blocks Google from crawling the entire site. Rankings disappear within days. Always check robots.txt on launch day.
Launching with noindex on the live site. Similarly, staging sites often have noindex meta tags on every page. If these aren't removed before launch, Google will stop indexing your pages. Check for this explicitly in the pre-launch crawl.
Removing content that was ranking. "Cleaner" design often means less content. If a long-form service page was ranking for 15 keywords, replacing it with a minimal one-paragraph version will likely lose most of those rankings. Redesign the presentation, not the content.
Slow launch performance. A redesign with beautiful visuals but uncompressed images and render-blocking scripts can cut your Core Web Vitals scores in half. Run PageSpeed Insights on the staging site and fix issues before launch.
Planning a redesign?

Every Bisyri rebuild includes a full SEO audit of the existing site, a redirect map, and post-launch monitoring — so you don't lose what you've already built. Get in touch to talk through what's involved.