A 12-line shell script that told me what the SEO suite couldn't

The dashboard said page load times were fine.

The page didn't load fine. I was sitting in a hotel in another city, watching a product page take seven seconds to render, and our enterprise SEO suite — the one with the dashboards and the executive summaries and the green checkmarks — was telling me everything was green.

That gap, between what the tools said and what was actually happening, has been the most useful teacher I've had in this work.

So I wrote a script.

#!/bin/bash
file="urls.txt"
output="check.txt"
output=$(date +%Y%m%d_%H%M%S)"_$output"

while IFS= read -r line
do
	printf '%sn' "$line"
	curl -I -svw 'monitor_load_times %{time_total} %{redirect_url} %{http_code}nn' \
	-m 15 -o /dev/null "$line" >>"$output" 2>&1
	printf '*%sn'
done <"$file"

That's the whole thing. Twelve lines, give or take. It reads URLs from urls.txt, hits each one with curl -I (a HEAD request, so we're not downloading bodies we don't need), records the total time, any redirect target, and the HTTP status code, and writes the lot to a timestamped log file.

You then run a chmod +x check.sh to change the permissions and then a run with ./check.sh. You get back a file named something like 20160417_180457_check.txt with one block per URL. Cron it every five minutes and you've built a poor person's uptime monitor. Run it from three different geographies and you've built a loose person's CDN tester.

Why does this matter?

Page Speed Service matters, but how fast pages load has its own price. Monitoring the execution and page load time is a must if you are serious about SEO. And this script can be helpful, while not being a real monitoring service. NewRelic and Pingdom and the dashboards from the suite I just maligned all do more than twelve lines of bash ever will. But they hide things. That's the price of polish: you trade visibility for convenience. The dashboard tells you what it has been told to tell you. The script tells you what curl actually saw, which is closer to what a browser sees, which is closer to what your customer sees. Three specific things this script taught me that no SaaS dashboard ever did:

Redirect chains kill TTFB. The %{redirect_url} field caught a http:// → https:// → https://www. → https://www.<lang-prefix>/ chain on a site I was advising for. Each hop added 200ms. The SEO suite reported a clean 301 to canonical and called it a day. The script showed me the four-hop reality.
time_total is honest about cold caches. Run the script twice in a row and the second pass is faster. Run it after sleeping the server overnight and the first pass tells you what your first visitor of the morning experiences. Most monitoring tools warm their caches by polling constantly — they don't see the cold-start tax. The script does, because you only run it when you run it.
The 15-second timeout (-m 15) is more useful than it looks. Anything that takes longer than 15 seconds isn't "slow" anymore. It's broken, from a user perspective. The fact that the script just gives up and moves on mirrors what users do. A monitoring tool that patiently waits 60 seconds and reports "succeeded in 47.3 seconds" is telling you the wrong story.

What you don't get

Honest list of what this script does NOT do, in case you're tempted to deploy it as a production monitoring tool:

JavaScript execution — curl gets you the HTML response, but not the rendered one. Modern SPAs will look fast in time_total but slow in reality.
Browser timings — no DOMContentLoaded, no LCP, no CLS. For a proper Core Web Vitals you need a headless browser (or, Lighthouse).
Alerting — it writes to a file, nothing else. You bolt that on yourself with grep + mail, or graduate to a real tool.
Geographic insights. Your laptop is one location. You can SSH and copy into VPSes in different regions, but that's a different exercise.