Launch checklist

Website Launch Checklist

Use this pre-launch checklist to catch blockers before users, clients, Google, and AI crawlers see your site. It is designed for indie SaaS, AI tools, client landing pages, and small product launches where a few missed basics can damage trust fast.

Run a free audit Read the checklist

Before you promote the site

A finished-looking website can still ship with a staging canonical, blocked robots.txt, broken footer legal links, missing analytics, cropped social image, or an empty primary CTA. Treat this checklist as the manual companion to the WebsiteReady launch readiness audit.

Domain & HTTPS

Use the final production domain before promotion so search engines, social previews, analytics, and users see the same canonical site.

✓Apex and www hosts resolve through the intended provider.
✓HTTP redirects to HTTPS with a 301 status.
✓www and apex canonicalization is explicit and preserves path/query strings.
✓No preview, staging, workers.dev, pages.dev, or localhost URLs appear in canonical, sitemap, or OG tags.

Crawlability

Public launch pages should be easy for Google, Bing, and AI assistants to discover unless there is a deliberate content-protection reason.

✓robots.txt returns 200 and does not block public launch pages.
✓sitemap.xml returns 200 and only lists canonical, indexable, production URLs.
✓Important pages do not have noindex meta tags or x-robots-tag noindex headers.
✓Report, account, admin, checkout, and private result pages are noindex or excluded when appropriate.

SEO basics

Each indexable page needs a clear search target, unique title, useful description, and server-visible content before GSC submission.

✓One H1 describes the page's primary task.
✓Title and meta description match search intent and avoid vague claims.
✓Self-referencing canonical URL uses the production domain.
✓JSON-LD, FAQ, OG image, favicon, and internal links are present where they add real value.

Trust, legal, and contact paths

A launch-ready site should not make users guess who runs it, what data is collected, or how to request help or deletion.

✓Privacy, Terms, and Contact links are visible and return 200.
✓Analytics, infrastructure providers, storage, retention, and deletion paths match the actual product behavior.
✓Public email aliases or contact forms are deliverable before they are shown on the site.
✓Disclaimers avoid overpromising legal, security, accessibility, ranking, or uptime guarantees.

Product QA

Do not stop at a 200 homepage. Test the real user task on desktop and mobile with good, bad, and edge-case inputs.

✓Primary CTA works and returns a usable result or clear error state.
✓Mobile layout has no horizontal scroll and touch targets are usable.
✓Placeholder copy, empty links, broken images, and unfinished buttons are gone.
✓Result pages, exports, and re-run actions work with real public URLs.

AI search readiness

AI readiness means clear public summaries and crawlable reference files, not a promise of AI rankings.

✓llms.txt summarizes the product, public pages, APIs, and usage boundaries.
✓FAQ and schema match visible page content.
✓Robots policy intentionally handles AI crawlers without accidentally blocking normal search.
✓Short answer blocks explain what the product does, who it is for, and what it does not check.

How WebsiteReady helps

Paste a public URL and WebsiteReady checks the homepage, robots.txt, sitemap.xml, llms.txt, trust links, sitemap URLs, redirects, indexability blockers, analytics signals, security headers, and AI search hints. The report groups issues by P0/P1/P2/P3 so developers know what blocks launch.

What still needs manual QA

Run Lighthouse or PageSpeed for Core Web Vitals, test forms and payments with real sandbox data, verify mobile layouts in a browser, and review legal text with a qualified professional when the site handles sensitive data or paid transactions.