Launch checklist

Can you put this in front of customers on Monday? Paste a URL: 32 checks run against the public response and a bounded set of first-party scripts, and the 13 no passive scan can settle are handed to you.

Loading the checklist…

What it checks, and in what order

The sections run in order of what a mistake costs you. A live API key in the page source is a bill; a missing meta description is a slow leak. Both are on the list, and they are not treated as the same kind of problem.

  1. Security and dataWhat a stranger can read, reach or change.
  2. Core functionalityWhether the things that look clickable actually do anything.
  3. Search and sharingWhether the page can be found and looks like something when shared.
  4. Accessibility and mobileWhether it works on a phone, and with a keyboard.
  5. Content and credibilityWhether the words are about this product or about any product.
  6. Performance and resilienceWhat it costs to load, and what happens when something fails.
  7. Deployment and ownershipWhether this is a real deployment or a preview someone shared.

Automatic versus by hand

An automatic check is one public evidence can settle: response headers, security-cookie flags, the initial HTML, and up to six same-origin scripts plus three referenced source maps. Evidence is attached, and a missing risk is marked “not detected” rather than passed.

A manual check is one where the honest answer is “we cannot see that.” The scanner does not execute JavaScript, log in, or access your repository or database. So it never guesses at whether row-level security is on. It asks, records your answer in your own browser, and counts an unanswered blocker as unanswered rather than as a pass.

Your answers are stored in this browser under a single local-storage key. The URL you scanned, the hostname and the results are not stored — not on our servers and not in that key. Clearing it is one button on this page.

What this is not

It is not a security audit, an accessibility audit, or a penetration test. It cannot log in, execute your JavaScript, read your dependency tree, or test your backend and database policies. A page with no detected findings can still be wide open, which is why the coverage and limitations stay visible and why the best state this checklist reports is “ready to verify.”

If you want the other two tools: compare two versions of a page to see what a round of fixes actually changed, or read how a result gets disputed when the scanner gets one wrong.