Website redesign SEO checklist: URLs, redirects and launch checks

Preserve the customer’s route through the redesign

The release is not complete because the new home page looks right. Someone may arrive through an old service link, a saved product page or a PDF cited in an email. Your migration plan needs a decision for those routes as well as the new navigation.

Google’s site-move guidance describes preparing a URL mapping and monitoring the old and new addresses. It also warns that visibility can fluctuate while changes are processed. A checked migration reduces avoidable mistakes; it cannot promise unchanged rankings.

The checklist here is a practical release plan for a business website. It is not a complete specification for every platform. A large catalogue, a changed domain or a complex application may need a more detailed migration design.

Make one inventory before making design decisions

Collect the addresses that matter to the first release and the people responsible for them. Include service pages, product records, useful articles, downloads and any landing pages linked from campaigns. Bring together the available CMS export, sitemap, analytics and link information rather than assuming one list is complete.

For each resource, record its purpose and what should happen after launch. A spreadsheet can be sufficient for a small site if it has an owner and is kept in step with the implementation. An old address needs a decision, not just a row marked “SEO”.

These addresses are invented examples. The right destination depends on the actual information a visitor expected to find. Do not use the table as a production redirect configuration.

Decide what genuinely needs a new URL

A redesign does not require every address to change. Retain useful paths unless there is a clear reason to move them. If the business combines two overlapping pages, explain which information survives and how the combined page serves both groups of visitors.

For permanent moves, Google’s redirect documentation identifies server-side 301 and 308 responses as permanent redirects. The status and destination should match the actual decision. A temporary interruption is not the same decision as retiring an address.

Ask the developer for a testable mapping, not a rule that silently sends every unknown address to the home page. Where the destination is still undecided, keep that item visible as unresolved instead of approving it as migrated.

Check the destination, not only the first response

For each mapped move, inspect the old address, the destination it returns and the final page. The destination should load the intended content. A redirect that ends at another redirect, a missing page or the wrong language is not a successful customer journey just because the first status looks correct.

Use a small review record with columns for the old URL, expected destination, observed destination, final status, content match and reviewer. Test a representative range before launch, then validate the complete agreed mapping with a suitable crawler or script. Keep manual checks for meaning: a status code cannot decide whether the replacement answers the original question.

Align internal links and canonical signals

Google describes redirects and canonical annotations as strong canonicalization signals, with sitemap inclusion a weaker signal. Its canonical documentation also recommends consistent internal links and compatible signals. These are signals to Google, not commands that guarantee a particular search result.

For the release review, pick one final address for each intended public page. Check that menus, relevant content links, canonical annotations and the sitemap agree with that decision. For language versions, confirm that equivalent links point to actual pages and have not been copied from a different region.

Put this check in the migration record so a content editor can repeat it later. A technically correct launch can be undermined if a subsequent edit restores links to an obsolete address.

Separate staging restrictions from launch settings

A test copy needs its own access plan. Google’s robots.txt introduction explains the role of crawl rules and their limitations. A robots.txt rule is not a password or a general confidentiality control.

Before publication, list the restrictions that belong only to the test environment. Verify the intended live response, metadata and access from a signed-out browser. Conversely, keep genuinely private areas protected after launch. Treat public indexing decisions and access control as separate checks.

Rehearse the launch and its recovery path

• Identify who can deploy, change redirects and restore the previous version.
• Confirm what is backed up and how newly received enquiries or orders are protected during recovery.
• Set a point after which live content changes need to be included in the migration.
• Test the primary enquiry or purchase journey on the published site.
• Record the launch version, known issues and the owner of each follow-up check.

A rollback needs a data decision, not just a copy of the old files. For example, restoring an earlier database without handling new orders can create a business problem even when the old design returns correctly. Agree the recovery process for the systems involved rather than improvising it during an outage.

Monitor evidence after publication

Compare like periods and page groups, with notes for the launch and any other changes. Separate a delivery failure, a reporting change and a change in search visibility. One daily total cannot tell you which of those occurred.

Google advises retaining migration redirects for as long as possible, generally at least a year. Record that requirement with the person who maintains the site. If you later propose removing a redirect, review its purpose and continued use rather than deleting it because the redesign project has closed.

Use the redesign brief to share the existing site and the important journeys. If the URLs are already broken, begin with the SEO brief and an inventory of the affected addresses before commissioning another visual change.

Evidence and sources

Sources checked on 15 October 2026. The URL examples and release-record format are illustrative editorial tools. They do not represent a measured client migration.

• Google Search Central: site moves with URL changes. Mapping, monitoring, uncertainty and redirect retention.
• Google Search Central: redirects. Permanent and temporary redirect behaviour.
• Google Search Central: canonicalization. Consistent canonical signals and internal links.
• Google Search Central: robots.txt introduction. Crawl-control scope and limitations.