I have moved a lot of dealerships onto new websites, and the same worry comes up every time. We are ranking now. If we rebuild, do we lose it?
It is a fair question. Migrations do go wrong, and when they do the damage is real and takes months to undo. But they go wrong for boring, preventable reasons rather than mysterious ones. Here is the order I work in.
Crawl the old site before you touch anything
You cannot preserve what you have not written down. Before any rebuild starts, crawl the existing site and get a complete list of its pages. Screaming Frog will do this free up to 500 URLs, which covers most dealer sites.
Do this first. Once the old site is switched off, this information is gone, and reconstructing it from memory does not work.
Find out which pages actually matter
Not every page deserves saving. Export your top pages from Google Search Console over the last twelve months, and your top landing pages from Analytics.
What you usually find is that a small number of pages do nearly all the work. A few inventory pages, maybe a financing page, the homepage, and one blog post somebody wrote years ago that quietly ranks for something valuable. Those are the pages to protect. The other two hundred matter far less.
Map old URLs to new ones
This is the step that decides whether the migration succeeds. Build a spreadsheet with every old URL in one column and its new destination in the next.
Every page falls into one of three buckets. It has a direct equivalent on the new site, in which case map it there. It has been merged into another page, in which case map it to that one. Or it genuinely has no replacement.
Two rules I would not bend. Do not map everything to the homepage as a shortcut, because Google treats a redirect to an irrelevant page as a soft 404 and you get no benefit. And do not skip a page just because it is inconvenient to think about.
Use permanent redirects, and check the chains
Every mapped URL needs a 301 redirect, which tells search engines the move is permanent and passes the accumulated value to the new address. A 302 says temporary and does not.
Watch for chains. If an old URL redirects to a second URL which redirects to a third, that is wasteful and fragile. Point each old URL directly at its final destination.
Test the redirects before launch, not after. On a staging site you can verify each one resolves to a live page rather than an error.
Bring the content that earns its keep
There is a temptation in a rebuild to start fresh and write everything again. Resist it for the pages that are ranking. If a page brings in buyers, the words on it are part of why. Improve it, restructure it, make it faster, but do not casually delete it.
This applies especially to the boring pages. A plainly written page answering financing questions may look dated next to your new design and still be the thing bringing you buyers every month.
Keep one preferred domain
Decide whether your site lives at the www version or without it, and make everything point at that one consistently. Same for HTTP and HTTPS: everything should end up on HTTPS.
What you do not want is the same page reachable at four addresses. It splits your signals and makes reporting harder to trust.
Update canonicals and internal links
Every page on the new site should have a canonical tag pointing at itself, in its final form: HTTPS, preferred domain, correct trailing slash.
Then fix the internal links. If your new pages link to old URLs that now redirect, every one of those is an unnecessary hop. Links inside your own site should point at final destinations.
Build a clean sitemap
Your new XML sitemap should list only pages you want indexed, in canonical form, each returning a 200 status. No redirected URLs, no noindex pages, no drafts, no error pages.
A sitemap full of redirects and dead pages is worse than useless, because it teaches Google that your sitemap is unreliable.
Do the Search Console work on launch day
Once the new site is live, submit the new sitemap in Google Search Console and use the URL Inspection tool on your most important pages to request indexing. Do not wait to be discovered.
If your domain has changed, use the Change of Address tool. If only the site changed and the domain has not, you do not need it.
Watch the first month properly
Some fluctuation after a migration is normal. Google has to recrawl everything and work out what moved where, and that takes weeks rather than days.
What you are watching for is the difference between settling and a genuine problem. Check the Coverage report for a spike in 404s, which means redirects were missed. Watch impressions rather than positions, because impressions recover first. And keep an eye on which pages are being crawled.
Give it a month before drawing conclusions, and keep the old crawl file so you can diagnose anything that went missing.
The mistakes I see most
- Launching first and thinking about redirects afterwards.
- Redirecting everything to the homepage.
- Leaving the staging site set to noindex and shipping that setting to production. This one is common and it is catastrophic.
- Deleting content that was ranking because it looked old.
- Forgetting that images and PDFs have URLs too.
- Never checking Search Console again after launch week.
What you should expect from a provider
If a website company cannot tell you how they will handle redirects, that is your answer. Ask before you sign: will you crawl our existing site, will you map every URL, will you put 301s in place, and will you check Search Console after launch?
Nobody can guarantee your rankings will be untouched. Search results move for reasons that have nothing to do with your website. What a competent migration does is remove the preventable causes, which is most of them.
The thing worth weighing is the other side of the ledger. Staying on a slow, dated website has a cost too. It is simply a quieter one, spread across every buyer who left without telling you.