How Audityxe actually measures a site

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
• /sitemap.xml — validity, URL count, freshness data
• /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.

Audits are not stored on our servers once the result is 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.