A release check that catches real landing-page failures

What to verify between “the build passed” and “people can use it”

A successful production build answers a narrow question: can the toolchain create an output bundle? A landing page can pass that check and still ship with a broken form, clipped mobile content, incorrect canonical address or links that work only on the developer’s machine.

Define the release evidence

Before testing, write down the observable result. For a simple landing page, a useful release record contains the deployed address, commit or version identifier, build result, checked viewports, primary action result, and the HTTP status of important routes. This prevents “looks fine” from becoming the only acceptance criterion.

Check the production path

Open the actual HTTPS address, not a local preview. Confirm that the main page returns a successful status and that redirects settle on the intended host and scheme. Test every prominent action: navigation, checkout or contact link, download, and any form submission. External links should point to the intended destination without staging parameters.

If the site uses client-side routing, load a nested route directly in a fresh request. A route that works only after navigating from the homepage usually indicates missing hosting rewrites.

Use responsive checks that expose constraints

Testing one narrow phone and one common desktop width catches more than dragging the browser until it “seems responsive.” At each width, inspect:

• horizontal overflow and clipped controls;
• headings that force awkward single-word lines;
• tap targets and fixed overlays;
• forms when the on-screen keyboard reduces height;
• tables, code blocks and long URLs;
• navigation at 200% text zoom.

Add a mid-width check when the layout changes columns. Most responsive defects appear near a breakpoint, not at the smallest or largest viewport.

Verify metadata as data

The browser title, description, canonical link and indexing directives should match the production page. Confirm that canonical URLs use the public HTTPS origin and that test environments are not referenced. If a social preview image is intentionally configured, request its absolute URL and verify its dimensions and content type.

Separate warnings from release blockers

A missing decorative asset can be a warning. A primary action that fails, a public page marked noindex, unreadable text, an exposed secret or a mobile layout that hides the offer is a blocker. Classifying findings keeps the release decision consistent.

The final record should state what was verified and what was not. “Published successfully” is justified only when the production address serves the expected version and the essential user path works. Traffic, leads and sales remain separate measurements collected after release.