Website Design Checklist: What to Review Before Launch

A website is ready to launch when its public pages are accurate and discoverable, visitors can use the important interactions, the production site is served securely, and the team can detect and respond to problems. Review the actual production configuration and the user journeys the site depends on; a checklist or automated scan alone cannot certify a site or predict its search performance.

Use the checklist below before launch, then repeat the checks that can change during deployment—such as redirects, indexing settings, forms, integrations, and performance—against the live production host.

Check that the homepage explains who the site serves, what it offers, and what visitors can do next.
Review page titles, headings, body copy, button labels, form labels, contact details, and calls to action for accuracy and consistency.
Check main navigation, internal links, and footer links. Look for broken destinations, misleading labels, missing expected pages, and pages that lead to a dead end.
Verify that important images and media have suitable alternatives: useful text alternatives for images where appropriate, and captions or transcripts for relevant audio and video.
Remove placeholder copy, test content, sample accounts, outdated promotions, and staging references.
Check that legal, privacy, and policy pages reflect the site’s actual practices and are reachable where visitors expect them.

2. Check accessibility and interaction

Use W3C’s WCAG guidance as a standards reference. WCAG 2.2 organizes success criteria around perceivable, operable, understandable, and robust content. Choose and state an appropriate conformance target for the project and any applicable obligations; this checklist is not a legal determination.

Keyboard: Navigate without a mouse. Confirm interactive controls can be reached and operated, the focus indicator is visible, and the focus order makes sense.
Focus and overlays: Open menus, dialogs, sticky headers, and consent interfaces. Make sure they do not hide the currently focused control or trap keyboard users without a clear way out.
Text and meaning: Check that color is not the only way information is conveyed and that text and interface elements remain distinguishable.
Images and media: Review text alternatives and media captions or transcripts where they are needed. WCAG’s text-alternative requirement has defined exceptions, so assess the purpose of each non-text item.
Targets and zoom: Try common mobile viewport sizes and browser zoom. Check that controls remain usable and that content does not become clipped or overlap.
Forms: Complete each form from start to finish. Check labels, instructions, required-field cues, validation, error recovery, confirmation, and the expected delivery or system update.
Accounts and checkout: Where relevant, examine sign-in, authentication, account creation, and payment flows. WCAG 2.2 includes criteria for minimum target size, focus not obscured, redundant entry, and accessible authentication.

Automated accessibility scans can find some issues, but they cannot supply all manual checks or assistive-technology evaluation. Do not claim WCAG conformance based only on a scanner: conformance is determined by meeting the applicable success criteria.

3. Verify search visibility and launch indexing

For pages intended for public discovery, inspect the production version for accidental crawl blocks and noindex directives.
Keep staging, private, and test content from being exposed as public launch content. Verify the deployed host and configuration rather than assuming staging settings carry over correctly.
Check canonical URLs, page titles, descriptions, internal links, and sitemap configuration where applicable.
Open the production URLs and confirm redirects resolve to the intended canonical HTTPS pages.

Google Search Essentials describes the fundamentals for eligibility in Google Search. Eligibility does not guarantee indexing or rankings. Check the site’s actual deployed configuration; a pre-launch checklist cannot promise a search outcome.

4. Check HTTPS and production security basics

Load the public site over HTTPS and check that the certificate is valid in the browsers you support.
Test expected HTTP-to-HTTPS redirects and confirm they reach the canonical destination without loops or unexpected intermediate pages.
Look for browser security warnings and mixed content, where a secure page requests resources over an insecure connection.
Check that staging settings, test accounts, sample data, and secrets have not carried into the public environment.
For accounts, payments, or personal data, include a security review appropriate to the site’s technology and data, plus a clear incident and rollback procedure.

Google recommends HTTPS for user and site security in its Search Central guidance. These checks are a launch baseline, not a complete security audit; the right additional review depends on the application and the information it handles.

5. Measure performance on representative pages

Choose representative pages, including media-heavy pages and important landing or checkout pages.
Review them at mobile and desktop sizes and under realistic device and network conditions.
Collect field data when available. Google points site owners to the Core Web Vitals report for site-wide field data and PageSpeed Insights to investigate individual pages.
Review the current Core Web Vitals—LCP, INP, and CLS—in Google’s live guidance, and use the measurement tools to collect the site’s readings. Do not infer a result without measurement.
Investigate pages that need attention, make targeted changes, and measure again.
Repeat after deployment: production hosting, final media, third-party scripts, and real traffic can affect performance. This is a practical reason to recheck measured pages, not a prediction about any particular site.

