A website launch checklist should prove that a visitor can reach your production site, understand its offer, complete its main task, and receive the expected result. It should also prove that someone can detect and recover from a failed release. A homepage that looks finished is only one part of that test.
Use the checks below before launch, during the release, and throughout the first week. Each row includes an action and a pass condition. The worked example is a fictional small SaaS with public articles, email sign-in, saved projects, and a paid plan; adapt the purchase checks for a store or the form checks for a service website. These are proposed acceptance tests, not results from a live launch.
1. Define what can block the launch
Write one primary journey before opening your testing tools: “A new visitor lands on the pricing page, signs up, creates a project, pays, and receives the purchased access.” A portfolio might replace that journey with opening a case study and sending an inquiry. An ecommerce site should add inventory, shipping, and order confirmation.
Separate a launch blocker from a follow-up improvement. A broken password reset, lost customer submission, exposed private project, or payment without delivery should stop a release. A slightly awkward heading or an optional animation can have an owner and a later date. Search rankings and field performance data cannot be guaranteed at launch.
For a solo founder, the owner can be you, but the evidence still needs to exist. Record the tested URL, release identifier, device or browser, result, and time. An unchecked box is an unknown, not a pass. If a feature is outside scope, record why rather than silently removing its check.
| Decision | Example | Required response |
|---|---|---|
| Stop release | Purchase succeeds but access remains locked | Fix and repeat the purchase journey |
| Restrict release | A secondary locale has broken navigation | Keep that locale out of this release and document scope |
| Follow up | An optional illustration needs refinement | Assign an owner and review date |
Before building more pages, connect each one to a purpose with content mapping. A launch checklist cannot compensate for a site whose pages all compete for the same task.
2. Before launch: domain, security, and production boundaries
Test the actual production hostname. A working preview does not prove that production DNS, redirects, authentication callbacks, or email links are correct. Visit the bare domain, preferred hostname, HTTP version, and a deep link in a signed-out browser. Record the final destination and check for loops.
| Check | Action | Pass condition |
|---|---|---|
| Domain and HTTPS | Open the public hostname on another network | Correct site loads with valid HTTPS and no browser warning |
| Preferred address | Visit alternate host and protocol variants | They resolve to the intended public URL without loops |
| Direct navigation | Paste a nested article or product URL into a new session | Intended page loads without visiting the homepage first |
| Preview isolation | Open staging and preview addresses without credentials | Private environments remain protected; search controls match intent |
| Private data | Open one user's private project as another account and signed out | Server rejects access; hiding a button is not the only protection |
| Configuration | Exercise production callbacks and integration endpoints | Correct environment is used; no preview callback or test key remains |
Keep private environments behind access controls. A robots rule is not authentication. For a public page that should stay out of search, a crawlable noindex instruction is a separate mechanism; blocking the crawl can prevent Google from seeing that instruction. Google's noindex documentation explains this distinction.
Avoid a last-minute global switch that removes every safeguard at once. Make public marketing routes accessible while preserving protection for account areas and previews. Then continue with the indexing diagnosis if a public page is known to Google but has not been crawled.
3. Before launch: prove the complete visitor journey
Test with fresh accounts and empty states, not only with the account you use to develop the site. Verify the success route, the failure route, and the recovery route. If registration works but the confirmation email points to localhost, the journey is broken.
| Journey | Action | Pass condition |
|---|---|---|
| Navigation | Use header, footer, logo, and key contextual links | Each goes to the intended page and locale |
| Forms | Submit valid data, missing fields, and an invalid email | Clear validation appears and accepted submissions reach the destination |
| Authentication | Register, follow the email, sign out, and reset access if supported | All links return to production and sessions behave correctly |
| Saved work | Create, edit, reload, and reopen a project | The latest confirmed changes persist for the correct user |
| Trigger a transactional message and reply to support | Expected messages arrive and the reply reaches a monitored inbox | |
| Error recovery | Interrupt a save or request on a test account | User gets a useful state and can retry without duplicate work |
| Missing pages | Visit a deliberately nonexistent public route | Helpful missing-page content and the intended HTTP status appear |
Add accessibility checks to that same journey. Complete the primary task using only a keyboard. Confirm visible focus, usable field labels, understandable validation, and a way out of every dialog. On a narrow mobile screen, check navigation, long titles, forms, and buttons at the actual point of use. A desktop screenshot does not establish mobile usability.
Use a realistic long name, an empty account, and a record with much more content than your demo. Those variations reveal clipped labels and layouts that hide the action people need. If the site sells a product, compare the promise on the pricing page with the access that the application actually delivers.
4. Before launch: make important pages eligible for search
Google's technical requirements describe minimum conditions for search eligibility, not a promise of inclusion. Test important canonical pages first: homepage, core offer, pricing or contact page, and a small set of useful articles. Private account pages and duplicate filter URLs do not need indexing.
| SEO check | Action | Pass condition |
|---|---|---|
| Response and content | Load each intended public landing page | Successful response and meaningful indexable content are available |
| Robots directives | Inspect robots.txt, page meta, and relevant response headers | Intended search pages are not accidentally blocked or marked noindex |
| Canonical choice | Compare preferred address, internal links, canonical, and sitemap | Signals identify the same intended version |
| Titles and descriptions | Read them alongside the visible page | Specific, accurate, and distinct across primary pages |
| Discovery | Follow normal navigation to each priority page | Crawlable contextual links connect it to the site |
| Sitemap | Open the submitted sitemap and sample its entries | Intended canonical URLs are listed; removed or private routes are excluded |
| Search Console | Verify the correct property and inspect a priority URL | You can see reports and investigate the exact production URL |
A sitemap helps discovery; submission does not guarantee crawling or indexing. Use accurate modification dates rather than updating every URL's date whenever a deployment runs. Google's sitemap guide is the reference for this check.
Keep the keyword-to-page assignment simple enough to review before launch. The keyword mapping guide shows how to avoid creating several near-identical pages for one intent. If Search Console later reports an unresolved discovered URL, use the specific troubleshooting workflow rather than repeatedly resubmitting the entire site.
5. Before launch: payments and measurement
A payment button needs a delivery test. Use your provider's supported testing environment for successful payment, failed payment, cancellation, and relevant subscription scenarios. Confirm that the provider record maps to the correct internal account and that repeated notifications do not duplicate delivery. Test and live credentials, endpoints, products, and prices must be intentionally separated.
Stripe's testing documentation covers simulated payment scenarios. Its fulfillment guide explains why completion cannot depend solely on the customer returning to a success page. Apply the equivalent documented flow for your provider. Production smoke tests require the owner's deliberate approval and plan; do not assume a simulated charge proves production delivery.
| Check | Evidence to capture | Pass condition |
|---|---|---|
| Checkout | Product, currency, interval, account mapping | Customer buys the intended offer |
| Delivery | Verified provider event and entitlement result | Correct user receives the purchased benefit |
| Failure | Declined or abandoned test payment | No unearned access and a usable next step |
| Operations | Refund and cancellation procedure | Owner knows the effects on money and access |
| Analytics | One test journey with expected events | Visits, signup, activation, and purchase have defined meanings |
Do not count a checkout-button click as collected revenue. Record the actual commercial event separately and exclude known tests from business reporting. Review what personal data enters analytics and error reports, and make the applicable consent behavior part of your acceptance test rather than adding a decorative banner.
Choose a payment setup with the SaaS gateway comparison, then use subscription billing rules to define renewal and access behavior. The launch check should validate that policy, not invent it during deployment.
6. Launch day: release, observe, and retain a way back
Name the release owner and record the previous working version. Know what a rollback restores. A code rollback might not reverse a database migration or an external payment, so identify compatible migrations and a recovery plan before changing production data.
Run a small smoke test immediately after release: homepage, deep link, sign-in, primary action, persistence, and the relevant delivery path. Confirm error monitoring receives a controlled test signal without leaking private data. Open the support inbox and make sure someone is responsible for responding.
If a critical journey breaks, stop promotion and apply the planned recovery. Record the failing step and affected release before changing unrelated settings. A fast rollback with evidence is more useful than a string of untracked production edits.
Performance checks belong here too. Use lab testing to spot obvious problems before traffic arrives, then evaluate real-user data when sufficient data exists. Web Vitals guidance distinguishes laboratory and field measurement; a new site may not have representative field data yet. Test the page visitors actually land on, including any third-party scripts loaded after consent.
For public-page follow-up, connect the release record to your content map so an owner can identify which landing pages are most important to recover first.
7. Copy this website launch checklist template
Paste this table into a document or spreadsheet. Duplicate rows for individual URLs and journeys. Use statuses such as “not tested,” “pass,” “blocked,” and “not applicable”; a box alone cannot explain a release decision. This is a copyable website launch checklist template, not a downloadable PDF or an editable CodePic template.
| Phase | Item | Owner | Evidence | Status | Next action |
|---|---|---|---|---|---|
| Before | Production domain and HTTPS | Replace | Final URL and time | Not tested | Test host variants |
| Before | Public search directives | Replace | URL and directive | Not tested | Inspect page and headers |
| Before | Signup and email return | Replace | Test account and result | Not tested | Complete fresh-account journey |
| Before | Save and reopen | Replace | Record ID and result | Not tested | Reload after edit |
| Before | Payment and delivery, if applicable | Replace | Test event and access result | Not tested | Exercise success and failure |
| Release | Previous release and recovery | Replace | Release IDs and procedure | Not tested | Confirm migration compatibility |
| Release | Production smoke journey | Replace | Steps and observed result | Not tested | Run after deployment |
| Week one | Errors and support | Replace | Issue and affected journey | Not tested | Assign highest-impact fix |
| Week one | Search discovery | Replace | Exact URL and report date | Not tested | Investigate priority URLs |
For the fictional SaaS, the release is blocked if saved projects disappear or paid access is assigned to the wrong account. A delayed search crawl is recorded for investigation without claiming that the site has failed every launch condition. Keep those decisions separate using the discovery troubleshooting guide.
8. First week: follow evidence, not the number of checked boxes
Review errors, failed signups, unanswered inquiries, activation drop-offs, and delivery failures. Prioritize by customer impact. One lost paid order can matter more than several cosmetic reports. Compare events with a handful of real support cases to catch misleading tracking definitions.
Inspect search visibility for the pages that matter, record current status and observation time, and avoid interpreting every excluded URL as damage. Google can legitimately leave duplicates or private pages out of its index. A sensible first-week review asks whether important pages are accessible and discoverable, not whether every generated URL appears in search.
Keep a short change log. If you alter navigation, submit a new sitemap, and rewrite fifty pages at once, the next status update will tell you little about which action mattered. For a discovered URL, follow the URL-by-URL diagnosis. Once acquisition starts working, use the billing lifecycle guide to verify the paid experience continues to work after the first purchase.
