The default chatbot is a floating bubble in the bottom right. That works fine for marketing pages and a homepage hero. It does not work inside a 4,000-word docs page where the user is reading. It does not work in a sidebar widget that needs to be tall and narrow. It does not work on a partner site where you want the same brain answering questions on a different domain. The embed needs to flex to the surface, and most chatbot tools only ship one placement.

SleekAI ships four. The shortcode renders inline anywhere classic-editor content goes. The Gutenberg block places the chat as a first-class block with size and copy controls. The sidebar widget drops it into any widget area or block-themed sidebar. And the JS snippet runs the same chatbot on any HTML page anywhere, talking back to your WordPress install through the REST API. All four share the same underlying widget, so behaviour, theming, and analytics are identical regardless of where the chat actually lives.

The same bot brain powers all of them. A docs embed in a post and a JS snippet on a marketing partner site both read the same wp_posts and wp_postmeta rows, run against the same retrieval mode, and log conversations into the same WordPress table. You configure the bot once and decide per surface how it should appear. That is what embeddable should mean: not a single iframe with a chat in it, but a real surface integration that respects where the content actually lives.

The word embeddable has been flattened by tools that ship a JavaScript snippet and call it done. A real embed is more demanding. It has to live inside the editor experience of the site, respect the layout of the surface it sits on, theme cleanly without breaking the host CSS, log conversations in a way the host team can analyze, and degrade gracefully when JavaScript fails or the user is on a slow network.

Multiple placements is not a feature for completeness; it is a recognition that different surfaces need different shapes of the same chatbot. A floating widget on the homepage is a marketing tool. An inline embed in a docs article is a reading aid.

A sidebar widget on a publication is a quick-help affordance. A JS snippet on a partner site is a distribution channel. The same underlying bot can play all four roles if the embed surface is designed to let it.

SleekAI's embed surface treats placement as a first-class concern. The shortcode and Gutenberg block know they live inside a post and pull surrounding content as context. The sidebar widget knows it lives in a narrow column and lays out accordingly.

The JS snippet knows it lives outside WordPress and negotiates CORS, context, and threading explicitly. Building those four placements as variants of one widget rather than four separate products means consistency in behaviour, in logs, and in maintenance. That is what makes embeddable a useful word again.