Website Redesign SEO Checklist: What to Preserve Before Launch

Before design: record what must survive

Before changing an existing website, identify the pages people find, the information they need, and the paths that turn a visit into an inquiry. Then decide what to keep, move, improve, or retire. A redesign SEO checklist gives the owner and provider a shared record of those decisions and a way to verify them at launch.

Careful work reduces avoidable mistakes; it does not guarantee unchanged rankings. Google explains that significant changes can cause search fluctuations while pages are recrawled and reindexed. Preserve useful value and intent, rather than every old sentence or URL.

Create one shared inventory before approving the new page structure. Give each item an owner, a decision, and a place to record the check result:

• Pages worth reviewing: current URLs, organic landing pages, pages with backlinks or referral visits, and important service or location pages. Include valuable images and downloads that may move.
• Content and search context: titles, main headings, useful answers, local details, and each page’s purpose. Save representative copies so omissions are visible later.
• Technical behavior: the current sitemap, canonical URLs, redirects, robots.txt rules, intentional noindex decisions, and structured data that is still accurate.
• Access and measurement: confirm business access to analytics and Search Console, record how ownership is verified, and save a baseline for important pages and queries.
• Customer paths: forms, booking links, integrations, destinations for inquiries, and the events used to measure successful actions.

Map every changed URL to a decision

Keep a useful URL when the page still serves the same purpose. For changes, record the final destination and expected response before development. The paths below are illustrative examples, not a client migration.

For permanent moves, Google recommends permanent server-side redirects such as 301 or 308. Send visitors directly to the closest relevant replacement. Test for loops, unnecessary chains, and destinations that themselves return an error. A homepage redirect is not a substitute for a missing service page.

Keep the redirect map after launch. For URL moves, Google recommends keeping redirects for at least a year; retain useful ones longer when old links still bring visitors. Include existing redirects in the plan so a platform switch does not silently discard them.

Preserve the answers, not the old layout

A cleaner design can accidentally remove the detail that made a page useful. Compare old and proposed pages side by side: can a reader still tell what the service covers, who it fits, where it is available, and how to take the next step?

• Keep accurate service details and genuinely useful local information.
• Retain supporting answers and FAQs that resolve real customer questions.
• Make page-specific context and descriptive headings visible in the new structure.
• Carry forward internal links that help readers reach related services or explanations.

You can rewrite, combine, or remove material when there is a reason. Record which new page answers the old page’s useful questions. That makes content review more specific than asking whether the new site “has enough SEO copy.”

Before launch: check the production setup

Ask the provider to record evidence against the agreed page list, including representative page types and important customer paths. Assign someone to resolve failures before approving launch.

• Redirects: prepare the approved map and verify it in a test environment.
• Canonicals: check that preferred page URLs use the production hostname and agree with links and sitemap entries. Avoid accidentally pointing every page at the homepage.
• Indexability: public search pages should be accessible, return successful responses, and have no unintended noindex in HTML or HTTP headers.
• robots.txt: review rules for the live hostname, including access to resources needed to render pages. Keep deliberate private-area restrictions separate from temporary staging rules.
• XML sitemap: list the intended canonical, indexable production URLs, and remove retired or redirected entries from the current sitemap. Google’s sitemap guidance explains URL selection and submission; submission does not guarantee indexing.
• Navigation and links: check menus, breadcrumbs, footer links, and contextual links against the new page map.
• Page details: review titles, descriptions, headings, and structured data. Retain markup only when it describes the current visible content accurately.
• Customer experience: review mobile rendering, readable content, keyboard access, forms, and integrations. Use the mobile diagnostic guide and speed guide for specific problems.
• Measurement: preserve analytics and Search Console access, verification methods, and agreed conversion events; check consent behavior and avoid duplicate tracking.
• Hosting behavior: verify HTTPS, the preferred hostname, and a helpful missing-page screen that returns a real 404 response.

