The launch checklist that stops a redesign costing you rankings

Before a redesign goes live, record every URL the old site has and map each one to its new address. Test the redirects and the tracking on staging. Remove the staging block at launch, and watch Search Console closely for the first few days. Google’s own site move guide asks for the same core steps. They are a mapping of old to new URLs, redirects kept for at least a year, and a new sitemap submitted once the move starts (Google Search Central).

Almost all of this has to happen before launch. After launch you are diagnosing damage instead of preventing it. This is the order we followed when we rebuilt this site, where 22 blog posts kept their exact URLs and 99 redirect rules were checked against the built site before cutover.

The short version

• Crawl and export the old site before anything changes. That export is your only record of what existed.
• Map every old URL to its closest new equivalent. Google advises against sending many old URLs to one unrelated page such as the homepage, because it can be treated as a soft 404 (Google Search Central).
• Keep URLs identical wherever you can. A URL that does not change needs no redirect.
• Remove the staging noindex or password at launch, and prove it with a live check.
• Keep redirects in place for as long as possible, and generally at least a year, Google says, so signals can move to the new URLs (Google Search Central).
• Expect some movement in search. Google says a medium-sized site can take a few weeks or more to settle after a move (Google Search Central).

The launch in four phases

Phase	When	What it protects	The check that matters most
Measure	Before any design or build decision	The record of which pages bring traffic, links and enquiries	A full crawl and 12 months of Search Console pages saved
Map	During the build	Rankings and links held by old URLs	Every old URL has one new destination, no gaps, no chains
Staging	The week before cutover	Forms, tracking and indexability on day one	Staging block in place, and a written plan to remove it
Launch and 72 hours	Launch day and the three days after	Early warning while fixes are cheap	Search Console coverage and 404s checked daily

What should you do before touching anything?

Measure first. Nothing gets deleted or changed until it has been recorded, because pages that look old sometimes hold the links the rest of the site depends on.

• Crawl the entire current site and save the export. This is your only record of what existed.
• Export the last twelve months of Search Console pages and queries.
• Export analytics landing pages with sessions and conversions.
• Export the backlink profile and note which pages hold the links.
• Screenshot the pages that matter, so you can compare content afterwards.
• List every URL with traffic, links or conversions and mark it protected. Nothing protected changes without a decision.

How do you build the redirect map?

Start with the protected list, then cover every other URL. Google’s guide says to create a mapping of old URLs to new ones and decide where each should redirect (Google Search Central).

• Write an old URL to new URL mapping for every page, with no gaps.
• Send every old URL to its closest real equivalent. Google says not to redirect many old URLs to one irrelevant destination such as the home page, because it can confuse users and may be treated as a soft 404.
• Keep URLs identical wherever possible. A URL that does not change needs no redirect and loses nothing.
• Check no redirect points at another redirect. Google suggests keeping chains to no more than three hops, and our recommendation for a planned move is one.
• Check no redirect points at a page that will not exist.
• Check no redirect source is also a live page. On many hosts the page is served and the rule never fires.
• Include images, PDFs, CSS and JavaScript files in the map. Google’s guide names embedded content as part of a move.
• Decide trailing slash behaviour and enforce it consistently.
• Decide www or non-www and enforce it consistently.

Photo: RDNE Stock project on Pexels.

What should you check on staging before cutover?

Check that staging is hidden from Google, that you know exactly how it is hidden, and that removing the block is on the launch-day list. Google’s site move guide says that if you use noindex rules during development, you should prepare a list of URLs to remove them from when the move starts (Google Search Central).

• Confirm staging is blocked from indexing, and confirm how that block is applied.
• Confirm the block will be removed at launch. A staging noindex left in place can keep the whole new site out of Google, which makes it one of the most expensive mistakes on this list.
• Check every page has a unique title and meta description.
• Check every page has exactly one h1 and no skipped heading levels.
• Check canonicals are self-referencing and point at the new URLs. Google’s guide asks for a self-referencing canonical on each new URL.
• Check structured data validates and describes only what the page shows.
• Check every internal link points at a new URL rather than through a redirect.
• Check images have alt text.
• Test every form and confirm the notification email actually arrives.
• Confirm analytics and conversion tracking fire on staging.
• Test on a real phone, not just a resized browser.
• Check the 404 page exists and returns an actual 404 status. Google does not index URLs that return a 4xx status, and an error page that returns 200 shows up as a soft 404 (Google Search Central).

What should you do on launch day, and in what order?

Deploy, remove the staging block, then prove the live site works before anyone goes home. Google suggests moving during a recurring dip in traffic, so a quiet day for your business is a sensible choice.

• Take a final crawl of the old site immediately before cutover, in case anything was published since your first export.
• Deploy, then remove the staging index block, and verify with a live fetch.
• Load the homepage and confirm it renders.
• Confirm HTTPS works and http redirects to it.
• Confirm www and non-www resolve to one version.
• Spot-check twenty redirects from your map against the live site.
• Submit the new sitemap in Search Console.
• Use the URL Inspection tool on your ten highest-traffic pages and request indexing. Google notes that requesting the same URL again does not speed it up (Google Search Central).
• Submit a form and confirm the email and the CRM record both arrive.
• Confirm analytics is recording real-time traffic.
• Check the browser console on five pages for errors.
• Search the live site for staging URLs, placeholder text and development content.

Photo: ThisIsEngineering on Pexels.

What should you watch in the first 72 hours?

Search Console coverage, 404s and form submissions, every day. This is when a migration problem is cheap to fix. Two weeks later, the damage has had time to show in rankings.

• Check Search Console coverage daily for a spike in excluded or not found pages.
• Check the crawl stats report for a spike in server errors.
• Watch analytics for landing pages that lost all their traffic.
• Watch for 404s in your server or edge logs and add redirects for anything real.
• Confirm form submissions are still arriving at the rate they did before.
• Check Core Web Vitals field data as it starts to populate.
• Keep the old site export handy for a month, because you will need it to answer questions.
• Leave the redirects in place for at least a year, as Google recommends.

Why this list exists

Redesigning a site that already brings in enquiries, without a URL inventory, is one of the most damaging things you can do to it. The traffic loss tends to appear weeks later, after the launch has been signed off and everyone has moved on. The protective work is not sophisticated.

It is a spreadsheet of every existing URL, a decision about where each one goes, and a check afterwards that every decision was carried out. What makes it fail is doing it after launch rather than before. The technical SEO audit guide covers the checks to run once the new site has settled.

The bottom line

A redesign should change how a site looks and works without changing what Google already knows about it. Keep the URLs you can, redirect the ones you cannot to their closest match, and check the result on the day. The preparation takes days. Recovering from skipping it can take months.

Questions people ask about this