Migrating a Fleet Website Without Losing Search Visibility

A website migration loses search visibility for one dominant reason: pages move or disappear and nothing tells search engines where they went. Everything else is secondary. Google documents the process for site moves with URL changes and the role of permanent redirects, and a migration that follows it generally carries existing rankings across, while one that skips the mapping step usually does not. This article sets out the process in order, from the inventory taken before anything changes to the monitoring that runs for weeks afterwards, framed around the specific structure a fleet or hire site tends to have.

Start with an inventory, not a design

The first sentence answers it: the inventory comes first because a redirect map can only cover URLs somebody wrote down. Every migration that loses pages lost them because nobody knew they were there.

Build the list from several sources, because no single source is complete. The existing sitemap, if there is one and it is current. A crawl of the live site, which finds everything linked internally. Analytics, which finds pages that received visits including ones not linked from anywhere. Search Console, which finds pages search engines know about including ones that no longer exist. And server logs where available, which find the pages being requested by anything at all.

What the union of those sources catches

Orphan pages that were linked from a newsletter three years ago. Landing pages built for a campaign and never linked. Old depot pages for sites that closed. Legacy article URLs from a previous content system. Individually these are small. Collectively they are usually a third of the inventory on a site more than a few years old, and they are disproportionately the ones with external links pointing at them.

Record what matters about each URL

For each URL note the current address, the page type, whether it has external links, and whether it has traffic. Those four facts drive every decision afterwards. A depot page with external links and traffic is a must-map. A duplicated tag archive with neither is a candidate for consolidation.

Decide the URL structure deliberately

The default position should be to keep the existing URLs. This is unpopular advice because new structures usually look better, but the trade is asymmetric: the gain from tidier URLs is modest and the risk from moving several hundred of them is real.

Change the structure when it is genuinely causing a problem. Symptoms that justify it include URLs containing session identifiers or query strings that generate near-infinite variants, structures so deep that the hierarchy is unreadable, or a scheme where the same page is reachable at several addresses. Google’s guidance on consolidating duplicate URLs is relevant here, and a structure that generates duplicates is worth fixing.

If you do change it, change it once

A migration that changes the domain and the URL structure and the content and the platform all at once is four experiments with one result. Where the choices can be separated, separate them. Where they cannot, accept that the settling period will be longer and that diagnosing a problem will be harder.

Keep the patterns predictable

Whatever structure you land on, make it derivable. A depot page at a predictable path, a vehicle class page at a predictable path, an article at a predictable path. Predictable patterns make the redirect map generatable rather than hand-typed, which is the difference between a reliable map and a long afternoon of copying.

Build the redirect map

The map is a list with two columns: every old URL, and the new URL it should lead to.

Google documents permanent redirects as the strongest signal that a page has moved for good, and that is the type to use for a migration. Temporary redirects tell search engines the move is not permanent, which is precisely the opposite of what a migration means.

Map to the closest useful equivalent

The rule that matters is that the redirect target should be useful to the person who followed the old link. A closed depot page redirects to the nearest operating depot, not to the depot index and certainly not to the home page. A retired vehicle class redirects to the closest class you still run. An old article redirects to the article that replaced it.

Redirecting everything to the home page is the most common shortcut and the most damaging. It is functionally equivalent to deleting the page from the reader’s point of view, because they arrive somewhere that does not answer their question and leave.

Where there is genuinely no equivalent

Some pages have no successor. A page about a service you no longer offer, for instance. For those, the honest answer is to let the URL return a not-found response and to make that page useful: a search box, the main destinations, and the fleet type index. A well-built not-found page turns a dead end into a navigation step, which is the entire point of building one properly.

Avoid chains

A redirect that points at a URL that itself redirects is a chain, and chains accumulate quietly through successive migrations until a request takes four hops. Flatten the map so every old URL points directly at the final destination. This is easy to check programmatically and easy to forget.

The launch-day checks

More migrations are damaged in the first hour after launch than in the three months of planning before it. The checks are short.

The robots file. A staging environment usually blocks crawlers. Shipping that file to production blocks the entire site. Google’s introduction to robots.txt covers the syntax; the migration issue is simply that the production file must be the production file.

Indexing directives. Staging templates frequently carry a site-wide noindex. Render several pages of different types in production and read the actual output rather than trusting the template.

Canonicals. Check that the canonical URL on each page type points at itself on the new domain, not at the old domain and not at the staging host. A canonical pointing at a site that no longer exists is a quiet, total failure.

Redirects. Test a sample from every page type, not just the home page. Confirm the status code is a permanent redirect and the destination is the intended one.

The sitemap. Submit the new sitemap. Google documents sitemaps as a way to tell search engines about your pages, and after a migration it is the fastest route to getting the new URLs discovered.

Keep the old sitemap available briefly

There is a case for leaving the old sitemap accessible for a short period after launch, because it encourages crawlers to revisit the old URLs and therefore to discover the redirects. Remove it once the old URLs have been recrawled.

Monitoring, and how to read it

After launch the temptation is to check everything daily and to draw conclusions from the first movement. Resist it.

Search engines have to recrawl the old URLs before they can see the redirects, and how quickly that happens depends on how often your site was being crawled before. For a modest fleet site that can be weeks rather than days. During that period the reported numbers will be noisy in both directions.

What to watch

The page indexing report tells you which URLs are indexed and which are not, with reasons. After a migration the useful signal is the shape of the change: old URLs moving into a redirect category, new URLs moving into indexed. Errors appearing in volume mean a template problem and are worth acting on immediately.

