Skip to content

Audits And Prospect

Walkthrough Files Go in audits/ Subdirectory

From legacy section: Client Walkthrough

Pattern: Placed walkthrough deliverable files (01-04) in the client root directory instead of audits/. The skill template also showed files in the root, contradicting the established pattern from Ianniello Chauvin. Rule: All walkthrough deliverables (01-11) go in clients/[client-slug]/audits/. Only CLIENT_PROFILE.md stays in the client root. The /client-walkthrough skill template has been updated to enforce this. Date: 2026-03-07


Verify Industry Match Before Building

From legacy section: Prospect Analysis

Pattern: "Gray Electric Motor & Pump Repair Co." appeared in electrician heatmap results. Built a full analysis treating them as an electrician — wrong industry. Rule: Before building any prospect analysis, read the full business name. If it indicates a different service category, flag and skip. Don't compare cross-industry businesses. Date: 2026-03-05


Audit reset/clear paths when adding persistence-dependent features

From legacy section: SEO NEO / Workbook

Pattern: Shipped slug-reuse on retry — createReportPage detects an existing WP slug under the audits parent and PUTs the new content instead of POSTing a fresh orphan page. Worked correctly for fresh runs and /api/internal/retry?from=publish paths, but still minted new orphan slugs on operator rerun (POST /api/audit/:id/rerun). Root cause: the orchestrator's resetAuditForRetry() helper cleared report_slug + report_permalink as part of its "clear all transient state for a fresh attempt" pass. The slug-reuse logic depended on those fields surviving the reset, but they didn't. Required a follow-up edit (one line removed from the resetAuditForRetry SET list) to keep slug-reuse working on operator rerun. Rule: When adding a feature whose behavior depends on persistent row state surviving retries, audit every reset/clear path in the codebase — orchestrator helpers (resetAuditForRetry), retry routes (/api/internal/retry/:id full-restart branch), DB triggers, any explicit UPDATE … SET col = NULL SQL. Grep for the column name in all UPDATE and DELETE SQL before shipping. For each match, decide intentionally: (a) keep the field across reset (preserve the cross-attempt continuity), or (b) clear it as part of a genuine "fresh start" semantic. Document the choice in a comment at the reset path so future contributors don't re-introduce the bug. Date: 2026-04-29


Citation/directory audits — Perplexity has a 30-50% blind spot on spam-tier directories; Chrome MCP is the only reliable verifier

From legacy section: SEO NEO / Workbook

When auditing whether a business listing is live on a low-DA directory (Hotfrog, MerchantCircle, n49, GoLocal247, longbeachbiz, ehbact, ourbizdirectory, semantictrade, etc.), Perplexity's perplexity_ask tool returns "DEAD - no listing data" for two completely different reasons: (a) the listing was actually removed/never published, OR (b) the directory has anti-scraping protection (Cloudflare challenge, JS-only rendering, geo-block) that blocks Perplexity's crawler. The two cases are indistinguishable from the response. WebFetch returns 403 on the same set. The signal that you're seeing case (b) and not case (a): early-numbered items (top of the list) come back LIVE while middle/later items come back DEAD — that's anti-scraping fingerprinting, not actual deletion. Confirmed on Ianniello Chauvin LLP citation audit 2026-05-13: items #3-9 of the 101-list returned 7/8 LIVE; items #10-100 returned mostly DEAD; the pattern is too clean to be coincidence. Why: During Phase A audit of the IC citation inventory (215 claimed live), I extrapolated from a 5-correct/5-dead initial sample that the 101 numbered citations were mostly live and the 14 pre-existing scraped were mostly dead. Broader 27-listing sample contradicted this — many "DEAD" results were actually bot-blocking, not deletion. Came close to telling the client "your foundation is half-rotted" when the truth was "we can't verify with this tool." Ground truth requires a real browser. How to apply: 1. For citation/listing audits at scale, default to Chrome MCP (mcp__Claude_in_Chrome__*) — it renders JS, passes Cloudflare challenges, and behaves like a real visitor. Slower per-listing (~3-10s vs Perplexity's ~1s) but actually accurate. 2. Use Perplexity for the FIRST PASS of the high-authority directories only (Google Maps, Apple Maps, Yelp, BBB, Yext-network-syndicated) — these allow API-style indexing and Perplexity can read them reliably. Don't trust Perplexity on spam-tier directories. 3. Detection heuristic during audit — if a sample of N URLs returns >80% "DEAD" and you know the credentials worked when those listings were submitted, treat the whole batch as INACCESSIBLE and re-run via Chrome MCP. Don't extrapolate "they all rotted." 4. In any audit deliverable, separate "confirmed dead" from "inaccessible/can't verify" — these are completely different categories with different recommended actions (the first you let die, the second you re-check via better tooling). 5. Build into citation skill suite spec — the /citation-audit skill must use Chrome MCP for the spam-tier middle-band; Perplexity is only acceptable for high-authority directories that allow indexed reads. Date: 2026-05-13