Kadence stores its blocks inside wp_posts.post_content using the standard block grammar with attributes for rows, columns, tabs, accordions, info boxes, and forms. SleekAI reads the rendered page at request time, so tab labels and panels, accordion question and answer pairs, info-box headings, and CTA copy all become structured text the model can use. There is no parallel FAQ document to keep in sync.

Display conditions scope each chatbot by post type, taxonomy term, user role, logged-in state, and URL pattern, so a pricing bot, a documentation bot, and a course-area bot can run on the same site under multibot. The SleekAI Wizard maps Kadence dynamic content fields, ACF, and custom post meta into named variables the prompt can reference, so values like a per-tier price or a per-feature ACF flag are always available even outside the rendered output.

Every conversation is logged inside WordPress with the model name, token usage, and the page it ran on. The JS API and PHP embed let you trigger the bot from a Kadence button or a custom layout module without rebuilding anything, and presets plus the guideline filter constrain off-topic chat by default.

Kadence sites tend to be marketing-heavy, with pricing tables, tabbed feature comparisons, and accordion FAQs that change as the team learns what converts. A chatbot trained on a static document goes stale the moment one of those blocks gets edited, and the cost is not just a wrong answer, it is a confidently wrong answer about a number that has changed or a feature that has been renamed. Visitors who came to the page specifically to compare plans leave with a worse impression than if there were no chatbot at all.

The fix is to read the live page. SleekAI takes the rendered output of every Kadence block on the current page, the tabs included, and passes it as context with the system prompt. Republish a Kadence page and the next conversation reflects the new copy without any extra step.

That removes an entire class of maintenance work from the marketing team's calendar. Pair it with display conditions per template and per role, and the bot stops being a single global widget and becomes part of each page's design. A pricing-page bot can focus on plan recommendations, a docs-template bot can lean on the article body, and a logged-in members bot can answer account questions against the user's own data.

Conversation logs surface the gaps so the team can fix block copy and prompts together rather than maintaining a parallel script.