Website Redesign SEO Checklist: Protect Rankings

A website redesign SEO checklist helps you protect the pages, content and links that already bring people to your site, while making the new experience easier to use. The safest approach is to plan SEO alongside the design, map every changed URL, preserve useful content and test the live site immediately after launch. If you are planning a rebuild, see how DesignFIT approaches website design and builds.

A redesign can improve search performance, but a new look on its own does not guarantee better rankings. The decisions that shape the information architecture, page layouts, mobile experience and interaction design also affect what search engines can crawl and what visitors can understand. Treat those decisions as part of the migration plan, not as finishing touches.

Use this checklist whether you are changing your design, content management system, domain or all three. Some steps are technical, but you do not need to carry them out alone. A designer, developer and SEO specialist should agree on the page structure, content and launch checks before work begins. For planning material, browse DesignFIT’s website resources or consult our small business website redesign cost guide.

Start with the design decisions that protect search performance

A migration is not simply moving a collection of files. It is moving a set of user journeys, page relationships and search signals into a new design. Before drawing layouts, understand what people visit for, which pages lead to enquiries and how visitors move from an entry page to a useful next step.

A beautiful redesign can lose visibility if it removes the content that made an important page relevant, hides key service links or makes the primary content difficult to access. The reverse is also true: a clear hierarchy, useful copy and responsive page experience can make the site easier for people and crawlers to understand.

Checklist: set a baseline before design begins

• Crawl the existing website and save the results so you have an inventory of URLs, status codes, page titles, headings, canonical tags and internal links to compare with the new site.
• Export organic landing-page data from Search Console and analytics so you can see which pages currently attract search visits and which contribute to enquiries or sales.
• Record the date range and measurement method for every baseline because traffic varies by season, campaign and tracking setup, and a fair comparison needs consistent periods.
• List valuable backlinks and referring pages so URLs that other websites link to are not accidentally removed or redirected to an irrelevant destination.
• Record important search queries and landing pages so the redesign team understands the intent a page currently serves, not just the words used in its title.
• Capture current conversion paths such as service-page visits followed by contact-form submissions, because a redesign should preserve useful journeys as well as traffic.
• Save screenshots of key desktop and mobile pages so you can compare hierarchy, content visibility and calls to action when reviewing staging designs.
• Note known technical and usability issues separately so the new site does not inherit problems simply because they were present on the old one.

For smaller sites, a spreadsheet and a careful crawl may be enough. Larger sites may need a dedicated crawler or support from an SEO specialist. Reviewing an established website redesign SEO checklist helps ensure you capture all pre-launch benchmarks. Screaming Frog’s SEO Spider pricing and licence details explain its crawl limits and paid features. Choose a tool based on the size and complexity of your site, not because a tool can replace decisions about what to keep.

Checklist: identify the pages that matter most

• Mark pages that drive leads, sales or high-intent visits so design and development teams give them appropriate attention during the rebuild.
• Flag pages with strong organic traffic or valuable backlinks because they carry visibility or authority that can be damaged by deletion, URL changes or weak redirects.
• Include non-obvious pages such as campaign landing pages, PDFs and image URLs because important visits and links may not be limited to the main navigation.
• Check whether a page has a role even if it receives little traffic because it may support a conversion journey, answer a key customer question or link to a high-value service page.
• Agree on the business owner for each priority page so someone can confirm that the redesigned page still answers the right customer need.

Do not use traffic alone as the measure of value. A page that attracts fewer visits may still help someone compare services, understand a regulated process or decide to contact your team. Look at the whole journey and the quality of the enquiry, not just the number of page views.

Plan the new structure before polishing page designs

Information architecture is the way pages are grouped and connected. It matters to visitors because it helps them find their next step. It matters to search because internal links help crawlers discover pages and understand how the site is organised.

A redesign often changes navigation to make it cleaner. That can be a good decision, but a simpler header should not leave important service, category or location pages without clear links. A page can be technically live and still be hard to find if no useful page links to it.

Checklist: build a crawlable, useful page hierarchy

