How the website audit works
Website Health Scanner turns a limited technical crawl into an understandable repair report. This page explains what is requested, how findings are classified, where PageSpeed data fits, and why an automated result always needs human review.
1. The scan starts with one public URL
The scanner normalizes the submitted address, follows a controlled number of redirects, and requests the public page over HTTP or HTTPS. Private, local, loopback, and otherwise restricted network destinations are blocked. This protects internal systems and keeps the service focused on pages that an ordinary visitor could open.
After the first page loads, the crawler discovers same-site links from its HTML. It follows a limited sample rather than attempting to copy an entire website. The production configuration currently allows up to 12 pages, two link levels, and a controlled number of page, image, and link requests. Limits keep scans responsive and reduce unnecessary traffic to the website being checked.
A scan is a sample
A result describes the pages and assets reached during that scan. It does not certify every URL, every browser state, or every future version of the website.
2. Eight technical areas are evaluated
| Area | Signals reviewed | What the signal can reveal |
|---|---|---|
| Speed | HTML response time, page size, redirect behavior, image weight, mobile Lighthouse score | Slow hosting, oversized documents, heavy assets, or a weak mobile loading path |
| Images | File size samples, formats, lazy-loading hints, alternative text | Downloads that delay mobile pages or images that lack useful text alternatives |
| Forms | Form actions, methods, named controls, submit controls | Forms that are incomplete in the HTML or have no plausible submission path |
| Buttons | Visible labels, accessible names, hidden interactive elements | Controls that may be difficult to see, understand, or use |
| Mobile | Viewport metadata, fixed-width clues, font and tap-target audits | Layouts likely to overflow, shrink, or become difficult to operate on a phone |
| Links | Status codes, failed requests, redirect limits, crawl failures | Destinations that visitors or search crawlers may not be able to reach |
| Metadata | Titles, descriptions, heading structure, canonical and indexing hints | Pages whose purpose is unclear or whose search presentation is incomplete |
| Web Vitals | LCP, INP, CLS, related Lighthouse diagnostics, field data when available | Slow main content, delayed interaction, or unexpected layout movement |
3. PageSpeed and crawler timing answer different questions
The direct crawl records how long the scanner took to receive a page from the Cloudflare edge region handling the request. That number includes network distance, DNS and connection work, server processing, redirects, and transfer time. It is useful for finding a slow response, but it is not a worldwide average and should not be presented as one.
When Google PageSpeed Insights is available, the report adds a mobile Lighthouse run and may include Chrome User Experience Report field data. Lighthouse is a controlled lab test. Field data represents eligible real Chrome visits over a rolling period. A site can therefore have a fast server response and a poor Largest Contentful Paint, or a weak lab run and acceptable field data. The report keeps those measurements separate.
If PageSpeed is unavailable, rate-limited, or unable to analyze the page, the rest of the audit still completes. The report marks the missing source instead of inventing a performance value.
4. Status and score calculation
Each of the eight checks receives one status. A pass means no configured failure signal was found in the checked sample. A notice provides context or points to a lower-confidence issue. A warning identifies a likely problem worth reviewing. A critical result identifies a stronger threshold breach, such as a very slow response or an unusually heavy asset.
The summary begins at 100 and applies a simple severity penalty across the eight checks:
- Critical: 14 points
- Warning: 7 points
- Notice: 3 points
- Pass: 0 points
The score is an internal prioritization aid, not a search-ranking score and not a guarantee of business performance. Two sites with the same number can have completely different repair needs. The finding text and affected examples matter more than the headline number.
The repair plan excludes passed checks, sorts remaining items by severity, and presents up to five actions. Equal-severity items keep the audit's technical order; they are not estimates of revenue impact.
5. Important limitations
Forms are not submitted
The scanner inspects form markup but does not send a real message, make a purchase, or create an account. A form can pass the structural check and still fail because of JavaScript, an external provider, spam protection, mail delivery, or a server-side error. Send a real test inquiry after every form change.
Rendered browser states can differ
HTML analysis can identify many layout clues, but it cannot prove every visual state. Cookie banners, animations, delayed scripts, geolocation, personalization, and login state may change what a visitor sees. Lighthouse contributes a rendered mobile test when available, but a manual check on a real phone remains valuable.
Authenticated and private content is outside the scope
The scanner is designed for public websites. It does not sign in, bypass access controls, or inspect internal addresses. Content that requires a password, a company network, or a private link should not be submitted.
Third parties may respond differently
Firewalls and bot controls can block an automated request even when ordinary visitors can open the page. Conversely, a cached response may be faster than a first-time visit. The report states failures plainly so they can be compared with a browser test.
6. Privacy and operational safeguards
Submitted URLs are used to perform the requested technical scan. Recent scan history is stored locally in the visitor's browser. The service uses request information and an IP address for rate limiting and operational security. It may send a public URL to Google PageSpeed Insights to obtain performance data.
Scan responses are cached for a short period to reduce duplicate work. The service applies request, response-size, redirect, concurrency, and rate limits. These controls are part of the measurement: when a page is too large or cannot be retrieved within the configured limit, the report explains that condition instead of silently truncating the result.
For the full handling description and operator contact, read the privacy page.