Checks

Every Inspector run fans out to six checks in parallel. Each check has its own panel on the detail page, and each contributes data to the Issues panel and the Inspector Score.

A check terminates in one of three states:

A failed check shows its error message in its panel. The other five checks still complete and contribute to the score.

CrUX (Field Data)

The CrUX panel renders real-world Core Web Vitals collected by Google from Chrome users over the past 28 days. It's labeled Field Data (CrUX) and shows:

• p75 LCP, INP, CLS, FCP, TTFB
• Form factor matching your device toggle (PHONE for mobile, DESKTOP for desktop)

CrUX is the data Google itself uses for search ranking, so a green CrUX panel is the strongest possible signal that real users are having a fast experience.

Chrome (Lab Audit)

The headless Chrome inspector loads the URL in a real Chromium instance and captures everything a browser sees. It powers the largest portion of the detail page across multiple sub-tabs:

• Page Overview - server response table with the full redirect chain (status, URL, DNS, TLS, TTFB, total time per hop), DOM size, depth, iframe count, and resource count
• Performance - lab Core Web Vitals (LCP, FCP, CLS, simulated INP)
• Visual Loading - filmstrip of the page rendering frame by frame, with an LCP overlay screenshot
• Waterfall - request-by-request network timeline
• CWV Diagnostics / Main Thread - long tasks, render-blocking resources, hot scripts, third-party blocking
• Resources - totals by type (JS, CSS, images, fonts), unused JS / CSS, duplicate scripts
• SEO - title, meta description, H1, canonical, viewport, language, image alt coverage, heading hierarchy, structured data, Open Graph, Twitter Card. JS-rendering parity (raw HTML vs after-JS) is also checked here.
• Crawlability - content-type mismatch detection, robots/X-Robots-Tag conflicts, redirect chains
• Security - security-headers grade, mixed content, CSP weaknesses, cookie hygiene
• Console - console errors and uncaught exceptions captured during the load

The Chrome check is the slowest by design (up to ~120 seconds) and runs serially across all workspace runs to keep results consistent.

Uptime

A simple HTTP fetch with detailed timing breakdown:

• HTTP status code
• TTFB and total response time
• Redirect chain length (and http:// → https:// redirect verification)
• Response size and key response headers

The Uptime check feeds the Availability pillar (HTTP status, response time) and the Infrastructure pillar (compression, caching, HTTP version on the main document, response-header size).

SSL

Inspects the certificate served by the host:

• Issuer, subject, common name
• valid_from, valid_to, days remaining
• Key algorithm and bit length
• Signature algorithm
• TLS protocol version negotiated
• Chain completeness

The SSL panel feeds the TLS/SSL sub-pillar of Security. Expired certificates and hostname mismatches are fatal - they trigger a full-page browser warning and apply the cross-pillar penalty.

WHOIS

Domain registration metadata, looked up at run time:

• Registrar
• Created / updated / expires dates
• Nameservers
• Privacy protection flag
• Registrant country (when published)

WHOIS findings are advisory only - domain expiry, recent registration, and privacy protection are surfaced as issues but never deduct from the Inspector Score. They appear in a separate Domain Health section because domain registration is outside the technical control of the page.

robots.txt

Fetches https://{host}/robots.txt and parses it. The panel shows:

• The raw file (with a View robots.txt button that opens a full-screen modal)
• The parsed allow/disallow groups for * and Googlebot
• A clear verdict for the inspected URL - whether it is allowed or blocked, and which directive matched
• AI-crawler coverage (whether all major AI crawlers are allowed or all blocked)

The verdict is the part that matters most. If the URL is blocked for * or Googlebot, the rule is fatal - it's listed in Issues with a critical severity and triggers the cross-pillar score penalty. A missing robots.txt (404) is informational, not an error.

Why Six Checks Together

Any single check tells you part of the story. Together, they let Inspector confirm a problem from multiple angles:

• A slow TTFB shows up in CrUX (real users), Chrome (lab probe), and Uptime (raw HTTP) - three independent confirmations of the same root cause.
• A noindex issue can appear in the raw HTML (Uptime headers / Chrome static parse) and in the post-JS rendered HTML (Chrome SEO sub-tab). When the two disagree, Inspector flags it as JS rendering parity - a fatal SEO finding.
• An SSL problem in the SSL check pairs with mixed-content findings from Chrome to give a complete picture of the page's security posture.

The Issues engine consolidates these signals and prioritizes them so you see the few things that actually need to change first.

Related