Website Redesign SEO Checklist: Before, During, and After Launch

Start here: Preserve useful pages, map changed URLs, test the live release, and compare the results with a dated baseline. Use the redesign SEO launch worksheet (CSV) (opens in a new tab) to record each URL decision and its actual test result.

A website redesign should account for the useful work the current site already does. Customers may have saved a service page, another business may link to a project, and search visitors may arrive somewhere other than the homepage.

A website redesign SEO checklist helps carry those paths into the new site. Before launch, identify the pages that matter, decide what happens to their addresses and content, and agree on how the finished work will be checked. After launch, verify those decisions on the actual website.

This guide focuses on search continuity and launch verification. For the business information, photographs, and account access needed to begin a project, use the website redesign preparation guide.

Create an inventory of the current site. Include service pages, articles, project pages, important downloads, and the main contact paths. Record each address and what someone uses that page to do.

Add the information you already have about search visits, inquiries, and links. A low-traffic page may still answer an important buying question or support a customer process. Decide whether to keep it based on its purpose as well as its numbers.

Save a dated baseline before changing anything. Record the reporting period and separate branded searches from service-related searches where the data allows. Keep screenshots of important page layouts and copies of content you may need to compare later.

The planning question is specific: which parts should stay, which need improvement, and which no longer serve a useful purpose?

Keep one dated spreadsheet with the following fields for each priority page: current URL, purpose, search clicks and impressions, reporting dates, important query groups, received inquiries where attribution is known, incoming links worth preserving, and the proposed content decision.

Use a recent complete period and retain a longer comparison where available to understand seasonality. A 28-day view can be convenient for matching weekdays; it is not a universal test window. Record filters, device, country, and tracking changes so another person can reproduce the comparison.

Export the old page titles, main headings, canonical URLs, status codes, and internal links with a crawler or other suitable inventory tool. Add pages from your CMS, sitemap, and business records. A crawl alone can miss an unlinked landing page still used in a sales email or advertisement.

Choose the priority set deliberately: pages that generate inquiries, answer high-value buying questions, receive relevant search visits, or have useful external links. Testing those pages first helps focus launch decisions, while the full URL inventory remains necessary for mapping.

A new design does not require a new address for every page. If a service page still covers the same subject and its URL works, retaining it avoids an unnecessary move.

If URLs do change, create an explicit map from the old addresses to their intended destinations. Google's site-move guidance (opens in a new tab) covers preparing that mapping, implementing the move, and monitoring what happens. It also advises separating major changes where practical. Replacing the domain, platform, content, and layout together can make problems harder to isolate.

Ask the person managing the launch to explain which changes are necessary and how they will be tested. A list of new pages is not a complete account of what happens to the old ones.

The examples below describe an imaginary business website. They demonstrate decisions, not a prescription for your URLs.

For a permanent move, Google recommends a permanent server-side redirect where possible, typically a 301 or 308. A temporary redirect serves a different purpose. Have the implementation checked against the actual decision in the map. Google's redirect documentation (opens in a new tab) explains those distinctions.

Do not send every removed page to the homepage. Choose a genuinely relevant replacement; if there is none, use an appropriate 404 or 410 response. Google's migration guidance (opens in a new tab) addresses removed content and irrelevant redirects.

Give the developer columns for old URL, expected destination, observed response, final URL, final status, and reviewer. A row is finished when the observed behavior matches the plan, not when a redirect rule has merely been entered.

For example, the imaginary /web-design-old/ page should return a permanent redirect to /website-design/, which should then return a working page. If it instead visits /services/ first and lands on a missing page, the map has not passed. Open the old address directly; clicking only the new navigation will never exercise that path.

Test for loops, unnecessary intermediate hops, and redirects to the wrong subject. Include important PDFs and image URLs when those assets move. Update your own internal links to the final destination so visitors do not repeatedly take the old route. Google's site-move documentation (opens in a new tab) covers assets, internal references, and redirect handling.

Review important pages alongside their replacements. Has a useful service explanation disappeared? Have project details been reduced to a photograph? Can a visitor still find the answer that made the old page useful?

