AI Engine Pro - WordPress Plugin

Guide to Setting Up and Using AI Engine Pro in WordPress

AI Engine Pro is best thought of not as a one-click "add chat" button, but as a working layer between WordPress, external AI providers, site content, forms, visitors, and administrators. In this guide, we will look at how to prepare your site, which modules to enable first, where to check the results, how to build a useful chatbot or AI form, and how not to mistake a model, hosting, REST API, or cache issue for a plugin issue.

This guide is written for site owners, webmasters, editors, and developers who already understand why they want an AI tool in WordPress but want to roll it out safely. It does not cover purchasing, license activation, or ways to bypass paid features. The focus is on setup, practical use cases, result validation, limitations, troubleshooting, and choosing comparable alternatives.

The core idea is simple: first decide what outcome you want for the site, then connect the right AI environment, set limits, test the chatbot or form on a staging page, and only then expose it to live traffic. That order saves money on AI provider requests and reduces the risk of odd replies, leaking unnecessary context, or running into cache conflicts.

What Problem the Plugin Solves and Where It Is Most Useful

AI Engine Pro helps a WordPress site connect to external AI services and use those responses inside the admin panel, on the public site, in forms, chatbots, internal analytics, and integrations. According to the official sources, the product supports chatbots, content and image generation, AI Forms, embeddings, AI Copilot, Playground, internal and REST APIs, and in the Pro version adds advanced forms, a realtime audio chatbot, embeddings-based knowledge, advanced MCP tools, usage insights and control, and assistants.

It is important to understand how it works. The plugin itself does not include a language model and does not "think" on its own. It provides the interface, stores settings, collects context, sends a request to the selected provider, receives the response, and shows it to the user or administrator. That means response quality depends not only on AI Engine Pro, but also on the selected model, API key, provider limits, context, prompt, WordPress REST API availability, and hosting behavior.

In practice, the product fits four common use cases especially well. The first is a visitor-facing chatbot that answers questions about the site, help content, catalog, services, or current page. The second is AI Forms, where a user enters data and the plugin generates a personalized response: a recommendation, short plan, email draft, product description, or project idea. The third is internal editorial work: drafts, revisions, translations, writing assistance, and prompt testing. The fourth is technical integration through MCP, functions, the REST API, and filters, where AI needs not only to respond, but to interact with WordPress as a system.

For a small site, you can start with one simple chatbot and basic request limits. For an agency, store, or knowledge base, a more valuable setup might be a combination of separate environments for different tasks, embeddings for the knowledge base, AI Forms for fixed-outcome workflows, Insights for monitoring requests, and MCP access limited to trusted administrators. The more authority you give the AI layer, the stricter your validation and restrictions should be.

When AI Engine Pro Is a Strong Choice

The plugin is especially useful if you want to keep AI features inside WordPress instead of connecting a separate SaaS widget with its own user base, analytics, and embedding logic. That is convenient when editors already work in WordPress every day and the knowledge you need already lives in posts, pages, products, documents, or custom fields.

Another strong scenario is a site that needs more than one generic AI feature and instead benefits from a broader toolkit: chatbot, form, content generation, images, request analytics, embeddings, and the ability to connect multiple AI providers. In that case, AI Engine Pro becomes less of a "widget" and more of a shared AI infrastructure layer for WordPress.

Who This Product May Not Be Right For

If all you need is a simple support chat without model setup, knowledge management, prompts, or limits, a specialized SaaS chat tool may be faster to launch. If the site is not ready to work with external AI APIs, the owner does not want to manage request costs, or the hosting environment blocks response streaming, rollout will require more hands-on attention. Projects with strict legal requirements around personal data should also separately assess what information is being sent to an external provider and whether site policies allow it.

Pre-launch check: if you cannot clearly explain what data the user will enter, which model will process it, and where the request history will be stored, it is too early to put an AI tool on a public site.

What to Check Before Installation and First Launch

