Instant, evidence-based website audits — every score backed by a real, live check.
This is the original work of Zelvior, open-sourced at github.com/zelvior/audityxe. Licensed under the custom Audityxe Custom Open-Source License — free to use, modify, and redistribute, provided Zelvior is always credited as the original author with a link back to the canonical repository. The software is provided as-is, with no warranty, and Zelvior is not responsible for anything arising from its use. Read
LICENSE.mdin full before forking, deploying, or redistributing.
- What Audityxe is
- What makes it different
- Audit engine: what actually gets checked
- Scoring model
- Exports
- Tech stack
- SEO & discoverability
- Getting started
- Environment variables
- PageSpeed Insights (Lighthouse) setup
- Payments (NOWPayments)
- Redeem codes
- Site Crawl module
- Project structure
- Plans and limits
- Design system
- Scripts
- Deploying
- Contributing
- Security
- Credits
- License
Paste in a URL. Audityxe fetches the live page, scores it across six categories plus a large multi-area deep audit, attaches real evidence to every finding, hands back exact code fixes for the weakest spots, and packages the result into shareable social copy, a downloadable banner, an embeddable badge, and PDF/JSON/Markdown exports.
No crawl queue, no "results in 24 hours", no account required for your first audit.
| Typical audit tool | Audityxe | |
|---|---|---|
| Data source | Cached scans, screenshots, or an LLM guessing from a page description | Real HTTP requests made the moment you click Analyze |
| Reproducibility | Score drifts between runs | Deterministic — same page, same score |
| Evidence | "Improve your SEO" | The exact header, tag, DNS record, or selector that triggered the finding |
| Limits | Silently omits what it can't measure | States explicitly what it couldn't check, and excludes it from scoring |
| Storage | Full reports retained server-side | Nothing stored beyond a domain + score + date for the badge |
Every check below runs for free, with no paid third-party API, on every audit.
SEO & crawlability
- Title tag presence, length, and duplicate
<title>detection - Meta description presence and truncation risk
- Canonical tag presence and duplicate/conflicting canonical detection
- Heading hierarchy (single H1, logical H2/H3 order, duplicate heading text)
robots.txt— fetched live: existence, rules, blanket-disallow detection, sitemap cross-referencesitemap.xml— validity, URL count, freshness- Open Graph + Twitter Card completeness (
og:imageverified live,twitter:creator,twitter:image,fb:app_id) - JSON-LD structured data — parsed, validated, and typed (Organization, Product, Article, FAQPage, BreadcrumbList, LocalBusiness, WebSite)
- Broken internal links (live-sampled, not assumed)
AI Crawler Readiness (GEO)
Generative Engine Optimization — whether AI answer engines can read and cite the site, which is a different question from classic SEO:
- Named AI crawler blocking in
robots.txt(GPTBot, ChatGPT-User, ClaudeBot, Claude-Web, anthropic-ai, PerplexityBot, Google-Extended, CCBot, Bytespider, Applebot-Extended) llms.txtpresence and whether it has real contentX-Robots-TagHTTP header indexing blocks — invisible to any checker that only reads HTML- Conflicts between the header-level and meta-tag-level robots directives
noai/noimageaiAI-training opt-out signals
Security & headers
- Full security header audit: CSP (including
unsafe-inline/unsafe-eval/wildcard strength analysis), HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, COOP/COEP/CORP, Clear-Site-Data - Per-cookie
Secure/HttpOnly/SameSiteflags, session vs persistent, tracking-cookie heuristics - CORS misconfiguration (wildcard origin, wildcard + credentials)
- Mixed content detection
- Server/
X-Powered-Byversion disclosure - Dangerous HTTP methods (safe, read-only probing)
- Exposed
.env,.git, and config-file scanning - Directory listing detection
- Subresource Integrity coverage on cross-origin scripts and stylesheets
- Publicly exposed JavaScript source maps
target="_blank"tabnabbing risk (missingrel="noopener")- Forms posting to insecure (
http://) endpoints
TLS & DNS
- Live TLS handshake: protocol version, cipher, issuer, validity window, days-to-expiry, self-signed detection, hostname match, SAN count, key type/size, weak-protocol flagging
- SPF, DKIM, DMARC email authentication records
- DNSSEC validation
- CAA certificate-issuance restriction records
- Subdomain takeover detection against 20+ known vulnerable service fingerprints
- Nameserver redundancy / zone health
security.txtvulnerability disclosure policy
Accessibility
- Image
altcoverage, plus generic/placeholder alt-text detection - Form input label association
- Button and link accessible names
- Generic link text detection ("click here", "read more")
- Keyboard focus visibility — flags CSS suppressing the focus outline with no visible replacement
- Skip-to-content link presence
<html lang>declaration- Landmark regions (
header/nav/main/footer) and content sectioning - Positive
tabindexmisuse,aria-hiddenon root elements <iframe>titles- Color-contrast heuristics
Performance & mobile
- Real browser-rendered Lighthouse pass via Google PageSpeed Insights (Core Web Vitals: LCP, CLS, TBT, FCP, Speed Index)
- Real-world CrUX field data when Google has enough traffic on the origin — distinguished from lab data
- Render Proof — the actual Chrome screenshot(s) Lighthouse captures, embedded in the report. Two independent captures (mobile viewport from the primary pass, desktop viewport from a small parallel best-effort call) are fetched, and the viewer's own device picks which renders via CSS — a phone gets the sharp native mobile capture, a desktop visitor gets the larger, higher-resolution desktop one, instead of one fixed low-res image stretched to fit everyone
- Compression, cache headers, image format/sizing/lazy-loading, inline-base64 bloat
- Render-blocking resources, web-font weight
- Viewport configuration, tap-target sizing, responsive-class signals
- Apple touch icons, web app manifest, Safari mask-icon
Content, UX & intelligence
- Flesch-Kincaid readability grade, reading time, duplicate heading detection
- Legal & trust page detection (privacy, terms, contact, refund, etc.) scored against detected site type
- Monetization signals (ad networks, affiliate links, payment processors, donation platforms, cart/checkout, pricing)
- Technical stack fingerprinting (framework, CMS, hosting, analytics, tag managers, chat widgets)
- AI-generated / "vibe-coded" pattern detection — emoji-heavy headings, buzzword density, em-dash frequency, stock gradient/blur/grain patterns, default font pairings, lorem ipsum
- Multi-page same-origin crawl: internal link graph, orphan pages, extended broken-link coverage
- HTML validity: doctype, duplicate IDs, deprecated tags, div-ratio, comment volume
Scores are deterministic, not model-generated.
- Each finding is
pass/warn/fail, with a severity (critical/high/medium/low). - A module's 0–10 score is
10 − (weighted severity loss / scored findings) × 10. - Unverifiable findings never affect the score. If a DNS lookup times out or PageSpeed Insights fails, that's recorded as "we couldn't check this" and excluded from the math — it is not scored as a failure.
- If every finding in a module is unverifiable, the module reports
—(not scored) rather than inventing a number from zero data. criticalfindings force a module tocriticalstatus regardless of the arithmetic.
| Format | Contents |
|---|---|
| Full branded report — score donut, category breakdown, every module and finding with evidence, Lighthouse lab + field data, embedded render screenshot | |
| JSON | Complete machine-readable payload — every module, finding, severity, confidence, and evidence string |
| Markdown | Copy-to-clipboard / download, for pasting into GitHub Issues, Notion, or a PR |
| Badge | Embeddable "Audited by Audityxe" SVG badge with live verification |
| Social | Auto-generated X/LinkedIn post copy and a downloadable share banner |
- Next.js 14 (App Router) · React 18 · TypeScript
- Tailwind CSS with a fully CSS-variable-driven token system
- Framer Motion for animation
- Firebase — Auth + Firestore (accounts, plans, badge records, admin config)
- lucide-react icons · jsPDF exports
- Google PageSpeed Insights API for the real-browser pass
- NOWPayments for crypto checkout
What's already in place, and what's genuinely outside what code alone can do:
On-page and technical SEO (in place):
Organization,WebSite(with aSearchAction),SoftwareApplication,FAQPage, andBreadcrumbListJSON-LD structured data across the homepage and every nested content page.app/robots.tsexplicitly allow-lists every major AI/answer-engine crawler by name (GPTBot,ClaudeBot,anthropic-ai,PerplexityBot,Google-Extended,CCBot, and others) rather than relying on a bare wildcard rule, which some of these treat as ambiguous for their exact user-agent token.public/llms.txtandpublic/llms-full.txt— the emerging convention AI crawlers check for a structured summary of a site, independent of robots.txt.app/sitemap.tscovers every public route with sensiblepriority/changeFrequencyvalues.- Canonical URLs, Open Graph, and Twitter Card metadata on every page (
lib/seo.ts). - Google Search Console verification (meta tag +
google*.htmlfile inpublic/).
Backlinks — what's structurally built in vs. what's genuinely outside code's control:
The single strongest built-in backlink mechanism is the embeddable audit badge
(/badge → /api/badge/[domain]): every site that embeds one links back to Audityxe with a real,
dofollow <a href> — the more sites use it, the more real backlinks accumulate organically, with
zero manual link-building. That's already live and working (verified: no rel="nofollow" on the
generated snippet).
What code cannot do is manufacture backlinks from other real websites, or make an LLM's training
data include or prioritize Audityxe — both require other people, sites, and organizations actually
linking to or citing it, which is an external, ongoing process, not a one-time setting. A concrete
starting checklist for that outreach: submit to Product Hunt,
BetaList, SaaSHub,
AlternativeTo, and Indie Hackers; post a
"Show HN" on Hacker News; write a launch post on
dev.to or Hashnode linking back to the repo/site; open a
PR adding Audityxe to a relevant awesome-* GitHub list; and list it on developer-tool directories
like G2 or Capterra if it fits their categories. Every one
of these is a real inbound link from a real domain — the kind of link SEO and LLM-training-data
crawls actually weight, and not something that can be faked from inside this codebase without
risking a manipulative-link penalty.
git clone https://github.com/zelvior/audityxe.git
cd audityxe
npm install
cp .env.example .env.local # fill in the values below
npm run devOpen http://localhost:3000.
Running an audit requires a signed-in, email-verified account, or
/api/auditwill reject every request with a 401/403. Create an account locally and verify it before testing.
| Variable | Required | Purpose |
|---|---|---|
.env.example is the single source of truth — it documents every variable |
||
| with click-by-click instructions for where to obtain each key, including the exact Google Cloud | ||
| setting that breaks PageSpeed Insights if you get it wrong. Start there: |
cp .env.example .env.localSummary:
| Variable | Required | Purpose |
|---|---|---|
NEXT_PUBLIC_FIREBASE_* (6 vars) |
✅ | Firebase web config — public by design |
FIREBASE_PROJECT_ID / FIREBASE_CLIENT_EMAIL / FIREBASE_PRIVATE_KEY |
✅ | Firebase Admin service account (secret) |
BYOK_ENCRYPTION_KEY |
✅ | Encrypts user-supplied API keys at rest |
IP_HASH_SALT |
✅ | Salts IP hashes for anonymous rate limiting (no raw IPs stored) |
PAGESPEED_API_KEY |
➖ | Lighthouse module. Without it PSI uses a shared quota that rate-limits hard |
AI_API_KEY / AI_BASE_URL / AI_MODEL |
➖ | Written verdict + promo copy. Scores never depend on this |
GEMINI_API_KEY / GEMINI_MODEL |
➖ | Alternative AI provider |
NOWPAYMENTS_API_KEY |
➖ | Enables crypto checkout |
NOWPAYMENTS_IPN_SECRET |
Mandatory if the API key is set — checkout refuses to start without it | |
NEXT_PUBLIC_DONATION_URL |
➖ | Footer Sponsor button target |
ADMIN_EMAILS / ADMIN_PASSWORD |
➖ | Enables /admin. Unset = admin panel disabled |
CRON_SECRET |
➖ | Protects /api/cron/* endpoints |
GOOGLE_SITE_VERIFICATION |
➖ | Search Console verification |
AUDITYXE_KILL_SWITCH / *_MESSAGE |
➖ | Emergency maintenance mode without redeploying code |
The Lighthouse module needs a Google API key. It's free, no billing required.
- Go to console.cloud.google.com and sign in.
- Create a new project via the project picker at the top.
- Enable the PageSpeed Insights API.
- Go to APIs & Services → Credentials → + Create Credentials → API key.
⚠️ Set "Application restrictions" toNone.
Why
Nonematters: an HTTP referrer restriction only validates requests that carry a browserRefererheader. Audityxe calls PSI server-side, which sends no referrer — so a referrer-restricted key is rejected with a 403 on every single request, permanently. An IP address restriction is also unsafe here, because serverless hosting uses non-fixed outbound IPs. This is enforced by Google's API gateway and cannot be worked around in application code.
Users can also add their own key in Settings, which is validated against the live API at save time and grants unlimited Lighthouse passes (their own Google quota) instead of the shared 1/week cap.
Crypto checkout uses the NOWPayments hosted invoice flow — NOWPayments hosts the currency picker, wallet address, QR code, and confirmation states, so no wallet address ever touches this codebase.
Flow:
POST /api/payments/nowpayments/create— authenticated; prices the plan server-side (never trusts a client-sent amount) and creates an invoice.- User is redirected to the NOWPayments hosted checkout.
- NOWPayments
POSTs status updates to/api/payments/nowpayments/ipn. - The webhook verifies the callback, then credits the plan.
Setup:
- Create a NOWPayments account and add a payout wallet.
- Copy your API key →
NOWPAYMENTS_API_KEY. - In Store Settings → Instant Payment Notifications, generate an IPN secret →
NOWPAYMENTS_IPN_SECRET. - Set the IPN callback URL to
https://your-domain.com/api/payments/nowpayments/ipn.
Also supported (see .env.example for full setup steps):
- Recurring subscriptions — monthly-only auto-renewal via NOWPayments' email-subscription flow (
/api/payments/nowpayments/subscribe, wired into the pricing page as "auto-renew monthly by email"). There is no annual tier — one recurring period, 30 days, matching the one-off price exactly. RequiresNOWPAYMENTS_EMAIL/NOWPAYMENTS_PASSWORD(subscription endpoints use a short-lived Bearer JWT minted on demand, not the API key directly) plus aNOWPAYMENTS_PLAN_STANDARD/NOWPAYMENTS_PLAN_PROplan id from the dashboard. - Donations —
/donateembeds the real NOWPayments donation widget viaNEXT_PUBLIC_NOWPAYMENTS_DONATION_KEY(a public, funds-safe key — not the same asNOWPAYMENTS_API_KEY). The footer's Sponsor button links there. The donation<iframe>requiresnowpayments.ioto be allowed in this app'sframe-srcContent-Security-Policy (next.config.js) — without it the browser blocks the widget outright with "This content is blocked." - Live payment status page —
/payment/statuspolls the app's own backend (never NOWPayments directly from the browser) every few seconds after checkout, showing "waiting for confirmation" until the IPN webhook actually credits the plan, then a clear confirmation. This is thesuccess_urlfor both one-off invoices and subscriptions. - Single price source of truth — all pricing (the pricing page, the manual "pay another way" email flow, and crypto checkout) reads from
PLANSinlib/plans.ts. There used to be a second, separate price table hardcoded in the NOWPayments integration that had silently drifted from the real advertised prices — fixed, and structurally can't drift again since there's only one table now. - Prices are env-var overridable —
NEXT_PUBLIC_STANDARD_PRICE_USD/NEXT_PUBLIC_PRO_PRICE_USDlet you retune plan prices from Vercel's Environment Variables UI, no code change needed. Set the var, redeploy (Next.js inlinesNEXT_PUBLIC_*vars at build time, so a redeploy is required for it to take effect). If unset, prices fall back to $5 Standard / $6 Pro.
Getting "Crypto amount ... is less than minimal"? NOWPayments enforces a minimum crypto amount per invoice that varies by coin — currencies with meaningful network/gas fees (ETH-network USDT, for example) can reject a low-USD invoice outright even though the price itself is valid. Standard was originally priced at $3, which several coins' minimums sat right at or above; it's now $5 by default, with real headroom. If you lower NEXT_PUBLIC_STANDARD_PRICE_USD back down and see this again, that's why — raise it back up, or expect certain coins to be unavailable at checkout below their own minimum.
Getting "INVALID_API_KEY" (HTTP 403) with a key that looks completely correct? This exact NOWPayments error message covers three different causes — see the full checklist in .env.example (API access must be separately enabled in dashboard Settings, a payout wallet must be configured, and sandbox keys are rejected by the production endpoint this app calls). The app also defensively trims the key value in case a stray newline was pasted into an env var.
That detailed diagnosis is deliberately operator-only: createInvoice's translated error (describeNowPaymentsError in lib/nowpayments.ts) is logged in full via console.error in both /api/payments/nowpayments/create and /subscribe, but the customer's browser only ever sees a short, generic "temporarily unavailable, try again or use email" message. Returning the full dashboard-setting diagnosis straight to a paying customer's checkout button used to be the actual behavior here — fixed, since it leaked internal account structure to any visitor and read as a wall of setup instructions to someone just trying to pay. Check your deployment's function logs (e.g. the Vercel dashboard) for the real cause when this fires.
Verified against multiple independent sources before shipping — the official NOWPayments Postman docs, their own nowpayments-sdk-nodejs GitHub repo, and their blog's subscriptions documentation all agree on the request field names and the IPN signing algorithm used here (JSON.stringify of a recursively key-sorted payload, HMAC-SHA512). This is as far as the integration can be verified without live credentials — see the warning below.
Security properties of the IPN handler:
- Signature is HMAC-SHA512 over the recursively key-sorted JSON payload, compared against the
x-nowpayments-sigheader using a constant-time comparison. - Verified against the raw request body — re-serializing a parsed object first can reorder keys and silently break verification.
- A missing IPN secret is a hard failure, never a skipped check. Without this, the endpoint would let anyone POST "payment finished" and grant themselves a paid plan.
- Crediting is idempotent and transactional — NOWPayments retries callbacks, so the payment ID is recorded and reprocessing is a no-op rather than stacking extra paid days.
- Paid time stacks onto remaining time rather than overwriting it.
- Transient Firestore failures return
500so NOWPayments retries, rather than silently swallowing a real payment.
⚠️ Verify before going live. Payment integrations must be tested against your own account. Run a small real payment end-to-end and confirm the plan is credited before accepting real money.
See the Refund Policy for refund handling, including why crypto refunds are sent as new transactions.
For giveaways and comps — instant, free plan access, redeemed at /account. Manage them from
/admin/redeem-codes (create one-off codes, or generate a batch of distinct single-use codes for
something like a launch giveaway). There used to also be a separate percent-off discount code type
applied manually at checkout — removed, since there's no self-serve checkout flow left for it to
adjust (NOWPayments' hosted invoice always charges exactly the advertised price), so it was sitting
half-wired to a checkout path that no longer exists. Redeem codes (plan_grant) are unaffected and
fully supported. The old /admin/discount-codes URL 301-redirects to the new one.
lib/site-crawl.ts extends a handful of checks (broken internal links, thin-content pages, orphan
pages) past the single page the rest of the audit is scoped to, by crawling a bounded, same-origin
sample of pages starting from the homepage. As of 3.5.0 there are two crawl modes, user-selectable
per audit from a toggle under the URL field ("Site crawl: Fast / Deep"):
| Fast (default) | Deep | |
|---|---|---|
| Source file | lib/site-crawl.ts |
lib/site-crawl-deep.ts (lazy-imported — see below) |
| Discovery | Homepage's own links + /sitemap.xml seeds |
Real multi-hop request queue — follows links found on every page it visits |
| Pages | Up to 6 | Up to 25 |
| Depth | 1 hop from homepage | Up to 3 hops |
| HTML parsing | Regex-based | Real DOM traversal via cheerio |
| robots.txt | Not checked | Fetched once, Disallow rules enforced before a URL is ever queued |
| Retries | None | One retry with backoff per failed/429/503 request |
| Concurrency | 3 in flight | 5 in flight |
| Typical cost | A few seconds | Up to ~40s internal budget (audit's overall timeout is raised to 60s for deep-mode requests specifically, see DEEP_OVERALL_AUDIT_TIMEOUT_MS in lib/analyze.ts) |
On the standalone Crawlee-based crawler package supplied for review: we evaluated merging it in
directly instead of building site-crawl-deep.ts. Verdict: it cannot be built as delivered.
@audityxe-crawler/core's package.json depends on @audityxe-crawler/fs-storage (its default
request-queue storage backend) via workspace:* — that package is not present anywhere in the
supplied archive, so core, and every package layered on it (basic-crawler, cheerio-crawler,
http-crawler), cannot install or compile. Separately, every package in it is ESM-only
("type": "module") and declares "engines": { "node": ">=22.0.0" }, built via a pnpm workspace +
Turborepo pipeline that assumes the whole monorepo is present — not a requirement this project
otherwise makes of its deployment target.
Rather than skip deep mode or ship something that fails to build, site-crawl-deep.ts
reimplements the package's genuinely useful techniques directly against the real, published
cheerio package (the same HTML parser the crawler package itself wraps) — the one new dependency
this required — with no other new dependency, no missing-package blocker, and no Node 22
requirement:
- Request queue — real breadth-first traversal, not a fixed one-page link sample.
- Retries — one retry with backoff before a request is recorded as failed.
- Concurrency pool — bounded concurrent fetches (shared
runWithConcurrencyhelper). - Session/UA rotation — requests rotate across a small pool of realistic desktop user agents.
- robots.txt compliance — parsed once per crawl; every candidate URL is checked against Disallow rules before being queued, the courtesy a real crawler owes a site.
- Cheerio-based parsing — real DOM traversal for links/title/word count, more accurate than fast mode's regex approach on malformed or unusual HTML.
No module from the reference package was skipped as a technique — what's not present is the
package's own request-queue storage engine (blocked by the missing fs-storage dependency) and
its Node 22/ESM toolchain, neither of which this reimplementation needs: site-crawl-deep.ts keeps
its queue in memory for the duration of one audit request, which is all a single-request serverless
function needs.
site-crawl-deep.ts and its cheerio dependency are only loaded via a dynamic import() when
crawlMode: "deep" is actually requested (see the ternary around crawlSite/crawlSiteDeep in
lib/analyze.ts) — the default fast path never pulls cheerio into its bundle or cold start.
Known limitation (unchanged in both modes): this is a plain-fetch crawl, not a headless browser.
On JavaScript-heavy SPAs (client-rendered React/Vue apps with a near-empty static HTML shell), it
can only see what's in the initial server response — possibleJsRenderedContent exists specifically
to flag this case rather than silently under-reporting. A future update could add a bounded
Playwright/Puppeteer serverless fallback for exactly these sites, as noted in site-crawl.ts's own
header comment; this remains unimplemented for the cold-start/bundle-size reasons already explained
there.
audityxe/
├── README.md
├── firestore.rules
├── LICENSE.md
├── middleware.ts
├── next-env.d.ts
├── next.config.js
├── package.json
├── postcss.config.js
├── tailwind.config.ts
├── tsconfig.json
├── vercel.json
├── .env.example
├── .eslintrc.json
├── app/
│ ├── error.tsx / global-error.tsx / loading.tsx / not-found.tsx
│ ├── layout.tsx, page.tsx, globals.css
│ ├── opengraph-image.tsx, robots.ts, sitemap.ts
│ ├── about/ acceptable-use/ account/ admin/
│ │ ├── activity/ announcement/ dashboard/ redeem-codes/ users/
│ ├── api/
│ │ ├── account/ # profile, delete, redeem-code
│ │ ├── admin/ # activity, announcement, audits, redeem-codes, search, stats, users
│ │ ├── announcement/
│ │ ├── audit/ # the main audit endpoint (+ bulk/)
│ │ ├── badge/[domain]/
│ │ ├── banner-bg/
│ │ ├── cron/cleanup-unverified/
│ │ ├── payments/nowpayments/ # create, ipn, status, subscribe
│ │ └── settings/
│ ├── audit-verification/ badge/ bulk/ changelog/ contact/ cookies/
│ ├── crash-reports/ credits/ disclaimer/ donate/ dpa/ faq/
│ ├── forgot-password/ guide/ license/ login/ maintenance/ methodology/
│ ├── offline/ payment/status/ pricing/ privacy/ refund-policy/
│ ├── register/ sample-report/ settings/ status/ terms/
│ ├── third-party-services/ trust-center/ verify-email/
├── components/
│ ├── AnnouncementBanner.tsx AuditActionBar.tsx AuditDefenderGame.tsx
│ ├── AuditModules.tsx AuthSidePanel.tsx BannerCanvas.tsx
│ ├── CompetitorBattle.tsx DiffFixes.tsx Footer.tsx
│ ├── Header.tsx Hero.tsx HomepageSeoContent.tsx
│ ├── HoverRevealButton.tsx IsometricLoader.tsx LegalLayout.tsx
│ ├── Logo.tsx ModerationGuard.tsx NotFoundGame.tsx
│ ├── OAuthButtons.tsx OfflineGame.tsx Onboarding.tsx
│ ├── PasswordInput.tsx PerformanceMetrics.tsx PromoKit.tsx
│ ├── RenderProof.tsx SampleReportView.tsx ScanProgress.tsx
│ ├── ScoreCard.tsx TrustBadges.tsx TrustSection.tsx
│ └── VerifyEmailBanner.tsx
├── context/
│ └── AuthContext.tsx
├── lib/
│ ├── analyze.ts # orchestrates a full audit
│ ├── audit-modules.ts # turns signals into scored modules + findings
│ ├── audit-defender-data.ts audit-log.ts admin.ts / admin-log.ts
│ ├── ai.ts announcement.ts badge-store.ts
│ ├── bloom-filter.ts breadcrumb.ts constants.ts
│ ├── counters.ts crypto.ts currency.ts
│ ├── deep-signals.ts # HTML/DOM signal extraction
│ ├── discount-codes.ts # redeem/giveaway codes only — percent-off codes removed
│ ├── dns-email-auth.ts dns-security.ts
│ ├── export-payload.ts # JSON report builder
│ ├── fetch-json.ts gemini.ts ip.ts
│ ├── legal-pages.ts network-checks.ts
│ ├── nowpayments.ts # invoice creation + IPN HMAC verification
│ ├── ops.ts pagespeed.ts pdf-export.ts
│ ├── plans.ts rate-limit.ts security.ts
│ ├── seo.ts site-context.ts
│ ├── site-crawl.ts # multi-page crawl, link graph, JS-render heuristic
│ ├── tls-check.ts # live TLS handshake inspection
│ ├── types.ts url-safety.ts user-moderation.ts
│ ├── user-settings.ts
│ └── firebase/
│ ├── admin.ts
│ └── client.ts
└── public/
├── google08dd6d11c7637a2e.html
├── llms.txt / llms-full.txt
├── manifest.webmanifest
├── security.txt
Generated from a full repository scan (187 files analyzed at commit 99feeee); regenerate this
block whenever routes or top-level modules are added or removed.
| Free | Standard | Pro | |
|---|---|---|---|
| All 6 categories + full deep audit | ✅ | ✅ | ✅ |
| Daily audits | 2 | more | most |
| Competitor comparison | — | ✅ | ✅ |
| Bulk audit (up to 20 URLs) | — | — | ✅ |
| Real-browser Lighthouse pass | — | — | 1/week shared · unlimited with your own key |
Every plan runs the identical engine — nothing is dumbed down on Free.
- Palette: warm editorial — paper/rust, fully token-driven via CSS custom properties
- Light/dark: automatic, follows
prefers-color-scheme. No toggle, no flash, no JS - Type: Fraunces (display) + Public Sans (body)
- Motif: hand-drawn SVG underlines, highlights, and circles on key headings
- No shadows or glows — flat borders and background tints only
- Respects
prefers-reduced-motionthroughout
npm run dev # development server
npm run build # production build
npm run start # serve the production build
npx tsc --noEmit # type check
npx next lint # lintIssues and pull requests are welcome. Before opening a PR:
npx tsc --noEmit && npx next lint && npm run buildAll three must pass. Please keep new audit checks deterministic and evidence-backed — if a check can't state why it failed with a real artifact from the page, it doesn't belong in the engine.
Found a vulnerability? Please don't open a public issue. Email zelvior@proton.me directly.
Never commit .env.local, Firebase service-account keys, ENCRYPTION_KEY, or NOWPayments
credentials.
Audityxe is built on the work of many others — see the full Credits page for every tool, framework, font, and interactive-component source used, with attribution.
Audityxe Custom Open-Source License — use it, modify it, ship it, build a business on it. Just credit Zelvior as the original author, clearly and visibly, with a link back to github.com/zelvior/audityxe.