How the website health score works

How the score is calculated

Each finding's severity costs a fixed number of points:

Points are added up per section, each section's total is capped, and the capped totals are subtracted from 100. Each problem counts once, even when two checks spot it. The caps stop one weak area from sinking an otherwise sound site, while a single serious problem still shows clearly. They add up to 120, so the score can reach 0 but not go below it.

A worked example

Take a typical older small-business homepage:

• Security: the Server header shows a version number (fix soon, 6).
• Speed: scripts in the head block rendering (minor, 2).
• SEO: the title says “Home” (6), no meta description (6), under 120 words (6), no H1 (6), no structured data (2), no canonical tag (2). Total 28, capped at 20.
• AI search: no llms.txt (2), no FAQ or Article structured data (2), no question-style headings (2). Total 6.
• Email and domain: DMARC is monitor-only, p=none (minor, 2).
• Contact and trust: the phone number isn't tap-to-call (minor, 2).

The capped totals are 6 + 2 + 20 + 6 + 2 + 2 = 38, so the score is 100 − 38 = 62, Fair. Without the SEO cap it would have been 54.

The cap also changes what a fix is worth. Rewriting the title brings SEO from 28 to 22, still over the cap, so the score doesn't move. Adding a meta description brings SEO to 16 and the score to 66. In a section over its cap, the gains arrive once you're under it.

What the colours mean

The report uses three colours, and every finding also carries a word tag (Serious, Fix soon or Minor):

• Red, serious: visitors see a warning, the site can be attacked, or Google can't index it. A section with any serious finding is red.
• Yellow, fix soon or minor: nothing is broken today, but it costs you trust, rankings, speed or email delivery. A section with findings but none serious is yellow.
• Green, passes: checked, nothing to fix. In the AI crawler list, green means robots.txt allows that crawler, yellow means it isn't mentioned, red means it's blocked.

The Overview tab lists the top five things to fix across all sections, serious first, then fix-soon, then minor. In the example, that's the server version and the four SEO warnings.

The six sections and what each looks at

Serious findings exist only in security (no HTTPS, a bad certificate, an insecure form, PHP at risk on an end-of-life branch), speed (not built for mobile), SEO (noindex, or robots.txt blocking every crawler) and email and domain (registration expiring within 60 days). AI search and contact and trust are never red.

What the checker requests from your site

Only what a browser or search engine would fetch:

1. Your homepage over https, or plain http if https fails, following up to five redirects within your own domain. A redirect to a different website stops the check.
2. The first answer from http://your-site/, to see whether it redirects to https.
3. /robots.txt, /sitemap.xml and /llms.txt.

It also reads your domain's MX and TXT records from public DNS, the registration record over RDAP (the registries' standard lookup, RFC 9083), and a Lighthouse run from Google PageSpeed Insights; none of those touch your server from our side. Requests carry RemidiyCheck/1.0 in the user agent, so you can spot them in your logs.

It never logs in, submits forms, guesses hidden paths, scans ports or tries an attack. We keep the address and result for 90 days, and your name and email only if you ask for help (privacy policy).

Limitations

• One page. Only the homepage is read; a broken contact page won't show up.
• No JavaScript. A site that builds its content in the browser can look thinner than it is, as it does to most AI crawlers.
• Version strings. A host that patched PHP without changing the reported version still reads as at risk (how to confirm).
• Time limits. The homepage gets 25 seconds and each small file 5; a robots.txt that doesn't answer in time counts as missing. If DNS fails, email checks are skipped and cost nothing. Only the first 1 MB of HTML is read.
• An hour's memory. Results for an address are reused for up to an hour, so a re-check straight after a fix may show the old result.
• Not a security audit. It can't see weak passwords, malware or plugins that leave no trace in the HTML.

How Lighthouse relates to the score

The Speed tab also shows Google's Lighthouse run on a simulated phone, from PageSpeed Insights: Performance, Accessibility, Best practices and SEO out of 100, plus the Core Web Vitals LCP, CLS and INP. The vitals are field data from real Chrome users (collected over 28 days) where Google has it, otherwise the lab run.

Lighthouse doesn't change the health score. Lab scores vary from run to run with network and server conditions (Lighthouse on variability), while the health score is built almost entirely from things that are either there or not. Google rates 90 and above as good, 50 to 89 as needing improvement and below 50 as poor.

Sources

• Google: About PageSpeed Insights (lab and field data, score bands)
• Chrome for Developers: Lighthouse overview
• Lighthouse: score variability
• web.dev: Web Vitals
• Google Search Central: introduction to robots.txt
• RFC 9083: RDAP responses (how registration data is published)

Common questions

See your own score. Run the website checker on your address; every finding links to the guide section that fixes it. If your server runs PHP, the PHP vulnerability checker leads with the PHP2Shell answer. If you'd rather hand the fixes over, that's what we do.