Site Migration Consulting

The sequence is the product

Almost every migration that loses traffic loses it for a reason that was preventable in a step nobody ran. Not because someone chose the wrong redirect code, but because there was no complete list of what existed before, so nobody could tell what was missing afterward.

So the deliverable here is a sequence, executed in order, with the earlier steps genuinely completed before the later ones start: a pre-migration baseline and full crawl, a URL mapping, redirect implementation tested on staging, launch-day verification, and post-launch monitoring measured against the baseline. Nothing in that list is clever. All of it is skippable under deadline pressure, which is exactly why it gets skipped.

The engagement is worth buying in proportion to how much of your revenue arrives through organic search and how many URLs are changing. A five-page brochure site moving hosts needs a checklist. A catalog of forty thousand URLs moving platform and domain simultaneously needs the whole sequence, and needs it started before the new site is built rather than the week before it ships. What drives the cost is the same list: total URL count, number of templates, how many systems the redirects have to pass through, whether logs are obtainable, and how many locales carry hreflang annotations that will need rewriting.

Everything is measured before anything moves

The baseline is the step that makes every later question answerable. Without it, a post-launch argument about whether traffic fell becomes a matter of opinion.

• A complete URL inventory, assembled from a full crawl, the XML sitemaps, server log files and Search Console — four sources because each one misses something the others catch. Log files in particular reveal URLs that are still being requested and still earning traffic but are linked from nowhere.
• Search Console performance data, exported. Note the constraints while exporting: the interface and its spreadsheet export cap at 1,000 rows, and data is retained for sixteen months. Whatever is not exported before the move is not recoverable later in the shape you will want it.
• A ranking snapshot, understood as a diagnostic sample rather than a scoreboard.
• Core Web Vitals field data at the 75th percentile, so a slower new site can be identified as slower rather than argued about.
• Revenue and conversions by URL and by template. This is what turns the mapping from an exercise in tidiness into a commercial exercise: the pages that earn get checked first.

The mapping, one row per URL

The mapping is a table with one row for every URL that exists today and the URL it will become. It is tedious, it is the thing people try to automate away, and the automation is where the losses come from.

Three rules make the difference. No unmapped URL that currently returns 200. Every live URL either has a destination or an explicit, recorded decision to be removed — in which case it returns 404 or 410 deliberately, which Google treats as a strong signal not to crawl it again. No dumping to the homepage. Redirecting a retired category to the root because no equivalent exists is a decision to discard whatever that page had earned; if there is genuinely no equivalent, a deliberate 404 is more honest and more useful to a visitor. No pattern rule shipped without spot-checking its output. Regular-expression redirect rules are efficient and they fail silently on edge cases — trailing slashes, uppercase paths, query strings, encoded characters, legacy URLs from two platforms ago.

Internal links get rewritten from the same mapping. Google's guidance on site moves is explicit that internal navigation should point at the new URLs directly rather than relying on redirects to resolve them, and a site whose own menus route through a redirect layer is a site that has kept its old architecture with extra steps.

Redirects: the type, the hop count, and how long they stay

Google's site-move documentation is unusually specific here, and following it removes most of the room for argument.

• Use permanent redirects — 301 or 308. The 308 is named in Google's own guidance and is routinely omitted by practitioners; it preserves the HTTP method where that matters.
• One hop. Googlebot follows up to ten redirect hops, but Google advises redirecting to the final destination directly. Chains accumulate in layers — an old platform rule, a canonicalization rule, a language rule — and each one is latency for every visitor as well as a crawl inefficiency.
• Keep them for at least a year. Google's wording is to keep redirects for as long as possible, generally at least one year, and to consider keeping them indefinitely for the sake of visitors following old links. One year is the floor, not the target.
• The Change of Address tool in Search Console is for domain changes, and must be submitted for all subdomains and both the www and non-www variants. It is explicitly not needed for a move from HTTP to HTTPS — a step that gets performed unnecessarily and causes confusion when it does not behave as expected.

