Website redesign SEO checklist and redirect map

A website redesign SEO checklist should establish a baseline, preserve useful content and URLs, test permanent redirects, verify indexing rules and monitor the launch. Use the checks below before changing templates or publishing a new site. Assign an owner and record evidence for each check so the team can identify and fix a failed release.

The checklist applies to a WordPress rebuild, a React or Next.js migration, and a redesign on the same platform. Separate URL changes, content changes and design changes where practical. Google recommends changing one thing at a time in its site move guidance. Planning reduces avoidable errors; it cannot guarantee unchanged rankings.

If the redesign is already live and visibility has fallen, follow the post-redesign traffic diagnosis. For routine releases after launch, use the maintenance SEO checklist.

Download the redesign launch checklist and redirect map

Use these editable CSV worksheets in Excel or Google Sheets. The redirect map contains fictional example.com URLs to demonstrate decisions; replace them with your own inventory. The launch checklist starts with blank evidence and status fields. Neither worksheet represents a client project or search performance result.

• Download the redirect map template (CSV)
• Download the website redesign SEO checklist (CSV)

For each old URL, record the intended action, final URL, expected response and observed response. Keep an unchanged page at its existing URL. Redirect a moved or consolidated page only to a relevant replacement. If content is permanently removed and has no suitable replacement, return a real 404 or 410 and remove internal links to it.

What must pass before launch?

A failed check needs an owner, a fix and a retest before the team signs it off. For a Next.js migration, also verify sitemap cache and publishing behavior and missing-page responses under streaming.

Worked launch test: five URLs and two failures

A launch sign-off needs expected and observed results for each important route. The following fictional test shows why a successful final response is not enough. It includes a retained page, a moved page, consolidated content, an intentional removal and a retained page with the wrong canonical. These are illustrative observations, not requests made to a client website.

Download the five-URL launch test example (JSON) alongside the existing CSV worksheets. The example records first response, final destination, expected canonical, a repair decision and blank retest fields. Copy the structure into your project log, replace the example addresses and save actual evidence before marking a row complete.

Run the checks in the same order

1. Confirm the intended action. Review the approved map before testing. A retired offer does not need the same outcome as a moved service page.
2. Inspect the first response. Record whether the old URL returns the expected success, permanent redirect or removal response. Do not record only the final address shown in a browser.
3. Follow the full destination path. Save the final URL and status. Review any intermediate hops, loops or unexpected host changes.
4. Read the destination. Check that the actual page answers the old page's intended purpose. A homepage returning 200 is not evidence of a suitable replacement.
5. Check indexing signals. Inspect canonical annotations, robots metadata and response headers. Review crawl access separately; a crawler must be able to retrieve the information it needs.
6. Check the source links and sitemap. Navigation and contextual links should reach the final relevant destination. Review the XML sitemap validation workflow for the published URL inventory.
7. Retest the repaired row. Save the time, evidence and owner. A proposed fix stays open until its new behavior is observed.

Test representative URLs from each changed template, then check the approved map in full where practical. A sample can expose a shared template defect but cannot certify every URL. Keep the sampled set explicit so another reviewer understands what the release check actually covered.

Separate release blockers from monitoring questions

Broken priority destinations, unintended indexing blocks and production pages canonicalizing to staging are release defects that need an owner and a fix. A new page that has not yet appeared in search is a different observation: confirm its technical eligibility, then track its indexing evidence. Do not repeatedly change a passing redirect map solely because a report has not refreshed.

For each failed row, record the affected scope, proposed repair, release decision and retest result. A single template defect can affect many pages, so reproduce the fix on more than the original example. Keep a known previous version and an agreed rollback procedure when a serious problem makes the new release unusable.

Use the automated SEO release tests for repeated route and metadata checks, while retaining human review for relevance and content. Automation can compare a destination or canonical with an expected value; it cannot decide whether two pages genuinely serve the same customer need.

Phase 1: Pre-launch preparation

This phase happens weeks or months before the new site goes live. The work you do here determines whether the launch goes smoothly or becomes a recovery project.

Benchmark your current performance

Before changing anything, document your current state so you can measure the impact of the redesign:

• Organic traffic -- export monthly organic session data from Google Analytics for at least the last 6 months.
• Keyword rankings -- record your positions for your top 50-100 keywords using rank tracking tools.
• Indexed pages -- check the Page indexing report in Google Search Console. Note how many pages are currently indexed.
• Backlink profile -- export your top referring domains and pages. These links need to keep working after the redesign.
• Top performing pages -- identify your highest-traffic pages, pages generating the most conversions, and pages ranking for your most important keywords. These are your priority pages that absolutely cannot break.

URL mapping and redirect plan

This is the single most important step. Every URL on your old site needs a clear destination on the new site.

Crawl the existing site

Start with a crawler export of reachable URLs, then compare it with sitemaps, Search Console landing pages, analytics, historical redirects and important backlink destinations. A crawl alone can miss orphaned or historical URLs. Record response status, page purpose and intended action in the master inventory.

Map old URLs to new URLs

Create a spreadsheet with two columns: old URL and new URL. For every page on the old site, determine where it maps to on the new site:

• Same URL -- ideal. No redirect needed. Link equity is preserved directly.
• New URL -- requires a 301 redirect from the old URL to the new one.
• Merged into another page -- redirect the old URL to the most relevant surviving page.
• Removed entirely -- redirect only if a relevant replacement exists. Otherwise return a real 404 or 410. An unrelated homepage or category redirect can be treated as a soft 404.

Implement 301 redirects

Set up a server-side 301 or 308 for a permanent move to a relevant replacement. Keep the rules available for at least one year, as Google recommends for site moves, and preferably longer when old links still receive visits. Test the old URL and its final destination before launch. Common implementation methods:

