Rudra Analyzer

Methodology

How we test and score websites

This page explains exactly what our checks look at, where their evidence comes from, how each score is worked out, how we keep testing safe and where the limits are. It describes the single-page checks behind the free tools and the website audit, plus the extra checks a site scan adds.

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 (length, generic wording, repeated words), H1 and heading order, canonical URL and the status of its target, robots meta and X-Robots-Tag rules, meta refresh, Open Graph and Twitter card tags (including whether og:image loads), html lang, viewport, image alt text, JSON-LD structured data (parse errors, duplicate types, invalid URLs, missing key properties for common types), hreflang, favicon, word count, link text and URL shape, plus robots.txt, up to three declared sitemaps, 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, and new informational findings cost nothing.
Tested with
Python requests + BeautifulSoup (reads the HTML the server sends; JavaScript is not run), plus one HEAD request each for a differing canonical target and the og:image
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, each compared with its published threshold (for example LCP 2.5 s / 4 s, CLS 0.1 / 0.25, TBT 200 / 600 ms), plus up to 15 failing audits with the files behind them. If Lighthouse can't run, a quick check reports server response, HTML size, compression, render-blocking files, caching headers and image size and format.
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. The quick check instead starts at 100 and lists its deductions; it is labelled as a quick check, never as a Lighthouse score.
Tested with
Google Lighthouse in headless Chrome, default (mobile) settings, one run; fallback: 1 GET plus at most 25 HEAD requests
Try the Website Speed Checker

Mobile experience

Technical name
Responsive layout
What it checks
The viewport meta tag (present, width=device-width, zoom not blocked) and horizontal overflow at phone (375×667), tablet (768×1024) and desktop (1440×900) sizes, naming the elements that stick out, with screenshots of the phone view and of any size with a problem.
How it's scored
Starts at 100. Missing viewport tag −20, viewport without width=device-width −10, viewport that blocks zooming −5, −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 and up to five examples (selector, HTML snippet, what to fix). Rules axe-core can't decide are listed as “needs manual review”, and passed rules are listed too.
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
A bundled copy of axe-core injected into Chromium via Playwright
Try the Accessibility Checker

Website security

Technical name
Transport security, header values, cookies and exposure
What it checks
HTTPS after redirects and whether http:// permanently redirects to HTTPS; the TLS certificate (trust, hostname, protocol version, issuer, expiry); security header values — HSTS max-age (at least 180 days) and syntax, CSP directives including 'unsafe-inline', 'unsafe-eval', broad script sources, nonces and hashes, object-src and base-uri, X-Frame-Options or CSP frame-ancestors, X-Content-Type-Options, Referrer-Policy, Permissions-Policy; cookie flags (Secure, HttpOnly, SameSite, Domain) by name only; CORS with one harmless test origin; mixed content; security.txt; version-revealing headers and public source maps; technologies and visible surface such as login forms and API references; inline event handlers and scripts without Subresource Integrity, flagged for manual review.
How it's scored
Starts at 100. Not HTTPS −40, invalid or expired certificate −40, failed TLS connection −30, CORS trusting any origin with credentials −25, no HSTS −15, no CSP −12, no http→https redirect −10, no clickjacking protection −8, active mixed content −8, Report-Only CSP −8, no X-Content-Type-Options −6, 'unsafe-inline' scripts −6, cookies without Secure −6, weak HSTS −5, and smaller deductions for other weak values. Many informational findings, such as a missing security.txt, cost nothing.
Tested with
Python requests (GET and HEAD only) + the standard-library ssl module
Try the Website Security Checker

Links & page errors

Technical name
Functional smoke test and form review
What it checks
Loads the page in a browser, records JavaScript console errors, uncaught exceptions and your own scripts, styles, images and fonts that fail to load, tests up to 12 unique links to the same site (navigation first) and up to 5 links to other sites, and reviews each form's markup: HTTPS, GET with passwords, labels, input types, autocomplete, external actions, a visible CSRF-style token and a submit button. Forms are never submitted, clicked, focused or filled in.
How it's scored
Starts at 100. Each broken internal link −10 (at most −40), each uncaught JavaScript error −10 (at most −30), each console error −5 (at most −20), each failed first-party file −4 (at most −20), a password form on HTTP, submitting to http:// or using GET −10 each, a placeholder as the only label −3. Broken external links and the other form notes are informational.
Tested with
Playwright with Chromium; link checks are HEAD with a GET fallback
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 evidence is collected

A finding only appears when a check actually saw the thing it describes — a header value, an element, a response. Each finding records where its evidence came from:

