What happened when we scanned our own website

The dated production snapshot

On September 4, 2026, Website Health Scanner was asked to scan its own public origin, https://webhealthscan.com. The request completed from the production Worker and returned an overall score of 87, classified as Good. The crawl attempted 11 pages and completed the eight report categories used for every supported target.

This is a snapshot, not a live badge. Hosting conditions, third-party APIs, page content, and the scanner itself can change after the date above. Publishing the date makes the evidence useful without pretending that one run proves permanent quality.

Why we publish an imperfect score

A perfect number would be easier to advertise and less useful to explain. The result contained zero critical findings, one warning, and two notices. Each remaining item demonstrates why a structural crawler and a browser-based review answer different questions.

The form warning

The scanner reported two forms without an HTML action. One is the scanner form itself. JavaScript handles that submission and sends JSON to the scan API, so a missing traditional action does not mean that the visible feature is broken. The warning is intentionally conservative because the crawler does not click a button, execute the complete interaction, and verify the resulting report.

The right follow-up was therefore not to hide the warning. We submitted a public URL in a real browser, observed the progress state, received a report, and checked the API response. That manual step converts an ambiguous structural signal into evidence about the actual workflow.

The mobile notice

The crawler found three wide tables. Wide fixed-format content is a genuine mobile risk, so the report asks for human review. On this site the tables sit inside horizontally scrollable wrappers. Separate viewport tests confirmed that the document itself does not overflow and that surrounding navigation and text remain inside the screen. The table content can be moved deliberately without pushing the whole page sideways.

The metadata notice

One of the sampled pages had a short meta description: the imprint. That page exists to provide operator details, not to compete as an editorial search result. It now carries noindex,follow and is excluded from the sitemap while remaining reachable to visitors and advertising crawlers. The privacy and terms pages use the same indexing treatment. This keeps required legal information accessible without presenting thin utility pages as the site's main published content.

What passed in the automated report

Five report areas passed without a critical, warning, or notice finding in this snapshot: page speed, image handling, button visibility, sampled links, and Core Web Vitals. Search metadata and mobile layout remained notices for the reasons described above, while form structure remained a warning.

A pass means that the inspected sample did not cross the scanner's configured thresholds. It does not prove that every browser state, every third-party service, or every future deployment will work. For example, a sampled link can return 200 now and fail tomorrow; an image can be reasonably sized on one template while a newly uploaded image is too large on another.

Manual checks performed around the scan

The automated result was paired with browser and production checks because the site's main value depends on an interactive workflow. The following checks were completed against the live service during the current release work:

• Fifty mobile viewport combinations: widths from 320 to 768 pixels were checked across the main public pages. The tests found no document-level horizontal overflow.
• Long target names: a deliberately long domain and dynamic report content were tested to confirm that text wraps instead of expanding cards or the page beyond the viewport.
• Self-scan: webhealthscan.com returned a complete report rather than the earlier Cloudflare 522 failure.
• External scan: a normal public external target returned a structured JSON report with all eight checks.
• Crawler access: requests using Googlebot and Mediapartners-Google user agents returned the public HTML without a challenge or noindex directive on editorial pages.
• Advertising state: AdSense ownership metadata and ads.txt remain available, but ad delivery and Auto Ads remain disabled while the site is under content review.

These checks test the public release rather than only the source files. They are repeated after deployment because a local success cannot detect a Worker route error, DNS problem, cache mismatch, or production-only configuration issue.

What this evidence still cannot prove

The scan does not send a real business inquiry, complete a purchase, read a page with assistive technology, or judge whether an explanation is persuasive. It also cannot see private dashboards, authenticated routes, geo-specific variations, or every page generated from a large content system.

PageSpeed lab results describe a controlled simulated visit. Core Web Vitals field data, when available, describe aggregated real visits and can differ by page group, device, connection, and time period. A fast run from one region does not mean every visitor worldwide receives identical latency. The report labels its measurement context so network distance is not silently treated as a universal fact.

Search quality is also outside the score. A technically clean page may still be unhelpful, repetitive, or poorly matched to a reader's question. That is why this site publishes the methodology, repair procedures, manual checklist, authorship, dated evidence, and limitations as separate content rather than relying on the tool screen alone.

How to reproduce the check

1. Open the Website Health Scanner.
2. Enter https://webhealthscan.com and start the scan.
3. Keep the tab open while the progress indicator advances through connection, crawl, links, PageSpeed, and report preparation.
4. Record the scan date, pages attempted, measurement region, PageSpeed availability, and each finding before comparing it with this snapshot.
5. Open any warning in a real browser and test the relevant task. Do not convert a structural signal into a failure claim without that verification.

It is normal for later values to differ. A meaningful comparison explains the changed conditions instead of selecting whichever run has the highest score. Material changes to the service are recorded in the public changelog, and the exact scoring approach is documented in the audit methodology.