Every agency has a war story about a launch that went sideways: a staging noindex tag that stayed live for three weeks, an MX record wiped during a DNS cutover, a contact form silently dropping leads into a spam folder. None of those failures are exotic. They all happen because someone skipped a line on a website launch checklist.
This is the checklist we actually run at Pixelseed before we push a client site to production. It is organised into phases, in the order we execute them, and every single item comes with the exact tool or command we use to verify it. Bookmark it, fork it into your project management tool, or paste it into your deployment runbook.
How to use this website launch checklist
Three rules make this list work in the real world:
- Run it twice. Once on staging (T-7 days) and once on production immediately after the DNS cutover. A check that passes on staging is not a check that passes live.
- Assign an owner per phase. DNS and SSL usually belong to the dev lead, meta tags and analytics to the SEO owner, content and forms to the project manager.
- Never verify in a browser alone. Browsers cache aggressively and hide status codes. Use the terminal, then confirm visually.
Launch day runbook at a glance
| When | What happens |
|---|---|
| T-7 days | Content freeze, full staging crawl, redirect map built, backups tested |
| T-48 hours | DNS TTL lowered to 300 seconds, SSL certificate pre-issued, monitoring configured |
| T-0 | DNS cutover, HTTPS forced, robots.txt and noindex removed |
| T+1 hour | Full production re-crawl, redirect spot check, forms tested end to end, analytics validated |
| T+24 hours | Sitemap submitted, error logs reviewed, Core Web Vitals field data monitoring started |
| T+7 days | Coverage report reviewed in Search Console, TTL restored, 404 log triaged |
Phase 1: Pre-flight (checks 1 to 4)
Do this a week out. Everything that follows depends on having a clean baseline.
| # | Check | How to verify |
|---|---|---|
| 1 | Content freeze declared and communicated to the client in writing | Email or ticket with a timestamp. No CMS edits on the old site after this point. |
| 2 | Legacy URL inventory exported (every indexed URL of the old site) | Screaming Frog crawl + Search Console Pages export + old XML sitemap, deduplicated in a spreadsheet |
| 3 | Staging parity with production: same PHP/Node version, same cache layer, same env vars | php -v, node -v, and a diff of .env.staging against .env.production keys (not values) |
| 4 | Secrets audit: no API keys, test payment keys or debug flags in the repo | npx gitleaks detect --source . and confirm WP_DEBUG / APP_DEBUG are false |
Phase 2: DNS and hosting (checks 5 to 9)
The DNS phase is where launches break in ways that are painful to undo. Propagation is not instant and email is the collateral damage nobody plans for.
| # | Check | Command or tool |
|---|---|---|
| 5 | TTL lowered to 300 seconds at least 48 hours before cutover | dig example.com A and read the TTL column |
| 6 | A, AAAA and CNAME records point to the new host | dig +short A example.com @1.1.1.1 and dig +short AAAA example.com @8.8.8.8 |
| 7 | One canonical host: www or non-www, the other 301s to it | curl -sIL http://www.example.com | grep -i -E 'HTTP/|location' |
| 8 | Email records untouched: MX, SPF, DKIM, DMARC still resolve | dig +short MX example.com, dig +short TXT example.com, dig +short TXT _dmarc.example.com |
| 9 | CAA record allows your certificate authority | dig +short CAA example.com |
Agency tip: before touching DNS, edit your local hosts file to point the domain at the new server IP and browse the production site as if it were live. You will catch hard-coded staging URLs in minutes instead of after the cutover.
Phase 3: SSL, HTTPS and security headers (checks 10 to 15)
| # | Check | Command or tool |
|---|---|---|
| 10 | Certificate covers every hostname including www and any subdomain | openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null | openssl x509 -noout -text | grep DNS: |
| 11 | Expiry date and auto renewal confirmed | openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null | openssl x509 -noout -dates plus certbot renew --dry-run |
| 12 | Full chain valid, no intermediate missing, TLS 1.2 and 1.3 only | SSL Labs server test, target grade A or A+ |
| 13 | HTTP forces HTTPS with a 301, not a 302 | curl -sI http://example.com | head -n 1 |
| 14 | Zero mixed content across templates | Chrome DevTools console, plus a Screaming Frog crawl filtered on Security > Mixed Content |
| 15 | Security headers set: HSTS, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, CSP | curl -sI https://example.com or securityheaders.com |
Add HSTS only once you are certain HTTPS works everywhere. Enabling max-age with preload on a broken configuration locks visitors out of your site for months.
Phase 4: Redirects and URL structure (checks 16 to 21)
If you are replacing an existing site, this phase protects the traffic you already earned. It is the single most common cause of post-launch ranking drops we get called in to fix.
| # | Check | Command or tool |
|---|---|---|
| 16 | Every legacy URL mapped 1:1 to a relevant new URL (not all to the homepage) | Redirect map spreadsheet, then Screaming Frog in List mode against the old URL list |
| 17 | Redirects return 301, not 302 or meta refresh | curl -sI https://example.com/old-page | head -n 1 |
| 18 | No chains or loops, maximum one hop | curl -sIL -o /dev/null -w '%{num_redirects} %{url_effective}\n' https://example.com/old-page |
| 19 | Trailing slash and case consistency enforced at server level | Test /page, /page/ and /Page with curl -sI |
| 20 | Custom 404 page returns a real 404 status, not a 200 | curl -sI https://example.com/this-does-not-exist | head -n 1 |
| 21 | Deleted content returns 410 where there is no equivalent page | curl -sI https://example.com/removed-offer | head -n 1 |
Phase 5: Crawlability and indexing (checks 22 to 26)
| # | Check | Command or tool |
|---|---|---|
| 22 | robots.txt no longer blocks the site and links to the sitemap | curl -s https://example.com/robots.txt |
| 23 | No stray noindex in HTML or in the X-Robots-Tag header | curl -sI https://example.com | grep -i x-robots and a site-wide crawl filtered on Directives |
| 24 | XML sitemap is accurate: only canonical, indexable, 200 URLs | curl -s https://example.com/sitemap.xml, then crawl it in List mode |
| 25 | Canonical tags are absolute and self-referencing (and point to HTTPS) | curl -s https://example.com | grep canonical |
| 26 | Search Console and Bing Webmaster Tools verified, sitemap submitted, domain property added | Google Search Console URL Inspection on the homepage and three key templates |
Phase 6: Meta tags, Open Graph and structured data (checks 27 to 31)
Meta data is what your launch announcement looks like when someone shares it. Getting the Open Graph image wrong is the most visible mistake on this list, because it appears in every LinkedIn and Slack preview for the next year.
| # | Check | Command or tool |
|---|---|---|
| 27 | Unique title tag on every page, under roughly 60 characters | Screaming Frog > Page Titles > Duplicate / Over 60 characters |
| 28 | Meta descriptions written for money pages, no template placeholders left | Same crawl, Meta Description tab, search for lorem and TODO |
| 29 | Open Graph complete: og:title, og:description, og:url, og:type, og:image at 1200×630 with an absolute HTTPS URL | curl -s https://example.com | grep 'og:' then LinkedIn Post Inspector and Facebook Sharing Debugger |
| 30 | X card tags present (summary_large_image) and image loads publicly | curl -sI https://example.com/og-image.jpg | head -n 1 |
| 31 | Favicon set, lang attribute and structured data valid (Organization, LocalBusiness, Product, Article, Breadcrumb) | Google Rich Results Test and Schema Markup Validator |
Phase 7: Analytics and tracking (checks 32 to 34)
| # | Check | Command or tool |
|---|---|---|
| 32 | Analytics tag fires once per page view, with the production measurement ID, not the staging one | Google Tag Assistant, GA4 DebugView, or the Network tab filtered on collect |
| 33 | Conversion events tested: form submit, phone click, purchase, file download | GA4 Realtime report while you trigger each event manually |
| 34 | Consent banner blocks tags before opt-in and consent mode signals are sent | Incognito window, DevTools Network tab, refuse cookies and confirm no tracking requests fire |
Phase 8: Forms, email and integrations (checks 35 to 37)
| # | Check | Command or tool |
|---|---|---|
| 35 | Every form submitted end to end from a real external address, including validation errors and the thank you page | Manual test, then confirm the entry landed in the CRM and in the CMS database |
| 36 | Transactional email deliverability: notifications reach the inbox, not spam, with a valid From domain | mail-tester.com, target a score of 9 or 10, plus an SMTP relay instead of the server mail function |
| 37 | Spam protection and third party integrations live: captcha or honeypot, payment gateway in live mode, booking and chat widgets loading | One real low value transaction in production, then refund it |
Phase 9: Broken links and assets (check 38)
| # | Check | Command or tool |
|---|---|---|
| 38 | Zero broken internal links, images, scripts, PDFs or external links | lychee --verbose --no-progress https://example.com or wget --spider -r -nd -nv -o crawl.log https://example.com, then grep the log for 404 |
Phase 10: Performance budget (checks 39 to 40)
Set the budget before you test, otherwise you will rationalise whatever number you get. These are the thresholds we hold ourselves to on client launches.
| Metric | Pass | Fail the launch |
|---|---|---|
| Largest Contentful Paint (mobile) | under 2.5 s | over 4 s |
| Interaction to Next Paint | under 200 ms | over 500 ms |
| Cumulative Layout Shift | under 0.1 | over 0.25 |
| Total page weight (template average) | under 1.5 MB | over 3 MB |
| JavaScript shipped | under 300 KB compressed | over 600 KB |
| # | Check | Command or tool |
|---|---|---|
| 39 | Every key template measured against the budget above, on throttled mobile | npx lighthouse https://example.com --form-factor=mobile --throttling-method=simulate --view or npx unlighthouse --site example.com for the whole site |
| 40 | Delivery layer optimised: Brotli or gzip on, long cache headers on static assets, WebP or AVIF images with width and height attributes, fonts preloaded with font-display swap | curl -sI -H 'Accept-Encoding: br' https://example.com/app.css | grep -i -E 'content-encoding|cache-control' |
Phase 11: Backups, rollback and monitoring (checks 41 to 42)
A launch is not finished when the site is live. It is finished when you can prove you can put it back and that you will know within minutes if it breaks. elementor.com has a solid rundown on this.
| # | Check | Command or tool |
|---|---|---|
| 41 | Pre-launch backup taken, stored off-server, and restore tested, with a written rollback plan and automated daily backups scheduled | mysqldump -u user -p db > pre-launch.sql plus a full file archive, then restore it to a scratch environment and load it in a browser |
| 42 | Monitoring live before cutover: uptime checks every minute, SSL expiry alerts, application error tracking, and alerts routed to a channel a human reads | UptimeRobot or Better Stack for availability, Sentry for exceptions, Search Console email alerts, plus a keyword check on a string that only appears when the page renders correctly |
Bonus: 6 checks we add for client projects
- Accessibility baseline: run
npx @axe-core/cli https://example.comand fix all critical issues. Check keyboard navigation, focus states and colour contrast manually. - Cross-browser and device pass: latest Chrome, Safari, Firefox and Edge, plus one real iPhone and one real Android device. Emulators lie about Safari.
- Legal pages published: privacy policy, cookie policy, terms, and the legal notices your jurisdiction requires, all linked in the footer.
- Print and email rendering: print stylesheet for invoices or menus, plus a plain-text fallback for automated emails.
- Scheduled tasks running: confirm cron jobs, cache warmers and feed imports execute on the new server with
crontab -land a log check. - Handover pack delivered: credentials in a password manager vault, CMS training recording, and a one-page document explaining who to call at 2 a.m.
The 5 mistakes we see most often
- Redirecting everything to the homepage. Google treats mass homepage redirects as soft 404s and the equity does not transfer. Map page to page.
- Leaving the staging noindex live. Check the header, not just the HTML source, because CDNs and server rules can inject
X-Robots-Tagindependently. - Cutting DNS over on a Friday afternoon. Launch Tuesday or Wednesday morning, when your host, your registrar and your developer are all reachable.
- Testing forms from an internal address only. Internal mail often bypasses the filters that will catch external submissions.
- No baseline metrics. Export traffic, rankings and conversion rates before launch. Without a baseline you cannot tell a seasonal dip from a technical regression.
Copy and paste version
Short form for your ticket tracker:
PRE-FLIGHT: content freeze / legacy URL export / staging parity / secrets audit DNS: TTL 300 / A + AAAA / canonical host / MX + SPF + DKIM + DMARC / CAA SSL: SAN coverage / expiry + renewal / A grade / HTTP 301 to HTTPS / no mixed content / security headers REDIRECTS: 1:1 map / 301 status / no chains / slash + case / 404 returns 404 / 410 for removed INDEXING: robots.txt / no noindex / sitemap / canonicals / Search Console META: titles / descriptions / Open Graph / X card / favicon + schema ANALYTICS: tag fires once / conversion events / consent gating FORMS: end to end test / email deliverability / spam + integrations LINKS: full crawl, zero 404s PERFORMANCE: budget met on mobile / compression + cache + images + fonts SAFETY: backup restored and rollback plan / uptime + error monitoring live
FAQ
How long before launch should I start this checklist?
Start the pre-flight and redirect phases seven days out. DNS TTL changes need 48 hours to propagate. The final production pass takes a competent developer around two hours on a standard brochure site and a full day on an ecommerce build.
What is the single most important item on a website launch checklist?
The redirect map, if you are replacing an existing site. Everything else can be fixed after launch with limited damage. Broken redirects cost organic traffic that can take months to recover.
Do I need to resubmit my sitemap after launch?
Yes. Submit the XML sitemap in Search Console right after the cutover and use URL Inspection to request indexing on your five most important pages. For a full domain change, also use the Change of Address tool in Search Console.
Should I launch a new site all at once or in phases?
For most sites, launch at once. Phased launches create duplicate content between old and new templates and make it very hard to attribute a traffic change to a specific cause. Phase the launch only when the platform migration genuinely requires it, for example a large ecommerce catalogue moving in stages.
How do I check if my site is indexable after launch?
Run curl -sI https://example.com | grep -i x-robots, load https://example.com/robots.txt, and use the URL Inspection tool in Search Console on the homepage. All three need to agree that the page is crawlable and indexable.
What should I monitor in the first week after go live?
404 logs, server error rates, Search Console coverage and crawl stats, Core Web Vitals field data as it starts to populate, form submission volume compared with the old site, and uptime. Review daily for seven days, then weekly for a month.
Launching soon and want a second pair of eyes? The Pixelseed team runs this exact checklist as a paid pre-launch audit, including the redirect map and a post-launch monitoring setup. Get in touch and tell us your go-live date.
