Rudra Analyzer

Methodology

How we test and score websites

This page explains exactly what our checks look at, how each score is worked out, which tools do the testing and where the limits are. It describes the single-page checks behind the free tools and the website audit.

What each check looks at

A full audit runs seven checks. Each has a plain name, used throughout our reports, and a technical name that describes what it actually tests.

SEO

Technical name
On-page and technical SEO
What it checks
Title and meta description, H1 and heading order, canonical URL, robots meta and X-Robots-Tag rules, Open Graph and Twitter card tags, html lang, viewport, image alt coverage, JSON-LD structured data, hreflang, favicon, word count, internal links, plus robots.txt, the XML sitemap, llms.txt, redirect chains and HTTPS.
How it's scored
Starts at 100. Missing title −25, missing meta description −15, missing H1 −15, noindex −30, and smaller deductions (2–15 points) for the rest. The newer checks together can remove at most 45 points.
Tested with
Python requests + BeautifulSoup (reads the HTML the server sends; JavaScript is not run)
Try the SEO Checker

Speed

Technical name
Page performance (Lighthouse)
What it checks
Lighthouse's performance category: First Contentful Paint, Largest Contentful Paint, Total Blocking Time, Cumulative Layout Shift, Speed Index and Time to Interactive, plus up to 15 failing audits.
How it's scored
Lighthouse's own 0–100 performance score, unchanged. An audit scoring below 0.5 is marked critical, below 0.9 a warning.
Tested with
Google Lighthouse in headless Chrome, default (mobile) settings
Try the Website Speed Checker

Mobile experience

Technical name
Responsive layout
What it checks
The viewport meta tag and horizontal overflow at desktop (1280×800), tablet (768×1024) and phone (390×844) sizes, with a screenshot of each.
How it's scored
Starts at 100. Missing viewport tag −20, −15 for each size where the page is wider than the screen, −10 if any size had loading problems.
Tested with
Playwright with Chromium
Try the Mobile Checker

Accessibility

Technical name
Automated WCAG testing
What it checks
axe-core's default rule set — WCAG 2.x level A and AA rules plus best practices — run on the rendered page. Up to 25 violation types are listed, each with the number of affected elements.
How it's scored
Starts at 100 and loses points per failing rule, by impact: critical −15, serious −10, moderate −5, minor −2.
Tested with
axe-core injected into Chromium via Playwright
Try the Accessibility Checker

Website security

Technical name
Transport security and HTTP security headers
What it checks
HTTPS after redirects; the TLS certificate (trust, hostname, protocol version, issuer, expiry); HSTS, Content-Security-Policy, X-Frame-Options or CSP frame-ancestors, X-Content-Type-Options, Referrer-Policy, Permissions-Policy; version numbers in Server or X-Powered-By headers.
How it's scored
Starts at 100. Not HTTPS −40, no HSTS −15, no CSP −12, no clickjacking protection −8, no X-Content-Type-Options −6, no Referrer-Policy or Permissions-Policy −4 each, version disclosure −3. Invalid or expired certificate −40, failed TLS connection −30, expiry within 14 days −10, within 30 days −5.
Tested with
Python requests + the standard-library ssl module
Try the Website Security Checker

Links & page errors

Technical name
Functional smoke test
What it checks
Loads the page in a browser, records JavaScript console errors and uncaught exceptions, tests up to 12 unique links to the same site (same protocol and domain) for HTTP errors, and counts forms without submitting them. Links to other websites are not tested.
How it's scored
Starts at 100. Each broken link −10 (at most −40), each uncaught JavaScript error −10 (at most −30), each console error −5 (at most −20).
Tested with
Playwright with Chromium
Try the Broken Link Checker

Server & availability

