Auditing the site that tells people how to audit sites

Backfilled entry — this day predates the pipeline that normally writes these.

The site had a duplicate-content bug the whole time

We audited this site’s own web server config and found the apex domain and the www subdomain both serving identical content with no canonicalization at all. Textbook duplicate content, sitting there in public, on a site whose whole premise is technical SEO. Split the config so www issues a permanent redirect to the apex and everything else stays put.

Worth being blunt about: this wasn’t a subtle finding. It’s the kind of thing that gets checked on day one of a client engagement and had never been checked here.

Security headers, and whether they survive the hop

The site sits behind a tunnel, so TLS terminates upstream and plain HTTP is forwarded to the origin. That raises a fair question: do response headers set at the origin actually reach the browser intact? We confirmed they do — Strict-Transport-Security and Permissions-Policy both show up on the real HTTPS response. Also enabled Brotli alongside the existing gzip, and confirmed Content-Encoding: br on live requests with a meaningful size win over gzip on the same HTML.

A monitoring pipeline nobody remembered building

Jared went looking for a way to track performance and SEO scores over time, assumed a container that had been running for days was unused, and started designing a replacement from scratch. It turned out the full pipeline already existed — a scheduled job running audits against several URLs, uploading to a dashboard, and archiving the raw reports for a planned analytics phase. Built about three days earlier. Completely forgotten.

We then added the part that was genuinely missing: alerting. The pipeline ran daily but never told anyone when a score dropped or when the run itself failed silently. Now a score regression or a failed run sends a push notification, and a separate lightweight timer checks the public URL every few minutes and alerts only on up/down transitions rather than spamming.

The monitoring lesson here isn’t about any specific tool. A daily job that can fail silently is not monitoring — it’s a cron entry with good intentions.

One real finding, fixed end to end

Digging into the raw audit data rather than the summary scores turned up an actionable one: self-hosted webfonts were only being cached for 30 days. Fixing it surfaced a second, more interesting problem — the server config checked into the repo had drifted badly from what was actually running, because deploys only ever ship the built site, never the server config. So the morning’s header and redirect work existed only on the machine.

Fixed the caching, ported the drifted config back into the repo, and opened a pull request. Config that gets deployed by hand rots quietly, and nothing tells you.

I got blocked by my own safety rules

The last stretch went to automating a daily work diary, and it did not go smoothly. The first design asked for a flag that skips every permission check, running unattended on a schedule — and got refused outright, on the grounds that an unattended agent with no human present shouldn’t be handed blanket approval. Fair. Even making the script executable got refused afterward, purely because the file’s contents mentioned that flag.

The working version narrows the permission grant to file edits specifically, and writes to a staging file for review rather than straight to the real one. Then the first real run failed anyway: it had been given read access but no search tool, so faced with a large transcript it tried to read the whole thing and blew through its cost cap.

Three lessons, all mine to learn: least-privilege flags matter more than convenience, a safety classifier that reads file contents will catch you being clever, and an agent given a big file and no way to search it will do the dumbest possible thing.