Redesign the website.
Protect what already works.

Use this working list with your designer or developer. Checkmarks stay in this page only and reset on reload. Print or save a PDF from your browser to keep a record. Checking a box records your review; it does not automatically audit the site.

Before design: record what must survive

• Write the purpose of the redesign.
  Name the audience, the visitor action and the business problem. Keep visual changes separate from changes to the offer, domain or platform.
• Save a dated baseline.
  Export available landing pages, search queries, clicks and accepted inquiries. Note seasonality and measurement gaps. Keep a dated copy of the current site.
• Inventory useful addresses.
  Combine the current sitemap, content system, analytics and linked pages. Include PDFs, images and addresses absent from the main navigation.
• Decide what happens to every important URL.
  Mark it keep, move, merge or retire. Preserve a useful existing address when it still fits. Assign one relevant destination to each moved page.
• Identify content worth keeping.
  Record what each page helps a visitor do, its important facts, images, downloads and links. Give rewriting decisions an owner.
• Plan the launch and recovery.
  Record access, DNS/hosting responsibilities, a working previous release and the conditions that would justify restoring it.

During the build: test the actual pages

• Keep previews out of search.
  Use appropriate preview access controls or noindex. Keep a launch list of restrictions that must change; never assume a preview is private because its address is unfamiliar.
• Review titles, headings and useful content.
  Check that each page explains its own topic and action. Keep important answers available in the rendered HTML and readable on a phone.
• Check canonical destinations and internal links.
  The new site should consistently reference its intended live URLs, not a preview host, old address or redirect chain.
• Test redirects individually.
  A moved page should reach its relevant replacement directly. Check that the destination works; do not send every removed page to the homepage.
• Inspect structured data and sitemap entries.
  Keep business facts aligned with visible content. Include only intended canonical, indexable pages in the launch sitemap.
• Run real visitor tasks.
  Read a service page, navigate on a phone, review an inquiry and exercise the tested submission/failure paths. Check keyboard access, zoom and loading behavior.

At launch and afterward: verify the live result

• Check the deployed site, not just the preview.
  Confirm the intended release, live host, HTTPS, important URLs and redirect targets. Inspect both status codes and the page content.
• Remove launch-only indexing restrictions.
  Inspect live HTML and headers for unintended noindex, preview canonicals or access walls. Check robots.txt separately; crawl access and indexability are different controls.
• Submit and inspect the live sitemap.
  Confirm its entries resolve as intended. Use the verified Search Console property, and check representative URLs with URL Inspection. Submission does not guarantee indexing.
• Confirm measurement and inquiry handling.
  Verify the correct site analytics and tested form behavior. Record the launch date so a tracking change is not mistaken for a traffic change.
• Monitor moved and important pages.
  Review search clicks, landing pages, errors and inquiries after launch. Investigate a broken path promptly; avoid repeated site-wide rewrites in response to one quiet day.
• Keep redirects and ownership in the handover.
  Document where redirects live, who maintains them and the accounts needed for future changes. Continue supporting useful old links.

Make the URL map explicit

These are fictional paths showing the decisions a map should record. The destination must match the old page’s purpose. A genuinely retired page with no relevant replacement can return a proper 404 or 410 instead of an unrelated redirect.

Add columns for the reason, responsible person, test date and observed result. Include valuable downloads and old campaign URLs. Test links from navigation and body copy as well as the redirect configuration.

Three mistakes that a polished preview can hide

The live page still says noindex

A preview restriction can survive launch in an HTML tag or response header. Google must be able to crawl a page to discover its noindex instruction. A robots.txt disallow is therefore not a substitute for removing a page from search. See Google’s noindex documentation.

The page works, but points search engines somewhere else

Inspect the live canonical, internal links and sitemap together. Preview domains and conflicting URL forms can persist in separate systems. See Google’s canonical guidance and sitemap guidance.

The redirect lands on the wrong answer

A successful redirect status does not prove a useful destination. Review the page the visitor reaches. Use a permanent server-side redirect for a permanent move where available, and avoid unnecessary hops. See Google’s redirect documentation.

What should happen after a redesign?

Keep a dated launch note and a short issue list. Review the most important landing pages and the inquiry path first. Compare meaningful periods with similar demand; tiny traffic samples can move sharply without a technical failure. If tracking changed, reconcile the measurement before attributing every difference to search performance.

For a domain or large URL change, use Google’s site-move guidance alongside this list. It explains preparation, mapping and monitoring. Crawling and rankings can fluctuate while the move is processed; there is no guaranteed completion date.