Google says good Core Web Vitals support Search success and user experience, but readings must be collected from the site. See Google’s Core Web Vitals guidance and the Web Vitals overview.

6. Exercise critical user journeys in production

Write down the actions that matter to this site’s audience, then complete each one as a visitor would. Depending on the site, that can include:

Submitting a contact, quote, newsletter, or support form and verifying both the confirmation shown to the visitor and the expected receipt by the destination system.
Creating an account, signing in, recovering access, and signing out.
Searching, filtering, booking, buying, downloading, or completing another primary task.
Opening embedded media and third-party integrations, and checking that analytics or consent settings behave as intended.
Following important internal and external links, including redirects.

Use production-safe test data and accounts. Confirm that the team knows how to monitor for launch issues and restore service or content if a defect appears. Backup, restore, and rollback steps depend on the platform, so document the ones that apply to this deployment.

7. A repeatable pre-launch review sequence

List the critical pages and journeys. Include representative content pages, forms, and any account, checkout, booking, or integration flow that matters.
Review content and links. Check copy, navigation, contact information, media alternatives, and expected destinations.
Test accessibility by hand. Use keyboard navigation, browser zoom, and the site’s key interactions. Record issues and the relevant WCAG success criteria where applicable.
Inspect production configuration. Check HTTPS, redirects, indexing controls, canonicals, and sitemap behavior on the live host.
Measure representative pages. Collect Core Web Vitals data when available and investigate individual pages that need attention.
Complete the user journeys. Verify the visitor-facing result and the downstream delivery or system action.
Assign fixes and recheck. Give each issue an owner, resolve launch blockers, and repeat affected checks after the final deployment.

8. Capture production pages for visual review

A screenshot can help reviewers compare production pages at a consistent viewport, inspect a long page, or attach a visual record to a launch issue. It does not replace keyboard, form, accessibility, security, or performance checks. For a one-off check, use your browser’s built-in screenshot or print controls. For repeatable captures, automate a browser and save the resulting image.

npm install playwright
npx playwright install chromium

Save this as capture.mjs, then run node capture.mjs https://example.com. Replace the example URL with a page you are authorized to review.

import { chromium } from 'playwright';

const url = process.argv[2];
if (!url) throw new Error('Usage: node capture.mjs https://example.com');

const browser = await chromium.launch({ headless: true });
try {
  const page = await browser.newPage({ viewport: { width: 1440, height: 1000 }, deviceScaleFactor: 1 });
  const response = await page.goto(url, { waitUntil: 'networkidle', timeout: 60000 });
  if (!response) throw new Error('Navigation did not return a main document response');
  console.log(`HTTP ${response.status()} ${page.url()}`);
  await page.screenshot({ path: 'launch-review.png', fullPage: true });
} finally {
  await browser.close();
}

For pages that continuously poll or load third-party resources, networkidle may never occur. In that case, wait for a meaningful selector or use a short delay after DOM content loads. Full-page captures can be large, and some pages load lazy content only as it enters the viewport; inspect the saved result and adapt the capture flow to the page.

9. Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server from ScreenshotNeo. One GET request can return a PNG, JPEG, WebP, or PDF. See the API documentation for parameters and options.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
r.raise_for_status()
with open("shot.webp", "wb") as f:
    f.write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await Bun.write('shot.webp', res);

Cookie and consent banners, newsletter popups, and chat widgets can be removed before capture; each cleanup step can be turned off.
Bot checks or CAPTCHAs, blank pages, timeouts, failed loads, and cache hits are not billed. Response headers identify the page verdict and billing status.
An MCP server lets AI agents use take_screenshot, get_page_info, and capture_pdf.
The Free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000. Every feature is available on every plan.

10. Screenshot options for launch reviews

Choose capture settings to match the review task. ScreenshotNeo supports the following options; consult the documentation for request parameter names and usage details.

