A website can be “finished” and still not be ready to launch.

The contact form works on the developer’s laptop, but nobody checked where the leads go. The pages look polished at desktop width, but the pricing table breaks on a phone. Analytics is installed, but internal traffic and form completions aren’t being measured. Everyone approved the design, yet nobody agreed on what “approved” actually means.

That last problem causes the others. A launch checklist says what to inspect. Acceptance criteria define what must be true, who proves it, and what evidence closes the issue.

Below is a copy-ready set of 68 criteria for agencies, freelancers, in-house teams, and business owners. Use all of them for a new site, or remove the sections that don’t fit your scope. Each line is written as a pass-or-fail test. That makes it useful in a proposal, statement of work, QA ticket, or launch sign-off document.

How to use this template

Put these fields beside every criterion: owner, status, evidence, exception, and approver. Status should be Pass, Fail, Blocked, or Not Applicable. “Looks good” isn’t evidence. A screenshot, recorded test, URL, report, or successful test submission is.

Set three rules before testing starts:

  1. A critical failure blocks launch. Examples include a broken checkout, an exposed secret, a noindex directive on the production site, or a form that loses leads.
  2. A noncritical failure needs a named owner and due date. It doesn’t quietly disappear because the launch meeting ended.
  3. An exception needs written approval. Record the risk, reason, compensating control, owner, and expiration date.

Test the production build in its real hosting environment. Staging is useful, but it can have different caching, redirects, security headers, third-party scripts, and environment variables.

1. Scope and stakeholder approval

1. Every contracted page has a production URL. Match the signed scope or sitemap to the deployed URL list. Redirect intentionally removed URLs rather than leaving visitors at a dead end. Google’s guidance says permanent redirects are a strong signal that the target should become canonical (Google Search Central).

2. Every contracted feature has a named test case. “Booking system” is too vague. State the user action, input, expected result, and destination of the data.

3. Out-of-scope requests are recorded separately. A launch shouldn’t be held hostage by a new idea raised during final review. Put the request in the backlog with an estimate and decision owner.

4. The approved design and production build have been compared. Record intentional differences. Test the pages that represent each template, not only the homepage.

5. The business owner has approved legal names, addresses, phone numbers, prices, and offers. The developer shouldn’t be the final authority on business facts.

6. A launch decision-maker and backup are named. If the primary approver is unavailable, the team still knows who can authorize launch or rollback.

2. Content and brand

7. Every page has final copy. No lorem ipsum, “TK,” draft labels, internal notes, or placeholder testimonials remain.

8. Headings describe the page in a logical order. The HTML specification defines six heading levels, and authors should use levels to communicate section hierarchy (WHATWG HTML).

9. Every image has an intentional text alternative decision. Informative images need useful alt text. Decorative images should use an empty alt attribute so assistive technology can ignore them, following the W3C alt text decision tree.

10. Image rights and credits are documented. Store the license, purchase receipt, photographer release, or internal ownership record outside the CMS.

11. Downloadable files open and match their labels. Check PDFs, menus, spec sheets, catalogs, forms, and gated assets from a logged-out browser.

12. Dates and time-sensitive statements are accurate. Search for old years, expired promotions, “coming soon,” temporary hours, and deadline language.

13. Brand names and product terminology are consistent. Use one approved spelling and capitalization for each product, service, certification, and location.

14. Contact details are consistent across the site. Compare the header, footer, contact page, schema, location pages, privacy notice, and confirmation emails.

15. Every page has a useful next step. The call to action can be a quote, purchase, booking, phone call, related guide, or contact option. It should match the visitor’s likely intent.

16. Header and footer navigation work at every supported width. Test keyboard use as well as pointer and touch input.

17. Every internal link returns the intended page. A 200 response isn’t enough if the link lands on the wrong product, old hostname, or generic homepage.

18. External links use HTTPS when the destination supports it. Open a sample of them and confirm the destination still supports the surrounding claim.

19. Logo links return to the homepage. Test from nested pages and any alternate navigation state.

20. Breadcrumbs reflect the visible site hierarchy. If breadcrumb structured data is included, follow Google’s required properties and test the markup (Google Search Central).

21. Search returns relevant results and a useful empty state. Try exact product names, common variants, and a query with no match.

