Website Redesign SEO Checklist: Keep Your Rankings

Keeping your rankings through a website redesign means recording how the current site performs, keeping or redirecting every URL that has traffic or links, and carrying over the content and on-page signals that earned those rankings. Then you test the new site before launch and watch it closely for several weeks afterwards. Most traffic losses after a redesign come from missing redirects, removed content or a staging block left in place, and nearly all of them are preventable.

This checklist follows the order of a real redesign project: before design starts, during build, at launch and after go-live.

Why redesigns so often hurt rankings

Search engines rank individual pages, not websites as a whole. Each ranking page has built up signals over time: its URL, its content, the internal links pointing to it, external backlinks, its title and headings, and how well it serves people who land on it. A redesign can disturb all of those at once.

The usual culprits are:

• Changed URLs without redirects, so links and rankings point to pages that no longer exist.
• Content cut for the sake of design, such as long service pages trimmed to a few lines and a large image.
• Menu and internal linking changes that bury important pages deeper in the site.
• Technical blocks carried over from staging, such as a noindex tag or a robots.txt disallow.
• Lost metadata and structured data when a new theme or platform does not carry them across.
• Slower or less stable pages from heavy design elements, sliders and scripts.

Some movement in rankings after any significant change is normal while search engines recrawl and reassess the site. This checklist is about keeping that wobble small and short-lived.

Benchmark the current site before you start

You cannot judge the impact of a redesign without a clear picture of where you started. Before any design work begins, capture the following.

• Organic traffic and conversions by landing page from Google Analytics, over at least the last twelve months so you can account for seasonality.
• Queries, clicks and impressions by page from Google Search Console. Export these, as Search Console only keeps a limited history.
• Rankings for your priority keywords, including local results if you serve particular areas.
• Backlinks by target URL from a backlink tool, so you know which pages carry external authority.
• A full crawl of the site using a crawler, saving every URL, status code, title, meta description, H1, canonical and word count.
• Page speed and Core Web Vitals for key templates, from Search Console and PageSpeed Insights.

Keep these exports somewhere safe. After launch, they become the reference you compare against, and the crawl is the raw material for your redirect map.

Plan the site structure and URL map

The single most important SEO document in any redesign is the URL map: a spreadsheet listing every old URL and where it will live on the new site.

Keep URLs where you can

If a URL is clean and descriptive already, the safest option is to keep it exactly as it is. Changing URLs purely for tidiness adds risk with little benefit. Only change them where there is a clear reason, such as a move to a new platform with fixed URL patterns or a proper restructure of your services.

Map every page that matters

Each old URL gets one of three outcomes.

Redirect to the most relevant equivalent, not to the homepage. Google usually treats a mass redirect to the homepage like a missing page, so the value is lost anyway.

Prioritise pages with organic traffic, conversions or backlinks, but do not ignore the long tail. Old blog posts and PDFs can carry links you have forgotten about.

Agree who owns SEO in the project

Redesigns usually involve several people: a designer, a developer, someone writing or approving content, and the business owner or marketing manager signing things off. SEO tasks fall between those roles very easily. The designer assumes the developer is handling redirects, the developer assumes the content is being migrated by someone else, and nobody checks the staging block on launch day.

Avoid that by agreeing ownership at the start. The easiest way is to give each checklist item an owner and a deadline in your project plan.

• Benchmarking and URL mapping: the SEO lead, with input from whoever knows the business’s priority pages.
• Content inventory and migration: the content owner, reviewed by the SEO lead before templates are signed off.
• Redirects, canonicals, sitemaps and robots.txt: the developer, checked by the SEO lead on staging and again at launch.
• Analytics and conversion tracking: whoever manages your reporting, tested before and after go-live.
• Post-launch monitoring: a named person who checks Search Console at agreed intervals and has authority to request fixes.

Build SEO review points into each design sign-off stage as well as the final week. Changing a wireframe costs an hour, while rebuilding a template after launch can cost weeks. If you are not sure where your current site stands before you begin, a digital marketing audit can give you a clear baseline and highlight which pages matter most.

Protect your content during design

Design teams naturally want clean, minimal pages, which is fine as long as the substance survives. Pages rank because they answer the searcher’s question well, and removing that content to suit a template is one of the most common causes of post-launch decline.

• Inventory content for each ranking page before wireframing, and design templates that can hold it comfortably.
• Keep the headings, copy, FAQs and supporting detail that match the queries each page ranks for. Improve them by all means, but do not strip them out.
• Avoid hiding core content in tabs, carousels or accordions that require scripts to load. Content in the HTML is safest.
• Retain text that describes your services and locations in plain language, which matters for both search engines and AI answer tools.
• Review merged pages carefully. Combining thin pages into one stronger page can help, provided the new page still answers everything each original did.

