Website Redesign Audit Checklist: SEO Migration Guide

A website redesign audit preserves a dated baseline, maps every old URL to a deliberate outcome, tests the new site before launch and monitors verified search and analytics changes afterwards. Keep the old crawl and redirect map so failures can be reproduced.

This checklist guides you through the SEO audit requirements at every stage of a redesign: before work begins, during the build, at launch, and in the critical monitoring period afterward. Skip any section at your own risk. The most common redesign disasters happen not because teams are unaware of SEO requirements but because they skip steps under time pressure.

Pre-Redesign Baseline

Before any redesign work begins, you need a comprehensive record of your current site's SEO assets. This baseline serves two purposes: it protects you during migration by ensuring nothing is accidentally lost, and it provides the benchmark against which you measure post-launch performance.

• Crawl the entire current site. Use Screaming Frog or a similar crawler to create a complete URL inventory. Export every URL with its status code, title tag, meta description, canonical tag, H1, word count, and indexation status. This becomes your master reference for the migration. Store this data securely. You will need it throughout the project.
• Export Google Search Console data. Save relevant Performance, Page Indexing and Sitemaps data before launch, including page and query views. Search Console retention and interface samples are limited; other retained analytics, logs and rank data can also support comparison.
• Export analytics data. Download organic landing page data including sessions, revenue (if applicable), and conversion data for at least the last 12 months. Identify your top 50 organic landing pages by traffic and your top 50 by revenue. These pages receive the highest priority during migration.
• Document backlink targets. Export your backlink profile from Ahrefs, Semrush, or a similar tool. Identify every page that has external backlinks pointing to it. These pages must be redirected correctly because each backlink represents authority that will transfer through the redirect (or be lost if the redirect is missing).
• Screenshot key pages. Take full-page screenshots of your top pages in their current state. This provides a visual reference that helps the redesign team understand what currently exists, and it serves as evidence if stakeholders later dispute what the old site contained.
• Document current technical configuration. Record your current robots.txt, XML sitemap URLs, canonical tag patterns, hreflang implementation (if applicable), structured data types, and any custom HTTP headers. These settings need to be replicated or improved in the new site, not forgotten.
• Decide content outcomes. Use user purpose, conversions, seasonality, links, search history, legal retention and measurement gaps to decide what to migrate, merge or remove. Zero impressions over a fixed period is not an automatic removal rule.

URL Mapping

URL mapping is the single most critical SEO element of any redesign. Every existing URL that has traffic, rankings, or backlinks must map to a specific destination on the new site.

• Create a complete URL mapping spreadsheet. List every current URL alongside its intended destination URL on the new site. Include columns for: current URL, new URL, current traffic (from analytics), current impressions (from GSC), backlink count, redirect type (301 or 410), and status (mapped/unmapped/merged/removed). This spreadsheet is the central reference for the entire migration.
• Map all high-value pages first. Start with your top traffic pages and top backlink pages. These are non-negotiable. Every single one must have a clearly defined destination on the new site. If the new site does not have an equivalent page, create one or identify the closest alternative.
• Handle URL structure changes. If the new site uses a different URL structure (for example, changing from /blog/post-name/ to /articles/post-name/), map every affected URL. Do not assume that changing one URL pattern applies cleanly to all URLs. Edge cases, manually created pages, and historical URL changes mean that automated pattern matching misses pages.
• Account for parameter-based URLs. Check your current site for URLs with query parameters that receive traffic or have backlinks. These are often overlooked in URL mapping because they do not appear in standard crawl exports. Search GSC for URLs containing ? to identify parameter-based pages that need mapping.
• Verify mapping completeness. Cross-reference your URL mapping against your baseline crawl. Every URL in the crawl should appear in the mapping spreadsheet. Flag any URLs in the crawl that do not have a mapping entry. These are the pages most likely to be forgotten during migration.
• Validate destination URLs exist. Before launch, verify that every destination URL in your mapping actually exists on the new site. Test by requesting each URL and checking for a 200 status code. Redirecting to pages that do not exist (creating redirect-to-404 chains) is a common migration error.

Redirect Plan

• Use a permanent redirect for permanent URL changes. Map an old URL to the closest equivalent destination and use 301 or 308. Google can process temporary redirects too, but the status should communicate the intended permanence.
• Implement redirects at the server level. Redirects should be configured in your server configuration (Apache .htaccess, Nginx config, or hosting panel redirect manager), not through JavaScript or HTML meta refresh tags. Server-level redirects are processed before the page loads, are correctly interpreted by search engines, and do not affect page load speed.
• Avoid redirect chains. If your current site already has redirects in place (old URL > current URL), the migration redirect must point directly from the old URL to the final new URL, not from the current URL to the new URL. Otherwise you create chains (old URL > current URL > new URL) that dilute ranking signals and slow crawling.
• Test redirects before launch. On a staging environment or during a maintenance window, test every redirect. Verify that the origin URL returns a 301 status code and that the Location header points to the correct destination. Automated testing using a script or a tool like Screaming Frog's list mode is essential for sites with hundreds or thousands of redirects.
• Return 404 or 410 for removed content without a replacement. Do not redirect unrelated URLs to the home page. Google processes both 404 and 410 responses as unavailable; choose the status that best describes the state.
• Plan for redirect maintenance. Google recommends keeping redirects for at least one year and users or external links may need them longer. Record ownership so future infrastructure changes preserve required mappings.
• Document the redirect implementation. Record exactly where redirects are configured (which file, which system, which hosting feature) and who has access to modify them. Development teams change, hosting providers change, and future team members need to know where the redirects live to avoid accidentally removing them.

