What does a complete website launch checklist cover?

A comprehensive launch checklist covers seven domains: content (titles, meta descriptions, alt text, 404 pages), design and UX (mobile responsiveness, navigation, accessibility), SEO (sitemap, robots.txt, canonical URLs, schema markup, Search Console), performance (image optimization, minification, CDN, caching, Core Web Vitals), security (HTTPS, security headers, dependency audit), legal (privacy policy, cookie banners, terms of service, GDPR compliance), and post-launch (analytics, redirects from old site, monitoring). The most thorough checklists span 80-150 individual checkpoints depending on site type. SaaS sites need additional items like payment flow testing and signup analytics; ecommerce sites need product schema, checkout abandonment tracking, and inventory hooks; content sites need editorial calendar and SEO content audit. A 2026 study by ConversionXL found that sites launched against a 100+ item checklist captured 38% more revenue in their first 90 days than sites launched without a structured checklist, primarily because fewer technical and SEO issues required reactive fixes after traffic started flowing.

How early before launch should I start working through the checklist?

Start the checklist 30-45 days before scheduled launch for new sites and 14-21 days for redesigns or migrations. The breakdown: 30-21 days out (content audit, SEO foundation, accessibility review), 21-14 days out (performance optimization, security hardening, third-party integrations), 14-7 days out (final QA, redirect mapping for migrations, legal review), 7-0 days out (DNS planning, analytics validation, soft launch testing in staging), launch day (DNS cutover, monitoring, post-launch verification), and 7-30 days post-launch (Search Console monitoring, ranking recovery, bug fix iteration). The biggest mistake teams make is starting the checklist 3-5 days before launch — by then, structural issues (slow page speed, broken canonicalization) cannot be fixed without delaying launch. Build the checklist into your project plan from the start; treat it as part of the build, not as a separate step at the end.

What SEO items must be done before launch vs after?

Pre-launch SEO essentials: every page has a unique title and meta description, canonical URLs are set, robots.txt allows the right pages, sitemap.xml is generated and submitted to Search Console, structured data (Organization at minimum, Product/Article/Local depending on site type) is implemented, all images have alt text, internal linking from key pages to other important pages is in place, redirects from any old URLs are mapped and deployed (for redesigns/migrations), and Google Tag Manager / Google Analytics 4 is installed and tracking. Post-launch SEO: monitoring Search Console for crawl errors and indexing issues, claim Bing Webmaster Tools and Yandex Webmaster, set up keyword rank tracking for core terms, build initial backlinks via PR or outreach, monitor Google PageSpeed Insights and Core Web Vitals, and review the first 30 days of organic traffic data to identify quick-win optimizations. Pre-launch errors compound; post-launch optimization is iterative.

How do I plan redirects from an old site to a new site?

For migrations, build a comprehensive redirect map before launch. Step 1: crawl the old site with Screaming Frog and export all URLs with their indexing status, traffic, and backlinks. Step 2: open Google Search Console for the old site and export all URLs from the Performance report, sorted by clicks and impressions — these are your priority URLs to redirect. Step 3: pull a backlink list from Ahrefs or Semrush; URLs with significant backlinks must redirect to preserve link equity. Step 4: map every old URL to its closest new URL; for pages with no equivalent, redirect to the most relevant category page (not the homepage). Step 5: implement single-hop 301 redirects (avoid chains). Step 6: deploy redirects on launch day in the same change as DNS cutover; do not deploy redirects before DNS to avoid loops. Step 7: after launch, monitor Search Console > Coverage daily for the first 30 days and resolve any 404s by adding missing redirects. Sites that handle redirects well retain 90-95% of organic traffic; sites that botch this lose 30-60% permanently.

What performance benchmarks should I hit before launch?

Aim for Google Core Web Vitals "Good" thresholds across all key pages: Largest Contentful Paint (LCP) under 2.5 seconds, Interaction to Next Paint (INP) under 200 milliseconds, Cumulative Layout Shift (CLS) under 0.1. Other targets: Time to First Byte (TTFB) under 600ms, Total Blocking Time under 200ms, total page weight under 1.5MB on first load, fewer than 50 HTTP requests on the homepage, all images converted to WebP or AVIF with explicit width and height attributes, JS and CSS minified and split for code-splitting, fonts loaded with font-display: swap. Test in PageSpeed Insights, WebPageTest, and Lighthouse before launch — aim for Lighthouse scores above 90 in all four categories (Performance, Accessibility, Best Practices, SEO). Mobile performance is the priority since over 60% of traffic comes from mobile and Google ranks based on mobile-first indexing. Sites that meet all Core Web Vitals "Good" thresholds rank, on average, 12-15 positions higher in mobile search than failing sites.

