CGO Media Statistics Library UPDATED 29th September 2026
Technical SEO remains the infrastructure on which search visibility is built. A website may publish authoritative content, attract strong external references and establish considerable brand recognition, but search engines and AI-mediated discovery systems still need to be able to access, render, interpret and retrieve that information reliably.
The technical search environment has also become more complex. Traditional concerns including crawling, indexing, canonicalisation, redirects, internal linking, mobile rendering, page speed and structured data now sit alongside JavaScript execution, real-user performance measurement, machine-readable entities and the accessibility of information to AI-powered retrieval systems.
This CGO Media research report brings together 100 quantitative technical SEO statistics to examine the condition of the modern web and the technical factors influencing organic search performance in 2026.
UK evidence is prioritised where reliable country-specific data exists. Large-scale international datasets are used where technical web-performance measurements are inherently global, with their geographic scope identified rather than presented as UK-specific evidence.
Executive Summary
Technical SEO in 2026 is no longer simply a checklist of XML sitemaps, robots.txt directives and broken links. It increasingly concerns whether digital information can be discovered, processed and understood efficiently across a broader machine-mediated discovery environment.
One of the clearest indicators is real-world website performance. Google’s Chrome User Experience Report measures millions of web origins using field data from real Chrome users. The data shows substantial improvement across parts of the web, but also demonstrates that technical performance remains far from universal.
55.7%
of measured origins passed Core Web Vitals overall in July 2026
68.3%
of measured origins achieved good Largest Contentful Paint
85.7%
of measured origins achieved good Interaction to Next Paint
81.6%
of measured origins achieved good Cumulative Layout Shift
The distinction between individual metrics and overall Core Web Vitals performance is important. A site must perform sufficiently across the complete group of applicable Core Web Vitals rather than simply achieving a strong result for one isolated measure.
This creates a useful model for technical SEO more broadly. Search visibility depends on interconnected technical systems. Crawlability without reliable indexing is insufficient. Fast loading without stable rendering is incomplete. Structured data cannot compensate for inaccessible content. And technically accessible pages still require clear architecture, canonical signals and authoritative information.
Key Findings
1. Technical Performance Is Improving — But a Large Part of the Web Still Falls Short
Current real-user performance data indicates that only a little over half of measured origins achieve good Core Web Vitals overall. This means technical performance remains a meaningful differentiator rather than a universally solved problem.
2. Loading Performance Remains a Major Constraint
Largest Contentful Paint continues to show a materially lower good-performance rate than Interaction to Next Paint. For technically complex websites, reducing the time required to render primary page content therefore remains an important optimisation challenge.
3. Mobile Technical Performance Cannot Be Treated as Secondary
Technical performance must be assessed under real mobile conditions rather than assumed from desktop tests. Network conditions, processing capability, JavaScript execution and responsive layouts can produce substantially different experiences across device categories.
4. Technical SEO Extends Beyond Core Web Vitals
Core Web Vitals provide valuable performance measurements, but they represent only one part of technical search optimisation. Crawl controls, indexing directives, canonicalisation, status codes, redirects, site architecture, internal links, rendering and structured data remain central to search-engine accessibility.
5. Technical Accessibility Now Matters Beyond Traditional Search
The technical foundations that make information accessible to search engines increasingly overlap with the foundations required for machine retrieval. Clear HTML, stable URLs, coherent internal architecture, accessible content, canonical consistency and machine-readable information can help reduce ambiguity across a wider discovery ecosystem.
What the 100 Technical SEO Statistics Cover
| Research Area | What We Examine |
|---|---|
| Crawling & Indexation | Crawl accessibility, indexation, robots directives, sitemaps and discoverability. |
| Core Web Vitals | LCP, INP, CLS and overall real-user performance. |
| Page Speed | Loading performance, rendering speed and user-experience measurements. |
| Mobile Performance | Differences between mobile and desktop technical performance. |
| JavaScript & Rendering | Client-side processing, rendering complexity and machine accessibility. |
| HTTP & Server Performance | Response behaviour, redirects, status codes and delivery infrastructure. |
| Structured Data | Schema implementation, rich-result eligibility and machine-readable information. |
| Site Architecture | Internal linking, crawl depth, URL structures and information architecture. |
| Technical Errors | Broken links, redirect problems, duplicate signals and indexing conflicts. |
| AI Search & Machine Retrieval | How technical accessibility increasingly supports discovery beyond conventional search results. |
2026 Core Web Vitals Benchmark
Google’s current Core Web Vitals framework measures three principal dimensions of real-world page experience: loading performance, responsiveness and visual stability.
| Metric | Measures | Good | Needs Improvement | Poor |
|---|---|---|---|---|
| LCP | Loading performance | ≤ 2.5 seconds | > 2.5 to 4 seconds | > 4 seconds |
| INP | Responsiveness | ≤ 200 ms | > 200 to 500 ms | > 500 ms |
| CLS | Visual stability | ≤ 0.1 | > 0.1 to 0.25 | > 0.25 |
CGO Media Research Position
Technical SEO Is Becoming Technical Discovery Infrastructure
The technical foundations of search visibility increasingly support more than conventional organic rankings. Websites must make information accessible, interpretable and retrievable across search engines, AI-mediated discovery systems and other machine-driven interfaces.
Crawlability → Indexability → Renderability → Performance → Entity Clarity → Machine Retrieval → Search & AI Visibility
Research Note
The statistics in this report are compiled from primary search-engine documentation, large-scale web-performance datasets, regulatory and industry research, and selected independent technical SEO studies. UK-specific evidence is identified separately from international data. Derived figures calculated from published measurements are labelled as CGO Media calculations. Full sources, definitions and methodological limitations are provided in the References & Research Methodology section.
Statistics 1–10
Core Web Vitals & Real-World Web Performance
Core Web Vitals provide one of the largest continuously updated datasets available for understanding real-world technical website performance. Unlike laboratory tests conducted under simulated conditions, the Chrome User Experience Report uses field data from opted-in Chrome users to measure how websites perform in real browsing environments.
The July 2026 Chrome User Experience Report contained data for more than 18 million origins. The results show that web performance continues to improve, but they also demonstrate that achieving good performance across every Core Web Vital remains considerably more difficult than passing any individual metric.
Statistic 1
18,059,068 Origins Were Included in the July 2026 Chrome UX Report
Google reported 18,059,068 origins in the July 2026 Chrome User Experience Report dataset. The scale of CrUX makes it one of the most substantial sources available for analysing real-world website performance.
Statistic 2
55.7% of Measured Origins Passed Core Web Vitals Overall
In July 2026, 55.7% of origins in Google’s CrUX dataset achieved good Core Web Vitals overall. This means that a little over half of measured origins met the required real-user performance standards across the applicable Core Web Vitals assessment.
Statistic 3
44.3% of Measured Origins Did Not Achieve Good Core Web Vitals Overall
If 55.7% of measured origins achieved good Core Web Vitals, the remaining 44.3% did not achieve a good overall assessment.
CGO Media Calculation: 100% − 55.7% = 44.3%.
Statistic 4
68.3% of Measured Origins Achieved Good Largest Contentful Paint
Google’s July 2026 CrUX release reported that 68.3% of measured origins achieved good Largest Contentful Paint performance. LCP measures how quickly the primary visible content of a page is rendered for users.
Statistic 5
31.7% of Measured Origins Did Not Achieve Good LCP
The corresponding figure means that 31.7% of measured origins were outside the good LCP classification in July 2026.
CGO Media Calculation: 100% − 68.3% = 31.7%.
Statistic 6
81.6% of Measured Origins Achieved Good Cumulative Layout Shift
In July 2026, 81.6% of measured origins achieved good CLS performance. CLS measures unexpected visual movement and provides an indication of how stable a page remains while users view and interact with it.
Statistic 7
85.7% of Measured Origins Achieved Good Interaction to Next Paint
Google reported that 85.7% of measured origins achieved good INP performance in July 2026. Of the three current Core Web Vitals, INP had the highest good-performance rate in this release.
Statistic 8
LCP Trailed INP by 17.4 Percentage Points
The proportion of origins achieving good LCP was 17.4 percentage points lower than the proportion achieving good INP. This indicates that loading the primary page content remains a broader challenge across the measured web than achieving the good INP threshold.
CGO Media Calculation: 85.7% − 68.3% = 17.4 percentage points.
Statistic 9
Only 48% of Mobile Websites Achieved Good Core Web Vitals in the 2025 Web Almanac Dataset
HTTP Archive’s analysis of 2025 real-user performance data found that approximately 48% of mobile websites achieved good Core Web Vitals overall. Mobile performance therefore remained below the halfway point in that dataset.
Statistic 10
56% of Desktop Websites Achieved Good Core Web Vitals in the Same 2025 Dataset
Desktop websites performed better, with approximately 56% achieving good Core Web Vitals. That produced an eight-percentage-point desktop advantage over mobile in the Web Almanac’s 2025 analysis.
CGO Media Calculation: 56% − 48% = 8 percentage points.
What the Core Web Vitals Data Tells Us
The first ten statistics reveal an important distinction between improvements to individual performance metrics and the ability to deliver consistently strong technical performance across an entire page experience.
More than four-fifths of origins in the July 2026 CrUX release achieved good CLS and more than 85% achieved good INP. Yet only 55.7% achieved good Core Web Vitals overall. A weakness in one component can therefore prevent an origin from achieving the overall good assessment even where other performance metrics are strong.
Largest Contentful Paint remains particularly important. At 68.3%, its good-performance rate was substantially below INP and CLS in the July 2026 dataset. Loading the principal visible content quickly therefore remains a major technical challenge across a significant proportion of the measured web.
Mobile Performance Remains the Harder Technical Problem
The device-level Web Almanac data reinforces this point. In its 2025 analysis, 56% of desktop websites achieved good Core Web Vitals compared with 48% on mobile.
Mobile environments combine network constraints, device processing limitations, JavaScript execution, image loading and responsive rendering. Technical SEO audits should therefore examine field performance by device rather than relying on a strong desktop result as evidence of strong mobile performance.
Sources & Measurement Notes
Google Chrome UX Report — July 2026 release: 18,059,068 origins; 68.3% good LCP; 81.6% good CLS; 85.7% good INP; 55.7% good Core Web Vitals overall.
HTTP Archive, Web Almanac 2025 — Performance: approximately 48% of mobile websites and 56% of desktop websites achieved good Core Web Vitals in the analysed 2025 dataset.
The Chrome UX Report and Web Almanac figures above are international web-performance measurements and should not be interpreted as UK-only statistics. They are included because Core Web Vitals are technical web standards applied to UK websites as part of the same global search ecosystem.
Statistics 11–20
Largest Contentful Paint, Loading Speed & Page Performance
Loading performance remains one of the clearest technical differences between fast and slow web experiences. Largest Contentful Paint measures when the largest visible content element within the viewport has rendered and provides a practical indication of when the primary content of a page becomes available to the user.
The 2025 HTTP Archive data demonstrates a persistent divide between desktop and mobile loading performance. It also reveals several of the underlying causes, including server response time, render-blocking resources, image formats and overall page weight.
Statistic 11
74% of Desktop Pages Achieved Good Largest Contentful Paint
HTTP Archive reported that 74% of desktop pages achieved a good Largest Contentful Paint result in its 2025 analysis. A good LCP is achieved when the largest visible content element renders within the recommended 2.5-second threshold for most users.
Statistic 12
62% of Mobile Pages Achieved Good Largest Contentful Paint
On mobile, only 62% of pages achieved good LCP. The mobile result was therefore materially lower than the corresponding desktop measurement.
Statistic 13
Desktop Led Mobile LCP Performance by 12 Percentage Points
The difference between the 74% desktop good-LCP rate and the 62% mobile rate produces a 12-percentage-point performance gap.
CGO Media Calculation: 74% − 62% = 12 percentage points.
Statistic 14
13% of Mobile Pages Had Poor LCP
HTTP Archive found that 13% of mobile pages fell into the poor LCP category, meaning their LCP exceeded four seconds under the measurement methodology.
Statistic 15
7% of Desktop Pages Had Poor LCP
The corresponding poor-LCP rate for desktop pages was 7%. Mobile pages therefore experienced poor LCP at almost twice the desktop rate.
Statistic 16
70% of Desktop Pages Achieved Good First Contentful Paint
In 2025, 70% of desktop pages achieved a good First Contentful Paint result. FCP measures the time between the initial page request and the browser displaying the first piece of DOM content.
Statistic 17
Only 55% of Mobile Pages Achieved Good First Contentful Paint
The equivalent good-FCP rate on mobile was 55%. This created a 15-percentage-point difference between desktop and mobile first-render performance.
CGO Media Calculation: 70% − 55% = 15 percentage points.
Statistic 18
Only 44% of Mobile Pages Achieved Good Time to First Byte
Just 44% of mobile pages achieved good Time to First Byte performance in 2025. TTFB captures network and server overhead before the browser receives the first byte of the response and begins subsequent rendering work.
Statistic 19
55% of Desktop Pages Achieved Good Time to First Byte
Desktop pages performed better, with 55% achieving good TTFB. Even on desktop, however, the figure indicates that almost half of measured pages were outside the good classification.
Statistic 20
Only 15% of Mobile Pages Passed the Render-Blocking Resources Audit
HTTP Archive reported that only 15% of mobile pages passed its render-blocking resources audit in 2025. The figure increased from 14% in 2024, but still indicates substantial scope to reduce resources that delay the browser’s initial rendering path.
Why Loading Performance Remains a Technical SEO Priority
The loading-performance statistics reveal that slow pages are rarely the result of a single technical problem. The time required to display primary content can be affected by server response, network latency, resource discovery, image delivery, render-blocking CSS and JavaScript, client-side processing and the weight of the page itself.
Mobile remains the more demanding environment. Good LCP was 12 percentage points lower on mobile than desktop, good FCP was 15 points lower, and good TTFB was 11 points lower in HTTP Archive’s 2025 data.
Images Remain Central to LCP Performance
One reason image optimisation remains so important is that images frequently become the largest visible element used to calculate LCP.
85.3%
of desktop pages had an image as the LCP content type
76.0%
of mobile pages had an image as the LCP content type
57%
of LCP images still used JPG
11%
of LCP images used WebP
The continued dominance of legacy image formats is notable. HTTP Archive found JPG accounted for approximately 57% of LCP images and PNG another 26%, while WebP accounted for around 11%. This leaves considerable room for broader adoption of modern image delivery strategies.
Page Weight Has a Measurable Relationship With LCP
HTTP Archive’s page-weight analysis provides further evidence of the relationship between heavier pages and weaker loading performance.
| Inner Page Weight | Desktop With Good LCP | Mobile With Good LCP |
|---|---|---|
| Up to 1 MB | 91% | 86% |
| 1–2 MB | 85% | 77% |
| 2–3 MB | 83% | 73% |
| 3–4 MB | 67% | 54% |
| 4–5 MB | 64% | 50% |
| 5 MB+ | 57% | 44% |
Among mobile inner pages weighing no more than 1 MB, 86% achieved good LCP. For pages weighing 5 MB or more, this fell to 44%. Although page weight alone does not determine performance, the difference illustrates how increasingly heavy page delivery can place greater pressure on the loading path.
Sources & Measurement Notes
HTTP Archive — Web Almanac 2025, Performance: LCP, FCP, TTFB, render-blocking resources, LCP content types and LCP image-format measurements.
HTTP Archive — Web Almanac 2025, Page Weight: page-weight segmentation and LCP performance for desktop and mobile inner pages.
These measurements are international web-performance datasets rather than UK-only statistics. They are used to establish quantitative technical benchmarks applicable to websites operating within the same web and search infrastructure.
Statistics 21–30
Interaction to Next Paint, JavaScript & Main-Thread Performance
Loading a page is only part of technical performance. Once content becomes visible, users expect the page to respond quickly when they click, tap or interact with interface elements. Interaction to Next Paint measures this responsiveness across the user’s visit and is now one of Google’s three Core Web Vitals.
The available performance data shows that INP has improved substantially across the web. However, the difference between desktop and mobile remains important, particularly when JavaScript execution and main-thread blocking are considered.
Statistic 21
97% of Desktop Sites Achieved Good Interaction to Next Paint
HTTP Archive’s 2025 performance analysis found that 97% of desktop sites achieved a good Interaction to Next Paint result. This places desktop INP among the strongest-performing major real-user performance metrics in the dataset.
Statistic 22
77% of Mobile Sites Achieved Good Interaction to Next Paint
The corresponding mobile result was 77%. Although more than three-quarters of mobile sites achieved good INP, the result remained materially below desktop performance.
Statistic 23
Desktop Led Mobile INP Performance by 20 Percentage Points
The difference between the desktop and mobile good-INP rates was 20 percentage points. The scale of this gap reinforces the need to evaluate interaction performance under real mobile conditions.
CGO Media Calculation: 97% − 77% = 20 percentage points.
Statistic 24
23% of Mobile Sites Did Not Achieve Good INP
With 77% of mobile sites achieving good INP, the remaining 23% were outside the good classification.
CGO Media Calculation: 100% − 77% = 23%.
Statistic 25
Median Desktop Total Blocking Time Was 92 Milliseconds
The median desktop page recorded a Total Blocking Time of approximately 92 milliseconds in HTTP Archive’s 2025 analysis. TBT measures how long the browser’s main thread is blocked by long tasks during the loading process in laboratory testing.
Statistic 26
Median Mobile Total Blocking Time Was 1,916 Milliseconds
On mobile, median Total Blocking Time reached approximately 1,916 milliseconds. This represents almost two seconds of aggregate main-thread blocking in the median mobile laboratory test.
Statistic 27
Median Mobile Total Blocking Time Was More Than 20 Times the Desktop Level
Comparing the median figures produces a substantial difference: mobile Total Blocking Time was approximately 20.8 times the desktop level.
CGO Media Calculation: 1,916 ms ÷ 92 ms ≈ 20.8×.
Statistic 28
The Median Mobile Page Loaded More Than 600 KB of JavaScript
HTTP Archive’s Web Almanac data shows that the median mobile page now transfers more than 600 KB of JavaScript. JavaScript therefore represents a substantial component of the modern page payload and can create significant processing work after network transfer has finished.
Statistic 29
Around One-Third of JavaScript Bytes Can Go Unused on the Median Mobile Page
Web Almanac analysis has repeatedly found substantial volumes of JavaScript that are downloaded but not required during the initial page experience. At the median, approximately one-third of transferred JavaScript bytes can be unused during page load.
Unused JavaScript still consumes network bandwidth and can add parsing, compilation and execution overhead even when it contributes little to the immediate user experience.
Statistic 30
Google’s Good INP Threshold Is 200 Milliseconds or Less
Google classifies Interaction to Next Paint of 200 milliseconds or less as good when assessed at the 75th percentile of page loads. INP above 200 ms and up to 500 ms needs improvement, while values above 500 ms are classified as poor.
JavaScript Performance Is Increasingly a Mobile Technical SEO Issue
The INP statistics initially appear encouraging. A large majority of measured websites now achieve good responsiveness, and desktop performance is particularly strong. However, the laboratory data reveals a more complicated technical picture.
The difference between 92 milliseconds of median desktop Total Blocking Time and 1,916 milliseconds on mobile illustrates how much more severely processing-heavy pages can affect constrained devices. The issue is not simply the number of JavaScript files downloaded. Browsers must parse, compile and execute the code, while long-running tasks can compete with user interactions for access to the main thread.
This is why JavaScript optimisation should not be treated purely as a page-speed exercise. Excessive client-side execution can affect responsiveness, rendering, content availability and the reliability with which both users and machines encounter important information.
The JavaScript Performance Chain
JavaScript Transfer
→
Parsing
→
Compilation
→
Execution
→
Main-Thread Work
→
Interaction Delay
→
User Experience
INP and Total Blocking Time Are Not the Same Metric
The contrast between relatively strong field INP results and much higher mobile Total Blocking Time should not be interpreted as a contradiction. The two metrics measure different aspects of performance.
| Metric | Data Type | What It Measures |
|---|---|---|
| Interaction to Next Paint | Field / real-user metric | Observed responsiveness to user interactions throughout a page visit. |
| Total Blocking Time | Laboratory metric | The sum of blocking time from long main-thread tasks during the measured loading period. |
Field data records what happens to real users, while laboratory measurements make it possible to diagnose technical conditions under controlled environments. Strong technical SEO therefore benefits from using both rather than treating one performance score as a complete representation of the website.
What Technical Teams Should Examine
JavaScript payload: determine how much code is being transferred and whether all of it is necessary.
Unused JavaScript: identify code that is downloaded but provides no immediate value to the rendered page.
Long tasks: locate execution tasks that occupy the main thread long enough to delay interaction.
Third-party scripts: measure the performance cost of analytics, advertising, consent, chat, personalisation and other external scripts.
Mobile processing: test on realistic mobile hardware and network conditions rather than assuming desktop laboratory performance will translate directly to mobile users.
Sources & Measurement Notes
HTTP Archive — Web Almanac 2025, Performance: Interaction to Next Paint and Total Blocking Time measurements for desktop and mobile websites.
HTTP Archive — Web Almanac, JavaScript: JavaScript transfer and unused-code measurements across modern web pages.
Google web.dev / Chrome: INP ≤200 ms is classified as good, >200–500 ms as needs improvement and >500 ms as poor when assessed at the recommended 75th percentile.
The performance measurements in this section are international rather than UK-only datasets. They provide technical benchmarks for websites operating in the UK and internationally. Field and laboratory metrics are identified separately because they measure different aspects of website performance.
Statistics 31–40
Cumulative Layout Shift, Visual Stability, Images & Layout Performance
Visual stability is the third major component of Core Web Vitals. Cumulative Layout Shift measures unexpected movement of visible page elements, helping identify experiences where content moves after users have already begun reading or interacting with a page.
The web has made substantial progress on CLS since the introduction of Core Web Vitals. However, HTTP Archive’s 2025 data shows that many websites still contain straightforward technical issues that can increase the risk of layout movement, particularly images without reserved dimensions and inefficient font-loading strategies.
Statistic 31
81% of Mobile Pages Achieved Good Cumulative Layout Shift
In HTTP Archive’s 2025 analysis, 81% of mobile pages achieved a good Cumulative Layout Shift score. A good CLS score is 0.1 or less under the current Core Web Vitals thresholds.
Statistic 32
72% of Desktop Pages Achieved Good Cumulative Layout Shift
The equivalent desktop result was 72%. Unlike several other Core Web Vitals measurements, mobile therefore outperformed desktop for visual stability.
Statistic 33
Mobile Led Desktop CLS Performance by 9 Percentage Points
The difference between the mobile and desktop good-CLS rates was 9 percentage points. This is the reverse of the pattern observed for LCP and INP, where desktop performance was stronger.
CGO Media Calculation: 81% − 72% = 9 percentage points.
Statistic 34
Only 9% of Mobile Pages Had Poor CLS
Approximately 9% of mobile pages were classified as having poor CLS in 2025. A poor CLS result is above 0.25.
Statistic 35
10% of Desktop Pages Had Poor CLS
The poor-CLS rate for desktop pages was approximately 10%. Severe layout instability therefore affected roughly one in ten measured desktop pages.
Statistic 36
Good Mobile CLS Increased From 62% in 2021 to 81% in 2025
HTTP Archive’s historical analysis shows that the proportion of mobile websites achieving good CLS increased from 62% in 2021 to 81% in 2025.
That represents a 19-percentage-point improvement over the four-year period.
Statistic 37
Good Desktop CLS Increased From 62% in 2021 to 72% in 2025
Desktop visual stability also improved. The proportion of sites achieving good CLS increased from 62% in 2021 to 72% in 2025, a gain of 10 percentage points.
Statistic 38
62% of Mobile Pages Still Had at Least One Image Without Explicit Dimensions
Despite improvements in overall CLS, 62% of mobile pages still failed to set explicit dimensions on at least one image in 2025. This was an improvement from 66% in 2024, but unsized images remained present on the majority of measured mobile pages.
Statistic 39
65% of Desktop Pages Had at Least One Image Without Explicit Dimensions
The problem was slightly more common on desktop, where 65% of pages had at least one image without explicit dimensions. This was down from 69% in 2024.
Statistic 40
87% of Mobile Pages Used at Least One Web Font
HTTP Archive found that 87% of mobile pages used at least one web font. Because font replacement can alter text dimensions after the initial render, font loading remains an important potential contributor to layout movement.
Visual Stability Has Improved — But Basic Technical Problems Remain
CLS provides one of the clearest examples of technical improvement across the web. In 2021, only 62% of both desktop and mobile websites achieved good CLS. By 2025, this had risen to 72% on desktop and 81% on mobile.
Mobile’s 19-percentage-point improvement is particularly significant. Yet the underlying implementation data shows that many websites still contain avoidable sources of instability.
The fact that 62% of mobile pages and 65% of desktop pages contain at least one image without explicit dimensions demonstrates the difference between achieving a passing field metric and fully implementing technical best practice.
Unsized Images Remain Widespread
When an image does not have a known intrinsic size, the browser may initially allocate insufficient space for it. Once the image loads, surrounding content can move to accommodate it, creating a layout shift.
| Measurement | Desktop | Mobile |
|---|---|---|
| Pages with at least one unsized image | 65% | 62% |
| Median unsized images per page | 2 | 1 |
| 75th percentile unsized images | 9 | 8 |
| 90th percentile unsized images | Approximately 25+ | Approximately 22+ |
At the upper end of the distribution, the problem becomes considerably larger. Pages around the 90th percentile contained more than 20 unsized images, meaning a relatively simple implementation issue can be repeated many times across a single document.
Secondary Pages Can Be More Visually Stable Than Homepages
71%
desktop homepages with good CLS
73%
desktop secondary pages with good CLS
79%
mobile homepages with good CLS
81%
mobile secondary pages with good CLS
Secondary pages performed slightly better than homepages on both device categories. This is plausible because homepages frequently contain more dynamic components including hero media, carousels, promotional banners, advertising, personalisation and other elements capable of altering the layout after initial rendering.
Font Loading Creates Another Technical Opportunity
Web fonts are used on 87% of measured mobile pages, yet the technical methods that can help make important fonts available earlier are much less widely deployed.
| Font Resource Hint | Desktop Pages | Mobile Pages |
|---|---|---|
| dns-prefetch | 24% | 24% |
| preconnect | 22% | 22% |
| preload | 15% | 16% |
| prefetch | Approximately 5% | Approximately 5% |
Only 15–16% of pages used preload for fonts in the dataset. The difference between widespread custom-font adoption and relatively limited preload usage demonstrates another area where relatively small technical changes can improve rendering behaviour.
Visual Stability Also Declines as Pages Become Heavier
HTTP Archive’s page-weight analysis found a clear decline in the percentage of inner pages achieving good CLS as page weight increased.
| Inner Page Weight | Desktop With Good CLS | Mobile With Good CLS |
|---|---|---|
| Up to 1 MB | 87% | 90% |
| 1–2 MB | 78% | 84% |
| 2–3 MB | 74% | 77% |
| 3–4 MB | 71% | 75% |
| 4–5 MB | 69% | 73% |
| 5 MB+ | 65% | 69% |
Among inner pages weighing no more than 1 MB, 87% of desktop pages and 90% of mobile pages achieved good CLS. Once page weight exceeded 5 MB, these figures fell to 65% and 69% respectively. The relationship does not prove that page weight itself causes layout instability, but heavier pages tend to contain more resources and dynamic components capable of affecting rendering behaviour.
Sources & Measurement Notes
HTTP Archive — Web Almanac 2025, Performance: CLS performance by device, historical CLS improvement, homepage versus secondary-page performance, unsized images, web-font adoption and font resource hints.
HTTP Archive — Web Almanac 2025, Page Weight: relationship between page-weight bands and the percentage of inner pages achieving good CLS.
Core Web Vitals threshold: CLS ≤0.1 is classified as good, >0.1–0.25 as needs improvement and >0.25 as poor when evaluated using the recommended real-user methodology.
The figures are international web-performance measurements rather than UK-only statistics. They provide technical benchmarks applicable to UK websites operating within the same browser and search infrastructure.
Statistics 41–50
Crawlability, Indexation, Robots.txt & Canonicalisation
Before content can compete for visibility, search engines must be able to discover, crawl and interpret it. Crawlability and indexability therefore remain among the most fundamental requirements of technical SEO.
The same technical controls are becoming increasingly relevant beyond conventional search. Robots directives, canonical signals and machine-access rules now operate in an environment containing traditional search crawlers, SEO crawlers and a rapidly expanding group of AI-related bots.
Statistic 41
84.9% of Websites Returned a Successful 200 Response for Robots.txt
HTTP Archive found that 84.9% of both desktop and mobile sites returned a successful HTTP 200 status when their robots.txt file was requested in 2025.
Statistic 42
13.3% of Desktop Sites Returned a 404 for Robots.txt
Approximately 13.3% of desktop sites returned a 404 response when robots.txt was requested. The corresponding mobile figure was 13.2%.
A missing robots.txt file does not itself mean that a site cannot be crawled. In the absence of crawl restrictions, compliant crawlers can generally proceed.
Statistic 43
Only 0.1% of Sites Returned a 5xx Server Error for Robots.txt
Server failures were uncommon: approximately 0.1% of both desktop and mobile robots.txt requests returned a 5xx status.
The low prevalence does not make these errors unimportant. A server error affecting robots.txt can temporarily influence how compliant crawlers treat access to the site.
Statistic 44
77.1% of Mobile Robots.txt Files Used the Universal * User Agent
The wildcard user agent remained by far the most common crawler target. It appeared in approximately 77.1% of mobile robots.txt files and 77.0% of desktop files.
This indicates that broad rules applying to multiple compliant crawlers remain considerably more common than individually configured crawler policies.
Statistic 45
GPTBot Appeared in 4.5% of Desktop Robots.txt Files
OpenAI’s GPTBot was explicitly named in approximately 4.5% of desktop robots.txt files in the 2025 Web Almanac dataset. The corresponding mobile figure was 4.2%.
Statistic 46
GPTBot Robots.txt Targeting Increased by Approximately 55% Year on Year
GPTBot appeared in 4.5% of desktop robots.txt files in 2025, compared with 2.9% in the previous year’s dataset. HTTP Archive described this as an increase of approximately 55%.
The increase illustrates how crawler-management strategies are expanding beyond conventional search-engine bots.
Statistic 47
47.9% of Mobile Pages Implemented Meta Robots Directives
Meta robots remained the dominant method for implementing page-level indexing and serving controls, appearing on 47.9% of mobile pages and 47.0% of desktop pages.
Statistic 48
Only 0.7% of Mobile Pages Used an X-Robots-Tag
HTTP-header-based X-Robots-Tag implementation remained uncommon, appearing on approximately 0.7% of mobile pages and 0.6% of desktop pages.
X-Robots-Tag remains technically useful because it can apply indexing controls to non-HTML resources, including documents and other file types.
Statistic 49
68% of Desktop Pages Used a Canonical Tag
Canonical usage increased again in 2025, with approximately 68% of desktop pages containing a canonical tag. Mobile usage was approximately 67%.
Both desktop and mobile canonical adoption had been approximately 65% in the previous year’s dataset.
Statistic 50
10.3% of Mobile Pages Contained Invalid HTML Elements Inside the Head
HTTP Archive found invalid HTML elements within the document head on approximately 10.3% of mobile pages and 10.1% of desktop pages.
This matters because invalid elements can cause browsers and crawlers to interpret the head as ending early. Important SEO elements appearing after that point may then be treated as body content rather than valid head metadata.
Crawl Management Is Becoming More Complex
The crawlability data shows a web with relatively mature traditional crawler controls. Approximately 85% of sites successfully serve a robots.txt file, and the universal wildcard remains the dominant method for expressing crawler rules.
What is changing is the number and type of crawlers website operators may want to address individually. Search-engine crawlers now coexist with SEO tools, commercial data crawlers, AI training crawlers and user-triggered AI retrieval systems.
GPTBot’s rise from 2.9% to 4.5% of desktop robots.txt files in a single year provides a measurable example of that transition.
AI Crawlers Are Becoming Visible in Robots.txt Data
HTTP Archive’s 2025 dataset records several AI-related user agents appearing in robots.txt files at measurable scale.
| Crawler | Desktop Robots.txt | Mobile Robots.txt |
|---|---|---|
| GPTBot | 4.5% | 4.2% |
| PetalBot | 4.0% | 4.4% |
| ClaudeBot | 3.6% | 3.4% |
| CCBot | 3.5% | 3.2% |
| Google-Extended | 3.4% | 3.0% |
| PerplexityBot | 2.8% | 2.7% |
| ChatGPT-User | 2.8% | 2.5% |
These percentages do not indicate whether a crawler is being allowed or blocked. They measure how often the user agent is explicitly named. The figures nevertheless demonstrate that AI crawler management has moved from a marginal technical issue into a measurable component of robots.txt configuration.
Crawl Controls and Index Controls Must Not Be Confused
| Control | Primary Function | 2025 Adoption Example |
|---|---|---|
| Robots.txt | Controls crawler access to paths for compliant crawlers. | 84.9% returned HTTP 200. |
| Meta Robots | Provides page-level indexing and serving instructions. | 47.9% mobile / 47.0% desktop. |
| X-Robots-Tag | Provides HTTP-header indexing controls, including for non-HTML resources. | 0.7% mobile / 0.6% desktop. |
| Canonical | Signals the preferred URL among duplicate or near-duplicate versions. | 67% mobile / 68% desktop. |
Canonicalisation Is Widespread — But Not Universal
Canonical adoption increased from approximately 65% in 2024 to 68% on desktop and 67% on mobile in 2025. However, this still leaves a substantial proportion of measured pages without an explicit canonical tag.
68%
desktop pages with a canonical
67%
mobile pages with a canonical
7%
desktop pages canonicalised to another URL
9%
mobile pages canonicalised to another URL
Canonical consistency is also important. HTTP Archive detected raw-versus-rendered canonical mismatches on approximately 0.7% of pages, while around 3% of mobile pages experienced a canonical change during rendering. At web scale, even relatively small percentages can represent a substantial number of URLs.
Technical Accessibility Is Now a Search and AI Discovery Issue
The expansion of AI-related crawler controls does not eliminate the traditional technical SEO requirement to make important public content consistently accessible and interpretable. Instead, organisations increasingly need to understand which machines they permit to access which content, and for what purpose.
Crawler Access → Page Retrieval → Rendering → Indexability → Canonical Clarity → Machine Understanding → Discovery Eligibility
Sources & Measurement Notes
HTTP Archive — Web Almanac 2025, SEO: robots.txt response codes, robots.txt user-agent usage, AI crawler targeting, meta robots implementation, X-Robots-Tag implementation, canonical adoption and invalid head markup.
A successful HTTP 200 response for robots.txt confirms that a file was returned. It does not establish that the directives inside the file are technically correct or strategically appropriate.
The presence of an AI crawler name in robots.txt does not indicate whether that crawler is being allowed or disallowed. It measures explicit targeting of the named user agent.
The HTTP Archive dataset is international rather than UK-only. It is used as a large-scale technical benchmark for crawlability and indexability practices relevant to UK websites operating within the same search and web infrastructure.
Statistics 51–60
Structured Data, Schema Markup & Machine-Readable Search
Structured data provides machines with an explicit representation of information contained within a web page. Rather than requiring a search engine to infer every relationship from visible text and HTML structure, schema markup can identify organisations, people, products, articles, breadcrumbs, events and other entities in a standardised machine-readable form.
Large-scale web data shows that structured-data adoption continues to expand. JSON-LD has become the dominant implementation method, while traditional formats such as Microdata remain present across a substantial part of the web.
Statistic 51
More Than 45% of Mobile Pages Used JSON-LD Structured Data
HTTP Archive’s structured-data analysis found JSON-LD on more than 45% of mobile pages. JSON-LD has therefore moved well beyond specialist SEO implementation and is now present across a substantial share of the measured web.
Statistic 52
JSON-LD Adoption Has More Than Doubled Since 2020
Large-scale Web Almanac measurements show JSON-LD adoption increasing from roughly 20% of pages in 2020 to more than 45% in recent measurements. This represents more than a doubling in implementation over the period.
Statistic 53
Microdata Remains Present on Approximately One in Five Pages
Despite the rise of JSON-LD, Microdata remains in use across approximately 20% of measured pages. Structured-data implementation across the web therefore remains a mixture of modern and legacy formats rather than a complete migration to one method.
Statistic 54
JSON-LD Is More Than Twice as Common as Microdata
Comparing adoption rates shows that JSON-LD is now used on more than twice as many pages as Microdata. This represents a significant shift in how websites expose structured information to search engines and other machines.
CGO Media Calculation: 45% ÷ 20% = approximately 2.25×.
Statistic 55
RDFa Is Used on Fewer Than 5% of Measured Pages
RDFa has become a comparatively minor structured-data implementation method, appearing on fewer than 5% of measured pages in large-scale Web Almanac datasets.
Statistic 56
WebSite Schema Appears on More Than 30% of Pages Using JSON-LD
Among pages implementing JSON-LD, WebSite is one of the most frequently observed Schema.org types, appearing across more than 30% of implementations in large-scale structured-data measurements.
Statistic 57
Organization Schema Appears on More Than One-Quarter of JSON-LD Pages
Organization markup is also among the most common JSON-LD entity types, appearing on more than one-quarter of pages using JSON-LD in large-scale web measurements.
Statistic 58
BreadcrumbList Appears on More Than 20% of JSON-LD Implementations
BreadcrumbList is another frequently observed structured-data type, appearing on more than one-fifth of pages implementing JSON-LD. Breadcrumb markup provides machines with an explicit representation of a page’s position within a site’s hierarchy.
Statistic 59
Product Is Among the Most Common Commercial Schema Types Across the Web
Product markup appears across a measurable double-digit share of JSON-LD implementations in large-scale web datasets, reflecting the importance of structured product information to ecommerce search and machine interpretation.
Statistic 60
Schema.org’s Vocabulary Contains More Than 800 Types
The Schema.org vocabulary now contains more than 800 defined types, alongside hundreds of properties that can be used to describe entities, attributes and relationships in machine-readable form.
Structured Data Has Become Mainstream Technical Infrastructure
The adoption trend is significant. When almost half of measured mobile pages contain JSON-LD, structured data can no longer reasonably be characterised as an advanced technique used only by technically sophisticated organisations.
Its role has also expanded. Structured data is commonly discussed in relation to rich-result eligibility, but its underlying function is broader: it expresses facts and relationships in a form designed specifically for machine interpretation.
For technical SEO, this means implementation quality matters as much as implementation volume. Adding large quantities of schema does not automatically improve visibility. The markup needs to correspond with visible content, represent the correct entity type and remain consistent with the organisation’s wider information architecture.
JSON-LD Has Become the Dominant Structured Data Format
| Format | Approximate Web Adoption | Implementation Approach |
|---|---|---|
| JSON-LD | 45%+ | Structured data contained within a separate JSON-LD script block. |
| Microdata | Approximately 20% | Structured attributes embedded directly within HTML elements. |
| RDFa | Below 5% | Semantic attributes embedded within HTML markup. |
Structured Data Is Fundamentally About Entities and Relationships
Organisation
→
Entity Properties
→
People
→
Products / Services
→
Content
→
Relationships
→
Machine Understanding
The increasing adoption of Organization, WebSite, BreadcrumbList, Article and Product markup reflects the movement from isolated keyword optimisation towards more explicit representations of entities and their relationships.
Structured Data and AI Search
Structured data should not be presented as a guaranteed mechanism for inclusion in AI-generated answers. Current evidence does not justify a claim that adding schema directly causes an organisation to be cited or recommended by an AI system.
Its value is more fundamental. Well-designed structured data reduces ambiguity by explicitly describing entities, properties and relationships. This makes it part of a broader technical architecture for machine-readable information.
Entity Identity
Clarifies what an organisation, person, product or other entity represents.
Entity Properties
Provides explicit attributes that machines can associate with an entity.
Relationships
Connects organisations, people, content, products and other entities.
Page Context
Provides machines with additional context about the information represented by a page.
More Schema Does Not Automatically Mean Better Technical SEO
Structured data should accurately represent the information users can verify on the page and across the wider website.
Incorrect entity types, conflicting properties, obsolete markup and automatically generated schema that does not correspond with visible content can reduce rather than improve machine clarity.
The technical objective is therefore not maximum schema volume. It is a coherent machine-readable representation of the organisation, its content and the relationships between important entities.
CGO Media Research Position
Structured Data Should Support the Wider Knowledge Architecture
Schema markup is most useful when it reinforces information that is already clear within the website’s visible content, internal architecture and external entity signals.
Visible Evidence → Structured Entities → Consistent Relationships → Reduced Ambiguity → Machine Understanding
Sources & Measurement Notes
HTTP Archive — Web Almanac, Structured Data & SEO: large-scale measurements of JSON-LD, Microdata, RDFa and commonly implemented Schema.org types across desktop and mobile pages.
Schema.org: vocabulary definitions and the scale of the structured-data type and property system.
Google Search Central: structured-data documentation and eligibility requirements for supported search features. Structured data can make a page eligible for particular search experiences but does not guarantee that those features will appear.
Structured-data adoption figures are international web measurements rather than UK-only statistics. They are used as technical benchmarks for UK websites operating within the same search and machine-readable web ecosystem.
Statistics 61–70
HTTP Protocols, Compression, CDNs & Delivery Infrastructure
Technical SEO performance is influenced not only by the HTML, JavaScript and images contained within a page, but also by the infrastructure responsible for delivering those resources. DNS resolution, HTTP protocol versions, compression, caching and content delivery networks can all affect how quickly a browser begins receiving and processing information.
HTTP Archive’s 2025 research demonstrates that modern delivery infrastructure is increasingly concentrated at the CDN layer. CDNs are playing an important role in deploying HTTP/3, modern compression and lower-latency DNS infrastructure before equivalent technologies become widespread across origin servers.
Statistic 61
29% of CDN-Served Mobile HTML Requests Used HTTP/3
In HTTP Archive’s 2025 dataset, 29% of mobile HTML requests served through CDNs used HTTP/3. This demonstrates the growing role of edge infrastructure in deploying newer web protocols.
Statistic 62
69% of CDN-Served Mobile HTML Requests Used HTTP/2
HTTP/2 remained the dominant protocol for CDN-served mobile HTML, accounting for 69% of measured requests. HTTP/3 therefore represents substantial adoption but has not yet replaced HTTP/2 as the principal delivery protocol in this dataset.
Statistic 63
Only 2% of CDN-Served Mobile HTML Requests Used HTTP/1.1
Legacy HTTP/1.1 accounted for only 2% of CDN-served mobile HTML requests in the 2025 analysis. Modern protocols therefore represented approximately 98% of measured CDN HTML delivery.
CGO Media Calculation: 29% HTTP/3 + 69% HTTP/2 = 98% using HTTP/2 or HTTP/3.
Statistic 64
35% of Mobile HTML Content Was Served Through a CDN
Approximately 35% of mobile HTML content in the HTTP Archive dataset was served through a CDN. HTML had lower CDN adoption than more cacheable static and third-party resources.
Statistic 65
71% of Third-Party Mobile Resources Were Served Through CDNs
CDN adoption was considerably higher for third-party content, with approximately 71% of measured third-party mobile resources being delivered through CDN infrastructure.
Statistic 66
Median Mobile CDN DNS Resolution Was 176 Milliseconds
HTTP Archive measured median DNS resolution of approximately 176 milliseconds for CDN-served mobile requests, compared with 217 milliseconds for origin infrastructure.
Statistic 67
CDN DNS Resolution Was 19% Faster Than Origin DNS on Mobile
The 176 ms median CDN DNS measurement compared with 217 ms for origin infrastructure represented an approximately 19% DNS-resolution advantage for CDN-served mobile requests.
Statistic 68
CDN DNS Resolution Was 60% Faster Than Origin DNS on Desktop
On desktop, median CDN DNS resolution was approximately 52 milliseconds compared with 129 milliseconds for origins. HTTP Archive calculated this as a 60% performance advantage.
Statistic 69
46% of CDN-Served Mobile Requests Used Brotli Compression
Among compressed mobile requests delivered through CDNs, 46% used Brotli. A further 42% used gzip and 12% used Zstandard, demonstrating considerably broader adoption of modern compression methods at the CDN layer.
Statistic 70
72% of Mobile Home Pages Properly Compressed Text Resources
Lighthouse’s text-compression audit found that approximately 72% of mobile home pages properly compressed eligible text-based resources in 2025. Mobile inner pages performed slightly better at 73%.
Delivery Infrastructure Has Become Part of Technical SEO
These statistics illustrate why technical SEO audits should extend beyond the source code of individual pages. A technically efficient HTML document can still be delivered through slow DNS resolution, legacy protocols, inefficient compression or distant infrastructure.
Conversely, modern infrastructure cannot compensate for excessively heavy or inefficient pages. CDNs can reduce latency, provide protocol optimisation and compress resources, but the underlying amount of code, imagery and other data still matters.
HTTP/3 Adoption Is Being Driven by CDN Infrastructure
| Protocol | CDN-Served Mobile HTML | Technical Context |
|---|---|---|
| HTTP/3 | 29% | QUIC-based transport with independent streams and reduced connection-establishment overhead. |
| HTTP/2 | 69% | Multiplexed requests over TCP and still the dominant protocol in the dataset. |
| HTTP/1.1 | 2% | Legacy protocol representing only a small share of CDN HTML delivery. |
Compression Remains an Underused Performance Opportunity
Compression reduces the number of bytes transferred across the network for text-based resources such as HTML, CSS, JavaScript, JSON and SVG. Despite being a mature optimisation, more than one-quarter of pages still failed HTTP Archive’s efficient text-compression audit.
71%
desktop home pages passed text compression
72%
mobile home pages passed
72%
desktop inner pages passed
73%
mobile inner pages passed
Each segment improved by only around one percentage point compared with 2024. The data therefore suggests that compression adoption is improving, but slowly.
Modern Compression Is Advancing Faster on CDNs
| Compression | CDN Requests | Origin Requests |
|---|---|---|
| Brotli | 46% | 39% |
| Gzip | 42% | 61% |
| Zstandard | 12% | Minimal / not materially represented |
Zstandard provides a particularly useful illustration of infrastructure change. Its share of CDN-compressed requests increased from approximately 3% in 2024 to 12% in 2025, a fourfold increase in share within a year.
Infrastructure Optimisation Matters More as Pages Become Heavier
The importance of efficient delivery becomes clearer when page weight is considered. The median home page continued to grow in 2025.
2.86 MB
median desktop home page
2.56 MB
median mobile home page
7.8%
year-on-year median home-page growth
202.8%
10-year growth in median mobile home-page weight
The median mobile home page increased from approximately 845 KB in July 2015 to roughly 2.56 MB in July 2025. HTTP Archive calculated the decade-long increase at 202.8%. Efficient compression, caching and resource delivery therefore matter in an environment where the typical amount of transferred data has increased substantially.
Technical Delivery Model
Search Performance Begins Before the Browser Receives the Page
DNS Resolution → Connection → TLS → HTTP Protocol → Server Response → Compression → Resource Transfer → Rendering → User Experience
Sources & Measurement Notes
HTTP Archive — Web Almanac 2025, CDN: CDN adoption, HTTP/3 and HTTP/2 deployment, DNS-resolution performance, Brotli, gzip and Zstandard compression measurements.
HTTP Archive — Web Almanac 2025, Page Weight: text-compression audit results, median page weight and long-term page-weight growth.
HTTP Archive cautions that its HTTP/3 measurements reflect its own test methodology, including popular websites and limited testing locations. The figures should not be interpreted as the percentage of all global internet traffic using HTTP/3.
These measurements are international rather than UK-only. They are used as technical infrastructure benchmarks relevant to UK websites operating within the same HTTP, browser, CDN and search ecosystem.
Statistics 71–80
Page Weight, Images, JavaScript & Resource Efficiency
Modern websites continue to become heavier. Larger image payloads, expanding JavaScript bundles, third-party services, fonts and increasingly sophisticated interfaces all contribute to the amount of data browsers must retrieve and process.
Page weight does not determine performance on its own. A well-cached and efficiently delivered page can outperform a smaller but poorly engineered alternative. Nevertheless, increasing payload size creates additional network, processing and rendering work and therefore increases the technical burden placed on browsers, mobile devices, crawlers and users.
Statistic 71
The Median Desktop Page Weighed 2,412 KB
Across HTTP Archive’s 2025 dataset, the median desktop page transferred approximately 2,412 KB of resources. A typical desktop page therefore now requires more than 2 MB of transferred data.
Statistic 72
The Median Mobile Page Weighed 2,164 KB
The corresponding median mobile page weighed approximately 2,164 KB. Mobile pages were somewhat lighter than desktop pages but still exceeded 2 MB at the median.
Statistic 73
The 90th-Percentile Desktop Page Exceeded 9 MB
At the 90th percentile, desktop page weight reached approximately 9,179 KB. This means one in ten measured desktop pages was approximately 9 MB or heavier.
Statistic 74
The 90th-Percentile Mobile Page Exceeded 8 MB
Mobile page weight reached approximately 8,337 KB at the 90th percentile. The upper end of the mobile web therefore routinely delivers multi-megabyte experiences to devices that may have more limited network and processing resources.
Statistic 75
Images Accounted for 911 KB on the Median Mobile Home Page
Images represented the largest measured resource category on the median mobile home page, contributing approximately 911 KB of transferred data.
Statistic 76
Images Accounted for 1,058 KB on the Median Desktop Home Page
Desktop home pages carried an even larger image payload. The median desktop home page transferred approximately 1,058 KB of image resources.
Statistic 77
The Median Desktop Page Transferred 708 KB of JavaScript
Across page types, the median desktop page transferred approximately 708 KB of JavaScript. At the 90th percentile, JavaScript transfer exceeded 2 MB.
Statistic 78
The Median Mobile Page Transferred 646 KB of JavaScript
The median mobile page transferred approximately 646 KB of JavaScript. At the 90th percentile, the mobile JavaScript payload increased to approximately 1,910 KB.
Statistic 79
98.1% of Pages Requested at Least One JavaScript File
JavaScript has become almost universal across the modern web. HTTP Archive found that 98.1% of pages made at least one request for an external JavaScript file.
This measurement does not include JavaScript embedded directly within the HTML document, meaning overall JavaScript usage is broader still.
Statistic 80
The Median Desktop Page Made 77 Network Requests
The median desktop page required approximately 77 network requests to assemble its resources. The median mobile page required 72 requests.
Request volume increased year on year by approximately 8% on desktop and 9% on mobile.
The Modern Web Is Becoming Heavier
The page-weight distribution demonstrates that web bloat is not confined to a small group of exceptionally large websites. More than 2 MB of transferred data is now typical at the median, while pages exceeding 8–9 MB appear within the top tenth of the measured distribution.
The technical consequences are cumulative. Every resource must potentially be discovered, requested, transferred, decompressed, parsed, decoded or executed before it can contribute to the rendered experience.
This means resource efficiency is not simply about achieving a particular Lighthouse score. It is about reducing unnecessary technical work throughout the entire delivery and rendering chain.
Page Weight Increases Rapidly Above the Median
| Percentile | Desktop Page Weight | Mobile Page Weight |
|---|---|---|
| 10th | 607 KB | 516 KB |
| 25th | 1,275 KB | 1,127 KB |
| 50th | 2,412 KB | 2,164 KB |
| 75th | 4,570 KB | 4,119 KB |
| 90th | 9,179 KB | 8,337 KB |
The difference between the median and 90th percentile is substantial. Desktop page weight rises from 2,412 KB to 9,179 KB, while mobile increases from 2,164 KB to 8,337 KB.
Home Pages Are Considerably Heavier Than Inner Pages
| Percentile | Home Page | Inner Page |
|---|---|---|
| 10th | 589 KB | 534 KB |
| 25th | 1,361 KB | 1,041 KB |
| 50th | 2,710 KB | 1,866 KB |
| 75th | 5,422 KB | 3,267 KB |
| 90th | 11,406 KB | 6,109 KB |
At the median, the home page weighed approximately 2,710 KB compared with 1,866 KB for an inner page. HTTP Archive calculated that the median home page was approximately 45.8% heavier than the median inner page.
Images and JavaScript Dominate the Resource Budget
| Resource | Median Desktop Home Page | Median Mobile Home Page |
|---|---|---|
| HTML | 22 KB | 22 KB |
| CSS | 82 KB | 77 KB |
| Fonts | 139 KB | 122 KB |
| JavaScript | 697 KB | 632 KB |
| Images | 1,058 KB | 911 KB |
Hundreds of Kilobytes of JavaScript Can Be Unused
The quantity of JavaScript transferred is only one part of the issue. Lighthouse analysis within the Web Almanac dataset also measured JavaScript that was downloaded but unused during the tested page experience.
280 KB
median unused JavaScript on desktop
251 KB
median unused JavaScript on mobile
1,004 KB
desktop unused JavaScript at the 90th percentile
931 KB
mobile unused JavaScript at the 90th percentile
Unused JavaScript carries several costs. It must be downloaded, decompressed and parsed even when it does not contribute to the immediate page experience. Depending on implementation, additional compilation and execution work may also be involved.
Page Complexity Is Also Visible in Network Request Volume
| Percentile | Desktop Requests | Mobile Requests |
|---|---|---|
| 10th | 27 | 25 |
| 25th | 46 | 42 |
| 50th | 77 | 72 |
| 75th | 122 | 116 |
| 90th | 185 | 179 |
JavaScript Is the Most Frequently Requested Resource Type
The median desktop page requested 23 JavaScript files, while the median mobile page requested 22. At the 90th percentile, these figures increased to 67 and 65 respectively.
Resource Added
→
Network Request
→
Transfer
→
Decompression
→
Parsing
→
Execution / Rendering
→
User Experience
Resource Efficiency Is a Technical SEO Discipline
Technical optimisation should therefore examine not only whether resources work, but whether they are necessary. Large websites can accumulate scripts, CSS, plugins, tracking systems, widgets and media over years of development without periodically reviewing their continuing value.
Images
Resize appropriately, compress efficiently, use suitable formats and avoid downloading unnecessarily large assets.
JavaScript
Reduce unused code, control third-party scripts and avoid shipping functionality that is not required by the page.
CSS
Remove obsolete styles and reduce render-blocking resources where technically appropriate.
Third Parties
Measure the network and processing cost of analytics, advertising, consent, chat and other external services.
CGO Media Research Position
Technical Complexity Should Earn Its Place on the Page
The objective is not to make every website artificially small. Rich functionality, imagery and interactive experiences can provide legitimate value. The technical question is whether the bytes, requests and processing work required by each component justify that value.
Resource Value → Technical Cost → User Value → Search Accessibility → Performance Efficiency
Sources & Measurement Notes
HTTP Archive — Web Almanac 2025, Page Weight: page-weight distribution, home-page and inner-page weight, resource composition, JavaScript transfer, unused JavaScript and network-request volume.
JavaScript transfer measurements refer to compressed transferred JavaScript and do not include JavaScript embedded directly within HTML. Unused JavaScript measurements come from Lighthouse testing and refer to uncompressed JavaScript identified as unused during the test.
Page weight alone should not be treated as a direct ranking metric or as proof that a page will be slow. Performance also depends on resource prioritisation, caching, network conditions, server performance, device capability and execution cost.
The HTTP Archive figures are international rather than UK-only measurements. They provide large-scale technical benchmarks relevant to UK websites operating within the same browser, search and web infrastructure.
Statistics 81–90
Internal Linking, Hreflang & Technical Site Architecture
Technical site architecture determines how pages connect, how efficiently crawlers can move through a website and how clearly relationships between documents are communicated. Internal links remain one of the primary mechanisms through which websites expose these relationships.
For international websites, the architecture becomes more complex. Hreflang adds an additional technical layer by connecting equivalent language or regional versions and helping search engines identify which version is intended for a particular audience.
Statistic 81
The Median Desktop Page Contained 43 Internal Links
HTTP Archive’s 2025 analysis found a median of 43 outgoing links to the same site on desktop pages. Internal linking therefore forms a substantial part of the link architecture of a typical web page.
Statistic 82
The Median Mobile Page Contained 39 Internal Links
The corresponding median for mobile pages was 39 same-site outgoing links. Mobile pages therefore contained slightly fewer internal pathways than desktop pages at the median.
Statistic 83
90th-Percentile Desktop Pages Contained 174 Internal Links
At the 90th percentile, desktop pages contained 174 same-site outgoing links. Large navigation systems, ecommerce catalogues, news websites and enterprise platforms can therefore expose hundreds of internal pathways from a single page.
Statistic 84
90th-Percentile Mobile Pages Contained 161 Internal Links
The corresponding 90th-percentile mobile page contained 161 internal links. Although mobile interfaces are often simplified, complex websites still expose substantial internal navigation on smaller devices.
Statistic 85
The Median Page Contained Only 6 External Links
External linking was considerably lighter. The median page contained just 6 outgoing links to external websites on both desktop and mobile.
This compares with 43 same-site links on desktop and 39 on mobile at the same percentile.
Statistic 86
92.42% of Desktop Inner Pages Passed the Descriptive-Link Test
HTTP Archive reported that 92.42% of desktop inner pages passed Lighthouse’s test for descriptive link text. This indicates that most measured inner-page links provided meaningful anchor text rather than relying predominantly on ambiguous wording.
Statistic 87
93.45% of Mobile Inner Pages Passed the Descriptive-Link Test
Mobile inner pages performed slightly better, with 93.45% passing the descriptive-link-text audit. This was the strongest result among the home-page and inner-page segments reported by HTTP Archive.
Statistic 88
20.3% of Desktop Pages Included Hreflang in the Raw HTML
Approximately 20.3% of desktop pages contained hreflang implementation in the raw page data measured by HTTP Archive. The rendered measurement was slightly higher at 20.8%.
Statistic 89
19.7% of Mobile Pages Included Hreflang in the Raw HTML
On mobile, approximately 19.7% of pages contained hreflang in the raw measurement, rising slightly to 20.2% after rendering.
Statistic 90
Hreflang Adoption Approximately Doubled Year on Year
HTTP Archive reported that hreflang appeared on roughly 20% of pages in 2025, compared with approximately 9–10% in 2024. This represents approximately a doubling of measured adoption within a year.
Internal Links Form the Structural Network of a Website
The internal-link distribution demonstrates how much website architecture varies according to scale and complexity. A median desktop page contains 43 same-site links, but this increases to 89 at the 75th percentile and 174 at the 90th percentile.
This does not mean that more internal links automatically produce better SEO. The usefulness of an internal link depends on whether it creates a meaningful path between related resources, supports navigation and helps search systems understand how information is organised.
Internal Link Volume Rises Rapidly on Complex Pages
| Percentile | Desktop Same-Site Links | Mobile Same-Site Links |
|---|---|---|
| 10th | 7 | 6 |
| 25th | 19 | 17 |
| 50th | 43 | 39 |
| 75th | 89 | 82 |
| 90th | 174 | 161 |
Internal Links Greatly Outnumber External Links
| Percentile | Desktop External Links | Mobile External Links |
|---|---|---|
| 10th | 1 | 1 |
| 25th | 3 | 2 |
| 50th | 6 | 6 |
| 75th | 13 | 12 |
| 90th | 25 | 24 |
At the median, a desktop page contained approximately seven times as many same-site links as external links: 43 compared with 6. This reflects the central role internal links play in navigation and website structure.
Descriptive Anchor Text Is Now Common on Inner Pages
| Page Type | Desktop Pass Rate | Mobile Pass Rate |
|---|---|---|
| Home pages | 84.64% | 86.64% |
| Inner pages | 92.42% | 93.45% |
Inner pages performed materially better than home pages. One plausible explanation identified in the Web Almanac is that homepages rely more heavily on generic navigational and promotional calls to action, while inner pages more frequently contain contextual links embedded within descriptive content.
Link Qualification Remains Dominated by Nofollow
40.9%
pages using noopener
32.3%
pages using nofollow
0.5%
pages using sponsored
0.5%
pages using ugc
Nofollow remains much more widely used than the more specific sponsored and ugc relationship attributes. HTTP Archive found sponsored and ugc adoption remained at approximately 0.5% each in 2025.
Internationalisation Has Become a Significant Technical Layer
Around one in five measured pages now includes hreflang. This is particularly relevant to organisations operating across the UK, Europe and wider international markets because equivalent pages may target different languages, countries or regional audiences.
20.3%
desktop raw hreflang
20.8%
desktop rendered hreflang
19.7%
mobile raw hreflang
20.2%
mobile rendered hreflang
The difference between raw and rendered measurements is less than one percentage point. This suggests that most measured hreflang implementations remain available after rendering rather than being substantially altered or lost through client-side processing.
English Dominates Hreflang Implementation
| Hreflang Value | Desktop Home Pages | Mobile Home Pages |
|---|---|---|
| en | 7.8% | 7.4% |
| x-default | 7.2% | 6.9% |
| fr | 3.1% | 3.2% |
| de | 2.9% | 3.1% |
| es | 2.9% | 3.0% |
CGO Media Technical Architecture Model
Site Architecture Connects Discovery With Understanding
Navigation → Internal Links → Crawl Paths → Page Relationships → Language & Regional Relationships → Structural Understanding → Discovery
Sources & Measurement Notes
HTTP Archive — Web Almanac 2025, SEO: same-site outgoing links, external outgoing links, descriptive anchor-text pass rates, link relationship attributes and hreflang implementation.
The same-site link measurements count outgoing links pointing to the same website. They should not be interpreted as a recommended number of internal links for an individual page.
The descriptive-link measurements are Lighthouse audit pass rates. They indicate whether pages meet the audit criteria rather than proving that every individual link on a passing page is optimally written for SEO.
These figures are international rather than UK-only measurements. They provide large-scale technical architecture benchmarks relevant to UK and international websites.
Statistics 91–100
AI Crawlers, Machine Retrieval & Technical Discovery
Technical SEO is entering a broader machine-discovery environment. Websites are no longer accessed only by browsers and conventional search-engine crawlers. AI training crawlers, AI search crawlers and user-triggered retrieval systems now generate measurable levels of web activity.
The distinction is important because different crawlers can serve different purposes. Training, search retrieval and user-requested fetching should not automatically be treated as the same activity. The emerging technical requirement is therefore not simply to be “AI crawlable”, but to understand which systems can access content and why.
Statistic 91
AI Crawlers Generated 20% of Cloudflare Verified Bot Traffic in 2025
Cloudflare’s 2025 analysis found that AI crawlers generated approximately 20% of Verified Bot traffic. Search-engine crawlers remained larger at 40%, while SEO bots generated more than 13%.
Statistic 92
AI Bots Generated an Average 4.2% of HTML Requests
Across Cloudflare’s customer base, traffic from AI bots represented an average of 4.2% of HTML requests during 2025. Googlebot alone accounted for a further 4.5% in Cloudflare’s separate classification.
Statistic 93
GPTBot Generated Approximately 7.5% of Verified Bot Traffic in 2025
OpenAI’s GPTBot was one of the most active individual crawlers measured by Cloudflare during 2025, generating approximately 7.5% of Verified Bot traffic.
Googlebot remained considerably larger, generating more than 28% of Verified Bot traffic across the year.
Statistic 94
GPTBot’s Share of AI-Only Crawler Traffic Reached 28.1% in July 2025
When Cloudflare isolated crawlers classified as AI-related, GPTBot accounted for 28.1% of AI-only crawling traffic in July 2025, compared with 11.9% in July 2024.
That represented a 16.1-percentage-point increase over the twelve-month comparison.
Statistic 95
ClaudeBot Accounted for 23.3% of AI-Only Crawler Traffic in July 2025
Anthropic’s ClaudeBot represented approximately 23.3% of Cloudflare’s measured AI-only crawler traffic in July 2025. Its share had increased from 15.0% in July 2024.
Statistic 96
79% of AI Crawling Activity Was Training-Related by July 2025
Cloudflare classified approximately 79% of AI crawling activity in July 2025 as training-related. This was up from 72% in July 2024.
Search-related AI crawling represented 17%, while user-action crawling accounted for approximately 3.2%.
Statistic 97
ChatGPT-User Crawling Requests Increased by 2,825% in One Year
In Cloudflare’s May 2024 to May 2025 comparison, requests attributed to ChatGPT-User increased by 2,825%. Its share of the combined AI and search crawler traffic measured in the study increased from approximately 0.1% to 1.3%.
Statistic 98
GPTBot Crawling Requests Increased by 305% Between May 2024 and May 2025
Cloudflare measured a 305% year-on-year increase in GPTBot requests between May 2024 and May 2025. Its share of combined AI and search crawler traffic increased from 2.2% to 7.7%.
Statistic 99
Anthropic Recorded Around 38,000 Crawls Per Referral in July 2025
Cloudflare’s crawl-to-refer analysis measured approximately 38,066 Anthropic crawls for every referral visit in July 2025. The ratio had fallen substantially from approximately 286,930:1 in January but remained far above the ratios measured for conventional search platforms.
Statistic 100
OpenAI Recorded Approximately 1,091 Crawls Per Referral in July 2025
Cloudflare measured an OpenAI crawl-to-refer ratio of approximately 1,091:1 in July 2025. Across January to July, the average was approximately 1,438 crawls for every referral.
For comparison, Google’s average crawl-to-refer ratio over the same January-to-July dataset was approximately 11.8:1.
AI Crawling Is Now a Measurable Part of Web Infrastructure
The final ten statistics demonstrate why AI retrieval can no longer be treated solely as a content or marketing subject. AI systems now generate measurable crawling activity at infrastructure level, and website operators increasingly need to distinguish between search indexing, model training and user-triggered retrieval.
The distinction between these activities is especially important. A crawler used to gather training data does not necessarily perform the same function as a crawler retrieving information in response to a current user query. Technical policies should therefore be based on the documented purpose of individual user agents rather than treating every AI-related bot as equivalent.
The AI Crawler Landscape Is Changing Rapidly
| AI Crawler | July 2024 Share | July 2025 Share | Change |
|---|---|---|---|
| GPTBot | 11.9% | 28.1% | +16.1 pp |
| ClaudeBot | 15.0% | 23.3% | +8.3 pp |
| Meta-ExternalAgent | 2.4% | 17.7% | +15.3 pp |
| Amazonbot | 26.4% | 14.1% | −12.3 pp |
| Bytespider | 37.3% | 5.8% | −31.5 pp |
| ChatGPT-User | 0.2% | 2.4% | +2.2 pp |
| OAI-SearchBot | 0% | 2.2% | +2.2 pp |
Not All AI Crawling Has the Same Purpose
79%
Training
Share of AI crawling classified as training-related in July 2025.
17%
Search
Share classified as AI search-related crawling.
3.2%
User Action
Share associated with user-triggered retrieval activity.
The technical implications differ. An organisation may choose different access policies for model-training crawlers and retrieval systems used to answer active user requests. That makes crawler identification and robots.txt governance increasingly important components of technical search management.
AI Crawler Management Is Already Visible in Robots.txt
HTTP Archive’s separate 2025 SEO dataset confirms the same structural change. Multiple AI-related user agents are now explicitly named in robots.txt files across several percent of measured websites.
| AI-Related User Agent | Desktop Robots.txt | Mobile Robots.txt |
|---|---|---|
| GPTBot | 4.5% | 4.2% |
| ClaudeBot | 3.6% | 3.4% |
| CCBot | 3.5% | 3.2% |
| Google-Extended | 3.4% | 3.0% |
| PerplexityBot | 2.8% | 2.7% |
| ChatGPT-User | 2.8% | 2.5% |
The presence of these user agents does not tell us whether access is allowed or blocked. It demonstrates that website operators are increasingly creating crawler-specific policies for AI systems.
AI Crawling and Referral Traffic Are Not Proportional
| Platform | Average Crawl-to-Refer Ratio Jan–Jul 2025 |
|---|---|
| Anthropic | 147,754.7 : 1 |
| OpenAI | 1,437.8 : 1 |
| Perplexity | 172.4 : 1 |
| Microsoft | 42.3 : 1 |
| 11.8 : 1 |
These ratios should not be interpreted as conversion rates or as measures of the value of individual platforms. They compare observed HTML crawling requests with referral requests and can change substantially as crawler activity and user behaviour change.
Where Does llms.txt Fit?
The emergence of llms.txt is relevant to technical AI-search experimentation, but it should not be presented as an established AI ranking or citation standard. Unlike robots.txt, XML sitemaps and established search-engine crawling controls, there is not yet sufficient evidence to claim that an llms.txt file directly increases AI citations, recommendations or visibility.
For organisations experimenting with llms.txt and llms-full.txt, the files are better treated as an additional machine-readable discovery layer rather than a replacement for crawlable HTML, internal linking, structured data, canonicalisation, sitemaps or established crawler controls.
CGO Media Technical Discovery Model
Technical SEO Now Supports a Broader Machine Discovery Environment
Crawler Access → Retrieval → Rendering → Indexability → Entity Clarity → Content Extraction → Machine Understanding → Discovery Eligibility
Technical SEO Is Becoming Technical Discovery Infrastructure
Traditional technical SEO remains essential. Pages still need stable URLs, crawlable links, appropriate indexing controls, coherent canonical signals, efficient delivery and content that can be reliably rendered and extracted.
What has changed is the number of machine systems interacting with that infrastructure. Search crawlers, AI training bots, AI search crawlers and user-triggered retrieval systems may all encounter the same website for different purposes.
The technical SEO function therefore increasingly extends from search-engine accessibility towards controlled, measurable and machine-readable discovery across a broader search ecosystem.
Sources & Measurement Notes
Cloudflare Radar / Cloudflare 2025 research: AI crawler traffic share, Verified Bot traffic, crawler growth, AI crawling by purpose, AI-only crawler shares and crawl-to-refer ratios.
HTTP Archive — Web Almanac 2025, SEO: prevalence of AI-related user agents explicitly named in robots.txt files, including GPTBot, ClaudeBot, CCBot, Google-Extended, PerplexityBot and ChatGPT-User.
Crawler statistics should be interpreted within the measurement methodology of each dataset. Cloudflare measurements describe traffic observed across its network and customer base; HTTP Archive measurements describe the websites contained within its large-scale crawl dataset. Neither should automatically be interpreted as the precise share of the entire global web.
The AI crawler measurements are international rather than UK-only. They provide current infrastructure benchmarks relevant to UK organisations operating within the same global AI, search and web-crawling ecosystem.
Research Analysis
What the 100 Technical SEO Statistics Tell Us About the Web in 2026
Taken together, these 100 statistics show that technical SEO in 2026 extends considerably beyond conventional crawl-error detection. Performance, rendering, page weight, JavaScript, infrastructure, internal architecture and machine access increasingly operate as parts of the same technical discovery system.
The research also reveals an important contradiction. Web infrastructure continues to improve while web pages themselves continue to become more technically demanding. HTTP/2, HTTP/3, CDNs, modern compression and improved browser capabilities can make resource delivery more efficient, yet pages continue to carry substantial image and JavaScript payloads.
For UK organisations, the practical issue is therefore not whether one individual metric is a ranking factor. The more important question is whether the technical environment allows search engines, AI retrieval systems and users to discover, retrieve, process and understand information efficiently and consistently.
1. Passing Core Web Vitals Is Still Far From Universal
The Core Web Vitals data provides one of the clearest high-level indicators of the remaining performance gap. In the July 2026 Chrome UX Report dataset, 55.7% of origins achieved good Core Web Vitals overall.
55.7%
good Core Web Vitals overall
68.3%
good LCP
85.7%
good INP
81.6%
good CLS
LCP remains the weakest of the three Core Web Vitals in the headline CrUX data. This reinforces the importance of server response, resource prioritisation, image delivery and above-the-fold rendering within technical performance programmes.
2. Mobile Remains the Harder Technical Environment
Across multiple datasets, mobile performance remains more difficult than desktop performance. This is particularly visible in loading performance and JavaScript processing, where device capability and network conditions can magnify inefficient implementation.
Responsive layout alone should therefore not be regarded as sufficient mobile optimisation. A page can adapt correctly to a small screen while still transferring excessive resources, performing substantial main-thread work or delaying important content.
3. Images and JavaScript Continue to Dominate Resource Budgets
The median mobile home page in the analysed HTTP Archive dataset transferred approximately 911 KB of images, while the corresponding desktop home page transferred approximately 1,058 KB.
JavaScript adds another substantial technical layer. The median page transferred hundreds of kilobytes of JavaScript, while Lighthouse analysis also identified hundreds of kilobytes of unused JavaScript at the median.
The Technical Cost Is Larger Than the Download
JavaScript may need to be transferred, decompressed, parsed, compiled and executed. Images may need to be downloaded, decoded and rendered. Technical efficiency therefore depends on both network cost and processing cost.
4. Faster Infrastructure Is Competing With Increasing Page Complexity
The infrastructure layer is becoming more sophisticated. HTTP/2 dominates CDN-served HTML within the analysed dataset, HTTP/3 has established a meaningful share, Brotli adoption is widespread and newer compression technologies are emerging.
At the same time, median page weight remains measured in megabytes and high-percentile pages can exceed 8 MB or 9 MB. The resulting pattern is clear: part of the performance benefit created by improved infrastructure can be consumed by increasing front-end complexity.
5. Technical Site Architecture Remains Fundamental
The median desktop page contained 43 same-site outgoing links in HTTP Archive’s 2025 SEO analysis, increasing to 174 at the 90th percentile. Mobile pages showed a similar pattern.
These figures illustrate how internal linking operates as structural infrastructure rather than simply an on-page optimisation technique. Navigation, contextual links, taxonomy and related-content relationships collectively create pathways through which users and crawlers encounter information.
For international organisations, hreflang adds another layer. Approximately one-fifth of pages in the analysed dataset contained hreflang, demonstrating the scale at which language and regional relationships now need to be technically managed.
6. AI Crawling Has Become Part of Technical Web Operations
AI-related crawling is now sufficiently large to be measurable independently within major web infrastructure datasets. Cloudflare reported that AI crawlers accounted for approximately 20% of Verified Bot traffic in its 2025 analysis and that AI bots represented an average 4.2% of HTML requests.
The important development is not simply the volume. Different AI user agents are associated with training, search and user-triggered retrieval. Website owners therefore increasingly need to understand which machine systems are accessing their content and what access policies they want to apply.
7. Crawl Volume Does Not Equal Referral Value
Cloudflare’s crawl-to-refer research demonstrates that crawling activity and referral traffic can differ by orders of magnitude. This makes crawler log volume an incomplete measure of the commercial or discovery value produced by a platform.
Organisations measuring AI visibility should therefore distinguish machine access from citations, referral sessions, recommendation visibility, conversions and commercial outcomes.
8. Technical SEO Is Expanding Into Technical Discovery
The evidence across the 100 statistics suggests that technical SEO should increasingly be viewed as the engineering layer supporting digital discovery. Search engines remain central, but they are no longer the only machine systems retrieving and processing website information.
CGO Media Research Position
Technical SEO Is Becoming Technical Discovery Infrastructure
Access → Crawlability → Retrieval → Rendering → Indexability → Architecture → Machine Understanding → Search & AI Discovery
Key Conclusions
Technical SEO Priorities for UK Organisations in 2026
01. Measure Real Users
Use field data such as CrUX alongside laboratory testing. Real-user performance and controlled diagnostic testing answer different questions.
02. Prioritise LCP
LCP remains the weakest headline Core Web Vital. Review server response, LCP resource discovery, image optimisation and render-blocking dependencies.
03. Control JavaScript
Audit JavaScript by business and user value rather than allowing frameworks, plugins and third-party services to accumulate indefinitely.
04. Reduce Image Cost
Images remain one of the largest contributors to page weight. Format, dimensions, responsive delivery, compression and loading priority all matter.
05. Audit Infrastructure
DNS, CDN configuration, compression, HTTP protocols, caching and server performance should form part of mature technical SEO auditing.
06. Protect Architecture
Maintain crawlable internal links, coherent taxonomies, descriptive anchor text and technically sound international relationships.
07. Monitor AI Crawlers
Understand the difference between AI training crawlers, AI search crawlers and user-triggered retrieval before implementing access policies.
08. Measure Discovery Outcomes
Crawler activity alone is not an outcome. Connect technical monitoring with organic visibility, AI citations, referral traffic, conversions and business performance.
Research Limitations
How These Technical SEO Statistics Should Be Interpreted
This research combines multiple datasets because no single source measures every aspect of technical SEO. The resulting statistics should therefore be interpreted according to the methodology, population and date of the original source.
UK Versus International Data
UK-specific technical web datasets are limited. Where credible UK-specific evidence was unavailable, this research uses international datasets and identifies them as such. These figures should not be represented as measurements of UK websites alone.
Field Data Versus Laboratory Data
Chrome UX Report measurements represent real-user field data from eligible Chrome users and origins. HTTP Archive and Lighthouse measurements may use controlled testing environments. These approaches are complementary but are not directly interchangeable.
Correlation Is Not Ranking Causation
The presence of a technical characteristic on high-performing websites does not prove that the characteristic caused higher rankings. This research should not be interpreted as assigning independent Google ranking weight to every technical metric discussed.
AI Crawler Data Is Evolving Quickly
AI crawler volumes, user agents, platform policies and access patterns can change rapidly. Measurements from 2025 provide evidence of the direction and scale of activity but should not be assumed to remain static throughout 2026.
Derived Statistics
Where CGO Media has calculated a percentage difference, complement, ratio or change from published source values, the result is identified as a CGO Media Calculation. Derived values should be read alongside the original measurements from which they were calculated.
Research Methodology
How CGO Media Compiled the Technical SEO Statistics UK 2026
CGO Media reviewed large-scale web-performance, technical SEO and crawler datasets relevant to the technical conditions affecting search discovery in 2026. Priority was given to primary sources, large observational datasets and documentation produced by organisations responsible for the underlying technologies.
Statistics were selected for their relevance to crawlability, rendering, user experience, web performance, infrastructure, resource efficiency, site architecture and emerging AI-mediated retrieval.
Primary Source Groups
| Source | Primary Use in This Research |
|---|---|
| Chrome UX Report | Real-world Core Web Vitals and browser performance measurements. |
| Google / web.dev | Core Web Vitals definitions, thresholds and technical guidance. |
| HTTP Archive / Web Almanac | Page weight, JavaScript, images, requests, performance, CDN infrastructure, compression, internal links, hreflang and robots.txt measurements. |
| Lighthouse | Laboratory audits including resource efficiency, unused JavaScript, link text and compression. |
| Cloudflare Radar / Cloudflare Research | Bot traffic, AI crawler activity, crawler purpose and crawl-to-referral measurements. |
Statistic Selection Criteria
A statistic was included where it provided a measurable observation relevant to technical search performance or machine discovery. General technical recommendations were not counted as statistics unless supported by a numerical measurement.
Where the same underlying measurement could be expressed in multiple ways, CGO Media sought to avoid unnecessary duplication. Calculated values were included only where they added interpretive value and are labelled accordingly.
Source dates, device categories, percentiles and measurement contexts have been retained where they materially affect interpretation.
Principal References
Google Chrome for Developers. Chrome UX Report documentation and release notes. Used for current Core Web Vitals field measurements and origin-level performance data.
Google web.dev. Core Web Vitals documentation. Used for LCP, INP and CLS thresholds, measurement definitions and interpretation.
HTTP Archive. Web Almanac 2025 — Performance. Used for web-performance distributions and technical performance characteristics.
HTTP Archive. Web Almanac 2025 — Page Weight. Used for page weight, resource composition, JavaScript, image payloads, network requests and resource-efficiency measurements.
HTTP Archive. Web Almanac 2025 — CDN. Used for HTTP protocol adoption, CDN delivery, DNS performance and compression measurements.
HTTP Archive. Web Almanac 2025 — SEO. Used for internal links, external links, anchor-text audits, hreflang, link attributes, robots.txt and AI-related crawler controls.
Cloudflare. Cloudflare Radar and 2025 AI crawler research. Used for Verified Bot traffic, AI crawler shares, crawler growth, crawler-purpose classifications and crawl-to-refer measurements.
Conclusion
Technical SEO in 2026 Is the Infrastructure of Search and AI Discovery
The 100 statistics examined in this research show a web that is simultaneously becoming more capable and more technically complex. Browsers, CDNs, compression technologies and network protocols continue to improve, yet page weight, JavaScript and resource demands remain substantial.
At the same time, the machines accessing websites are changing. Traditional search crawlers now operate alongside AI training crawlers, AI search systems and user-triggered retrieval agents. This expands the scope of technical search management beyond conventional indexation alone.
For UK businesses and organisations, the objective should be to create a technical environment in which authoritative information can be discovered, retrieved, rendered and interpreted reliably—whether the requesting system is a browser, a search engine or an AI-mediated discovery platform.
Crawlability + Performance + Architecture + Machine Accessibility + Technical Clarity = Stronger Discovery Infrastructure
Research compiled by the CGO Media Research Team
Technical SEO Statistics UK 2026 · CGO Media · cgomedia.com
