A case study on 36,943 URLs and what they reveal about AI visibility.
For years, site speed was treated as a secondary priority in SEO strategy — a confirmed ranking factor, but rarely the primary focus compared to content and keyword strategy. That is changing.
AI-powered systems now answer roughly 9 out of 10 informational queries directly — no click-through, no scrolling past ten search results, just a generated answer that either cites a page as a source or doesn’t. This represents a significant shift in how online visibility actually works.
To understand whether page speed affects AI citation the same way it affects search rankings, this study analyzed 36,943 cited URLs (with data support from originality.ai) alongside a nearly matching set of organic search URLs. The goal was to answer one question:
Does page speed actually affect whether AI engines cite a page’s content?
Here’s what the data showed.
First, a look at who’s actually crawling sites now
Before getting into the results, it’s worth understanding how much the crawler landscape has shifted. Cloudflare’s data shows that OpenAI’s GPTBot now accounts for 7.7% of all crawler traffic, more than triple where it was a year ago, with request volume up 305%.
Here’s the fuller picture of how things moved between 2024 and 2025:
| Bot name | Share in 2024 | Share in 2025 | Change | Request growth (2024→2025) |
|---|---|---|---|---|
| Googlebot | 30% | 50% | +20% | 96% |
| GPTBot | 2.2% | 7.7% | +5.5% | 305% |
| ChatGPT-User | 0.1% | 1.3% | +1.2% | 2,825% |
| PerplexityBot | <0.01% | 0.2% | +0.2% | 157,490% |
| ClaudeBot | 11.7% | 5.4% | -6.3% | -46% |
The PerplexityBot figure stands out in particular — 157,490% growth in request volume in a single year. Googlebot still holds the largest share at 50%, but AI crawlers are claiming a growing portion of that traffic, and the trend is clearly upward.
The volume behind this is substantial. Vercel reports 569 million requests from ChatGPT crawlers per month across their network alone, with some sites seeing over 150 requests per second — a significant load for any shared hosting environment to handle without degradation.
This is the premise behind the study: if LLM crawlers behave anything like traditional search crawlers when it comes to speed, then a slow site isn’t just losing rankings — it’s losing citations. It becomes effectively invisible in the exact place a growing share of searches now happen.
The two metrics that actually matter
Page load time is made up of many moving parts — DNS resolution, server response, asset loading, render-blocking scripts, third-party scripts, the user’s device and connection, and more. Rather than accounting for all of them individually, this study narrowed the focus to the two metrics that matter most for how an LLM crawler actually experiences a page.
#1. Time to First Byte (TTFB)
This is the gateway. It’s the moment access to a page actually begins — the time between when a request is made and when the first byte of the response comes back.
The earlier that first byte arrives, the sooner a crawler can start parsing the page, rendering dynamic content, and extracting the information it needs. This is functionally identical to what Googlebot reports back in Google Search Console:
This tracks logically from the crawler’s side. An LLM crawler operating under a defined crawl budget is likely to treat a fast TTFB as an early signal that a page is worth deeper processing. A slow first byte risks the page being deprioritized before the crawler ever reaches its actual content.
#2. DOM Readiness
This is the second half of the equation — how quickly the main content becomes accessible after that first byte lands. Ideally, content should be present in the initial HTML, for an important reason:
Vercel’s own research found that ChatGPT and Claude crawlers fetch JavaScript files — ChatGPT for 11.50% of requests and Claude for 23.84% — but they don’t execute any of it. They cannot read client-side rendered content. If key information only appears after a JavaScript framework renders it in the browser, an AI crawler may never see it at all.
Google’s Gemini is the exception — because Gemini runs on Google’s infrastructure, it inherits the same JavaScript rendering capabilities as Googlebot, so it can process modern web apps fully, unlike standalone ChatGPT/Claude crawlers.
Again, this is about crawling/indexing, not live browsing. The finding is specifically about the bots that fetch pages to build training or retrieval data (GPTBot, ClaudeBot, etc.), not about what happens if a user asks Claude or ChatGPT to browse a specific page live in a session — that’s a different code path with different capabilities.
This has real implications for modern WordPress builds that lean on heavy client-side rendering, page builders with layered scripts, or lazy-loaded content that never renders before the crawler moves on.
Study methodology
To keep the methodology rigorous, the test setup used two AWS servers running the web-vitals JavaScript library, testing the URL set with different user agents. The crawl took close to two days to complete and compile. Here’s a look at the raw data structure:
The core comparison came down to 18,385 URLs cited by various LLMs against the same number of URLs pulled from organic search results, measuring TTFB consistency across both sources.
The results
Finding #1: The vast majority of AI-cited pages are fast
80.91% of URLs cited by LLMs — 14,875 of the total pages tested — load with a TTFB under 500ms, which lands squarely in Google’s “good” range for Core Web Vitals.
That line drops sharply after the 500ms mark, pointing to a strong correlation between low server response times and visibility in AI-driven indexing. It suggests LLM-based crawlers and AI systems are prioritizing content that gets delivered with minimal latency.
The pages that fell into the slower 1s–1.5s range were largely pages with heavy dynamic content, PDFs, dense research papers, or ones that returned 404/500 errors during testing — the kind of technical friction that tends to work against both users and crawlers.
Finding #2: Organic search results are only slightly faster
The same TTFB test was run against organic search URLs to check for a meaningful gap between “gets ranked” and “gets cited by AI.”
85.98% of organic search pages had a TTFB under 500ms, compared to 80.91% for LLM-cited pages — a gap of roughly 5%. That’s a modest edge for traditional search, which makes sense given that speed has been part of Google’s ranking algorithm for years.
But the two lines track closely across the entire chart, which points to the more important finding: the speed discipline it takes to rank well organically is largely the same discipline it takes to get cited by AI. These are no longer separate concerns.
Outside research supports this.
In a study titled “Does Speed Impact Ranking?“, Neil Patel found that among various page load metrics, TTFB showed the strongest correlation with search rankings:
First byte time sits well above every other metric on that chart — the same pattern showing up in an entirely separate dataset.
Finding #3: Fast TTFB tends to carry the rest of a page’s metrics along with it
The next question was whether pages with a good TTFB (under 500ms) also reached DOM readiness quickly — since a fast first byte doesn’t automatically mean a fast, usable page.
After collecting TTFB data, it was straightforward to filter out pages with an average TTFB of under 500ms. We had to calculate the DOM readiness time for those pages — and the results were in line with our expectations:
The majority of both LLM-cited and organic pages with good TTFB also reached DOM readiness within 1 second (63–68%), tapering off from there. The takeaway is straightforward: speed compounds.
A fast server response tends to predict a fast, fully-usable page overall — and that combination is what both crawlers and human readers reward.
The benchmark to aim for
The recommended benchmark aligns with Core Web Vitals and what this dataset showed across the board:
- Good = under 800ms.
- Needs improvement = 800–1800ms.
- Poor = anything over 1800ms.
For sites specifically pursuing AI citations, the data suggests aiming tighter than that — under 500ms is where the real separation happens.
What this means for business
These numbers matter because of what they imply for visibility going forward.
If a site is slow, it isn’t just losing a few ranking positions. It risks becoming invisible at the exact moment a customer asks an AI system for a recommendation — and getting no credit for the content behind it, because the crawler never got a fast, clean look at it.
That has real business implications:
- Lost citations mean lost brand visibility. If ChatGPT, Claude, or Perplexity can’t reliably access and render content fast enough, they’ll cite a faster competitor instead — even when the slower page has better content.
- Lost crawl budget means incomplete indexing. Sites under heavy AI crawler load (some see 150+ requests per second) that can’t keep up risk missing the crawl window on key pages entirely.
- Slow WordPress sites are especially exposed. Between page builders, plugin bloat, unoptimized images, and third-party scripts, WordPress is one of the platforms most prone to landing in the “needs improvement” or “poor” TTFB zone, at a time when speed matters more than it has in years.
The upside is that speed is one of the few SEO and AI-visibility levers that’s largely within a site owner’s control. Backlinks and authority build slowly and unpredictably. TTFB, DOM readiness, and Core Web Vitals can be fixed directly, often with measurable improvement within days rather than months.
For any serious WordPress site — a business site, an ecommerce store, a content brand trying to stay visible as search shifts toward AI — page speed has become a must-have trait, not an optional optimization.
Turning this into action
This study reflects the exact problem Speedy.Site was built to solve:
WordPress sites with solid content and design held back by a slow TTFB, with no clear visibility into why, or whether fixes were actually working.
Here’s how the platform is built to address what the data surfaced:
1. WordPress-specific performance optimization. Speed problems on WordPress typically come from a predictable set of causes — bloated themes, unoptimized images, render-blocking plugins, poor caching, and slow hosting configurations. Speedy.Site is built to target these WordPress-specific issues directly, rather than offering generic caching advice.
2. Real User Monitoring (RUM), not just lab tests. Lab tests (like Lighthouse or PageSpeed Insights) capture a snapshot from a single artificial test run. RUM shows how a site is actually performing for real visitors, on real devices, over real connections — the same kind of data that shaped the TTFB and DOM readiness findings in this study. Average TTFB across real traffic is what a crawler experiences over time, not a single best-case test result.
3. A full year of Web Vitals and performance monitoring. Speed isn’t a one-time fix — it’s a moving target. New plugins get installed, themes get updated, content gets added, and performance can degrade over time without anyone noticing. Every Speedy.Site customer gets a full 12 months of ongoing Core Web Vitals and performance tracking, providing visibility well past the initial optimization.
4. A clear line back to the benchmarks that matter. Instead of vague scores, the goal is aligned with what this study found: keep TTFB under 500ms, keep DOM readiness tight, and keep Core Web Vitals green — consistently, not just on launch day.
The bottom line
Speed used to be something optimized for human visitors, with the assumption that Google would notice too. Now it’s something to optimize for human visitors, for Googlebot, and for an entire new layer of AI crawlers deciding in real time whether a page is worth citing.
The data is clear on this point: 80.91% of AI-cited pages are fast, first-byte-quick, and structurally clean. A site outside that range isn’t necessarily being penalized for weak content — it may simply be losing the race before a crawler gets a chance to read it.
Well-structured content and real authority still matter, and they always will. But the technical foundation underneath — whether AI systems and search engines can access content quickly and reliably — has become a baseline requirement rather than a differentiator.
Fix TTFB. Watch DOM readiness. Monitor performance continuously rather than once. That’s the core of it, and it’s one of the few levers in modern SEO that’s entirely within a site owner’s control.
For a closer look at where a WordPress site currently stands, Speedy.Site includes RUM-based Web Vitals monitoring for a full year, making it possible to track these numbers over time rather than guess.
