Launch a New Website
Launch the new site without losing what the old one earned
A new website is one of the most common causes of lost organic revenue we see. Rarely because the design is worse — almost always because the launch was run as a design deadline rather than as a migration with a sequence, a benchmark and a way back.
The timeline
What has to happen, and when
This page is organised as a sequence because that is what the risk is made of. Almost every launch failure we investigate is a step done in the wrong order rather than a step nobody knew about.
At the sitemap stage, before any design
Decide which pages will exist, what they are called, how they are grouped and what each URL will be. These are search and commercial decisions, not design ones, and they are close to impossible to revisit once templates are built and content is written against them.
You get: An agreed sitemap and URL structure
Six to eight weeks out: take the benchmark
Record what the current site does before it is gone. Rankings for commercial terms, organic sessions and conversions by page, top landing pages by revenue, backlinks by target URL, and Core Web Vitals. Without this you will have no way to tell a normal post-launch wobble from real damage.
You get: A dated pre-launch benchmark you can point at later
Four weeks out: build the redirect map from the old site
A full crawl of the old site, plus twelve months of analytics and Search Console data, plus server logs, plus a backlink export. Every old URL maps to the closest equivalent new one, or to a genuinely relevant parent. A map built by crawling the new site will miss the retired pages that still carry links.
You get: A complete, reviewed old-to-new URL map
Two weeks out: test the migration on staging
Run the redirects against staging and check them in bulk. Verify titles, headings, structured data, canonical tags and internal links survived the content move. Confirm analytics and conversion tracking fire on the new templates, on mobile as well as desktop.
You get: A verified redirect test and a tracking sign-off
Launch day: check the four things that kill sites quietly
The robots directives, the noindex tags, the canonical tags and the sitemap. Confirm the staging block did not ship, confirm the sitemap lists the new URLs, submit it, and spot-check redirects against live rather than staging. Launch mid-week, in the morning, with people available.
You get: A signed launch-day check
First thirty days: watch in the right order
Week one for crawl errors, server errors and indexing. Weeks two and three for rankings and traffic against the benchmark. Week four for conversion rate, which is the thing most likely to have quietly got worse while every technical indicator looked fine.
You get: A thirty-day monitoring log and a fix list
The dangerous ones
Four failures that look exactly like a successful launch
The obvious problems get caught. A broken page, a form that does not submit, a logo in the wrong place — someone reports those within hours. The expensive ones are silent for a fortnight.
- The staging noindex went live with the site.
- A staging environment is correctly blocked from indexing during the build. Then the build is pushed to production and the block goes with it. The site works perfectly for every human who visits, and disappears from search over the following days. This is the single most common serious launch error, and it takes one check to prevent.
- The redirect map was built from the new site.
- Someone crawls the new site, lists the pages and maps the obvious equivalents. That approach cannot see the URLs that no longer exist — the retired service page still holding a dozen editorial links, the old campaign landing pages, the blog posts that quietly earn a steady trickle of qualified traffic. Those are exactly the ones worth keeping.
- Nobody recorded what the old site was doing.
- Six weeks after launch someone asks whether organic traffic is down. Without a dated benchmark the conversation becomes an argument between people with different recollections. Teams then either panic and reverse decisions that were fine, or reassure each other through a real loss until the quarter closes.
- Analytics stopped, or started counting differently.
- The tag was not moved, or it was moved and now fires twice, or the conversion event was renamed during the rebuild. Whatever the cause, the launch date becomes a discontinuity in your only source of truth, and every comparison across it is unreliable for as long as the site exists.
How much risk you are carrying
Three kinds of launch, three very different risks
Work out which of these you are doing before you decide how much planning it warrants. Teams routinely believe they are doing the first and are actually doing the second.
| Dimension | Same URLs, new design | New URL structure | New domain |
|---|---|---|---|
| Main risk | Content and internal links lost in the rebuild | Redirect gaps and lost link equity | All of the above, plus the brand signals attached to the old domain |
| Must be planned | Template parity, page speed, tracking continuity | A complete old-to-new map before any content freeze | Map, domain change notification, and a longer watching period |
| Typical pattern after launch | Little movement if content and links were preserved | Some movement for weeks while recrawling settles | A longer, more variable settling period |
| Where teams underestimate it | Assuming identical URLs means identical pages | Discovering old URLs that were never in the CMS | Treating it as a rebrand deadline rather than a migration |
| Rollback difficulty | Straightforward if the old build is retained | Harder once redirects have been crawled | Hardest, and least advisable to attempt twice |
After go-live
The first thirty days, in order
The order matters. Chasing rankings in week one produces noise, and checking conversion in week four is what catches the failure everyone else missed.
- Day one: confirm the site is indexable, the sitemap is submitted and the staging block did not ship
- Day one: spot-check the highest-value redirects against the live site, not staging
- Week one: monitor server errors, crawl errors and soft 404s daily and fix as they appear
- Week one: confirm analytics and conversion events fire correctly on every key template
- Week two: watch index coverage — pages discovered, pages indexed, pages excluded and why
- Week two: compare rankings for commercial terms against the pre-launch benchmark
- Week three: compare organic sessions and enquiries by landing page against the benchmark
- Week three: re-measure Core Web Vitals on real devices now that live traffic is arriving
- Week four: compare conversion rate, not just traffic, against the old site
- Week four: review search queries for terms the old site ranked for and the new one does not
- Keep the old site archived and restorable for at least a month after launch
Our position
What we insist on before a launch date is agreed
These are conditions rather than recommendations. They are the reason some of our launches move by a week, and the reason we have not had to write a recovery plan for one.
What has to be in place
- A dated pre-launch benchmark of rankings, traffic, conversions and backlinks
- A complete redirect map built from the old site, reviewed line by line
- Redirects tested in bulk on staging before go-live, not after
- Analytics and conversion tracking verified on the new templates in advance
- A launch-day check covering robots directives, noindex, canonicals and the sitemap
- The old site archived and restorable for at least thirty days
What we will not agree to
- Launching on a Friday, or the day before anyone with access goes on leave
- Treating redirects as a task for after go-live
- Changing the domain, the design and the URL structure in a single release
- Skipping the benchmark because the date is close
- Promising that no traffic will move, which nobody can honestly promise
Related
Before and after the launch
Before you launch
Questions
What people ask in the weeks before a launch
When should the SEO work on a new website start?
At the sitemap stage, before any design work begins. The decisions that matter most — which pages exist, what they are called, how they are grouped and what each URL will be — are made early and are extremely expensive to revisit once templates are built.
Bringing search in at the end produces the familiar outcome: a better-looking site with a structure that cannot express what the business sells, and a redirect map assembled in a panic during launch week.
How much traffic will we lose when we launch?
Nobody can promise a number, and be wary of anyone who does. What we can say is that a same-URL redesign carries low risk, a URL restructure carries real risk that a complete redirect map largely contains, and a domain change carries the most.
Some movement in the first weeks is normal even when everything was done correctly, because search engines have to recrawl and reassess. The point of the pre-launch benchmark is to let you tell that normal movement apart from actual damage.
Do we really need to redirect every old URL?
Every old URL that earns traffic, holds external links, or is still being crawled. That set is larger than the page list in your CMS, because it includes old campaign URLs, retired pages that still hold links, and paginated or parameterised variants.
Build the map from the old site: a full crawl, twelve months of analytics and Search Console data, server logs and a backlink export. A map built by crawling the new site will miss exactly the pages that mattered most.
What is the most common launch mistake you see?
A staging site that was blocked from indexing, then pushed to production with the block still in place. The site goes live, everyone celebrates, and it quietly disappears from search over the following days because it is telling search engines not to index it.
The second most common is the reverse: a staging site that was never blocked, got indexed, and now competes with the live site as a duplicate. Both are avoidable with a single check on launch day, and both are routinely missed.
How long should we watch it after launch?
Closely for thirty days, then at a normal cadence. The first week is about errors and indexing, the second and third about ranking and traffic against the benchmark, and the fourth about conversion, because a site can hold its traffic perfectly and still convert worse than the one it replaced.
Keep the old site archived and restorable for at least a month. The ability to compare a page against its predecessor, or to roll back, is worth far more than the hosting cost of keeping it.
Have the launch reviewed while there is still time to change it
If your launch date is more than two weeks away, most of the risk on this page is still avoidable. Send us the new sitemap and the current site, and we will tell you what is missing from the plan.
If we don't deliver the work we agreed to deliver for reasons within our control, you don't pay for the undelivered work. Read our guarantee
Last updated · Reviewed by Zubair Afzal