Gooten
Security & crawler-access rescue for a print-on-demand SaaS: from Grade F to Grade A, and from blocked-by-Cloudflare to fully readable by Google, ChatGPT, Claude and Perplexity — without breaking the site or spiking the hosting bill.
At a glanceGooten (an OrderMesh Inc. brand) had a WordPress-on-Kinsta site that was failing on security headers (Grade F) and — worse — every search and AI crawler was hitting a Cloudflare bot-verification wall instead of the actual content. AEO score was 0. DoodleWeb hardened the site at the application layer (HSTS, CSP, X-Frame-Options, Referrer-Policy, Permissions-Policy), tightened Wordfence, hid the WP version, moved the login to a private path, and coordinated with Kinsta support to disable the extra Cloudflare challenge rules that were blocking legitimate crawlers — while leaving Kinsta's baseline protection in place. Result: SecurityHeaders grade F → A, GPTBot / Googlebot / Claude / Perplexity now return a clean HTTP 200 with full HTML, zero malware, daily automated scanning on, and bot-driven hosting spikes controlled at the firewall level. Completed and verified June 2026.

Where they started.
Gooten had a failing SecurityHeaders grade of F — HSTS, CSP, X-Frame-Options and Subresource Integrity were missing, with Referrer-Policy and Cross-Origin-Resource-Policy flagged. Worse, every scanner and AI crawler was hitting a Cloudflare bot-verification challenge instead of the site, so external tools scored the site near zero: AEO 0, GEO 20, FAQ schema missing, AI crawler rules not configured. On top of that, an earlier unmanaged bot surge had spiked the hosting bill, so we couldn't just rip protection down.
What we built.
We hardened the site at the application layer so it protects itself instead of leaning on a blanket challenge page: implemented the missing security headers (HSTS, X-Frame-Options, Referrer-Policy, Permissions-Policy, Content-Security-Policy), updated all plugins to current stable releases, removed deactivated and duplicate plugins, hid the WordPress version, tightened Wordfence firewall + login-attempt limiting, moved the WP login to a private path, and scheduled an automated daily security scan. In parallel we rewrote robots.txt to explicitly welcome GPTBot, anthropic-ai (Claude), OAI-SearchBot, ChatGPT-User, Google-Extended, Googlebot, Meta-ExternalAgent, Amazonbot and PerplexityBot — then coordinated directly with Kinsta support to disable the extra Cloudflare challenge rules that were catching legitimate crawlers, while keeping Kinsta's baseline protection in place. Wordfence rate limiting was set to strict so the WordPress firewall carried the load the moment the Cloudflare challenge layer came down.
Where it landed.
SecurityHeaders grade F → A. Live crawl test `curl -I -A "GPTBot" https://www.gooten.com/` now returns HTTP/1.1 200 OK with the full HTML document and new security headers present, where it previously returned the Cloudflare challenge page. Sucuri SiteCheck confirms no malware, blacklist issues or critical vulnerabilities. Bot-driven hosting cost pressure is under control, with daily bot and bandwidth monitoring and an immediate revert path in place through the transition.
Theworkbehindthe launch.
Each engagement covers strategy, design, build, and post-launch care — orchestrated by a single senior team.
Barrierswehadto overcome.
A concise look at the constraints that shaped every decision in the build.
Security grade F
SecurityHeaders.com graded gooten.com at F. HSTS, X-Frame-Options, CSP and Subresource Integrity were missing; Referrer-Policy and Cross-Origin-Resource-Policy were flagged. The site was hardened only at the edge, not inside WordPress.
Crawlers blocked at the edge
Extra Cloudflare rules added previously — not Kinsta's default protection — were challenging Googlebot, Bingbot, GPTBot, Claude and Perplexity along with everything else. External scanners never got past the wall to the content, which is why UI, accessibility and AEO scans came back near empty.
AI readiness at zero
AEO score 0 and GEO score 20. AI crawler rules were not configured and FAQ schema was missing — largely because crawlers only ever saw the challenge wall, not the site.
Hosting bill under bot pressure
An earlier spike in the Kinsta hosting bill traced back to unmanaged bot traffic. We couldn't simply remove protection — we had to move protection into WordPress before touching the Cloudflare rules.
Whatwebuilt.
The pieces that shaped the final build — each tied back to a real business outcome.
Application-layer hardening
Implemented HSTS, X-Frame-Options, Referrer-Policy, Permissions-Policy and a Content-Security-Policy tuned for the site. SecurityHeaders grade moved from F to A. Hid the WordPress version, tightened Wordfence, moved the login to a private path, and added login-attempt limiting to cut brute-force noise.
Malware & vulnerability hygiene
Ran a full Wordfence malware and vulnerability scan and remediated the flagged issues. Sucuri SiteCheck confirms clean — no malware, no blacklist entries, no critical vulnerabilities. Scheduled an automated daily security scan going forward.
Crawler-friendly by design
Rewrote robots.txt to explicitly welcome GPTBot, anthropic-ai (Claude), OAI-SearchBot, ChatGPT-User, Google-Extended, Googlebot, Meta-ExternalAgent, Amazonbot and PerplexityBot — so search engines and AI assistants can read and cite the site.
Cloudflare cleanup with Kinsta
Coordinated directly with Kinsta support to disable the extra challenge rules that were catching legitimate crawlers, while keeping Kinsta's default Cloudflare layer in place. The root cause was surgically removed, not the whole protection layer.
Stability through the change
Set Wordfence rate limiting to a strict configuration so the WordPress firewall carried the load the moment the Cloudflare challenge layer came down. Bot and bandwidth analytics monitored daily through the transition, with an immediate revert path if anything looked off.
Whatchanged.
What changed for the team and their audience after launch — measured in real behavior, not vanity metrics.
- SecurityHeaders grade F → A
- Live crawl test returns HTTP 200 with full HTML for GPTBot, Googlebot, Claude and Perplexity
- AI crawler rules configured in robots.txt and live
- Sucuri SiteCheck: no malware, blacklist issues or critical vulnerabilities
- Automated daily security + malware scanning scheduled
- WordPress login moved to a private path with rate limiting
- Bot-driven hosting cost pressure controlled at the firewall level
- Daily bot & bandwidth monitoring with immediate revert path in place
Insidethebuild.
A few selected screens from the live product.
Theyfeltliketruepartnersandapproachedthisprojectwithalotofcareandprofessionalism.DoodleWeb'sworkresultedinzerosecurityincidents—theircommunicationwasincredibleandtheycompletedeverytaskontime.
Numbersweareproud of.
Specific, measurable, and pulled from production analytics (not assumptions).
