Website Redesign SEO Checklist: Protect What Already Works

A website redesign can improve how your business explains its services while accidentally removing the pages, information and paths people already use. The risk is not limited to changing the domain. Rewriting a service page, replacing navigation, moving a useful document or launching a template with the wrong indexing settings can also change how the site is discovered.

The practical response is to record what exists before deciding what the new site should replace. A website redesign SEO checklist should connect each important old URL to a deliberate content decision, an implementation owner and a verified result. It should also make uncertainty visible when historical search or traffic information is missing.

The workflow below focuses on preserving an existing site's useful search foundations. It cannot guarantee unchanged rankings, but it gives your team evidence to prevent and investigate avoidable migration faults.

Record the current site before approving content changes

Create a baseline while the existing website is still available. Keep a dated copy of its page inventory, important content, metadata, internal links, redirects, images and downloadable files. Save the underlying exports as well as a summary so another person can check how a decision was reached.

Do not rely on the navigation menu as the complete inventory. A useful landing page may receive visitors from search, an old campaign or an external link without appearing in the main menu. Combine the CMS inventory with a crawl, available sitemaps and authorized measurement sources. Record where each URL was found.

Separate measured value from assumptions

For important pages, note the available evidence: relevant search queries, visits, enquiries, external links or known operational use. Include the reporting period and the source. A single recent week can miss seasonal or infrequent demand.

If Search Console, analytics or logs are unavailable, mark the value as unknown. Do not translate missing access into zero traffic or zero search value. You can still record the page's purpose, useful material and current links while requesting the missing evidence from the account owner.

Assign business and content reviewers as well as technical owners. The developer may know whether a URL works, while the service lead knows whether the replacement explanation is accurate. Both reviews matter when an established page is being shortened, combined or repositioned.

Decide what stays, changes or retires

Give every existing page a proposed treatment before implementation. Retaining a URL is usually the simplest starting point when its purpose remains valid. A shorter or more fashionable slug alone is not a strong reason to add migration work.

Where a change is justified, map the old URL to the closest useful replacement. Judge the destination by what the visitor expected to find, not just by whether it belongs to the same broad service category. A detailed integration guide and a general development page are not automatically equivalent.

Use a decision register, not a redirect list alone

This example uses fictional paths to show the information a team should record. It is not a recommendation to remove or redirect any particular live page.

Existing path	Proposed treatment	Reason to review	Required acceptance evidence
/services/customer-portals/	Retain URL and revise content	The service still exists, but the explanation needs improvement	Same intent retained, approved copy present, page returns successfully
/guides/portal-access/	Move to an equivalent guide	The content structure is changing	Direct permanent redirect to the corresponding guide; links updated
/downloads/portal-brief.pdf	Retain or replace the document deliberately	Sales still distributes the link	File opens, content is current and any replacement is accessible
/events/old-workshop/	Investigate before retirement	Historical use is not yet known	Business owner reviews value and approves the final response

Add the current title, intended primary topic, replacement owner and approval date to your working register. Keep implementation status separate from approval. A proposed destination is not a verified redirect, and a configured redirect is not proof that the destination contains the right information.

Review images and documents in the same way as pages. A page migration can appear complete while its supporting diagram or useful PDF disappears. Include changes to media locations in the scope and identify material that must remain downloadable.

For implementation choices, Google's redirect guidance distinguishes permanent moves from temporary routing. Use a permanent redirect for a genuinely permanent replacement. Test the actual server response and final destination rather than assuming that a redirect entry in the CMS is being applied by the public frontend.

Verify the staged replacement against the baseline

Review the staged site in two ways: as a visitor completing a task and as a technical response containing content and metadata. A polished screenshot cannot establish whether the page serves the intended title, canonical, response status or index controls.

Compare the important pages with the approved register. Check that their useful explanations, evidence and conversion paths survived the redesign. If content changed substantially, ask the responsible reviewer to confirm that the new page still answers the same core question or that a deliberate intent change has been approved.

