# Google Lighthouse only tests one page. Your website has hundreds.

> Every Lighthouse run audits a single URL. Here's why a green homepage score hides slow templates, and how to audit every page of your site instead.

Published: 2026-11-15 · Author: AiroPages

Google Lighthouse is the most widely used way to measure page speed, accessibility and SEO basics. It is also limited in a way many teams never notice: **every Lighthouse run tests exactly one URL.** Chrome DevTools, PageSpeed Insights and the Lighthouse CLI all audit the single page you point them at, on a single device, at a single moment. If you only ever test your homepage, you are measuring the one page on your site that least resembles the others.

This article explains what that limitation means in practice, why the homepage is a poor stand-in for the rest of your site, how Google actually evaluates performance across many pages, and what a proper whole-site audit looks like, whether you script it yourself or use a hosted tool.

## What Lighthouse actually measures

Lighthouse is an open-source auditing tool built by Google's Chrome team. You give it a URL, it loads that page in Chrome under controlled conditions, and it reports scores from 0 to 100 in four categories: Performance, Accessibility, Best Practices and SEO. Since Lighthouse 13.3 there is also a beta category, [Agentic Browsing](/glossary/agentic-browsing), that checks how usable a page is for AI agents.

The Performance score is built from five lab metrics: [Largest Contentful Paint](/glossary/lcp), [Total Blocking Time](/glossary/tbt), [Cumulative Layout Shift](/glossary/cls), [First Contentful Paint](/glossary/fcp) and [Speed Index](/glossary/speed-index). We cover the weighting in detail in [how the Lighthouse performance score is calculated](/blog/how-the-lighthouse-performance-score-is-calculated).

You can run Lighthouse in four common ways:

- **Chrome DevTools**: the Lighthouse panel audits the tab you have open.
- **PageSpeed Insights**: Google's web tool runs Lighthouse on Google's servers and adds real-user data from the [Chrome UX Report](/glossary/crux). See [Lighthouse vs PageSpeed Insights](/blog/lighthouse-vs-pagespeed-insights) for the differences.
- **The Lighthouse CLI and Node module**: for scripting and automation.
- **Lighthouse CI**: runs Lighthouse against a list of URLs you configure, usually inside a build pipeline.

All four have one thing in common. Each run takes one URL and produces one report. None of them discovers the other pages on your site, and none of them tells you how the site as a whole is doing.

## Lighthouse tests one page by design

The one-URL design is not a bug. Lighthouse is a page-level diagnostic: it records a detailed trace of one page load and explains exactly which resources, scripts and layout changes made that page slow. That depth is what makes it useful. It would be impossible to show that level of detail for a thousand pages in one report.

The problem is not the tool. The problem is how it gets used. In most teams the workflow looks like this:

1. Someone opens PageSpeed Insights.
2. They paste in the homepage.
3. The score is 92, so performance is "fine".

That conclusion only holds for the homepage. It says nothing about the hundreds of other URLs that real visitors and search engines see every day.

## Why your homepage is the least representative page you have

On most websites the homepage is the best-performing page, for predictable reasons.

**It gets the most attention.** The homepage is the page designers polish, developers optimize and stakeholders check. When someone notices a slow site, the homepage is what gets fixed.

**It is cached and warm.** High-traffic pages sit in CDN and server caches. Deep pages, such as a blog post from two years ago or a product in a small category, are more likely to be served cold, with a slower server response ([TTFB](/glossary/ttfb)).

**It is built from a different template.** A homepage is usually a one-off layout. Your articles, product pages, category pages, docs and landing pages each have their own template, with their own images, fonts, scripts and widgets.

**Inner pages carry the heavy stuff.** The things that hurt performance most tend to live on inner pages:

- Large hero images and inline images in articles, often uploaded at full camera resolution
- Video embeds, maps, social embeds and comment systems
- Product galleries, reviews widgets, size guides and recommendation carousels
- Ad slots and affiliate scripts on content pages
- CMS plugins and page-builder blocks that load their own CSS and JavaScript
- Tables, code blocks and syntax highlighters on docs pages

**Inner pages are where visitors land.** For most content and e-commerce sites, search visitors arrive on articles, category pages and product pages far more often than on the homepage. Check the landing-page report in your analytics to see your own split. If most of your organic traffic lands on blog posts, the blog post template is the page that matters most, and it is the one a homepage audit never sees.

### What a single-page audit typically misses

| Page type | Problems a homepage audit won't show |
| --- | --- |
| Blog posts and articles | Oversized or unsized images, embeds, ad scripts, web fonts loaded late, layout shift from injected widgets |
| Product pages | Image galleries, reviews and recommendation widgets, third-party personalization scripts, heavy JavaScript bundles |
| Category and search pages | Long image grids, filters that re-render on every click, infinite scroll, pagination issues |
| Landing pages | Page-builder bloat, A/B testing scripts, chat widgets, tracking pixels |
| Docs and help pages | Large DOM size, syntax highlighting, search widgets, missing accessible names on navigation |
| Old or rarely visited pages | Cold caches, outdated markup, broken images, legacy plugins nobody remembers installing |

