How to run Lighthouse on every page of your website

Lighthouse tests one URL at a time. That is fine for a homepage, but most sites have dozens or thousands of pages, and the slow ones are rarely the ones you check by hand. This guide covers how to audit all of them.

Step 1: Get a complete list of URLs

Your sitemap is the best starting point because it lists the pages you want search engines to index. Look for it at /sitemap.xml, /sitemap_index.xml, or in the Sitemap: line of /robots.txt. Large sites often use a sitemap index that points to several child sitemaps, sometimes gzipped.

Before testing, clean the list:

• Remove URLs that redirect or return errors.
• Remove pages marked noindex, since they will not rank anyway.
• Drop pagination (/page/2) and query-string variants that show the same content.
• Collapse duplicates that share a canonical URL.

If you have no sitemap, a shallow crawl of internal links from the homepage will find most pages.

Step 2: Decide on devices and runs

By default, Lighthouse emulates a mid-range phone with simulated throttling: a slow 4G connection (150 ms latency, 1.6 Mbps down) and a CPU slowed down 4 times. Desktop uses a faster connection, no CPU slowdown and its own scoring curves, so the same page usually scores higher on desktop. Test both if you care about both, and treat them as separate results.

Scores also move between runs because of network and CPU timing. A page can score 78 on one run and 84 on the next. Running each page 3 times and keeping the median smooths this out. See Lighthouse score for how the performance score is built.

Step 3: Run the audits

Option A: The Lighthouse CLI in a loop

Install Node.js, then the CLI:

npm install -g lighthouse
lighthouse https://example.com/ --output=json --output-path=./home.json
lighthouse https://example.com/ --preset=desktop --output=json --output-path=./home-desktop.json

Wrap that in a script that reads your URL list and writes one report per URL and device. It works, but expect to handle retries, timeouts, Chrome crashes and the parsing of hundreds of JSON files yourself.

Option B: Lighthouse CI

Lighthouse CI accepts a list of URLs in its collect settings and runs each one several times. It is built for checking a handful of key pages on every pull request, and it can fail a build when scores drop below a budget.

Option C: A hosted bulk audit

A hosted tool removes the setup. With AiroPages, you enter a domain or sitemap URL and it reads your sitemaps, skips noindex and duplicate pages, groups pages by template, and runs every page on mobile and desktop, several pages at once. You see the exact price for your site before you pay. Read bulk PageSpeed testing without the CLI for a closer look at hosted options.

Step 4: Group results by template

Reading 300 reports one by one does not scale. Most sites are built from a small number of templates: a blog post, a product page, a category page. If the blog template ships a 1.2 MB hero image, every blog post fails the same LCP check.

Group failing audits by template and sort by the number of affected pages. One fix to the template often lifts dozens or hundreds of pages at once.

Step 5: Fix, re-audit, and keep watching

After you fix an issue, re-run the affected URLs to confirm the improvement. Then schedule regular checks, weekly for most sites, so a new script, image or plugin does not quietly undo the work.

If a page has enough real traffic, compare lab results with CrUX field data. Lab tests tell you what to fix; field data tells you what real visitors experience.