Check canonical and internal-link consistency

A canonical identifies the preferred URL for duplicate or closely similar content. Inspect the rendered value on representative pages and test across every page family. Look particularly for staging domains, old domains, template-wide homepage canonicals and different pages pointing to one another unintentionally.

Keep internal links, sitemap entries and canonical preferences consistent. Google's canonicalization documentation explains that these signals have different strengths and that Google ultimately chooses the canonical. A tag is not a guarantee that the requested URL will be selected.

Links in the new site should lead directly to the intended current destination. A working redirect is useful for an old external link, but there is little reason to make your own updated navigation take that extra step. Check contextual links, breadcrumbs, footers and links inside older editorial content, not just the main menu.

Test rendering and staging protection separately

If the rebuild changes how pages are rendered, inspect what the server returns and what appears after scripts run. Important headings, explanations and links should not depend on a visitor clicking an interface control merely to make them available. Google's JavaScript SEO guidance describes the processing involved and the importance of crawlable links and accessible content.

Keep staging protected, then prepare an explicit release checklist for the production settings. A crawl block and a noindex directive are not interchangeable. Google must be able to retrieve a page to see its noindex instruction, as explained in its index-blocking documentation. Neither mechanism is an access-control system for confidential information.

Coordinate the launch checks and responsibilities

Treat launch as an operational change with named owners. Identify who deploys the frontend, who manages domains and hosting, who verifies forms and integrations, who checks search settings, and who can authorize a rollback. Agree how issues will be reported while the change is happening.

Create a recoverable backup and verify the recovery method before it is needed. Keep the approved release files and settings identifiable. A rollback decision is difficult when nobody knows which application version, database state and media set belong together.

Define stop conditions before the release

For a fictional service website, the team might agree not to proceed if the main enquiry journey fails, required content is missing, sensitive information is exposed, or a shared template sends the wrong indexing instruction. These are examples of operational gates, not universal thresholds. Define the actual gates around your site's business risk.

After deployment, repeat the important checks on the real public host. Verify the final HTTPS URLs, representative page families, redirects, internal destinations, images and downloads. Review raw responses as well as browser behavior. Environment variables and hosting rules can make the deployed result differ from the staged build.

Confirm that the sitemap contains intended canonical, indexable pages. A sitemap helps discovery; it does not prove that each listed page is useful or will be indexed. Google's sitemap overview explains that a sitemap supplements the links and information search engines use to discover a site.

Record actual results. “Migration checked” is less useful than a dated list of tested URLs, expected responses, failures and retests. Retain that evidence beside the approved mapping so later investigations do not depend on someone's memory.

Monitor after launch without blaming every change on the redesign

Set a review schedule before the launch team disperses. Compare equivalent periods where possible and account for campaign changes, seasonality, demand and measurement changes. A drop in a reporting dashboard may need investigation, but it does not identify the cause by itself.

When an important page changes unexpectedly, start with its response and content. Does the old link reach the intended destination? Is the replacement indexable? Is its main explanation present? Has the canonical changed? Are relevant internal links still available? Then compare authorized search, traffic and conversion evidence for that page.

Keep an incident record with the affected URL, first observation, evidence, proposed cause, action and retest. Separate confirmed implementation faults from hypotheses. For example, a missing redirect can be reproduced directly; the reason for a ranking movement may remain uncertain even after technical checks pass.

Google's site-move guidance warns that rankings can fluctuate while changed URLs are processed. It also recommends keeping redirects for as long as possible, generally at least a year. Continue to review their use and relevance rather than removing them automatically when an internal project closes.

Make preservation part of the redesign scope

Before changing an established website, agree what must be preserved, what can improve and how each decision will be verified. The URL register, acceptance evidence and post-launch responsibilities should be part of the delivery scope. If you need help planning a controlled website migration, begin with the existing site and its known risks rather than a list of new templates alone.