A Better Website Should Keep the Search Traffic You Already Earned

“The new site looks better. Why would Google care?” Because the new site may also have different URLs, less service detail, fewer internal links and a template that accidentally tells search engines not to index it.

The design can be better while the underlying search and customer paths become worse. That is why I would ask for the migration plan before approving the launch date. A homepage screenshot cannot show whether an old article redirects correctly or a quote form reaches the sales team.

This checklist is for the company commissioning the work and the people implementing it. It covers a visual redesign, CMS migration, major rebuild and URL or domain change. Use the checks that match the project. Record “not applicable” with a reason rather than silently skipping them.

Decide what is actually changing

A new color system on existing pages is a different project from replacing the CMS, rewriting content, changing the domain and reorganizing every URL. List the changes explicitly: design, templates, content, navigation, rendering, hosting, tracking and addresses.

Preserve working URLs when there is no real reason to move them. A cleaner-looking folder structure is not automatically worth a migration. Where possible, separate major changes into controlled releases. If business constraints require one large release, make the comparison and rollback plan more detailed.

For hosting changes with unchanged URLs, use Google's hosting-move guidance. For changed addresses, use its site-move guidance. A design refresh does not need a domain-move process just because the website looks new.

Discuss technical scope early. Our full-stack development approach is relevant when templates, integrations and custom systems change together. The SEO work should be part of that build, with acceptance criteria that developers can actually test.

Before design: preserve the evidence and the useful pages

Create an inventory that survives the old site

Crawl the current site and save the export outside the environment being replaced. Add URLs from sitemaps, Search Console, analytics, the CMS and useful backlink records. A crawl alone can miss orphaned pages that still get visits.

For each important URL, record status, title, H1, meta description, canonical, indexing rules, main content, internal links and relevant structured data. Include PDFs, images and other assets that attract visitors or support customer tasks. Save representative screenshots too, but do not use screenshots as the only content backup.

Identify pages that earn qualified leads, non-brand search clicks, useful backlinks, seasonal demand or essential support visits. Low recent traffic is not sufficient reason to delete a page used during another season.

Save a baseline you can compare later

Export search performance by page and query group, with country, device and date range noted. Save organic landing-page outcomes and actual enquiry counts. Record tracking definitions, the account time zone and known measurement gaps.

Choose comparable full periods and keep longer seasonal context where available. For a US company, distinguish US performance from worldwide totals. A shift in geographic mix can make a total look fine while the market you serve loses visibility.

Build a watch list of important pages and representative templates. Include a service page, location page, article, category, product, filtered route and any booking flow that applies. You need both commercially important URLs and samples that reveal shared template failures.

Give every page a deliberate outcome

• Keep: the address and useful purpose remain.
• Improve: the page stays, with an agreed content change.
• Move: a relevant new address replaces it.
• Merge: useful content moves into a genuinely equivalent destination.
• Retire: the content no longer belongs, with a documented reason and response plan.

Do not let a designer's page list become an accidental deletion list. A service page shortened to a slogan may lose the detail that helps people choose you. Preserve the answer, evidence and useful next step, even if the layout changes.

For stores, category hierarchy, filters, product variants and stock states deserve their own review. The migration checklist must protect catalog pathways as well as the homepage.

Before launch: map addresses and test the new site

Create a mapping with old URL, intended destination, action, owner and test result. Add an explanation for merges and removals. The destination should preserve the relevant task, not merely exist.

A hypothetical old boiler-repair page should land on the corresponding repair page, not a generic “all services” screen. An irrelevant homepage redirect is not a useful substitute for a missing answer. When content is genuinely gone and no suitable replacement exists, a proper removal response may be appropriate.

Test the redirect map as a list

Use permanent server-side redirects, normally 301 or 308, for permanent moves where supported. Google's redirect documentation explains the distinction from temporary redirects.

• Run the mapped old URLs through the proposed rules and record the actual destination.
• Check that the final page works, is relevant and has the intended indexing signals.
• Look for loops, accidental chains and destinations on staging.
• Test important URL variants and query strings that existing customers or campaigns use.
• Check the interaction between CMS redirects, server rules and CDN rules.

A redirect map marked “done” because somebody imported it is not a tested map. Rule order can turn a specific redirect into a generic one. Test the full list when practical and manually inspect the critical destinations.

A reproducible redirect test in Screaming Frog

These interface labels were checked against the official documentation on October 8, 2026; labels can differ by version or language. Save the expected destination before running the test, so an actual destination cannot accidentally become your definition of success.

