Website Redesign SEO Checklist: Plan URLs, Redirects and Launch Checks

A redesign changes pages that customers may already have bookmarked, linked to or found through Google. Renaming a service page without planning its replacement can leave an old search result pointing to an error page, even when the new website looks finished.

I would include the checks below in the scope of a website redesign, with a named person responsible for each decision. They are especially useful when changing a content management system, reorganising services or moving to a different domain.

Record which pages attract relevant visitors and which support the customer journey. A low-traffic contact page or specialist service page can still be worth preserving. Save a copy of page titles, headings and useful content before the design team starts replacing templates.

Keep a dated record of enquiries and organic-search performance. That gives you a baseline for investigating a change after launch, rather than relying on a general impression that traffic looks different.

• Keep the existing address when the page still serves the same purpose and there is no useful reason to change it.
• Map a moved page to its direct replacement.
• Map consolidated pages to a new page that genuinely covers their subject.
• For removed content with no relevant replacement, return an appropriate 404 or 410 response.

For example, if a business moves its boiler-servicing page from one address to another, the old address should lead to the new boiler-servicing page. Sending it to a general homepage makes the visitor search again. Google's site-move guidance warns that irrelevant redirects can confuse users and may be treated as soft 404 errors.

A domain move, platform change and major content rewrite together also make diagnosis harder. Google recommends changing one thing at a time where possible. If your project combines them, separate the checks and record what changed.

Test the old addresses, not just the new menu links. Each moved URL should reach its relevant final destination directly, without a loop or an unnecessary chain of intermediate pages. The destination should load successfully and show the expected content.

Include valuable PDFs and other linked resources in the plan. For a domain move, check the old domain's relevant variants too. Keep ownership and hosting arrangements in place so the redirects can continue working. Google recommends keeping redirects for as long as possible, generally at least one year; useful old links can justify keeping them longer.

Before the public launch, check for development settings that should not carry over: unwanted noindex tags or headers, crawl restrictions, staging-domain references and password protection on public pages. Google's noindex guidance also explains that a crawler must be able to access a page to see its noindex instruction. Blocking crawling and preventing indexing are different controls.

Review the live configuration after deployment as well as the preview. A setting that is correct on the test server can still be wrong on the public site.

Check that canonical tags point to the intended public addresses, including the correct domain and HTTPS version. In an ordinary migration, each new page should identify its own intended canonical URL. Keep any deliberate consolidation decisions consistent with your URL map.

Update the XML sitemap with the canonical URLs you want indexed and check it for old addresses or staging links. Google's sitemap guidance describes the supported formats and submission options. A submitted sitemap helps discovery; it does not guarantee indexing.

• A recent backup exists and someone knows how to restore it.
• Important old URLs and their redirects have been tested.
• Public service pages load, show the right content and permit the intended crawling and indexing.
• Navigation, contact links, forms and confirmation messages work on mobile as well as desktop.
• Analytics and enquiry measurement still work with the site's consent settings.
• Someone is available to investigate faults after launch.

Record problems against an owner and a next action. A broken enquiry form or an accidental noindex rule on a main service page deserves attention before launch. Minor visual refinements can have their own agreed follow-up list.

Compare equivalent periods and look at page groups as well as site totals. A traffic difference could involve tracking, demand, changed content or a technical fault. Google notes that rankings may fluctuate while it recrawls and processes a site move, so there is no fixed recovery date to promise.

Keep the URL map and launch notes. They make it easier to trace a missing enquiry route or an old link several weeks later.

Tell me about your website project→, email info@phil-carr.co.uk or call 01226 697 325. Include your current website address, what is changing and your intended launch date.