How to Automate Pagespeed Insights [For Multiple URLs using Google Sheets] – Moz

Running PageSpeed Insights (PSI) one URL at a time is like brushing your teeth with a single hair. Yes, technically possible.
No, you shouldn’t live like this. If you manage a site with more than a handful of important pages, you need a repeatable way
to pull PSI data in bulk, log it, and spot trends without turning your weekly routine into a tab-hoarding marathon.

In this guide, you’ll build a simple “performance dashboard” in Google Sheets powered by Apps Script. You’ll paste in a list of URLs,
click a menu item (or let a schedule do it for you), and your sheet will automatically collect PSI scores, key Lighthouse lab metrics,
and optional categories like SEO and Accessibility. It’s the kind of automation that makes technical SEO feel less like detective work
and more like… well, still detective work, but with fewer coffee stains.

Why automate PageSpeed Insights in the first place?

PSI is incredibly useful, but it’s also incredibly manual. Automation turns PSI from a “once-in-a-while check” into a monitoring habit.
That matters because performance is not a one-time project. It drifts. New scripts ship. Images creep in. A/B tests multiply. Third-party tags
spawn like gremlins after midnight.

• Catch regressions fast: Log scores daily/weekly so you can spot dips after releases.
• Prioritize fixes: Compare top landing pages, templates, and slow offenders in one view.
• Prove impact: Show “before vs. after” improvements with timestamps, not vibes.
• Build a performance culture: Teams pay attention to what gets measured.

What you’re actually automating (PSI vs. Lighthouse vs. field data)

When you call the PageSpeed Insights API, Google runs a Lighthouse audit (lab data) for the URL and returns results as JSON. The API can also
return user experience metrics (“field data”) sourced from the Chrome User Experience Report (CrUX) where availablebut Google has signaled
that CrUX field data is being phased out of the PSI API, with CrUX APIs recommended instead.

Translation: your automation should focus on Lighthouse lab metrics (which the PSI API is built around), and optionally you can grab any field data
that’s still returned today. If field data disappears later, your sheet shouldn’t fall apart like a cheap lawn chair.

Set up your Google Sheet “command center”

Create a new Google Sheet and add three tabs:

1) “Config” tab (inputs)

• Column A: URL list (one per row). Include the full URL (https://…).
• Cell B1: Strategy (mobile or desktop). Start with mobile because that’s where reality hurts most.
• Cells B2–B5 (optional): Categories you want (performance, seo, accessibility, best-practices). If you skip this, you’ll run Performance only.

2) “Results” tab (output log)

Add a header row like this:

Your script will append a new row per URL each run, so you can chart trends over time.

3) “Dashboard” tab (optional, but fun)

Use pivot tables, filters, conditional formatting, and charts:

• Show average Performance score by template group (if you add a “Template” column later).
• Highlight URLs below a threshold (e.g., Performance < 80 on mobile).
• Graph LCP over time for your top 10 traffic pages.

Get a PageSpeed Insights API key (the polite way)

The PSI API can be called without a key for light use, but if you’re automating (especially across many URLs), you want an API key for reliability.
Create a key in Google Cloud and enable the PageSpeed Insights API for your project. Then we’ll store the key in Script Properties so it isn’t
sitting in your sheet like a sticky note that says “DO NOT STEAL.”

Apps Script: the engine under the hood

In your Google Sheet, go to Extensions → Apps Script. Delete any placeholder code and paste in the script below.
This script does four big things:

1. Reads your URL list and settings from the Config tab.
2. Calls the PSI API for each URL (mobile or desktop).
3. Extracts scores and key Lighthouse metrics.
4. Appends clean rows to the Results tab.

Copy/paste Apps Script (Google Sheets + PageSpeed Insights API)

Scheduling: make it run automatically (without bribing a coworker)

A bulk PSI report is great, but automation really shines when it’s consistent. Use a time-driven trigger so your sheet updates on a schedule
(daily, weekly, etc.). In Apps Script, open the clock icon (Triggers) and add a trigger for runBulkPsi.

Want to set it up with code? You can add a helper function like this:

One heads-up: triggers aren’t always “exactly at 8:00:00.” Think “around 8-ish,” like a friend who’s always a few minutes late but brings snacks.

Practical reporting ideas (so the data becomes decisions)

Use a “Top URLs” shortlist

PSI is powerful, but if you monitor 5,000 URLs daily, your script will eventually stage a protest. Start with your most important pages:
top landing pages, top revenue pages, key category templates, and anything that’s been historically slow.

Create a “template grouping” column

Add a column in your Config tab like “Template” (Product, Blog, Category, etc.). Then your dashboard can show averages by template type.
This makes performance fixes easier because most speed work is template work, not one-off page work.

