Website Redesign SEO Checklist: Protect Your Rankings (2026)

A redesign can lose search traffic that took years to build. Old pages vanish, addresses change without redirects, or a setting from the test site tells Google to drop the live one. This website redesign SEO checklist covers what to do before the build, during it, on launch day and in the weeks after. It can't freeze your rankings, but it deals with the usual reasons a redesign loses them, and you can do much of it with a spreadsheet and Google Search Console.

The 25 checks below fall into four stages. Keep one spreadsheet for the whole project: it starts as a list of your current pages and becomes your redirect map and launch-day test list.

Why redesigns lose rankings

Google ranks individual pages. A redesign puts rankings at risk when it changes those pages in ways Google notices:

• Addresses change without redirects, so old links and search results end on "page not found".
• Pages that ranked are removed or cut down to make the new design look tidier.
• Titles and headings are rewritten and stop matching what people search for.
• The test site's block goes live: a noindex tag or robots.txt rule meant for staging ends up on the real site.
• New templates are slower, or show less on a phone.

The lowest-risk redesign changes how pages look, not where they live or what they say. If your current addresses and content work, keep them, and most of this checklist becomes a quick check rather than a project.

1. Before the redesign: record what ranks now

• List every URL on the current site. A crawler such as Screaming Frog SEO Spider records each page's address, title, meta description and H1. Its free version crawls up to 500 URLs, which is enough for many small business sites. Then add what a crawl can miss: URLs in your XML sitemap, PDFs, old campaign landing pages and pages only other sites link to.
• Export your top pages and searches from Search Console. In the Performance report, set the date to the last 16 months (the most it shows) and export the Pages and Queries tabs. Exports stop at 1,000 rows; larger sites can get more through the Search Console API. Keep the files, because you'll compare against them after launch.
• Note the pages other sites link to. In the Links report, export Top linked pages under External links. Every page on that list needs a redirect, even if it gets few visits from search, so those links keep working.
• Benchmark traffic and enquiries. In Google Analytics, open Reports → Engagement → Landing page and note sessions and key events, such as enquiries or sales, for your main pages. Add the secondary dimension Session source / medium to see which visits came from Google. Record the last three months and the same months last year, so you can allow for seasonal changes.
• Decide what content stays. Mark each URL keep, merge or remove. Pages with clicks, rankings or outside links stay, and so does the text that earned them. Merging thin pages is fine if each old page redirects to the page that now covers its subject. A page with no traffic, no links and no job to do can go.

2. During the build: carry over what ranks

If any URLs change, read Google's guide to site moves with URL changes. The short version is below, with the rest of the build.

• Keep URLs that work. The safest address is the one Google already knows. Change a URL only for a clear reason, such as a messy structure or two pages becoming one.
• Map every old URL to a new one. Add a "new URL" column to your spreadsheet. Each old URL should get a permanent server-side redirect (a 301 or 308) to its closest new page. Don't send lots of old pages to the home page: Google may treat that as a "soft 404", in effect a missing page. Point each redirect straight at the final page, not through a chain.
• Keep titles, descriptions and headings on pages that rank. Copy them from your crawl unless you have a reason to change them, and keep the main text too. A service page that ranks with 800 words of useful detail shouldn't shrink to a banner and three lines because the new layout looks cleaner.
• Rebuild internal links. Menus, footers and links in your text should point at the new URLs, not at old ones that redirect. Keep important pages in the main menu, within a couple of clicks of the home page, and give each page a canonical tag that points at its own new URL.
• Carry over structured data. If the old site had markup for your business details, products, articles or breadcrumbs, add it to the new templates. Test it with Google's Rich Results Test, which accepts pasted code while staging is behind a password. Don't rebuild FAQ markup for rich results: Google stopped showing FAQ rich results in May 2026.
• Keep the staging site out of Google. Put it behind a password. Google says robots.txt doesn't keep pages out of its results, and a noindex tag on staging is easy to carry over to the live site by mistake. On WordPress, the "Discourage search engines from indexing this site" box under Settings → Reading adds a noindex tag. If staging uses it, add "untick it" to your launch list now.
• Test speed before launch. Run Lighthouse in Chrome's developer tools on each main template while logged in to staging, and compare the results with the old pages. After launch, Google measures what real visitors experience against three targets. The main content should show within 2.5 seconds (LCP), the page should respond to a tap or click within 200 milliseconds (INP), and the layout shouldn't jump about (CLS of 0.1 or less). Large images, sliders and extra scripts are common reasons a new design is slower.
• Check every template on a phone. Google uses the mobile version of your site for indexing and ranking, so mobile pages need the same main text, headings, structured data, titles and descriptions as desktop. Text in tabs or accordions is fine if it's already in the page, but Google won't load content that is only fetched after a tap or swipe.