1. Switch to Mode > List. In the spider's advanced configuration, enable Always Follow Redirects to inspect the destination beyond the uploaded list.
2. Use Upload to paste your old URLs or load the saved list. Start with critical customer routes, then cover the migration inventory. Public staging restrictions may require an authorized test environment; never remove production protections just to complete a crawl.
3. Export Reports > Redirects > All Redirects. Compare each final address and response with the planned mapping. Review chains and loops separately; a successful final 200 does not make a wrong destination correct.
4. Open critical final pages and confirm the intended content, canonical, robots meta tag and HTTP indexing headers. Repeat the list test on production after deployment and save a timestamped export.

See Screaming Frog's migration workflow and list-mode documentation. Crawl access and rendering configuration affect coverage; record them with the export.

These are illustrative routes, not W-MAX client results. Record old URL, expected destination, actual destination, redirect hops, final HTTP status, canonical, indexing instructions, content check, owner, timestamp and evidence location. Keep each failure open until a fresh test verifies the correction.

Compare content and metadata by template

Titles and H1s should describe the actual page. Meta descriptions should remain useful rather than becoming the same CMS default everywhere. Metadata is not the whole SEO strategy, but a broken import often signals other missing fields.

Compare page purpose and supporting detail, not just word counts. Check service scope, location information, product specifications, supporting FAQs and evidence. A larger word count can still hide the loss of the one answer customers needed.

Review structured data against visible content and validate applicable types. A template rebuild can drop product, organization or breadcrumb markup. Valid markup is not a guarantee of a rich result; see Google's structured-data explanation. Preserve appropriate markup without adding types that do not fit.

Protect staging and prevent staging rules from reaching production

Use authentication or restricted access for private staging. If a public test page relies on noindex, remember that Google must be able to crawl it to see that instruction. A robots.txt block alone is not a dependable way to keep a URL out of search. Google explains this noindex requirement.

Keep a separate list of production pages that should be indexable. Inspect both HTML robots tags and response headers. An X-Robots-Tag added at the server or CDN can affect pages even when the CMS checkbox looks correct.

Check robots.txt by host. Review canonicals, language annotations where used, asset URLs and sitemap addresses for staging references. The new site should not call the test host its preferred location. Authentication stays on staging; live public pages get their intended access and indexing rules.

Check navigation and rendered content

A redesign that removes category links can make important pages harder to discover. A flatter structure is not always better if it creates one overwhelming list. A deeper structure is not always worse if useful hubs and contextual routes remain. Compare important pages' incoming links and their accessibility from relevant sections.

Use crawlable links with real destinations. Google describes its requirements in link best practices. Navigation that only works after a custom click event deserves testing.

If the rebuild changes JavaScript rendering, compare the initial HTML and rendered output. Check the actual text, links, canonical and error handling. Test representative pages with URL Inspection when available, not only by disabling JavaScript in your own browser. Google's JavaScript SEO guidance covers crawling and rendering considerations.

Do not use “Google can render JavaScript” as a reason to skip verification. A working browser page and a reliably discoverable, correctly rendered search page are different acceptance checks.

Retest performance and customer actions with real content

Measure representative pages with production images, fonts, widgets and tags. Compare lab tests under consistent conditions and retain field data as context. Field metrics take time to reflect a new release; launch-day laboratory results are not a fresh real-user baseline.

Check usability as well as speed: keyboard navigation, mobile menus, layout shifts, readable text and visible contact controls. W-MAX's page experience article gives related background. Google's current guidance is clear that good experience alone does not guarantee high rankings.

Complete forms, calls, booking and checkout where relevant. Confirm server acceptance, email or CRM delivery and success events. Preserve useful attribution parameters through redirects and test external booking domains. Document the expected analytics events before comparing the new dashboard.

Search Console: inspect the indexed record, then test the live page

1. Select the correct property and enter the exact production URL in the inspection bar. Read the indexed report first: it describes Google's stored information, including the last crawl and canonical selection where available.
2. Choose Test live URL. Review current crawl access and indexing eligibility. In the tested-page details, inspect fetched HTML and rendered output where available; check that the service answer and important links survived.
3. If the live result differs from the indexed report, record both and their timestamps. A successful live test does not mean the page is already indexed, that Google will choose your canonical, or that rankings are protected.
4. After fixing a problem, rerun the live test. Request indexing where appropriate and available, then monitor the indexed record later. A request is not a deadline or a guarantee.

These steps follow Google's URL Inspection troubleshooting guidance. Use a representative set from each changed template; one passing homepage cannot approve the whole site. Authentication on staging prevents a normal public live test, so complete this check on production when accessible.

Use a launch gate with evidence, not a verbal “looks good”

