For libraries above a few hundred articles, the practical pattern is OpenAI Files vector store. Mirror your articles into the vector store on publish (Agent Sync or a webhook handles this), and retrieval pulls only the relevant articles per turn. Token use stays predictable, accuracy holds, and you avoid the 'try to fit everything into the prompt' anti-pattern. For smaller libraries, raw read of the WordPress posts is simpler and just as accurate.

Yes. Fenced code blocks with language hints, syntax-highlighted snippets, JSON payload examples, structured tables, ordered and unordered lists, and section headings all flow into prompts intact. Replies can quote the real snippets back without re-indenting them, which matters for any technical help center where the value of a doc is in its exact code or its exact table of error codes.

Screenshots are referenced by alt text and image filename in the source content, so the bot can describe what a screenshot shows if your alt text is good and can point the visitor at the article for the visual. Embedded video the bot cannot summarise unless you provide a transcript in the article. The practical recommendation is to keep transcripts under fold on video-heavy articles - it helps SEO, accessibility, and the bot equally.

If your articles are translated and live as separate WordPress posts per language (WPML, Polylang, or native multisite), scope a bot per language by URL pattern or locale. Each bot reads the matching translation as its source. For un-translated content, the model still replies in the visitor's language, effectively translating the canonical English article on the fly - which extends coverage without translating every article.

It complements the existing search rather than replacing it. The search bar remains for the visitors who prefer to browse and for the SEO surface. The chatbot adds a conversational alternative for visitors who would rather describe their problem in their own words. Some teams put the chatbot as the primary entry and keep search as the secondary; others split by intent (search for browsing, chat for specific questions). Either pattern works.

Yes - articles restricted to logged-in users (or to specific plans, roles, or seats) can be included for the right users via display conditions and user role checks. A free-tier user gets the public-articles bot; a Business-plan user gets a bot that also knows the Business-plan-only articles. This avoids the awkward 'the bot answered about a feature you cannot access' pattern that public chatbots sometimes hit.

Yes, and arguably more. The articles themselves remain as the canonical pages search engines index. The chatbot is a navigation layer for visitors who arrive on the site, not a replacement for the SEO surface. In fact, conversation logs often surface high-intent search queries that should become new articles, which then themselves rank. The help center grows in response to real customer language rather than internal guesses about what to write next.

SleekAI reads articles on every request. Publish or update an article and the next chat reflects it. For vector-store backed setups, mirror on publish via a small WordPress hook or via Agent Sync. WordPress revisions on each article give you the audit trail of what the bot was reading at any specific date, which matters when a customer claims the bot told them something different than the current article says.