The Website Redesign Checklist That Protects Your SEO

A redesign is one of the fastest ways to improve how a business is perceived — and one of the fastest ways to lose the organic traffic it already had. We regularly speak to owners a few weeks after a relaunch who tell us the same story: the site looks far better, everyone internally is pleased, and enquiries have quietly halved. Nothing obvious is broken, so nobody knows where to look.

The uncomfortable truth is that rankings almost never collapse because of the new design. They collapse because of what happened around it — URLs that changed without redirects, pages that were cut because they looked dated, headings and internal links that were rewritten out of existence, or a staging site that shipped with search engines still blocked. Every one of those is preventable with a plan made before the first mockup.

Across 50 delivered builds — 42 on WordPress, 5 on Bubble.io, one hybrid build and one custom Next.js application — we have settled on a sequence that keeps the visible improvement and the invisible equity. This is that checklist, in the order we actually run it. Work through it and a redesign becomes a step up rather than a reset.

Why redesigns lose traffic in the first place#

Search engines do not rank a design. They rank pages: specific URLs with specific content, linked to from specific places, with a history of satisfying specific queries. A redesign touches all four of those things at once, which is why it carries more risk than any other routine project a business runs on its website.

When we audit a redesign that went wrong, the cause is nearly always in this list:

• URLs changed to a new structure with no redirect map, so every ranking page returns a 404.
• Content was trimmed for visual tidiness, removing the 800-word service pages that were doing the ranking.
• Headings became images or decorative text, so the on-page signals disappeared even though the words are still visible.
• Internal linking was simplified into a slim navigation, cutting deep pages off from the rest of the site.
• Title tags and meta descriptions were regenerated by the new theme instead of being carried across.
• The staging site launched with noindex or a Disallow rule still in robots.txt.
• Page speed regressed because the new build ships heavier images, more fonts and more third-party scripts.

Step 1: Benchmark and archive before anything changes#

You cannot protect what you have not measured. Before a single page is designed, capture a complete picture of the current site. This takes an afternoon and it is the only reason you will be able to answer the question everyone asks two months later: did the redesign actually help?

Crawl the live site and keep the crawl#

Run a full crawl of the existing site and export it. You want every URL that returns a 200, along with its title tag, meta description, H1, word count, canonical tag and status code. Export your XML sitemap separately, and pull the list of URLs that have earned impressions in the last twelve months from Search Console. Those three lists together are your inventory — and the Search Console list matters most, because it includes pages your crawler may never reach through navigation.

Also export your backlink profile. Pages with external links pointing at them are the ones where a broken redirect costs real money, and they deserve individual attention rather than a bulk rule.

Record the baseline you will be judged against#

Note organic sessions, organic conversions, impressions and average position for the previous three months, plus your Core Web Vitals field data. Save a copy of the numbers somewhere outside the analytics tool, because tracking configuration often changes during a rebuild and you will want a fixed reference point. Where the site is being replatformed entirely, take screenshots of your top twenty pages too — they settle a surprising number of arguments about what the old site actually said.

Step 2: Decide what happens to every single URL#

This is the step that separates a clean redesign from a painful one. Take your inventory into a spreadsheet and give every old URL a decision: it stays as it is, it moves to a new URL, it merges into another page, or it is retired. There is no fifth option, and no URL is allowed to be blank.

Our default advice is to keep URLs unchanged wherever the page is genuinely staying. A prettier slug is worth very little; a redirect chain is a permanent tax. Change the structure only when the old one is actively harmful — duplicate paths, dates baked into evergreen article URLs, or a taxonomy nobody understands.

Two rules save more traffic than everything else here. First, never bulk-redirect a set of retired pages to the home page — search engines treat that as a soft 404 and the equity evaporates. Second, redirect old URL to final URL directly. Chains of two or three hops accumulate quickly across successive redesigns and slow every request that follows them.

On an Apache-hosted WordPress site the map itself is unglamorous, which is exactly the point:

# Place above the default WordPress rewrite block in .htaccess.
RewriteEngine On

# One line per individually mapped page.
Redirect 301 /web-design-agency /services/website-design
Redirect 301 /about-us-2 /about

# Pattern rule: the whole old news folder becomes /blog/.
RewriteRule ^news/(.*)$ /blog/$1 [R=301,L]

# Force a single canonical host and scheme.
RewriteCond %{HTTP_HOST} ^www\.example\.com [NC,OR]
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]

Step 3: Protect the pages that already earn#

Redesigns tend to be led by the home page, because that is what everyone looks at in the kick-off meeting. In our experience the pages that actually bring in enquiries are service pages, location pages and long-form articles — the ones nobody presents in a mockup review. Identify your top twenty organic landing pages early and make them a formal part of the design scope.

For each of those pages, carry the signals across deliberately rather than hoping the new template reproduces them:

• Keep the title tag and meta description, or improve them consciously — do not let a theme regenerate them.
• Keep one H1 per page, and keep the heading hierarchy without skipping levels.
• Keep the substantive body copy. If a page ranks on 900 words, a 200-word redesign of it will not hold.
• Keep the internal links that point into the page, including contextual links from articles.
• Keep structured data — organisation, service, article, FAQ and breadcrumb markup all need porting.
• Keep image alt text, and keep the images themselves indexable at sensible file names.

