Short answer: page speed is a genuine user-experience concern and a documented page-experience input, and that is the entire honest case for it. There is no AI trust signal in site speed, no evidence that fast sites get cited more, and no crawl-budget problem at small scale. Fix speed because people are waiting on your page.
The real signal, and it is a modest one
Here is what is documented. Google publishes a page-experience framework built on Core Web Vitals — how quickly the main content appears, how quickly the page responds to input, and whether the layout jumps while loading. These are user-experience metrics measured against real visitors, and page experience is used as one input among many when deciding what to show. [2]
That is real, and it is worth attention. It is also a much smaller claim than the industry conversation suggests. Page experience does not override relevance, it does not carry a site on its own, and it is specifically about experience rather than a speed score.
So the correct framing is: fast pages are a sign of a well-built site, not a lever on rankings. If you are fixing them for your customers, the returns are real and immediate. If you are fixing them because you believe it will transform your visibility, it will not.
Key takeaway: speed is a quality signal for your customers. It is not a citation strategy.
Three claims worth discarding
“Speed determines your crawl frequency.” Crawl budget is real and documented, and it is entirely relevant to large sites — marketplaces, news archives, anything with millions of URLs where fetching has an actual cost. A small business site has orders of magnitude more budget available than it consumes, so it is not constrained. The concept is being borrowed from a problem almost nobody reading this has.
“A slow page gets crawled quarterly instead of weekly.” Not a documented behaviour. No source describes this, and it is the kind of specific-sounding number that makes a story feel authoritative.
“Fast sites are cited more by AI assistants.” No mechanism, no evidence, no way to test it. An assistant is retrieving and summarising; nothing in that process reads your load time. If a vendor is selling this as a finding, ask for the study.
What Core Vitals actually measure
Three metrics, and knowing which is which saves most of the wasted effort:
- Largest Contentful Paint — when the main content appears. Almost always governed by your largest image, and almost always fixed by resizing and compressing it. If you change one thing, change this.
- Interaction to Next Paint — how quickly the page responds after someone taps. Governed by JavaScript, and the one most often ignored by sites with heavy form libraries.
- Cumulative Layout Shift — whether the page jumps around while loading. Usually caused by images or embeds with no dimensions set.
You do not need to pass on every page. You need to not be obviously slow on the pages people actually visit, and on mobile connections rather than office wifi. Field data from real visitors beats a lab-perfect score on a page nobody opens. web.dev is the reference for the current thresholds. [1] Ahrefs has a practical guide to the fixes. [3]
Visibility of system status and user control over what is happening are among the most durable findings in interface design, and both apply to a page that takes four seconds to respond to a tap. [5] There is one behavioural point that outranks all of it: a slow page breaks the path, and a broken path loses the conversion regardless of what the metrics say. Reducing friction covers where that actually happens, and it is usually a form.
Where automation genuinely earns its place
Automation does not make you citable. What it does is stop things drifting, and drift is a real problem — particularly in structured data.
Hand-maintained markup rots silently. Somebody updates the phone number in the header, the footer keeps the old one, and the JSON-LD block in the template carries last year’s address. You now have a machine-readable statement about your business that is wrong, and nothing tells you. Structured data is described in detail in the schema guide, and the important structural point is that it should be generated from the same record the visible page renders from. [4]
That is the whole argument for automation here, and it is a good one. It also generalises beyond schema: your hours, your coverage area and your response time drift in exactly the same way, and the same fix applies.
| Signal | Real? | Worth acting on |
|---|---|---|
| Page experience as a search input | Yes, documented | If a specific page is slow |
| Largest image delaying load | Yes, measurable | Start here |
| Structured data drifting out of sync | Yes, common | Automate from one record |
| Speed determining crawl frequency | No, for sites under ~100k pages | Ignore |
| Slow page crawled quarterly | No source | Ignore |
| Fast site cited more by assistants | No evidence | Ignore |
| Interaction latency on form-heavy pages | Yes, measurable | Often the real problem |
What to do first
- Check Core Web Vitals on two or three pages real visitors actually use, on mobile.
- Find the largest image on your slowest page and resize it. That is usually most of the problem.
- If you have a form with a heavy library, measure how long it takes to respond to a tap.
- Move your structured data to be generated from the same source as your page content.
- Stop treating speed as an AI strategy. It is an engineering task with a customer-facing payoff.
How this connects
- Work smarter covers which tasks are worth automating.
- Automated entities covers generating markup from one record.
- Reducing friction covers what a slow page costs you.
- Modern search covers where page experience fits in the wider picture.