22. The primary lead journey works from landing page to confirmation. Submit a real test lead, verify delivery, inspect the CRM record, and confirm the visitor sees the right next step.

23. The primary purchase or booking journey works end to end. Test totals, taxes, delivery or appointment options, payment, confirmation, and cancellation rules where applicable.

24. The 404 page returns an actual 404 status. A friendly error page that returns 200 can confuse crawlers and reporting. Google documents these as soft 404s (Google Search Central).

4. Forms, email, and integrations

25. Required fields are marked in text and code. Don’t depend on color alone. Programmatic required states help browsers and assistive technology interpret the form (W3C Technique ARIA2).

26. Every field has an associated label. Placeholder text isn’t a substitute. W3C explains that explicit labels expand the clickable area and identify controls to assistive technology (W3C Forms Tutorial).

27. Invalid submissions show specific, recoverable errors. Errors should identify the field and explain how to fix it without deleting valid entries.

28. Valid submissions reach the correct destination. Verify the inbox, CRM, help desk, spreadsheet, or scheduling system with a unique test value.

29. Notifications have a working reply path. Confirm From, Reply-To, subject, recipient, and spam behavior. Never assume a delivered automation test proves a human can reply.

30. Duplicate submissions are controlled. Double-click the submit button and retry after a slow response. The result shouldn’t create duplicate orders or flood the CRM.

31. Spam controls don’t block ordinary users. Test with privacy extensions, keyboard-only input, and a slow completion time. Provide a recovery path if a challenge fails.

32. Consent language matches the data collected. The privacy notice should identify the actual tools and purposes in use, not a generic list copied from another site.

33. Integration failures are visible to an owner. A webhook failure needs logging or an alert. Silent data loss is a launch blocker.

5. Accessibility

Use WCAG 2.2 as the reference standard and record the target conformance level in the project scope. Automated scans help, but W3C says tools can’t determine accessibility on their own and human judgment is required (W3C Evaluating Tools).

34. All interactive controls work with a keyboard. Navigate forward and backward, open menus and dialogs, operate media, and submit forms without a mouse.

35. Keyboard focus is visible and isn’t hidden behind sticky content. WCAG 2.2 includes criteria for visible focus and focus not being obscured (W3C WCAG 2.2).

36. A skip link reaches the main content. It should appear on focus and work on every primary template.

37. Text and controls meet the project’s contrast target. Test real foreground and background colors, including hover, focus, disabled, error, and text-over-image states. The minimum Level AA ratios are defined in WCAG Contrast Minimum.

38. Content works at 200% browser zoom. It shouldn’t lose information or require two-dimensional scrolling except where WCAG permits it (W3C Reflow).

39. Dialogs keep focus under control. Focus moves into the dialog, stays within it while open, closes with the expected controls, and returns to a logical trigger.

40. Status messages are announced without stealing focus. Test form success, validation, search results, cart updates, and loading outcomes with a screen reader.

41. Video has accurate captions and audio-only information has an alternative. Use the media requirements that apply to the content under WCAG time-based media.

42. One manual screen-reader pass is complete. Cover the homepage, navigation, a content page, the primary form, and the main transaction flow.

6. Responsive and browser behavior

43. The site works at the agreed browser and device matrix. Name versions or support rules in the contract. “All browsers” isn’t testable acceptance language.

44. No page has accidental horizontal scrolling at 320 CSS pixels. WCAG’s reflow guidance uses 320 CSS pixels as the vertical-content reference width (W3C Reflow).

45. Touch targets are usable and don’t trigger neighbors. WCAG 2.2 defines a Level AA minimum target size of 24 by 24 CSS pixels, with specific exceptions (W3C Target Size).

46. Orientation changes don’t hide content or controls. Test portrait and landscape where the experience isn’t intentionally orientation-specific.

47. Text doesn’t overlap at supported widths and zoom levels. Check long names, button labels, navigation items, prices, error messages, and translated content if applicable.

48. Hover-only content has another access method. Menus, tooltips, and explanations must also work for keyboard and touch users.

7. Performance and resilience