If you are planning a content overhaul at the same time, consider doing it in stages. Changing design, structure and content all at once makes it very hard to diagnose any problems later.

Carry over on-page and technical signals

Many signals live in the template or the CMS rather than in the visible copy, which makes them easy to lose when the theme or platform changes. Check each of these for every important page.

• Title tags and meta descriptions, migrated or rewritten by a person rather than left to template defaults.
• One clear H1 per page and a logical heading structure.
• Canonical tags pointing to the correct final URL on the new site, not the staging domain.
• Structured data, such as Organization, LocalBusiness, Product, Article or FAQ markup where it applies, validated after migration.
• Image alt text and file names, especially for product and portfolio images.
• Hreflang tags if you run versions of the site in more than one language, such as English and Welsh. Our guide to bilingual websites for Welsh businesses covers this in more detail.
• Internal links in menus, footers and body content, updated to point straight at final URLs rather than through redirects.
• XML sitemap listing only canonical, indexable URLs on the new site.
• Analytics and tag manager installed, with conversion events recreated and tested.

Build and test on a protected staging site

Your staging site should be hidden from search engines, but in a way that cannot accidentally survive launch. Password protection or IP restriction is the most reliable approach, because it stops crawling entirely and does not depend on remembering to remove tags.

If you do use a noindex tag or a robots.txt disallow on staging, add a launch-day task to remove it, and assign that task to a named person.

Before launch, crawl the staging site and compare it with your original crawl. Look for these problems.

• Pages from the URL map that are missing.
• Broken internal links and redirect chains.
• Missing or duplicated titles, descriptions and H1s.
• Canonicals or links that reference the staging domain.
• Pages with much lower word counts than their originals.
• Noindex tags on pages that should be indexed.

Test performance at this stage too. Run key templates through PageSpeed Insights or Lighthouse and fix heavy images, render-blocking scripts and layout shifts before launch. A redesign is the cheapest point to build speed in, and our website speed optimisation team often works alongside designers for exactly that reason.

Launch-day checklist

Launch is not the moment to improvise. Work through a written list, ideally early in the week so the team is around to fix anything that goes wrong.

1. Remove staging protection, and check that robots.txt allows crawling and that no unintended noindex tags remain.
2. Deploy the redirects from your URL map, as server-side 301 redirects.
3. Test a sample of redirects, including your highest-traffic and most-linked old URLs, checking each goes directly to the right page in a single hop.
4. Confirm HTTPS and the preferred domain work correctly, with HTTP and non-preferred versions redirecting cleanly.
5. Submit the new XML sitemap in Google Search Console and Bing Webmaster Tools.
6. Check analytics and conversion tracking by completing test enquiries or purchases.
7. Use URL Inspection in Search Console on key pages to confirm Google can fetch and render them.
8. If the domain itself has changed, keep ownership of the old domain, maintain its redirects and use Search Console’s Change of Address tool.
9. Crawl the live site and compare against your pre-launch benchmark.

Keep the old domain and its redirects in place for the long term. Removing redirects a few months later throws away the value they were preserving.

Monitor and fix quickly after launch

The first few weeks after launch tell you whether the migration has held. Check these at least weekly to begin with.

If a page loses visibility, compare it with the old version: was content cut, a redirect missed, internal links reduced or the heading changed? Most problems become obvious once you put the before and after side by side.

Recovery timescales vary with the size of the site and how much changed. Small sites with clean migrations often settle quickly, while larger restructures can take longer. Beware of anyone who promises no movement at all.

Common redesign mistakes to avoid

• Leaving SEO until the site is almost built, when templates and URLs are hard to change.
• Redirecting everything to the homepage.
• Launching on a Friday or just before a holiday.
• Letting the old domain or hosting expire, taking redirects with it.
• Replacing written content with images of text or video only.
• Changing platform, domain, structure and content in one go without a plan to isolate issues.
• Assuming the new CMS or theme handles titles, canonicals and schema correctly without checking.

Planning your own redesign

A good redesign leaves the site faster and better at turning visitors into enquiries, and keeps the search visibility you spent years building. Most of that comes down to preparation done before anyone opens a design tool. Start with the benchmark crawl and the URL map, because every later step depends on them.

On our own website redesign projects, SEO is on the agenda from the first workshop. We also run technical SEO migrations for businesses whose developers are building the new site, handling the redirect map, launch checks and the weeks of monitoring afterwards.

Share:LinkedInXEmail