SaaS Launch Checklist: What a Production-Ready Website Needs

What does a production-ready website or SaaS launch checklist include, from 404 pages and SEO to Open Graph images, error handling and legal pages?

It includes twelve groups of checks: domains and email authentication, security, SEO basics, social sharing images, error pages, monitoring, backups, analytics and consent, accessibility, performance, legal pages, and billing and support. The checklist below lists each item with the official source to check it against. Security, backups and billing are blockers; most of the rest can be fixed in the first week if needed, but should not be forgotten.

This production-ready website checklist is the launch-week counterpart to our SaaS MVP planning checklist, which covers the decisions to make before you build. Copy the groups below into your issue tracker, give each item an owner and tick them off in the week before launch.

1. Domains, DNS and email authentication

• The domain is registered in your company's name, with auto-renew on and registrar access protected by multi-factor authentication.
• HTTPS works on the bare domain and www, one redirects permanently to the other, and HTTP redirects to HTTPS.
• SPF, DKIM and DMARC records are published for every domain or subdomain that sends email. Google's email sender guidelines require all senders to Gmail to use SPF or DKIM, and bulk senders (more than 5,000 messages a day) to use SPF, DKIM and DMARC.
• Transactional email (password resets, invitations, receipts) sends from a separate stream or subdomain from marketing email.
• Marketing emails include one-click unsubscribe, which Google requires of bulk senders.
• Password reset and invitation emails have been tested end to end on Gmail and Outlook addresses, including the spam folder.

2. Security headers and secrets

• Security headers are set, following OWASP's HTTP Headers Cheat Sheet: Strict-Transport-Security, a Content-Security-Policy, X-Content-Type-Options: nosniff, framing blocked with CSP frame-ancestors (or X-Frame-Options), a Referrer-Policy such as strict-origin-when-cross-origin, and a Permissions-Policy that disables features you do not use.
• X-Powered-By is removed and the Server header reveals nothing useful. OWASP advises against setting X-XSS-Protection other than to 0.
• No API keys or database credentials in client code or the repository; production secrets are stored in the host's secret manager.
• Rate limiting on sign-in, sign-up, password reset and any public form.
• Each customer's data is separated and tested: log in as customer A and try to load customer B's records by changing IDs in the URL. Our guide to custom web application security goes deeper.
• Admin routes are protected, logged and not discoverable from public pages.

3. Technical SEO

• Every public page has a unique, descriptive <title> and meta description. Google's title link guidance recommends titles that describe the page concisely and avoid keyword stuffing and boilerplate repeated across pages.
• One clear H1 per page.
• A rel="canonical" link on every indexable page, using absolute URLs, which Google recommends over relative paths.
• An XML sitemap of canonical public URLs, using absolute URLs and submitted in Search Console or referenced with a Sitemap: line in robots.txt. Google's limit is 50,000 URLs or 50MB uncompressed per sitemap, and it ignores <priority> and <changefreq>.
• A robots.txt that does not block pages you want found. Google notes that robots.txt is not a way to keep a page out of search; use noindex or password protection for that.
• App pages behind login, staging sites and preview deployments set to noindex or protected, so they never compete with your marketing site.
• Structured data in JSON-LD, the format Google recommends, for your organisation, articles and FAQs where relevant, checked with Google's Rich Results Test. Structured data makes a page eligible for rich results; it does not guarantee them.
• Search Console verified for the production domain before launch.

4. Open Graph and social sharing images

• The four properties the Open Graph protocol (ogp.me) lists as required on every shareable page: og:title, og:type, og:image and og:url.
• og:image:alt alongside every og:image, which the protocol says should be specified when an image is, plus og:image:width and og:image:height.
• Absolute HTTPS URLs for images, served publicly (not behind login or a preview password).
• Twitter/X card tags (twitter:card and, optionally, its own title and image) if you want a large image card there; check the platform's current documentation.
• A default share image for the site, and specific images for key pages such as the home page, pricing and articles.
• Previews checked by pasting real URLs into the platforms you care about (LinkedIn, Slack, X) after deployment.

5. Error pages and error handling