HTTP response
Status codes, redirects and response headers from a normal request to your page.
HTML
The page source your server sends, before any JavaScript runs.
Rendered page and browser runtime
The page after it loads in Chromium: the rendered elements, JavaScript errors and files that failed to load.
Lighthouse
Lab metrics and audits from one Lighthouse run.
axe-core
Accessibility rule results for the rendered page.
Crawl data
In site scans: the pages, links, titles and canonicals stored during the crawl — no extra requests.
robots.txt and sitemap
Your robots.txt rules and the URLs your XML sitemaps list.
TLS connection
The certificate and protocol version your server presents.

Privacy: evidence never contains cookie values, tokens, passwords, Authorization headers, API keys or anything typed into forms. Cookies are reported by name and flags only, form fields by name and label only, and query-string parameters that look like tokens are removed from URLs.

Confidence levels

Every finding says how sure we are, so you know what to act on straight away and what to check first.

High

Directly observed: a header value, a status code, an element that failed a rule. You can confirm it yourself in seconds.

Medium

A strong signal that depends on context — for example a cookie that looks like a session cookie from its name, or a page listed in the sitemap that no crawled page links to.

Low

A heuristic that needs a person to review, such as a form without a visible CSRF token or inline event handlers. These are worded as “potential” or “manual review” and are never presented as confirmed vulnerabilities.

Checks performed and “Not tested”

Reports list every rule we evaluated, including the ones that passed, so you can see what was covered and not just what went wrong. A short list of problems means something different when forty checks passed than when only five could run.

“Not tested” means a check didn't apply or wasn't safe to run — for example the cookie Secure check on a page that isn't served over HTTPS, or a link to a private address. “Skipped” means it couldn't run, usually because our own request failed or timed out; the area is then marked partial and the summary says which checks are missing. A timeout or DNS error on our side is “could not verify”, never a failure of your site.

Skipped and not-tested checks cost no points. If a whole area couldn't run — its engine was unavailable or it failed on our side — it is left out of the overall score instead of being counted as zero.

Safety: how security checks stay non-destructive

Every check is passive and read-only. In practice that means:

  • Our own requests use GET or HEAD only — never POST, PUT, PATCH or DELETE. When a page is opened in a browser, its own scripts run as they would for any visitor.
  • The CORS check is a single GET carrying one harmless Origin for a domain that can't exist (https://rudra-audit.invalid), with no cookies or credentials.
  • Only a short, fixed list of well-known files is requested — such as robots.txt, sitemap.xml, /.well-known/security.txt, llms.txt, humans.txt and the manifest your page links to, plus the health and API-description paths the server check lists above. We don't guess or enumerate other paths, and source maps are only checked when one of your own scripts names them.
  • Forms are never submitted, clicked, focused or filled in, and no attack payloads are sent.
  • We never sign in, send credentials or try passwords.
  • Requests to private and internal network addresses — localhost, 10.x, 192.168.x, cloud metadata services and similar — are blocked before they are sent, including redirect hops and, in our Playwright browser checks, every request the page makes while it loads.

Scoring

Each area starts at 100 and loses points for the problems found; speed uses Lighthouse's own score instead. The report lists every deduction next to the finding that caused it, so you can see exactly where the points went.

The same issue is never deducted twice: three cookies without Secure are one finding with one deduction. Where the number of occurrences matters, such as broken links or JavaScript errors, the deduction grows with the count up to a stated cap. Newer informational findings cost nothing; a few long-standing low-priority checks keep a small deduction, for example a missing Referrer-Policy (−4) or a minor accessibility rule (−2).

A site scan adds cross-page SEO checks — duplicate titles and descriptions, canonical problems, links to redirects, sitemap URLs that return errors, missing hreflang return links and identical content — that single-page checks can't see. Together they can remove at most 5 points from the SEO score, and problems already scored on each page aren't counted again.

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, or a check fails on our side, that category is left out of the average rather than being counted as zero or guessed. When Lighthouse isn't available, speed is covered by the quick check instead.

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, and label every metric as a lab measurement from one run.

  • Playwright and Chromium

    Loads pages in a real browser engine for the mobile layout, links, forms and errors, and accessibility checks, and captures screenshots. Requests to private network addresses are blocked inside the browser.

  • 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, using GET and HEAD requests only.

  • 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

Reads the configuration a browser receives: header values, cookie flags from the page's own response, CORS, TLS and the HTML. It isn't a penetration test — no exploitation, no login, no authenticated pages, no server-side code review and no vulnerability scanning of your software or dependencies.

Links and forms

Tests up to 12 links to the same site and 5 to other sites per page. Some servers return errors to automated visitors even when the page works for people, so external 401, 403, 405 and 429 answers are treated as inconclusive. Forms are never submitted, so server-side validation and CSRF protection can't be tested.

SEO

Reads the HTML your server sends, not the page after JavaScript runs. It doesn't measure rankings, traffic, keywords or backlinks, and complete structured data doesn't guarantee rich results.

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