Launch Ready
How we scan
A score is only useful if you know how it was produced. This page condenses the public Launch Ready scan documentation: what the crawler fetches, how the number is calculated, and how the Agency API fits in.
What a scan is
A scan is a one-off crawl of the site you point Launch Ready at, followed by a fixed set of deterministic checks. It runs on Launch Ready's 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.
The crawler identifies itself as LaunchReady/1.0 (+https://uselaunchready.com; pre-launch QA crawler). Full method notes live at uselaunchready.com/how-we-scan.
The crawl
- Starts at the saved project URL, then fetches /robots.txt and /sitemap.xml from the same origin and checks the TLS certificate.
- Queues same-site pages from the sitemap and in-page links. Off-site links are never crawled.
- robots.txt is an input to the report; it does not narrow the crawl. The plan's page limit is the constraint that keeps a scan small.
- Per request: 12 second timeout, at most 8 redirects, at most 2 MB of response body, at most 4 pages at a time.
- Hosts that resolve to a private, loopback, or reserved address are refused. You cannot use the scanner to reach an internal network.
- If the project stores HTTP basic auth for staging, those credentials are sent on that scan and nowhere else.
Page limits per plan
| Plan | Pages per scan | Lighthouse |
|---|---|---|
| Free | 25 | Not run |
| Pro | 200 | Homepage |
| Agency | 300 | Homepage |
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.
Rendering and LighthousePro
After the HTTP crawl, a bounded set of pages is re-opened in headless Chromium so JavaScript-rendered content can be read. The homepage is always included, capped at 15 pages or the plan page limit, whichever is lower.
On paid plans, Google Lighthouse runs once per scan on the homepage only, for performance, accessibility, SEO, best-practices, and Core Web Vitals. It is not run per page, and it is not run on Free. If Lighthouse fails, the rest of the scan still completes.
What we do not touch
- Never submit a form, click a purchase button, or trigger a checkout.
- Never log in as one of your users. The only credentials sent are HTTP basic auth you chose to store on the project.
- Do not write to your site, and do not follow links off your domain.
- Do not bypass bot protection. If a page blocks the crawler, the report says so.
How the score is built
Every finding lands in one of eight categories, and a rule that fires on several pages counts once. Each category starts at 100. An important issue takes 20% of what is left; an improvement takes 6%. A single launch-blocking issue takes the category to 0. The overall score is the weighted average of the eight categories.
| Category | Weight |
|---|---|
| Technical reliability | 25 |
| SEO / indexability | 20 |
| Analytics / marketing | 15 |
| Forms / conversion | 15 |
| Performance | 10 |
| Content QA | 5 |
| Accessibility | 5 |
| Compliance signals | 5 |
One launch-blocking issue caps the overall score at 35. One important issue caps it at 69. A site that is noindexed in production cannot show a 90 because everything else passed.
Readiness labels
- 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.
Rule tuningPro
A workspace can tune rules per project: ignore a rule, change the severity it reports at, or require a tag or page of its own. An ignored finding still appears, marked as suppressed, but is excluded from the score, readiness label, comparison, and alerts. Every override records who made it and why.
API and deploy hookPro
The Launch Ready API is available on the Agency plan. Base URL: https://uselaunchready.com/api/v1. Create a key in Settings → API keys (lr_live_…) and send it as a bearer token. The same capabilities are also exposed over MCP at https://uselaunchready.com/api/mcp.
- GET /api/v1/projects — list websites and latest completed scans.
- POST /api/v1/projects/{id}/scans — start a scan; supports Idempotency-Key.
- GET /api/v1/scans/{id} — poll until completed or failed.
- GET /api/v1/scans/{id}/findings — open findings by default; evidence stays in the app.
- POST /api/v1/scans/{id}/share — mint a client-facing share link.
- POST /api/v1/hooks/scan?project=<id> — deploy hook; safe to fire twice for one deploy.
Full request and response shapes, rate limits, GitHub Actions, and MCP client examples are in the live API reference at uselaunchready.com/docs/api.
What this is not
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.
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.