# 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:
| State | Meaning |
| ----------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Success** | The collector returned data |
| **No data** | The collector explicitly says no data exists (e.g. CrUX has no traffic for this URL, robots.txt is missing). Treated as a successful outcome - no error |
| **Failed** | The collector could not return data. Transport-level failures (collector unreachable) are retried once; a definitive error response (HTTP 4xx/5xx) fails on the first attempt |
A failed check shows its error message in its panel. The other five checks still complete and contribute to the score.
## CrUX (Field Data) [#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 getting a fast experience.
Low-traffic URLs may have **no data** in CrUX. Inspector flags this as an informational issue (no score deduction). The moment the URL crosses Google's traffic threshold, future runs will fill it in.
## Chrome (Lab Audit) [#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 errors and uncaught exceptions are also captured during the load; they surface as findings in the Issues panel rather than in a dedicated sub-tab.
The Chrome check is the slowest by design (up to \~3 minutes) and runs serially across all workspace runs to keep results consistent.
## Uptime [#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 [#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 [#whois]
Domain registration metadata, looked up at run time:
* Registrar
* Expiry date and days remaining
* TLD
* Root domain
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 page's technical control.
WHOIS data is not available for every TLD. ccTLDs in particular often return **no data**. This is an informational result, not a failure.
## robots.txt [#robotstxt]
Fetches `https://{host}/robots.txt` and parses it. The panel shows:
* The raw file (shown inline in a collapsible **robots.txt file** section)
* 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 [#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 [#related]
How findings from the six checks become a prioritized fix list.
How issues add up to a single 0–100 grade.