The following priorities are an operating recommendation, not an official Google severity scale. Agree them with the team before launch. That prevents a missing decorative element from getting the same urgency as a sitewide indexing block.

For every important check, store the old URL, expected production URL and response, intended canonical and indexing rule, actual result, tester and timestamp. Attach the relevant crawl row or test evidence, and record any approved content difference. This makes sign-off reproducible instead of relying on “the developer checked SEO.”

Agree who can authorize launch, who can deploy a fix and who can roll back. Preserve the previous deployment and a tested backup. If the site takes orders or enquiries, a rollback must also protect records created after launch. Restoring yesterday's database blindly can erase today's customers.

Choose a lower-traffic window when practical, with the people who can fix problems available. A Friday-evening launch with everyone offline turns a small failure into a long outage.

Launch day: check the public environment again

Staging approval does not prove that production works. Host settings, caching, redirects and environment variables can change the result. Run a short public-environment check immediately after release.

1. Access: verify important pages, certificates and expected HTTP responses.
2. Indexing: inspect live robots.txt, robots tags and headers on each major template.
3. Destinations: run the old URL list again and confirm the critical final pages.
4. Content: compare the watch list with the approved version, including mobile and rendered output.
5. Discovery: check important internal links, canonicals, language routes and sitemap URLs.
6. Business: complete test enquiries, calls and orders where relevant, and verify delivery and tracking.
7. Monitoring: confirm access to Search Console, analytics, CRM and operational logs.

Use accurate current preferred URLs in the new sitemap and submit it through Search Console. Sitemap submission helps discovery; it does not force indexing or replace navigation and redirects.

For an eligible domain move, verify the properties and follow the Change of Address instructions. Do not use that tool for an ordinary layout change or a path-only reorganization.

Update ad destinations, important profile links and owned integrations that still point to changed addresses. A working redirect is useful, but avoid making every future customer travel through it unnecessarily.

First 24 to 72 hours: separate urgent failures from incomplete data

These are suggested monitoring windows, not a promise that search reports or rankings will settle within three days. Watch accessibility, enquiry delivery and server errors immediately. Search data has its own processing and crawling timeline.

Compare the public crawl with the inventory. Look for unexpected missing pages, new redirect chains, staging canonicals, sudden template-wide noindex and broken assets. Use operational logs to investigate failures and bot access where available.

A sitewide traffic drop right after launch needs a measurement check as well as an SEO check. If the Analytics tag disappeared, fewer recorded sessions do not prove fewer visitors. Compare Search Console, server requests and actual enquiries. If forms stopped delivering, restore the customer path even while the search investigation continues.

Keep a change log after launch. Record the URL or template, symptom, evidence, fix and verification. Stop adding unrelated improvements while investigating a significant failure. Otherwise the baseline keeps moving.

Escalate widespread access failures or indexing instructions immediately. For minor isolated issues, a focused patch may be safer than reversing the entire deployment. Roll back when the agreed failure conditions are met and the tested recovery protects current business data.

First 2 to 4 weeks: watch groups, not just the homepage

Monitor the watch list and page groups by template, query family, country and device. For changed URLs, follow old and new destinations together. A decline on old URLs can be expected during a move; it becomes a concern when the relevant new pages are not replacing the lost useful visibility.

Inspect pages with unexpected indexing states and compare them with unaffected examples. A common problem on every service template suggests a shared rule or rendering issue. One product category losing demand may require a different explanation.

Review clicks, impressions, qualified enquiries and outcomes against comparable periods. Do not compare an incomplete week with a full week or assume every movement came from the redesign. Consider seasonality, search demand, unrelated site changes and broader ranking changes.

Keep redirects operating. For URL moves, Google recommends retaining them for at least a year, and keeping useful customer routes longer can make sense. Ranking fluctuations can happen while changes are processed. There is no honest guarantee that a migration produces zero movement.

If relevant visibility remains weak, return to the evidence: deleted answers, changed intent, missing internal links, accessibility, redirects and rendered content. Check those before commissioning a new backlink campaign to compensate for a technical mistake.

Close the migration when the evidence supports it

A launch is an event. A migration is a process. Close it when the important destinations work, useful content is present, indexing signals are intentional, customer actions are delivered and measured, and remaining search changes have been reviewed.

Hand over the final URL map, content decisions, test records, monitoring notes, redirect ownership and unresolved issues. Keep the baseline and backup available. Make ongoing monitoring someone’s responsibility rather than assuming the project manager still watches it.

Frequently asked questions

If your company is planning a rebuild, web development and SEO review should share that acceptance checklist. Ask for evidence that the new website preserves the useful paths you already earned. Then judge the redesign by what customers can do and what the search data shows, alongside how it looks.