A canonical indicates a preferred version of duplicate or similar content; it does not redirect visitors. Keep these signals consistent using Google’s canonical URL guidance. Google can select a different canonical, so check the result after launch too.

Match the checks to the type of change

• Same-domain redesign: if URLs and infrastructure stay in place, focus on content, rendering, links, settings, and customer paths. A new layout alone is not a site move.
• URL restructuring: changed paths need explicit mapping, redirects where appropriate, and updated links and sitemap entries.
• Platform or hosting migration: URLs can remain unchanged while templates, settings, certificates, forms, or redirect rules change. Verify those behaviors rather than assuming they transfer.
• Domain change: plan property verification, old-to-new domain redirects, and continued control of the old domain as a separate workstream.

For hosting changes that keep URLs, follow Google’s hosting-move guidance: test the new infrastructure before switching traffic and monitor the transition before retiring the old hosting.

For a domain move, verify ownership of both properties and complete redirects before using Search Console’s Change of Address tool when applicable. It is not for same-domain path changes, HTTPS-only moves, or switching between www and non-www. Follow the linked requirements for your specific domain and subdomain setup rather than treating it as a redesign button.

On launch day: verify the live site

Run this check against the production hostname after the release. Record the URL, observed result, person responsible, and any follow-up. Keep the previous site backup and an agreed recovery plan available.

1. Open representative old URLs, including important landing pages and older redirected paths. Confirm they remain available or reach the intended replacement without loops.
2. Inspect important new pages for useful content, successful responses, the intended canonical, and absence of accidental noindex or crawl blocks.
3. Fetch the live sitemap and verify its hostname and URLs. Check navigation and contextual links, and investigate unexpected 404s.
4. Walk the primary customer path on a phone and desktop, including menu, service page, contact options, and form validation.
5. Verify analytics loading and agreed events using controlled test/debug facilities, with the expected consent choices.
6. Record launch time and unresolved issues so later changes can be compared with what actually shipped.

Test submissions in a sandbox or approved test route where possible. Only make a controlled live lead submission if the owner can identify and remove it and any notifications are expected. Do not place real orders, generate payments, or send repeated test inquiries to prove a path works.

After launch: investigate patterns, not every wobble

Name who will review the following days and weeks, how they will report issues, and who will fix them. Launch verification and continued monitoring are different responsibilities; confirm both in the scope.

• Search Console: review Page indexing issues and submitted sitemap status. Use URL Inspection on important pages to check indexing and Google’s selected canonical.
• Site behavior: investigate unexpected 404s, server errors, redirect failures, and missing content using logs and repeat checks of the URL map. Planned removals are different from broken replacements.
• Search performance: compare organic landing pages and page/query patterns with the saved baseline. Keep date ranges, devices, countries, and filters comparable.
• Business measurement: confirm conversion events still represent completed customer actions. A tracking change can look like a business decline even when inquiries still arrive.

Google’s Search Console monitoring guide explains the indexing, sitemap, and performance reports. Fix a confirmed block or broken redirect promptly. For performance movement, consider reporting delays, seasonality, changed content, and the time needed to process new URLs before changing the site again. Daily ranking movement by itself does not identify a redesign defect.

What not to do

• Do not change every URL merely to make it shorter.
• Do not delete a strong page before checking its role and replacement.
• Do not send unrelated retired pages to the homepage.
• Do not launch with public production pages accidentally noindexed.
• Do not remove analytics or Search Console access before confirming the replacement setup.
• Do not treat a successful visual redesign as proof that launch verification is complete.

Where Veriq fits

Veriq’s website redesign work starts with the current site and the parts worth keeping. When included in the agreed scope, that work can cover useful URLs and content, redirects, technical SEO foundations, and checks of launch behavior. Confirm the page inventory, testing responsibilities, and any post-launch monitoring in the proposal. Rankings cannot be guaranteed.

Still deciding how much to change? The redesign-versus-rebuild guide addresses the scope decision. The redesign cost guide explains budgeting for that work. Use this checklist to make the preservation and launch requirements explicit once a direction is chosen.