We launch in ten days. Is it too late?

Not if the old site is still live, because that is the thing that cannot be recovered later. The URL inventory has to be captured while the old site can still be crawled, and once it is switched off the list has to be reassembled from whatever fragments survive in analytics and Search Console — always incomplete. A compressed engagement that captures the inventory and builds the redirect map is worth far more than a thorough one starting the week after launch.

Our developer says the redirects are handled. Do we still need this?

Frequently they have handled the pages someone remembered. What goes missing is the long tail — old campaign URLs, discontinued products, blog posts from four years ago, parameter variants, versions with and without a trailing slash. Those pages are often the ones carrying accumulated value. The check is straightforward. Crawl the complete old URL list against the new site and see how many return a 404. If the answer is none, your developer was right and the audit cost you little.

Will we lose traffic anyway?

A dip in the first weeks is normal while Google recrawls and reassigns, and it should recover. What is not normal, and what this work exists to prevent, is a permanent loss from URLs that were never redirected or that were sent somewhere unrelated. We will tell you what looks like ordinary settling and what looks like damage, and the difference is visible in the indexing report rather than in a traffic chart.

What does the deliverable actually look like?

A mapping file with one row per old URL and its destination, a separate list of everything that had no obvious match with a decision recorded against each, a pre-launch verification crawl on staging, and a post-launch crawl showing status codes for the full old list. It is one of the few pieces of search work that is entirely verifiable — either every old URL resolves or it does not.

Does a domain change need anything extra?

Yes. A new Search Console property verified at domain level through a DNS record, so it covers every subdomain and both protocols, plus the change of address process, plus the outside references — profiles, directories and any partner sites pointing at the old domain. Redirects carry visitors across on their own. Updating the references that people control is what stops you depending on those redirects indefinitely.

Can we keep the old site up for a while as a fallback?

Not on the same content. Two live copies of the same pages on different addresses puts the search engine in the position of choosing one, and it may not choose the one you launched. If a fallback is needed, it belongs behind a login or on a blocked address rather than publicly reachable.

SEO & Organic Growth

Keeping your rankings through a redesign, a replatform or a domain change

A complete inventory of every URL the old site owned, matched one by one to the new site, so the traffic arrives at the new pages instead of at a 404.

From: $500–$4,000
Typical time: 2–4 weeks
Usually bought by: Rebranding companies

The failure that only shows up afterwards

A migration is the single most reliable way to lose organic traffic that took years to build, and it is unusual because the damage is invisible on launch day. The new site looks better than the old one. Everybody who reviews it types the home page address and finds it working. The pages that break are the ones nobody in the meeting has thought about since 2021 — a product that was discontinued but still gets searched for, a guide that quietly earns links, a campaign landing page that a supplier has been linking to for years.

What is being carried across is not files. Every URL that has been live for a while has accumulated something — references from other sites, a position on queries, a place in Google's index. A permanent redirect moves that accumulation to the new address. A 404 discards it, and a temporary redirect frequently fails to transfer it at all.

The other thing to understand is that the window closes. Everything this work depends on comes from the old site being reachable — the crawl, the URL list, the current status codes, the sixteen months of query data. Once the old site is switched off, that inventory can only be approximated, and approximation is exactly what leaves a page behind.

How a migration is handled

Capture the inventory while the old site is still live. A full crawl saved as a file, the complete list of indexed URLs, sixteen months of query and page data exported from Search Console before any of it expires, the landing pages from analytics, and the current sitemap. Four sources rather than one, because each of them misses something different. Three to four days.
Match old to new, and record the unmatched. Every old URL gets a destination on the new site. The straightforward ones map automatically. What matters is the residue — the pages with no obvious equivalent, which get a documented decision each rather than a sweep to the home page. That list is the real work and it needs your input on commercial questions. Three to five days.
Verify on staging before anything is public. The old URL list crawled against the staging environment, checking that each returns a single permanent redirect to a live page. Chains get straightened so the original URL points directly at the final destination rather than through two intermediate hops. The staging site itself must be closed to crawlers, and that block must not travel to production. Two days.
Control the launch itself. Redirects live at switchover, the new sitemap containing only canonical indexable URLs that return a 200, the old sitemap left available briefly so the old addresses are recrawled and their redirects discovered, Search Console properties in place, and any maintenance window served as a temporary unavailable status rather than as a working page saying the site is down. One day, with someone watching.
Monitor for four weeks and fix what surfaces. The full old URL list recrawled against production for status codes, the indexing report watched as pages are reassigned, server logs or Search Console checked for what is being requested and failing, and external links to the old domain updated where the owners will do it. Ongoing across two to three weeks.

