Skip to content
Start an assessment
Fog lifting off layered forested ridges at dawn
We broke our own site four ways. None of them showed in a browser.

How to redesign a website without losing SEO

Most traffic lost in a redesign is lost to mechanical mistakes, not to the new design. Here are the four we made on our own launch, how long each took to find (8 to 24 days), and the checklist we now run before any site goes live.

Check my redesign plan ↓Skip to the checklist
Aric Sangchat, founder of ArocBy Aroc · Updated 24 October 2026 · Every date and number is from our own records
The short answer

To redesign a website without losing SEO, keep every URL that already earns visits, and send each URL that changes to its closest equivalent page with a single permanent redirect. Make sure every new page declares itself as its own canonical, list only the final URLs in the sitemap with honest dates, and compare Search Console before and after, page by page.

Check all of it in the HTML the live site actually serves, not in the code or the CMS settings. Each of our four mistakes looked correct in the code.

1 hop per redirectself-canonical on every pagehonest sitemap datescompare by page, not average
Risk check · 6 questions

Is your redesign about to cost you traffic?

Six questions, about a minute. You’ll see your result straight away; no email needed.

0 of 6

01Will any page addresses (URLs) change?
02Is there a written list matching every old URL to its new one?
03Has anyone checked which current pages bring in search traffic?
04Will someone check the new site for a “noindex” tag or a blocked robots file before launch?
05Will someone check each page's canonical tag in the live HTML, not just in the settings?
06Is analytics and enquiry tracking set up on the new site before the old one goes?

Why a website redesign loses search traffic

Search engines rank pages, not websites. A redesign changes the address, the content or the technical signals of many pages at once. Each change gives Google a reason to re-evaluate, and a mistake on any one of them can quietly remove a page that used to bring in customers.

The design itself is rarely the problem. The losses come from the plumbing: addresses that change without a redirect, pages that accidentally tell Google to ignore them, and content that’s removed without anyone noticing it was the part that ranked.

A sourced range, with a caveat. Industry estimates put the typical loss at 20–40% of search traffic in the first months when a site moves without a redirect plan, and a 5–15% dip that recovers when the move is handled well. These are rough ranges from trade press and agency reports; we couldn’t find a primary study behind them.

What broke when we redesigned our own site

On 3 August 2026 we replaced the old arocwebdesigns.com with a new site: twelve new pages went live, and six old addresses were retired behind permanent redirects.

Our site was small, and the old traffic was meant to go. We had changed what the company sells, and we wrote down beforehand that the old pages’ impressions would fall. So this isn’t a story of clawing back lost traffic. It’s a list of mechanical faults that would have cost a site with real traffic a great deal, found on a site where they cost very little.

  1. 3 Aug · Day 0New site live. Six old URLs retired behind permanent redirects.
  2. 11 Aug · Day 8Fixed: nine pages had been telling Google they were the homepage.
  3. 21 Aug · Day 18Fixed: six of eight redirects were two-step chains.
  4. 24 Aug · Day 21Fixed: nineteen pages shared the homepage’s preview card.
  5. 27 Aug · Day 24Found: sitemap dates had stopped signalling changes.

Four faults, in the order we found them

Fault 1 · Found on day 8

Nine pages told Google they were the homepage

What happened
Every page has a canonical tag naming its official address. Ours was set once, in a shared layout, so nine pages (including Assess, Build and Grow) each declared the homepage as their official address. In effect we asked Google to ignore them. Until the fix, the homepage was the only page on the site eligible to rank.
Why it was hard to see
The code looked right, and searching the code for “canonical” turned up the word in ordinary paragraph text on two pages, which looked like a pass. Only the HTML the server actually sent showed the fault.
The fix
Each page now declares itself, and a test reads the built pages and fails if any page names another as canonical.
<link rel="canonical" href="https://arocwebdesigns.com/"> ← on /assess

Check yours: Open any page, view the source and find rel="canonical". Does it show that page’s own address?

Fault 2 · Found on day 18

Six of eight redirects took two hops instead of one

What happened
The redirects pointed at addresses ending in a slash (/grow/), but the site serves them without one (/grow). So each old address redirected once to the slash version, then again to the real page.
How we noticed
Eighteen days after launch, one retired page still carried 65% of the site’s search impressions, at its old position. Google hadn’t processed its redirect yet. We can’t prove the chain was the cause, but removing it was free.
The fix
Every redirect now resolves in exactly one step, and a test fails if a chain comes back.
/phuket-seo → 308 → /grow/ → 308 → /grow