Preparation is not just a formality. AI Engine Pro touches external APIs, WordPress REST requests, public widgets, forms, user permissions, and sometimes caching. If you switch everything on immediately on a production site, the first failure may look like "the chatbot does not work," when the real cause is a blocked /wp-json endpoint, the wrong provider, an unavailable model, aggressive JavaScript optimization, or missing limits.

WordPress Technical Readiness

Start with the basics: the site should be able to handle REST API requests normally, the administrator should have access to the plugin menus and Meow Apps settings, and the public-facing site should not break chatbot scripts through minification or deferred loading without exclusions. The official documentation for live website issues directly ties chatbot functionality to the WordPress REST API: if /wp-json is unavailable or requires authorization for visitors, the public chat may not respond.

On a test page, open your browser developer tools and check for JavaScript errors and HTTP responses with authorization or server error codes. If the site is protected by a security plugin, firewall, REST API restriction, or complex cache rules, test temporarily on a page where you can control those rules.

AI Provider Readiness

AI Engine Pro supports multiple AI services through environments. The official tutorial notes that after installation, an OpenAI environment may be created without a key, and additional environments can be added for different services and tasks. That is useful, but it requires discipline: do not mix a test environment, an image model, a text model, and an embeddings model into one chaotic setup.

For the first launch, one text-based environment that passes a quick connectivity check is enough. After that, you can add separate environments for vision, image generation, Anthropic, OpenRouter, local Ollama through an add-on, or a vector database for embeddings, if you actually need those workflows. An error like "You exceeded your current quota" usually points to the provider or its limits, not to the plugin itself.

Data Policy and User Roles

Before going public, decide what data can be sent in an AI request. For a simple FAQ bot, public page content is enough. For a form involving personal data, an internal assistant, or MCP access, you need to restrict who can use it, enable limits, and avoid sending anything to the model that should not leave the site. This is especially important for MCP: the documentation describes Bearer Token authentication and a choice of exposed tools, which means the token must be stored as a secret and the tool list should stay minimal.

Installation and Initial Validation Without Unnecessary Risk

For a typical WordPress plugin, the basic path is standard: upload the ZIP or install from the directory, activate it, open the settings, and connect the AI environment you need. AI Engine Pro has one important nuance: the official first-chatbot guide warns that the Pro version should not be kept active alongside the free version, because running both can create problems. This article does not cover licensing steps, but the operational takeaway is simple: the site should have only one active version of the product.

After activation, do not start by placing the widget site-wide. First open the plugin dashboard, enable only the modules you actually need, and configure the AI environment. If you are testing a chatbot, select the environment and model in the chatbot settings or use defaults. If you are testing AI Forms, enable the Forms module and build the form on a private or draft page. If you are testing MCP, start with the smallest possible toolset and no public exposure.

First Steps After Activation

1. Open the AI Engine settings area and make sure you can see the dashboard, server/client modules, and the tabs that match the features you enabled.
2. Create or verify the environment for your chosen AI provider, then run a connectivity test from the plugin interface.
3. Select default environments for the tasks you plan to use: text responses, images, vision, or embeddings.
4. Create a separate test page and place the first chatbot via block or shortcode rather than using site-wide mode.
5. Enable Insights before going public so you can see requests, errors, tokens, and limit behavior.
6. Check the public page in guest mode, in another browser, and with caching enabled.

This order gives you a clear cause-and-effect chain: if the environment test fails, the problem comes before the chatbot. If the test passes but the block does not respond on the page, check the REST API, cache, JavaScript, and selected chatbot ID. If the chat responds but does not answer based on site materials, move on to instructions, content-aware, or embeddings.

How to Tell the Basic Setup Worked

A minimal successful test looks like this: the admin panel saves the environment, the quick test returns a response, the test chatbot answers in preview or on a private page, the browser console shows no REST API errors, and Insights records a new request entry. If streaming is enabled, the response may appear gradually; if your hosting or provider does not handle streaming well, temporarily disable it and compare the behavior.

Do not launch a site-wide chatbot right away. First validate a single embed on a test page. A global widget across all pages makes troubleshooting harder because different templates, cache layers, load conditions, and third-party scripts start influencing the result.

Detailed Setup After Installation: Environments, Modules, Limits, and Request History

