I ran a 957-row technical review on my own website. Here is the checklist.
I build and run a couple of small sites under an unregistered working brand, OpenYuri. Before I pointed anyone at my own paid review service, I did the only honest thing: I ran the review on my own sites first. I used a zero-dependency Node script (review.mjs, GET requests only) against one of them, https://brief.openyuri.com.
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, orframe-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.
What happened after I wrote the first draft of this
I ran the same pass against the site you are reading right now: 8 URLs, 301 rows. It came back with 40 rows needing action, 25 of them Medium — missing security headers, no OpenGraph cards, short cache on the stylesheet. I fixed those with one _headers file (HSTS, X-Content-Type-Options, Referrer-Policy, frame-ancestors and a Content-Security-Policy in report-only mode), OG and Twitter cards plus an image, and inlining the stylesheet at build time. Re-measured: 0 rows needing action — 0 High, 0 Medium, 0 Info, 241 passing, 60 still not checked.
Candidly: the 72 Mediums on my other two sites are still sitting there. I chose to fix the storefront first because it's the one you can measure yourself right now — paste https://svc.openyuri.com/ into your own scanner, or ask me for the four report files (before, and each pass after each fix). A review you can reproduce is the only kind worth paying for.
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.