PapaBear Hosting: AI-readiness retrofit for a live WordPress brand
PapaBear Hosting is OptimoWeb’s own WordPress hosting brand, and it had the same problem most established WordPress sites have: structurally invisible to AI crawlers, with no entity graph and no crawler policy. Instead of rebuilding it, we retrofitted it with a single mu-plugin — canonical Organization + WebSite schema, a single-source FAQPage rendered visibly and in markup, Speakable, OG/Twitter meta, an explicit robots allowlist for AI crawlers, and llms.txt manifests — plus a draft-first content engine that writes nightly and publishes nothing without human review. It is the retrofit path, demonstrated on ourselves.
At a glance
The real numbers.
| Metric | Number |
|---|---|
| mu-plugins added (files a rebuild would have required: entire theme) | 1 |
| Pages rebuilt or redesigned | 0 |
| FAQ questions single-sourced to visible HTML + FAQPage schema | 7 |
| AI crawlers explicitly allowlisted (GPTBot, ClaudeBot, PerplexityBot, …) | robots allowlist |
| AI-crawler manifests published | 2 (llms.txt + llms-full.txt) |
| Articles auto-published by the nightly content engine | 0 — every draft held for human review |
All numbers are first-hand — measured on our own build, not estimated.
On this page
The starting point
PapaBear Hosting is a live WordPress brand — ours, the hosting side of the house behind our managed hosting service. Like most established WordPress sites, it worked fine for humans and was nearly illegible to machines: no entity graph tying pages to one canonical organization, no FAQ markup, no Speakable, incomplete social meta, and no stated policy for AI crawlers at all. The usual agency answer is "rebuild it." For a working brand with live customers, that is often the wrong answer — the site did not need new pages, it needed a machine-readable layer over the pages it had.
The approach
The constraint we set: no rebuild, no theme surgery, no plugin sprawl. Everything ships as a single mu-plugin — a must-use plugin that WordPress loads always, that no admin can accidentally deactivate, and that touches no existing template. That makes the retrofit reversible, auditable, and cheap: one file tree to review, zero regressions to hunt across a redesign. It is the counter-case to the full rebuild documented in our own site’s case study — same AI-readability goals, opposite delivery path, and the practical version of what our AI-era SEO guide describes.
The single-source rule does the heavy lifting: the 7-question FAQ lives in one data structure, which renders the visible FAQ block on the page and emits the FAQPage schema. The markup can never drift from what a human sees — which is the failure that gets rich results revoked.
The stack
- One WordPress mu-plugin carrying the entire retrofit — no theme edits, no page-builder changes.
- Organization + WebSite entity graph with a canonical
@id, so every page references one root node. - Single-source FAQPage: 7 questions rendered visibly and emitted as schema from the same data.
- Speakable markup on answer-shaped copy, plus complete OG/Twitter social meta.
- Robots allowlist for AI crawlers — GPTBot, ClaudeBot, PerplexityBot and peers explicitly welcomed, not left to default.
- llms.txt + llms-full.txt manifests describing the brand for AI assistants.
- Draft-first content engine: nightly automated article drafting targeted at the hosting customer profile, every piece held as a draft for human review — nothing auto-publishes. The automation pattern is the same one behind our workflow-automation service and the n8n guide.
What shipped
The whole machine-readable layer went live on the existing site with zero pages rebuilt: canonical entity graph, visible-plus-schema FAQ, Speakable, social meta, the AI-crawler allowlist, and both llms manifests. The content engine drafts nightly on hosting topics — deliverability, backups, migrations — and its publish count is deliberately zero until a human approves each piece. That gate is a feature, not a limitation: auto-published AI content is how a brand torches trust, and a hosting brand sells nothing else. The same human-gate discipline applies to everything public-facing we automate.
Why this matters beyond our own brand: the retrofit path is the right recommendation for most working WordPress sites. If your site converts fine and your brand is established, you likely need the machine-readable layer, not a redesign — a fraction of the cost on our pricing page, and a different conversation than the budget-builder trade-offs or a ground-up build. It applies whether you run a hosting brand or a professional-services firm; the ownership economics behind it are in the 5-year math guide.
Outcomes
What this delivered — plainly.
- Full AI-readability layer live on an existing WordPress brand with zero pages rebuilt — delivered as one mu-plugin
- Organization + WebSite entity graph with canonical @id referenced across the site
- 7-question FAQ single-sourced: visible HTML block and FAQPage schema rendered from the same data — cannot drift
- Speakable markup and complete OG/Twitter social meta
- robots allowlist explicitly admitting AI crawlers (GPTBot, ClaudeBot, PerplexityBot, and peers)
- llms.txt + llms-full.txt manifests published
- Nightly draft-first content engine on the hosting customer profile — 0 auto-published articles, 100% human review before publish
Questions
FAQ
What is an "AI-readiness retrofit"?
Adding the machine-readable layer — entity graph with a canonical @id, FAQ schema matching visible content, Speakable, social meta, an AI-crawler policy, and llms.txt — to an existing site without rebuilding it. The pages stay; the structure around them changes.
Why a mu-plugin instead of a normal WordPress plugin or theme edits?
A must-use plugin loads always, cannot be accidentally deactivated from the admin, and touches no theme files. The whole retrofit lives in one reviewable unit, is reversible by removing one thing, and survives theme updates untouched.
Does the content engine publish articles automatically?
No — by design. It drafts nightly against the hosting customer profile, and every piece is held for human review before anything goes live. Zero auto-publishing is the point: automated drafting saves time, but a human decides what the brand says.
When is a retrofit the right call instead of a rebuild?
When the site already works for humans — it converts, the brand is established, the content is sound — but machines cannot read it. If the site is also slow, dated, or structurally broken, a rebuild wins; we will tell you which side of the line you are on.
Can this be done to my existing WordPress site?
Yes — this pattern was built to be repeatable: entity graph, single-source FAQ, Speakable, social meta, crawler allowlist, and llms manifests, delivered as one mu-plugin on your existing install, typically without touching your theme.
Have a WordPress site that works — but AI can’t read it?
The retrofit path adds the entity graph, FAQ schema, crawler policy, and llms.txt to the site you already have. No rebuild, one reviewable plugin.