How we scan

A scan is a one-off crawl of the site you point us at, followed by a fixed set of deterministic checks. It runs on our own worker, not in your browser, and it does not keep a session on your site afterwards. Nothing is scanned on a schedule unless you turn on monitoring for that project.

• We start at the project URL you saved, and first fetch /robots.txt and /sitemap.xml from the same origin. We also open a TLS connection to the host to check the certificate.
• We queue pages from the sitemap and from links we find, but only ones on the same site as the start URL, and only ones whose path looks like a page rather than an asset. Off-site links are never crawled. Links that differ only in their query string (filters, sorting, tracking) wait until the plain pages are done, so the page limit goes to distinct pages.
• What we do with robots.txt: we read it so the checks can tell you whether your site is blocking search engines. It is an input to the report — it does not narrow our own crawl. We only fetch pages on a site you asked us to scan, up to your plan's page limit, which is the constraint that keeps a scan small.
• Each request identifies itself as LaunchReady/1.0 (+https://uselaunchready.com; pre-launch QA crawler).
• Per request: 12 second timeout, at most 8 redirects, and at most 2 MB of response body read. A larger page is still a working page: we judge it on what we read. We fetch at most 4 pages at a time, so a scan behaves like a handful of visitors, not a load test.
• After the page crawl we check linked assets and outbound links so broken ones can be reported: up to 40 off-site targets and up to 80 checks in total, each with a shorter 8 second timeout. Only an HTTP error, or a domain that does not exist, counts as broken. A page that does not answer in time is listed as not checked, not reported as broken.
• Hosts that resolve to a private, loopback, or reserved address are refused before a connection is made, and the address we checked is the address we connect to. You cannot use the scanner to reach an internal network.
• If the project stores HTTP basic auth for a staging site, those credentials are sent on the requests for that scan and nowhere else. They are encrypted at rest.
• On production scans we flag HTTP redirects that pass through or end on a staging or preview host, including hosts you list as previous staging domains. Coverage is limited to redirects the crawl already encounters within normal limits — we do not separately crawl previous staging domains or invent historical URLs.

How many pages one scan will fetch:

A scan stops when it reaches the limit, so a large site is sampled rather than exhausted. The report says how many pages were fetched.

Plenty of sites put their real content behind JavaScript, so after the HTTP crawl we re-open a small, bounded set of pages in a headless Chromium and re-read the DOM. The set is chosen deterministically: the homepage always, then pages that look thin or look like a single-page-app shell, then one page per distinct URL shape — capped at 15 pages (or your plan's page limit, whichever is lower).

Each render gets 10 seconds to load and 1.5 seconds to settle. A page that times out is retried up to 3 more times, with 15, 20, and 30 seconds to load, and all renders in one scan share a 6-minute budget. Every request the browser makes goes through the same private-address check as the crawler; anything that fails it is aborted. If Chromium is unavailable or a page still fails to render, the scan completes anyway: the findings from that page are marked as HTML-only and your coverage summary shows the full reason.

On paid plans we run Google Lighthouse once per scan, on the homepage only, for its performance, accessibility, SEO and best-practices categories, plus the Core Web Vitals timings. It is not run per page, and it is not run at all on Free. If Lighthouse fails, the rest of the scan still completes and the report says so.

• We never submit a form, click a purchase button, or trigger a checkout.
• We never log in as one of your users. The only credentials we ever send are the HTTP basic auth you chose to store on the project.
• We do not write to your site, and we do not follow links off your domain.
• We do not bypass bot protection. If a page blocks us, the report says so.

Per page we keep the requested URL, the final URL after redirects, the status code, content type, response time, response size, any fetch error, and whether the page was rendered. We do not keep a copy of your page bodies after the scan finishes.

Per finding we keep the rule, category, severity, the page it was found on, a short evidence excerpt that shows why the check fired, and the recommendation.

When Chromium renders the homepage we also keep a screenshot of its first screen, shown on the report. Screenshots are deleted after 30 days, except the newest one for each project. The evidence excerpts and that screenshot are the only page content that outlives the scan.

See the Privacy Policy for retention and deletion.

Every finding lands in one of eight categories, and a rule that fires on several pages counts once, as one issue: the report lists its pages under it. Each category starts at 100, and every important issue takes 20% of what is left and every improvement 6%, so one important issue leaves 80 and two leave 64. A single launch-blocking issue takes the category to 0. The overall score is the weighted average of the eight:

Some checks are advisory: security headers, structured data (JSON-LD), incomplete link previews, hreflang and llms.txt. They arrived after sites already had scores, so they are listed as improvements and counted in the category tallies, but they do not change the score or the readiness label, and each says so. A rule override that re-grades one makes it count like any other finding.

• Critical blocker detected — at least one launch-blocking finding.
• Not ready — at least one important finding, or a score under 60.
• Ready with warnings — at least one improvement finding, or a score under 85.
• Ready — nothing above passed-level, and a score of 85 or better.

A workspace can tune rules per project: ignore a rule, change the severity it reports at, or require something of its own (a tag on the homepage, a page that must exist). Tuning changes the score, deliberately and visibly.

• An ignored finding still appears on the scan and in the report, marked as suppressed, but it is excluded from the score, the category counts, the readiness label, the new/resolved comparison, and alerts.
• A re-graded finding scores at its new severity; the report keeps the original one next to it.
• A requirement you add produces a normal finding when it is not met, and scores like any other.
• Every override records who made it and why, so a client report can show what was silenced and on whose say-so.

Launch Ready is a pre-launch QA aid. It is not a WCAG audit or certification, not legal or compliance advice, not a privacy assessment, and not a penetration test. It does not compare screenshots, does not run Lighthouse on every page, and does not test flows that require logging in — checkout, dashboards, and members-only content are outside what an automated crawl can see.

Automated checks miss things and sometimes flag signals that need a human look. Use the report as input to your launch decision, not as the decision.