What happened when we scanned our own website

November 1: reading a fresh result

At 20:02 UTC on November 1, a production scan returned 97/100, Good: no critical findings, no warnings, one notice, and seven passes. It attempted and scanned 12 pages, with no failed page, and reached its 12-page limit. PageSpeed data was available. This is a bounded snapshot from Cloudflare edge, not a measurement of every visitor or every URL.

What the notice means

The mobile check flagged four tables that may be too wide. The signal identifies a condition worth checking; it does not establish that the whole page overflows or that a visitor cannot use a table. The tables on this site have scroll wrappers. Open the affected pages on a narrow screen, check whether the document itself scrolls sideways, and confirm that each table can be scrolled and read.

We checked the public HTML on November 1: the tables were on Methodology, Core Web Vitals, Form testing, and this page. Each was inside a scroll wrapper. That identifies where to test, but does not prove the wrappers work at every screen size or with every input device.

After this scan, we changed the mobile report to name affected pages, distinguish a missing device-width hint from a confirmed layout failure, and recommend an actual narrow-screen check. A future score may change because of that rule change; it should not be presented as a repair to the scanned website.

What passed, and what did not get tested

Speed, images, form structure, button visibility, sampled links, search metadata, and the PageSpeed-based Core Web Vitals check passed. The form result describes plausible HTML structure, not successful submission or email delivery. Search grading covered nine eligible pages and excluded three intentionally noindex legal pages. A pass applies only to this run and its sample.

The September 26 snapshot below scored 87 under earlier rules. Two of its findings were later addressed by changing the scanner's form and metadata rules. The score difference alone does not prove that the website became faster or that a visitor-facing issue was repaired.

October 3: correcting the scanner, not padding the website

The earlier form and metadata findings exposed two weaknesses in our own rules. We treated a missing form action as a warning even though native HTML supplies a default. We also graded descriptions by a fixed character range and included deliberately noindex legal pages. Both behaviors have been corrected. The dated results below are retained as historical evidence, not presented as the current scoring rules.

Reproducible local HTTP fixtures cover a form without an action, an empty action, externally associated controls, disabled fields, the enabled first-legend exception, short and long descriptions, and robots directives in HTML and headers. Valid form defaults no longer trigger warnings; enabled unnamed fields still do, with the affected page URL. Search metadata now excludes intentional noindex pages and does not fail text solely on length.

A higher score after a rule correction is not evidence that hosting became faster or that email delivery was repaired. Compare the finding text and the rules used for each run. The methodology explains the corrected behavior and links to the underlying standards. None of these technical checks establishes advertising eligibility or guarantees a search ranking.

September 26: a worked report

A fresh production scan returned 87/100, Good: zero critical findings, one warning, two notices, and five passes. The crawler attempted and scanned 12 pages without a failed page, but its 12-page limit was reached. This is an inspectable sample, not a complete inventory of every possible URL or browser state.

All eight check outcomes

• Speed: pass. The sampled pages responded well from the Cloudflare scan region. That does not measure every visitor's network delay.
• Images: pass. No unusually large image appeared in the checked sample. Future uploads still need review.
• Forms: warning. The scanner form has no HTML action URL; a browser interaction is needed to distinguish JavaScript handling from a failed form.
• Buttons: pass. No obviously hidden primary button was found. The scan does not test every overlay or interaction state.
• Mobile: notice. Four tables may be too wide. All four are inside scroll wrappers, but that alone does not prove the rest of a page fits a phone.
• Links: pass. Sampled destinations returned no clear error. This is not a promise about every link or a later visit.
• Search metadata: notice. One of 12 sampled pages had a short description: /imprint at 56 characters.
• Core Web Vitals: pass. Mobile Lighthouse reported no major issue in this run. Field data from real visitors can differ.

Three follow-up decisions

1. Verify the form, do not relabel the warning as a failure. Enter a public URL on the scanner homepage, submit it, and confirm that progress appears and an eight-part report arrives. This proves the scanner workflow for that run; it would not prove that a separate business contact form delivers email.
2. Inspect the mobile tables in a narrow browser. Each table should scroll inside its wrapper while the document itself stays within the viewport. If the whole page scrolls sideways or controls disappear, fix that layout before dismissing the notice.
3. Keep the legal page accessible without optimizing it as a search article. The imprint's short description is real, but the page is intentionally noindex,follow and linked from the footer. A longer description would not resolve a visitor problem.

The earlier September 4 scan also scored 87, but attempted 11 pages, reported two forms without an action, and found three wide tables. Those count changes do not by themselves prove that a form or layout was repaired: the sampled page set changed. Compare individual findings and the actual visitor journey, not just the score.

September 4: the earlier 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 September 4 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. The original rule was too broad: native HTML also permits an omitted action. We removed that warning on October 3 rather than requiring a needless markup change. The crawler still does not execute the complete interaction or verify delivery.

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.