Why Notion needs a different chatbot path
Notion is the only major content platform in our integration matrix that does NOT run arbitrary JavaScript on its published pages. When you click Share, Publish, and put your Notion page on the web at a notion.site URL, Notion renders the page through its own front-end and intentionally blocks third-party scripts. You can connect Google Analytics through Notion's first-party Notion Sites tier, edit basic SEO meta, and add a simple navbar, but you cannot drop in a chatbot widget, a heatmap tool, or any third-party script.
This is a deliberate trust decision on Notion's part. The notion.site domain has hundreds of thousands of public pages, and allowing arbitrary scripts would expand the attack surface for the whole subdomain. It is also a real constraint for Notion-first teams that want a chatbot on their docs or handbook.
There are two practical workarounds, both well-trodden:
- Publish your Notion content through a third-party Notion-to-site tool that DOES allow custom code (Super.so, Potion.so, Feather, and others). These tools read your Notion workspace, render the pages at their own domain (or your custom domain), and let you inject scripts. ChatRaj drops in via a single script tag in the tool's global code area.
- Keep your public site on a separate platform (Webflow, WordPress, Framer, plain HTML), use Notion as the editorial source for the content, and let ChatRaj train on the live public version. The chatbot lives on the public site; the source of truth lives in Notion.
Both work. The first is faster if you are already publishing through Super or Potion. The second is the right call if your public site is not actually a Notion site, even though Notion is where your team writes.
Path A: Super.so (recommended for Notion-first teams)
Super.so is the most popular Notion-to-site tool and the one we get the most ChatRaj installs from. Two install options inside Super:
Option A1: Global Code (site-wide, recommended). In your Super dashboard, open your site, go to Settings, Code, scroll to Global Code. Paste ChatRaj's script tag into the Body section. Hit Save. The chatbot bubble now appears in the bottom-right corner of every page of your Super-published site.
Option A2: super-embed: code block inside Notion (page-specific). Super added this in April 2024: paste your script tag into a Notion code block on a specific Notion page, prefix the code with super-embed: on the first line, and Super will execute the embedded HTML and scripts when it renders that page. Useful if you only want the chatbot on certain pages (your docs root, but not your changelog, for example).
Use Option A1 unless you have a specific reason to scope the bot to one page. Site-wide is the default expectation for a chatbot widget.
Path B: Potion.so
Potion is the second-most-popular Notion-to-site tool and works similarly. Open your Potion dashboard, pick your site, go to Site Settings, Code Injection. Potion gives you Head Code and Body Code slots. Paste ChatRaj's script tag into Body Code. Hit Save. Republish your Potion site. The chatbot bubble appears site-wide.
Potion also has a Custom Code Widget feature for page-level scoping, but the global Body Code path is the standard pattern for site-wide tools.
Path C: Feather and other Notion-to-blog tools
If your Notion content is published through Feather (Notion-to-blog), Florafauna, Oncetable, or a similar tool, the same pattern applies: every one of these tools has a Custom Code or Site Code section that accepts arbitrary script tags. Drop ChatRaj's snippet into that section and save. The exact UI label varies (Custom Code, Site Code, Code Injection, Global Scripts) but the concept is identical.
For tools that do not expose a custom-code section at all (rare in 2026 but it happens), Path D below is the fallback.
Path D: Use Notion as a knowledge source, embed ChatRaj on a separate site
If your public site is built with Webflow, WordPress, Framer, Squarespace, or plain HTML, and Notion is where your team actually writes the content, the cleanest setup is:
- Publish the relevant Notion pages to the web (Notion's native publish, or via Super/Potion if you want a nicer presentation).
- In ChatRaj's dashboard, add those notion.site (or super-published) URLs as Sources. Submit the sitemap if you have one through Super; otherwise paste the individual page URLs.
- Embed ChatRaj's script tag on your actual public site (Webflow Footer Code, WordPress theme footer, etc.) per the install guide for that platform.
This pattern is common for teams whose Notion is the editorial layer for a marketing site, a help center, or a developer-docs hub published through one of those tools. ChatRaj reads the latest content from Notion (via the public URLs) and answers questions on whatever site your visitors actually land on.
Notion AI vs ChatRaj: which is which?
Notion ships its own AI feature (Notion AI) and operators sometimes ask whether they need ChatRaj if Notion AI already works on their workspace. The short version: they serve different audiences.
Notion AI is for the people editing your Notion workspace. It rewrites paragraphs, summarizes pages, generates content blocks, and answers questions about the workspace for logged-in editors. It is excellent at what it does. It does not, however, talk to your public website visitors. Anonymous visitors on your public Notion-published site cannot use Notion AI; it lives inside the Notion app for authenticated workspace members only.
ChatRaj is for those public visitors. The chatbot sits on your published site, answers questions from anonymous visitors using the same Notion content as its knowledge base, and captures leads when the bot can not answer something. The two products do not compete; they sit on opposite sides of the publish boundary. Notion AI helps you write the docs faster; ChatRaj helps your visitors find answers in the docs you published.
Why Path D works so well for editorial teams
Path D (Notion as source of truth, public site on a different platform) sounds like a workaround but is actually the cleanest setup for many teams. Three reasons it's worth considering even if Super or Potion could theoretically host your public site:
Editorial-publishing separation. Notion is excellent as a writing surface but its public-site rendering is constrained by the platform's design. Webflow, WordPress, Framer, and similar tools give you more control over typography, navigation, marketing-funnel components (pricing tables, testimonials, CTA blocks), and SEO meta. Keeping Notion as the doc editor and using a separate platform for the public site lets each tool do what it's best at.
Faster public-site updates without rebuilding. When you change a Notion page, Super/Potion republish their cached site, which can take seconds to minutes. If your public site is Webflow/WordPress with Notion as a source, your public-site rendering is independent of your Notion edits, and ChatRaj's content cache re-syncs on the schedule you control through the Sources page. This is preferable when you want full control over when changes go live.
Lower dependency stack. Path D removes Super or Potion as a hard dependency from your public site's uptime story. If Super goes down, your public site (Webflow/WordPress) keeps running. The only thing that pauses is the bot's ability to re-fetch new Notion content, and existing cached answers keep working.
Lead capture, ungated, plus docs-style use cases
Notion is heavily used for public help centers, developer documentation, and B2B knowledge bases. Two ChatRaj features map directly:
Lead capture for visitor questions the docs don't answer. When a visitor asks something the bot cannot answer from your Notion docs, the bot offers to take their email and follow up. The captured emails flow to a CSV export, a webhook, or your CRM via Zapier (planned). For a docs site that doubles as a marketing surface, this turns an "I don't know" moment into a sales lead.
Unanswered-question analytics. Every question the bot couldn't answer from your Notion content gets surfaced in the ChatRaj dashboard's Unanswered tab. For docs teams, this is a free editorial backlog: every unanswered question is content you should add to your Notion handbook. Most docs teams find 5-15 high-signal content gaps per month this way without doing any user research.
Privacy + GDPR
ChatRaj never trains models on your visitors' chat logs and never shares visitor data across customers. Each bot is fully isolated by chatbot_id; the only data we store about visitors is a random visitor_id cookie (used to give conversation continuity across page loads) and the messages they send.
For GDPR compliance on EU traffic, ChatRaj signs a Data Processing Agreement (DPA) with every paid customer. Visitor consent for the chat widget should fold into your site's existing cookie consent banner. If you are publishing through Super or Potion, both have cookie-consent integrations that can whitelist ChatRaj's domain. If you are on Path D (Notion as source, separate public site), apply the consent banner pattern from your public site's platform (Webflow, WordPress, etc.).
Working with Notion's content limitations
A few honest constraints to set expectations:
- Toggles, callouts, columns, and synced blocks render as inline content on public Notion pages, so ChatRaj's crawler sees them as part of the page text. No special handling needed.
- Databases (galleries, tables, boards) render their visible rows on the public page. ChatRaj indexes what's visible. Rows hidden behind filter views or pagination are not crawled.
- Embeds (Figma, YouTube, Loom) are referenced as URLs in the page HTML but the embedded media itself is not indexed. The bot can mention "we have a Figma file on X" but cannot answer questions about the content of the Figma file.
- Private workspace pages are invisible to ChatRaj. The bot only sees what you've made public. Publish the pages you want the bot to answer from, keep internal-only content private.
When you should NOT use ChatRaj with Notion
A few honest signals that ChatRaj might not be the right fit for your Notion-powered site:
- Your Notion content is entirely private (internal-only handbook). ChatRaj's crawler reads public URLs; for private Notion content you would need an internal-tooling chatbot with Notion API integration, which is a different product category.
- You're on Notion's free plan AND publishing through notion.site without a custom-code site tool. Custom code is blocked on plain notion.site URLs, so there is no install path without bringing in Super, Potion, or a similar tool first.
- Your visitor volume is fewer than 50 per month on the Notion-published site. At that volume the chatbot's value is hard to justify against your setup time. Focus on driving traffic first via SEO or content marketing.
For everyone else: the install path through Super, Potion, Feather, or via Path D is straightforward, and the free ChatRaj tier is enough to confirm whether the bot's answers from your Notion content are good enough before you spend a dollar.