Website redesign SEO checklist: 10 checks before launch

Start by recording the pages that already bring relevant visits or enquiries. In Search Console, record the pages and queries that bring relevant impressions and clicks. In analytics, record the landing pages and enquiries the business can reliably attribute. Use complete date ranges, keep filters consistent and write down the date of each export.

For each useful page, note its current URL, title, main heading, canonical address, key internal links, conversion route and any known external links. Keep the source data in the business's own controlled account. If the data is unavailable, record that as an open question instead of inventing a baseline.

A small set of pages may deserve more careful review than the rest. A page with qualified enquiries or useful external references can matter even when its search volume is modest.

A redesign does not require every address to change. If an existing URL is understandable, accurate and still fits the page, keeping it avoids creating extra migration work. A new visual design can use the same address.

Decide whether to keep each page, move it, combine it with a genuinely related page, or retire it. Record the decision and its reason. Do not delete a useful page just because its old template is being replaced.

When two pages cover overlapping topics, decide which one should answer the visitor's question and what distinct information the other contributes. Combine pages when the destination still answers the questions visitors brought to each original page.

Record a destination for every old address that moves. The new destination should preserve the old page's useful purpose or provide its closest appropriate replacement. Keep the map in a shared project record so the developer, content owner and approver work from the same list.

Use a permanent server-side redirect when a page has permanently moved. Point the old address directly to its final destination, rather than sending it through several temporary addresses. Test both the response and the destination content. Update internal navigation and page links to use the final address so visitors do not take an unnecessary detour.

Google's site-move guidance says to keep redirects for as long as possible, generally at least one year. If an old address still receives useful visits or has links from other sites, consider keeping its redirect longer. The redirect does not guarantee that search rankings or traffic will stay unchanged.

A page is more than its URL. Review the content that explains the offer, the title and main heading, its internal links, images, structured data and canonical address. Keep facts and claims accurate. If the page's purpose changes, revise its text so the new page answers the question its title promises to answer.

Structured data should describe information visitors can see on the page. After a template change, make sure its names, dates, authors, offers and other fields still match the visible copy. Do not add markup simply to suggest a rich result that the page does not qualify to show.

When content is deliberately moved or consolidated, make the surviving page complete and helpful for the person who lands there. A redirect is not a replacement for the information the visitor expected to find.

A staging site may need authentication or a temporary noindex directive. Before public launch, confirm that the intended live pages are accessible to search crawlers and are not blocked by a robots rule, an unintended noindex directive or a canonical that points elsewhere.

Check the final rendered page as well as the source. Important text and links should be available in a form that people and search systems can read. Test a sample of high-priority URLs, every mapped redirect and pages with changed templates.

The sitemap should list the final canonical URLs that the site intends to expose. Check that each listed destination returns the expected page instead of a redirect, error, staging address or duplicate version. Google treats a submitted sitemap as a hint for discovering URLs. Crawling and indexing decisions can follow separately.

Before release, test the pages and actions the project promised: important service pages, redirects, contact routes, booking or payment journeys, mobile layouts and the agreed editing tasks. Confirm that enquiry delivery reaches the intended inbox or system using an explicitly labelled test and a named reviewer.

After launch, check a sample of priority URLs in Search Console and compare the same page groups, country filters and date windows used for the baseline. Review crawl and indexing reports, sitemap processing, broken links, server responses and enquiry records. Investigate specific lost pages or queries before changing large groups of titles or content.

Search visibility can fluctuate while engines recrawl and process the changed pages. A careful checklist can prevent avoidable mistakes, but no developer or consultant can promise unchanged rankings, a specific number of clicks or first-page positions.

Agree who can approve release and which failures will delay it before testing begins. Give that person a record with the expected result, the evidence and the person responsible for any fix.

For answer engines, start with the same useful page: make the core explanation visible, answer the buyer's question plainly, show who is responsible for the information and link to the evidence behind important claims. Keep structured data consistent with what visitors can read.

Google's current guidance says its AI Search features use the same SEO fundamentals and have no separate technical requirements. It does not require a special AI file or special schema to appear in those features. Prioritise clear, original content and reliable crawl access.