We audited our own website. It failed.
We sell SEO audits. We built the system that runs them. In August 2026 we pointed it at our own site and published everything it found, including the parts that make us look bad.
What the audit found
The site was a single page with strong surface polish — well-written meta tags, clean heading hierarchy, valid JSON-LD, mobile-responsive with real breakpoints. Underneath:
Security — the headers were theatre. The page shipped a Strict-Transport-Security directive as an HTML <meta http-equiv> tag. Browsers have never honoured HSTS that way; only a real HTTP response header counts. The site looked protected in its own source code and enforced nothing. Of six standard security headers, one was present, and it was a Content Security Policy with no fetch directives — a policy that restricted nothing while appearing in the response.
Performance — self-inflicted. A 603 KB build of three.js loaded in <head> with no async or defer, blocking HTML parsing before the browser reached the page's own styles. The headline text was then set to opacity: 0 and faded in on a 0.4-second animation delay. Chrome does not record Largest Contentful Paint for an element at zero opacity, so the page was manually adding time to its own core metric. Two WebGL scenes ran permanent, uncancelled animation loops, including one that kept rendering while scrolled off screen and while the browser tab was in the background.
Structured data — pointing at nothing. Organization.logo and ProfessionalService.image both referenced /logo.svg. That file had never been uploaded. Neither had /og-image.jpg or /favicon.ico, both referenced in the page head. Google could not attach a logo to a Knowledge Panel; social shares rendered with no preview image.
The sitemap described a site that did not exist. Of five URLs, three were fragment links — /#services, /#process, /#faq. Everything after # is stripped by the browser and never sent to a server, so all three resolved to the homepage. A fourth was marked noindex. One URL out of five was real and indexable.
Structured data disagreed with the page. The FAQ schema encoded four of five visible questions, and one of those four had an answer whose text differed from what visitors actually read. Google requires structured-data answers to match visible content.
Small things that undermine trust. Footer social icons all pointed at href="#" while the schema declared working profile URLs. Two different contact addresses appeared across the site and its policy documents, one of them free webmail — on a site selling brand authority.
And one we found only after fixing everything else: **/privacy-policy returned 404** while being linked from the footer of every page and declared as the canonical URL in the policy's own head.
What we changed
- Removed the fake HSTS meta tag; set all six security headers as real HTTP response headers
- Deployed a scoped Content Security Policy in report-only mode first, verified a clean console across every path, then enforced it
- Moved three.js out of
<head>entirely — it now loads after the page has finished, and is not fetched at all on reduced-motion, Save-Data, 3G, or devices reporting 2 GB of RAM or less - Removed the opacity animation from the headline so it paints immediately
- Gated both WebGL loops behind an IntersectionObserver and a visibility check, with real
cancelAnimationFramecalls - Created and uploaded every referenced asset; repointed the schema at files that exist
- Rewrote the sitemap to list only real, indexable URLs
- Completed the FAQ schema to all five questions, matching the rendered text character for character
- Fixed the dead social links and reconciled the contact address across four files
- Added an extensionless-URL rewrite so
/privacy-policyresolves - Wired up lead capture, with a second notification that fires only when a call is actually booked, so a form submission with no booking is visible as a follow-up rather than silence
- Redirected
wwwto the apex domain, so the same content stops being served from two hostnames
Measured results
| Before | After | |
|---|---|---|
| securityheaders.com grade | D | A |
| Security headers present | 1 of 6 | 6 of 6 |
| Referenced files returning 404 | 6 | 0 |
| Real indexable URLs in sitemap | 1 of 5 listed | 1 of 1 listed |
| FAQ answers in structured data | 4 of 5, one mismatched | 5 of 5, exact match |
Render-blocking JS in <head> | 603 KB | 0 |
| Sitewide broken links | 1 (/privacy-policy) | 0 |
| Hostnames serving the same page | 2 (www and apex) | 1 |
| Form submissions recorded | 0% | 100% |
The security grade moved from D to A in sixteen minutes of deploy time, verified externally by securityheaders.com before and after.
Post-remediation measurements: Total Blocking Time 0 ms, Cumulative Layout Shift 0.001, server response time between 0.13 s and 0.22 s across repeated runs, with Brotli compression, and PageSpeed Insights mobile scores of **91 Performance, 98 Accessibility, 100 Best Practices, 100 SEO**.
What this case study does not prove
We are an SEO agency, so we will be precise about the limits of our own evidence.
We have no before-and-after performance comparison. We captured our performance baseline after deploying the fixes, which means we cannot show you a PageSpeed score that improved. We know what the architecture was doing and why it was slow. We cannot put a number on it.
That is a real mistake, and it changed how we work. On every site we touch now, before we change a single line, we capture the baseline: PageSpeed Insights on mobile and desktop, response headers, Core Web Vitals, structured data, crawl files, and every referenced asset. You get that file. When the work is done we run the identical capture again and you get the second file, so the difference is measurable by you rather than described by us.
We could not do that for ourselves on this project. We will not repeat it on yours.
We have no ranking or traffic data. This site had one indexed page when the work started and has one now — because it is genuinely one page. Technical correctness does not create content that ranks. That work is separate and ongoing, and when there is ranking data we will publish it, including if it is disappointing.
Lab metrics are not field data. The PageSpeed figures above are simulated on a throttled connection. Real-world Core Web Vitals require weeks of visitor data.
What this case study does demonstrate: a documented technical baseline, a set of specific defects, the reasoning behind each fix, and an externally verifiable result.
Check our work
Every claim above is verifiable from outside without our cooperation.
securityheaders.com— enter the domain and compare against the grade above- PageSpeed Insights — run it yourself on the homepage; we have no way to influence what it tells you
curl -sI https://ravensedgemedia.com/— the six response headershttps://ravensedgemedia.com/sitemap.xml— count the URLs- Google's Rich Results Test — the structured data
We also run a scripted verification against our own site that checks headers, asset status codes, canonicalisation, sitemap contents and structured data on every deploy. We use the same script on client sites.
If any claim on this page does not hold up when you check it, we want to know.
Why we published this
The strongest reason to trust an agency is not a list of services. It is evidence that they hold themselves to what they sell, including when the result is embarrassing.
Our own site was broken in ways we would have flagged as critical on a client site. We found it, fixed it, measured it, and published the parts that make us look bad alongside the parts that do not.
If you want the same treatment on your site, the audit is free and you get it before we speak. We run it, send you the findings, and you decide whether the call is worth your time once you have read them.
Want the same audit on your site? It is free, and you get the findings before we speak — so you can decide whether a call is worth your time once you have read them.
Get your free audit