Methodology
How Zenith scores your site.
A score is only useful if you can see how it was produced. Here is the exact method, taken from the code that runs your audits.
The Zenith Score
Four categories are scored independently: Security, Accessibility, Search (SEO) and Performance. Each starts at 100 and loses points for each distinct issue found. The overall Zenith Score is the equally weighted average of those four (25% each), rounded and clamped to 0-100.
Reliability (uptime and incidents) is reported separately rather than folded into the score, because it measures a different thing over a different time window.
Severity deductions
Each distinct issue reduces its category score by a fixed amount:
- −25critical
- −15high
- −7medium
- −3low
- −0info
One issue counts once
Findings are grouped by the rule that produced them before scoring. A single misconfiguration that appears on two hundred pages is one finding with two hundred affected URLs, not two hundred deductions. Without this, large sites would be penalised simply for being large.
Because rule identity is stable, we can also tell you which findings are new, ongoing or resolved compared with your previous audit.
What gets checked
- Security: response headers and transport configuration: HTTPS, HSTS, CSP, frame protection, content-type options, referrer policy, cookie flags.
- Search: titles, meta descriptions, canonical URLs, headings, document language, indexability, sitemap and robots availability, broken internal links.
- Accessibility: automated checks including image alternatives, document language and responsive viewport.
- Performance: laboratory measurements: server response time, document size, and browser render timings on the homepage.
Crawl boundaries
Audits stay on your own origin, respect robots.txt, and are bounded in page count (by your plan), crawl depth, concurrency and response size. Only safe GET requests are made, and state-changing paths (sign-out, cart, admin) are skipped. To keep costs predictable, full browser rendering is used on your homepage while remaining pages are analysed at the HTTP level.
Monitoring
Uptime checks run on your plan’s interval and record status, response time and errors. To avoid alerting on a single blip, an incident opens only after two consecutive failed checks, and resolves on the first successful one. You get exactly one notification when it opens and one when it recovers.
Limits you should know
- Security checks are passive configuration checks. They are not a penetration test, and a perfect score does not mean your site is secure.
- Automated accessibility testing catches a meaningful subset of issues but cannot certify WCAG compliance. Manual testing is still required.
- Performance figures are laboratory measurements from a single render, not field data from your real visitors.
- Scores are a prioritisation aid, not an industry certification.
Check library
What Zenith checks, and how.
These are the checks behind every score. Each one says what it catches, what it pairs with, and where our coverage stops.
Showing 14 checks
Every page is served over HTTPS, and a plain http:// request is sent there.
Without it, anyone on the same network can read or change what a visitor sees. Browsers also label the page Not secure.
- Works well with
- Strict-Transport-Security
- A single 301 redirect from http to https
- Avoid
- Redirect chains that hop through several addresses
- Links and assets that still point at http://
- How Zenith checks it
- Zenith requests the http:// address and follows where it goes. A page that stays on plain HTTP is marked critical.
Tells browsers to use HTTPS for your domain for a set time, even if someone types http://.
It closes the gap on a visitor's first insecure request. That's the moment a downgrade attack needs.
- Works well with
- An HTTPS redirect on every host
- A max-age of six months or more once HTTPS is stable
- Avoid
- includeSubDomains or preload before every subdomain serves HTTPS: it locks those subdomains out
- How Zenith checks it
- Read from the response headers of each HTTPS page. A missing header is marked high.
Lists which scripts, styles, images and frames a page is allowed to load.
If someone manages to inject markup, the browser won't run anything the policy doesn't allow.
- Works well with
- Report-only mode while you tune it
- Hashes or nonces for the inline scripts you keep
- Avoid
- 'unsafe-inline' in script-src: it switches off most of the protection
- How Zenith checks it
- Zenith checks that a policy is sent. It doesn't yet grade how strict the policy is, so a weak CSP won't be flagged.
Stops other sites from loading your pages inside a hidden frame.
A framed page can trick people into clicking controls they can't see. Think confirming a change on an account page.
- Works well with
- CSP frame-ancestors 'self'
- X-Frame-Options: DENY for older browsers
- Avoid
- X-Frame-Options: ALLOW-FROM: current browsers ignore it
- How Zenith checks it
- Passes when either X-Frame-Options or a frame-ancestors directive is present. Marked medium when neither is.
The value nosniff tells browsers to trust the Content-Type you send.
Without it, a browser can decide an uploaded file looks like a script and run it.
- Works well with
- Accurate Content-Type headers on every file you serve
- Avoid
- JavaScript served with the wrong type: with nosniff on, the browser blocks it
- How Zenith checks it
- Header presence on each page. Marked low when missing.
Controls how much of the current address is passed to the next site a visitor opens.
Full URLs can carry account IDs, search terms or reset tokens you didn't mean to share.
- Works well with
- strict-origin-when-cross-origin as a sensible default
- Avoid
- unsafe-url, which sends the full address everywhere, including over HTTP
- How Zenith checks it
- Header presence. Marked low when missing.
Turns off browser features you don't use, such as the camera, microphone or location.
If a third-party script is compromised, it can't ask your visitors for access you never needed.
- Works well with
- An explicit list of the features you do use
- Avoid
- Blocking something an embed relies on: payment forms may need the payment feature
- How Zenith checks it
- Header presence. Reported as information, not as a problem.
Meaningful images carry alt text that says what they show.
Screen reader users hear the description. Without it they hear a file name, or nothing.
- Works well with
- alt="" on purely decorative images, so they're skipped
- Avoid
- Starting with "image of", or repeating the caption beside it
- How Zenith checks it
- Finds images with no alt attribute on each crawled page and lists the pages they're on.
The lang attribute on the html element, such as en-GB.
Screen readers use it to choose pronunciation. Translation tools use it to detect the language.
- Works well with
- lang on any passage written in a different language
- Avoid
- A template's lang="en" left on a site written in another language
- How Zenith checks it
- Reads the html element on every crawled page.
A unique title and meta description for each page.
They're usually the first thing people read in search results, before they decide to click.
- Works well with
- One H1 that matches the page's purpose
- A canonical URL
- Avoid
- The same title on every page
- How Zenith checks it
- Flags missing titles as high. Very short titles, ones likely to be cut off, and missing descriptions are flagged lower.
A robots noindex instruction that hides a page from search engines.
It's often left on when a site moves from staging, and the page quietly drops out of search.
- Works well with
- noindex on pages that genuinely should stay private, like account settings
- Avoid
- Shipping a staging template's noindex to production
- How Zenith checks it
- Reads the robots meta tag on each page. A noindex is marked high.
How long your server takes to start sending the page.
Everything waits on it. Fonts, images and scripts can't start until the HTML arrives.
- Works well with
- Caching HTML at the edge where the page allows it
- Avoid
- Holding the response while slow third-party API calls finish
- How Zenith checks it
- Timed on every request Zenith makes. Slow responses are marked high, moderate ones medium.
A request to your site on a fixed schedule: every 15 minutes on Free, 5 on Solo, every minute on Pro and Agency.
You hear about an outage from Zenith, not from a customer.
- Works well with
- A public status page, included on every paid plan
- Avoid
- Monitoring an address that redirects to a login page: it can look up while the app is down
- How Zenith checks it
- An incident opens after two failed checks in a row, so one slow response won't page you.
Check the method against your own site.
Run a free scan, then read every deduction in the report.