The most useful part of configuring AI Engine Pro is not the chatbot appearance, but the underlying control model. You need to understand which environment handles which task, which modules are enabled, where the plugin stores request data, and how usage is limited. Without that, the chatbot may work in testing but become expensive, unpredictable, or awkward on a public site.

Environments for AI and Default Environments

The official tutorial explains that environments let you connect different services: OpenAI, Azure, Google, Anthropic, OpenRouter, HuggingFace, and other supported options. Default environments help assign specific environments and models to different tasks. That is better than changing the model manually in every place, because plugins, custom code, and AI Engine's internal features can all use the configured defaults.

For a typical site, start with three layers. The first is a "primary text environment" for the chatbot and forms. The second is an "experimental environment" for model testing and prompt engineering in Playground, so you do not alter the behavior of the public tool. The third is a "separate embeddings environment" if you are using Pro knowledge with Pinecone, Qdrant, Chroma, or OpenAI Vector Store. Do not give environments identical names. A month from now, you should still know which one powers the visitor chatbot and which one is only for editorial use.

What to Enable Right Away

• One production text environment that passes a connectivity test and is not used for risky experiments.
• A default model for the chatbot and AI Forms, if those will be your first public-facing features.
• Streaming only after you have checked your hosting and the behavior of the selected provider.
• Separate environments for embeddings or images only when you are actually using those features.

What Not to Enable Without a Reason

Do not enable every module "just in case." The more modules are available, the harder it becomes to read the interface, diagnose problems, and explain to editors where everything lives. Public REST API, MCP, function calling, advanced assistants, and extra add-ons are best enabled only for a specific use case. Be especially careful with features that let AI or an external application take actions in WordPress rather than only return text.

Insights, Statistics, and Queries Data

Insights is not just for pretty dashboards. The documentation notes that through Queries you can see scope, user, model, tokens, price, and additional metadata, while Queries Data and Queries Form Data let you store details of submitted and returned data. That helps verify which chatbot or form is actually making a request, which model is being used, and which input parameters were sent to the AI.

On the other hand, storing detailed queries increases the size of your local database and may include data users entered into forms. So enable that storage intentionally: for testing and troubleshooting it is useful, but for long-term public use it should be evaluated against your data policy, retention rules, and administrator access controls.

Limits for Guests, Users, and the Entire System

The official documentation separates limits for users, guests, and the system. That makes sense: a guest, a logged-in user, and the site as a whole carry different risks. For a first public launch, a request-count limit is usually enough; a cost-based limit is not always necessary. Cost limits are harder to manage because providers and models calculate usage differently, and in some cases the estimates may not be precise.

A practical starting point: give guests a strict limit, logged-in users a softer one, and use the system limit as a global safeguard against errors, bots, looping code, or unexpected traffic. Then review Insights after a few days and adjust the values based on real behavior.

Rolling Back a Questionable Setting

If the site starts behaving strangely after enabling a feature, rollback should be fast. First disable the public output of the specific chatbot or form, then turn off streaming, then temporarily disable the module you enabled most recently. Do not delete data or change multiple settings at once. One step, one check. Otherwise you will not know what actually fixed the problem.

For a production site, it is helpful to keep a short change log. The article does not need dates, but in your admin notes it is worth recording which environment, model, chatbot ID, page ID, and limits were in use during each test. When an error like "not responding" or "context was not injected" appears, those notes can save hours.

Chatbots, Content-Aware, and Knowledge: How to Get Answers Based on Your Site Content

A chatbot in AI Engine Pro can be a simple model interface or a smarter assistant that receives page context, user input, and knowledge-base content. The difference is fundamental. If you just add a polished widget with no context, the model will answer from general knowledge and may confidently invent details. If you configure instructions, content-aware, or embeddings, the chatbot has a real chance to answer based on your materials.

Three Knowledge Levels for Your First Chatbot