Technical name
Availability and response time
What it checks
The page itself plus common paths — robots.txt, sitemap.xml, /health, /healthz, /api, /api/health, openapi.json, swagger.json, manifest.json and security.txt — for server errors and average response time. A 404 on these optional paths is not penalised.
How it's scored
Starts at 100. Page unreachable or 5xx −50, page 4xx −20, −15 for each other path returning 5xx (at most −30), average response time above 800 ms −8 or above 1,500 ms −15.
Tested with
Python requests
Try the Website Audit

How the overall score is calculated

The overall score is the average of the category scores, rounded to a whole number. Only categories that produced a result count. If an engine isn't available on our server — for example Lighthouse isn't running — that category is left out of the report and out of the average, rather than being counted as zero or guessed.

If a check runs but can't complete, for example because the page doesn't load in time, it scores 0 and does count, because that is a real problem a visitor would hit too.

Scores are shown with a plain status: 90–100 is “Good”, 50–89 “Needs attention” and 0–49 “Poor”. The status is always written out next to its colour.

The tools we use

We build on established, open tools rather than inventing our own measurements.

  • Google Lighthouse

    Measures loading performance in a real Chrome browser. We use its performance score and audits as they are.

  • Playwright and Chromium

    Loads pages in a real browser engine for the mobile layout, links and errors, and accessibility checks, and captures screenshots.

  • axe-core

    The open-source accessibility rules engine from Deque, used widely for automated WCAG testing.

  • requests and BeautifulSoup

    Fetch pages and parse their HTML for the SEO, security and server checks.

  • Python's ssl module

    Opens a TLS connection to read and validate your certificate against the standard trusted certificate authorities.

What automated checks can't tell you

  • Whether your content is useful, accurate or persuasive, or how well it will rank against competitors.
  • Accessibility questions that need a person: whether alt text is meaningful, keyboard order makes sense, or content is understandable.
  • Whether your site has vulnerabilities, outdated software, weak passwords or malware. The security check reads your configuration; it's not a penetration test.
  • How fast your site is for your real visitors. Lighthouse runs one lab test; real-visitor data can differ.
  • Anything behind a login, a paywall or a form — we only see pages that load publicly.
  • Problems on other pages. Each single-page check looks only at the address you enter.

Why results can vary between runs

Speed changes the most. Every Lighthouse run is a fresh page load, and network conditions, server load, caching, ads and third-party scripts differ from one load to the next. A few points of difference between runs is normal.

Browser-based checks can also differ if the page loads content in a random order, shows different banners or experiments, or blocks automated visitors some of the time. SEO and security results change only when your page or server configuration changes.

Known limitations by area

Speed

A lab test of one load, using Lighthouse's default simulation of a mid-range phone on a throttled connection. It can't measure Interaction to Next Paint (INP), which needs real interactions; Total Blocking Time is the closest lab signal.

Accessibility

Automated rules find only part of the problems a page can have. Passing doesn't mean the page meets WCAG; manual testing with a keyboard and screen reader is still needed.

Security

Checks that headers are present, not how strong their values are, and doesn't inspect cookies, mixed content or application vulnerabilities.

Links

Tests up to 12 links to the same site per page. Links to other websites are not checked, and some servers return errors to automated visitors even when the page works for people.

How AI is used in reports

When it's switched on, an AI model (Anthropic's Claude) rewrites the real findings from a scan into a short, prioritised list of next steps. It receives the scanned address, the category scores and the issues our scanners detected.

It is instructed to explain and prioritise only those findings. It doesn't create issues, change scores or claim anything was measured that wasn't. When AI isn't configured, or the request fails, we use a templated summary built from the lowest-scoring areas instead — the report shows which one you're reading.

Scores and issues always come from the scanners described above, never from the AI.

What happens to your data

Analyses are temporary. Every scan, site scan and layout test — with its results, reports and screenshots — is deleted automatically 24 hours after its last activity.

Our privacy policy explains what else we store, such as account details, and for how long.

Read the privacy policy

Try the checks

Every tool on this page is free to try on one page of your site, and our guides explain how to fix what they find.

Browse the free toolsRun a full website auditRead the guides