The first pass came back with 311 measured rows, 40 of them needing action — 0 High, 25 Medium, 15 Info — 211 passing and 60 that could not be checked from where I was sitting. Eighteen minutes later a re-run came back with 0 needing action. Here is exactly what changed, because the interesting part is not the score, it is how cheap most of the fixes were.

What the 40 actually were

They were not 40 different problems. The report counts one row per check per page, so an origin-wide problem repeats once per page:

• HSTS (Strict-Transport-Security) absent — 8 rows, Medium
• CSP absent, not even Report-Only — 8 rows, Medium
• Frame-embedding protection absent (no X-Frame-Options, no frame-ancestors) — 8 rows, Medium
• OpenGraph / Twitter card tags missing — 5 rows, Info
• One render-blocking item in <head> (the stylesheet) — 5 rows, Info
• A sampled static asset caching for under a day — 5 rows, Info
• Charset not declared on sitemap.xml — 1 row, Medium

So: 24 of the 40 rows were three missing HTTP response headers. One of the cheapest fixes in web operations, and I had shipped the site without it.

Fix 1 — one _headers file, 24 rows gone

On Cloudflare Pages this is a single file in the repo root. This is literally what mine says now:

/*
  Strict-Transport-Security: max-age=31536000; includeSubDomains
  X-Content-Type-Options: nosniff
  Referrer-Policy: strict-origin-when-cross-origin
  X-Frame-Options: SAMEORIGIN
  Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; font-src 'self'; connect-src 'self' https://api.web3forms.com; form-action 'self' https://api.web3forms.com; frame-ancestors 'self'; base-uri 'self'; object-src 'none'

/sitemap.xml
  Content-Type: application/xml; charset=utf-8

/styles.css
  Cache-Control: public, max-age=3600

/og.png
  Cache-Control: public, max-age=604800

Two things I would have got wrong without measuring:

Verify header changes with a GET, not a HEAD. My first check used curl -I, which looked like the deploy had silently failed — no security headers in the output. curl -x ... -D - -s https://svc.openyuri.com/ -o /dev/null (a real GET) showed all of them present. Whatever you use to confirm, make sure it exercises the same method a browser does.

I left the CSP in Report-Only on purpose. The contact form posts to https://api.web3forms.com, so flipping this to enforcing without watching the reports first would have been a good way to break my own intake line on a storefront that has a live form on it. That is the difference between a header that exists and a header you can actually run.

Fix 2 — OG and Twitter cards, 5 rows

Every page was missing OpenGraph metadata, which means: when someone pastes my link into Slack, X or a messaging app, it shows bare text instead of a title, description and preview image. For a shop whose only distribution is "someone shares the link", that is not cosmetic. Added og:title, og:description, og:url, og:image plus twitter:card=summary_large_image, and made sure the image actually existed on the origin before trusting the tags.

One small trap: my own build script skipped this fix on one page, because that page's own body text contains the literal string og:image and the script's "does it already have OG tags" test matched the article text instead of the head. A checker that greps for a string can be fooled by the string appearing in the content it is checking.

Fix 3 — inline the stylesheet at build time, 10 rows — and 10 rows I lost

Five pages had one render-blocking item: a <link rel="stylesheet" href="/styles.css">, 6.3 KB on disk, 2 KB after compression. Five more rows flagged that this asset cached for under a day. The site has no JavaScript and one small stylesheet, so I stopped shipping a separate file for it and added one build step that pastes the CSS into each page inside <style> tags.

This is where the honest footnote lives, and it is the part most "we fixed everything!" write-ups would skip:

• The re-run measured 301 rows, not 311. Ten rows disappeared.
• Why: two checks (asset-compression, cache-validators) only fire when the page samples a same-origin asset. With no external stylesheet, there is nothing left to sample, so those ten rows stopped existing rather than passing.
• The render-blocking-head rows flipped from Info-severity failures to Medium-severity passes — the severity label is attached to the check, not to the outcome.

Same headline number, slightly different denominator. I would rather state that than let a "40 → 0" look tidier than it is. If you are ever reading an audit that only gives you totals, ask what the row count was before and after.

Where it landed

Re-measured twice more (once right after the fixes, once after further copy edits, in case I had broken something): 8 URLs, 301 rows, 0 needing action — 0 High, 0 Medium, 0 Info — 241 passing, 60 not checked.

Those 60 are not a pass and I am not going to present them as one. They are things a GET-only review simply cannot see from outside: anything behind the login form, browser-rendered Core Web Vitals, search-console and index coverage, consent-banner behaviour, whether the email the form triggers actually arrives. A report that scored those would be guessing.

And two of my other sites still have 72 Medium rows sitting open — same three headers, same fix. I did the storefront first because it is the one you can go and measure yourself right now.

If you want to check my work rather than take my word for it

The full human-readable checklist with what each item costs a visitor is on the shop: https://svc.openyuri.com/checklist — that page also shows the before/after numbers above. Scope and limits (what USD 99 does and does not include) are at https://svc.openyuri.com/pricing .

Or do it yourself before you pay anyone: fetch your own homepage with response headers shown, and ask four questions. Is Strict-Transport-Security there? Is any CSP sent, even Report-Only? Can your page be framed? Do your links paste with a preview card? Four honest answers will tell you more than a 100-point score.

The only real lesson from the afternoon: the whole fix took eighteen minutes, and I still spent longer arguing with myself about whether an eighteen-minute job was worth measuring. The site did not change in the ways I expected; it changed in the two lines I would never have thought to look at.

The numbers from that run, straight out of the report: 24 URLs in scope, 114 requests, 1.14 MB transferred, 0 transport failures. It produced 957 total rows — one measurement per check per page. Of those, 72 rows needed action (0 High, 72 Medium, 0 Info), 865 checks came back confirmed OK, and 20 could not be checked from where I was sitting.

I want to be clear about what those numbers are, because it is the part most "audit" posts get wrong. As the report itself puts it: "These are plain counts of individual findings. They are not a quality score… not comparable to any other tool or site." A count of 72 does not mean my site scores 92/100. It means 72 individual measurements came back failed, and a great many of them are the same one-line problem repeating across every page. The other honesty rule the whole report lives by: "Nothing here is estimated, modelled or inferred — if a row says not checked, it is because we could not read it from here." No guessing, no "looks like maybe" — either the server returned it or the row is blank.

So this post is really the checklist, with what each failure costs a real visitor and the one line that fixes it.

How the pass works (so the results mean something)

Every URL is fetched once with a GET; its response headers and returned markup are read against a fixed list; robots.txt is read before any page is touched. The politeness is explicit: at least 250 ms between requests to one host, max 2 concurrent, 20 s per-request timeout, a 5-hop redirect cap, 5.00 MB per document. No JavaScript is executed — the report describes what the server returned, not what a browser eventually paints. That is a real limitation and the report says so, rather than pretending the page is what the markup implies.

Group 1 — Security headers (my 72 mediums, almost entirely)

On the run, three checks failed on 24 of 24 pages, which is why the count is lumpy: they are origin-wide, not page-specific.

• Strict-Transport-Security (HSTS) — absent. What it costs: without it, a visitor on coffee-shop Wi-Fi can be knocked back to plain HTTP by anyone between them and my server, and their cookie leaks in the clear. Fix is genuinely one line in the CDN/server config: Strict-Transport-Security: max-age=31536000; includeSubDomains.
• Content-Security-Policy — absent (neither enforcing nor Report-Only). What it costs: CSP is the main brake on an injected or third-party script running inside my pages. Fix without breaking the site: ship Content-Security-Policy-Report-Only: default-src 'self' first to see what my own pages would break, then switch to enforcing once the exceptions are known.
• Frame-embedding protection — both X-Frame-Options and CSP frame-ancestors absent. What it costs: a third-party site could load my page in an invisible frame and capture clicks on it (clickjacking). Fix: X-Frame-Options: SAMEORIGIN, or frame-ancestors 'self' inside the CSP.

The checks that passed here are worth naming so you can see what "OK" looks like: X-Content-Type-Options was nosniff, Referrer-Policy was strict-origin-when-cross-origin, Set-Cookie flags were Secure; HttpOnly; SameSite=Lax, and the Server header published no version number. Those are the rows I would have wanted to find missing.

Group 2 — Transport and TLS (the quiet relief)

These all came back OK on my run, and they are the ones that make me sleep: final status code was HTTP 200 with no redirect for the exact address requested; TLS certificate valid and trusted with 87 days remaining; TLSv1.3 negotiated. The one to watch is certificate days-remaining — a site that runs out gets a full-screen browser error for every visitor, not a soft warning. A cron that alarms under 14 days is the whole fix.

Group 3 — Caching and render-blocking (from a second site of mine)

I ran the same pass on https://photo.openyuri.com (12 URLs, 502 rows) and it surfaced the performance-style items as Info, not Medium — a real cost, but a scheduling one. Cache-Control on a sampled page asset was max-age=0, so that CSS is re-fetched on every visit; the fix is to raise max-age once the file is content-hashed. One render-blocking stylesheet in <head> (/_astro/Landing…css) holds first paint until it lands; the realistic moves are to inline the critical part or serve it from the same origin so it arrives with the document. Neither is scary; both are free wins that a visitor feels.

Group 4 — Metadata and indexing (cheap, and I still missed some)

Page title was 55 characters, meta description 110 characters, charset declared as utf-8 on every page — all fine. 404 behaviour passed too: a deliberately-missing path answers HTTP 404, which matters because broken-link detection depends on an honest 404 (a soft-404 that returns 200 makes crawlers and this tool both blind). The second site did miss OpenGraph/Twitter card tags, so links to it paste as bare text instead of a preview card — og:title, og:description, og:image, og:url.

The one that surprised me

Internal links paying a redirect. On the photo site, links pointed at the bare address /privacy which answers a 308 before landing on /privacy/. The user pays an extra round-trip for a link I wrote. The fix is to rewrite those links to the final address they land on. Small, but it is exactly the kind of thing you only see when you measure instead of assume.

What could not be checked

The report had a whole section for the 20 not-checkable rows, and I think that section is the honest heart of it. Things behind a login, browser-rendered Core Web Vitals, search-console rankings, consent-banner behaviour — all recorded as not checked, here is why, rather than guessed at. A review that only reports what it measured is more useful than one that scores what it assumes.

If you want someone to run this on your site

I'm a solo operator, so this is a fixed, one-pass thing, not a subscription: USD 99, up to 25 URLs of a live site, delivered as a written evidence report — per-URL findings, the observed value, why it matters, and what to change. Implementation work, if you want it done for you, is quoted separately per milestone. If that sounds useful, details and how to request it are at https://svc.openyuri.com/ .

And if you'd rather do it yourself first: run the checklist above against your own homepage. I did, and it told me things about my own site I would have sworn were already fixed.

One more thing, said plainly. This tool is my own product, and the USD 99 fixed scope above is what I sell — so this post is also promotion, and you should read it that way. Disclosure: this is my own product; the numbers above come from runs on my own sites (brief.openyuri.com and photo.openyuri.com), not client work. There are no clients to cite yet, so you will find no customer names, no logos and no testimonials anywhere on the site or in this post. The full list of what gets measured is published at https://svc.openyuri.com/checklist , and requests go through https://svc.openyuri.com/ . If you run the checklist on your own homepage first and find fewer than five things to fix, honestly — you do not need to pay me.