Three accessible reading modes per page, in any language — AI-generated and SEO-safe.

A non-profit serving disabled populations needed every page on their site to be available in three reading modes: Standard, Plain Language (simplified vocabulary), and Easy Read (single-sentence blocks paired with custom icons for users with cognitive disabilities). Building these manually would mean thousands of hours of human work. Hosting them naïvely would tank SEO with duplicate content. And the site had to work in any user’s preferred language, translated on the fly.

I built a custom WordPress AI pipeline that solves all three at once. Here’s how practical WordPress AI integration looks when the constraints are real.

The situation.

The client serves a diverse population — multiple languages, multiple literacy levels, and a substantial percentage of users navigating with cognitive support needs. For their mission, accessibility isn’t a compliance afterthought; it’s the core deliverable.

The site already supported dynamic translation via Weglot. What it didn’t support was the cognitive-accessibility dimension. The team’s existing process for producing Plain Language and Easy Read versions of articles involved a chat-window LLM tool, a Word document, manual copy-paste back into WordPress, and a graphic designer custom-illustrating the icons that Easy Read content requires. The result was good. The cost was unsustainable. The volume of content they needed to make accessible was orders of magnitude larger than the manual process could support.

The constraints.

The project had three conflicting requirements I came to call the iron triangle:

Scaling. Every page needed three reading-mode versions. Each Easy Read version needed unique, contextually appropriate icons. Manual production was already maxed out. Bringing the system to scale meant a one-click pipeline editors could trigger from inside WordPress.

SEO. Naïvely hosting three versions per page (separate URLs, or hidden-but-present HTML) would trigger duplicate content penalties or dilute ranking signals. The alternate versions needed to be completely invisible to Googlebot but instantly available to human users.

Translation. The site already used Weglot for multi-language translation. Weglot translates the HTML payload at the server level. If we hid the Plain Language and Easy Read text from the server response to protect SEO, Weglot wouldn’t see it either — and non-English speakers would hit untranslated English when they toggled reading mode.

Solving any one constraint was straightforward. Solving all three at once required four systems — WordPress, the Claude API, Weglot’s translator, and Google’s crawler — to communicate cleanly in real time.

What I built.

A “Populate with AI” pipeline inside the WordPress editor.

Editors needed to stay inside WordPress. Context-switching to an external AI tool, copying output, and pasting back was the manual workflow we were eliminating.

I built a custom integration on the WordPress 7.0 native AI client (wp_ai_client_prompt()), wired into Advanced Custom Fields. On the post-edit screen, every page has a “Populate with AI” button next to its standard content. One click triggers a secure background process: it reads the Standard content, packages it with a custom system prompt, sends it to the Anthropic Claude API, and receives a structured JSON response containing both the Plain Language version and the Easy Read version — including raw SVG code for the per-sentence icons. The script decodes the response and writes it directly into the corresponding ACF Repeater fields.

What previously took a copywriter and a designer several hours now takes about 15 seconds, with zero manual data entry.

Asynchronous DOM injection to protect SEO.

Solving the duplicate-content problem meant the alternate reading-mode text never exists in the initial server response. When Googlebot crawls the page, it sees only the keyword-optimized Standard content.

For human users, I added a three-button UI toggle for reading mode. Clicking “Plain Language” or “Easy Read” fires a JavaScript request to a custom REST endpoint, which queries the database for the alternate content and returns it. The script swaps the visible content via DOM injection.

Because search-engine bots don’t click UI elements or trigger asynchronous fetches, the page’s ranking signals stay concentrated on the Standard content. The accessibility features are available to every human user; the SEO authority stays intact.

Race-condition handling with Weglot’s MutationObserver.

The translation problem turned out to be the most subtle. Since the alternate text never appeared in the initial page load, Weglot’s server-side translator never saw it.

I had to use Weglot’s client-side translation pathway instead. I designated a specific DOM container as the injection zone, registered its CSS ID with Weglot’s MutationObserver watch list, and made sure the JSON payload from the REST endpoint always landed inside that container.

The flow now happens in a fraction of a second: REST returns the English alternate content, the browser detects the DOM mutation, Weglot intercepts the new text, pings its own API, and replaces the English with the user’s preferred language. The user experiences a clean reading-mode toggle that’s also fully translated. Three systems coordinated, no visible seams.

ACF 6.8 Discoverable Content for a self-healing prompt.

The most notoriously fragile part of any LLM integration is forcing structured output. If Claude hallucinates a field name or wraps its response in unexpected markdown, the integration crashes.

I built the prompt against the new ACF 6.8 Discoverable Content feature, which exposes a machine-readable JSON schema of the Flexible Content layout. The script dynamically queries ACF for the current schema and passes it directly into the prompt as the required output format. The result is a self-healing pipeline: if the client adds a new sub-field to their Easy Read layout in the future, the prompt regenerates, Claude starts producing the new field, and no code has to change.

Role-based billing for grant transparency.

Because the client is grant-funded, transparent infrastructure ownership mattered. I set up a Role-Based Workspace in the Anthropic Developer Console, with the client’s organization holding the billing profile (prepaid credits with hard monthly limits, so they could never exceed their grant allocation). I held Developer-only access — enough to manage API keys and monitor token usage during the build, but with no claim on the infrastructure. The client owns the workspace outright and pays for AI usage at cost, no markup.

The outcome.

• Massive cost and time savings. What was a multi-hour, multi-person manual process is now a single-click, ~15-second automated one. Over the site’s lifetime, this saves tens of thousands of dollars in copywriting, data entry, and graphic design.
• Uncompromised SEO. The asynchronous-injection architecture means the site can offer rich cognitive-accessibility features without ceding a single ranking signal.
• Seamless inclusivity. Users from any language background, at any literacy level, with or without cognitive accessibility needs, can access the organization’s content instantly — with formatting and translation handled transparently.
• A platform the client owns. The infrastructure runs on the client’s billing account, against their API keys, in their workspace. No vendor lock-in. No “we’ll take 30% of your AI spend forever.”