Website redesign checklist (with redirect plan)

A website redesign checklist has three parts. Record what the current site does before you change anything. Map every old URL to a new one and redirect it permanently. Then check the live site against your records after launch.

The redirect plan is the part that protects the search traffic you already have. Google's site move documentation lists the usual mistakes: blocks on search engines left in place after launch, redirects that point to pages that do not exist, and sitemaps that still list old URLs. Each one is covered below.

Before you start: check that you need a redesign

A redesign is not always the answer. A site that looks dated may only need new content, faster hosting or better tracking. When Stryx takes over an existing site, the work starts with an audit, and a rebuild is recommended only if it is needed. See website redesign for how that decision is made.

1. Record the current site

Do this first. Once the old site is gone, the numbers are hard to recover.

• Export a list of every URL on the site. Google suggests building the list from sitemaps, traffic data, server logs, the CMS and the Links report in Search Console.
• Include images, PDFs and other downloads. They can receive search traffic and links too.
• Note the pages that bring the most visits and the most enquiries.
• Note the pages that other websites link to.
• Save the current search performance from Search Console and the current Core Web Vitals.
• Save the number of enquiries, calls, bookings or sales per month, so there is a baseline.
• Save every page title, meta description and heading.
• List every form, tracking tag, integration and third-party script, and what each one does.
• Take a full backup of files and database, and confirm that it restores.

2. Plan the new site

• Write down what the redesign must achieve: more enquiries, a clearer offer, a new service, a faster site.
• Decide for each existing page whether to keep it, improve it, merge it or remove it.
• Keep URLs the same wherever you can. A URL that does not change needs no redirect.
• Give each page one topic, so that pages do not compete with each other.
• Change one thing at a time where possible. Google's advice is, for example, to finish a domain move before redesigning the layout or switching CMS.
• Agree who writes and approves the content, and by when.

3. The redirect plan

A redirect plan is a list with one row per old URL: the old URL, the new URL, and a note on what happened to the page.

1. List every old URL from the export in step 1.
2. Map each one to its closest new equivalent. A service page goes to the new page for that service, not to a general page.
3. Handle merged pages. Several old pages can redirect to one consolidated page that covers the same content.
4. Handle removed pages. If a page has no replacement, let it return a 404 or 410. Google warns against sending many old pages to one unrelated URL such as the home page, which it may treat as a soft 404.
5. Use server-side permanent redirects, such as 301 or 308. Google describes client-side redirects as a last resort.
6. Redirect straight to the final URL. Avoid chains where one redirect leads to another.
7. Update everything that points to old URLs: internal links, canonical tags, hreflang tags on multi-language sites, and the XML sitemap.
8. Test every row before launch on the staging site and again after launch.
9. Keep the redirects. Google recommends at least one year, and suggests keeping them indefinitely for the sake of visitors.

When the domain name itself is changing, the work is larger. See website migration.

4. Build and check on staging

The new site should be built on a staging site, away from the live one.

• Keep staging blocked from search engines, and keep a list of every block so it can be removed at launch.
• Carry over or improve page titles, meta descriptions, headings and structured data.
• Check every page at phone, tablet and desktop widths.
• Test every form and confirm where each submission goes.
• Set up tracking for enquiries, calls and bookings.
• Check page speed and accessibility basics such as contrast, keyboard use and image descriptions.
• Proofread, and have the client approve the content page by page.

5. Launch day

• Pick a quiet period. Google suggests timing a move for when traffic is lower.
• Remove the search engine blocks used on staging: noindex tags and robots.txt rules.
• Switch on the redirects and test a sample from the plan.
• Confirm that the site is verified in Search Console, then submit the new sitemap.
• Use the Change of Address tool only if the domain or subdomain has changed. Google says it is not for changes within the same domain.
• Submit a test enquiry through every form and confirm that tracking records it.
• Update the website link on Google Business Profile, social profiles and ad campaigns.

6. After launch

• Watch the indexing and not-found reports in Search Console and fix broken URLs as they appear.
• Expect some movement. Google says rankings can fluctuate while it recrawls a site, and that a medium-sized site can take a few weeks or more.
• Compare enquiries, traffic and Core Web Vitals with the baseline from step 1.
• Ask the owners of important external links to update them to the new URLs.
• Keep the old site's backup until the new site has settled.

A wider list of checks is in the technical SEO audit checklist.

Getting help

Stryx builds new sites on a staging server, redirects old URLs when a site is replaced and sets up tracking at launch. To talk through a redesign, get in touch.