Website Redesign SEO: What to Check Before Launch

A beautiful website preview answers an important question: do we like the new website?

It leaves several others open. Can someone still reach a service page from an old link? Will an inquiry arrive in the right inbox? Did a setting used to hide the preview follow it into production? Does the team know what it will check the morning after launch?

A website redesign SEO checklist should turn those questions into assigned work and visible evidence. Nobody can promise a redesign will have zero ranking movement. You can, however, avoid treating the transfer of an existing business asset as an aesthetic formality.

The useful deliverable is a handoff record. It should explain what exists today, what changes, how it was tested, and who owns the follow-up.

Inventory what the current site does

Ask for a list of existing URLs before approving a new page structure. Combine the site's page inventory with available search, analytics, and inquiry information. Label missing information instead of treating a blank column as zero value.

A page may deserve attention because it receives search impressions, has useful inbound links, supports a recurring customer question, or appears in a sales process. Traffic alone is an incomplete reason to keep or discard it.

Use a working sheet with the current URL, purpose, evidence available, proposed action, destination if changed, and review owner. “Keep,” “improve,” “combine,” and “remove” are different decisions. Give each a reason someone besides the designer can understand.

This is also where you separate a redesign from a URL migration. Changing the layout does not require changing every address. If a working URL still describes the page, ask what changing it would accomplish.

Make changed URLs an explicit project

When addresses do change, map old pages to relevant new destinations and test those mappings before launch. Google's site-move guidance covers URL changes, preparation, mapping, and monitoring; it also warns that search visibility can fluctuate while a move is processed. A design approval is not a substitute for that migration work. Google: Site moves.

Consider a hypothetical company combining two overlapping service pages. The team should explain why the new page satisfies the intent of both old pages. Sending both addresses to the homepage because it exists is not the same decision.

For a permanent move, Google recommends a permanent server-side redirect where possible; HTTP 301 and 308 are permanent redirect status codes. Ask the developer to show the actual response and final destination, rather than merely showing that a browser eventually loads something. Google: Redirects and Search.

Have the reviewer follow a sample of important old links as a customer would. Does the new destination answer the same question? Technical routing and a useful arrival experience belong in the same review.

Keep page identity consistent

For each important page, check the final address, title, main heading, description, and canonical reference together. A canonical reference tells search engines which URL you prefer for duplicate or closely similar content; it is a signal, not a command that overrides every other consideration. Google advises consistency among canonical signals and internal links. Google: Canonical URLs.

The practical handoff question is whether the team can explain what page it intends to exist. A production service page should not accidentally identify the preview address as its preferred version. An old title copied from a template should not describe a different service.

Review meaning as well as fields. A technically tidy title can still be vague. A polished heading can remove the one phrase that made the service understandable. Preserve the buyer's question while improving the way the page answers it.

Check discovery and access on production

Open the live navigation, service links, and article links after deployment. Confirm that important pages remain reachable through the site, not only through a URL somebody pasted into a spreadsheet.

Review the generated sitemap against the approved final URLs. Google recommends including the canonical URLs you want shown in search results; submitting a sitemap helps discovery but does not guarantee crawling or indexing. Google: Build and submit a sitemap.

Also verify the production response and indexing controls for representative pages. Have the technical owner inspect page-level and response-header directives, rather than assuming that removing a preview banner made the site publicly indexable. Record the checked address and result.

You do not need every stakeholder to become a developer. You do need a named person who can distinguish a successful deployment from a successful public page check.

Test the inquiry path alongside the SEO work

Search traffic has a job after it arrives. Include the contact path in the launch review even when the project is being described as an SEO migration.

On a phone, open a service page, read the offer, start an inquiry, and verify both acceptance and failure behavior in a controlled test. Label test submissions so nobody mistakes them for prospects. Confirm the intended recipients and what the visitor sees when delivery fails.

Check phone links, booking destinations, confirmation copy, and any event used to count success. Clicking a button and successfully sending an inquiry should not be casually treated as interchangeable outcomes.

The marketing analytics guide provides broader measurement context. At launch, the narrower requirement is evidence that the specific customer action you care about still works and is measured as intended.

Agree on the first post-launch review before launch day

Save a dated baseline and a concise change log. Record the URLs affected, the deployment time, and any simultaneous campaign or offer changes that will complicate interpretation.

Assign the immediate technical check separately from the later performance review. A broken page can require action now. A short run of ranking changes needs context. Compare like-for-like periods, devices, locations, search types, and page groups where the data allows it.

Do not merge an organic search position, a Maps result, and an AI feature into one success story. Likewise, a Search Console report for one URL is not a report for the whole business. Label the scope beside the number.

Agree on a rollback or repair path for material failures. Keep access to the previous implementation and identify who can act. The point is to reduce confusion during an incident, not to reverse a launch every time a metric moves.

Ask for the evidence, not a reassurance

A useful handoff can be brief: the URL decisions, tested redirects, page checks, inquiry test, baseline, and owners. It should be specific enough that a second person can verify it.

When evaluating website design and SEO support, ask how those responsibilities connect. “SEO included” needs to describe actual work.

The new site should look like progress. The launch record should help you determine whether the rest of the business came with it.