The Website Launch Checklist We Run Before Every Go-Live
The technical, SEO, and business-continuity checks that prevent launch-day emergencies.
The difference between a smooth launch and a stressful one is almost always preparation, not luck. We run the same structured checklist before every go-live, covering technical, content, and business-continuity items that are easy to skip under deadline pressure and expensive to discover missing after the site is public.
Key takeaways
- Most launch-day emergencies are preventable with a staging-environment dry run.
- Redirects from old URLs are the single most commonly skipped item with the biggest SEO cost.
- Analytics and conversion tracking must be verified live, not assumed to be working.
- A rollback plan should exist before launch, not get improvised during an incident.
- Post-launch monitoring in the first 48 hours catches issues before they compound.
Technical verification
Before DNS changes, everything should be tested end to end on staging with production-equivalent data: every form submits and delivers correctly, every internal link resolves, and the site renders correctly across the real device and browser matrix your analytics show your audience actually uses, not just the latest Chrome on a large monitor.
SSL certificates should be confirmed valid for the production domain, and server response times and Core Web Vitals should be checked against the production environment specifically, since staging and production infrastructure can perform very differently under real traffic.
- SSL certificate valid and auto-renewing on the production domain.
- All forms tested end to end, including error states and confirmation emails.
- Core Web Vitals checked on production infrastructure, not staging.
- 404 page, robots.txt, and XML sitemap all correctly configured.
- Site tested on real mobile devices, not only browser emulators.
Redirects and SEO continuity
If the launch replaces an existing site, every URL from the old structure that has any inbound links, search rankings, or bookmarked traffic needs a 301 redirect mapped to its new equivalent. Skipping this is the most common and most costly launch mistake we see — it silently forfeits months or years of accumulated search equity and breaks every external link pointing at the old site.
Pull the full list of indexed URLs from Google Search Console and top pages by traffic from analytics before building the redirect map, not just the pages the team remembers existing.
Non-negotiable: No redesign or replatform should go live without a complete, tested redirect map. Test a sample of redirects manually after launch, not just in the configuration file.
Analytics and tracking must be verified, not assumed
Confirm GA4, Google Tag Manager, and any ad platform pixels are firing correctly on the live domain using GTM's preview mode and GA4's real-time report, immediately after launch. A tracking snippet that worked on staging can silently fail in production due to a domain mismatch, a consent banner blocking it, or a caching layer serving a stale page.
Verify that key events (form submissions, purchases, phone-number clicks) fire correctly with a live test transaction or submission before considering the launch complete. Discovering a broken conversion event two weeks later means two weeks of unmeasured performance data that cannot be recovered.
Content and legal review
Proofread every page in its final production context, not just in the CMS editor, since rendering differences can introduce line breaks, truncation, or missing images that were invisible in the draft view. Confirm the privacy policy, terms of service, and cookie consent banner are current and match the actual data practices of the new site, particularly if new tracking or forms were added.
Check that contact information, business hours, and any third-party review or trust badges are current, and that all social and directory links point to the correct live profiles rather than placeholder URLs left over from development.
Have a rollback plan and watch the first 48 hours
Know exactly how to revert DNS or restore the previous site version before you need to, including who has access to make that change and how long propagation will take. Deciding this during an active incident wastes time that matters most in the first hours after launch.
Monitor uptime, error rates, and Search Console coverage reports closely for the first two days. Crawl errors, unexpected 404 spikes, or a sudden ranking drop are far easier to correct within 48 hours than after they have had time to compound.
- Documented DNS/hosting rollback procedure, tested in advance.
- Uptime monitoring alerts configured before, not after, launch.
- Search Console coverage report checked daily for the first week.
- A named owner responsible for the first 48 hours post-launch.
Frequently asked questions
How long before launch should the redirect map be finalized?
At least a week before go-live, with time to test a representative sample manually. Building it the day of launch under time pressure is how mistakes make it into production.
Should launches happen on a Friday?
We avoid it. Launching earlier in the week leaves a full business week to catch and fix issues with the full team available, rather than discovering a problem over a weekend.
What if we find a major bug right after launch?
That is what the rollback plan is for. A quick, deliberate revert is almost always better than trying to patch a serious issue live while the site is generating leads or transactions.
Ready to move on this?
We run this checklist, or a version scoped to the specific project, before every site we launch. Ask us for the full internal checklist if you are planning a launch or replatform on your own timeline.