The first level is instructions. This is where you define the role, response boundaries, style, no-invention rule, and escalation behavior. For a services site, that might mean "answer only based on information from the site; if the answer is unavailable, suggest contacting a specialist." The second level is content-aware. The official tutorial shows the {CONTENT} placeholder, which injects the cleaned text of the current page into the context. That works well for questions about a specific article, service, or product page.

The third level is embeddings. The Pro documentation explains that the user request is vectorized and then relevant embeddings are added to the chatbot context. This is not "database search" in the traditional sense, but a way of selecting relevant fragments that the model can use when generating a response. Embeddings are useful when the chatbot needs to remember not just one page, but many posts, help articles, contacts, rules, catalog entries, or an entire knowledge base.

Why Content-Aware Sometimes Misses the Page

One critical nuance from the documentation: content-aware and Knowledge Push pull content from the WordPress post record, not from the final HTML a visitor sees after a builder, ACF, shortcode, or third-party plugin has done its work. If important text is not stored in the standard post content field, the chatbot may not see it. You can validate this through Dev Tools and the content retrieval button, and in shortcode-based scenarios the resolve shortcodes option may help. For more complex fields, a developer can use the mwai_contentaware_content($content) filter or a separate Content Parser add-on.

This is a classic case where AI Engine Pro is working correctly, but the site itself is more complex than a standard WordPress post. So do not judge knowledge quality based on a single question. First verify what content is actually reaching the request, and only then adjust instructions, the model, or embeddings.

Embeddings in Pro: What to Check Before Importing a Knowledge Base

Embeddings require an environment and, depending on the service you choose, an external vector database. The official tutorial mentions Pinecone and Qdrant as examples. Before doing a full sync, test a small set: one contact block, one service page, one FAQ fragment. Then ask the chatbot questions in the language a visitor would use, not just the exact admin headings.

The embeddings troubleshooting documentation includes several useful checks: whether a knowledge environment is selected in the chatbot settings, whether the minimum score is too low or too high, whether there is a maximum number of embeddings to add to the context, whether embedding requests appear in Insights, and whether retrieved context shows up in the Discussion tab. It also mentions the vector dimension mismatch error, where the index dimension does not match the embeddings model. That cannot be fixed with a prompt; the model and index must match.

How to Validate Chatbot Results

Create a short set of test questions: one with an exact answer on the page, one based on knowledge-base content, one outside the site topic, and one that tries to break the instruction rules. A successful setup does not mean the chatbot answers at length. It means it answers within the boundaries of the available context, acknowledges missing information, and does not invent links, prices, addresses, or terms.

If the chatbot responds too generically, check the instructions and whether context is actually present. If it responds confidently but incorrectly, tighten the instructions and add an explicit rule against making things up. If embeddings are not being used, check the selected knowledge environment, query mode, and context max length. If responses are too slow, do not rush to blame the plugin: the official guidance on long response times and streaming notes that delays often depend on the provider, distance, hosting, and SSE support.

AI Forms: When a Form Is Better Than a Chatbot and How to Build a Working Flow

AI Forms is one of those features people often underestimate. A chatbot is useful for open-ended conversation, but not ideal when you want one structured result from a known set of inputs. The official documentation explicitly explains that AI Forms works well for scenarios where you need to create a custom response based on user input, such as a quiz or decision tree, and that this is often easier than trying to train a chatbot to guide the user step by step toward a single outcome.

What the Form Is Built From

AI Forms use Gutenberg blocks. The documentation describes the container, fields, submit prompt, and output. The container holds the layout and styling, fields collect user input, submit prompt sends the request template to the AI, and output displays the response. Field values can be inserted into the prompt using curly braces: if a field is called WORD, then {WORD} will be replaced with the user's input.

If the site uses a third-party page builder and building the form directly in the post is inconvenient, you can enable Forms Editor and insert the form via shortcode. This is an important practical detail: there is no reason to break the page just to force Gutenberg if the form can be built in a separate editor and displayed wherever the builder allows it.

Practical Example: A Recommendation Form for a Service Page

Take a concrete use case: on a consulting service page, you want to give visitors an initial recommendation based on their project type. You are not collecting personal documents or promising legal or medical advice. The form should ask about the project area, the goal, the main constraint, and the preferred answer format, then return a clean next-step plan.