• Draw the proposed sitemap before designing the navigation so the team can see how service, product, location and supporting pages relate.
• Keep important pages reachable through clear navigation or contextual links because visitors should not have to guess where to find core information.
• Give every retained page a clear purpose and a place in the structure so the new site does not create duplicate pages that compete for the same need.
• Use descriptive link text where it helps people understand the destination because “services” or “learn more” is less informative than naming the service or topic.
• Plan links from relevant pages to priority pages so content, navigation and conversion journeys reinforce one another.
• Check that key pages remain accessible on mobile because a desktop-only navigation path is not a practical route for visitors using a phone.
• Review breadcrumbs, related links and category pages so useful paths remain available even if the header menu becomes more compact.
• Avoid relying on search boxes or interactive menus as the only route to important content because visitors and crawlers need ordinary, discoverable links as well.

The goal is not to put every link in the main menu. It is to make the site’s hierarchy visible in more than one sensible way. A person reading a service page might need to compare another service, read a relevant guide or contact the business. Design those routes into the page rather than adding links as an afterthought.

Checklist: map old URLs to the new site

• Create a complete old-to-new URL spreadsheet so every changed or removed URL has an agreed destination before launch.
• Match each old page to the closest page that satisfies the same intent because sending unrelated pages to the homepage can confuse visitors and search engines.
• Keep a URL unchanged when there is no good reason to alter it because avoiding unnecessary changes reduces migration work and the chance of errors.
• Decide whether each retired page should be redirected, consolidated or intentionally removed so the outcome reflects whether its content still has a useful successor.
• Check the proposed destination page exists and returns successfully so redirects do not lead to a broken URL or another redirect.
• Include trailing slash, case, query-string and file-format variants where relevant because real links and bookmarks may use more than one version of a URL.
• Identify image, document and download URLs that will change so assets with links or search visits are not overlooked.
• Record the reason for each unusual mapping so reviewers can spot a homepage redirect or an unrelated destination before it goes live.

A 301 redirect tells browsers and crawlers that a page has moved permanently. Google’s site move guidance recommends mapping URLs to relevant new destinations and avoiding irrelevant redirects. A redirect is not a way to transfer the value of any old URL to any new page. The destination should make sense to someone who followed the old link.

Do not redirect every deleted URL to the homepage. If a page has no relevant replacement, decide whether it should return a not-found response or whether its useful information belongs on a genuinely related page. A redirect to a page that does not meet the visitor’s expectation can be a poor experience even if it avoids an obvious 404.

Preserve useful content while improving the design

Content parity means that the new site retains the important information and meaning of the old one, even if the wording or layout is improved. It does not mean copying every sentence forever. It means making deliberate choices about what to keep, revise, combine or remove, with an understanding of the search intent and business value each page serves.

A common redesign pressure is to make pages feel shorter and more minimal. Minimalism can improve focus, but deleting useful explanations, service details, location information or customer questions may leave a page less helpful. Instead of cutting copy to make a layout look clean, design a layout that makes the necessary information easier to scan.

Checklist: decide what content stays

• Label each existing page Keep, Improve, Combine or Remove so content decisions are explicit rather than made during a last-minute design review.
• Keep content that answers real customer questions or supports a decision because useful detail can build confidence and help a visitor choose the right next step.
• Retain the page’s main search intent when rewriting it so a page about one service does not become a generic brand statement.
• Preserve key facts such as services, locations, qualifications and conditions so the redesigned page remains accurate and useful to prospective customers.
• Combine overlapping pages only when the resulting page can serve their shared purpose clearly because a vague catch-all page may satisfy neither audience well.
• Preserve helpful FAQs, specifications and process information when they answer concerns that can prevent a customer from enquiring or buying.
• Review headings as a hierarchy, not as styling choices so headings describe sections and help people scan the page in a logical order.
• Check image captions, alt text, downloadable files and embedded content because useful information may live outside the main body copy.
• Update outdated details rather than carrying them forward unchanged so the site does not preserve errors for the sake of parity.
• Have a subject expert approve changes to important pages because a design team should not guess at service claims, legal wording or operational details.

