Assistant should answer site, service, policy and guide questions from content you control. The Knowledge Base determines what can be retrieved; Page & service training helps a known customer phrase prefer the correct real destination.

Understand the content layers

Assistant 1.30.4 can use:

• selected public WordPress pages, posts, products and eligible public custom post types;
• WooCommerce policy and product knowledge when enabled;
• language-aware chunks built from rendered Gutenberg, Elementor and other supported page content;
• Custom Q&A entries stored in Assistant;
• Page & service training links that map a phrase to a specific published item;
• a live Content Graph used to understand page role, structure, parent/menu signals and relevant sections.

Training never makes a false page true. Correct the published source first, then rebuild.

Select authoritative sources

Open NAI Assistant → Settings → Knowledge Base.

1. Enable the Knowledge Base.
2. Select only public post types and specific pages Assistant is allowed to use.
3. Include WooCommerce policies if they are current and customer-facing.
4. Exclude drafts, private content, legal drafts, obsolete campaigns, internal procedures and duplicate translated pages.
5. Keep policy, product, service, guide and blog roles clear. Ordinary support questions should retrieve a real procedure or guide, not a semantically nearby blog post.

On multilingual sites, the active request language filters retrieval. Assistant supports language relationships from Polylang, WPML and TranslatePress and avoids presenting a translation from the wrong language as the primary source.

Configure source behaviour

Use Source relevance to decide how strict visible sources should be. Keep strict relevance for a new site. Set Maximum sources shown to a small number; two strong sources are more useful than a long list.

Leave Allow related sources when no direct-answer source exists off unless related reading has been manually tested. A related article must not be shown as proof for a factual answer it does not support.

Enable citations when visitors benefit from opening the underlying page. Visible destination cards should be actual pages, services, products or guides that support the answer.

Add Custom Q&A

Use Custom Q&A for a concise fact with no suitable published page—for example a controlled support contact or a temporary service rule.

• Write the question in wording customers actually use.
• Keep the answer factual and short.
• Do not duplicate a long policy that already has a maintained page.
• Add translated entries when the fact must be found in several languages.
• Review Q&A during every policy or contact change.

Use Page & service training

Under Settings → General → Page & service training:

1. Enter the customer phrase.
2. Select the exact published page, service, package or guide that should be preferred.
3. Save all Settings tabs.
4. Run the phrase in Knowledge overview & diagnostics.

Use training for recurring ambiguity such as a product-support phrase that otherwise retrieves a general article. Do not create dozens of near-duplicate rules before checking taxonomy, titles, headings and source quality.

Rebuild and maintain the index

Start a Knowledge Base rebuild after first setup, a provider/model change, source-scope changes or broad content migrations. The worker runs in background batches, retries temporary provider failures and preserves the previous usable index until the new job completes.

Individual published content saves can refresh affected knowledge. Deleted content is removed. After a material source correction:

1. update the public page;
2. refresh or rebuild the relevant knowledge;
3. clear the response cache;
4. start a new browser conversation;
5. verify the answer and visible source.

Changing the embedding provider or model requires a complete rebuild because vector dimensions and meanings are incompatible.

Diagnose retrieval

The Knowledge overview & diagnostics card shows source type, language, source count and chunk count. Enter a real customer question, select its language and run the diagnostic.

Check:

• whether the intended source was indexed;
• whether its language is correct;
• which section/chunk matched;
• semantic and lexical relevance;
• whether a training rule was applied;
• whether a role-mismatched blog/article was suppressed.

Test the exact symptom-led phrases customers use, including “where is,” “I can’t find,” “not working” and “error” together with the product or account surface.

Troubleshooting

• Source count is zero: confirm the Knowledge Base is enabled and the selected content is published and public.
• Wrong language wins: verify language assignment in WordPress/WPML/Polylang and rebuild language metadata.
• Old answer remains: update the authoritative page, rebuild and clear response caching before testing a fresh conversation.
• Blog appears during support: make sure the request is treated as support/guide intent and that a dedicated guide exists.
• A guide is not found: confirm the guide custom post type is public, queryable and selected; rebuild after custom-post registration changes.
• Build stays queued: inspect Action Scheduler/WP-Cron and Technical diagnostics, then repair the first provider or worker error.

Verification checklist

• Every indexed source is public, current and intentionally customer-facing.
• Product, policy, service and guide questions retrieve role-appropriate content.
• Languages stay isolated correctly.
• Custom Q&A contains no secrets or duplicated long policies.
• Training rules point to real published destinations.
• A deliberate unknown question is not answered from weak nearby content.