Review need	Useful capture options
Review a long landing page	Full-page capture with lazy images loaded
Inspect one component	Capture an element by CSS selector; hide selectors that obstruct the review
Compare appearance	Dark mode, 12 device presets, custom viewport, retina scale, transparent background, or image resizing
Check a printable document	PDF with paper size, margins, landscape orientation, and page ranges
Test a rendered state	Custom CSS or JavaScript, click an element, wait for a selector, delay, or network idle
Control page loading	Block ads, trackers, requests, or resource types; set headers, cookies, user agent, authorization, timezone, or geolocation
Automate repeat checks	Choose cache TTL, use async jobs with signed webhooks, capture up to 100 URLs per bulk call, and check usage through the usage API

Signed links support public image tags, and an OpenAPI specification is available. ScreenshotNeo accepts parameter names used by other screenshot APIs to ease migration. Keep access keys private; for public pages that need an embeddable image, use the signed-link option rather than exposing a secret key.

11. Troubleshooting launch review captures

Symptom	Likely cause	What to check
Browser reports a certificate warning	Invalid, expired, or incorrectly configured certificate	Check the certificate and production HTTPS configuration, then retest the canonical URL.
HTTP and HTTPS show different pages or redirect repeatedly	Inconsistent host or redirect rules	Trace the redirect destination and verify the intended canonical HTTPS URL.
Public page does not appear eligible for discovery	Accidental crawl block, `noindex`, or incorrect canonical	Inspect the deployed page and its production indexing configuration.
Form looks successful but nothing arrives	Front-end confirmation is disconnected from delivery or a downstream integration	Check the receiving inbox or system using production-safe test data.
Keyboard focus disappears under a menu or sticky header	Overlay or layout covers the focused item	Test open and closed states with the keyboard; adjust focus handling or layout and retest.
Screenshot misses content or times out	Lazy loading, persistent network activity, slow navigation, or a page-specific wait condition	Wait for a meaningful selector or use a bounded delay; verify the resulting capture.
Automated scan passes but users still encounter an access barrier	Automated checks do not cover every interaction or assistive-technology experience	Do manual keyboard, zoom, form, and relevant assistive-technology checks.
Production screenshot differs from staging	Deployment settings, final assets, third-party scripts, or host-specific behavior differ	Review the live production page and repeat the relevant configuration and interaction checks.

12. Performance, reliability, and cost considerations

Measure instead of guessing: Core Web Vitals and other performance readings depend on the pages and conditions measured. Use field data when available and page-level investigation for specific URLs.
Recheck changed pages: Deployment, final assets, third-party scripts, and real traffic can alter behavior. Build a post-deployment review into the launch process.
Keep captures scoped: Capture representative pages and states rather than generating images without a review purpose. Full-page screenshots and high-resolution captures can be larger and slower to handle.
Plan for failure: Browser automation can encounter timeouts, dynamic content, and external integrations. Use explicit waits tied to page behavior, timeouts, and a retry policy appropriate to the workflow; inspect failures instead of treating every saved image as proof of a successful page.
Account for recurring tools: Browser automation has setup and execution costs in the environment where it runs. ScreenshotNeo plans are Free for 1,000 shots/month, Starter $5 for 3,000, Growth $15 for 15,000, Pro $39 for 60,000, Scale $99 for 250,000, and Business $249 for 1,000,000; yearly billing gives two months free. Every feature is on every plan.
Keep the checklist tailored: There is no single product or test suite required for every launch. Base the review on the audience, content, forms, integrations, and business-critical flows of the site.

13. Frequently asked questions

Does passing this checklist guarantee a successful launch?

No. It provides a structured review, but a site can still encounter defects or operational issues. Monitor the live site and have a response and rollback process appropriate to the project.

Does a good accessibility scan prove WCAG conformance?

No. A scanner can identify some issues, but conformance depends on the applicable success criteria and needs review beyond automated results.

Will a technically eligible page rank in Google?

Eligibility is not a guarantee of indexing or ranking. Search outcomes depend on more than this launch checklist.

Should every page be captured before launch?

Usually, start with representative templates and the pages or states tied to critical journeys. Expand coverage where page-specific layouts or behavior warrant it.

When should the team repeat the review?

Repeat checks after changes that can affect the public experience, including deployment, content updates, navigation or form changes, and integration changes. Prioritize production behavior for launch-critical paths.