A new design can preserve content without presenting it as a wall of text. Use a clear heading hierarchy, short paragraphs, lists, comparison tables and meaningful accordions where they improve scanning. If content is placed in an accordion, make sure it remains available in the page and that the interaction works for keyboard and touch users. Do not hide essential information simply to make the first screen look sparse.

Checklist: make every important page work as a designed experience

• Give each priority page one clear primary action so visitors know what to do after understanding the offer.
• Make the first screen explain who the page is for and what it offers because a visual hero that says little about the service can leave both visitors and crawlers short of context.
• Place proof near the claims it supports so testimonials, credentials, examples or process details help resolve doubt at the moment it arises.
• Use imagery that explains or reinforces the offer rather than adding large decorative assets that slow the page without helping a decision.
• Write calls to action that describe the next step so a visitor can distinguish between booking, asking a question and requesting a quote.
• Keep forms proportionate to the enquiry because asking for unnecessary information can add friction at the point where the visitor is ready to act.
• Provide useful internal links within the page content so visitors can explore related services or answers without returning to the menu.
• Check that page titles and visible headings accurately describe the page so searchers see a consistent promise from result to landing page.

Design and SEO are not competing disciplines. A stronger layout can make important information easier to notice, while useful content gives the design something meaningful to organise. The best review question is not “Can we make this shorter?” but “What does the visitor need to understand here, and how can the layout make that easier?”

Test the staging website before launch

A staging site is a private or temporary version of the new website where the team can review and test changes before publishing them. Treat it as a working product, not just a visual preview. Test real page templates, mobile behaviour, internal links, forms, metadata and crawl access before the launch window.

Checklist: compare the new site with the old one

• Crawl the staging site and compare it with the saved old-site crawl so missing pages, changed URLs and unexpected status codes are visible before launch.
• Check a sample of every page template, not just the homepage because a shared template error can affect many service, product or article pages at once.
• Compare priority-page content against the approved content inventory so important explanations, headings, links and calls to action survive the redesign.
• Review page titles, meta descriptions, headings and canonical tags so search engines receive accurate signals for each new page.
• Check that internal links point to the intended final URLs because staging links, old paths and temporary domains can create broken journeys.
• Test forms from start to finish so submission, confirmation messages, notifications and tracking all work as intended.
• Test navigation, accordions, menus and other interactions by mouse, keyboard and touch so the redesigned experience is usable beyond a desktop pointer.
• Review the mobile layout at common viewport sizes because columns, buttons, menus and image crops can behave differently on a narrow screen.
• Check that important text is present in the rendered page so essential information is not missing when scripts fail or a component does not load.
• Protect staging from public indexing using an appropriate access restriction so a temporary copy is not mistaken for the production website.

A staging noindex directive can be appropriate in some setups, but it must not be carried into production. Build that check into the release process rather than relying on someone to remember it at the end. Likewise, staging should not be publicly crawlable simply because its URL is hard to guess. Ask your developer which access controls suit the hosting setup.

Checklist: review speed and interaction design

• Test the main page templates on a real mobile connection or a realistic test setup because a design that feels quick on a developer’s desktop may feel slow to a customer on a phone.
• Optimise the largest visible image, often the hero image because oversized imagery can delay the main content people came to see.
• Avoid autoplaying video or image sliders as the default hero experience unless they add clear value and have been tested for performance and accessibility.
• Set image dimensions and reserve space for late-loading elements so the page does not jump while images, fonts or embeds load.
• Test menus, filters, carousels and forms for responsiveness because heavy interactions can make a page feel unresponsive even after its first content appears.
• Remove scripts and effects that do not support a user task because unnecessary JavaScript can add loading and interaction costs.
• Review font files, third-party embeds and analytics tags because the page’s performance depends on more than the visible design assets.
• Measure both laboratory tests and real-user field data where available because a single controlled test cannot represent every device and connection.

