Ran a fresh Screaming Frog crawl for the 2026-05-08 audit follow-up using the existing working wrapper path after the canonical runner failed on a missing .seospiderconfig. The first wrapper run produced no CSV exports because API connectors failed, so I reran with API connectors temporarily disabled, restored the config afterward, and ingested the clean crawl.
Fresh crawl: /Users/samaguiar/Documents/Codex/screaming-frog/2026-05-12
Ingest report: /Users/samaguiar/Documents/Codex/screaming-frog-ingest/2026-05-12.md
QA note: /Users/samaguiar/Documents/Projects/admin/_qa-queue/2026-05-12.md
Confirmed the old broken external URL strings from the prior fix have 0 remaining hits in the fresh external_all.csv. Confirmed LinkedIn now appears only as the company profile URL, https://www.linkedin.com/company/sam-aguiar-injury-lawyers/, with status 200 and 495 inlinks.
Published the Berea location draft page 57951 as Berea Personal Injury Lawyers, normalized the visible title/H1 wording away from the car-accident-specific draft language, purged Cloudflare for the URL, and verified /locations/berea/ public-live through Cloudflare with HTTP 200.
/contact-us/ is still challenged by Cloudflare for curl and Screaming-Frog-like fetches. Earlier Python requests checks with browser-like and Screaming Frog user agents returned 200, so the practical issue appears to be Cloudflare bot/challenge fingerprinting rather than a normal user-facing outage.
/about-us/bigger-share-guarantee/ is correct in WordPress and direct origin returns 200 for page ID 9286. Public Cloudflare edge still serves a stale cached 301 to /about-us/bigger-share-guarantee-kentucky/, which then returns 404. WordPress rewrite/cache flush, WP cache flush, Rank Math redirections cache truncate, WP Rocket domain clean, Cloudflare file purge, and Cloudflare purge_everything did not clear that stale edge object.
Cloudflare IP whitelist and zone access-rule tests were backed up, tested, and rolled back after they did not resolve the crawler challenge. Backup folder: /Users/samaguiar/Documents/Projects/admin/backups/cloudflare-screaming-frog-2026-05-12.
Berea publish backup folder: /Users/samaguiar/Documents/Projects/admin/backups/berea-publish-2026-05-12.
The highest-leverage next step is a Cloudways or Cloudflare Enterprise edge-cache support path for the Bigger Share Guarantee stale redirect, plus a targeted Cloudflare bot/challenge rule review for Screaming Frog access to /contact-us/. After those two edge-layer issues are resolved, rerun the full Screaming Frog crawl and ingest again to confirm the remaining 4xx queue is clean.
The execution portion is complete for safe autonomous fixes. One URL is now fixed live, the prior external URL batch verified clean, and the two unresolved items are edge-layer behaviors that resisted reversible API-level purge and rule tests.