The same is true outside performance. Accessibility problems such as low colour contrast, images without alt text or buttons without labels usually come from shared components. If the blog template has an unlabeled share button, every article fails that audit, and a homepage test will never mention it. We cover this in [accessibility at scale](/blog/accessibility-at-scale).

## How Google evaluates performance across your site

Google does not rank your website on one homepage score. Its page experience signals are based on [Core Web Vitals](/glossary/core-web-vitals): LCP, [INP](/glossary/inp) and CLS, measured from real Chrome users and reported through the Chrome UX Report. A page passes when at least 75 percent of visits meet the "good" threshold over the previous 28 days: LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less.

Three details matter for whole-site performance:

1. **Evaluation is page by page.** Field data is collected for individual URLs where there is enough traffic. A fast homepage does not lend its score to a slow article.
2. **Similar pages are grouped.** Search Console's Core Web Vitals report groups URLs that look alike, which in practice usually means pages built from the same template. When a template fails, a whole group of URLs is flagged together.
3. **Origin data fills the gaps.** When a page does not have enough real-user data of its own, tools fall back to origin-level data for the whole site. Slow inner pages pull that origin number down for every page that relies on it.

Lighthouse scores themselves are lab data, not a ranking signal. But the problems Lighthouse finds, such as a slow LCP image, a long main-thread task or an unsized banner, are the same problems that show up in field data. That is why running Lighthouse on the pages that real visitors use is the practical way to improve the numbers Google actually looks at. For more on the difference, read [lab data vs field data](/blog/lab-data-vs-field-data).

## An example: the green homepage that hides a red blog

Here is an illustrative example of how this plays out. Imagine a company site with about 400 indexable pages:

- 1 homepage
- 12 product and pricing pages
- 300 blog posts
- 60 docs pages
- around 25 landing pages

The marketing team checks the homepage in PageSpeed Insights every month. It scores 94 on mobile. Everyone assumes the site is in good shape.

Now run Lighthouse on every page instead. The results might look like this:

| Template | Pages | Typical mobile performance | Main issue |
| --- | --- | --- | --- |
| Homepage | 1 | 94 | None significant |
| Product pages | 12 | 78 | Third-party chat widget blocks the main thread |
| Docs | 60 | 85 | Large DOM from an expanded navigation tree |
| Landing pages | 25 | 63 | Page-builder CSS and an A/B testing script |
| Blog posts | 300 | 41 | 2 MB hero images without width and height, plus a late-loading font |

Three quarters of the site is in the red, and it is the part that receives most of the search traffic. Not one of these problems appears in the homepage report.

The good news is in the last column. The 300 failing blog posts do not have 300 different problems. They share one template, so they share the same two problems. Resize and set dimensions on the hero image, preload the font, and every blog post improves at once. This is why grouping results by template matters so much: it turns an overwhelming list of failures into a short list of fixes. We go deeper on this in [template-level fixes](/blog/template-level-fixes).

## The ways to audit a whole site

If one URL per run is the limit, the answer is to run Lighthouse once per URL. There are several ways to do that, each with trade-offs.

| Method | Setup | Effort per audit | Good for | Watch out for |
| --- | --- | --- | --- | --- |
| PageSpeed Insights, one URL at a time | None | Very high | Spot-checking a few pages | Impossible to keep up with beyond a handful of pages |
| PageSpeed Insights API script | API key and a script | Medium | Developers who want field and lab data together | API quotas, error handling, stitching results together |
| Lighthouse CLI loop | Node.js, Chrome, a script | Medium | Full control over settings | Slow when run one page at a time, results vary with your machine's load |
| Lighthouse CI | CI pipeline configuration | Low once set up | Catching regressions on a fixed list of key URLs | Only tests the URLs you list, not every page |
| Hosted bulk tool | None | Low | Every page, both devices, with history and grouping | Cost, and knowing which pages are included |

### Doing it yourself with the Lighthouse CLI

If you are comfortable on the command line, a basic whole-site audit is a short script. First, get the list of URLs from your sitemap:

```bash
curl -s https://example.com/sitemap.xml \
  | grep -o '<loc>[^<]*</loc>' \
  | sed -e 's/<loc>//' -e 's/<\/loc>//' > urls.txt
```

Then run Lighthouse on each one, for mobile and desktop:

