Methodology
How AIClicks works
Every scanner has a methodology. Most won't tell you theirs. Here's ours — what we test, how we verify it, how we score it, and what we can't see.
The verification layer
Scanners are wrong in two directions: they cry wolf (false positives) and they miss things (false negatives). Our verification layer attacks the first problem head-on: every HIGH and CRITICAL finding is independently re-probed with a second, distinct test before it reaches your report.
If the finding doesn't reproduce, it's downgraded to tentative and labeled NOT REPRODUCED with the explanation attached — visible in your report, never silently dropped. Findings whose type has no supported second probe keep the engine's confidence standing, and say so explicitly.
Scoring
Each module scores 0–100 and maps to a letter grade: A (90+), B (75+), C (55+), D (35+), F (below 35). The overall score is a weighted blend of module scores. Scores are snapshots of the live site at scan time — re-scan after changes to track movement.
Every scan reports scan quality: which checks completed, which were skipped or timed out, and how many findings passed verification. A 70 with full coverage means more than a 90 with gaps — we show you the difference.
The nine modules
Module 01
Cyber Security
We probe the live site the way an external attacker sees it: TLS configuration and certificate chain, security headers, DNS records (CAA, DNSSEC, DANE), open ports with banner confirmation, sensitive-path exposure, and active tests for XSS, SQL injection, CORS, and host-header issues on authorized domains. Findings are correlated against the OSV vulnerability database and a curated CVE catalog.
Honest limitation: We test from the outside — no credentials, no authenticated areas, no source code. Logic flaws, business-logic abuse, and vulnerabilities behind login walls are out of scope. Port results depend on network path; banner confirmation is required before a finding is raised.
Module 02
Quantum / Post-Quantum Readiness
We read the actually negotiated TLS 1.3 key-exchange group from a live handshake — the real signal for PQC readiness — and check whether it is a hybrid post-quantum group (ML-KEM) or classical. We also inspect the certificate signature algorithm and grade harvest-now-decrypt-later exposure against the NSA CNSA 2.0 timeline.
Honest limitation: We observe the negotiated group, not the server's full supported-groups list. Certificate PQC signatures (ML-DSA) are not yet issued by public CAs, so that check is informational until the ecosystem catches up.
Module 03
AI Content Detection
An ensemble of five independent statistical detectors (perplexity/entropy band, burstiness, lexical diversity, marketing-phrase signatures, formulaic scaffolding) votes on each page's text, with model-family stylistic attribution and C2PA/SynthID media-provenance checks. Agreement across detectors — not any single metric — drives the call.
Honest limitation: All detection is probabilistic, never proof. Heavily edited AI text evades statistical detectors, and false positives occur — especially on formulaic human writing. Never use this for consequential decisions (employment, academic discipline) without human review.
Module 04
GEO / AI Visibility
We grade readiness for generative answer engines across three pillars: Schema.org depth (key citation types and property completeness), E-E-A-T signals (organization identity, authorship, dates, trust links), and citation readiness (FAQ/HowTo schema, llms.txt, crawl surface, content freshness).
Honest limitation: We measure the technical surface answer engines consume — we cannot observe proprietary ranking or citation decisions inside ChatGPT, Perplexity, or Google AI Overviews. Scores reflect best-practice readiness, not guaranteed citation.
Module 05
Blockchain Intelligence
We detect on-page Web3 surface: wallet-connect patterns, smart-contract address references, and token/chain identifiers, then assess the exposure they create (phishing-adjacent patterns, drainer-kit signatures).
Honest limitation: We analyze the website's Web3 surface, not on-chain activity. We do not audit smart-contract code or trace transactions.
Module 06
Performance
A lab heuristic built from observable signals — time to first byte, render-blocking resources, image hygiene (dimensions, lazy-loading, modern formats), compression, caching headers, DOM complexity, font-loading strategy, and transport protocol — estimates Core Web Vitals risk (LCP, CLS, INP) Lighthouse-style.
Honest limitation: This is a lab estimate, not field data. Real Core Web Vitals (CrUX p75) require real-user measurement or a headless-browser run under controlled conditions. Treat grades as risk signals, not field truth.
Module 07
Privacy & Compliance
We inventory trackers and fingerprinting APIs in the page, detect consent-management platforms, classify cookies, map third-party data flows, and check for privacy/cookie policy links — then grade GDPR/CCPA posture. We specifically flag pre-consent tracking: trackers that fire before any consent gate.
Honest limitation: We observe the client side only. Server-side data sharing, retention practices, and data-sale disclosures cannot be verified passively. This is compliance posture signaling, not legal advice.
Module 08
Accessibility
Static WCAG 2.2 analysis in the axe-core tradition: alt text, form labels, page language, title, heading structure and hierarchy, link purpose, zoom lockout, landmark regions, ARIA usage, focus visibility, and tab order. Each violation maps to its success criterion, level, and — via our litigation-risk layer — ADA/EAA exposure correlation.
Honest limitation: Static analysis catches roughly a third to half of real barriers. Color contrast ratios, keyboard traps, focus order, and screen-reader usability require rendered testing and human judgment. A passing score is not a conformance claim.
Module 09
Brand Protection
We generate lookalike-domain candidates (typosquats, homoglyphs, TLD variants) for the target brand and check registration status and liveness — surfacing live lookalike sites that may indicate phishing or brand abuse.
Honest limitation: Candidate generation is heuristic; we cannot enumerate every possible variant, and a registered lookalike is not proof of malicious intent. Manual review is required before action.
Data handling
- We fetch your site's public pages, headers, DNS records, and TLS handshake — the same data any visitor's browser receives.
- Active tests (XSS, SQLi probes) run only on domains you've verified or explicitly authorized, using non-destructive payloads.
- Scan reports are private to your account unless you choose to share them.
- We don't sell scan data. Monitoring data is used only to power your alerts.
Methodology you can verify. Scans you can reproduce.