How Audityxe actually measures a site

Short version, before the detailed sections below: when you submit a URL, Audityxe's audit engine makes a live HTTP request to that exact page — not a cached copy, not a database lookup — and parses the real HTML and response headers it gets back. There's no headless browser rendering JavaScript at this stage (that's what the Pro-only PageSpeed pass adds separately, below); this first pass reads what any server or bot would actually receive.

From that single live fetch, the pipeline runs dozens of distinct checks across six scored categories, plus additional deep-audit modules (AI Answer Engine Readiness among them) shown separately from the six category scores:

• Technical & Metadata Health — title tag, meta description, canonical tag, viewport meta, charset, doctype.
• SEO Foundations — heading hierarchy (one H1, logical H2/H3 order), structured data (JSON-LD), robots.txt and sitemap.xml fetched live and checked for real matches, Open Graph and Twitter Card tags.
• Security — HTTPS enforcement, HSTS, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, and other response headers read directly off the live HTTP response.
• Accessibility — image alt text coverage, form label association, color-contrast heuristics, keyboard focus visibility (flags CSS that suppresses the focus outline with no visible replacement), heading structure re-checked from an accessibility angle.
• UX & Technical Hygiene — mobile viewport configuration, tap-target sizing signals, a sampled pass over on-page links and images to flag ones that 404 or fail to load, ads.txt presence where relevant.
• AI Answer Engine Readiness (AEO/GEO) — a deep-audit module, not one of the six scored categories: two distinct questions — whether AI answer engines like ChatGPT, Claude, and Perplexity can actually crawl the site at all (named AI-bot rules in robots.txt, whether an llms.txt is present, whether the X-Robots-Tag HTTP header blocks indexing independently of the HTML meta tag, a noai/noimageai opt-out signal), and separately whether the content is actually shaped to be lifted as a direct, citable answer (FAQPage/HowTo/Speakable schema, question-phrased headings, a direct-answer opening paragraph).
• Performance (Pro only) — a real browser-rendered pass via Google PageSpeed Insights, covering Core Web Vitals (LCP, CLS, TBT, FCP, Speed Index) rather than estimating from static HTML.

Every category score is deterministic: the same input HTML and headers always produce the same category score, computed by fixed rules, not a language model guessing a number. The overall score (out of 10) is a weighted average of the six category scores — the exact weights and thresholds are documented in Section 4 below. The one place a model is involved at all is optional written commentary (the one-line verdict, and — Pro-only, bring-your-own-key — promo copy); it never touches the numbers themselves.

Audityxe applies the same strict benchmark to every website it audits — there's no per-industry curve, no "good enough for a small business" leniency, no manual override. That's what makes a website audit score comparable across two unrelated sites, or across the same site audited weeks apart: the yardstick never moves.

Every fix suggestion is evidence-based: rather than a generic "improve your SEO" note, each one names the exact tag, header, or HTML pattern that caused the deduction, so you can verify it yourself in view-source and re-run the audit to confirm the fix landed. See Section 6 below for exactly how fixes are generated.

Full detail on every one of these — the exact network requests made, the category weighting formula, competitor-comparison methodology, and what Audityxe deliberately can't measure — is in the sections below.

When you click "Analyze Now," our server fetches your page's live HTML directly — the same way a browser or search engine crawler would, with a real HTTP request, following real redirects, reading real response headers. There is no cached database of pre-scored sites; every audit is a fresh network request made at that moment.

In parallel, we also fetch your site's real /robots.txt and /sitemap.xml, sample a handful of your on-page links and images with live HTTP requests, check for a real /ads.txt file, and run a real browser-rendered performance and accessibility pass. Nothing here is simulated — see the "Live network requests" section below for the exact list.

This distinction matters, so we keep it explicit everywhere in the product:

• The target page itself, with manual redirect-chain tracking (real hop count, HTTPS→HTTP downgrade detection)
• /robots.txt — existence, rules, sitemap cross-reference, and whether any named AI crawler (GPTBot, ClaudeBot, PerplexityBot, Google-Extended, etc.) is specifically blocked
• /sitemap.xml — validity, URL count, freshness data
• /llms.txt — existence and whether it has real content, for AI-answer-engine readiness
• /ads.txt — existence and entry count
• Up to 10 on-page links, checked live via HEAD/GET for broken (404/410/5xx) responses
• Up to 8 on-page images, checked live via HEAD for actual file size and content-type
• The declared og:image URL, checked live to confirm it actually loads as an image
• A full render of the page in real Chrome (via Google's PageSpeed Insights service) for performance, accessibility, and Core Web Vitals

Each category starts from a baseline and real signals add or subtract points — never randomness. For example, Technical & Metadata Health adds points for a present meta description, canonical tag, HTTPS, structured data, and a cross-referenced sitemap, and subtracts points for a missing robots.txt, a blanket Disallow: /, or a noindex directive. The exact formulas are open in the codebase (lib/analyze.ts) — we're not asking you to trust a black box.

Beyond parsing HTML, Audityxe also has your page actually rendered in real Chrome — via Google's free PageSpeed Insights service, the same underlying engine (Lighthouse) that powers Chrome DevTools. This measures things static HTML parsing simply can't: real Largest Contentful Paint, Cumulative Layout Shift, Total Blocking Time, and a full rendered accessibility audit (contrast, focus order, ARIA correctness against the actual rendered DOM). Every specific issue it flags is shown as its own finding with a description, not folded into a single opaque score.

Fixes are template-based, triggered by specific real findings — e.g. "no meta description found" always produces the same category of fix with a concrete before/ after snippet. Every fix also carries an evidence line stating exactly what was checked and what was found — "sent a live GET request to /sitemap.xml — no successful response," for example — so you can verify it yourself rather than take our word for it. Fixes are not independently validated against your live codebase (we don't have access to it) — they're the standard, correct fix for the specific problem detected. Always test a fix in a staging environment before shipping to production.

When a competitor URL is provided (Standard/Pro plans), we run the exact same audit pipeline against it independently, then compare category-by-category. A category is called out as a "win" only when the score difference is 0.4 or greater, to avoid overstating noise-level differences as meaningful wins.

Full audit results are not stored on our servers once returned to your browser — there's no public report page, no cross-account history, and no database of who audited what. Everything you see is computed fresh for you, for that request, and belongs to you: use the copy/export/share buttons on any result to keep your own copy.

One narrow exception: to power the embeddable badge at /badge, we keep a per-domain record of your site's most recent overall score and audit date — nothing else about the audit is stored alongside it.