What a static HTML scan can and cannot tell you
LaunchForge's public scanner fetches a page once, over HTTPS, and examines the HTML that came back — within bounded size, redirect and time limits. It never runs JavaScript, never renders the page, and never executes anything the page contains. That bounded, non-executing design defines exactly what the results mean.
What the scanner observes
- The HTTP status of the response (did the page load with a 200?).
- Whether the address uses HTTPS.
- On-page elements present in the returned HTML: title, meta description, headings, viewport and language declarations, canonical link, JSON-LD blocks, Open Graph tags, image alt attributes and the amount of text.
Each result is reported with the evidence observed — for example, the measured title length or the number of H1 headings found.
What it cannot observe
- What Googlebot saw. Another crawler may receive different HTML — sites can serve different content by user agent, location or A/B test. One fetch is an observation, not proof of what any search engine indexed.
- Indexing, rankings or traffic. Only Google Search Console shows whether Google indexed a page and how it performs in search.
- Rendered content. Pages that build their content with JavaScript may return an empty shell. The scanner labels these as limited coverage instead of inventing failures — and a shell response does not prove Google cannot index the site, because Google renders JavaScript. Sites built with current Lovable projects use server-side rendering, while older React+Vite apps can use verified-crawler prerendering — neither is established by one static fetch. Google: JavaScript SEO basics · Lovable: SEO & AEO
- Speed, Core Web Vitals, rendered accessibility or real conversions. Those need measurement tools, not a static fetch.
How partial results are handled
When a response is blocked, behind a login, a challenge page or a JavaScript shell, the scanner's heuristic detectors mark the affected checks as unavailable rather than failing them. These detections are heuristics — they catch common patterns, not every possible one. The score is then computed only over the checks that could be assessed, and the coverage label says which kind of evidence you have — for example "HTTP/HTTPS only" or "Present head metadata only". When nothing about the target content could be assessed, no numeric page score is shown at all.
Optional AI explanations only explain findings that were actually observed. They cannot change scores, evidence or approvals, and they are never sent the page HTML.
Scan history is a storage policy: URLs, scoped scores and which checks were assessable are kept in your browser only — never the page HTML, and never in a LaunchForge database. The URL you submit is necessarily sent to the scanning service to fetch the page.
Illustrative examples
- A page behind a bot challenge returns a "Just a moment" interstitial: the scanner reports limited coverage instead of claiming the real page is missing a title.
- A JavaScript app returns an empty root element and a script bundle: head metadata present in the HTML can still be assessed; body checks are marked unavailable.
- A response that arrives as an HTTP 206 partial body has limited coverage and is labelled accordingly. An oversized, truncated or otherwise invalid transfer can instead be rejected outright, with no report at all — not every incomplete download produces a partial report.
These examples are illustrative of the detection rules, not records of specific sites.
Sources
Try it on a page
Scan an accessible public HTTPS page and see up to 12 potential checks — only the checks the returned evidence permits are assessed, each with the observed evidence.