49. Core Web Vitals pass the agreed threshold in the test environment. Google’s current “good” thresholds are LCP within 2.5 seconds, INP at or below 200 milliseconds, and CLS at or below 0.1 at the 75th percentile (web.dev). Lab tests can’t supply a real 75th-percentile field result for a new site, so record a lab budget now and review field data after launch.

50. Hero images are correctly sized and prioritized. Don’t lazy-load the likely LCP image. The browser needs to discover and request it early, as described in web.dev’s LCP optimization guidance.

51. Below-the-fold images and embeds don’t block initial rendering. Use native lazy loading where suitable and reserve dimensions to reduce layout shifts (MDN).

52. Fonts have an approved fallback behavior. Confirm text stays readable during load and that fallback-to-webfont swaps don’t create unacceptable layout movement.

53. A third-party failure doesn’t break navigation, forms, or checkout. Block analytics, chat, reviews, maps, and ad scripts one at a time and test the core journey.

54. The custom error and maintenance behavior is documented. Record who can activate it, what users see, and how the team communicates an outage.

55. A restore test has been completed. A backup file isn’t evidence of recoverability. Record the restore date, environment, duration, and person who verified it.

8. Search readiness

56. Production pages intended for search return 200 and permit indexing. Check HTTP headers, robots meta tags, canonical tags, authentication, and robots.txt together.

57. The XML sitemap contains canonical, indexable production URLs. Google recommends fully qualified absolute URLs and notes that a sitemap is only a hint, not a guarantee of crawling or indexing (Google Search Central).

58. robots.txt is on the production hostname and doesn’t block required assets. Google’s robots.txt specification describes the supported fields and crawler behavior (Google Search Central).

59. Every indexable page has a unique, descriptive title. Google recommends concise, descriptive title text and warns against repeated boilerplate (Google Search Central).

60. Canonical tags use the intended absolute production URL. Redirects, sitemap inclusion, and rel="canonical" can all signal canonical preference, with redirects and canonical annotations treated as strong signals (Google Search Central).

61. Structured data matches visible content and passes validation. Use Google’s Rich Results Test for supported search features and the Schema.org validator for general vocabulary checks.

62. Social sharing has been tested with the production URL. Confirm title, description, image, URL, and fallback behavior on the platforms the business actually uses.

9. Analytics and privacy

63. Analytics records production traffic once. Check for duplicate tags and confirm page views while using the platform’s debug or real-time view.

64. Primary conversions fire only after success. A form-start or button-click event isn’t a completed lead. Test success, validation failure, abandonment, and duplicate submission.

65. Campaign parameters survive the journey where required. Test landing URL, internal navigation, form submission, CRM record, and thank-you page reporting.

66. Consent choices are honored. Rejecting optional categories should prevent those tags from operating as defined by the site’s policy. Acceptance shouldn’t be easier to find than rejection where applicable.

10. Security, ownership, and launch control

67. HTTPS, access, and ownership checks pass. Every public URL should redirect to HTTPS without loops or mixed content. Review production response headers against the OWASP Secure Headers Project. Confirm the business controls the domain registrar, DNS, hosting, CMS owner account, analytics, tag manager, search tools, payment accounts, and recovery methods. Remove shared passwords, unnecessary launch accounts, debug output, sample users, and exposed environment files.

68. The launch and rollback plan has been rehearsed and signed. Record the change window, DNS or deployment steps, freeze time, smoke tests, monitoring owner, rollback trigger, rollback steps, and final approver. Lower DNS TTL ahead of a planned change only when it fits the migration plan. DNS caches can retain records until their TTL expires (Cloudflare Learning Center).

Copy-ready sign-off block

Paste this at the end of your project document:

Release: [name/version]
Production URL: [URL]
Test window: [date and time]
Criteria passed: [number]/68
Not applicable: [criterion numbers and reasons]
Approved exceptions: [links]
Open noncritical issues: [links, owners, due dates]
Rollback owner: [name]
Business approver: [name/date]
Technical approver: [name/date]
Decision: Launch / Hold

Acceptance criteria won’t eliminate every launch problem. They will stop “done” from meaning five different things to five different people. More importantly, they create a record of what the team tested, what the owner accepted, and what still needs attention.

If you’d rather have a web team handle the build, testing, and launch accountability, tell us what you’re working on.