How does my site get included in the Chrome User Experience Report without signing up?

What is the Chrome User Experience Report and why is it strategic?

The Chrome User Experience Report (CrUX) is a public dataset driven by real browsing data from Chrome users who opted into syncing and sending statistics. It aggregates Core Web Vitals (LCP, INP, CLS) and other user experience metrics across millions of sites. This is the official source Google uses to assess browsing experience in its search engine.

For an SEO practitioner, CrUX is the absolute benchmark: the data it contains is what Google uses for ranking in search results. If your site isn't included in CrUX, you have no visibility into the real metrics Google sees. And importantly, you can't compare your performance to that of your competitors in the user experience arena.

Why doesn't my site appear in CrUX?

Inclusion is based on a minimum traffic threshold from eligible Chrome users (those who have enabled usage statistics). Google does not share the exact threshold, but field observations indicate that a site with less than a few thousand monthly visitors is unlikely to be included. Niche sites, new domains, or individual low-traffic pages often remain invisible.

CrUX aggregates data at the origin (domain) level and, sometimes, at the URL level for the most popular pages. If your site is young, confidential, or in the process of migration, it might not reach the threshold. [To be verified]: Google does not publish precise documentation on the necessary volume, making planning for growing sites challenging.

How can I check if my site is included in CrUX?

Three simple methods allow you to check for your domain's presence in the dataset. First: use PageSpeed Insights by entering your URL. If CrUX has data for your origin, it will appear in a dedicated tab labeled "Field Data." Otherwise, only lab analysis (simulated data) will be available.

The second: directly query the CrUX API through a tool like BigQuery or third-party tools (CrUX API, CrUX Dashboard). The third: check the Core Web Vitals report in Google Search Console, which relies on CrUX. If no data appears in these three interfaces, your site is likely not included in the public dataset.

• Inclusion in CrUX is automatic and based on a sample of Chrome traffic — no manual effort can force a site’s addition.
• An undocumented minimum traffic threshold determines eligibility. Low-traffic sites do not appear in the dataset.
• CrUX data is what Google uses for ranking — lack of CrUX data = lack of visibility on the official metrics leveraged by the engine.
• Self-collecting data via JavaScript web-vitals is the only alternative for non-included sites or to achieve finer granularity (by page, by user segment).
• CrUX aggregates at the origin (domain) level and sometimes at the URL level for high-traffic pages. Niche pages often remain invisible even if the domain is included.

Is this statement consistent with observed practices in the field?

Yes, it is fully consistent. The automatic nature of CrUX inclusion is an established and observable fact: thousands of sites appear in the dataset without any voluntary action from their owners. No sign-up, no forms, no manual validation — everything relies on the volume of eligible Chrome traffic. It’s a model of passive collection that favors high-audience players.

However, the lack of transparency regarding the exact traffic threshold remains a pain point for practitioners. It has been observed that sites with 5,000 monthly visits can be absent, while others with 10,000 visits appear. The traffic composition (Chrome share, share of users with sync enabled) likely plays as significant a role as the raw volume. [To be verified]: Google has never published an official figure, which forces growth sites to work in the dark.

What nuances should be added to this statement?

The first nuance concerns the granularity of the data. CrUX aggregates at the origin (domain) level, which obscures variations between pages. An ultra-high-performing homepage can mask disastrous conversion pages — and vice versa. URL-level data exists in CrUX, but only for pages with significant individual traffic. For an SEO managing optimization by template or category, this is insufficient.

The second: CrUX only captures Chrome users who opted into sending statistics. This excludes Firefox, Safari, Edge (non-recent Chromium), and privacy-first Chrome users. The sample is large but not universal. If your audience is mostly Safari (premium iOS market, for example), CrUX may under-represent your real-world situation.

In what cases does this rule not apply or has limitations?

CrUX does not cover very low-traffic sites, intranets, sites under development or in closed beta. It also does not capture badly instrumented single-page applications (SPAs) where client-side transitions do not generate new exploitable CrUX measures. Sites behind strict authentication (B2B portals, members-only) may see their public traffic below the inclusion threshold.

Another limitation: the latency of CrUX data publication. Metrics are aggregated over a 28-day rolling window and published with a delay. If you fix a performance bug today, it will take several weeks for the improvement to appear in CrUX. For real-time monitoring, self-collection via JavaScript web-vitals remains essential.

What should I do if my site is not in CrUX?

The first step is to implement your own Core Web Vitals collection using the web-vitals JavaScript library (available on npm). This library measures LCP, INP, CLS, FCP, TTFB on the client side and allows you to send metrics to your Analytics tool (Google Analytics 4, Matomo, etc.) or to a custom endpoint. You will thus retrieve granular data by page, device, and user segment — far beyond what the public CrUX offers.

The second: cross-reference this data with that from Search Console (Core Web Vitals report) to check for consistency. If Search Console reports CWV data but the public CrUX is empty, it indicates that Google is utilizing unpublished internal data. If neither reveals any data, your site is likely below the eligible traffic threshold — or your JavaScript instrumentation is faulty.

What mistakes should be avoided in interpreting CrUX data?

Never assume that the absence of your site in CrUX means Google isn't measuring your Core Web Vitals. Google may collect data via Search Console or other internal channels without publishing it in the CrUX dataset. The lack of public visibility does not equate to a lack of consideration in ranking.

Another common mistake: relying solely on origin-level CrUX data to optimize specific pages. Domain averages mask internal variations. A disastrous product page may be invisible in origin-level CrUX if the rest of the site compensates. Instrument your critical pages individually to drive optimization at the proper granularity level.

How can I check if my site adheres to Google's Core Web Vitals recommendations?

Use PageSpeed Insights in "Field Data" mode (if available) to obtain CrUX metrics. Compare them against the official thresholds: LCP < 2.5s, INP < 200ms, CLS < 0.1 for at least 75% of visits. If field data is missing, switch to lab data (Lighthouse) while keeping in mind that it only reflects a simulated scenario, not the actual user experience.

Supplement with RUM (Real User Monitoring) collection via web-vitals.js to obtain continuous and segmented metrics. Cross-reference with Search Console to detect discrepancies between your instrumentation and the data Google sees. If discrepancies are significant, check your collection code and eligibility of your users (Chrome share, proportion of authenticated traffic, etc.).

• Check your site's presence in CrUX via PageSpeed Insights, the CrUX API, or Search Console (Core Web Vitals report).
• Implement the web-vitals JavaScript library to collect LCP, INP, CLS in real-time and send the data to Analytics.
• Individually instrument critical pages (conversion pages, SEO landing pages) to obtain URL-level granularity.
• Cross-reference the self-collected data with that from Search Console to detect inconsistencies or blind spots.
• Avoid relying solely on origin-level CrUX data to optimize specific pages — prioritize granular RUM collection.
• Monitor CrUX publication latency (28-day rolling) and do not expect real-time responsiveness from this dataset.