Rebuild a website without losing Google rankings
Updated 30 July 2026 · By Alex
Most businesses that rebuild a website are promised a faster, better-ranking site. Then traffic drops in week three.
Short answer: rankings attach to the URL and the content at that URL, not to the design. A rebuild that keeps the same domain, keeps or cleanly redirects every ranking URL, preserves the substantive content and metadata, and holds the internal link structure together will normally come through with its positions intact after a two to six week settling period.
Why rebuilds lose rankings
Almost every loss traces back to one of five causes.
- URLs changed without redirects. The new CMS uses
/services/oven-repairwhere the old one used/oven-repairs. Google has years of signal attached to the old URL and now finds a 404. - Content was trimmed. A designer reduced a 900 word service page to 150 words because it looked cleaner. The page no longer answers the query it used to rank for.
- Metadata was regenerated. Hand-written title tags get replaced by a template like
Page Name | Business Name, discarding the keyword targeting that took years to tune. - Internal links thinned out. The old site linked to a page from six places, the new mega-menu links to it from one. Internal link count is a ranking input, and cutting it demotes the page.
- The staging site got indexed, or the live one got noindexed. A
noindexheader left on at launch will remove a site from the index within days.
All five come from treating a rebuild as a design project.
What carries the rankings
| Carries across | Does not carry across |
|---|---|
| The domain and its history | Your old CSS or template |
| Each URL, if preserved or 301 redirected | The visual design |
| The substantive text on each page | The CMS it was built in |
| Title tags, meta descriptions, structured data | Page load time (this one you improve) |
| Inbound links, if the URL still resolves | Anything behind a login |
| Internal link structure and anchor text | Content you decided to delete |
So you can change stack completely, WordPress to Astro or Wix to a static build, without touching the things that rank. Changing the URLs, the content and the metadata at the same time is what loses rankings.
The migration checklist
Work through this in order. Steps 1 to 4 happen before anything is built.
- Crawl the existing site and export every URL. Screaming Frog's free tier covers up to 500 URLs, which is more than most service businesses have. You need the full list before you can promise to preserve it.
- Pull the pages that earn traffic. In Search Console, open Performance, set the date range to the last 12 months, and export by page. Any URL with impressions is a URL you are now responsible for. Sort by clicks and treat the top 20 as untouchable.
- Export the current metadata. Title tag, meta description and any structured data for every URL that matters. This becomes your acceptance test later.
- Record the internal link count per URL. How many pages link to each important page today. This is the number the new site has to match or beat.
- Build the new site with the old URLs. Where a URL must change, write it into a redirect map as you go.
- Map redirects one hop. Old URL to new URL,
301, never a chain of two or three. Chains leak signal and are slow to crawl. Never bulk-redirect deleted pages to the home page: Google treats that as a soft 404 and it wastes the signal entirely. - Carry the content across before you edit it. Launch with the old copy, then improve it after the dust settles. Rewriting content during a migration means that when something drops you cannot tell whether it was the move or the words.
- Reinstate the metadata and structured data on day one. A page that launches without its title tag loses its main on-page signal.
- Check canonicals are self-referencing. Every page should declare itself canonical unless you have a deliberate reason otherwise. A canonical left pointing at a staging domain removes the site from the index.
- Verify
robots.txtand thenoindexheader before DNS changes. Then verify them again an hour after launch.
The first 30 days after cutover
- Day 0: submit the new sitemap in Search Console. Confirm it reports the URL count you expect.
- Day 1: crawl the live site and confirm every URL in your redirect map resolves with a single hop and a 200 at the end. Fix any chain you find.
- Day 2 to 7: watch the Pages report for a spike in "Not found (404)" or "Page with redirect". More than a few means the redirect map has a gap.
- Week 2 to 4: watch impressions. Positions bounce during recrawl. Impressions stabilising is the signal that the move landed.
- Week 4 to 8: compare Performance data against the same window before the move. Anything materially down gets checked individually against the metadata export from step 3.
If a page has not recovered after eight weeks, the cause is nearly always mechanical: a redirect that did not land, content that got trimmed, or a canonical pointing at the wrong URL.
What this looked like in practice
Alpha Home Appliances is a Sydney appliance repair business with thirty years of trading history and a website that had fallen behind. It was missing Core Web Vitals thresholds and competitors with technically healthier sites were edging ahead on the same suburbs and services.
The rebuild moved the site to Astro with a static-first architecture and very little JavaScript, which is the change that moves the performance numbers. It stayed on the same domain. URLs were preserved where they already ranked, redirects were mapped one hop, canonicals were self-referencing from launch, and structured data went in on day one.
When you should not rebuild
Rebuilding is the wrong answer when the actual problem is content or authority. If a site is technically fine and simply does not rank, a new design will not fix it, and you will have spent the budget that should have gone into the pages themselves. Run PageSpeed Insights and check Search Console for coverage errors. If both come back clean, the rebuild is a branding decision.
If you are weighing this up for your own site, the services page covers what a rebuild engagement involves, and the contact page is the fastest way to find out whether yours needs one.
Frequently asked questions
Will a website redesign hurt my Google rankings?
Only if the migration is handled loosely. Rankings attach to the URL and the content at that URL. A redesign that keeps the same domain, keeps or one-hop redirects every ranking URL, preserves the substantive content and metadata, and keeps the internal link structure intact will normally hold its positions through a two to six week settling period.
How long does it take for rankings to recover after a site migration?
Expect two to six weeks of movement for a small site on the same domain, longer if URLs changed. Watch impressions during that window; they stabilise first. If a page has not recovered after eight weeks, look for a redirect that did not land, content that was trimmed, or a canonical pointing at the wrong URL.
Do I need to keep my old URLs?
Keep them wherever they already rank or already have inbound links. Changing a URL that ranks is the most common way a rebuild loses traffic. Where a URL must change, map it to the closest equivalent with a single 301, never a chain, and never to the home page in bulk.
Should I change domain at the same time as rebuilding?
No. Change one variable at a time. A domain change, a URL restructure and a content rewrite launched together make it impossible to tell which one caused a drop and impossible to roll back cleanly. Move the domain on its own, let it settle, then rebuild.
Want this done on your own site?