```bash
mkdir -p reports
while read -r url; do
  name=$(echo "$url" | sed 's#https\?://##; s#[^a-zA-Z0-9]#_#g')
  npx lighthouse "$url" --quiet --output=json \
    --output-path="reports/${name}-mobile.json" \
    --chrome-flags="--headless=new"
  npx lighthouse "$url" --quiet --output=json --preset=desktop \
    --output-path="reports/${name}-desktop.json" \
    --chrome-flags="--headless=new"
done < urls.txt
```

This works, but you will quickly run into the practical problems:

- **Discovery.** Sitemaps are often incomplete or include pages you don't want to test (redirects, noindex pages, pagination). Large sites split sitemaps into an index of several files.
- **Time.** At 10 to 30 seconds per run, two runs per page, a few hundred pages takes hours on one machine.
- **Consistency.** Running other programs while the script runs, or running several Lighthouse processes on one small machine, skews the results. Read [why Lighthouse scores change](/blog/why-lighthouse-scores-change) for the details.
- **Making sense of it.** You now have hundreds of JSON files. To find what to fix, you need to extract the failing audits from each one and work out which problems repeat across which pages.
- **Keeping it up.** A one-off audit is a snapshot. Sites change with every deploy, so you need to repeat it and compare runs. See [how to monitor site speed after every deploy](/blog/monitor-site-speed-after-every-deploy).

Our guide on [running Lighthouse on every page](/guides/run-lighthouse-on-every-page) walks through these steps in more detail, including how to handle sitemap indexes.

## What a good whole-site audit looks like

Whichever method you choose, a whole-site Lighthouse audit is only useful if it does these things:

1. **Finds every indexable page.** Read the sitemaps and robots.txt, crawl links when sitemaps are missing, and skip noindex pages, duplicates and pagination, so you test what search engines actually index.
2. **Tests mobile and desktop.** Google indexes the mobile version of your pages first, and mobile scores are usually much lower. See [why your mobile score is lower than desktop](/blog/mobile-vs-desktop-lighthouse-scores).
3. **Uses consistent settings.** Same Lighthouse version, same throttling, same region, so results are comparable across pages and over time.
4. **Groups issues by template.** Pages built from the same template fail the same way. One grouped issue with every affected URL listed is far more useful than the same audit failing 300 times.
5. **Ranks by impact.** Order issues by how many pages they affect and how much time they cost, so the first fix is the one that helps the most visitors.
6. **Shows field data next to lab data.** Where Google has real-user data, show it alongside the lab results, so you can tell the difference between a lab problem and a problem real visitors feel.
7. **Explains fixes in plain language.** Developers need the technical detail. Everyone else needs to know what is wrong and why it matters.
8. **Tracks changes over time.** Scheduled re-scans and alerts catch regressions before they spread.

## A step-by-step plan for your first whole-site audit

If you have never looked beyond the homepage, this is a practical order of work that keeps the job manageable.

1. **Make an inventory.** List every indexable URL. Your sitemap is the starting point; compare its size with the number of pages Google reports as indexed in Search Console. Large gaps in either direction are worth investigating on their own.
2. **Name your templates.** Group URLs by pattern: `/blog/*`, `/products/*`, `/category/*`, `/docs/*`, landing pages, and one-off pages like the homepage and pricing. Most sites have between five and fifteen templates, no matter how many pages they have.
3. **Take a baseline on both devices.** Run Lighthouse on every page, mobile and desktop, with the same settings. Record the date and the Lighthouse version, because scores shift slightly between versions.
4. **Triage by template.** For each template, note the typical score, the most common failing audits and how many pages are affected. A template where every page fails the same audit is your best opportunity.
5. **Fix the template, not the page.** Make the change once in the shared component: resize and set dimensions on the hero image, defer the third-party script, add the missing label to the share button.
6. **Verify everywhere.** Re-scan every page that had the issue, not just one example. Fixes often miss pages that use an older variant of the template or override the shared component.
7. **Watch the field data.** Lab results improve immediately. Real-user data in the Chrome UX Report is a rolling 28-day window, so expect Core Web Vitals in Search Console to catch up over the following weeks.
8. **Schedule the next scan.** Performance regresses quietly. Decide how often you will repeat the audit and who looks at the results.

## Which pages to fix first

Not every slow page deserves the same urgency. A simple way to prioritize is to score each problem on three things:

- **Reach**: how many pages share the problem. A template issue affecting 300 articles beats a one-off problem on a single page.
- **Traffic**: how many visitors land on those pages. Use the landing-page report in your analytics, or the pages report in Search Console, to see which templates bring people in.
- **Severity**: how far the pages are from passing. A template whose mobile LCP is 6 seconds needs attention before one sitting at 2.7 seconds.

Multiply them, roughly, and work from the top. In practice this almost always points to the article or product template first, and the homepage last.

