Private AI and RAG Backend Architecture for WordPress

Why WordPress AI needs an architecture, not only a prompt box

Adding an AI button to WordPress is easy. Designing where content is processed, which endpoints are public, how grounding works, how model costs are controlled, and how a static frontend can call the backend safely is the hard part.

AI‑Kit starts with the least invasive path: local, on-device browser AI when available. That works well for editor-side rewriting, translation, metadata generation and lightweight tasks. But production websites often need more: fallback when local AI is unavailable, frontend chatbots, DocSearch, multimodal prompts, citations, knowledge-base grounding and protection against public endpoint abuse.

The AI‑Kit backend is the serverless side of that model. It moves backend AI execution into the customer’s AWS account instead of routing every request through the WordPress server or a shared plugin vendor runtime.

System boundary

WordPress editor / Media Library / frontend blocks
        │
        ├─ local mode when browser AI is available
        │
        ▼
AI-Kit JavaScript runtime
        │
        ├─ /admin/* routes for WP Admin and trusted operations
        └─ /frontend/* routes only when public features are enabled
                 │
                 ▼
          Amazon API Gateway
                 │
                 ▼
          AiHandlerFunction
  prompt, writer, rewriter, summarizer,
  translator, language detector, proofreader,
  upload URL helper and knowledge-base listing
                 │
        ┌────────┴────────┐
        ▼                 ▼
Amazon Bedrock        Knowledge Base pipeline
Nova models           S3 documents + S3 Vectors
Guardrails            DynamoDB debounce state
                      EventBridge scheduler
                      KnowledgeBaseSyncFunction

The frontend does not need model provider keys. WordPress does not need to proxy prompts through PHP. Static exports can still use frontend routes when those routes are explicitly enabled and protected with the selected public-access model.

What the AI‑Kit backend stack provisions

Endpoint surface: one backend, two trust zones

The stack’s most important product decision is the separation between admin and frontend routes. The same capability may exist in both zones, but the trust model is different.

The RAG pipeline

User question or DocSearch query
        │
        ▼
Prompt route receives request
        │
        ├─ validate auth / reCAPTCHA / WAF path expectations
        ├─ apply guardrail and input checks
        │
        ▼
Query builder predicts category, subcategory and tags
        │
        ▼
Bedrock Knowledge Base retrieval
        │
        ├─ optional strict metadata filtering
        ├─ optional rerank
        └─ retrieved snippets with citation spans
        │
        ▼
Answer template selection
        ├─ KB_ONLY
        ├─ ASK_WHEN_NO_KB
        └─ KB_PREFERRED
        │
        ▼
Bedrock generation with citations and grounding policy
        │
        ▼
AI-Kit renders answer, sources and highlights in WordPress UI

The key point is that RAG is not just “send documents to a model.” The backend has to decide what sources are allowed, how categories map to metadata, whether an answer may fall back to general knowledge, and how citation spans are returned to the WordPress interface.

Grounding policy is a product decision

Different content categories should not all behave the same way. A product documentation chatbot can answer from general knowledge when asked about a generic concept. A medical, legal, financial or internal policy assistant may need to refuse when the knowledge base does not contain an answer.

AI‑Kit exposes this through knowledge-base configuration rather than hard-coding one behavior for every site. Category policies, strict metadata filtering and prompt templates turn content governance into an operational layer that editors and developers can understand.

Knowledge Base ingestion lifecycle

A RAG system is only as useful as its ingestion lifecycle. For WordPress, that lifecycle starts in familiar places: posts, pages, custom post types, KB sections and editor-controlled source selection. The backend lifecycle starts when those documents are written to the S3 document bucket.

WordPress KB source selected or regenerated
        │
        ▼
Markdown document + optional metadata.json
        │
        ▼
S3 DocsBucket under documents/ prefix
        │
        ▼
S3 event or scheduled ingestion path
        │
        ▼
DynamoDB debounce lock/state
        │
        ▼
EventBridge Scheduler
        │
        ▼
KnowledgeBaseSyncFunction
        │
        ▼
Bedrock ingestion job updates Knowledge Base vectors

The debounce layer matters because publishing systems often update several files at once. Starting a full ingestion job for every small object event is noisy and expensive. A single sync worker with DynamoDB state and EventBridge scheduling gives the system room to batch changes into a more predictable ingestion rhythm.

Static export friendly AI

Static WordPress complicates many traditional plugin assumptions. The public visitor cannot call a WordPress AJAX endpoint if WordPress is not in the request path. AI‑Kit handles this by making frontend AI calls browser-to-backend calls, not browser-to-WordPress-to-model calls.

Authentication and protection matrix

Model selection and cost posture

The backend deliberately separates model choice from plugin code. Admin routes can default to a stronger model, while frontend routes can use a lighter model first and fall back according to stack parameters. That matters for agencies because public chatbot usage, editor features and document search usually have different cost profiles.

Operational runbook

1. Use the AI‑Kit Deployment Wizard to select only the frontend features, auth modes and optional protections the site actually needs, then open the prefilled CloudFormation Create stack review URL.
2. Choose auth mode per surface: IAM/Cognito for admin, NONE + reCAPTCHA/WAF or Cognito for frontend.
3. Copy the ApiBaseUrl stack output into WordPress → AI‑Kit Settings → API Settings, then connect any additional feature-specific outputs or identifiers required by the chosen backend mode.
4. Define KB metadata categories, subcategories and tags before publishing many documents.
5. Configure grounding policy for categories where hallucination risk matters.
6. Publish KB documents from WordPress and run or schedule ingestion.
7. Test editor, static frontend and authenticated/member flows separately.
8. Watch CloudWatch logs, metrics, DLQ and model-call latency before increasing public exposure.

What makes this different from a typical AI plugin

When this architecture is a good fit

• WordPress sites that need AI features without sending all content through a shared plugin SaaS backend.
• Static WordPress frontends that still need chatbot, DocSearch or frontend AI capabilities.
• Agencies building repeatable private AI deployments for clients with different content governance requirements.
• Documentation, support, healthcare-adjacent, legal-adjacent or enterprise sites where grounding policy matters.
• Teams that want AWS logs, IAM, WAF, guardrails, S3 document storage and model access in the customer account.

When not to use it

Related architecture articles

FAQ