Free tool
Launch the new site without losing the traffic the old one earned
Forty checks across benchmarking, staging hygiene, redirects, indexing, tracking, on-page, performance and the first eight weeks. Tick them off as you go — your progress is kept in your own browser and never sent to us.
Website Launch SEO Checklist
Your progress
0 of 40 checks complete across 8 stages.
Your ticks are saved in this browser only. Nothing is uploaded, and clearing site data clears them.
Before you touch anything: benchmarking
A launch that loses traffic is only diagnosable against a record of what you had. Capture these while the old site is still live.
0 of 5 done
Why: You cannot verify a redirect map later against a list of old URLs you never saved.
Why: Sitewide totals hide the pattern; a launch problem almost always shows up on specific templates first.
Why: Search Console only retains 16 months, and the "why excluded" reasons are the fastest post-launch comparison you have.
Why: Rewriting metadata during a redesign is one of the most common causes of unexplained ranking loss.
Why: Content gets cut for design reasons and nobody notices until the rankings that depended on it are gone.
Staging hygiene
Almost every catastrophic launch is caused by a staging setting that travelled to production, or a production setting that never arrived.
0 of 5 done
Why: A robots.txt disallow does not prevent a URL being indexed if something links to it; a password does.
Why: An x-robots-tag left in a shared config is the single most damaging launch mistake, and it is invisible in page source.
Why: One staging canonical on a template can deindex every page that uses it.
Why: Every hop through a redirect is wasted crawl budget and a slower page for the person clicking.
Why: A dummy contact number that reaches nobody costs more in a week than the launch did.
Redirects
If URLs are changing, the redirect map is the launch. Build it as data you can test, not as a list someone works through by hand on the night.
0 of 5 done
Why: Bulk redirects to an irrelevant page are treated as soft 404s and pass nothing on.
Why: A temporary redirect tells search engines to keep the old URL, which is the opposite of what a migration needs.
Why: Chains accumulate across successive migrations and eventually stop being followed.
Why: Real inbound links and bookmarks use the messy variants, and those are the ones that 404 in week one.
Why: This is the only step that proves the redirect map works rather than assuming it does.
Indexing and robots
Getting these wrong does not degrade performance gradually. It removes the site from search.
0 of 5 done
Why: It is a two-character difference between a normal launch and a site that disappears within days.
Why: Blocked assets stop the page being rendered as a visitor sees it, which distorts how it is assessed.
Why: Cross-domain or protocol-mismatched canonicals are the most common cause of "duplicate, Google chose a different canonical".
Why: Four accessible versions of the homepage split every signal the old site earned.
Why: A sitemap full of redirects and noindexed URLs slows discovery and hides real coverage problems.
Analytics and tracking
Measurement is what turns a launch from a leap of faith into something you can respond to. It has to be right before traffic arrives, not after.
0 of 5 done
Why: Weeks of data in the wrong property cannot be moved into the right one afterwards.
Why: Single-page submissions silently stop being counted when the form component is rebuilt.
Why: Broken links between platforms show up as missing conversions and lead to the wrong campaign being paused.
Why: A consent change and a site launch on the same day makes any drop impossible to attribute.
Why: Six months later nobody remembers whether the dip started before or after launch.
On-page and content
The redesign is where content quietly gets lost. This group is about making sure it did not.
0 of 5 done
Why: Design systems often turn the logo into an H1 across the whole site.
Why: Duplicate titles across a template are the fastest way to make a large site look thin.
Why: A page that ranked on 900 words rarely holds the position on 200.
Why: A link that only exists as a click handler is not a link anything can follow.
Why: Markup describing content that is not on the page is a policy problem, not just an invalid one.
Performance and Core Web Vitals
Measure on a mid-range phone on a throttled connection. A new site is almost always faster on the machine that built it.
0 of 5 done
Why: A lazy-loaded hero image is the most common self-inflicted LCP problem.
Why: Layout shift is judged on the real visit, and late-loading media is the usual cause.
Why: Tag managers accumulate scripts nobody has owned for years, and each one competes with your content.
Why: Shipping a 3000px image into a 600px slot wastes most of the mobile page weight.
Why: Launch day is the worst possible time to discover the origin is serving everything uncached.
The first eight weeks
Most migration damage is fixable if you find it quickly. Nearly all of it is permanent if you find it in the next quarterly report.
0 of 5 done
Why: Errors found on day one cost an afternoon; the same errors found in month three cost rankings.
Why: Coverage reports lag by days, so the first week of data is not the verdict.
Why: Logs show what crawlers actually did, which is often not what the sitemap asked for.
Why: Ranking fluctuation after a migration is normal for weeks; a sustained drop at week eight is not.
Why: Redirects removed after a few months break the external links that were the point of keeping them.
What this does and does not do
- Covers the search and measurement work around a website launch or replatform, from pre-launch benchmarking through the first eight weeks after.
- Keeps your ticks in this browser only, using local storage. Nothing is uploaded, no account is needed, and clearing site data clears them.
- Does not audit your site. It cannot tell you whether any given check passes — you or your developer have to verify each one.
- Does not cover design QA, accessibility conformance testing, legal or privacy review, or the content strategy behind the redesign.
- Does not replace a migration plan for a large or multi-market site, where URL mapping, hreflang and staged rollouts each need their own process.
Order of operations
A launch has a sequence, and skipping ahead is what causes damage
Almost every migration failure traces back to work done in the wrong order rather than to work left undone entirely.
Record what you have, before it disappears
Crawl the live site, export analytics and Search Console, and save the current titles, descriptions and body content of anything that earns traffic. This is the only step with a hard deadline attached to the old site rather than the new one.
You get: A crawl export, a metadata export and an analytics baseline
Map the URLs while the new structure is still changeable
Build the redirect map as data — a spreadsheet with old URL, new URL and status — as soon as the new information architecture is agreed. Doing it after the build is finished means discovering pages with nowhere sensible to go, when it is too late to add them.
You get: A one-to-one redirect map in version control
Fix the staging environment properly
Password-protect it, then make sure every setting that exists only to keep staging out of search is removed on production. This is the group of checks where a single missed line is catastrophic rather than merely costly.
You get: A documented difference between staging and production config
Verify on launch day, not the morning after
Check response headers on production, confirm robots.txt, submit the new sitemap, spot-check twenty redirects by hand and confirm conversion tracking fires. An hour here is the cheapest hour in the whole project.
You get: A signed-off launch-day verification pass
Watch for eight weeks, then judge it
Crawl within 24 hours, then compare against the baseline at two, four and eight weeks. Resist the urge to change things in week one — you will be reacting to normal recrawl fluctuation and you will not be able to tell which change did what.
You get: A weekly monitoring routine with a defined stopping point
The usual causes
How a good redesign loses a year of search visibility
- The noindex came with it.
- Staging is kept out of search with a directive that lives in server configuration. If the production environment inherits that configuration, the entire site tells search engines to remove it, and it does not show up in page source. The site can be effectively gone within a week of launch.
- Nobody wrote down the old URLs.
- Once the old site is switched off, the list of what used to exist is gone unless someone exported it. Analytics shows the pages that had traffic, not the pages that had links, and the ones with links but little traffic are often the ones carrying the most value.
- The content got shorter because the design looked better that way.
- Design reviews optimise for how a page looks with a small amount of text in it. A page that ranked on genuinely useful depth rarely holds that position after it is cut to two paragraphs and a photograph, and the connection is not made because the change was a design decision, not a content one.
- The new front end is slower on a phone than the old one.
- Modern build tooling makes it easy to ship a great deal of JavaScript, and everyone reviews the site on a fast connection on a desktop machine. The regression only appears in field data weeks later, by which point it is competing for attention with a dozen other post-launch tasks.
A useful reframing
The drop is almost never caused by the design
When traffic falls after a launch, the instinct is to blame the thing that changed most visibly. It is rarely the culprit. Search engines do not have an opinion about your new colour palette, and the pages that lose visibility are usually not the pages that changed most in appearance.
What changed underneath is what matters: which URLs exist, what they say, whether they can be crawled, and whether the signals pointing at the old ones were passed on. Those four questions account for the overwhelming majority of post-launch losses, and all four are answerable with the checks above.
This is genuinely good news, because it means the diagnosis is mechanical rather than aesthetic. There is a finite list of things to check, most of them produce a clear yes or no, and the ones that fail can usually be fixed in days rather than rebuilt over months.
Know which one you are doing
Three kinds of launch, three very different risk profiles
The checklist is the same. How much of it is load-bearing depends entirely on which of these you are actually undertaking.
| Dimension | Redesign on the same URLs | Replatform with new URLs | Domain change |
|---|---|---|---|
| Redirect work | Minimal — confirm nothing moved | The single largest task in the project | Sitewide, plus a change of address notification |
| What usually breaks | Metadata reset, content cut, slower front end | Unmapped URLs, redirect chains, duplicate canonicals | Everything above, plus links and citations pointing at the old domain |
| Typical exposure | Low, and mostly self-inflicted | Moderate to high | High, and slowest to recover |
| Time to settle | Two to four weeks | Four to eight weeks | Eight weeks or more on a large site |
| The check that matters most | Content and metadata parity against the old pages | One-to-one redirect verification after launch | Response-header and canonical verification on the new origin |
If you would rather not do this yourself
How we handle a launch when we are the ones responsible
What we do
- Build the redirect map as version-controlled data, and test it by re-crawling the saved old-URL list after launch
- Export and archive the old crawl, metadata and analytics baseline before anything is switched off
- Check response headers on the production origin on launch day, not just page source
- Compare the new pages against the archived old ones and flag content that has been dropped
- Set a defined monitoring window with agreed checkpoints, so nobody is reacting to week-one noise
What we will not do
- Sign off a launch where the redirect map has not been tested against the real old URLs
- Redirect a set of retired pages in bulk to the homepage to save mapping time
- Tell you a drop is normal without showing you the crawl and coverage data behind that judgement
- Promise a specific recovery timeline, because recrawl speed depends on factors nobody controls
- Let a launch date stand when a check that could remove the site from search has not been completed
Questions
What people ask before and after a launch
We are keeping the same URLs. Do we still need most of this?
Yes, though the redirect section becomes short. Same-URL redesigns still lose traffic, and the usual causes are metadata reset by the new CMS, body content cut for design reasons, internal links rebuilt as buttons, and performance regressions from a heavier front end.
The benchmarking, staging, on-page and monitoring sections all apply exactly as written. Treat the redirect group as a five-minute confirmation that nothing moved rather than as work.
How long after a launch should traffic take to recover?
For a well-executed migration on a small to mid-sized site, expect movement for two to four weeks and something close to the previous level by week six to eight. Larger sites take longer simply because recrawling every URL takes longer.
A drop that is still deepening at week eight is not fluctuation. That is the point at which to stop waiting and start diagnosing, beginning with the redirect map and the indexing report rather than with content.
What is the single most damaging launch mistake?
A noindex directive carried over from staging to production. It is usually set as an HTTP header in a shared server configuration rather than as a tag in the page source, which means it is invisible to anyone checking by viewing the page.
It can remove a site from search results within days, and recovery takes far longer than the removal did. Checking response headers on the live production origin, not just the page source, is a five-minute job that belongs on launch day itself.
Can we redirect all our old URLs to the new homepage?
You can, and it is close to the worst available option. A redirect to a page that is not a reasonable equivalent tends to be treated as a soft 404, which means the old URL passes on nothing and the person who clicked it has to start their search again.
One-to-one mapping to the closest equivalent page is the standard. Where no equivalent exists, a relevant category page is a reasonable second choice, and a genuine 410 is better than a misleading redirect.
Does my progress on this checklist get saved anywhere?
Only in your own browser, in local storage. There is no account, no server, and nothing is sent to us — which also means your ticks will not follow you to another device or survive clearing your site data.
If your browser blocks local storage, the checklist still works normally; it simply will not remember your ticks after a refresh, and it tells you so.
Launching soon, or already launched and watching the numbers fall
Both are worth a conversation, and they are different conversations. Before a launch we can review the redirect map and the staging configuration. After one, the diagnosis usually takes days rather than weeks.
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
Related
Where to go next
- redesigns and replatforms we runWhere this list stops being your job and becomes ours.
- launching a new website
- the technical layer a migration depends on
- performance and Core Web VitalsA new site is almost always fast on the machine that built it.
- build a tagged campaign link
- recovering traffic that has already gone
Last updated · Reviewed by Zubair Afzal