Our own audit
These are the findings our tool produces when it audits our own site — and what we did about each one.
Any audit tool has a conflict of interest: whoever builds it controls the weights, and can tune them until their own site passes. So a passing score on our own site would prove nothing.
This page does the opposite. It records, with dates, where our own site fails the checks we sell. An entry stays here after it is fixed, with both dates — the found date and the resolved date. We keep the failures on the record; deleting them would defeat the point.
We run this audit on our own site as we build it, and we fix findings before they reach anyone. When we ran our free audit against our own site on August 1, 2026, it scored 96 out of 100 — and of all 31 checks, the only one failing was the Content-Security-Policy recorded below. That one is now resolved too, so all four records that follow carry both dates.
Our accessibility checks passed by string match, not by element
Found: July 31, 2026
- What. Run against real pages, our five accessibility checks reported a pass whenever the relevant attribute appeared anywhere in the HTML. A single alt attribute, on any image, marked the whole page as passing. This was a false positive, not a false negative — the site returned a pass that was not true, on the very checks the product sells.
- Why. The checks tested for the presence of a string in the page source instead of inspecting each element. Measured against axe-core on three real pages, the overlap was zero: on css-tricks.com our engine reported image alt text as passing while 7 images had no alt, and semantic landmarks as passing while axe-core found 120 nodes outside any landmark.
- Plan. We rewrote the five checks to verify each element instead of matching a string, under ticket DEV-236. Fixing a false pass lowers scores, and it did: on css-tricks.com the accessibility score fell from 100 to 50 and the overall score from 87 to 79 — the same for our own audits. We record this because it is the most direct proof that we do not tune scores to flatter: the correction moved the number down.
Resolved: July 31, 2026. One honest limit remains, open under ticket DEV-238: the report gives the verdict — pass or fail — without the count behind it. It tells you a check failed, not yet how many items failed. Publishing the fix without naming that limit would claim more than the product delivers today.
Our Content-Security-Policy failed our own audit
Found: August 1, 2026
- What. Run against our own site, our Security check for Content-Security-Policy (CSP) returned a failure.
- Why. The policy we served relied on 'unsafe-inline' in its script and style directives (and on 'unsafe-eval' for scripts). Those allowances weakened the protection a CSP exists to provide, so the check did not pass. The header was present; it was simply too permissive to count as a pass.
- Plan. We are tightening the policy under ticket DEV-193. Removing Google Tag Manager (already done) means the stricter policy no longer needs a per-request nonce — the expensive, risky part of the fix. Target: within 30 days of this entry, by August 31, 2026.
Resolved: August 30, 2026. The policy we serve now admits scripts only by a nonce minted per request — script-src 'self' 'nonce-…' 'strict-dynamic' — with no 'unsafe-inline', no 'unsafe-eval', and no wildcard letting a script load from any https origin. We checked it the way a customer would: our own audit, run against the deployed site rather than against the configuration file, returns a pass on this check. Two corrections belong in the open rather than in a quiet edit to the plan above. The plan was wrong about the nonce: removing Google Tag Manager did not remove the inline scripts, because the framework we build on writes its own into every page — 33 of the 35 script tags on our home page are its, and each one now carries the nonce. And the fix is partial in a way we will not hide: the new policy places no restriction on styles. A CSP has no way to permit an inline style attribute other than 'unsafe-inline' itself — the exact allowance this entry exists about — and the interface components we use write those attributes as the page runs. So our scripts are locked down and our styles are not. A script executes and a style does not, which is why we made that trade; but it is a trade, and it belongs on this page.
Our technology detector reported technologies that were not there
Found: July 27, 2026
- What. Our technology detector named technologies a site did not use. On one paid report it listed nine, and only two were real — wrong seven times out of nine. Because the AI guide read that list, it once advised installing a tag manager on a site that had none.
- Why. The detector matched text shown on the page instead of the infrastructure behind it — it matched substrings in running prose, and in one case read the list of technologies printed for another site as if they were this one's. This was not a bad signature; it was a limit of the method. An analysis that does not execute JavaScript cannot see what a site actually loads at runtime.
- Plan. Because the cause was the method and not a rule, we turned the capability off rather than patching it, under ticket DEV-223 — the display, the feed into the AI guide, and the commercial mention in the paywall, in all three languages. Turning off the delivery meant removing the promise with it.
Resolved: July 31, 2026.
A customer's report could be indexed by search engines
Found: July 27, 2026
- What. The paid report route was served without a noindex directive, so a customer's report — which names the audited URL and its security findings — could have appeared in search results.
- Why. The route inherited the site's default metadata, which allows indexing, and never overrode it. The report is meant to have a permanent, shareable link; it was never meant to be discoverable in search.
- Plan. We added noindex to the report route and removed the canonical tag that pointed staging reports at the production domain, under ticket DEV-222. The report link stays permanent and shareable, and is now not indexable.
Resolved: July 28, 2026.
If a plan's date passes before the fix ships, this entry will be updated with the reason and a new date — never quietly removed.
See your own site's findings
Run the same audit on your site.
Audit my site