Launching Without a Traffic Dip

Some dip is normal

Worth saying before the rest, so the normal version is not mistaken for a disaster.

Even a well-executed migration usually shows a small decline for a week or two while addresses are recrawled and redirects are followed.

Single digits, recovering within a month, is a successful launch rather than a problem.

Thirty or forty percent that does not recover is a fault, and the fault is nearly always something introduced during the switch rather than anything about the new site's quality.

Do not launch in stages

The most damaging sequencing mistake is moving one section at a time, on the reasoning that it limits risk.

It does the opposite. For the duration, you have two versions of your site, partly duplicated, with internal links pointing in both directions and a redirect layer that is half applied.

A search engine crawling that has to reconcile a structure that is genuinely inconsistent, and it will do so slowly and badly.

Everything goes at once: new site, complete redirect map, correct configuration. It feels riskier and it is substantially safer.

The order on the day

1. Take a full backup of the old site, files and database.
2. Confirm the redirect map is loaded and tested on staging.
3. Switch, in one operation.
4. Remove any search-blocking instruction from the new site.
5. Test a sample of redirects against the live site.
6. Submit the new sitemap.
7. Test the contact forms for real.

Item four is the single most common cause of a catastrophic dip, and it is one setting.

When to do it

Early in the week and early in the day, which is the opposite of what people choose.

Friday evening is popular because it feels low risk. It is the worst option available, since any fault has the entire weekend to run with nobody watching, and the people who could fix it are unreachable.

Tuesday morning means the whole team is present for the following two days, which is when problems actually surface.

Avoid launching immediately before your busiest season, and avoid launching the week before whoever built it goes on holiday.

Keep the old site recoverable

Not merely backed up, but restorable within an hour by somebody who is available.

Most launch problems are fixable in place, and the ability to roll back is rarely used. Its value is that it converts the decision from a commitment into an experiment.

Establish before launch day who can execute a rollback, how long it takes, and what the threshold is for deciding to do it.

A team that has agreed in advance what would constitute failure makes far better decisions at four in the afternoon than one improvising under pressure.

Do not change everything at once

A migration is one variable. Businesses routinely bundle several.

New site, new domain, new hosting, new platform, restructured content, and rewritten copy, all in the same week.

Each of those is survivable individually. Together they make diagnosis impossible, because when traffic falls there is no way to tell which change caused it.

Where you can, separate them. Move hosting a month before, or the domain a month after, and leave the rebuild as the only thing changing on the day.

A worked example

A services business launched a rebuild on a Thursday afternoon before a long weekend.

The new site had been built on staging with a search-blocking instruction, which was copied to live untouched.

Nothing looked wrong. The site worked, forms delivered, and the design was well received.

Traffic began falling on day four and nobody connected it to the launch, because the site was plainly working.

It was found in week three, by which point most of the site had been dropped from the index.

Correcting it took one minute; recovery took roughly four months.

An hour of checking on launch day would have caught it, and the check is one line in a settings page.

The first hour

A short, specific list, done by somebody who is not the person who built the site.

Confirm the site is indexable. View the homepage source and check no blocking instruction is present.

Request a dozen old addresses by hand and confirm each lands where the map says.

Submit a real contact form and confirm arrival.

Check the site on a phone, on mobile data, not on office wifi.

Confirm analytics is recording, since a rebuild frequently loses the tracking code.

The first fortnight

Watch three things daily and ignore everything else.

Not-found reports, in your search console and your server logs, which reveal the addresses the map missed.

Index coverage, which shows whether the new addresses are being taken up.

And enquiries, which is the number that actually matters and the one most likely to reveal a broken form.

Resist reading daily ranking positions during this period. They are noisy at the best of times and genuinely uninterpretable during a migration.

The hours you do not control

If the switch involves pointing the domain somewhere new, the change does not reach everybody at once.

Address records carry a lifetime value telling other systems how long to remember the answer, and until that expires some visitors continue reaching the old server while others reach the new one.

With a typical setting that window can run most of a day, which means two versions of your business are live simultaneously and you cannot tell which one any given person is seeing.

The fix is preparation rather than patience. Lower that lifetime value to a few minutes about forty-eight hours before launch, make the switch, then raise it again once things are settled.

During the window, leave the old site in place and working rather than taking it down. A visitor still being routed there should find a functioning site, not an error, and any form on it should still deliver somewhere a person is reading.

The counter-case

A staged launch is defensible in one situation: a very large site where a single switch is operationally impossible, such as a retailer with tens of thousands of pages across distinct systems.

Even there the unit should be a complete, self-contained section with its own redirects fully in place, not a partial move.

The other legitimate case is a genuine pilot, where a small section moves first specifically to test the process, with a plan to move everything shortly after.

What is not defensible is drifting into a staged launch because the new site was not finished, which is how most of them actually happen.

The map that makes all of this work is covered in rebuilding without losing your rankings.

Frequently asked questions

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.