Goal

Return a short personalized suggestion on the service page: what to prepare before reaching out, which consultation format to choose, and which questions to ask the specialist. That reduces low-quality inquiries and helps the visitor understand whether the service is a good fit.

Preparation

• Enable the Forms module and make sure a working environment is selected for text responses.
• Create a test page with no indexing or limited access so visitors do not see the draft.
• Define the fields: PROJECT_TYPE, GOAL, LIMITATION, and FORMAT.
• Decide whether form data should be stored in Insights. It is useful for troubleshooting, but for public use you should evaluate it against your data policy.

Steps

1. Add an AI Form Container and choose a base theme so the form does not look like raw HTML.
2. Inside the container, add the fields: a select for project type, an input or textarea for the goal, a select for the limitation, and a select for the response format.
3. Add AI Form Submit and compose a prompt with placeholders: "Write a brief recommendation for a {PROJECT_TYPE} project. Goal: {GOAL}. Constraint: {LIMITATION}. Response format: {FORMAT}. Do not promise a precise outcome if there is not enough data."
4. Add AI Form Output and specify its selector or ID in the submit settings so the response is rendered in the correct block.
5. Open the page as a guest, submit the form, and verify that submit blocks duplicate submissions while processing and that output receives the response.

Validation and a Common Nuance

Check more than just whether the response looks good. Validate empty fields, required field behavior, resubmission, markdown rendering, data logging in Insights, and the effect of caching. If the response appears in the wrong place, the issue is usually the output selector. If the form was built inside a page builder, first confirm that the shortcode is rendering the correct form, then move on to JavaScript and theme conflicts.

When Not to Use AI Forms

Do not turn AI Forms into a substitute for a critical application form, payment form, legal questionnaire, or medical decision flow without separate review. The AI response should be a suggestion, draft, recommendation, or interactive helper, not a final action with real consequences for the user. If the result must be strictly deterministic, use a conventional form with validation rules first and only then, if needed, add AI as a supporting text layer.

Validating Results Before a Public Launch

After setup, it is easy to fall into a trap: the administrator sees a response in preview, assumes the task is done, and puts the chatbot or form on every page. For AI Engine Pro, that is not enough. You need to validate not only whether a response appears, but also the request path, context quality, guest behavior, Insights logging, limits, and theme impact. Otherwise the first real problem will show up for a visitor rather than on the test page.

The best approach is to run validation as a short acceptance test: define in advance what counts as a successful result, which errors are acceptable during testing, and which parameter you change after each failed run. That matters even more for AI tools because the model can produce persuasive text even when the wrong context was injected.

Testing the Chatbot with Four Types of Questions

For the first chatbot, prepare a small set of questions. Do not rely only on ideal wording copied from your admin interface. Visitors are imprecise, abbreviate names, confuse sections, and ask in conversational language. Your test set should reflect that.

• A question with an exact answer on the page where content-aware is enabled. Here the chatbot should answer from the current page material, not from general knowledge.
• A question based on the knowledge base or embeddings. Here you want to see that the retrieved fragments were actually added to the context.
• A question outside the site's topic. A good answer here is a polite refusal or a suggestion to contact a human, not a fabricated response.
• A question that tries to bypass the instructions. This is not a test of perfect security, but of how resilient your baseline restrictions are.

After each response, check Insights and the Discussion tab if they are enabled. You need to know which model answered, which chatbot ID was used, whether an embeddings request occurred, and whether the request exceeded a limit. If the answer is good but Insights is empty, you are likely checking the wrong layer or did not enable storage for the data you need.

Testing AI Forms for Repeatability

AI Forms need a different testing approach. There is less conversational freedom, but more risk around fields, the output selector, and resubmission. Test the form with at least three data sets: a normal user input, an empty required field, and a long input with unnecessary detail. If the submit prompt uses field names in curly braces, make sure every placeholder is being replaced with a real value.

