What GazeRank checks, and how the score works

1. Crawl. GazeRank fetches your homepage and key internal pages, plus robots.txt, llms.txt and your sitemap.
2. Measure. Performance comes from Google PageSpeed Insights (Lighthouse, mobile). Accessibility comes from axe-core. Headers, robots.txt rules and structured data are read directly from your site.
3. Score. Each area gets a score from 0 to 100.
4. Rank. Findings are ranked by impact. The top fixes appear first, each with the evidence, the owner, the time it takes and the exact change.
5. Re-check and monitor. After you make a change, you can re-check it, and you can schedule weekly or monthly scans with email alerts.

• •A score out of 100 for the whole site, and for each of the five areas
• •The few fixes worth making first, ranked by impact
• •Quick wins you can finish in one sitting
• •AI platform readiness for ChatGPT, Claude, Perplexity and Gemini
• •Real Lighthouse performance numbers
• •Your score history across scans

The overall score is the average of the measured category scores: SEO, Performance, Accessibility, Content and AI Search Visibility.

A real example, from a scan of gazerank.com:

If a category can't be measured, the report shows it as not measured instead of guessing a number, and it is left out of the average. A scan where performance couldn't be measured is averaged over the four categories that were measured, and the report says which.

Performance and Accessibility are never estimated when Google returns real Lighthouse data — those two numbers are set from the measurement itself, and the overall score is recalculated from them.

These checks measure whether AI systems can access and understand your site. They are signals, not a measure of actual citations (see section 10).

That is 6 + 4 + 4 + 4 + 4 + 3 = 25 checks. The Fast area is dropped entirely when performance couldn't be measured, so such a scan runs 22 of the 25 checks rather than scoring performance on the viewport tag alone.

Each platform gets its own weighted score, so a site can be ready for one assistant and blocked for another.

A crawler blocked in robots.txt marks that platform blocked and the report shows the exact disallow rule to change.

robots.txt · llms.txt · sitemap · canonical tags · noindex tags · AI crawlers blocked · broken links · HTTPS · security headers (Content-Security-Policy, HSTS, X-Frame-Options).

Performance numbers come from Google PageSpeed Insights (Lighthouse), run on a mobile profile:

• •Largest Contentful Paint (LCP)
• •Cumulative Layout Shift (CLS)
• •Interaction to Next Paint (INP), when Google has data for it
• •First Contentful Paint, Total Blocking Time and Speed Index

Each Core Web Vital is rated Good, Needs improvement or Poor. These numbers vary between runs. LCP can move by about a second, so look at the rating and the trend, not a single scan. If PageSpeed can't produce a result, the report says not measured.

Accessibility uses axe-core, run against WCAG 2.2 rules, with failing Lighthouse audits reported alongside it. Automated testing catches only part of the accessibility problems a real person might hit, so treat a high score as a good baseline, not a full audit.

A scan runs 34 rule-based SEO and Content checks, plus an AI pass that can add its own findings on top. The rule-based checks are:

Content checks: low content readability (Flesch Reading Ease below 60) · AI-generic filler language. Two more freshness and breadth checks — missing published/updated dates, and no multimodal content (tables, video, embeds) — are reported under AI Search Visibility.

Counting only what the scanner can verify: 60 deterministic checks run across all categories (32 SEO, 22 Security, 2 Accessibility, 2 Content, 2 AI Search Visibility). The AI layer can surface issues those rules don't cover, so a report can contain more findings than the list above.

• It doesn't measure real AI citations. AI readiness is about whether your site is technically and editorially ready, not whether any assistant mentions you. No tool can guarantee a citation.
• It can't see content that only exists after JavaScript runs. If a page builds its content that way, the report flags the page and marks the affected findings as incomplete. Performance data comes from PageSpeed Insights, which does run JavaScript.
• It samples pages. A scan crawls up to 12 pages — your homepage plus internal links found on it, one level deep — not a full recursive crawl. The report shows how many pages were analyzed. The no-signup preview is capped at 5 pages and shows the top 3 findings.
• It doesn't predict rankings. Fixing issues removes obstacles, but search and AI results depend on much more than technical health.

Each priority fix shows why it matters, the evidence, who usually owns it, how long it takes and the exact change. After you make a change, Verify this fix re-checks that issue on your site.

What re-checking can and can't confirm:

• •It re-crawls up to 3 pages of your site, so it's fast but not sitewide.
• •Rule-based findings (missing alt text, blocked crawler, missing meta description) can be verified automatically when the same pages are re-crawled.
• •Findings that came from the AI model are reported as partially verified — the model isn't identical run to run.
• •Performance issues are reported as not re-checked, because the quick re-check doesn't re-measure Lighthouse. Run a full scan to re-measure them.
• •Findings that need editorial judgment are labelled for manual review, never marked fixed automatically.

• Google PageSpeed Insights (Lighthouse) for performance and accessibility audit failures
• axe-core for accessibility checks against WCAG 2.2
• Your own site, fetched directly: robots.txt, llms.txt, sitemap, headers, HTML and structured data
• An AI model for content-quality judgments, the written summary, and SEO, Content and AI Search Visibility findings that rule-based checks can't catch. It reviews your most important pages in detail and gets titles and word counts for the rest. If it's unavailable, the report falls back to rule-based checks only and says so.