Full details are in Google's documentation on site moves with URL changes.

Staging is where migrations are won, and where they are lost

Before launch, the staging environment gets crawled with the redirect map applied, and every row in the mapping gets tested: the old URL, the response code returned, the number of hops, and the final destination compared against the intended one. A rule that works on the ten URLs someone checked manually and fails on the two hundred that share an edge case is the normal failure, not the exotic one.

Then the failure that causes more damage than every other cause combined: the staging blocker shipping to production. A staging site is correctly kept out of the index with a robots.txt disallow, a noindex tag, HTTP authentication, or all three. On launch night, when the new site is copied over, that blocker travels with it. The site goes live, looks perfect to everyone testing it in a browser, and is quietly instructing search engines to stay away. It is frequently discovered a week later, by which time the damage is real.

So the check runs twice, deliberately: confirm staging is not indexable before launch, and confirm the blocker is gone within minutes of launch. Those are two separate items on the list because they are true at different times.

Launch day, and the first forty-eight hours

A defined sweep, run in order, starting the moment the change is live:

1. robots.txt on production reads as intended, and does not read as staging's.
2. Meta robots tags: nothing carrying noindex that should be indexable.
3. Canonical tags point at the new URLs, not the old ones — a common oversight when templates are copied.
4. Sample redirects tested across every template, not just the homepage and a product page.
5. A status-code sweep of the full mapping, looking for chains, loops, unexpected 302s and anything that landed on a 404.
6. The new XML sitemap submitted, with accurate <lastmod> values rather than the build timestamp on every row.
7. hreflang annotations rewritten to the new URLs where multiple languages or regions exist. A migration silently breaks every return link if these are not updated, and the failure is invisible without deliberate validation.
8. Analytics and conversion tracking firing on the new URLs. This one is listed last and matters first. If tracking breaks at launch, the damage from every other failure becomes unmeasurable — you cannot tell a real traffic loss from a measurement loss, and the argument about what happened never resolves.

Monitoring against the baseline, not against a feeling

For several weeks after launch the same instruments get read on a schedule, and every reading is compared against the numbers taken before the move rather than against the previous week.

The Page Indexing report shows new URLs being indexed and old ones dropping out — both should be happening, and only one of them happening is the signal. Crawl Stats shows the response-code mix and host status across robots.txt fetch, DNS resolution and server connectivity. Search Console performance gets read by page and by query against the export, not as a single traffic line. Server logs and redirect error logs show URLs still being requested that the mapping missed, which is the most reliable way to catch what was overlooked.

Google's own expectation for how long this takes is worth setting with stakeholders in advance: a small to medium-sized website can take a few weeks for most pages to move, and larger sites take longer. Some volatility during that window is normal. The distinction that matters is between a dip that recovers as reprocessing completes and a loss that does not, and telling them apart requires the baseline. Without it, everyone is arguing from memory.

When you do not need this, and what to do if the move already happened

If URLs are not changing — a redesign that keeps every path, a hosting move, a template refresh — the risk profile is entirely different and this is not the engagement to buy. Hosting and infrastructure moves have their own documented considerations, and a checklist plus a monitoring window will usually cover it.

If the site is small and organic search is not a meaningful revenue channel, the honest answer is that a competent developer with a mapping spreadsheet and a redirect test can handle it. The consulting engagement earns its cost where the URL count is high, the templates are many, or the revenue passing through organic makes an avoidable loss expensive.

If the migration has already happened and traffic fell, the work is different again and it starts with reconstruction: recover the old URL inventory from log files, archived sitemaps and Search Console's remaining sixteen months, identify what is unmapped or chained or returning 404, and fix the mapping retrospectively. Recovery is genuinely possible, particularly within the first weeks. It is slower and more expensive than doing it in the right order, and the outcome cannot be committed to in advance — but the first move is always the same: find out what used to exist.

Frequently Asked Questions

Published 2026-08-11