3. Launch day: switch it on safely

Launch early in the week, not on a Friday afternoon, so someone is around to fix what breaks. Then work through these in order:

1. Put the redirects live with the new site, then test them. Paste the old URLs from your map into a crawler (Screaming Frog's list mode does this). Each one should redirect once, permanently, and land on the right new page, which returns 200. Fix any that end on the home page or a 404.
2. Remove every staging block. Open yoursite.com/robots.txt and check it doesn't say "Disallow: /". View the source of a few pages and search for "noindex". On WordPress, untick "Discourage search engines". Take the password off.
3. Submit the new XML sitemap. In Search Console's Sitemaps report, add the sitemap address and click Submit. The status should say Success. List only new URLs that return 200, not old ones that redirect.
4. Inspect your key pages. Run your home page and top pages through the URL Inspection tool with Test live URL. It shows whether Google can crawl each page and whether indexing is allowed. You can request indexing for the most important ones, but there's a daily limit and no guarantee. The robots.txt report, under Settings, shows when Google last fetched your file and lets you request a recrawl after removing a block.
5. Check analytics and forms. Open the Realtime report in Google Analytics while you click around the site, and make sure your visit appears. Send a test enquiry through every form, check it arrives, and check it's counted if you track it as a key event.
6. Mark the date. Add a launch annotation in Search Console's Performance report (right-click the chart) and in Google Analytics, so anyone reading the charts later can see when the new site went live.

Changing domain as well? Once the redirects are live, use the Change of address tool in Search Console's settings. You don't need it for a new design on the same domain, or for a move from http to https. Check your property too: a URL-prefix property only covers addresses that start with that exact prefix, so add one for the new address. A Domain property covers all subdomains and both http and https.

4. After launch: watch and fix for 4–8 weeks

Google says a small to medium-sized site can take a few weeks for most pages to move, and rankings can go up and down meanwhile. Check these twice a week for the first month, then weekly until week eight.

• The Pages report (older guides call it Index Coverage). Look for new rows under Not found (404), Soft 404, Redirect error and Server error (5xx). An old URL with traffic or links that now returns a 404 needs a redirect. A 404 for a page you removed on purpose, with no replacement, isn't a problem in itself; Google suggests fixing the 404s you link to yourself or list in your sitemap.
• Crawl stats. Under Settings, Crawl stats breaks Google's requests down by response. More 301s after launch are normal, because Google is following your redirects. A growing number of 404s or server errors means something needs fixing.
• Traffic, page by page. In the Performance report, compare clicks and impressions with the weeks before launch and the same weeks last year. Check the top pages from your export one by one, because a steady total can hide an important page that lost most of its traffic.
• Fix fast when a top page drops. If a page that mattered is still well down after two or three weeks, compare it with the old version: redirect, title, headings, text and the internal links pointing to it. Put back what was lost before you try anything new.
• Keep the redirects. Google advises keeping them for at least a year, and for visitors' sake, ideally for good. Don't use the Removals tool to clear old URLs out of Google: it only hides them for a while, and the redirects are what move Google on to your new pages.
• Core Web Vitals after a month. The Core Web Vitals report uses real visitors' data over 28 days, so it takes about a month to reflect the new templates. If pages show as Poor, fix the template: one fix covers every page built on it.

If traffic is still well below your benchmark after eight weeks and these checks look clean, look wider. Google's guide to debugging search traffic drops covers other causes, such as algorithm updates and seasonal changes.

Do it yourself or get help?

If your site is small and keeps its URLs, you can work through this list yourself with free tools. Get help when many URLs change, when you're moving platform or domain, when the site sells online, or when nobody on your side can set up server redirects. Those are the redesigns where one missed step costs the most.

Whoever builds the new site, ask for the URL map in the first week, not the last. If you're rebuilding on WordPress or moving to a custom-built website, redirects and launch checks should be part of the build plan, not an extra at the end.

Talk to Devtings

Devtings builds WordPress and custom websites and does SEO for small and mid-size businesses in the US and the UK. If you're planning a redesign, we can go through your URL map, redirects and launch checks with you. See our SEO services or get in touch.