What sets the price

The range is $500–$4,000 across 2–4 weeks, and three things decide the position within it.

How many URLs there are and how well they map. A hundred pages moving to a like-for-like structure is a short job. Four thousand URLs where the category system has been redesigned means every unmatched page needs a judgement, and those judgements cannot be automated because they are commercial.

Whether the domain is changing as well as the design. A redesign on the same domain is one set of risks. Moving to a new domain adds property verification, the change of address process, external references and a longer reassignment period during which things look worse than they are.

How much control you have over the new platform. A hosted store where redirects go in through an interface with its own rules is different from a server where the rules can be written directly. Some platforms make certain URL structures impossible to reproduce, and that constraint has to be found during mapping rather than on launch night.

The three ways migrations lose traffic

The old site goes off before its URL list is captured. This is the one that cannot be undone. Every other mistake here can be corrected in the weeks after launch, but a URL nobody recorded cannot be redirected, and the only trace it leaves is a slow decline nobody attributes correctly. Any migration that has already passed switchover without an inventory is a recovery job rather than a migration job.

Temporary redirects, or chains left to stack. A temporary redirect tells the search engine this is a short-term arrangement and the original address will be back, so the accumulated value frequently stays where it was. Chains are the slower version of the same problem — after two site changes the old address points to a second address which points to a third, each hop costing time, and a share of visitors abandoning along the way. Every chain gets flattened to point straight at the final page.

The launch window is served as a normal page. A holding page saying we will be back shortly, returned with a success status, tells a crawler that this is now the content of every URL it requests. Served for long enough, that is how a site removes itself. The correct response during planned downtime is a temporary unavailable status, which tells the crawler to come back later and leaves the index untouched.

See where the site stands before you brief anyone.

If the site is already live, start from what it scores rather than from a guess. The audit reports what it checked, what it found, and — the part most tools leave out — what it could not check, and why.

See the website audit Talk about this work

Questions people ask before they commit.

We launch in ten days. Is it too late?: Not if the old site is still live, because that is the thing that cannot be recovered later. The URL inventory has to be captured while the old site can still be crawled, and once it is switched off the list has to be reassembled from whatever fragments survive in analytics and Search Console — always incomplete. A compressed engagement that captures the inventory and builds the redirect map is worth far more than a thorough one starting the week after launch.
Our developer says the redirects are handled. Do we still need this?: Frequently they have handled the pages someone remembered. What goes missing is the long tail — old campaign URLs, discontinued products, blog posts from four years ago, parameter variants, versions with and without a trailing slash. Those pages are often the ones carrying accumulated value. The check is straightforward. Crawl the complete old URL list against the new site and see how many return a 404. If the answer is none, your developer was right and the audit cost you little.
Will we lose traffic anyway?: A dip in the first weeks is normal while Google recrawls and reassigns, and it should recover. What is not normal, and what this work exists to prevent, is a permanent loss from URLs that were never redirected or that were sent somewhere unrelated. We will tell you what looks like ordinary settling and what looks like damage, and the difference is visible in the indexing report rather than in a traffic chart.
What does the deliverable actually look like?: A mapping file with one row per old URL and its destination, a separate list of everything that had no obvious match with a decision recorded against each, a pre-launch verification crawl on staging, and a post-launch crawl showing status codes for the full old list. It is one of the few pieces of search work that is entirely verifiable — either every old URL resolves or it does not.
Does a domain change need anything extra?: Yes. A new Search Console property verified at domain level through a DNS record, so it covers every subdomain and both protocols, plus the change of address process, plus the outside references — profiles, directories and any partner sites pointing at the old domain. Redirects carry visitors across on their own. Updating the references that people control is what stops you depending on those redirects indefinitely.
Can we keep the old site up for a while as a fallback?: Not on the same content. Two live copies of the same pages on different addresses puts the search engine in the position of choosing one, and it may not choose the one you launched. If a fallback is needed, it belongs behind a login or on a blocked address rather than publicly reachable.

Often taken together.

Start with the brief, not the invoice.

Send what you are trying to achieve. You get a written scope, a price and a date — or an honest “this is not the right service for that”.

Talk about Migration SEO All SEO & Organic Growth services