A page that cannot be delivered is not indexed. A page that loads slowly usually is. The line between those two facts is where most page speed work stops paying for itself, and knowing which side you are on takes two different kinds of measurement.
Page speed does not decide whether Google indexes a page. Availability does. If the server cannot deliver the page, or delivers it so slowly that the fetch times out, the page never gets read and cannot be indexed. Once the page is delivered and read, speed stops being an indexing question and becomes a ranking and experience question. Market4's own indexing diagnosis lists twelve named causes for a page being crawled and left out of the index, and not one of them is a performance metric.
Speed affects indexing at exactly one boundary: whether the fetch succeeds. A page the server cannot retrieve is a named cause of a page not being indexed, and a request that hangs long enough looks identical to one that failed. That is a server availability problem rather than a front-end performance problem, and it is fixed in different places — origin capacity, database queries, timeouts, cold starts — than the ones a Lighthouse report points at. Compressing images does not help a page that returns a 504.
There is a softer version of the same effect on sites large enough for crawl scheduling to matter. A slow origin means each fetch costs the crawler more, and a crawler working through a large site will get through fewer URLs per visit. On a site of a few hundred pages this is not the reason anything is missing from the index; on a site of hundreds of thousands, the arithmetic changes. The honest position for most sites is that the crawler is not the bottleneck and a page crawled and left out was left out for a reason on that twelve-item list.
A PageSpeed Insights report carries two kinds of number and they are not the same claim. Lab metrics — the performance score, LCP, CLS, TBT, FCP and Speed Index — come from one synthetic run on Google's hardware, along with the ranked list of opportunities. Field metrics — LCP, INP, CLS, FCP and TTFB — come from real Chrome users over the previous 28 days. Lab tells you what one load looked like under controlled conditions. Field tells you what actually happened to people.
The two can legitimately disagree, and lab CLS versus field CLS is the usual case. Lab is a single load at a single viewport with nothing scrolled. Field is every real load, including the ones where somebody scrolled into a late-loading advert and shifted the layout under their own thumb. A lab CLS of zero next to a field CLS that is not zero is not a broken measurement; it is two honest answers to two different questions.
Google's five words say the page was fetched and left out of the index. They say nothing about why. Here is what the string reports, how it differs from "discovered", and the evidence that narrows it to a cause.
Market4 turns one release note into a changelog page, a blog post, a mail-out and a week of social posts — and then tells you which of them brought anyone back.
| Property | Lab metrics | Field metrics |
|---|---|---|
| Where the number comes from | One synthetic run on Google's hardware | Real Chrome users over the last 28 days |
| Metrics reported | Performance score, LCP, CLS, TBT, FCP, Speed Index | LCP, INP, CLS, FCP, TTFB |
| Available for a brand new page | Yes, immediately | No, until enough real traffic accumulates |
| Can be attributed to the whole site instead | No | Yes, when the page itself has too little traffic |
| Useful for a competitor's page | Yes, any public URL can be run | Only if that origin has enough real traffic |
A field number in a PageSpeed report is not always about the URL you asked for, and quoting it as though it is causes real misreadings. The report carries a field_source value with three possible answers. URL means the numbers belong to that page. ORIGIN means the page itself had too little real traffic, so the whole site's numbers were substituted. NONE means there was neither, and the field list is empty. Reporting origin-level numbers as a specific page's performance is a common way to draw the wrong conclusion from an otherwise correct report.
The practical rule is to say which one you are quoting, every time. "This page's LCP is 2.1 seconds for real users" and "the site's LCP is 2.1 seconds for real users, because this page has too little traffic to measure" are different sentences, and only one of them supports a decision about this page. A new post will almost always come back with ORIGIN or NONE, which is another way of saying field data cannot tell you anything about a page published last week.
Market4 splits the work across two tools because one of them writes and the others read. run_pagespeed queues an analysis and hands back a report whose status is QUEUED; the result is not ready on return, because PSI takes roughly 20 to 40 seconds, so the report id has to be polled. get_pagespeed then reads it: section=report for one run by id, section=history for runs newest first, and section=key for whether a PageSpeed key is configured and when it was last saved. The key section reports configuration state only and never the key itself.
Two details are worth copying if you build something similar. The run tool takes no API key as an argument — the app's stored key is used, and when there is none the refusal names the panel page and the Google Cloud console URL that fix it. And the strategy defaults to mobile rather than desktop, because mobile is what Google ranks on; the API's own default is desktop, which would quietly measure the device that matters least in a ranking context. When reading a trend from history, pin the strategy, because mobile and desktop runs use different devices and different throttling and a history that mixes them looks like a regression that never happened.
The fourth item is where speed work and indexing work genuinely overlap, and it is worth separating from the rest. Content that only exists after JavaScript runs is both a rendering cost and an indexing risk, and the fix serves both. Everything else on a Lighthouse opportunities list — image formats, unused CSS, render-blocking scripts — improves what a person experiences without changing whether the page is held in the index. That is the boundary this whole subject turns on, and it is easier to see once you know what the twelve named causes of an unindexed page actually are.
Usually not, unless the page was failing to load at all. Indexing is a selection decision Google makes after it has read the page, and the named causes of a page being left out are things like a canonical pointing elsewhere, an orphaned URL, content missing from the server HTML, thin content and duplication of your own pages. None of those is a speed measurement. If the page loads and Google has read it, speed work is ranking and experience work rather than indexing work.
Field metrics come from real Chrome users over the previous 28 days, so a page nobody has visited yet has nothing to report. The report will either substitute the whole origin's numbers, flagged as origin-sourced, or return an empty field list. Neither is an error. It does mean that for a page published this week, the only speed numbers available are lab numbers from a single synthetic run, and those should be described as such.
Measure mobile for anything ranking-related, because that is the device Google ranks on. The PageSpeed API's own default is desktop, so a tool that does not override it is quietly measuring the less relevant device. Measure both only if you have a genuine desktop-heavy audience and are optimising experience rather than rankings. When comparing runs over time, pin one strategy: mobile and desktop use different device profiles and different throttling, so mixing them produces a fake trend.
Because they measure different things. Lab CLS is one load, one viewport, nothing scrolled, on controlled hardware. Field CLS is every real load your page received, including sessions where someone scrolled past a late-loading advert or an image without dimensions and watched the layout move. A lab score of zero alongside a non-zero field score usually means the shift happens below the fold or after interaction, which a single unscrolled synthetic load will never see.
Yes. PageSpeed Insights works on any public URL, so a competitor's page can be measured the same way your own is. The lab half of the report is available immediately for any URL. The field half depends on whether that origin has enough real Chrome traffic, and it may come back attributed to the whole origin rather than the specific page. Quote it with the same caveat you would apply to your own numbers.
Publishing a post sends two independent announcements. One IndexNow request reaches Bing, Yandex, Seznam, Naver and Yep. Google takes no part in IndexNow, so it is told by re-submitting the sitemap.
The bandwidth you save by blocking an AI crawler shows up in a log. The citations you lose do not show up anywhere, because nothing reports an answer that did not mention you.