Content Migration

• Preserve all ranking content. Content that currently ranks and drives traffic should be migrated intact to the new site. Do not rewrite ranking content during a redesign. The redesign and content changes are separate projects that should not happen simultaneously. Change one variable at a time.
• Verify title tags and meta descriptions transfer. After migrating content, check that title tags and meta descriptions from the old site are present on the new site. CMS migrations frequently lose meta tag data because the field mappings between systems differ. Compare a sample of 50+ pages against your baseline export.
• Check heading structure. New templates may change the heading hierarchy of migrated content. If your old H2s are now H3s because the new template uses H2 for a section title, the content structure has changed in ways that affect SEO. Review heading output for each template type.
• Verify image migration. Check that all images transferred correctly, that image file names and alt text are preserved, and that images are not broken. Image URLs often change during migration, which can break embedded images in content if the CMS does not update internal references.
• Preserve internal links. Internal links within content must be updated to point to new URLs rather than relying on redirects. While redirected internal links work, they add latency and a redirect hop that could be avoided. Use search-and-replace tools to update internal link URLs in the content database after migration.
• Check structured data. If your old site had schema markup, verify that equivalent or improved structured data exists on the new site. Schema implementations are frequently lost during redesigns because they were implemented in the old theme code rather than through a CMS-level plugin.

Technical Checks

• XML sitemap is updated. The new site's XML sitemap should contain all new URLs and no old URLs. Submit the updated sitemap in Google Search Console immediately after launch. If your sitemap URL has changed, update the reference in robots.txt.
• Robots.txt is correct. Verify that robots.txt on the new site does not block any pages that should be crawled. A common migration error is deploying the staging site's robots.txt (which often blocks all crawlers) to production.
• Canonical tags are correct. Check that canonical tags on the new site point to the correct new URLs, not to old URLs or staging URLs. Canonical tags pointing to non-existent or redirected URLs confuse search engines about which version of a page to index.
• SSL is fully implemented. Verify HTTPS is active on all pages, that there are no mixed content warnings, and that HTTP URLs redirect to HTTPS. A redesign that changes the URL scheme from HTTP to HTTPS (or vice versa) requires additional redirect configuration.
• Hreflang tags are updated. If your site uses hreflang for international targeting, verify that all hreflang tags reference new URLs, that reciprocal tags are in place, and that no hreflang tags point to old or redirected URLs.
• Google Search Console is reconfigured. If the domain or URL structure has changed significantly, you may need to add the new domain as a property in Search Console, submit the new sitemap, and use the Change of Address tool if moving to a new domain.
• Analytics tracking is verified. Confirm that your analytics tracking code is present and firing correctly on all pages of the new site. Check that goals, ecommerce tracking, and event tracking are configured. A redesign that breaks analytics tracking creates a data gap that is impossible to fill retroactively.

Post-Launch Monitoring

• Monitor crawl and index evidence. Check the Page Indexing report, URL inspection and server logs on a cadence matched to migration risk. Investigate new 404 groups and fix mappings when a relevant replacement was missed.
• Track indexation of new URLs. Use Search Console and URL Inspection for priority pages. There is no one-week indexing guarantee; investigate access, canonicals, internal links and content when evidence shows a persistent gap.
• Compare organic traffic and impressions. Account for seasonality, tracking changes and query mix. Investigate material page-group declines promptly rather than waiting for a fixed recovery window.
• Check affected queries and pages. Compare query and page groups with the baseline while accounting for demand, tracking and result changes. A site move has no universal recovery deadline; inspect redirects, canonicals, rendering, crawl and index state when a decline persists.
• Test redirect functionality monthly. Recheck a sample of redirects monthly for the first six months. Server configuration changes, hosting migrations, and .htaccess modifications can inadvertently break redirects. Periodic testing catches problems before they cause lasting damage.
• Run a full crawl at 2 weeks and 6 weeks. Crawl the new site at two weeks and six weeks post-launch, comparing against the baseline crawl. Look for pages that were in the baseline but are not in the new crawl (indicating they were forgotten during migration), new 404 errors, and any technical issues introduced by the new platform.
• Document lessons learned. After the monitoring period, document what went well and what went wrong. Every redesign surfaces unexpected issues. Recording these lessons makes the next migration smoother and prevents the same mistakes from being repeated.

Google documents site moves with URL changes and redirect behaviour. Use the technical report framework to assign owners and verification steps.