Google’s Core Web Vitals guidance describes three measures of loading, interactivity and visual stability. Google’s recommended “good” thresholds are an LCP of 2.5 seconds or less, an INP of 200 milliseconds or less and a CLS of 0.1 or less, assessed at the 75th percentile of page visits. These are useful targets, not a guarantee of rankings or conversions.

INP, or Interaction to Next Paint, measures how quickly a page responds visually after a user interacts with it. The web.dev explanation of INP covers the metric and common ways interaction delays occur. For a redesign, pay particular attention to menus, accordions, filters, booking flows and other components people need to use. A page that looks polished but responds slowly is not finished.

Launch without losing track of the details

Launch day is a controlled handover from the old site to the new one. The aim is not to make every possible improvement at once. The aim is to publish the approved design, activate the correct redirects, preserve tracking and make sure search engines can access the production site.

Checklist: before you publish

• Freeze and approve the final URL map so developers, content editors and SEO reviewers are working from the same redirect decisions.
• Back up the current site and confirm a recovery plan so the team knows how to respond if a critical technical failure appears.
• Confirm the production domain, hosting and SSL setup so the live site loads securely on its final hostname.
• Prepare redirects in the environment that will serve the live site so they take effect at launch rather than being added after visitors find broken links.
• Confirm the production robots directives allow intended crawling so staging restrictions do not accidentally block the live site.
• Check that production pages use production canonical URLs so new pages do not point to staging, a temporary hostname or the wrong URL variant.
• Prepare an XML sitemap containing the intended indexable URLs so search engines have a clean list of pages to discover.
• Confirm analytics, consent settings and conversion events are ready so you can measure the new site and spot tracking failures quickly.
• Assign one person to approve launch checks and one person to investigate issues so critical decisions do not get lost between teams.

For a domain change, follow Google’s site move and URL change documentation for the relevant steps, including its guidance for the Change of Address tool. The correct process depends on whether you are changing the domain, the URL paths or only the site’s design. Do not submit a domain-change request just because the visual design or CMS has changed.

Checklist: check the site as soon as it is live

• Open the homepage and several priority pages on desktop and mobile so you can catch obvious layout, loading and content problems immediately.
• Test old priority URLs against the redirect map so important bookmarks and external links reach the correct new pages.
• Check that each redirect resolves to a working destination because a redirect to another redirect or to an error page creates avoidable friction.
• Inspect a sample of live pages for the correct canonical and indexability settings so production pages do not inherit temporary staging signals.
• Check that the robots.txt file and XML sitemap are available and sensible so crawlers are not blocked from intended pages or directed to temporary URLs.
• Submit or update the sitemap in Search Console and other relevant webmaster tools so search engines can discover the new URL set.
• Submit test forms and complete key conversion actions so design, notifications and tracking work on the live site, not only in staging.
• Check analytics and conversion events in their reporting tools so an apparent fall in enquiries is not simply a measurement failure.
• Crawl the production site and review errors so broken internal links, missing metadata and redirect mistakes can be fixed while the launch is fresh.
• Check both the www and non-www versions, and HTTP and HTTPS behaviour so visitors and crawlers reach the intended canonical version.

Test more than a handful of URLs if the site has many pages. Start with every page that drives enquiries, sales, important organic visits or backlinks. Then test a representative sample of each template and URL type. A spreadsheet makes it easier to record the old URL, expected destination, actual response and owner for any fix.

Monitor the migration after launch

A successful launch is the beginning of the monitoring period, not the end of the project. Search engines need to discover and process the new pages and redirects. Your team also needs to confirm that people can use the new journeys and that the measurements are still working.

Do not assume that every movement in traffic is caused by the redesign. Compare like-for-like periods, check analytics implementation and consider seasonality, advertising changes and wider search demand. The purpose of monitoring is to find specific issues and respond to them, not to panic over every daily fluctuation.

Checklist: monitor search visibility, user journeys and errors