Check yours: Put an old URL into any redirect checker. Does it reach the new page in one step?

Fault 3 · Found on day 21

Every page shared the homepage’s preview card

What happened
The title, description and link shown when a page is shared (on LinkedIn, Facebook or in a message) were inherited from the homepage. Nineteen pages, one identity.
Why it matters
It doesn’t move rankings directly. But every shared link misrepresented its page, and any service that reads these tags got the homepage’s description instead of the page’s own.
The fix
Each page now generates its own from its title and description, and a test checks all of them.

Check yours: Paste a page link into a LinkedIn post draft. Does the preview show that page, or your homepage?

Fault 4 · Found on day 24

The sitemap stopped telling Google when pages changed

What happened
A sitemap can tell search engines when each page last changed. Ours gave every page the launch date by default. Six pages then had their copy changed and kept the old date, so the change notices we send to search engines never went out for them.
What we learned
An honest date matters, but it’s a weak signal on its own. One page with a corrected date went 21 days without being recrawled; another was recrawled within about three hours of getting a link from a page Google already visits.
The fix
Dates change only when visible text changes, and new pages get links from existing pages on the day they launch.

Check yours: Open /sitemap.xml. Do the dates match when pages actually changed?

None of the four was a design decision. All four were invisible in a browser, and all four looked right in the code.

Launching in the next 90 days?

We found each of these 8 to 24 days after our own launch. On a site with real traffic and enquiries, that’s weeks of lost business. If your redesign is in progress, run the risk check, or tell us what’s changing and we’ll tell you where it’s likely to break.

Run the risk check ↑Talk about your redesign →

How long Google took to catch up

The retired pages faded out over about three weeks. By the third week after launch, no retired page and no query for the old service recorded a single impression. That matched what we’d written down before launch. It’s a prediction coming true, not a gain, and it’s in our own growth report with the rest of the numbers.

Expect weeks, not days, and don’t judge the new site by its first fortnight. Compare groups of pages, not the site average. When a weak group of pages disappears, the average position improves without anything actually ranking better. What an SEO audit cannot tell you explains why.

Impressions on the largest retired page
Impressions on the largest retired page, 2026
WindowImpressions
15 Jul – 3 Aug (before launch)87
8 – 13 Aug31
17 – 23 Aug0

The website redesign SEO checklist

Sixteen steps: ten before launch, six after. Tick them off as you go; this page remembers your progress on this device.

Before launch

After launch

What a redesign cannot fix

A redesign protects the search visibility a site already has, but it doesn’t create demand. If the old site wasn’t bringing in customers, the cause may not be the design at all. Does my website need a redesign? walks through that decision, and the Aroc Growth System is how we find the stage that’s actually breaking.

Questions people ask about redesigns and SEO

Will redesigning my website hurt my SEO?

It doesn't have to. Most losses come from changed URLs without proper redirects, pages that accidentally tell Google to ignore them, and content that was removed. Handled carefully, a dip of a few weeks is normal, and it recovers.

Should I use a 301 or a 308 redirect?

Either. Both are permanent, and Google treats them the same. What matters more is one hop, to the right page.

How long does Google take to process redirects?

It depends on how often Google crawls your site. On our small site, the retired pages took about three weeks to drop out of search.

Can I change my URLs during a redesign?

Yes, if each old URL redirects to its true equivalent. But a URL that already ranks is worth keeping if you can.

Protect what already works before anything goes live

We’re redesigning anywayHow we handle a redesign

We protect what already ranks, then rebuild what doesn’t work.

Not sure we shouldStart with Assess

$950, fixed. Find out whether the website is the problem before you rebuild it.

Sources

  1. Aroc launch record, 3 August 2026.
  2. Canonical fix, 11 August 2026.
  3. Redirect-chain fix, 21 August 2026.
  4. Share-preview fix, 24 August 2026.
  5. Sitemap-date finding, 27 August 2026, and recrawl observations.
  6. Retired-page impressions: Aroc’s growth report, 26 August 2026.
  7. Typical-loss ranges: trade press, e.g. Search Engine Land, “Recovering SEO traffic and rankings after a website redesign”.
Aric Sangchat, founder of Aroc
Aric SangchatFounder, Aroc

Built enterprise front-ends for Wells Fargo and Esurance at Manifest (2015–18) before running his own businesses.

About Aric →
New articles by email

Get every new article by email

One email when a new article is published: the finding, the numbers and the link. No filler, and you can unsubscribe in one click.

We’ll email you when a new article is published. Unsubscribe any time. Privacy policy