The new copy can be clearer and more concise without removing essential information. Give each page a descriptive title, a main heading that fits the subject, and a next step appropriate to the visitor's needs.

Check preferred URLs as well. A canonical tag identifies the preferred version of a page when similar versions exist. Internal links, canonical tags, and sitemap URLs should point consistently to the intended addresses. Avoid accidentally identifying the staging site or a retired address as preferred. Google's canonical guidance (opens in a new tab) explains these signals; a canonical tag does not physically redirect visitors.

The team should know how the preview is kept out of public search and which settings must change at launch. Password protection, crawler rules, and noindex have different functions.

A noindex instruction tells a search engine not to include a page in its results, but Google must be able to crawl the page to see it. Blocking a URL in robots.txt is not a substitute for that instruction. Use proper access control for private previews. Before release, check that intended public pages are not carrying over a preview-only exclusion. Google's noindex documentation (opens in a new tab) explains the distinction.

Keep the launch checklist in the project scope. Each row should name a person and an observable result:

Use this as the acceptance record for the public release. A named reviewer should attach the result or record the exception next to each item.

• Priority public pages return successful responses and show the approved content on mobile and desktop.
• Changed old URLs reach their intended replacements; intentionally retired URLs behave as documented.
• Live pages have no unintended password gate, crawler block, or noindex instruction, including one sent in an HTTP header.
• Canonical URLs, navigation, contextual links, and sitemap entries use the intended live addresses.
• Page titles and main headings identify the actual subject; useful service information and project evidence survived the redesign.
• Important images and downloads load, and descriptive image alternatives still fit the content.
• Existing structured data matches the visible page and has not retained staging URLs or obsolete business details.
• Contact and booking paths work end to end, including actual receipt and understandable error messages.
• Analytics records the agreed interactions, with a dated note for any measurement changes.
• The launch owner knows who can restore service, what data must be preserved, and who checks the result.

A broken primary inquiry path or a sitewide indexing exclusion should trigger a launch decision immediately. A minor visual preference belongs in the follow-up list. Define that distinction before launch day so it does not become an improvised argument under pressure.

Repeat the key checks on the production domain. Preview success does not establish that live configuration, notifications, or third-party connections are working.

Open important old links directly. Check their destinations, the main navigation, and any links from business profiles or advertising you control. Complete an agreed test inquiry and confirm actual receipt.

Use Search Console (opens in a new tab) to inspect representative URLs, review indexing, and examine search performance. Submit the current sitemap where appropriate, then monitor rather than assuming submission guarantees inclusion.

Agree who checks early launch issues and who reviews the following weeks. A new indexing exclusion, a broken redirect, and a change in search demand need different responses. Compare pages and query groups, not only a sitewide total.

A reasonable starting schedule is to check live functionality and critical URLs immediately, revisit indexing and errors during the first week, and review page and query trends weekly through the first month. Larger migrations may need closer and longer monitoring. This is a suggested review cadence, not Google's promised processing time.

Treat these as investigation paths, not automatic diagnoses. Several causes can overlap. Keep the launch log beside the reports so you can connect a symptom with a specific change.

If traffic drops, verify availability, indexing instructions, redirects, and tracking before rewriting every page. Restore missing useful content where the evidence points to its removal. Correct the identified problem, record the fix date, and follow the affected URLs. Avoid repeated large changes that erase your ability to understand what helped.

If an outage requires recovery, preserve new inquiries and other live data before replacing a deployment or restoring a backup. Recovery of service and recovery of search visibility are separate outcomes. Neither should be assumed from a successful file restore.

A useful redesign proposal makes content decisions, URL handling, testing, and post-launch responsibilities explicit. Ask who owns the inventory, who approves removals, who verifies inquiries, and what support is included after the site goes live.

Google notes that rankings can fluctuate while a significant move is processed. No responsible checklist can promise unchanged traffic. The value of planning is that the team knows what changed, what was checked, and where to investigate. Google's site-move guidance (opens in a new tab) describes that transition.

If you are preparing for a new version of your site, discuss your website redesign. Bring the current URL, the changes you need, and any pages or customer processes that must carry forward.

After launch, the website maintenance plan checklist helps define who checks forms, handles updates, and responds to problems.