Technical website checks explained in plain English
Website Health Scanner is an independent tool for people who need to understand a public website without beginning with a developer console. It combines a technical scan with practical guidance and makes the limits of automation visible.
Why the project exists
Many website problems are easy to describe after they are found and difficult to notice before they cost a visitor: a form appears normal but has no useful submission path, a mobile layout overflows, an image is several times larger than its display size, or an important page links to a destination that no longer exists.
The scanner brings common checks into one report. It is designed to help an owner, editor, or developer decide where to investigate first. It does not promise search rankings, legal compliance, perfect accessibility, or a flawless website. Those outcomes require broader review and ongoing work.
How the content is created
The explanations on this website are written for this service and tied to the signals its scanner reports. Guidance is organized around observable problems, likely impact, and a verification step. Technical thresholds and external metric definitions are checked against primary documentation where possible.
Editorial principles for the site are straightforward:
- Separate measurements from assumptions.
- State when a result is limited to a sample or scan region.
- Do not present an automated score as a business or search guarantee.
- Prefer a repair that can be tested over vague optimization advice.
- Correct material errors when they are reported and confirmed.
Operator and contact
Website Health Scanner is built and operated by Florian Pöll in Westendorf, Austria. Operator address and jurisdiction details are published in the imprint.
For a privacy request, a security concern, or a factual correction, email floripoell@gmail.com. Please include the affected page or scan URL and enough detail to reproduce the issue. Do not email passwords, private URLs, or sensitive website data.
Security reports can also follow the contact and disclosure information published at security.txt.
What maintaining this service involves
Florian maintains the scanner code, its Cloudflare deployment, the public guidance, and the checks used before a release. Work begins with a reproducible observation: a URL that returns an unexpected status, a page that overflows at a particular width, a report category that misstates what it can prove, or a production route that behaves differently from a local test.
A change is first checked against the smallest relevant test. Shared scanner or routing changes then run through the full automated suite. Production releases use a Cloudflare dry run before deployment and a separate check against the live domain afterward. The live check covers public routes, canonical redirects, legal configuration, indexing files, advertising state, security headers, error behavior, and at least one real scan request.
Layout changes receive browser checks at narrow and desktop widths. Scanner changes are tested with an external public target and, where relevant, against webhealthscan.com itself. This does not make defects impossible. It creates a trail from reported behavior to a test that can fail before the same regression is released again.
Verification and correction process
Technical claims are checked against observed responses, the scanner implementation, or primary product documentation. A threshold is stated with its measurement context. A result from Lighthouse is not described as field data, a response time from one scan region is not described as global visitor latency, and a structural form warning is not described as proof that no inquiry can be delivered.
When a factual error is reported, the affected public page and the current production behavior are reviewed together. Confirmed material errors are corrected in the page, scanner, or both. Changes that affect how a visitor interprets a report are recorded in the changelog. Dated measurements remain labeled as snapshots so later values do not silently rewrite what was observed.
The self-audit is the clearest example of this approach. It publishes the real 87/100 result, including the warning and notices, then separates scanner observations from the browser checks used to interpret them.
What the operator does not claim
Website Health Scanner is not a certification body, search engine, legal adviser, accessibility conformance audit, penetration test, or substitute for a developer who can inspect an application end to end. The operator does not promise a ranking increase, worldwide latency, uninterrupted availability, or delivery of a contact request based only on HTML structure.
The service is intentionally narrower: it identifies a bounded set of public technical signals, shows the evidence available to the scanner, explains the likely impact, and gives the reader a practical verification step. That scope is useful only when its boundaries remain visible.
Funding and advertising
The service is intended to remain accessible without a required user account. It may be supported by clearly identified advertising in the future. Advertising does not determine scan status, score, repair order, or editorial guidance. Sponsored placement is not currently part of the audit report.
When advertising technology is active, its use and related data handling will be described in the privacy information and subject to the consent choices required for the visitor's region. Legal, error, loading, and other non-content states are not intended as advertising destinations.