A website redesign does not hurt your SEO. A bad migration does. Traffic drops when URLs change without redirects, when content gets trimmed for visual reasons, and when nobody captured a baseline to compare against. Handle those three things and a redesign is one of the few projects that reliably lifts rankings instead of risking them.

Summary

  • Most post-redesign traffic loss comes from four causes: broken URL mapping, removed content, lost internal links, and unindexed staging settings left switched on.
  • Capture a full baseline before design starts. Export Search Console queries and pages, GA4 landing page sessions, and a complete crawl of every live URL.
  • Build the redirect map from the crawl, not from memory. Every old URL gets a 301 to the closest matching new URL, never a blanket redirect to the homepage.
  • Keep content parity on your top pages. If a page ranks, the new version needs the same headings, the same entities, and at minimum the same word count.
  • Expect a two to six week settling period. Judge the redesign at day 90, not day 7.
  • In Canada, a professionally managed redesign with a proper migration typically runs $6,000 to $25,000 depending on page count and integrations.
Founder reviewing website analytics on a laptop from a mountain balcony before a site redesign
Capture your baseline before anything gets rebuilt. You cannot prove a redesign worked if you never wrote down what it replaced.

Table of Contents

  1. Why do websites lose traffic after a redesign?
  2. What do you capture before the redesign starts?
  3. How do you build a redirect map that actually works?
  4. What breaks silently during a redesign?
  5. The launch day checklist
  6. What happens in the 90 days after launch?
  7. What does a safe redesign cost in Canada?
  8. Frequently asked questions

Why do websites lose traffic after a redesign?

Because the redesign was scoped as a design project and the search engine was treated as a spectator. Google does not see your new hero section. It sees a set of URLs, the content on them, and the links between them. Change those three things without a plan and you have effectively launched a new site that happens to share a domain name.

Four causes account for nearly every drop we get called in to fix.

1. URLs changed and nothing was redirected

This is the big one. A new theme or a new CMS restructures permalinks. /services/web-design/ becomes /what-we-do/web-design/. The old URL now returns a 404. Every backlink pointing at it, every ranking it held, and every bookmark a past customer saved all die at the same moment. Google will drop the old URL from the index within days and the new one starts from zero authority.

2. Content was cut for aesthetic reasons

Designers reduce. That instinct is correct for conversion and dangerous for search. A 1,800 word service page that ranked for forty long-tail queries becomes a 300 word page with a nice photo, and thirty-eight of those queries vanish. The page still exists, the URL still resolves, and the traffic is gone anyway because the words that earned it were deleted.

3. Internal links were rebuilt from the navigation only

Old sites accumulate contextual internal links inside body copy over years. Those links tell Google which pages matter. A rebuild that only recreates the header menu and footer strips out that entire signal layer. Deep pages that were two clicks from the homepage become orphans reachable only from a sitemap.

4. Staging settings shipped to production

In WordPress this is the Discourage search engines from indexing this site checkbox, which writes a sitewide noindex. It gets ticked on staging, the site goes live, and nobody unticks it. A site can sit invisible for weeks before anyone notices, because rankings decay gradually rather than disappearing in one day. Also in this category: a robots.txt that still blocks everything, hardcoded staging URLs in canonical tags, and password protection left on a subdirectory.

What do you capture before the redesign starts?

Capture four exports before a single wireframe exists: a full crawl of every live URL, twelve months of Search Console query and page data, twelve months of GA4 landing page sessions, and your current Core Web Vitals field data. Without these you cannot build a redirect map, cannot prove regression, and cannot prove improvement.

The four exports, and what each one is for

ExportWhere fromWhat it is for
Full site crawl (URL, status code, title, meta description, H1, word count, canonical, indexability)Screaming Frog (free to 500 URLs) or SitebulbThe source document for the redirect map and the content parity check
Search Console: Pages and Queries, 12 months, exported to CSVGoogle Search ConsoleIdentifies which URLs are actually earning impressions and clicks, so you know what must not break
GA4: Landing page sessions and conversions, 12 monthsGA4 Explore reportSeparates pages that get traffic from pages that get revenue. They are not the same list.
Core Web Vitals field data (LCP, INP, CLS)PageSpeed Insights or the CrUX report in Search ConsoleYour before number. Speed is one of the few areas a redesign can objectively win.

Then rank every page into one of three buckets

  1. Protect. Pages with clicks, conversions, or backlinks. URL stays identical. Content stays at parity or improves. These are non-negotiable.
  2. Merge. Thin or overlapping pages competing for the same query. Combine into one stronger page and 301 the losers into the winner. This fixes keyword cannibalisation as a side effect of the redesign, which is free value most teams leave on the table.
  3. Retire. Pages with zero impressions, zero conversions, and zero backlinks over twelve months. Redirect to the most relevant surviving parent, or let them 410 if there is genuinely no equivalent. Do not redirect them to the homepage.

This exercise usually shrinks a site by twenty to forty percent, and that is a good outcome. Fewer, stronger pages is the correct shape. Just make sure the shrinking happens on paper with data in front of you, not in a design review because someone thought the menu looked crowded.

