A website redesign SEO audit belongs at three moments, not one: while the plan is still changeable, immediately after launch as validation, and again once search engines have recrawled enough URLs for the real consequences to surface.
The first pass decides what must survive the change. The second confirms the launch did what it was supposed to do. The third is the only one that can show what actually happened, because it is the only one that runs after Google has re-processed the site.
There is no universal day count for that third pass, and anyone quoting one is guessing about your crawl rate. Google's site move guidance says only that "a small to medium-sized website can take a few weeks for most pages to move, and larger sites take longer." The usable signal is not the calendar — it is indexed URL counts on the old and new URL sets no longer moving. Audit when they settle.
One thing to decide before any of it: if the redesign has already launched and traffic has dropped, the first move belongs in Search Console, not in a paid audit. A public-page review can find causes. It cannot prove one.
What a redesign or migration actually changes
The reason redesigns damage search performance is rarely one dramatic mistake. It is that a relaunch touches many independent systems in the same deploy, so the failure has several plausible parents and no obvious one. This is the list worth holding in your head before anything else.
| What changes | Why it matters | The failure mode |
|---|---|---|
| URLs | Every ranking, link, and bookmark is attached to a specific URL | New slugs, a new category structure, a trailing-slash or case change, or a move away from .html paths. Old URLs 404 and their history has nowhere to go |
| Redirects | They are the only mechanism that carries an old URL's history to a new one | Missing rules, redirects to the homepage instead of the equivalent page, temporary status codes where permanent ones were meant, or chains several hops deep |
| Canonicals | They tell search engines which of several similar URLs is the preferred one | A new theme hard-codes the wrong canonical, points every page at the homepage, emits the staging domain, or points at a URL that itself redirects |
| noindex and robots rules | They decide whether a page can be indexed or crawled at all | The staging site's blanket noindex or Disallow: / ships to production. This is the single most expensive redesign mistake, and it is silent |
| Navigation and internal links | They are how crawlers and shoppers discover pages, and how importance is distributed | A cleaner menu quietly orphans collections. Body-copy links from guides to collections are dropped in the rewrite |
| Templates | One template writes titles, headings, and markup for thousands of URLs | A template stops emitting the H1, or writes a generic title pattern across the whole catalog at once |
| Structured data | Product and breadcrumb markup drives rich results eligibility | The new theme drops Product markup, or an app that used to inject it is not installed on the new build |
| Sitemaps | They are a discovery hint for the new URL set | The sitemap still lists old URLs, lists URLs that redirect, or is not regenerated at all |
| Page content | Ranking is partly a function of what is on the page | A visual redesign cuts body copy to make the layout breathe, and removes the text the page was ranking for |
The pattern: the visible part of a redesign is the design. The part that decides search outcomes is almost entirely invisible in the browser — status codes, head tags, robots rules, and generated markup. A stakeholder review of the new look tests none of it.
Stage one: the pre-launch audit
This is the cheapest of the three and the one most often skipped, because at this point nothing is broken yet. Its job is not to find problems. It is to write down what must survive.
Inventory what currently earns something
- Export the URLs that currently receive organic clicks, and the URLs that hold external links. These two lists overlap but are not the same, and both need a destination on the new site.
- Record each important page's current title, H1, canonical, and indexation status. This becomes the comparison set for stage two.
- Note which pages exist mainly to be found by search. If the redesign proposes to merge or remove them, that is a decision, not a detail.
Decide the URL policy before the build, not after
The most common cause of a bad website site migration SEO outcome is that URL structure was treated as a design output rather than an input. If URLs do not have to change, do not change them. A pure visual refresh on the same URLs is a materially lower-risk project than a replatform, and Google documents the two cases separately: site moves without URL changes versus site moves with URL changes.
Where URLs must change, build the old-to-new map as a spreadsheet during the build, with a row for every URL on the inventory list. Each row needs a specific equivalent destination. "Redirect everything else to the homepage" is a fallback for stray traffic, not a plan.
Agree the redirect mechanics
Google's redirect documentation is explicit about the ranking of methods. Server-side HTTP redirects are the most reliably interpreted; meta refresh is weaker; JavaScript redirects are a fallback because rendering can fail. Permanent status codes (301, 308) signal that the target should become canonical; temporary ones (302, 303, 307) do not carry that signal. The site move guidance also asks you to avoid chains beyond a few hops and to keep redirects in place "for as long as possible, generally at least 1 year."
Plan the staging protections you will have to undo
Write the removal step into the launch runbook at the same time you add the protection. Every blanket noindex rule, every Disallow: /, and every password wall on staging is a production outage waiting for someone to forget it.
Stage two: launch-day validation
This pass is narrow, fast, and mechanical. It is not an assessment of whether the redesign is working — nothing can tell you that yet. It answers one question: did the launch do what the plan said it would?
Indexability of the live site
Fetch the production robots.txt and the rendered head of a homepage, a collection, and two product URLs. Confirm no stray noindex rule and no site-wide Disallow shipped. Note that a page blocked in robots.txt cannot have its noindex read at all — Google's block indexing documentation states the rule "must not be blocked by a robots.txt file" to take effect, which is also why blocking is not a way to remove pages.
Redirects, sampled against the map
Take a sample from the old-to-new spreadsheet across every page type, not just the homepage. Confirm each returns a permanent status code, lands on the intended equivalent in one hop, and does not terminate on a 404 or a soft 404 dressed as a category page.
Canonicals in the rendered source
Confirm each sampled page declares one canonical, that it is self-referential where it should be, and that it uses the production domain rather than staging. Google's canonicalization documentation treats a canonical link as a strong signal rather than a directive, and specifically warns against pointing canonicals at redirect chains or conflicting across methods.
Titles, H1s, and body copy
Compare the sampled pages against the stage-one record. Look for the template failures: a missing H1, a title pattern that collapsed to the store name, or a product description that survived the CMS export but is no longer rendered.
Structured data
Confirm Product and breadcrumb markup is still emitted on the new templates and still describes what the page visibly says. Google's product structured data reference lists what a product snippet needs; a theme change is a common point at which it silently stops being output.
Sitemaps and Search Console
Regenerate the sitemap so it contains the new canonical URLs and not redirects. Google's sitemap documentation is clear that submitting one "is merely a hint" and does not guarantee that Google will download it or use it for crawling, so treat it as discovery help rather than as the fix. Where a domain changed, submit the Change of Address request; Google notes it is not needed for an HTTP-to-HTTPS move.
Everything in that list is verifiable on launch day from public pages plus your own Search Console. None of it requires waiting, and all of it gets more expensive to fix once the old URLs have started dropping out of the index.
Stage three: the post-launch diagnosis
This is the audit people mean when they search for one, and it is the one with a genuine timing constraint. Running it too early produces noise: indexed counts are mid-flight, positions are unstable, and the new URLs have not all been processed. Running it late means a fixable problem has been compounding.
The honest trigger is not a date. Watch the two indexed URL counts described in Google's site move guidance — the old set falling, the new set rising — and audit properly once both have stopped moving meaningfully. On a small store that can be a couple of weeks. On a large catalog it is longer, and Google says so rather than giving a number.
What this pass is looking for
- Coverage gaps. New URLs that were expected to be indexed and are not, and old URLs still indexed that should have been replaced.
- Consolidation failures. Cases where the old URL's history plainly did not transfer, usually because the redirect is missing, temporary, chained, or aimed at the wrong page.
- Duplication the new structure created. A redesign that adds filters, sorting parameters, or a second path to the same collection generates URL variants that did not exist before.
- Template regressions that survived launch day. Problems that only appear on page types outside the launch-day sample.
- Intent drift. Pages that were merged in the redesign and now serve two purposes badly, or a new page that competes with an existing one for the same search.
Ecommerce-specific checklist
Stores have failure modes that a brochure site does not, because the catalog is generated rather than authored. Run these in addition to the general checks above.
- Product URLs across the whole handle set. Sample products from several collections, not just bestsellers. Slug generation rules often differ for products with special characters, long names, or duplicate titles.
- Variant and option URLs. Confirm which variant forms are crawlable on the new build and that they canonicalise to the parent product as intended, rather than becoming a new set of near-duplicate indexable URLs.
- Collection and category paths. A restructured taxonomy is a URL change even when the design looks similar. Every collection that had a URL needs a destination.
- Filtered and faceted URLs. New filter UI frequently creates a very large number of crawlable combinations. Decide which have standalone search value before deciding what to block or canonicalise; Google's faceted navigation documentation covers the trade-offs.
- Pagination on collections. Confirm page two onward is reachable, returns 200, and does not canonicalise every page to page one if those products are only discoverable there.
- Out-of-stock and discontinued products. A replatform is when stores quietly drop products that were still ranking. Decide deliberately: keep, redirect to the nearest equivalent, or let it 404.
- Internal search and cart paths. Confirm the new build is not exposing internal search result URLs or cart states as indexable pages.
- Product markup and price/availability accuracy. Structured data that no longer matches the visible page is worse than none.
- Guide-to-collection links. Content pages that pointed at collections are a common casualty of a template rewrite, and they are usually the internal links doing the most work.
- Image URLs and alt text. A CDN or theme change rewrites image paths; image search traffic is the quietest thing to lose.
Shopify-specific notes
Shopify redirects are created under URL Redirects in the admin. Its URL redirect documentation records real constraints worth knowing before you plan a map: you can only redirect from URLs that currently 404, several fixed paths such as /products and /collections/all cannot be redirected, and per-plan redirect limits apply. Theme changes are also the usual reason template-level markup and metadata quietly change. More on the platform in the Shopify SEO audit page.
WooCommerce-specific notes
The product permalink base is a settings choice, and changing it on a live store rewrites every product URL. WooCommerce's permalinks documentation states it plainly: "Changing permalink structures updates the URLs of existing products. Any previously shared links or search engine indexes pointing to the old URLs will return 404 errors unless you set up redirects." Overlapping SEO plugins after a rebuild are the other frequent source of conflicting canonical and robots output. More on the platform in the WooCommerce SEO audit page.
The redesign mistakes that do the most damage
Ranked by how much they cost relative to how easy they are to avoid.
| Mistake | Why it is costly | Cheap prevention |
|---|---|---|
| Shipping staging's noindex or Disallow: / | Removes the whole site from eligibility, and looks like nothing is wrong in a browser | One check of production robots.txt and rendered head tags on launch day |
| Changing URLs without a page-level map | Every unmapped URL's history stops at a 404 | Build the map from the inventory list during the build, not after launch |
| Redirecting everything to the homepage | Google's site move guidance says not to redirect many old URLs to one irrelevant destination such as the new homepage, because it "can confuse users and might be treated as a soft 404 error" | Map to the nearest genuine equivalent. Consolidating several old pages onto one genuinely consolidated new page is fine; a blanket sweep to the homepage is not |
| Temporary status codes on a permanent move | Temporary redirects do not signal that the target should be canonical | Confirm status codes on a sample rather than assuming the platform's default |
| Cutting body copy for visual balance | Removes the text the page ranked with, with no error anywhere to indicate it | Diff the rendered text of top pages against the stage-one record |
| Simplifying navigation into orphan pages | Pages that lose all internal links lose their discovery path and their internal importance | Check that every priority collection is still reachable from at least one crawlable path |
| Retiring redirects after a month | Signals may still be in transit; Google asks for at least a year | Treat the redirect layer as permanent infrastructure, not launch scaffolding |
| Judging the outcome in week one | Indexed counts and positions are mid-flight, so the data is not yet about the redesign | Watch indexed URL counts settle before drawing any conclusion |
Triage: rankings or traffic dropped after launch
The instinct after a relaunch is to blame the relaunch. Sometimes that is right. Often the timing is coincidental — a core update, a seasonal pattern, a tracking change, or a competitor's move can land in the same window. A decline that follows a redesign is not evidence that the redesign caused it. Correlation in an analytics chart is a prompt to investigate, not a finding.
Work through the table below in order. Google's guidance on debugging search traffic drops starts in the Performance report and separates impressions from position before touching anything technical, which is the right sequence here too.
| What you observe | What it points at | How to test it |
|---|---|---|
| Impressions collapsed across the whole site at once | A site-wide indexability problem rather than a ranking problem | Check production robots rules and head tags first, then Page Indexing for a mass exclusion reason |
| Old URLs still show impressions; new equivalents show almost none | Redirects or the new URL set are not being processed as intended | Sample redirects for status code, hop count, and destination; inspect a few new URLs directly |
| Clicks fell but impressions and positions are roughly stable | A snippet, title, or measurement change rather than a ranking change | Compare rendered titles and descriptions against the old ones; confirm analytics is actually recording on the new build |
| One page type dropped and the rest held | A template-level regression on that type | Compare two or three URLs of that type against the stage-one record for H1, canonical, markup, and body text |
| A handful of specific pages dropped | Those URLs were merged, removed, thinned, or orphaned in the redesign | Trace each one: does it still exist, is it still linked, does it still contain the content it ranked with |
| Indexed URL count is far higher than the catalog size | The new build created crawlable variants — filters, parameters, or a second path to the same page | Look at what kinds of URL are indexed, then decide handling before blocking anything |
| Positions moved but the site is technically clean | Possibly not the redesign at all | Check whether a core update completed in the window, and compare against the same period last year before concluding |
| Nothing moved for the first week or two | Probably normal — recrawling has not caught up | Wait for indexed counts to settle rather than making changes on incomplete data |
A rankings loss audit has a ceiling. Public pages can show that a redirect is temporary, a canonical is wrong, or a template stopped emitting an H1. They cannot show what Google did with those signals, when, or why. Establishing cause needs Search Console history, analytics, and often server logs — which is why a serious ranking-loss investigation starts with your own data and uses a public-page review to narrow the candidates.
Replatform, redesign, or both
The words get used interchangeably and they carry different risk.
- Visual redesign, same platform, same URLs. Lowest risk. The exposure is templates, body copy, internal links, and markup — not URL history. Most of the checks above still apply; the redirect layer mostly does not.
- Restructure, same platform, new URLs. Now URL history is in play and the old-to-new map becomes the central artefact.
- Ecommerce replatform to a different system. The highest-risk version, because everything changes together: URL patterns, template output, structured data, sitemap generation, and the redirect mechanism itself. A website replatform typically also imports the catalog, so product data problems and SEO problems arrive in the same week and get confused with each other.
- Domain change. Adds the Change of Address step and makes the redirect layer the only bridge between old and new.
Knowing which of these you are doing is what makes the pre-launch pass cheap. A visual refresh does not need a URL map. A replatform that is treated like a visual refresh is where the expensive version of this guide's problems comes from.
What our audit can and cannot do here
StoreAuditLab sells one fixed-scope product: a manual review of up to 10 representative public URLs, plus up to 10 Ahrefs-backed keyword and page opportunities, delivered as a prioritized PDF within 48 hours for $100. That scope is a good fit for some parts of a post-redesign question and a poor fit for others, and the difference is worth stating before you buy rather than after.
A good fit for
- A post-launch sanity check on representative templates: what the new build actually emits for titles, H1s, canonicals, robots rules, and markup
- Confirming that a sample of redirects resolves the way the plan intended
- Finding template-level regressions that repeat across a catalog
- Spotting pages that now compete with each other after a merge
- Comparing the new page set against search demand you are not answering
- A second pair of eyes before a redesign's URL decisions are locked
Not a fit for
- Proving why traffic dropped — that needs Search Console history, analytics, and often logs
- Verifying a full redirect map; ten URLs is a sample, not coverage
- A complete crawl of a large catalog
- Implementation, theme edits, or writing the redirect rules
- Penalty, manual action, or backlink recovery work
- Any ranking, traffic, or revenue promise
The audit works from publicly observable evidence plus third-party keyword data. No store logins, no analytics access. If your question is "did the launch emit what it was supposed to emit, and what should be fixed first" — that is squarely in scope. If your question is "prove the redesign caused the drop" — no public-page review can answer it, at any price. What sets an audit's price covers the rest of the scope boundary, and the full sample report shows the format the findings arrive in.
Common questions
Should I run an SEO audit before or after a redesign?
Both, and they are different jobs. The pre-launch pass records what currently earns something and decides what must survive — it is the cheapest possible insurance because nothing is broken yet. The post-launch pass finds what the build actually did. If you can only run one, run the one before launch: a problem caught in the plan costs a spreadsheet row, and the same problem caught two months later costs recovery.
How long after launch should I wait before judging the results?
Long enough that search engines have recrawled and reprocessed most of the site, which is a property of your site's size and crawl rate rather than a fixed number of days. Google says only that a small to medium-sized website can take a few weeks for most pages to move and that larger sites take longer. The practical signal is that indexed URL counts on the old and new URL sets have stopped moving. Launch-day validation should not wait for any of this — it happens immediately.
Can you redesign a website without losing SEO?
Yes, and the way to reduce avoidable risk is unglamorous. Keep URLs where you can. Where you cannot, map every URL that earns clicks or holds external links to a specific equivalent, with permanent server-side redirects kept in place long-term. Preserve useful text and internal links rather than trimming them only for layout. Verify indexability, canonicals, templates, and markup on live production rather than assuming the platform default. Nobody can promise no movement at all, and a lasting decline still needs diagnosis rather than an assumed cause.
How many hours should I estimate for site migration SEO?
There is no honest single number, because the work scales with the number of URLs that need an individual decision rather than with the size of the design project. The variables that actually move it are: how many URLs currently earn clicks or hold links, whether URL patterns change at all, how many page types exist, whether the platform generates redirects or requires them one at a time, and whether the catalog is being re-imported. Estimate the URL map first — it is usually the largest single line item — and treat validation and post-launch diagnosis as separate blocks rather than folding them into launch. For reference on our own boundary: our fixed-scope review of up to 10 representative URLs is delivered within 48 hours, which is a sampled diagnosis and not a full migration programme.
My rankings dropped right after the redesign. Was it the redesign?
Possibly, but the timing alone does not establish it. Start in Search Console rather than in a crawler, and separate impressions from position before touching anything. Check whether the fall is site-wide, confined to one page type, or limited to specific URLs — each points somewhere different. Also check whether a core update completed in the same window and how the period compares to the same weeks last year. A public-page review can find broken redirects, wrong canonicals, missing markup, and lost content, and it can rule things out. It cannot prove causation.
Is an ecommerce replatform different from a redesign?
Materially. A visual redesign on the same platform and the same URLs mostly risks templates, body copy, internal links, and markup. A replatform changes URL patterns, template output, structured data, sitemap generation, and the redirect mechanism at the same time, and usually re-imports the catalog as well — so product data problems and search problems arrive together and are easy to confuse. Treat a replatform as the higher-risk project it is, and do the URL mapping before the build rather than after.
Get a second pair of eyes on the relaunch
StoreAuditLab reviews up to 10 representative public URLs by hand, adds up to 10 Ahrefs-backed keyword and page opportunities, and delivers a prioritized plain-English PDF in 48 hours. $100 one time, fixed scope, no implementation upsell. Useful before you lock URL decisions, or after launch when you want the template-level problems found and ordered — not a claim about what caused a drop.
Get the $100 audit →