Verified results
Two published proofs. Both dated, both traceable.
Signal publishes a result only when its source, window, joins, coverage and limitations have been verified and the client has approved it. That leaves fewer case studies on this page than an agency would like, and every one of them can be checked.
Proof one
A developer scanned his own site, fixed what it found, and scanned again
Named, dated, and in his own words.
- 68Scan 1 · 10:09 pm
- 69Scan 2 · 10:19 pm
- 93Scan 3 · 1:51 am
Three scans. Fixes between each one. One evening.
The score is the headline. What actually changed is that 10 failing checks became 1 — individually findable, individually fixable problems, not a rating.
“Wow — this is amazing. It took me two hours and three scans, and as the developer it helped me find things I hadn't been able to see for three months. Amazing software, just from the free scans.”
Scores and times are from our scan records, 12–13 August 2026, published with the client's permission. Their result came from their fixes — the scanner showed them what to fix and whether it had worked.
Proof two
One verified audit-to-audit comparison
The same checks, the same site, two dates. Every other number on this site is either yours or marked as an example.
| Result | First audit | Later audit | Change |
|---|---|---|---|
| Pass | 33 | 36 | +3 |
| Warning | 4 | 3 | -1 |
| Fail | 4 | 2 | -2 |
| Unknown | 9 | 9 | no change |
How to read this honestly
This is a verified audit-to-audit comparison of one site (a real client of ours, unnamed), not a performance claim. Part of the movement between the two runs may be detector correction — the audit engine getting better at reading the site — rather than a change to the website itself. We do not claim all five points as implementation results, and signalIQ separates website improvement from detector correction when it reports to you.
Results depend on access, architecture, scope and the issues detected. No score or outcome is promised in advance.
Read these figures as text
The client site, first audit: score 87 out of 100 — 33 pass, 4 warning, 4 fail, 9 unknown. Later audit: score 92 out of 100 — 36 pass, 3 warning, 2 fail, 9 unknown. Change: pass +3, warning −1, fail −2, unknown unchanged.
The method
What every future case study passes before it appears here
01
Re-run the source extracts
Every figure is pulled again from the platform or system it came from, never copied from an old report.
02
Confirm the window and the timezone
The exact date range and the timezone the systems report in, stated on the case study.
03
Reconcile native totals
Each system's own total is recorded before any join, so a join can never inflate a figure above its source.
04
Calculate join coverage
How many records could be joined deterministically, and how many could not, both published.
05
Disclose gaps and limitations
What the data could not show is written beside what it could.
06
Obtain client approval
The client sees the case study with its limitations and approves it in writing before it is published.
Case studies in preparation
Client work whose figures have not yet been re-run, reconciled and approved is not shown here, whatever the headline numbers looked like at the time. The lesson from that work is on this site already: separate systems each answered part of the question, and valid totals did not join into a reliable journey.
Never
What this page will never carry
Make your own before-and-after
Run the free audit now, fix what it finds, and run it again. The comparison is yours to keep.