Operator mapping old URLs to new URLs by hand in a notebook beside a laptop
The redirect map is the single highest-leverage document in a migration, and it is almost always built too late.

How do you build a redirect map that actually works?

Take the full crawl of old URLs, put them in column A, and map each one to its closest equivalent new URL in column B. Every old URL gets a row. Use permanent 301 redirects, one hop only, and never point a batch of unrelated pages at the homepage.

The five rules

  • 301, not 302. A 302 signals a temporary move and passes authority far less reliably. Use 302 only when the move is genuinely temporary.
  • One hop. Old URL goes straight to final new URL. Chains of two or three redirects waste crawl budget and leak equity at every step. This is the most common error in migrations that were done in stages.
  • Closest match, not nearest ancestor. A blog post about Airbnb pricing should redirect to the new Airbnb pricing post, not to /blog/. Redirecting to a category page is treated as a soft 404 by Google when the content is not equivalent.
  • Never mass-redirect to the homepage. Google explicitly treats irrelevant homepage redirects as soft 404s. You get the worst of both outcomes: the old page is dead and the redirect passes nothing.
  • Keep the map forever. Store it in the project folder. Two years from now, someone will need to know why /old-page/ resolves the way it does.

What good and bad mapping looks like

Old URLWrongRight
/services/web-design-calgary/301 to /301 to /services/website-packages/
/blog/2023/airbnb-pricing-tips/301 to /blog/301 to /airbnb-pricing-guide/
/team/former-employee/404301 to /about/
/old-service-we-discontinued/301 to /301 to the closest current service, or 410 if none exists

On WordPress, implement redirects at the server level in .htaccess or Nginx config where you can, and use a plugin like Redirection only for the long tail. Plugin-based redirects run through PHP on every request, which adds latency to exactly the pages you are trying to make faster.

What breaks silently during a redesign?

The visible breakages get caught in QA. The expensive ones are invisible in a browser: metadata that did not carry over, schema that was attached to the old theme, internal links that were never rebuilt, and images that lost their alt text and filenames.

Metadata and headings

Title tags and meta descriptions frequently live in the theme or in a plugin that is being replaced. Migrating from one SEO plugin to another, or from a page builder to blocks, can silently wipe them. Crawl the staging site and diff titles, meta descriptions and H1s against the old crawl. Anything that changed should have changed on purpose.

Watch heading hierarchy in particular. Designers set heading levels by visual size. If your new page has three H1s because the headline, the section title, and the stat block all use the largest type style, fix it. One H1 per page, then a logical H2 and H3 structure.

Structured data

If your old theme output LocalBusiness, Article, FAQPage or Product schema, confirm the new build still does. Run every template type through the Google Rich Results Test on staging: homepage, service page, blog post, contact page, and any listing template. Rich results are one of the few things that visibly disappear from the SERP the week they break.

Internal links inside body content

Crawl the old site, filter to internal links found in body copy rather than navigation, and rebuild that layer deliberately. Every protected page should have at least three contextual internal links pointing at it from other pages. This is the cheapest ranking lever available during a rebuild and almost nobody uses it.

Images, filenames and alt text

A media library migration often renames files or strips alt text. If you get image search traffic, that is a real loss. It is also the moment to convert to modern formats, since you are touching every image anyway. Serving WebP or AVIF instead of oversized JPEGs is usually the single largest speed win available in a redesign.

Speed regressions from the design itself

New sites are often slower than the ones they replace. Video heroes, three webfont families, a scroll animation library, and a live chat widget will each add weight. Set a performance budget before design starts and hold it: LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1, measured on a mid-range mobile device on a real connection, not on a desktop over office fibre.

The launch day checklist

Run this in order on launch day. It takes about ninety minutes and it is the difference between a clean migration and three months of forensic work.

  1. Confirm the Discourage search engines setting is OFF in Settings, Reading.
  2. Fetch /robots.txt on the live domain and confirm it does not contain Disallow: /.
  3. Spot-check canonical tags on five templates. They must point to the live domain, not staging.
  4. Crawl the live site fresh. Zero unintended 404s, zero redirect chains, zero pages returning 500.
  5. Run your full redirect map through a bulk status checker. Every row should return a single 301 landing on a 200.
  6. Confirm HTTPS everywhere and that HTTP and www variants both resolve to one canonical version.
  7. Regenerate and submit the XML sitemap in Google Search Console and Bing Webmaster Tools.
  8. Verify analytics is firing. GA4 tag present on every template, conversion events tested end to end, including form submissions and phone taps.
  9. Test every form. Send a real submission and confirm it arrives in the inbox and the CRM.
  10. Validate schema on each template type with the Rich Results Test.
  11. Run PageSpeed Insights on mobile for the homepage, a service page and a blog post. Compare to your baseline.
  12. Use the URL Inspection tool on your five most valuable pages and request indexing.

What happens in the 90 days after launch?

Expect a settling period of roughly two to six weeks while Google recrawls, reprocesses redirects, and reassigns signals to the new URLs. Some fluctuation is normal and is not evidence of failure. Judge the redesign at day 90 against your baseline, not at day 7 against your feelings.

