I Ran a Real SEO Audit On My Own Live Site — Here's a Free SEO Audit Report Sample

Four days ago, my site was invisible to Google. Not slow. Not penalized. Invisible — robots.txt was telling every crawler Disallow: /, and nothing about the site looked broken. No 500s, no console errors, no drop-everything alert. Just a CDN quietly serving a stale, wrong file to every bot that asked for it.

I found it while running a full technical SEO audit on my own portfolio site, voixoff-fr.surge.sh — a one-page static portfolio, four pages total, zero JavaScript, 4-13KB per page. I do SEO audits as a service, and I wanted a real, embarrassing, unedited example to show what one actually looks like before I ask anyone to pay for it. So instead of a mocked-up PDF, I published the whole thing: seo-audit-sample.surge.sh, a free SEO audit report sample built from a live site with real bugs in it.

This post walks through how I ran the audit, what it found, and the one mistake that almost made me miss the worst bug on the site.

The method: no paid tools, just curl and patience

I didn't run this through a $99/month SaaS dashboard. The whole audit stack was:

• curl -I and curl -v for raw response headers
• Manual HTML parsing for title/meta/heading structure
• Direct inspection of CDN cache headers (surge-cache, age, etag)
• The PageSpeed Insights API for performance (when it wasn't rate-limited — more on that below)

Nothing exotic. The point of the exercise was to show that most of the value in a technical audit comes from actually reading the raw response the way Googlebot sees it, not from a dashboard with colored gauges.

The bug: robots.txt lied, and the cache made sure nobody noticed

Here's the sequence. I requested https://voixoff-fr.surge.sh/robots.txt and got:

Disallow: /

Full site, blocked. But the file in my deploy folder said Allow: /. So either I'd deployed the wrong file, or something was serving a stale copy.

I checked the response headers:

surge-cache: HIT
age: 35619

Age of nearly 36,000 seconds — almost 10 hours old, and climbing, because nothing was invalidating it. The root cause: surge.sh serves its own default robots.txt with Disallow: / on new sites, and its CDN had cached that default on the bare path. I had since deployed my corrected file (Allow: / + Sitemap directive) — the deploy succeeded, the origin file was correct — and yet the CDN kept serving the cached default to every bot. Googlebot had been reading Disallow: / for four days straight, with no error surfaced anywhere.

That's the finding that anchors this whole SEO audit report sample: a bug with zero visible symptoms that can silently deindex a site.

The trap: cache-busters hide the bug they're supposed to catch

My first instinct when I suspected caching was to check robots.txt?cb=12345 to force a fresh fetch. It worked — I got the correct, up-to-date file. Which meant, for about ten minutes, I thought everything was fine.

It wasn't. Googlebot doesn't request robots.txt?cb=12345. It requests the bare path, /robots.txt, with no query string — and that's exactly the URL the CDN was serving stale. Adding a cache-buster proved the correct file existed, but it completely masked the fact that the real URL Google actually hits was still broken.

The lesson, and the reason I'm calling it out explicitly in the report: always test robots.txt with the bare path, no query string, no cache-busting parameter. Anything else tells you what you want to hear.

What else the audit found

The robots.txt issue was the critical one, but a real audit checks the whole surface. Summary table:

The strong points are genuinely strong — this is a hand-built, zero-JS static site, so there's very little surface area for bugs. Which is exactly why the robots.txt cache issue stood out: it's the one failure mode that has nothing to do with code quality and everything to do with infrastructure you don't fully control.

The full sample report

I didn't want to just describe this in a blog post — the actual report, with headers, timestamps, and the full findings list, is published here: seo-audit-sample.surge.sh. It's the same format I'd hand to a paying client, evidence and all, minus the client's name. If you want to see what an "SEO audit report sample" looks like when it's built from a real site instead of a template with placeholder text, that's it.

Quick wins if you're checking your own site

• Fetch robots.txt and sitemap.xml with a bare curl, no browser, no query string. Compare against what's on disk.
• Check age and *-cache headers on anything served through a CDN — a HIT with a large age on a file you recently changed is a red flag.
• Keep titles under ~60 characters and meta descriptions under ~160 — both of mine were over, and both get silently truncated in search results with no warning from anything.
• Don't assume "it deployed successfully" means "it's serving correctly." Those are two different claims.

If you want one done on your site

This is genuinely my own site, audited with the same process I use for clients — no fabricated numbers, no invented scores. If you want a similar evidence-backed audit (headers, raw responses, no guessing) run on your own site, I'm doing these as a paid service, launch pricing starting at $0.10: alexcarter.privacy@proton.me.

Otherwise, go check your robots.txt right now, without the ?cb=.