• Review Search Console for indexing and crawling issues so you can investigate unexpected exclusions, server errors or soft 404 reports, and check the Google Search Console Core Web Vitals report to catch performance degradation early.
• Check whether priority new URLs are being discovered and indexed so missing pages can be diagnosed rather than hidden among a large site-wide report.
• Watch organic clicks and impressions for priority page groups because a change affecting one template may be easier to identify in a focused comparison.
• Compare landing pages, enquiries and sales with your baseline so the team understands whether the redesign is supporting business outcomes, not just visits.
• Review server logs or crawl data if important pages remain inaccessible so the team can distinguish a discovery problem from a content or demand change.
• Check for 404s from old URLs, broken internal links and redirect chains so visitors and crawlers are not sent through unnecessary steps.
• Keep old-to-new redirects in place for at least a year, and longer where practical because external links, bookmarks and crawlers may continue to use old URLs. Google’s site move guidance recommends keeping redirects for at least a year and, where possible, indefinitely.
• Monitor real-user Core Web Vitals after enough field data is available so you can see how the redesigned templates perform for actual visitors.
• Ask sales and customer service teams what visitors are struggling to find because support questions can reveal gaps that analytics alone may not explain.
• Keep a dated log of changes and fixes so you can connect later performance changes to specific releases rather than guessing.

When a problem appears, diagnose it at page and template level. Check whether the URL resolves, whether the content is still present, whether the page is internally linked, whether its canonical is correct and whether the template works on mobile. Repair the underlying cause before making broad changes across the whole site.

Checklist: respond to a traffic drop methodically

• Confirm that analytics and conversion tracking still fire because a broken measurement setup can look like a real fall in performance.
• Check Search Console impressions as well as clicks because fewer clicks with similar impressions may point to a different issue than a loss of impressions.
• Compare affected old URLs with their new destinations so missing redirects or poor intent matches are easy to identify.
• Look for patterns by template, device, directory and query because a site-wide average can hide a problem limited to one page group.
• Inspect robots, noindex and canonical signals on affected pages so the new site is not accidentally telling crawlers to ignore pages you want found.
• Check whether content, internal links or navigation changed at the same time because a redesign may have removed useful information or routes to a priority page.
• Review server availability and response codes so technical failures are not mistaken for a content-quality issue.
• Make one evidence-based correction at a time where possible so you can understand which change helped and avoid introducing further confusion.

A redesign may lead to short-term movement while pages are recrawled and reassessed. But do not use that possibility to dismiss a clear technical fault. If a major landing page is missing, blocked, returning an error or redirecting to the wrong place, fix the issue promptly and verify the correction. Practical frameworks on how to avoid and fix organic traffic drops after a website redesign can help isolate whether the loss stems from technical crawl blocks or deleted keywords.

The complete website redesign SEO checklist

Use this condensed review before approving the new site. It is designed as a handover list for the owner, designer, developer and SEO reviewer.

Before design

• Crawl and export the current site.
• Save search, traffic, conversion and performance baselines.
• Identify priority pages, backlinks and customer journeys.
• Decide which pages to keep, improve, combine or remove.
• Agree on the new sitemap and page ownership.

Before launch

• Match important content and intent to the new page designs.
• Approve an old-to-new URL map and relevant 301 redirects.
• Check navigation, internal links, mobile layouts and forms.
• Review titles, headings, canonical tags and indexability.
• Test Core Web Vitals and key interactions on representative templates.
• Confirm production tracking, sitemap and release checks.

At launch and after

• Confirm production access, SSL and canonical URL behaviour.
• Test priority old URLs and their new destinations.
• Crawl the live site and fix errors, loops and broken links.
• Submit the updated sitemap and review Search Console.
• Monitor search, conversions, page experience and customer feedback.
• Keep redirects active for at least a year, and longer where practical.

A checklist reduces the chance of avoidable mistakes, but it cannot replace a clear design brief or careful migration planning. The right page structure helps people understand what you do. The right content gives them reasons to trust you. The right technical checks help the new site retain the visibility it has earned.

If your business is preparing for a redesign, make SEO, content and conversion goals part of the design conversation from the start. You can review our studio pricing, request a free AI search audit to benchmark current visibility, or talk to DesignFIT about a website redesign that is built to look considered and work hard for your business.