Also test how the form behaves after an AI provider error. A good interface should not get stuck in an endless submitting state. If the result block stays empty, inspect the output selector, browser console, and query log. If the form is inside a page builder, test it both as a logged-in administrator and as a guest, because builders sometimes alter markup or script load order.

Testing Limits and Guest Behavior

Limits are best tested before the public launch. Set a low guest limit on the test page and submit several requests as a guest. You should see a limit-reached message and a record in Insights. Then test a logged-in user with a different limit. This will show whether AI Engine Pro really distinguishes between guests, users, and the system, rather than applying one generic rule to everyone.

Do not guess at production limits. If the site gets little traffic, a strict daily guest limit may be perfectly fine. If the chatbot is built into a busy help center, a limit that is too low will create the false impression that something is broken. The right configuration usually comes after several cycles: test limit, review Insights, adjust, retest.

Performance and Streaming Testing

Streaming makes chat feel smoother, but it depends on the model, provider, hosting, and SSE support. Test the same request both with and without streaming. If the response is stable without streaming but breaks with it, the issue may be in the hosting environment or network layer. If both modes are slow, reduce the prompt, context, or number of embeddings, or choose a faster model.

Do not judge speed based on a single question. Use one short question, one page-context question, and one embeddings-based question. That helps you see what is actually slowing things down: the model, content injection, knowledge retrieval, or page rendering. For a public launch, stability matters more than the typing effect. If streaming causes errors, disable it for now and come back to it later.

MCP, REST API, and Function Calling: Powerful Modes for Careful Users

One reason AI Engine Pro stands out is that it is not limited to a widget on a public page. It can act as a bridge between WordPress and external AI applications through MCP, while also exposing a REST API and developer tools. That is powerful, but it is also where user roles, tokens, available tools, and a clear understanding of consequences matter most.

MCP as AI Application Access to WordPress

The documentation describes the MCP server as a structured API-like interface through which an application such as ChatGPT or Claude can see tools and perform actions: retrieve data, update content, and manage WordPress entities. In the AI Engine settings, you need to enable MCP, set a Bearer Token, and choose which tools will be exposed.

For an administrator, that opens workflows like "prepare a post draft," "review media," "build a list of pages without descriptions," or "help with content." For a developer, it creates a way to build custom MCP tools. But for a public site, this is not a feature you simply "turn on and forget." The Bearer Token must remain secret, and the tool set should be limited to what a specific trusted application actually needs.

When to Use MCP and When to Use Function Calling

MCP is a better fit when an external AI application needs to work with WordPress as a set of tools. Function calling makes more sense when a chatbot inside the site needs to trigger a specific prebuilt function, such as checking available times, verifying a record status, or returning data from an internal catalog. If the task can be expressed as a single controlled call, there is no need to expose a broad MCP layer.

A good rule is this: the broader the access, the fewer the users and the more detailed the logging should be. For a public visitor, use a chatbot or AI Forms with limits. For an editor, use Copilot, Playground, or an internal assistant. For an administrator, use MCP and REST only after testing, with restricted access and a clear rollback path.

Public REST API and Access Security

The Public REST API documentation states that it is disabled by default. When enabled, requests must be authenticated, and access is also governed by AI Engine limits. Examples that expose a function to all users are flagged as undesirable or requiring caution. For most use cases, the practical takeaway is simple: enable Public REST API only for a specific integration, and do not expose endpoints publicly without authorization.

If a developer is building an external application, use a nonce or a dedicated Bearer Token, permission checks, and separate limits. Do not store secrets in JavaScript visible to every visitor. Do not connect external systems until it is clear what data they send and which WordPress user is treated as the actor behind the action.

Practical Use Ideas for Different Types of Sites

AI Engine Pro works best when you do not try to turn on "AI everywhere," but instead choose one clear scenario that fits the site type. Below are several workable directions based on confirmed capabilities: chatbot, forms, embeddings, usage insights, editorial AI tools, and controlled integrations.

Knowledge Base or Services Site

For a knowledge base, start with content-aware on articles and embeddings for core support materials. The chatbot should help users find answers, not replace navigation. In the instructions, add a rule that it should refer only to available materials and acknowledge when data is missing. Validate results with real visitor questions such as "how do I sign up," "what documents do I need," or "what should I do if the email never arrived."

