The scenario: a family-run flooring retailer, twenty-two years in business, with a website built in 2015 on a page builder that has since been abandoned by its developer. It is slow, it is unreadable on a phone, and nobody can edit it because the person who built it moved provinces.
It also ranks. Not brilliantly, but it has a decade of accumulated links and history, and it produces a steady handful of enquiries a month. That history is the asset most rebuilds destroy.
Phase 1: inventory (before anything else)
About three hours, and it determines whether the project succeeds.
- 01Crawl the old siteA full crawl produces every URL, title, meta description, heading and internal link. The free tier of a desktop crawler covers 500 URLs, which is plenty here. This example produced 47 real pages plus 180 junk URLs generated by the builder's pagination and tag archives.
- 02Export Search Console dataSixteen months of query and page data. This shows which pages earn impressions and clicks, and which have quietly never been seen by anyone.
- 03Export analytics landing pagesTwelve months, sorted by sessions. Combine with the Search Console list and de-duplicate.
- 04Find external linksSearch Console's Links report lists pages other sites link to. In this example: the home page, a page about subfloor preparation from 2017 that a trade association had linked to, and — unexpectedly — a PDF price list from 2019. All three needed to survive.
- 05Screenshot everything that mattersRankings, traffic by page, and the current Core Web Vitals. This is the baseline you will be judged against, and after launch nobody remembers what it was.
Phase 2: decide what survives
Forty-seven pages went into a spreadsheet with four columns: URL, sessions, impressions, decision. Four decisions were available.
| Decision | Count | Applies when |
|---|---|---|
| Keep — same URL, rewritten content | 12 | The page has value and the URL is sensible |
| Merge — into a stronger page, redirect | 19 | Several thin pages cover one topic |
| Redirect — to the closest equivalent | 9 | Content is obsolete but the URL has links or traffic |
| Remove — return 410 Gone | 7 | No traffic, no links, no reason to exist |
The 180 junk URLs from the builder's tag archives were left to 404. They had no traffic, no links and no purpose, and adding 180 redirects for them would create clutter that outlives the project.
Phase 3: content migration
The temptation in a rebuild is to rewrite everything. Resist selectively: pages that rank are ranking for a reason, and a total rewrite can lose the relevance that earned it.
- Pages that rank well: keep the structure, headings and key phrasing. Improve readability, add the FAQ block, fix the title tag. Do not start from a blank page.
- Pages that rank badly: rewrite freely. They have nothing to lose.
- Merged pages: combine into one comprehensive page, keeping the strongest headings from each so the merged page covers everything the originals did.
- Everything: add what was missing across the whole old site — prices, process, real photos, and questions the sales team answers daily.
Phase 4: build and pre-launch checks
- Staging site blocked from indexing — and a written note to remove the block before launch.
- Every mapped URL exists on the new site, or has a redirect rule written for it.
- Titles and meta descriptions written for all 21 surviving pages, none duplicated.
- LocalBusiness schema added, with the store address and hours.
- All images resized, compressed and converted to WebP. The old site's 4 MB hero became 180 KB.
- Core Web Vitals tested on staging with a throttled connection.
- Forms tested from a phone on cellular data.
- The 2019 PDF re-uploaded at its original path — the simplest way to preserve a link is to leave the file where it is.
Phase 5: launch day, in order
- 01Full backup of the old siteFiles and database, downloaded and held locally, before anything changes.
- 02Remove the staging index blockThe single most common rebuild disaster. Check the meta robots tag and robots.txt, then check them again after DNS moves.
- 03Point DNS, leave email aloneMX records screenshotted beforehand and verified afterwards. Website migrations that break email cause more immediate business pain than any ranking change.
- 04Deploy the redirects and test every oneWalk the spreadsheet. Each old URL should resolve to its mapped destination in a single hop, with a 301. Chains lose signal and get truncated.
- 05Resubmit the sitemapNew sitemap submitted, and the old one left in place for a few weeks so search engines re-crawl the old URLs and discover the redirects.
- 06Request indexing for the top pagesHome page and the top five money pages, via URL Inspection.
- 07Update external referencesBusiness Profile, Facebook, directory listings, email signatures. Anywhere the old URL structure was published.
Phase 6: the first month
| When | Check | Expect |
|---|---|---|
| Day 1 | Redirects, forms, indexing block, email | Everything works, or fix immediately |
| Day 2–3 | Search Console coverage | Crawl activity rising, some 404s to investigate |
| Week 1 | Traffic vs baseline | A dip of 10–20% is normal |
| Week 2 | Rankings | Fluctuation, sometimes sharp. Do not act yet |
| Week 3–4 | Traffic and rankings | Recovery beginning, approaching or passing baseline |
| Week 6 | Full comparison | If still meaningfully down, investigate redirects first |
What changed, and why (modelled)
- Pages went from 47 to 21. Fewer, stronger pages beat many thin ones — the site stopped competing with itself for the same queries.
- Mobile became usable. The old site required pinch-zoom, and mobile was the majority of traffic. This alone changes conversion regardless of ranking.
- Load time fell substantially, mostly from image compression.
- Prices were published for the first time. The single most requested piece of information on the site, previously available only by phoning.
- Every page gained an FAQ section, which is where the first new long-tail rankings appeared.
The ranking history survived because of the mapping spreadsheet. That is the whole trick. A rebuild that loses half its traffic and one that comes back stronger are usually the same design work with about four hours of difference, and those four hours are spent on redirects.
Common questions
- Will I lose my Google rankings if I redesign my website?
- Not if URLs are preserved or properly redirected and content quality is maintained. Traffic loss after a redesign is almost always caused by missing redirects, changed URLs without mapping, or an indexing block left over from staging — all avoidable.
- Should I keep my old URLs when rebuilding?
- Where the page genuinely survives as the same page, yes. Every redirect carries a small risk and a small loss. Tidier URLs are rarely worth breaking a decade of accumulated history.
- How long does it take to recover from a website migration?
- Two to four weeks for most small sites, assuming the redirects are correct. If you are still materially down after six weeks, the problem is technical rather than temporary — start with redirect testing and indexing status.
- What is the biggest risk in a website rebuild?
- Launching without a URL map. Everything else is recoverable; a site that has thrown away its redirect plan cannot reconstruct it afterwards, because the old site is gone and with it the record of what used to exist.