Where content genuinely is weak, improve it during the redesign rather than deleting it. Consolidating five thin pages into one authoritative guide is usually a gain. Quietly dropping five thin pages that collectively earned a fifth of your traffic is a loss you will feel for months.

Step 4: Rebuild the technical foundations, not just the visuals#

A redesign is the cheapest opportunity you will ever get to fix the technical layer, because everything is being touched anyway. Retrofitting the same work into a live site later costs several times more.

Performance is part of the brief#

Set a performance budget before the design is signed off, and hold the build to Google’s published Core Web Vitals thresholds: Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds, and Cumulative Layout Shift below 0.1. Those numbers are easy to hit when the hero image is sized properly, fonts are self-hosted with explicit dimensions on media, and third-party scripts are counted. They are very hard to retrofit into a page builder layout with six sliders and four tracking tags.

Get the indexing rules right#

Every redesign needs an explicit plan for canonical tags, pagination, faceted URLs and any parameter-driven pages the new build introduces. Filters that generate URL parameters are the most common accidental duplication we find after a launch, particularly on WooCommerce stores where colour and size filters can multiply a 200-product catalogue into thousands of crawlable variants.

Plan multilingual structure up front#

If the site serves more than one language, decide the URL structure and the hreflang strategy before build, not after. We have shipped sites in English, German, French, Italian, Hebrew, Polish, Dutch and Norwegian, and the pattern is consistent: language handling bolted on at the end produces missing return tags, untranslated meta data and duplicate home pages. Right-to-left builds in particular — such as our Hebrew e-learning work — need the layout tested in both directions from the first template, not the last sprint.

Step 5: The pre-launch checklist#

Run this in order on the staging site in the days before go-live. Every item is something we have seen break a real launch.

1. Crawl the staging site and compare the URL inventory against your old-site export — anything missing needs a decision, not a shrug.
2. Test the redirect map in bulk by running every old URL through a crawler and confirming a single 301 hop to a 200 response.
3. Confirm no redirect resolves to a 404, a redirect chain, or the home page by accident.
4. Check that every page has a unique title tag and meta description, and that none are empty or duplicated across templates.
5. Verify one H1 per page and a heading hierarchy that never skips a level.
6. Validate structured data on the templates that carry it, including breadcrumbs and FAQ markup.
7. Regenerate the XML sitemap so it lists only final, indexable URLs, and confirm robots.txt points at it.
8. Remove the staging noindex directive and the Disallow rule — check both, they live in different places.
9. Confirm analytics and conversion tracking fire on the new templates, including the form success state.
10. Test forms end to end and confirm the enquiry actually arrives in the inbox that receives it.
11. Run Lighthouse on the templates that matter — home, service, article, contact — on a throttled mobile profile.
12. Check the site at 360px width for horizontal overflow, and tab through it to confirm visible focus states.
13. Take a full backup of the old site and database, and keep it until you are three months clear of launch.

Step 6: Launch day and the first 30 days#

The work is not finished when DNS propagates. A redesign typically causes a visible fluctuation in rankings for a few weeks while search engines re-crawl and re-evaluate the new pages. That is normal. What is not normal is a decline that does not recover, and the only way to tell the difference is to watch closely.

• Submit the new XML sitemap in Search Console on launch day and request indexing for your most important pages.
• Watch the Pages report daily for the first fortnight — a spike in Not Found or Redirect Error is your early warning.
• Fix newly reported 404s by adding them to the redirect map, and keep the map under version control.
• Compare organic landing-page performance against your baseline weekly, not daily; daily data is too noisy to act on.
• Re-run Core Web Vitals field data after 28 days, once real user data has accumulated on the new build.
• Keep the old site accessible internally for a quarter so you can settle any question about what changed.

How we approach redesigns at Tekvion#

We start every redesign with an inventory and a redirect map, before design work begins. It is not the glamorous part of the project, but it determines whether the launch is uneventful. The inventory tells us which pages must survive; the map tells the build team which URLs are fixed and which are free to change. Design then works within those constraints, which turns out to be a creative help rather than a hindrance — it forces early clarity about what each page is actually for.

Scale changes the emphasis but not the method. A multi-location retail site with hundreds of showroom pages needs template-level redirect rules and careful handling of the store locator; a specialist clinic site needs its appointment flows and German-language meta data carried across intact; a Dutch WooCommerce store needs its product URLs, category structure and filter parameters mapped before a single template is rebuilt. Same checklist, different pressure points.

We also insist on a staging environment that mirrors production, a full backup that is verified rather than assumed, and a launch window with people available. Most redesign disasters we have been asked to rescue were not caused by a lack of skill. They were caused by launching in a hurry, on a Friday, with no way back.

Where to start#

If your current site is dated but earning, the goal is not a blank page — it is a rebuild that keeps every signal you have accumulated and improves everything you have not. Start with the inventory this week: crawl the site, pull your Search Console data, and list the twenty pages you cannot afford to lose. That single document will shape the entire project.

If you would rather not run it alone, this is exactly the work we do. Our website redesign service covers the inventory, redirect mapping and rebuild end to end; our SEO services cover the audit, on-page carry-over and post-launch monitoring; our migration and replatforming work handles the harder cases where the CMS or domain is changing too; and our UI/UX design practice makes sure the new site is genuinely easier to use, not just newer to look at. Tell us what your current site earns and we will tell you honestly what a redesign should protect.