Technical SEO Audit Checklist Before You Redesign or Migrate

Most technical SEO audit checklists are written as if you have a quiet month and a dedicated SEO team. You usually do not. You have a redesign on the calendar, a migration in the backlog, or a founder asking why traffic dipped after the last visual refresh.

I run this audit before a site is rebuilt, not after launch when the damage is already indexed. The point is not to collect 80 screenshots. The point is to find the issues that will survive a new theme, a new CMS, or a new agency.

This technical SEO audit checklist is the version I use before a redesign or platform move. It is grounded in how Google actually crawls and indexes pages, documented in Google Search Central, not in a tool vendor's feature list.

What a technical SEO audit is for

A technical audit answers one question: can search engines discover, understand, and keep the pages that make you money? Content quality matters. Off-page signals matter. None of that helps if the important URLs are blocked, duplicated, slow, or about to be replaced without redirects.

Run this before you redesign or migrate. After launch, the same checklist becomes a regression test. The sequence matters because a pretty staging site can hide a broken production index.

If you only audit the new design, you will miss the old URLs that still hold the rankings.

When to run it

• Before a visual redesign on the same CMS.
• Before moving from Webflow, WordPress, Wix, or Framer to another stack.
• Before a domain change, HTTPS cutover, or trailing-slash cleanup.
• After a sudden indexing drop in Search Console.
• Before you hire an agency so you know what you already have.

Baseline: capture the current site before anyone touches it

Do this first. If you skip the baseline, every later argument about 'the redesign hurt SEO' becomes a guess.

1. Export the full URL inventory from a crawler. Keep status codes, canonicals, indexability, title, H1, word count, and inlinks.
2. Export Search Console performance for 16 months if available: queries, pages, countries, devices.
3. Export the Pages / Indexing report: indexed, excluded, crawled not indexed, duplicate, soft 404.
4. Save Core Web Vitals from Search Console and a lab pass in PageSpeed Insights for the homepage, a money page, and a blog or CMS item.
5. List the top 50 landing pages by clicks and the top 50 by conversions. Those URLs are non-negotiable in the redirect map later.

Use Google Search Console as the source of truth for indexation. A crawler shows what is possible. Search Console shows what Google actually did.

Crawlability and robots

robots.txt

Open robots.txt and read it like a contract. Look for accidental Disallow rules on /blog, /case-studies, CMS paths, or parameter-free HTML that marketing still needs. Confirm the sitemap URL is listed. Confirm staging, preview, and search-result URLs are blocked if they exist on the same host.

XML sitemap

The sitemap should contain only canonical, 200, indexable URLs. Lastmod dates should move when the page materially changes. If the sitemap includes 301s, 404s, noindex pages, or faceted junk, Google wastes crawl budget and you get a false sense of coverage.

Internal discovery

Orphan pages are indexable URLs with zero internal links. They often appear after a nav redesign. If a high-traffic guide is only reachable from the old footer, the new site will drop it unless you put it back in the architecture.

Indexation and duplicates

In Search Console, sort excluded reasons. The ones that matter before a redesign:

• Excluded by noindex on pages you still want ranked.
• Duplicate without user-selected canonical.
• Alternate page with proper canonical, but the canonical points at a weaker URL.
• Crawled, currently not indexed on money pages.
• Soft 404 on URLs that used to rank.

Then check host normalization. You want one protocol, one hostname, and one trailing-slash rule. Every extra combination is a duplicate waiting to split signals during the rebuild.

Canonicalization rules are documented in Google's consolidating duplicate URLs guide. Self-referencing canonicals on the preferred URL are the default. Cross-canonicals belong on true duplicates, not on every similar blog post.

Status codes and redirects

Crawl for 404s, 500s, 302s on permanent moves, and redirect chains. A chain of three hops looks harmless in a spreadsheet and expensive in crawl budget. Flatten to one 301 from old URL to final URL.

Before a migration, build the redirect map from the baseline inventory, not from memory. Every 200 URL that earned clicks or links needs a destination. Soft 404s and parameter copies do not.

On-page technical signals

This is not a content audit. It is the technical layer that content sits on.

• One H1 per page, matching the topic, not the brand slogan.
• Unique title and meta description on every indexable URL.
• Canonical matches the URL you want in results.
• hreflang only if you truly have language or country variants, and the return tags exist.
• Pagination, infinite scroll, and filters do not create indexable thin copies.

Structured data that is worth keeping

Do not add 12 schema types because a plugin offered them. Keep the types that match visible content: Organization or Person on the site, WebSite with sitelinks search box only if the search works, Article or BlogPosting on articles, FAQPage only when the FAQs are on the page, BreadcrumbList when breadcrumbs render, Product only on real products.

Validate with the Rich Results Test and keep a copy of the JSON-LD you already have. Redesigns routinely delete schema because it lived in an old snippet, not in the new component library.

Performance and Core Web Vitals

Lab scores are useful. Field data in Search Console is what Google uses. Before you change templates, note LCP, INP, and CLS for mobile on the templates you will replace: home, service, article, CMS item.

The usual pre-redesign killers: unoptimized hero images, three font families, a tag manager loaded with abandoned pixels, and a slider library nobody asked for. If the new design adds all four back, the audit was theater.

Google's current guidance lives in Core Web Vitals documentation and PageSpeed Insights.

Mobile, HTTPS, and mixed content

Confirm the site is HTTPS end to end, the certificate is valid, and HTTP redirects in one hop. Mixed content on the new design will quietly break images and scripts. Check the mobile viewport, tap targets, and whether the mobile nav hides pages that still need to be crawled.

JavaScript rendering risks

If important copy, links, or product data only appear after client-side rendering, test the raw HTML and the rendered DOM. This matters more on Next.js, Framer, and heavy Webflow interactions than people expect. If Googlebot sees an empty shell, your titles in Search Console will look fine while the body stays thin.

The pre-redesign go / no-go

I do not start a rebuild until these are written down:

1. URL inventory and top landing pages.
2. Indexation screenshot from Search Console.
3. Redirect rules for every URL that earned clicks or links.
4. List of schema types to re-implement.
5. Performance budget for the new templates.
6. Who owns robots.txt, sitemap, and canonicals after launch.

If an agency cannot show you those six artifacts, they are designing a site, not protecting a search asset. That is the difference I look for when I take over a project.

After you launch, run the same checklist again

Compare crawl vs crawl. Compare Search Console coverage week one and week four. Spot-check the top 20 URLs for title, canonical, H1, and status code. Submit the new sitemap. Request indexing only on the money pages, not the whole site.

If you want the human version of why sites decay after the reveal, I wrote about building for the post-launch web. The audit is how you keep the next launch from becoming another reset.

If you are planning a redesign or a platform move and you want a second set of eyes on the inventory before anyone opens Figma, that is the conversation I take.