• A custom 404 page that returns HTTP status 404 (not 200), with links to the home page, search or the main sections. Google calls a page that shows "not found" content with a success status a soft 404.
• A 500 error page that is static enough to render when the app is failing, and does not show stack traces.
• Friendly in-app error states: what went wrong, whether the user's work was saved, and what to do next.
• Empty states for every list and dashboard a new user sees before they have data.
• Forms validate on the server as well as in the browser, and show errors next to the field.
• Broken internal links checked with a crawler before launch. Google says its crawlers slow down when a site returns server errors, so persistent 5xx responses are an SEO problem as well as a user one.

6. Monitoring and alerts

• Error monitoring on the front end and back end, with source maps uploaded, so errors arrive with readable stack traces.
• Uptime checks on the home page, sign-in and a health endpoint, alerting a named person.
• Logs searchable for at least the first weeks after launch, without passwords, tokens or full card numbers in them.
• Alerts for failed background jobs and failed payment webhooks.

7. Backups and recovery

• Automated database backups, with point-in-time recovery if your provider offers it.
• A restore tested once, into a separate environment, with the time it took written down.
• Uploaded files backed up or versioned, not only the database.
• A written note of who can restore, and how, if the person who set it up is unavailable.

8. Analytics with consent

• The activation event and a retention signal are tracked and visible in a dashboard on launch day.
• Non-essential cookies and similar technologies are not set before the user agrees, where the law requires consent. In the UK, the ICO's guidance on storage and access technologies describes exceptions, including one for analytics used solely to improve your service with clear information and an easy way to object; advertising uses still need consent.
• In the EU, the ePrivacy rules apply to storing or reading information on a user's device; the EDPB's guidelines on the technical scope of Article 5(3) of the ePrivacy Directive explain what that covers. Rules differ by country, so take advice for your markets.
• Cookie banner choices are respected in code, recorded, and easy to change later.

9. Accessibility

• Every interactive element reachable and usable with a keyboard, with a visible focus style.
• Semantic HTML: real buttons and links, labelled form fields, headings in order, alt text on meaningful images. web.dev's accessibility guidance covers these basics.
• Text contrast and zoom checked; the layout works at 200% zoom.
• An automated check run on key pages, followed by a manual keyboard pass. Treat WCAG 2.2 (a W3C Recommendation) level AA as the target; automated tools find only part of the issues.

10. Performance

• Core Web Vitals measured on the home page, pricing page and the app's first screen. web.dev's thresholds for a good experience are LCP of 2.5 seconds or less, INP of 200 milliseconds or less and CLS of 0.1 or less, at the 75th percentile of page loads.
• Images resized, compressed and given width and height attributes; the main hero image not lazy-loaded.
• Third-party scripts (chat, analytics, tag managers) audited and loaded after the main content.
• Our guide to web vs mobile apps and Core Web Vitals gives per-metric optimisation steps.

11. Legal pages

• A privacy policy that matches what the product actually collects, which processors you use and where data is hosted.
• Terms of service covering acceptable use, payment, cancellation, liability and governing law.
• A cookie notice or policy, linked from the consent banner.
• For B2B: a data processing agreement ready to send, and a list of sub-processors.
• Company details required in your jurisdiction (for example registered name and address) in the footer or legal pages.
• These pages are general obligations that differ between the EU GDPR, UK GDPR and US state laws; have a qualified lawyer review them rather than copying another company's. Our guide to GDPR and privacy for SaaS explains the basics.

12. Billing and support

• Every billing path tested in your payment provider's test environment: new subscription, upgrade, downgrade, cancellation, failed payment and card requiring authentication. Stripe, for example, publishes test card numbers for declines and 3D Secure in its testing documentation.
• Webhooks verified, idempotent and alerting on failure; see failed payments and dunning.
• Live keys in production only, test keys everywhere else, and a real low-value purchase made and refunded after switching to live.
• Receipts and invoices show your company details and, where needed, tax numbers.
• A support route visible in the app and on the site, a named person answering it, and a short internal note on how to handle the first refunds and account deletions.
• A status page or at least a plan for telling customers when something is down.

When you need less, or more

A marketing site with no logins needs groups 1, 3, 4, 5, 9, 10 and 11, and very little of the rest. A product handling health, financial or children's data needs more than this list: a security review, data protection impact assessment and possibly penetration testing. If you built the product quickly with AI tools, run the free app readiness checker first; it highlights the security and reliability items most often missed.