Website Redesign SEO Checklist
Planning a new website? Use this website redesign SEO checklist to review URLs, redirects, content and tracking before launch, then monitor the move.
Before launching a redesigned website, check what will happen to its existing pages, search visibility and enquiry journeys. A stronger visual design is welcome, but it does not establish that old links still work, useful content has survived or the live site can be indexed.
This website redesign SEO checklist sets out nine checks to agree with your developer before launch. Use it to record the evidence, the person responsible and any unresolved issues. It is intended for a business reviewing its own redesign, not as a promise that rankings will stay unchanged.
Can a website redesign affect SEO?
Yes. A redesign can change page addresses, content, navigation and the way a site is delivered. Google says significant changes can cause temporary ranking fluctuations while it recrawls and reindexes pages. A redesign that keeps the same URLs still needs checks, because its content and technical settings may have changed.
First establish the scope: is this a visual refresh, a new platform, a change of page structure or a domain move? The checks below help with launch planning, but a domain change or a large, complex migration needs a plan specific to that move.
1. Record what the current website contributes
Keep a dated starting record before development work replaces the old site. Note the pages that attract relevant visitors, explain important services or generate enquiries. Save the reporting period and any known tracking gaps so later comparisons have context.
- Export a list of current page addresses from the website and sitemap.
- Record important search landing pages and the enquiries or sales you can reliably connect to them.
- Keep copies of essential service information, useful downloads and approved supporting material.
- Identify pages customers or partners still reach through existing links.
Do not let a low traffic count automatically decide whether a page is removed. A specialist specification sheet or enquiry page may matter to a small number of valuable buyers. Ask the business owner to review those cases before the structure is signed off.
2. Give every old URL a recorded decision
Create a simple old-to-new URL list. For each existing address, record whether it will stay, move, merge into another page or be removed. Add the proposed destination and the person approving the decision.
Keep a useful address where there is no reason to change it. If a page is being merged, check that the destination genuinely answers the visitor's original need. For content that has been removed with no suitable replacement, agree the correct not-found response rather than sending visitors somewhere unrelated.
Include documents and other linked assets in the review, not just pages shown in the main menu. Keep this list with the project handover so another developer can understand the choices later.
3. Test redirects against the agreed destinations
For a permanent page move, Google recommends a permanent server-side redirect where possible. Common examples are HTTP 301 and 308. Ask the developer to confirm the approach used by your platform and test the actual response rather than relying on a redirect setting in an admin screen.
Check that each moved address reaches the intended live page. Prefer a direct move to the final destination rather than several intermediate redirects. Also test for loops and destinations that themselves return errors.
A hypothetical example: an old maintenance-service page should lead to its relevant replacement, not a general homepage that no longer explains maintenance. Google warns that unrelated redirects can be treated as soft 404 errors. A blanket homepage redirect is not a substitute for a reviewed mapping.
Google guidance on redirects and search
4. Review useful content before removing it
Compare important old and new pages side by side. Check that the redesigned version still explains the service, who it is suitable for, practical restrictions and the next step. A clean layout can contain substantial information; it does not require replacing specific answers with short slogans.
Ask a colleague who understands customer questions to review the copy without the designer's explanation. Can they find what the business does and what happens after an enquiry? Note missing details as content tasks, separate from visual feedback.
Retain only accurate, relevant evidence. Old testimonials, expired offers and outdated product details should not be carried across simply because they existed before. Record what needs updating and obtain approval for the replacement.
5. Check the rendered titles and descriptions
Review the title and meta description of each important page. They should describe that page's actual content, distinguish it from other pages and avoid repeated keyword lists. Include any site-name suffix in the review so the complete title remains concise.
Then inspect what the live page serves. A correctly completed field in the content management system is not proof that the template outputs it correctly. Check for an inherited homepage or About title, duplicate title elements and descriptions that belong to a different page.
Compare the page's main heading with its title and content. Google can generate search-result titles and snippets from several sources, so saving your preferred wording does not guarantee Google will display it verbatim.
6. Confirm the live site is available for indexing
Check the production site's indexing settings at launch. Development restrictions can survive a release, including noindex instructions in page metadata or HTTP headers. Review the pages intended for search separately from pages that should remain excluded.
Do not confuse robots.txt with noindex. Google needs to access a page to read its noindex instruction; blocking crawling can prevent it from seeing that instruction. Ask the developer to explain the intended behaviour of each restriction rather than removing every rule indiscriminately.
Also confirm that the production site no longer requires development access credentials. Any private preview should remain appropriately protected; the public website needs its own deliberate launch configuration.
Google guidance on noindex and crawling
7. Check canonicals point to the right live pages
A canonical identifies a preferred URL when duplicate or similar page versions exist. It is not a redirect for visitors. Check that the redesigned pages do not refer to a staging domain, an old address or an unrelated page as their preferred version.
Google recommends a self-referencing canonical on the preferred page. Keep the signals consistent: the canonical, internal links and sitemap should not nominate different addresses for the same content. Investigate unusual cases with the developer instead of applying one homepage canonical across the whole site.
Google guidance on canonical URLs
8. Update the sitemap and internal links
Check the XML sitemap after publication. It should use complete live URLs for pages you want found in search, rather than staging addresses or a stale list from the old site. Open a sample of listed URLs and confirm they lead to the expected pages.
Review navigation, links within articles, buttons and downloadable documents too. Where a destination has moved, update the link to its final address rather than making every visitor pass through the old URL's redirect.
Submit the relevant sitemap through Search Console and monitor its status. A sitemap helps communicate the URLs you want discovered; it is not a guarantee that every listed page will be indexed or rank.
Google guidance on building and submitting a sitemap
9. Test enquiries and agree who monitors the launch
Complete the real enquiry journey on a phone and a desktop. Use a clearly labelled test submission and check where it arrives. Test booking links, telephone links and any important downloads, including pages people reach directly rather than through the homepage.
Check that the intended analytics and enquiry events still record correctly. An unchanged tracking account does not establish that a redesigned form or confirmation page still triggers the same measurement. Document the test and remove or identify test records so they do not confuse reporting.
Use Search Console to review search clicks, impressions, queries and landing pages after launch. Compare like-for-like periods where practical, and note seasonality or other changes before attributing every movement to the redesign. Keep a named owner for checking errors and escalating problems.
Do not assess the launch using one average ranking alone. Review the pages and searches that matter to the business alongside actual enquiry outcomes. A broken form needs attention even if search visibility appears stable.
What should be signed off before launch?
- The old-to-new URL list and tested redirects.
- Approved service content and page-specific titles and descriptions.
- Production indexing settings, canonicals and the current sitemap.
- Working mobile and desktop enquiry journeys with a measurement check.
- A handover record naming the people responsible for post-launch checks.
Keep unresolved issues visible, with an owner and a decision about whether they block launch. This makes the handover more useful than a general assurance that the new website is SEO friendly.
Plan the redesign around your next enquiry
When comparing UK website developers, ask how they will handle these checks and what evidence you will receive. A migration checklist should be part of a practical delivery conversation, not a guarantee of a particular ranking.
The Digital Cogs offers web design and development alongside SEO and AI search services. If you are planning a redesign, tell us what needs improving and what the existing website already does well. We can discuss the website, search and enquiry requirements together.
Explore our web design and development services
Explore our SEO and AI search services
Discuss your website redesign with The Digital Cogs
Prepare for the conversation with our marketing agency brief guide
Primary guidance checked for this article
Google Search Central: planning site moves with URL changes
Google Search Central: title links