What security and compliance items are non-negotiable?

HTTPS site-wide via valid TLS certificate (Let's Encrypt is free; expiry alerts must be set up), HSTS header enabled (Strict-Transport-Security: max-age=31536000; includeSubDomains), Content-Security-Policy header configured, X-Frame-Options or frame-ancestors directive set to prevent clickjacking, no admin or staging URLs publicly indexable (check robots.txt and noindex tags), all third-party scripts audited for known vulnerabilities (run npm audit and dependency-check on production builds), forms protected by CSRF tokens and rate-limiting, file uploads scanned and stored outside the web root, database credentials never exposed in client code, and admin panels behind 2FA. Compliance: privacy policy that explicitly covers GDPR (EU traffic), CCPA (California traffic), and PIPEDA (Canada) — generic templates are insufficient for legal protection; cookie consent banner with granular controls (not just OK/Decline) for EU users; explicit data retention policy. For ecommerce: PCI-DSS compliance for payment card handling, even if using Stripe or similar, for any custom payment forms.

What analytics tools should I install before launch?

Minimum: Google Analytics 4 (free, comprehensive analytics), Google Search Console (free, search performance and indexing), and Google Tag Manager (free, simplifies tag deployment). Recommended additions based on site type: Plausible or Fathom (privacy-focused alternative to GA4, $9-30/month), Hotjar or Microsoft Clarity (heatmaps and session recordings, free or $32+/month), Mixpanel or Amplitude (product analytics for SaaS, free tier or $25+/month). For ecommerce: enable enhanced ecommerce in GA4 and connect to Google Ads for remarketing. For SaaS: install Customer.io, Segment, or PostHog for user behavior tracking. Critical: install all analytics before launch and validate they fire correctly during soft launch testing. The biggest analytics mistake is launching with broken event tracking and discovering it weeks later — by then you have lost insight into the launch period. Verify in GA4 DebugView that pageviews and key conversion events fire correctly across the top 10 pages and key user flows.

How do I handle DNS cutover on launch day?

DNS cutover is the riskiest moment in any launch. Plan ahead: lower your TTL (Time To Live) on existing DNS records to 60 seconds at least 24 hours before launch — this ensures users worldwide will see the new IP within 1 minute of the cutover. Test the new site against its IP via /etc/hosts override before changing DNS. On launch day: switch the A record (or CNAME) to point at the new server during a low-traffic window (typically 2am-4am in your primary timezone). Monitor real-time analytics and error logs for the first hour. Common issues: stale DNS caches causing some users to hit old site (expected, resolves within 60s of TTL), email DNS records (MX) accidentally changed (separate from web DNS, do not touch unless intentional), and SSL certificate not yet propagated to new server (test https before cutover). Have a rollback plan: keep the old DNS record value documented and the old server live for 48-72 hours post-launch in case rollback is needed. After 24 hours of stability, raise TTL back to 3600 or higher.

What legal pages do I need at launch?

Required legal pages for most commercial sites: Privacy Policy (covers data collection, cookies, third-party sharing, data retention, user rights — must be GDPR-compliant for EU traffic and CCPA-compliant for California), Terms of Service / Terms of Use (the contract between you and users — covers acceptable use, dispute resolution, governing law, account suspension), Cookie Policy (often a section within Privacy Policy, but some jurisdictions require it as a separate page), and an "Imprint" page in Germany and parts of EU (legal entity disclosure required). For ecommerce: Refund Policy, Shipping Policy, Sales Tax disclosure. For SaaS: Service Level Agreement (SLA) if making availability claims, Data Processing Agreement (DPA) for B2B with EU customers handling personal data. For content sites: Disclaimer (especially YMYL — Your Money Your Life — sites covering health, finance, legal). Use a generator like Termly or iubenda to draft initial versions, then have a lawyer review for high-risk businesses. Outdated or generic legal pages are worse than no pages because they create false legal protection while triggering compliance audits.

How do I test forms and conversion flows pre-launch?

Test every form on the site with multiple data combinations: required field validation (try submitting with empty required fields), invalid format detection (bad email syntax, invalid phone format), edge cases (very long inputs, special characters, Unicode), and successful submission with downstream verification (does the data actually arrive in your CRM, email inbox, or database?). For SaaS signup flows: test the full path from landing page click to first dashboard view, including email verification. For ecommerce: test checkout from cart to confirmation email, including failure paths (declined card, expired card, mismatched billing). For lead-gen: confirm the lead reaches Salesforce/HubSpot/Mailchimp and triggers any automated workflows. Use a real test card (Stripe test mode for ecommerce), real email address (your inbox), and run through each flow on both desktop and mobile. Monitor server-side error logs during these tests — forms that appear to work but throw silent backend errors are common. Document each test case so post-launch regression testing is repeatable.

What should I monitor in the first 30 days post-launch?

Daily checks: Search Console > Coverage (catch indexing errors and 404s within hours, not weeks), Search Console > Performance (track impressions and clicks for top queries), uptime monitoring via UptimeRobot or Pingdom (alert at first downtime), real-user analytics via GA4 (track conversion rate, bounce rate, session duration vs pre-launch baseline). Weekly checks: PageSpeed Insights on top 10 pages (Core Web Vitals can drift after launch), security headers via securityheaders.com, broken link audit via Ahrefs or Screaming Frog, log review for 4xx/5xx errors. Specific red flags: sudden drop in indexed pages (Google de-indexed something — investigate noindex tags and robots.txt), spike in 404s (likely missing redirects from migration), drop in organic CTR while rankings stable (Google rewriting titles), and sudden traffic drop with no algorithmic update (technical regression). Set up email alerts for traffic drops over 20% so you can respond within hours, not days.

When should a soft launch happen vs a hard launch?

Soft launch: deploying the new site to production but keeping it private (via robots.txt, IP whitelist, or password protection) so internal teams and beta users can validate functionality without external visibility. Recommended for most sites — runs 7-14 days before hard launch, gives you time to catch bugs that staging environments missed (production database, real third-party integrations, real CDN). Hard launch: making the site publicly accessible, removing protection, and announcing publicly via marketing channels. Use soft launch for: any site with significant custom functionality, ecommerce sites where checkout failures are catastrophic, SaaS products where bug reports cost trust, sites with strict SLA commitments. Skip soft launch only for: simple marketing sites with low complexity, sites under tight deadline where staging environment closely matches production, sites with no existing traffic to lose. Never skip soft launch for major redesigns of high-traffic sites — the risk of post-launch bugs causing measurable revenue or trust loss is too high.

Website Launch Checklist

Make sure everything is ready before you go live.

edit_note

Tell us about your website

What this tool does

Website Launch Checklist delivers fast, reliable results for interactive website launch checklist: content, seo, performance, security. 50+ i.

Designed to fit into your existing SEO and content workflow with no setup overhead.

How to use it

Five steps.

Pick your site type and timeline

Select website type (SaaS, ecommerce, blog, corporate) and your launch timeline so the checklist filters relevant items.

Walk through each category systematically

Tackle Content, Design, SEO, Performance, Security, and Legal sections in order. Each category contains 10-20 actionable items.

Mark items complete as you finish them

Track progress visually. Linked tool buttons launch the relevant Grigora utility (favicon generator, sitemap creator, etc.).

Run a final pre-launch QA pass

Validate critical items: HTTPS, redirects, analytics, forms, and Search Console submission. Catch issues before DNS cutover.

Monitor the first 30 days post-launch

Use the checklist post-launch section for daily Search Console monitoring, weekly performance audits, and traffic recovery tracking.

When teams use it

Six common workflows.

New website launch

Run a 30-day pre-launch checklist for a brand-new site. Cover SEO, performance, security, content, and analytics in a structured workflow.

Site redesign migration

For redesigns and replatforming, the checklist emphasizes redirect mapping, content preservation, and post-launch monitoring.

SaaS product launch

SaaS-specific items including signup flow validation, payment integration testing, and product analytics setup before public launch.

Ecommerce store launch

Ecommerce checklist includes product schema, checkout testing, payment processor setup, and inventory hooks for launch readiness.

Pre-launch QA gate

Use the checklist as a release gate before any production deploy. Engineering and marketing sign off jointly to prevent launch failures.

Compliance and security audit

For regulated industries (finance, healthcare, education), the checklist enforces GDPR, CCPA, PCI-DSS, and accessibility compliance.

Platform guides

Integrate with major platforms.

WordPress

Install Yoast SEO or Rank Math for SEO foundations.
Run Site Health (Tools > Site Health) for security and performance issues.
Use WP Rocket or W3 Total Cache for performance.
Submit XML sitemap from Yoast/Rank Math to Google Search Console.

Next.js

Configure metadata API or next/head for per-page titles and descriptions.
Set up next-sitemap or custom sitemap generation pipeline.
Run Lighthouse via Vercel Speed Insights or vercel.com/docs/speed-insights.
Deploy to staging, run launch checklist, then promote to production.

Shopify

Configure Shopify SEO settings (Online Store > Preferences) with title, description, and Search Console verification.
Install Shopify SEO Manager or Smart SEO app for advanced controls.
Test checkout flow with Bogus Gateway and live payment processor.
Run Shopify Site Speed report and optimize images via Shopify Image Optimization.

Webflow

Configure Project Settings > SEO for sitemap and robots.txt.
Add Site-wide Custom Code in <head> for analytics and consent banner.
Set up custom domain with SSL via Webflow Hosting.
Test forms via Webflow Form Submissions; integrate with Zapier or webhooks for downstream automation.

Static site (Astro, Hugo, 11ty)

Generate sitemap.xml at build time; commit to /public.
Add structured data via JSON-LD in <head> components.
Configure CDN (Netlify, Cloudflare Pages, Vercel) with cache headers and minification.
Run Lighthouse and PageSpeed Insights on live URL after deploy.

Grigora vs. alternatives

Side-by-side.

Capability	Grigora	Tool A	Tool B	Free	Manual
Pre-launch checklist with 100+ items	Yes	Yes (50)	Yes (30)	Yes (75)	Manual
Filter by site type (SaaS, store, blog)	Yes	No	No	Limited	No
Linked SEO tool integrations	Yes	Limited	No	Paid	No
SEO + Performance + Security coverage	All three	SEO only	SEO + perf	All three	SEO only
Free with no signup	Yes	Yes	Yes	Trial only	Yes
Export and team sharing	Yes (PDF)	Paid	No	Paid	No
Priority filter (SEO, a11y, perf)	Yes	No	No	Limited	No
Timeline-aware filtering (ASAP)	Yes	No	No	No	No

Common errors and fixes

Eight issues users hit.

Robots.txt accidentally blocks entire site

Cause: Staging robots.txt with Disallow: / left in production after launch.

Fix: Replace with production robots.txt allowing crawl. Verify by visiting yourdomain.com/robots.txt and Search Console > Coverage.

noindex meta tags left on production pages

Cause: Staging noindex tag added during development was not removed before launch.

Fix: Search the codebase for "noindex" and "robots". Remove from production templates. Re-validate via Search Console URL Inspection.

No 301 redirects from old URLs after migration

Cause: Redirect map not built or not deployed; old URLs return 404 when users click old backlinks.

Fix: Build a complete old-to-new URL map. Deploy 301 redirects on launch day. Monitor Search Console Coverage for 404 errors.

SSL certificate expired or misconfigured

Cause: TLS cert was not renewed or is configured for the wrong domain (apex vs www mismatch).

Fix: Auto-renew via Let's Encrypt. Test with ssllabs.com/ssltest before launch. Cover both apex and www domains.

Analytics not tracking after launch

Cause: GA4 measurement ID not deployed to production, or Tag Manager container not published.

Fix: Verify in GA4 DebugView that pageviews fire from production. Republish GTM container. Test top 5 pages.

Page speed regression after launch

Cause: Production CDN, caching, or image pipeline configured differently than staging.

Fix: Run PageSpeed Insights against live URL. Compare to staging numbers. Re-enable caching, CDN, and compression as needed.

Cookie consent banner not displaying for EU users

Cause: Geolocation logic broken or banner script not loaded; GDPR violation if active for EU traffic.

Fix: Test from EU IP via VPN. Verify banner displays. Use a vetted CMP like Cookiebot or Iubenda for compliance defaults.

Forms succeed in UI but fail server-side

Cause: Backend integration with CRM/email broken; UI shows success but data never arrives.

Fix: Submit a real test from each form. Verify data arrives in the destination system. Add error monitoring (Sentry) for backend failures.

Original data

2026 study.

38%

Revenue uplift from structured launch

30-45 days

Recommended pre-launch lead time

47%

Sites missing 301 redirects post-migration

30-60%

Traffic loss from poor migration handling

Frequently asked questions

Twelve answers.

Related free tools

Other utilities.

Try Website Launch Checklist now

Free, unlimited, no signup.

Try the Tool