Watch for server errors and not-found responses in the logs, because those are the URLs your map missed. Every one of them is a page that existed, was requested, and now leads nowhere. This is the single most valuable post-launch feedback loop and it is available immediately, unlike the search reports.

When to intervene

Intervene immediately for anything structural: a template-level directive error, a large batch of not-found responses, a canonical pointing at the wrong host. Wait for anything positional. A ranking that moved in the first fortnight has not settled, and reacting to it usually means changing something that was about to recover on its own.

The parts specific to a fleet site

Two things about this category deserve separate attention.

Depot pages carry local signals. A depot page that moves URL is the page most likely to be the target of an external link from a local directory, a supplier listing or a partner. Prioritise them in the map and check them individually rather than as a batch.

Vehicle class pages are frequently consolidated. A rebuild often merges several thin class pages into fewer stronger ones, which is usually correct. Map every merged URL to the page that now covers it, and make sure the destination page genuinely covers the class the old URL was about. A merge that leaves a class unmentioned turns a redirect into a dead end with extra steps.

Content that should not survive the migration

Not everything deserves to be carried across. Thin tag archives, duplicate print pages, old campaign landing pages for offers that ended. Consolidating those is part of the improvement, and consolidating is not the same as deleting: the URL still redirects, it simply redirects to the page that now covers the subject.

A timeline that works

Migrations go wrong under time pressure more than for any technical reason, so it is worth naming a sequence that leaves room to check things.

Four weeks out. Take the inventory. Crawl the live site, export the analytics list, export the Search Console list, pull the log files. Deduplicate into one sheet. This is the only step that cannot be compressed, because everything after it depends on the list being complete.

Three weeks out. Decide the URL structure and build the map. Generate it where the patterns allow and hand-check the exceptions. Review the map with someone who knows the business rather than the site, because they will spot the depot that moved two years ago and the class that was renamed.

Two weeks out. Build the redirects in the staging environment and test them there. Testing redirects for the first time in production is how launch day turns into a long night.

One week out. Freeze content changes on the old site. Every edit made after the inventory is a row that may not be in the map. Run a final crawl to catch anything added since.

Launch day. Deploy, then run the five checks in order: robots file, indexing directives, canonicals, redirect samples, sitemap submission. Nothing else happens until all five pass.

The week after. Read the logs daily for not-found responses and server errors. Fix the map where it missed. Ignore rankings entirely.

Weeks two to eight. Read the index reports weekly. Act on structural errors, ignore positional movement.

Do not launch on a Friday

It sounds trivial and it is the most reliable piece of advice in the list. The checks above find problems, and problems need someone available to fix them. A migration that launches on a Thursday morning gets two working days of attention before anyone is away from their desk.

What to fix while everything is open anyway

A migration is the one moment when changing the structure of the site is cheap, because it is being changed regardless. It is worth having a short list of things to correct at the same time.

Redirect chains inherited from previous migrations can be flattened as part of building the new map, since every old URL is being looked at anyway. Duplicate entry points, where the same page is reachable with and without a trailing slash or with and without a prefix, can be collapsed to one canonical form and redirected. Pages that were split for no reason can be merged, and pages that were merged into something unreadable can be split.

The discipline is to keep this list short and structural. A migration is not the moment to rewrite every page, because if visibility does move you will have no way to tell whether the cause was the URLs or the content. Change the plumbing during the migration and the prose afterwards, and you keep the ability to diagnose what happened.

Changing platform, domain and structure are three different moves

People say migration to mean at least three separate things, and they carry very different risk.

A platform change rebuilds the site on different technology while keeping the same domain and the same URLs. This is the lowest risk version by a wide margin: from the outside almost nothing has moved, so there is very little for a search engine to reprocess. If the URLs genuinely stay identical, most of this article is precaution rather than necessity.

A structure change keeps the domain but moves pages to new paths. This is the case the redirect map exists for, and the one where the quality of the mapping decides the outcome.

A domain change moves everything to a new hostname. Google documents this case specifically and the mechanics are the same, with the addition that the change of address needs to be declared in Search Console and that the old domain has to keep serving redirects for a long time afterwards. Not months. Years, if you can, because external links do not get updated.

Doing more than one at once

Sometimes there is no choice: a rebrand forces a domain change at the same time as a rebuild. When that happens, the practical mitigation is to keep the URL paths identical across the domain change even if you would have improved them, so that exactly one variable has moved. Improve the paths in a separate, later change once the domain move has settled.

Keep the old domain alive

The most expensive mistake in a domain move is letting the old registration lapse once traffic looks fine. Every external link pointing at the old domain flows through it, and those links are the ones you cannot rebuild. Keeping a domain registered is the cheapest insurance available in this whole exercise.

Plan for the settling period

The last piece is organizational rather than technical. Whoever signs off the migration should know in advance that there will be a period of movement and that it is expected. Migrations get reversed, or panic-patched into a worse state, because nobody set that expectation and the first bad week looked like a failure.

Agree in advance what would constitute a real problem: a large volume of not-found responses, a template-level indexing error, a sustained decline past the settling window. Anything else is noise, and treating noise as signal is how a well-executed migration gets undone.

If you are planning one, the fleet website redesign page sets out how the mapping and redirect work is handled as part of the build rather than as an afterthought, and the pricing page covers what the ongoing plan includes once the new site is live. For the structural decisions the new site should make while you have the chance, the article on depot page structure covers the part most migrations get wrong twice.