Google has not announced its new CrUX ad metrics as direct SEO ranking factors. They are experimental measurements of the ads real Chrome users encounter, and they are separate from Core Web Vitals. Google added them to its page-experience resources in September 2026, which makes them useful for investigating ad-heavy pages, not a new score to optimize for rankings. Chrome's announcement and Google's Search guidance make that distinction clear.
If your site runs display ads, the data can help you ask better questions: How much of the visible page do ads occupy? How much network transfer and CPU time are associated with them? This guide explains the four measurements, where to find them, why a report may be empty, and how to pair them with a controlled performance investigation. It does not assume that a high ad number caused a ranking drop.
Are CrUX ad metrics a Google ranking factor?
There is no published basis for treating Ad Count, Ad Density, or either Ad Weight metric as a direct ranking factor. Google's page-experience documentation now lists them as a resource for understanding visitors' ad experience. In the same document, Google says its ranking systems use Core Web Vitals, while other page-experience aspects do not directly make a page rank higher. A resource appearing on that page is not an announcement that its numbers have become ranking inputs.
Chrome is also explicit about the distinction: the ad metrics share CrUX's data pipeline with Web Vitals, but they are not Core Web Vitals. They have no official “good,” “needs improvement,” or “poor” ranges and no suggested target. A dashboard that paints 20% Ad Density green and 30% red would be applying its own rule, not Google's.
That does not make advertising experience irrelevant to SEO work. Google asks site owners whether excessive ads distract from or interfere with the main content. Heavy or late-loading ads can also be worth investigating when an important page has weak performance or a difficult reading experience. The new numbers give a publisher a way to quantify parts of that experience; they do not prove why a page ranks where it does. If you need the definitions and established thresholds for LCP, INP, and CLS, use Screpy's separate Core Web Vitals guide.
What do the four CrUX ad metrics measure?
The metrics describe different parts of an ad experience. Treat them as four observations, not ingredients in a combined SEO score. Chrome reports eligible field data over a rolling 28-day window and shows each metric at the 75th percentile, or p75. A p75 Ad Density of 25% means 75% of included visits had a session-level density of 25% or less; it does not mean ads covered exactly one-quarter of every page view. The Chrome methodology explains the sampling and percentile rules.
| Metric | What it reports | What it does not tell you |
|---|---|---|
| Ad Count | The average number of visible ads in the viewport during a visit, shown as a decimal count. | The number of ad slots in the page's HTML. |
| Ad Density | The average share of the visible viewport occupied by ads during a visit, expressed as a percentage. | Whether a particular ad is intrusive or whether content is high quality. |
| Ad Weight: CPU | Cumulative JavaScript execution time attributed to ad frames, in milliseconds. | Every ad-related script's CPU cost. Chrome excludes ad scripts running in the main frame. |
| Ad Weight: Network | Cumulative compressed transfer associated with ad resources, in kilobytes. | A page-load time, LCP value, or proof that ads slowed a specific visit. |
Ad Count and Ad Density are sampled from the visible viewport once per second as someone scrolls or reads. A sticky unit can therefore remain in many samples, whereas an ad near the top disappears from samples after the visitor scrolls away. CPU and network weight accumulate across the page visit rather than measuring how much of the screen is occupied. Chrome's CPU definition is particularly important when interpreting a low CPU number: main-frame ad scripts are outside that metric.
For an illustrative example, imagine two article templates each average one visible ad. One uses a small unit beside the content; the other uses a large sticky unit. Their Ad Count may be similar while their Ad Density differs. Now imagine the smaller unit loads a heavy creative. Its network weight could be higher despite occupying less screen space. These are possible patterns, not results measured on Screpy or any particular publisher. The point is to investigate the metric that changed instead of treating “more ads” as a complete diagnosis.
How do you check CrUX ad metrics?
Start with CrUX Vis, Chrome's public dashboard. It needs no site ownership verification. Enter the origin of an ad-funded site, choose the device class you want to examine, and open the Ad Metrics view. Record the reporting period, device, and all four p75 values together. Then switch between origin-level and URL-level views if the specific page has enough eligible data. Do not compare a mobile origin value with a desktop URL value as if they described the same population. Chrome's tooling guide says CrUX Vis shows historical rolling 28-day periods and refreshes weekly.
For repeatable reporting across a portfolio, the CrUX API exposes the latest snapshot and the History API exposes a time series. The documented metric keys are experimental_ad_count, experimental_ad_density, experimental_ad_cpu, and experimental_ad_kilobytes. Query an origin for a site-wide baseline or a url when page-level data is available. Both APIs require a key; the current snapshot updates daily, while history is released weekly. Keep the API's collectionPeriod with the values so a later comparison uses the correct dates. These experimental fields are not yet in the CrUX BigQuery dataset according to Chrome's current documentation.
To investigate one page immediately, inspect it in Chrome's DevTools Ad panel under controlled conditions. That is a local test, not the same observation as thousands of real-user visits in CrUX. It can help reveal a particular ad load or script behavior before the rolling field window catches up. Screpy's Core Web Vitals monitoring can help track important URLs' separate performance checks; Chrome's tools remain the source of the new CrUX ad metrics. Keep those two datasets labeled separately in any report.
Why are CrUX ad metrics missing?
An empty report does not mean the site has no ads, that its ads are lightweight, or that Google has judged its page experience. First check the exact origin and URL you entered. Data for www.example.com and another hostname should not be assumed interchangeable, and a page may lack a URL-level record even when its origin has one.
Next check eligibility. Chrome says its aggregated ad reporting currently includes only origins with at least one real authorized seller listed in ads.txt; a missing file or placeholder-only file does not qualify. General CrUX participation criteria still apply, so a low-traffic URL may have no page-level data. Chrome also warned at launch that availability would increase as the new metrics rolled out. None of these conditions supports treating a blank value as zero.
If the site legitimately sells advertising, verify its ads.txt with the ad-operations owner rather than adding an arbitrary seller merely to populate a report. If the site does not use that kind of advertising, a missing aggregate ad record may be expected. You can still inspect a page locally: Chrome applies the ads.txt filter when aggregating CrUX, while its DevTools Ad panel attempts local measurements without that filter. Record the Chrome version, URL, device setting, consent state, and test date; a local run is diagnostic evidence, not a substitute field percentile.
How should SEO teams use the data?
Use the new metrics to choose an investigation, not to assign an SEO grade. Start with an important ad-supported template, such as an article or gallery page that readers actually visit. Save its mobile and desktop CrUX values separately, along with the reporting period. Compare each value with the same origin or URL over time; if you change a layout today, a rolling 28-day field window will not isolate that change tomorrow.
| What you notice | Useful next question | Independent check |
|---|---|---|
| Ad Density rises while Ad Count stays similar | Did a slot grow, become sticky, or remain visible longer? | Inspect the template at several scroll positions on a phone-sized viewport. |
| Ad Count rises but Density does not | Did more small units appear without taking much more screen area? | Compare slot placement and visible ad frames before and after the change. |
| CPU weight rises | Did ad-frame execution change? | Record a controlled Chrome trace and inspect ad frames. Remember that Chrome's CPU metric excludes main-frame ad scripts. |
| Network weight rises | Did creatives or ad resources become heavier? | Inspect ad-related transfer in DevTools, including repeated loads during a longer visit. |
| A Core Web Vital worsens at the same time | Are ads actually responsible, or did another page change occur? | Compare controlled traces, deployment history, and the affected CWV. Treat the shared trend as a hypothesis. |
For example, suppose the illustrative mobile trend shows stable Ad Count but rising Ad Density after a new sticky placement. A sensible next step is to inspect that placement on the relevant template, then test a smaller or non-sticky variant. Keep consent state, device, network conditions, and ad demand as comparable as possible. Measure user experience and business outcomes as well as ad metrics. If both density and a Core Web Vital later improve, that is useful evidence, but the field correlation alone still does not prove a ranking effect.
Do not assume a low CPU number means the entire ad stack is cheap: Chrome excludes main-frame ad scripts from that metric. Do not assume a URL value represents one clean page view on a client-routed single-page application, either; Chrome says soft navigation does not yet reset the ad-metric collection window. Infinite scrolling and time spent paused on a page can also change viewport averages. Those limits make local reproduction especially important before changing inventory or templates.
For an SEO team, the practical outcome is a better conversation with engineering and ad operations. Bring the specific metric, the URL or origin, the device, the date window, and a reproducible page behavior. Keep any Screpy performance check or Search Console trend beside that evidence, clearly labeled as a different measurement. Fix a verified experience problem because it helps readers; do not promise that reducing Ad Density alone will move rankings. Google currently presents the new CrUX figures as diagnostic page-experience resources, not a new ranking threshold.