Content Site and Editorial Team

For editors, Copilot, Playground, and templates are useful for drafts, translations, revisions, and shorter text variations. That said, AI responses should not be published automatically without editorial review. A better approach is to make AI Engine Pro a preparation tool and leave the final decision to a human who can verify facts, tone, links, legal wording, and brand fit.

Landing Page with Interactive Recommendation Flow

On a landing page, AI Forms is often stronger than a chatbot. The visitor enters three to five parameters, gets a personalized suggestion, and understands the next step to take. This flow is easier to control because the prompt is structured in advance and the output appears in a known place. Add guest limits and check whether you are storing unnecessary personal data in Queries Form Data.

Administrative Workflows and Agency Use

MCP and the developer API are especially interesting for agencies and technically hands-on site owners: they can automate drafts, reviews, media handling, SEO tasks, and internal operations. But those workflows should not be introduced on a live site without staging, a backup, and limited tools. The AI tool should support the administrator, not receive unrestricted permission to change everything at will.

Quick takeaway: for public visitors, choose chat or AI Forms; for editors, use Copilot and Playground; for knowledge workflows, use embeddings; for developers, use MCP, REST API, and filters. Do not mix these access levels together in your first rollout.

Safe Enhancement: Conditional Chatbot Output via Shortcode

The official documentation for the first chatbot shows several display methods: the site-wide feature, shortcode, and block. It also describes the idea of shortcode override for display conditions. This is a useful and safe pattern if you want to show AI chat only where it genuinely helps, such as in your help center, on service pages, or inside an account area.

Below is a small example for Code Snippets or a child theme. It does not modify WordPress core or plugin files. Replace the $allowed_pages array with the IDs of the pages where the chat should appear, and verify the chatbot ID in the shortcode. If you are not using default, use your own ID from the Chatbots tab.

add_shortcode( 'site_help_ai_chat', function () {
    $allowed_pages = array( 42, 105 ); // Page IDs where the AI chat should appear.

    if ( ! is_page( $allowed_pages ) ) {
        return '';
    }

    return do_shortcode( '[mwai_chatbot id="default"]' );
} );

After adding the snippet, insert the [site_help_ai_chat] shortcode on a test page. Check the page in a guest browser, then open a page that is not included in the $allowed_pages array. The chat should appear on allowed pages and stay hidden everywhere else. Rollback is simple: disable the snippet or remove the shortcode from the page.

This approach is useful when site-wide mode is too broad. For example, a chatbot may belong in the help center and on a service page, but not on checkout, on the privacy policy page, on heavy landing pages, or anywhere another interactive widget is already in use. If you use caching, clear the cache for the affected pages after changing the conditions.

Why AI Engine Pro May Not Work and How to Find the Cause

Troubleshooting AI Engine Pro should happen layer by layer. First check the AI provider and environment, then the WordPress REST API, then the plugin module, then the page output, then the cache, theme, and third-party optimization. If you start changing the prompt, model, design, and server settings all at once, you may accidentally hide the real cause.

The chatbot works in the admin area but not on the live page

Symptom: preview in the settings responds, but the visitor sees an empty widget, a send error, or endless loading on the live site.

Possible cause: the WordPress REST API is blocked or restricted, the public request requires authorization, a security plugin is blocking the endpoint, or the theme or optimizer is breaking the JavaScript. The official troubleshooting page for live website issues explicitly points to the role of the REST API.

What to check: open /wp-json, inspect the Network tab in the browser, temporarily disable JavaScript optimization on the test page, and check the page as a guest. If requests are being denied for authorization reasons, look for a security rule or a REST API restriction.

How to fix it: allow the required REST access for the public workflow, exclude the page or scripts from aggressive optimization, disable site-wide mode, and test the block or shortcode on a single page. If the cause is on the hosting side, provide support with the exact URL and the Network error.

Content-aware is not injecting page text

Symptom: the chatbot is supposed to answer based on the current page, but behaves as if it cannot see the page content.