Week 1

  • Check Search Console Page Indexing daily. Watch for spikes in Not found (404), Redirect error, Blocked by robots.txt, and Excluded by noindex tag.
  • Recrawl the site every couple of days and fix new 404s as they appear from pages you missed.
  • Monitor GA4 landing pages against the same period last month. Look for individual pages that went to zero, which points to a mapping error rather than a general decline.

Weeks 2 to 6

  • Compare Search Console query data to the baseline export. Queries that dropped out entirely are your priority list.
  • For each lost query, open the page that used to rank and check content parity. Nine times out of ten a section was cut.
  • Reach out to your highest-value backlink sources and ask them to update to the new URL. Redirects work, but a direct link is stronger.

Day 90 review

Put the before and after side by side: total clicks, total impressions, average position on your top twenty queries, conversion rate, and Core Web Vitals. A well-executed redesign should show flat-to-up organic traffic and a meaningfully better conversion rate, because the design work is doing its job while the SEO work protected the floor. If organic is still down more than ten percent at day 90, the cause is almost always redirects or content parity, not Google.

Common mistakes

  • Launching on a Friday. Nobody is watching the weekend and by Monday you have lost three days of detection time. Launch Tuesday morning.
  • Redesigning and replatforming at once. New design plus new CMS plus new domain plus new hosting means when something breaks you cannot tell which change caused it. Sequence them.
  • Deleting the old site immediately. Keep a full backup and the old crawl for at least six months. You will need it.
  • Skipping the baseline. Without it, any argument about whether the redesign helped is a matter of opinion.
  • Treating a rebrand and a redesign as the same project. If the domain is also changing, that is a domain migration with its own additional steps, including a Change of Address in Search Console.
  • Panicking in week two. Reverting a migration halfway through the settling period causes more damage than the original drop.

What does a safe redesign cost in Canada?

A professionally managed redesign with a proper SEO migration typically runs $6,000 to $25,000 in Canada, driven mostly by page count, integrations, and how much content needs rewriting rather than by the visual design itself. The migration work adds roughly ten to fifteen percent to a build, and it is the cheapest insurance in the project.

ScopeTypical range (CAD)What is included
Small business, 8 to 15 pages$6,000 to $12,000Design, build, redirect map, content parity pass, launch QA
Established site, 30 to 80 pages plus blog$12,000 to $25,000Above plus content consolidation, schema rebuild, internal link architecture, 90-day monitoring
Migration-only rescue on an existing rebuild$1,500 to $5,000Redirect audit, parity diff, indexation fixes, recovery plan

If a quote does not itemise the redirect map, the content parity check and post-launch monitoring, that work is not happening. Ask for it explicitly. Our website packages include migration as standard, and ongoing indexation and rankings monitoring sits inside the website growth packages rather than being sold as an emergency later.

Two related reads if you are earlier in the decision: website speed optimization for Canadian businesses covers the performance budget side of a rebuild, and managing multiple WordPress sites covers the maintenance stack that keeps a new build from decaying.

Frequently asked questions

How long does it take to recover traffic after a website redesign?

If URLs stayed the same and content parity was maintained, there is often no dip at all. If URLs changed, expect two to six weeks of fluctuation while Google processes redirects and reassigns signals, with full stabilisation by around day 90. Larger sites take longer simply because recrawling every URL takes longer.

Should I keep my old URLs in a redesign?

Yes, unless there is a concrete reason to change them. Keeping URLs identical removes the single largest source of migration risk. Change them only when the existing structure is genuinely harmful, for example dates in blog URLs you want gone or a category structure that no longer reflects the business. Cosmetic tidiness is not a good enough reason.

Do I need to resubmit my sitemap after a redesign?

Yes. Regenerate the XML sitemap so it lists only live, canonical, indexable URLs, then resubmit it in Google Search Console and Bing Webmaster Tools on launch day. Also use URL Inspection to request indexing on your most valuable pages rather than waiting for a natural crawl.

Can a redesign improve my rankings rather than just protect them?

It can, through three mechanisms: faster Core Web Vitals, consolidation of thin competing pages into stronger single pages, and a deliberate internal linking structure that funnels authority to your money pages. Those gains come from the migration work, not the visuals. A prettier site with the same technical foundation will not move rankings on its own.

What if I already relaunched and traffic dropped?

Work the causes in order. First confirm the site is indexable, checking the noindex setting, robots.txt and canonicals. Second, crawl for 404s and fix the redirect map. Third, compare the current pages against an archived copy of the old ones for missing content. Fourth, rebuild internal links. Most recoveries land within four to eight weeks of the fixes going live.

The bottom line

Treat the migration as a deliverable with a named owner, not as a task that happens automatically because the developer is competent. Baseline, map, parity, QA, monitor. Five steps, and they protect years of compounding work.

If you are planning a rebuild and want the migration handled properly from day one, look at our website packages, or tell us about your project through the intake form and we will scope the redirect and content parity work before anyone opens a design file.