App Health Check
How the score works
Rubric v0.2. Fixed rules, public information only, and every statement labelled with where it came from.
Principles
- Evidence first. Each finding shows the raw observation and the check that produced it.
- Missing data is never a penalty and never a pass. A check that cannot run is excluded and listed under what we could not check.
- Reproducible. The score is computed by code from a versioned rubric. The same evidence gives the same score.
- Honest labels. Verified by scan moves the score. Self-reported answers never do.
Areas and weights
| Area | Weight | Checks (weight inside the area) |
|---|---|---|
| Security hygiene | 22 | HTTPS enforced and a valid certificate that is not expiring within 14 days (25); HSTS with a long max-age (15); Content Security Policy (20); TLS 1.2 or newer (10); frame protection (10); nosniff (5); Referrer-Policy (5); Permissions-Policy (5); cookie flags, only where cookies are set (5). |
| Performance | 18 | Lighthouse mobile performance score from Google PageSpeed Insights (60), plus real-user Chrome field data for LCP, INP and CLS when Google has enough traffic to publish it (40). The lab score is a single run, so it can vary a little each time. Field data is used only when it exists. |
| Quality basics | 12 | Lighthouse accessibility (35), best practices (25) and SEO (25), plus JavaScript errors logged while the page loads (15). The accessibility result is an automated subset, not a compliance verdict. Crashes after the page has loaded cannot be seen from outside. |
| Search discoverability | 14 | Page title (15); meta description (15); sitemap that exists and whose sampled addresses load (15); canonical link (10); social preview tags (10); one main heading (10); not accidentally set to noindex (10); structured data that parses (10); page language (5). These are read from the page we already fetched, plus up to three sitemap addresses. |
| AI search readiness (signals) | 8 | Readable text present in the server HTML, because most search and AI crawlers do not run JavaScript (40); clear heading structure (25); structured data that says who or what the site is (25); a modified date (10). These are signals, not guarantees: nobody outside the AI companies knows their ranking factors. Whether AI crawlers are allowed in robots.txt and whether llms.txt exists are shown for information and never affect the score. |
| Platform and dependency freshness | 20 | Front-end libraries with known advisories (40); end-of-life runtimes, servers and frameworks that are declared or disclosed (40); very old major versions of detected libraries (20). Scored only when at least one version is actually visible. |
| Repository health (when a repository is supplied) | 14 | Last commit recency (25); commit activity over 90 days (20); contributor spread (15); automated checks present (10); tests present (10); lockfile present (10); archived flag (10). Public GitHub repositories only. |
Rules
- The headline is the weighted average of the areas that were scored. It is shown only when at least three areas were scored and they cover at least 60% of the weight that applies to the inputs. Otherwise the report says Partial evidence.
- A critical finding, such as no HTTPS or an invalid certificate, caps the headline at 50. Two or more high-priority findings cap it at 70. An area is capped at its worst finding.
- An area shows insufficient data when fewer than 60% of its check weight could be verified.
- Bands: 85 to 100 Healthy signals; 70 to 84 Good, with watch items; 50 to 69 Needs attention; under 50 At risk. We never use the words certified, verified secure or guaranteed.
- The triage signal (Low, Moderate, High) helps decide whether a human review is worthwhile. It is separate from the score.
Where the data comes from
- Our own ordinary requests to your public pages: headers, cookies, robots.txt, sitemap.xml (plus up to three addresses from it), llms.txt and the page HTML. We then follow the links on your own pages, and the sitemap, to read up to 80 pages of the same website in total, with a short pause between requests.
- A TLS handshake to read the protocol version and certificate.
- Google PageSpeed Insights (Lighthouse), mobile strategy, and the Chrome UX Report for real-user speed where it exists.
- The GitHub REST API, read-only, for public repositories you point us to. We never clone, install or run anything.
- End-of-life dates from endoflife.date, bundled as a snapshot dated 2026-10-16.
- A short list of well-known library advisories (jQuery, Bootstrap, Lodash and similar), matched only when the version appears literally in a script address.
Wording rule: versions are described as declared in your repository or disclosed by your server, never as what your production runs. A private or missing repository is reported as not accessible, never as having no tests.
About the requests
Checks are passive: ordinary requests for the main page and standard files, then up to 80 pages found through your own links, no path guessing, no cookies, no logins. We read your robots.txt first and stop if it asks automated tools to stay away. We do not follow private or internal addresses.
The scanner identifies itself as ZovintraHealthCheck/1.0 (+https://www.zovintra.com/app-health-check/method). To opt out, disallow ZovintraHealthCheck in your robots.txt, or email contact@zovintra.com.
Privacy notice for this tool
- What we store: the scan results (findings and scores), the host name that was checked, and a hashed form of your network address that rotates daily and is used only for rate limits. We do not store page content, source code or secrets.
- Reports: private links with a random identifier, not indexed by search engines, deleted after 30 days.
- Email: if you ask for the full report we store your email address and consent time, and send the report link to that address only. Marketing emails are sent only if you tick the separate optional box. Every email says who we are and how to stop.
- Review requests: your name, contact details, the answers you give and the scan summary are stored and emailed to our team so we can reply. We keep them until you ask us to delete them. We do not sell or share them with vendors.
- Your choices: to see, correct or delete your data, or to raise a concern, email contact@zovintra.com. We are Zovintra Private Limited, Sirohi, Rajasthan, India.
- Our general privacy policy also applies.
Limits and changelog
This is an automated initial assessment based on public information at one point in time. It is not a code audit, penetration test or security certification.
Rubric v0.2 added search discoverability, AI search readiness, real-user speed data and a load-time error check. Rubric v0.1 was the first version. Weights and thresholds may change as we compare results with senior engineers’ judgement; the version is recorded on every report so scores stay comparable.