Possible cause: the text is stored outside standard post content, in a builder, ACF, shortcode, meta fields, or a third-party component. The documentation explains that content-aware pulls data from the WordPress post record, not from the final rendered HTML.

What to check: enable Dev Tools in the AI Engine settings, use the content inspection tool, and see whether the {CONTENT} placeholder was replaced with actual text. If the text is missing, the problem is not the model.

How to fix it: enable resolve shortcodes if the content comes from a shortcode. For ACF and more complex builder structures, use the Content Parser add-on or the developer filter mwai_contentaware_content($content). If there is no quick fix, do not promise page-aware answers to users on that page.

Embeddings exist, but the chatbot is not using them

Symptom: the knowledge base is in place, but responses stay generic or the chatbot does not find the right fragment.

Possible cause: the knowledge environment is not selected in the chatbot settings, the minimum score or max embeddings values are poorly tuned, context max length is too small, the embeddings request is not being executed, or the vector index dimension does not match the model.

What to check: use Query mode in the Knowledge tab, use Insights to confirm the embeddings request, and check the Discussion tab where the injected context is visible. Make sure the query is phrased the way a visitor would ask it, not only as the exact post title.

How to fix it: select the knowledge environment in the chatbot, tune the score and number of embeddings, increase context max length, and align the embeddings model with the index. If the error mentions a vector dimension mismatch, fix the model or the index, not the prompt.

Provider quota or limit error

Symptom: the response says the quota or limit has been exceeded, or that the request cannot be completed.

Possible cause: billing details are not configured with the external provider, limits have been exhausted, the selected model is unavailable, or the error was cached. The quota documentation stresses that AI Engine does not include its own models and depends on the external service.

What to check: run a request in AI Playground or directly in the provider dashboard, check the environment test, temporarily clear the page cache, and review Insights and the actual model being used.

How to fix it: correct the provider settings, switch to an available model, define limits in AI Engine, and clear the cache. If the error appears only in the public widget, check whether the site cached an older response.

Responses are too slow or streaming does not work

Symptom: the user waits too long for a response, streaming output never appears, or it cuts off mid-response.

Possible cause: provider latency, distance to the service, a model with long response times, hosting without proper SSE support, a proxy, or a firewall. The official hosting and streaming page ties streaming to Server-Sent Events support.

What to check: disable streaming and compare the standard response, try a lighter model, test on different hosting or staging, and inspect network requests.

How to fix it: use a faster model, shorten the prompt and context, temporarily disable streaming, and confirm SSE support with your hosting provider. If the delay comes from the AI provider, the plugin cannot speed it up on its own.

Request history or form data is missing

Symptom: you expect to see query details or form input in Insights, but the data is not there.

Possible cause: Insights is enabled, but Queries Data or Queries Form Data is not enabled, or the request never reached AI Engine.

What to check: whether the required options are enabled in Settings, whether the request itself appears in Queries, whether there are REST API errors, and whether the correct chatbot or form is selected.

How to fix it: enable data storage only for the duration of troubleshooting or in line with site policy. If the data is sensitive, collect the minimum necessary set and restrict administrator access.

When AI Engine Pro Is the Right Choice

AI Engine Pro is worth using if you need a controlled AI layer inside WordPress: one product for chatbots, AI Forms, embeddings, editorial tools, usage insights, APIs, and careful integrations. It is especially strong when the site already lives in WordPress and the team wants more than an external widget. It lets you connect AI to content, roles, limits, and admin workflows in one place.

Do not start with the maximum setup. First configure the environment, test a simple chatbot or AI Form on a test page, enable Insights, set limits, and confirm that the REST API, cache, and hosting are not getting in the way. Then add content-aware, embeddings, MCP, and developer workflows. That path is slower on day one, but it gives you a clearer result with fewer surprises.

If, after reading this guide, you already know which scenario you want to test first and which checks you will run before going public, you can download the installation package and prepare a safe trial run on staging or a separate test page. Make the final decision based not on the feature list, but on how reliably the product answers questions about your site, stays within limits, and avoids making life harder for editors.