Two exceptions are worth making. First, fix anything that breaks a page outright (errors, blocked resources, pages that never paint) regardless of reach. Second, give extra weight to pages that make money: checkout steps, pricing, signup and lead forms often have little search traffic but matter more per visit than anything else.

## How often to audit the whole site

The right rhythm depends on how often your site changes:

| Your site | Suggested whole-site scan |
| --- | --- |
| Rarely changes (brochure site, small portfolio) | Monthly, plus after any redesign or new plugin |
| Regular content publishing (blog, news, docs) | Weekly |
| Frequent deploys or many contributors (e-commerce, SaaS, large content teams) | Weekly or daily, plus checks on key pages in CI |
| Agencies managing client sites | Weekly per client, with a monthly report |

Whatever the rhythm, scan after the changes that most often cause regressions: theme or framework updates, new marketing or analytics tags, new embeds or widgets, image pipeline changes and CDN or hosting changes.

## It's not only about speed

The one-page problem applies to every Lighthouse category, not just Performance.

**Accessibility.** Lighthouse's accessibility audits catch problems such as low colour contrast, missing alt text, unlabeled buttons and links, form fields without labels and skipped heading levels. Most of these come from shared components, so they repeat on every page that uses them. Automated checks only catch part of the picture and manual testing still matters, but running them on every page is the cheapest way to find the repeat offenders.

**SEO.** The SEO category checks basics such as whether a page can be indexed, whether it has a title and meta description, whether links have descriptive text and whether the canonical and hreflang tags are valid. A noindex tag left on a template, or a missing meta description on 200 product pages, only shows up when you test those pages. See [the technical SEO checks Lighthouse runs](/blog/technical-seo-checks-lighthouse-runs).

**AI agents.** The beta Agentic Browsing category looks at how easily AI agents can read and use a page, including the accessibility tree and site-level files such as llms.txt. Accessible, well-structured templates help both people using assistive technology and the AI assistants that increasingly summarize and act on websites. Read [getting your site ready for AI agents](/blog/get-your-site-ready-for-ai-agents).

## How AiroPages audits every page

We built AiroPages because we kept running into exactly this problem. It is a hosted tool that runs Lighthouse on every page of your site, with no CLI or setup.

You enter a domain or a sitemap URL. AiroPages reads your sitemaps and robots.txt, or crawls the site, and skips noindex pages, duplicates and pagination. You can tick and untick pages before you scan. Every page is then tested on mobile and desktop with the same settings PageSpeed Insights uses, several pages at a time on dedicated scan engines, and results appear as each page finishes.

Instead of hundreds of separate reports, you get identical issues grouped by template, ranked by how many pages they affect, with a plain-English explanation of each problem and a technical fix for your developer. You can copy the fixes as a prompt for Claude Code, Cursor or Copilot, or connect a coding agent through [MCP](/docs/mcp) so it can read the issues and re-scan the pages after fixing them. Chrome UX Report field data appears next to the lab scores where Google has it, and [scheduled scans](/features/monitoring) email you when scores drop.

You can pay once for a single report, starting at $5, or subscribe from $19.99 a month for regular re-scans. You see the exact price for your site before you pay, and any page that fails to scan is credited back as a URL scan. See [pricing](/pricing) for the details.

## Common objections

**"Our homepage is our most important page."** It may be your most visited single page, but it is rarely where most search visitors land, and it is rarely where the slow templates are. If 300 articles drive your organic traffic, those 300 articles are collectively far more important than one homepage.

**"PageSpeed Insights already shows data for our whole site."** It can show origin-level field data, which is an average across every page with enough traffic. That tells you the site has a problem, but not which pages or templates cause it, and it gives you no lab diagnostics for anything except the URL you tested.

**"We already run Lighthouse CI."** That is a great safeguard for the URLs you configured, usually a handful of key pages. It does not cover the long tail of pages built from the same templates, or new pages added after the configuration was written. Use CI for fast feedback on key pages and a full-site scan for coverage.

**"Our pages all use the same theme, so testing one is enough."** Themes share a header and footer, but content differs. An article with a video embed, a product with a 12-image gallery and a landing page with three tracking scripts behave very differently on the same theme. You only find the outliers by testing them.

## The bottom line

Lighthouse is an excellent tool for understanding why one page is slow. It was never designed to tell you how a whole website performs, and a good homepage score is not evidence that the rest of your site is fast.

To get a true picture, test every indexable page on mobile and desktop, group the results by template, and fix the problems that affect the most pages first. Do it once to find the big wins, then keep doing it after every significant change, because performance problems come back with every new plugin, script and image.

If you want to do it without building the tooling yourself, [enter your site on AiroPages](/) to see your page count and the exact price of a full report. For a broader look at the options, read our guide to [bulk PageSpeed testing without the CLI](/guides/bulk-pagespeed-testing-without-cli).