How to check PageSpeed scores for many URLs at once

Published November 11, 2026 · Hill Country Bots

If you have already pasted the same ten landing pages into PageSpeed Insights, you know the pattern. Wait for the report. Copy the mobile score, the Core Web Vitals, and the top opportunity. Do the next URL. It works, and it gets old once the list grows past a handful of pages.

The first method is free: Google's official PageSpeed Insights API, plus a spreadsheet or a short script. The second is a bulk checker we built, Bulk PageSpeed Checker, sold on the Apify Store. Use whichever fits the job.

What each check actually returns

For every URL, on mobile or on desktop, you get two kinds of numbers.

Lab data comes from Lighthouse, which Google runs on its own servers. You get Performance, Accessibility, Best Practices, and SEO scores from 0 to 100, plus lab metrics such as Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), and Total Blocking Time.

Field data comes from the Chrome UX Report, when Google has enough real visitor data for that page. This is where Core Web Vitals live: LCP, Interaction to Next Paint (INP), and CLS, usually as a 75th percentile over about 28 days, plus a verdict such as FAST, AVERAGE, or SLOW.

A mobile check and a desktop check of the same page are two separate audits. The same page can look fine on a desktop and slow on a phone. Lab scores also move a little from one run to the next. That is normal. Treat a single Lighthouse score as a snapshot, and put more weight on the field data when it is present.

Method 1: the free way

Start with your most important pages

If you only need a handful of URLs, stay on the official report at pagespeed.web.dev. Paste one URL, wait, and write down the mobile Performance score, the field Core Web Vitals, and the first opportunity. Then do the next URL.

That is enough for a homepage, a pricing page, and a couple of templates. It is not a good way to check 50 or 500 pages.

Get a URL list from the sitemap

For a longer list, open the site's robots.txt file (for example, https://www.example.com/robots.txt) and follow the Sitemap: line to the XML sitemap. Copy the loc URLs into a spreadsheet. Nested sitemap indexes take more time, because you have to open each child sitemap too.

You can also pull the list with a sitemap extractor. We have one, the Sitemap URL Extractor, at $0.50 per 1,000 URLs. A text editor and a browser are fine for a small site.

Call the official PageSpeed Insights API

Google documents this on the PageSpeed Insights API getting started page. One request looks like this:

curl "https://www.googleapis.com/pagespeedonline/v5/runPagespeed?url=https://www.wikipedia.org/&strategy=mobile"

Add your own API key as &key=YOUR_API_KEY once you move past a few test requests. You can create a key in Google Cloud by enabling the PageSpeed Insights API. Google gives you a free daily quota. Check the current limit in your own project before you point a script at hundreds of URLs.

Each request tests one URL on one device and returns a large JSON file. To do a list, you loop over the URLs, wait for each response (often 10 to 30 seconds), and pull out the fields you care about. A simple approach:

1. Put the URLs in a text file or a spreadsheet, one per line.
2. Get a free API key and enable the PageSpeed Insights API in a Google Cloud project.
3. For each URL, request mobile (and desktop if you need both).
4. Save the Performance score, lab LCP and CLS, field LCP, INP and CLS when they are present, and the first opportunity title.
5. Write those fields to a CSV so you can sort and filter them.

You can do that with a short script, or with Google Apps Script inside a Sheet. Space the requests out so you do not hit Google's rate limits. If a request fails, record the error and move on. Failed tests happen, and a retry later is usually enough.

This method is free, and the numbers come from the same API the official report uses. The work is in the loop, the errors, and turning the JSON into a table you can sort.

Method 2: a bulk checker (the one we built)

If you would rather paste a list and download a CSV, that is what our Bulk PageSpeed Checker does. We built this tool. It calls Google's official PageSpeed Insights API for you. You do not need your own Google API key, though you can add one if you want.

It costs $3 per 1,000 successful audits ($0.003 per URL on one device). That is the live Apify Store price as of November 11, 2026. Failed, invalid, and timed-out audits are written as error rows and are not charged. Checking 500 URLs on mobile and desktop is 1,000 audits, or $3.00.

Steps

1. Make your URL list. Paste it, or pull it from a sitemap first with the Sitemap URL Extractor if the site is large.
2. Open the Bulk PageSpeed Checker on Apify.
3. Paste the URLs, choose mobile, desktop, or both, and start the run. Leave the categories at the default if you want Performance, Accessibility, Best Practices, and SEO.
4. When it finishes, download the dataset as CSV, Excel, or JSON. Each successful row is one URL on one device, with scores, lab metrics, field Core Web Vitals when Google has them, and the top fixes.

You can also run the same check from an n8n workflow with our community node, or from the Apify API. Site Health Kit can do this kind of check inside Google Sheets.

Real results from a test run

On November 11, 2026 we ran three public pages, on mobile and desktop, through our PageSpeed check. These are the actual numbers from that run, not a made-up example. Lab scores can shift a little the next time you run them.

Full URLs tested: https://web.dev/, https://www.wikipedia.org/, and https://crawlee.dev/. The run also returned Accessibility, Best Practices, and SEO scores, lab CLS and Total Blocking Time, and field INP and CLS. We left those out of the table to keep it readable.

How to read a table like this

Start with the field verdict, especially on mobile. On this run, Wikipedia is FAST on both devices, crawlee.dev is AVERAGE, and web.dev is SLOW on mobile (field LCP 3.05 seconds) and AVERAGE on desktop. Google treats an LCP up to 2.5 seconds as good, so that mobile field LCP is the first number I would act on.

Then look at lab Performance and the top fix. web.dev's mobile lab LCP was 7.8 seconds, and the first opportunity was "Reduce unused JavaScript" (about 3.5 seconds). Wikipedia's mobile Performance was 99, with a small cache-lifetime suggestion. crawlee.dev sat at 66 on both devices, with "Minimize main-thread work" (about 1.5 seconds) as the desktop top fix.

If the same fix shows up on many of your own pages, fix that once (a shared script, a cache header, an image template) rather than chasing one URL at a time.

A few things that trip people up

One URL on both devices counts as two audits. If you only care about phones, run mobile and you cut the work, and the cost, in half.

Pages with almost no real visitor traffic often have no field data. You will still get lab scores. Do not treat a missing field verdict as a pass.

The API tests the public page. It does not log in, and it will not see content that appears only after a paywall or on a private dashboard.

Invalid URLs and timeouts should show up as errors, not as fake scores. In our tool those rows are free. If you write your own script, log the failures so they do not disappear.

Questions

Related tools

• Free site check. Test one page for free and get PageSpeed scores, Core Web Vitals and plain English fixes.
• Bulk PageSpeed Checker. The tool described above, $3 per 1,000 successful audits.
• Apify Store listing. Run it there and download a CSV.
• Sitemap URL Extractor. Build the URL list before you run PageSpeed.
• Bulk PageSpeed for n8n. The same check, from an n8n workflow.
• SEO Audit Tool. On-page and technical SEO scores, plus a client-ready HTML report.
• Site Health Kit. The same kind of checks, inside Google Sheets.