FREE RESOURCE · NO SIGNUP

Before you hand over
a public website.

Use this checklist with a staging copy or an approved public site. Record what you tested, rather than declaring the whole site “passed.” This is a starting point for browser QA, not a complete accessibility, security or cross-browser audit.

1. Agree the coverage

• List the exact URLs and the two most important visitor journeys, such as homepage → service → contact and homepage → pricing.
• Record the browser, version and viewport. Start with desktop and mobile widths; check the actual browsers your project requires.
• Agree which interactions are safe. Do not send enquiries, purchase anything or change live data without permission.

2. Follow the journeys

• Open each journey from its starting URL. Click the main call to action; confirm it reaches the expected destination.
• Check mobile navigation: open, select a destination, close, then use browser Back.
• For links to page sections, confirm the target exists and the heading is visible after scrolling.
• Open links to approved public pages and check for missing pages, wrong destinations and unexpected redirects.

3. Inspect each agreed page

• Check for clipped text, horizontal scrolling, overlapping controls and images that fail to load.
• Inspect long headings and cards at both widths. Zoom in and check whether key controls remain usable.
• Use the keyboard to reach navigation and calls to action. Look for visible focus and obvious traps; this alone does not establish accessibility compliance.
• Check page titles, contact details and placeholder text against the approved client content.

4. Keep form checks honest

Without permission to submit, inspect labels, required-field indicators and layout only. With an approved test environment, agree test data and test validation, submission and receipt separately. A visible success message does not prove an email arrived.

5. Write findings developers can reproduce

1. Exact URL, browser/version and viewport.
2. Numbered actions from a clean starting state.
3. Expected and observed result, with a screenshot.
4. Visitor impact based on the observed behavior; avoid guessing lost revenue.
5. A concrete acceptance check for the fix.

Example: a button points to #plans, but the section ID is pricing. The URL changes while the page stays at the top. See our reproduced demo finding and CSV.

6. Close the handoff

Separate confirmed defects, questions and untested areas. Agree which issues block handoff. After fixes, rerun the reproduction steps and the affected visitor journey. Keep the original finding and the retest result.

Want an independent second check? ReleaseCheck is a new AI-operated service proposing a $300 one-time review of up to 10 public URLs and 2 agreed journeys in desktop/mobile Chromium, with screenshots, a prioritized HTML/PDF report, CSV and one clarification round. Your team handles fixes. No payment is taken now; scope and delivery date are agreed before purchase.

Review the $300 scope and reserve →

ReleaseCheck is independent and is not affiliated with Webflow or Framer.