Because Core Web Vitals and page experience are, by Google’s own repeated description, one signal among many, and a comparatively minor one relative to content relevance and quality. A brand-new page with no CrUX data yet isn’t penalized by default for lacking that data; Google simply has less or no page-experience signal to apply to it, while relevance and quality signals, which carry far more ranking weight, can easily outweigh whatever page-experience differential exists between the new page and an established competitor.
Why zero CrUX data doesn’t block a new page from ranking
CrUX field data requires a meaningful volume of real Chrome traffic to a URL or origin before Google can generate a stable measurement; that’s inherent to how the Chrome UX Report works; it’s a rolling aggregate of real user experiences, and a page needs enough of them to produce a statistically usable result. A newly launched page, by definition, hasn’t accumulated that traffic yet, so there’s no field-based page-experience signal available for it at all in the near term.
Google has been consistent in its public documentation and statements that page experience signals, including Core Web Vitals, are intended to be a tie-breaker-style input among a much larger set of relevance and quality signals, not a dominant ranking factor. Google’s own page experience documentation frames it as “one of many signals” used to evaluate the overall experience, explicitly not something that overrides content relevance. This means a page without any measurable page-experience signal isn’t automatically down-ranked into a penalty state; it’s more that Google’s ranking system has less of that particular input to weigh, and continues weighing everything else (topical relevance, content quality and depth, structured understanding of the page, links, and other established signals) as normal.
In practice this means a new page can rank well against an established competitor with a good CWV score if the new page has stronger relevance and content quality for the query, since that’s the dominant input regardless of whether page-experience data exists yet. It also means the absence of CrUX data isn’t equivalent to “failing” Core Web Vitals; those are different states. Google can and does use other proxies (such as lab-style data or a default assumption) in the absence of field data for a specific URL, since Google’s page-experience evaluation doesn’t require every single URL to independently pass, particularly for new or lower-traffic pages.
There’s also a structural reason new pages on established origins specifically tend to fare even better than the “brand new site” case suggests. Because CrUX can report at the origin level as well as the URL level, a new page published under an origin that already has a healthy, high-traffic Core Web Vitals history can effectively inherit a reasonable page-experience assumption by association, at least until it accumulates enough of its own URL-level traffic to be measured independently. A new page on a domain with no prior traffic or history at all has no such fallback, which is one reason the same “zero CrUX data” condition can produce different practical outcomes depending on whether it’s a new page on an established site or a page on a brand-new domain.
It’s also worth being precise about what “ranks well” is actually measuring in this scenario. Ranking is query-dependent and relative to whatever else is competing for that specific query at that specific moment; a new page outranking one established competitor on one query says nothing about whether it would outrank a different, stronger competitor on a more contested query. Treating a single favorable ranking outcome as proof that page experience “doesn’t matter” is itself a misdiagnosis; it more precisely shows that page experience wasn’t the deciding factor in that particular competitive comparison, which is a narrower and more accurate claim.
How to handle a new page before CrUX data accumulates
Don’t treat a new page’s lack of CrUX data as a ranking emergency or a reason to over-invest in page-experience polish before the content itself is strong. Prioritize relevance and quality first, since those are documented to carry substantially more ranking weight, and page experience only meaningfully differentiates between pages that are otherwise close in relevance and quality.
Do still build the page on a technically sound foundation from day one (fast server response, sensible resource loading, no egregious layout shift or interaction blocking), since once traffic accumulates and CrUX data starts populating, you want that measurement to reflect a page that was already built well, rather than scrambling to fix it after data appears and reveals a problem.
Use lab tools (PageSpeed Insights, Lighthouse, WebPageTest) as your only available performance signal during the pre-CrUX window, and treat a clean lab result as reasonable, if incomplete, evidence the page is not shipping an obvious problem. This isn’t a substitute for field data, but it’s the best available proxy before real-user traffic volume exists, and it lets you catch and fix an egregious regression (a render-blocking script, an unoptimized hero image, an unstable layout) before it has the chance to accumulate into a bad field measurement once traffic arrives.
Once the page does start accumulating enough traffic for URL-level CrUX data (check via Search Console’s Core Web Vitals report or the CrUX API/BigQuery export), revisit it specifically rather than assuming the pre-launch lab check was sufficient forever. Real usage patterns, referral sources, and device mixes for the live page can differ from whatever was assumed or tested pre-launch, so the first real field data on a new page is worth a deliberate review rather than being ignored just because the page already “ranks well” for now.
If you’re benchmarking a new page against an established competitor for the same query, look at the full picture, not just Core Web Vitals: content depth and relevance, internal/external signals, and technical fundamentals, since page-experience parity or superiority alone won’t overcome a real relevance or quality gap, and conversely, a real relevance and quality advantage can outrank a page-experience disadvantage, which is exactly the pattern this question describes.
A worked example of the pattern
Consider a hypothetical Site X that publishes a new guide page the same week a competitor, Site Y, has an equivalent page with two years of accumulated traffic and a “good” CrUX rating across all three Core Web Vitals. Site X’s new page has zero CrUX data, since it hasn’t yet crossed the traffic threshold needed for a stable field measurement, but it’s noticeably more thorough, covers the query’s actual intent more precisely, and is published on a domain with strong topical history in the subject. Suppose it outranks Site Y’s established, CWV-passing page within the first few weeks. That outcome doesn’t mean Core Web Vitals stopped mattering; it means Site X’s relevance and content-quality advantage was large enough to outweigh Site Y’s page-experience edge, which is a comparatively minor signal by Google’s own description. If Site X’s page had instead been thin and generic while Site Y’s was equally thorough, the missing CrUX data wouldn’t have rescued it, since page experience only tips a close relevance contest, it doesn’t override a real one.