Track the metrics that move the score

Lighthouse Performance is a weighted blend of metrics (like LCP, CLS, and Total Blocking Time). Instead of chasing the score like it owes you money,
monitor the actual metrics too. Your sheet already logs common onesuse them.

Troubleshooting and “Why is this score different today?”

1) Score variability is normal

PSI scores can fluctuate even if you didn’t change the site. Network conditions, server load, testing environment differences, and third-party scripts
can all introduce variability. If you want stability, run multiple tests and track the median/average over time instead of panicking over one run.

2) Watch Apps Script quotas and runtime limits

Apps Script has daily service quotas (including URL Fetch calls) and time limits. If you’re running lots of URLs:

• Batch requests (the example script uses batches of 10).
• Reduce categories when you only need Performance.
• Split your URL list into chunks and schedule multiple triggers at different times.
• Log less frequently (weekly for long-tail pages, daily for key pages).

3) “My sheet is slow” is usually a structure problem

If your Results tab becomes huge, dashboards get sluggish. Solutions:

• Create a new Results tab each month (Results_2026_02, Results_2026_03, etc.).
• Use a summary tab that pulls only the latest row per URL.
• Archive older data to another spreadsheet.

4) “Insufficient data” (field data) happens

Field data requires enough real-world Chrome usage. Smaller sites or low-traffic pages may not have it. Also, because field data via the PSI API is
being phased out, you should treat it as “nice to have,” not “business-critical.” If you need reliable field data, use the CrUX APIs.

Real-World Experiences: what teams learn after they automate PSI (Extra 500+ words)

Once teams start logging PageSpeed Insights data in a spreadsheet, a few “aha” moments show up almost immediatelyand they’re not always the ones you’d
expect. First: people stop arguing about performance in the abstract. Before automation, the conversation is usually, “The site feels slow” or
“It’s probably fine.” After automation, the conversation becomes, “Mobile LCP on our product template jumped from ~2.4s to ~3.6s right after Tuesday’s
release.” That shiftfrom opinion to timelinechanges how fast problems get fixed.

Second: the score is the headline, but the metrics are the plot. A Performance score dropping from 92 to 84 will get attention, but it rarely tells you
what to do next. Teams learn to look at LCP, CLS, and Total Blocking Time (plus the audit opportunities) and ask, “What moved?” A common pattern is that
LCP drifts upward when hero images change, when personalization expands above the fold, or when fonts shift from “efficient” to “fashion statement.”
Another common pattern is that TBT increases when new tag managers, chat widgets, or A/B testing frameworks pile on more JavaScript work during page load.
Once you have history in Sheets, you can correlate these changes with release notes, marketing launches, or vendor rollouts.

Third: automation makes you respect variability. Teams usually get surprised the first time they see the same URL score 89, then 93, then 87 across a
few runs. That’s not the tool being “wrong”it’s the real world being noisy. The practical response is to treat single runs as samples, not verdicts.
In a spreadsheet workflow, that often means running the same URL multiple times and tracking a median score, or running tests at consistent times
(for example, early morning) to reduce environmental differences. Over weeks, trends become much clearer than single-day spikes.

Fourth: bulk reporting exposes the “template tax.” Many sites discover that performance isn’t a handful of broken pagesit’s a pattern.
Blog posts might all be fast while product pages are all slower, or category pages might struggle on mobile because of heavy filtering UI.
Once you can group URLs by template type in Sheets, you stop wasting effort on whack-a-mole fixes and instead focus on template-level improvements:
image sizing rules, critical CSS, deferred scripts, smarter font loading, or reducing third-party tags on key templates.

Finally: once data lives in Sheets, people get creative. Teams set thresholds (“alert us if Performance drops below 80”), add notes columns for release
dates, build simple dashboards for leadership, and create “performance sprints” where the goal is measurable improvement across the pages that matter.
The biggest benefit isn’t the automation itselfit’s the habit it enables. If performance is measured consistently, it becomes part of how the site is
managed, not a dramatic event that happens once a quarter when someone yells “Why is Google mad at us?”

Conclusion

Automating PageSpeed Insights with Google Sheets is one of the fastest ways to turn performance from a “sometimes task” into an ongoing system.
With a simple Apps Script setup, you can run PSI in bulk, log results over time, and build a lightweight monitoring dashboard that helps you prioritize
fixes and prove outcomes. Start small: your most important URLs, mobile strategy, Performance category, and a weekly trigger. Then expand thoughtfully.
Your future self (and your site visitors) will thank youand your browser will finally have fewer than 37 PSI tabs open.