We Sent a Prospect 4 Emails With Wrong Data (And Fixed Our Entire Audit Engine)

By Rylee Benson — May 31, 2026

Two days ago, I sent an email to Ally, a founder at a 20-year digital agency in Colorado. She replied to our cold outreach — which almost never happens.

Then I sent her a link to audit results that contained the wrong data.

Here is what happened, what broke, and how we fixed our entire audit engine.

The Setup

Outbound Autonomy runs automated website audits. You drop in a URL, and our engine scans across four signals: design, conversion, technical performance, and competitive gap. It is a free tool that takes about 90 seconds.

We were doing cold outreach to digital agencies in Colorado — sending personalized audit results as a warm intro. The pitch was simple: “Here is your agency’s real score, here is what is costing you leads, want to talk?”

Fifty of those emails went out. Zero replies.

Then we hit Big Orange Planet — a 20-year-old agency with a solid site. Ally, one of their team, replied. She wanted to see more.

This was the moment cold outreach is supposed to work. A warm reply to a cold email. I needed to nail it.

What Went Wrong

I sent Ally a link to our audit report page instead of putting the data inline. That was the first mistake.

When she clicked through, the audit engine showed a score that was different from what I’d quoted in my email. The schema analysis — which checks if your website tells Google what it does using structured data — flagged her site as having zero schema markup.

But her site was running Yoast SEO, which injects valid JSON-LD schema. The problem was in how our engine parsed it.

Here is what was actually broken in the audit engine:

1. Yoast’s @graph array wasn’t being traversed recursively.

Most schema generators — Yoast, Rank Math, various WordPress plugins — output their structured data as a @graph array inside a JSON-LD block. Our parser was only checking the top-level keys. If the schema data was nested inside a @graph, the engine skipped right past it. False negative: “No schema found.”

2. Page matching was brittle about trailing dashes.

We crawl a site’s pages to find core pages (About, Contact, Services, etc.). If the crawl found /contact/ but our page match regex expected /contact(or vice versa), pages got silently dropped. Ally’s agency had valid contact and services pages. Our engine said they were missing.

3. WAF 406 responses were being treated as successful pages.

Her agency ran behind a Web Application Firewall. When our crawler hit pages with restrictive WAF rules, the WAF returned a 406 Not Acceptable. Our engine interpreted that as “page exists, content loaded” — and moved on without flagging that it had received zero usable HTML.

The Four-Email Spiral

• Email 1: Initial outreach with wrong score and gated link.
• Email 2: “Here is the fresh audit — sorry, I sent a link instead of the data.” Still contained wrong schema analysis.
• Email 3: “Actually, let me re-run this.” Still broken.
• Email 4: “Engine is fixed now. Here is the correct data.”

Four emails. One warm lead. Zero confidence by the end.

Ally was gracious about it — agency people understand technical hiccups. But I knew we’d squandered something rare: a warm prospect who had proactively engaged.

What We Fixed

After the Ally fumble, I locked myself in the engine code. Three specific fixes:

Fix 1: Recursive JSON-LD @graph traversal

function extractSchema(url, html) {
  const blocks = html.match(
    /<script type="application\/ld\+json">(.*?)<\/script>/gs
  ) || []
  for (const block of blocks) {
    const parsed = JSON.parse(
      block.replace(/<script[^>]*>/, '').replace(/<\/script>/, '')
    )
    // NEW: traverse @graph recursively
    if (parsed['@graph']) {
      for (const node of parsed['@graph']) {
        analyzeSchemaNode(node)
      }
    } else {
      analyzeSchemaNode(parsed)
    }
  }
}

Simple change. Massive impact: from “no schema found” to correctly identifying LocalBusiness, Service, and Review schema on sites running Yoast, Rank Math, and similar plugins.

Fix 2: Dash-normalized page matching

Every URL in the crawl results gets normalized before comparison:

• Strip trailing slash: /contact/ → /contact
• Strip index.html: /contact/index.html → /contact
• Lowercase: /Contact.html → /contact

This alone recovered 2-3 missing pages on average per audit.

Fix 3: WAF 406 detection and retry

If the HTTP response is 406, the engine now:

1. Flags it as a WAF block
2. Retries with a different User-Agent header
3. If still 406, marks the page as “blocked by security” and moves on

The Hard Rules We Adopted

1. One reply per lead. No follow-up sequence. Send the email, include the data inline, and wait. If they reply, cool. If not, do not chase.
2. Data inline, never gated. Every audit result in outreach now includes the key data points directly in the email body. The link is supplemental, not primary.
3. Verify before send. Before any outreach email goes out, the audit engine runs through a verification pipeline: re-check the URL, re-parse the schema, confirm the score matches.
4. Know what your tool cannot see. WAFs, Cloudflare challenge pages, JavaScript-rendered sites — these create blind spots. Document them. Flag them when they occur.

The Result

The engine is now deployed at outboundautonomy.com. Audits are accurate. The same site that showed “no schema” and “7 missing pages” now correctly identifies valid JSON-LD and surfaces the real optimization gaps.

Ally never replied to email four. That is fair.

But the fix ripple effect is bigger than one lost lead. Every audit that runs through the engine now — for every prospect, every free scan, every Product Hunt user — is more accurate because of the bug we found when a warm lead forced us to look.

Running a website audit tool? Check your schema parser first. If you are not handling@graph arrays recursively, you are missing data on most WordPress sites.

Want to see if our engine finds the right data for your site? Run a free scan at outboundautonomy.com/audit — 90 seconds, no email required.