Test a web page before launch

Define the release candidate

A launch test applies to one immutable artifact, not to “the site” in the abstract. Record the commit or source state, build identifier, Preview URL, environment, content inventory, and planned production host. If the build changes after testing, the evidence no longer covers the artifact you intend to promote.

Write a short release contract before opening the browser. List the routes and tasks that must work, the browsers and viewport classes you support, the expected integrations, the canonical domain, and explicit exclusions. Mark which checks are automatic, manual, or dependent on an authenticated external service.

Freeze factual copy and configuration long enough to test them together. A late metadata edit can break a title limit; a late environment change can send a form to the wrong destination. Urgent corrections should produce a new Preview and a focused rerun plus any full gates affected by the change.

Verify the served response first

Request representative pages directly rather than reaching all of them through client navigation. Confirm successful pages return an appropriate 2xx status, missing pages return 404, and permanent URL moves use a permanent redirect. Follow the redirect chain from HTTP, alternate hostnames, and legacy paths to one canonical HTTPS destination without loops or avoidable hops.

Inspect the rendered head on the served page. Titles and descriptions should be unique and truthful. The canonical must name the production URL rather than the Preview host. Language, viewport, icons, social metadata, and structured data must match visible content. Do not infer these values from a source component; framework rendering and environment configuration can change the response.

Fetch robots.txt, the sitemap, feed, manifest, and other public machine surfaces. Sitemap URLs should be canonical, indexable, and successful. Confirm that private or Preview environments are protected without shipping the same restriction to Production. Validate structured data and check that its claims are visible to a person on the page.

Inspect response headers. Confirm content type and character encoding, a deliberate referrer policy, framing controls, content security policy where used, transport security on the canonical host, and appropriate caching. A policy present only in a configuration file does nothing if the platform does not send it.

Read the page without presentation

Disable CSS or examine the unstyled document. The reading sequence should still communicate header, navigation, main content, supporting regions, and footer. Check one descriptive page heading, logical subsections, real anchors for navigation, buttons for actions, persistent labels, table headers, and useful image alternatives.

Disable JavaScript and identify what remains. A static article should remain readable. Navigation and ordinary form submission should use progressive enhancement when the product permits it. If a task genuinely requires script, the failure state should explain that requirement instead of presenting an empty page or inert control.

Inspect the accessibility tree on representative pages. Confirm useful names, roles, states, landmarks, and descriptions. Automated rules can identify many invalid relationships, but manual inspection is required to judge whether the structure and language make sense.

Complete every task with a keyboard

Start at the browser chrome, press Tab once, and verify the skip link appears when the design includes one. Traverse forward and backward through the entire page. Focus must be visible, ordered meaningfully, and absent from hidden or decorative elements. Sticky layers must not cover the focused target.

Operate every menu, disclosure, dialog, tab set, form, and media control with the expected keys. Escape should close modal layers, and focus should return to the control that opened them. Focus must stay inside a modal dialog while it is open and must not become trapped in ordinary page content.

Repeat the primary task with a representative screen reader when the release risk warrants it. Listen for headings, landmarks, link purpose, field labels, errors, and dynamic status. Record the browser, screen reader, version, and limitations instead of converting one successful journey into a universal conformance claim.

Test reflow and resilient content

At 320 CSS pixels, inspect each representative template for page-level horizontal scrolling, clipped controls, overlapping text, and inaccessible off-screen content. Some tables and code samples legitimately need local two-dimensional scrolling; their container should scroll without forcing the whole page to do so.

Zoom text to 200 percent, enlarge the default font where possible, and test at intermediate widths rather than only named devices. Replace short test copy with long headings, URLs, validation errors, and realistic navigation labels. Confirm images scale, grids collapse at content-driven boundaries, and the DOM order continues to match visual and keyboard order.

Test reduced motion, forced colours, dark mode when supported, and high contrast for critical controls. Pause or remove unnecessary animation and ensure focus, errors, selection, and disabled states do not rely on colour alone. Check touch targets on a real or accurately emulated narrow device.

Exercise forms and external boundaries

Submit every form successfully and invalidly. Confirm labels, instructions, required states, error association, preserved input, pending state, duplicate submission handling, and recovery from network failure. Verify the actual destination rather than accepting a success message as proof.

Test authentication, payments, email, storage, analytics, search, and webhooks against their intended Preview or test-mode accounts. Inspect provider records or logs for the exact request. Do not expose live customer data or real payment credentials during testing, and do not claim that a mocked integration proves the external boundary.

Review privacy behavior in the browser. Identify cookies, local storage, third-party requests, form fields, analytics events, and embedded resources. Visible consent and policy language must match the behavior. Confirm secrets remain server-side and logs omit unnecessary personal data.

Measure loading and failure behavior

Use a throttled connection and a fresh cache. Watch when the main content, primary image, fonts, and interactive controls become available. Record Core Web Vitals from appropriate lab and field sources without treating one desktop run as representative of all users.

Inspect image dimensions and formats, font loading, cache headers, compression, render-blocking resources, client JavaScript, and third-party requests. Remove dependencies without a clear purpose. Reserve space for media and dynamic content so late responses do not move the interface under a pointer or finger.

Force slow, empty, partial, and failed responses. A useful failure state names what failed, preserves safe work, and offers a retry or next step. Avoid indefinite spinners, silent form failures, and optimistic success that appears before the server or provider has accepted the operation.

Check content and link integrity

Read the page as an editor. Verify names, prices, dates, statistics, legal terms, and product behavior against authoritative records. Remove placeholder claims, dead controls, draft notes, generated citations that do not support the text, and language promising rankings, compliance, or guarantees without evidence.

Crawl internal links and assets. Confirm every navigation item, contextual link, download, image, script, and stylesheet resolves as intended. Check outbound links manually when they are important to the task and ensure external destinations do not receive sensitive query data.

Search, feeds, sitemaps, navigation counts, and public copy should derive from the same registry where the architecture supports it. Reconcile any documented counts against the build rather than copying an old roadmap number forward.

Rehearse promotion and rollback

Know who can promote, how the exact artifact becomes Production, which domain and environment variables change, and how to restore the preceding deployment. Record the known-good deployment before launch. A rollback plan is useful only when it identifies a recoverable artifact and the person authorized to use it.

Promote the tested Preview instead of triggering an untested rebuild when the platform supports that operation. Immediately repeat a compact canonical smoke: home page, primary navigation, one content route, one missing route, sitemap, critical form or checkout, headers, and logs. Then run the broader production matrix proportionate to the release.

Watch errors, external provider activity, analytics health, and user reports after real traffic reaches the release. Keep a fixed observation window and distinguish absence of errors from absence of traffic. If a gate fails, stop the rollout or restore the recorded known-good artifact before beginning a broad repair.

Publish the evidence honestly

A release record should name the artifact, Preview and Production identifiers, local gates, browser journeys, live requests, log window, and unresolved limits. Do not write “fully accessible,” “secure,” or “all tests passed” when important manual or external checks were not run.

This procedure reduces preventable launch defects; it does not certify every browser, user, legal requirement, security threat, or future content change. The durable habit is to test one exact artifact, promote that artifact, verify the canonical service, and preserve evidence another person can reproduce.