• Server-level redirects in .htaccess (Apache) or nginx config
• Cloudflare Workers or page rules for sites on Cloudflare
• Plugin-based redirects for WordPress (Redirection plugin or Rank Math)
• _redirects file for Netlify or similar platforms

Avoid redirect chains (old URL > intermediate URL > final URL). Additional hops add latency and create more opportunities for a broken destination or loop. Point the old URL directly to the final relevant page. Google says permanent redirects do not inherently lose PageRank; the reason to shorten a chain is reliable routing and faster access.

Moving a store from WooCommerce requires platform-specific decisions beyond the general map. Use the WooCommerce to Shopify SEO migration and redirect worksheet to review product/category destinations, Shopify path restrictions and live response checks.

Content migration

A redesign often leads to content being accidentally removed, rewritten, or reorganized in ways that hurt rankings.

Review valuable content before changing it

Review valuable pages against their search intent, conversion role and current accuracy before removing or merging them. Preserve useful coverage and avoid simultaneous unrelated rewrites during a migration. When outdated or overlapping content needs a change, document the decision, relevant destination and measurement plan rather than keeping it unchanged solely because it once ranked.

Preserve title tags and meta descriptions

If a page keeps the same URL and content, keep the same title tag and meta description. Titles help describe the page, and descriptions can inform the search snippet. Keep useful existing metadata during the migration so changes in search presentation are easier to investigate.

Maintain heading structure

The new design should preserve the heading hierarchy (H1, H2, H3) of existing pages. Designers sometimes remove or restructure headings for visual reasons. Make sure the H1 stays, and the heading hierarchy remains logical.

Preserve internal links

Check that all internal links from the old site are replicated in the new design. A redesign frequently breaks internal linking structures when navigation menus change, sidebar links are removed, or footer layouts are updated. Broken internal links can orphan pages and disrupt how Google understands your site structure.

Technical SEO setup

Before launching, verify these technical elements on the new site (ideally on a staging environment):

Check	What to verify
robots.txt	Allows crawling of all important pages. Remove any staging-environment "Disallow: /" rules before launch.
XML sitemap	Updated with all new URLs. Remove old URLs that no longer exist. Submit to Search Console after launch.
Canonical tags	Each intended canonical page points to its correct production URL. Intentional duplicates point to the preferred equivalent page. Check the canonical rules against the URL map.
Schema markup	All existing structured data is migrated and updated with new URLs where needed.
HTTPS	The new site runs on HTTPS with no mixed-content warnings.
Mobile responsiveness	Test on real devices, not just browser tools. Check all page types. Read the mobile SEO guide.
Page speed	Run PageSpeed Insights on key pages. The new design should be at least as fast as the old one. See the speed guide.
Open Graph tags	Verify OG tags are set on all pages for proper social sharing.
Analytics tracking	Google Analytics and Search Console are connected and tracking properly on the new site.
404 page	A missing URL returns the intended 404 or 410 response, rather than a success response containing an error message. Check the body and status.

Phase 2: Launch day

On the day you switch from the old site to the new one:

1. Deploy the new site with all redirects active from the start.
2. Test every redirect by visiting old URLs and confirming they land on the correct new page. Spot-check at minimum your top 20 pages, all service/product pages, and the homepage.
3. Submit the updated sitemap to Google Search Console. It helps Google discover the intended canonical URLs; it does not guarantee immediate crawling, indexing or rankings.
4. Remove unintended noindex directives from pages intended for search. Check both HTML robots tags and the X-Robots-Tag response header. Keep intentional exclusions such as private or utility pages excluded.
5. Verify analytics is firing on the live site. Check real-time reports in Google Analytics to confirm data is flowing.
6. Check robots.txt on the live domain. Make sure it does not block crawling of important sections.

Add the automated SEO release test suite to your release process for important routes, with deliberately failing and corrected examples to verify that the gate works.

Phase 3: Post-launch monitoring

Use the repair log to repair broken source links after a launch, recording each source page, original href, intended destination and observed retest outcome.

Set a monitoring cadence based on the scale of the change, available traffic and observed errors. Check release defects immediately; review performance using complete, comparable periods. For a substantial migration, frequent checks at the beginning can help identify shared template problems, followed by less frequent reviews once the release is stable:

• Page indexing in Search Console -- inspect unexpected changes affecting URLs that should be indexed. Intentional redirects, duplicates and removed pages can be valid exclusions; assess them against the approved URL map.
• Crawl stats in Search Console -- Review crawl activity alongside server availability and crawl access. A change in request volume alone does not identify the cause; compare affected hosts, resources and observed errors.
• Organic traffic in Analytics -- compare equivalent days and weeks to your benchmarks. Investigate sustained declines in important pages or conversions, allowing for seasonality and tracking changes.
• Keyword rankings -- track priority queries and their destination pages. Investigate disappearances or sustained losses alongside impressions, clicks and indexing evidence; one position change alone cannot identify the cause.
• 404 responses -- check unexpected missing pages against the URL map. Restore an accidentally removed page or redirect a moved page to its relevant replacement. Keep intentional removals as 404 or 410 when no replacement exists.
• Core Web Vitals -- check for regressions in real user experience and use lab tests to diagnose them. Performance is one part of page experience; a single score cannot predict rankings. Use the speed optimization guide when needed.

Investigate a persistent decline using the affected pages and queries rather than a fixed recovery deadline. Compare equivalent periods and separate countries, devices and page templates. The Search Console query-to-page workflow helps keep those comparisons consistent. Check redirect failures, content changes, indexing rules and rendering problems with a technical SEO audit.

Planning a website redesign? As an SEO specialist and front-end developer, I handle both the design/development and the SEO migration in one process. Get in touch and let's review the migration risks before your launch.