How to Add an AI Chatbot to a Framer Website (2026)

Adding a chat script to Framer is straightforward. The harder part is deciding where it belongs, what it may answer from, and how a customer reaches a person when a website source is not enough.

Framer’s current Custom Code and Embed options support those two placement choices; the safe launch work happens around the snippet. This guide gives Framer founders, agencies, and small support teams a placement decision, a source map, and a nine-prompt test for a support chatbot. Framer-specific details were checked in August 2026.

A Framer chatbot is a support workflow, not a script

Framer can load third-party scripts through Project Settings → Custom Code. Its current guide specifically names chat and support widgets as examples, lets you choose where a snippet is placed, and lets you scope it to selected pages or run it on every page visit. (Framer: How to add custom code)

That is the delivery mechanism. It does not decide whether the chatbot has a current returns policy, whether it can see a customer’s order, or whether a failed answer has a human exit.

Before you paste anything, write down the first job the chatbot is allowed to do. A good first job is usually narrow:

• explain published pricing, inclusions, eligibility, or service areas;
• answer delivery, returns, booking, or product questions from a current policy page; or
• help a visitor find the right public guide, then offer a person when the guide is not enough.

Keep a separate list for questions that need private data or a judgment call:

• “Where is my order?”
• “Can you change my subscription?”
• “Will you make an exception to the refund policy?”
• “Why was my account charged?”

A chatbot grounded in public content can explain the general policy. It cannot truthfully inspect a particular order, account, payment, or appointment unless it has a verified connection to that system. Route those questions to a person rather than letting a content-only agent improvise.

For the broader operating model, see our website chatbot setup guide. The rest of this article is about the Framer-specific placement and release choices.

Choose Framer Custom Code for a floating launcher; use an Embed only for an intentional inline experience

Use Custom Code when the chat launcher should follow people across the site. It is the normal choice for a floating support widget: add the vendor script once in Project Settings, choose the placement, scope it to the relevant pages, and publish. Framer documents Custom Code as the site-level option for external scripts and support widgets. (Framer: How to add custom code)

Use Framer’s Embed component only when you deliberately want an inline support panel inside a particular layout, such as a help page or a member portal landing page, and the provider explicitly supports that implementation. Framer’s Embed documentation explains that scripts can be pasted into the component’s HTML field, but also cautions that some integrations need additional wrapping to function correctly. (Framer: How to add an iframe or embed script)

The practical choice is small but important:

• Sitewide floating support: use Custom Code. It is consistent across pricing, FAQ, and contact pages, and it avoids turning each page into a chat layout.
• A deliberate inline support surface: use an Embed only when the provider documents an inline embed or iframe. Give it a defined container and test it on the published page.
• Do not install both by accident: a global script and an inline instance can create duplicate launchers or confused visitor sessions.

Owlish currently provides a per-agent script for a floating web widget, so the Custom Code route is the relevant Framer path for Owlish. It is not a Framer-native integration, and this guide does not assume one.

Build a Framer Support Widget Placement & Source Map before you install it

The snippet should be the last operational decision, not the first. Make this small map first. It ties each placement decision to an answer boundary, so the agent does not inherit every old campaign page simply because it happens to be public.

Decision	Record before launch	Example
Widget placement	Sitewide Custom Code or one inline page	Floating launcher on pricing, FAQ, and contact pages
Safe question	The precise question the chatbot may answer	“What does the annual plan include?”
Canonical source	The one current page or file that proves it	Current pricing page, owned by RevOps
Out-of-scope route	What happens when a live system or judgment is needed	Order-status request → human support

Then add three fields outside the table for every canonical source: a named owner, a review cadence, and whether the source is public enough for a visitor to see cited. This exposes common launch problems early:

• A return window appears in both a policy page and a two-year-old promotion.
• A linked PDF contains the actual warranty terms, but the website crawl only sees the page that links to it.
• An “ask us” contact page looks like support content but does not contain an answer.

For Owlish, a website source discovers and ingests the main content of approved pages; use allow and exclude patterns to keep irrelevant URLs out. Linked PDFs are intentionally not ingested from a website crawl, so upload an important policy PDF as a separate source rather than assuming the crawler found it. (Website-source limits)

This map also gives a Framer agency an honest handover artifact: a client can update a page, but the owner of a business-critical answer and the human route are explicit instead of buried in a script field. For a repeatable agency kickoff, use our full AI chatbot client onboarding checklist.

Add the widget, restrict its domains, and leave room for fixed controls

Once the map is sound, the Framer installation is short:

1. Build and test the agent in the chatbot provider’s workspace. Add only the approved pages and source files from the map.
2. Copy the provider’s generated web-widget snippet without changing its agent identifier or script URL.
3. In Framer, open Project Settings → Custom Code, add a clearly named script, choose the relevant placement, and scope it to all intended pages. Framer’s custom-code guide documents page selection and run-frequency controls in that flow. (Framer: How to add custom code)
4. Publish to a test URL or a limited set of production pages. An editor preview is not the same as a real visitor session.
5. Test the published site in a private browser window at desktop and phone widths.

If you use Owlish, configure the web widget’s allowed domains before widening the rollout. With enforcement enabled, requests from domains not on the list are rejected; add your production host and each staging host you genuinely need for testing. Citation display is enabled by default, so you can decide whether a visitor should see source chips while retaining a way for the team to inspect grounding. (Web widget configuration)

Framer sites often have cookie controls, fixed navigation, an accessibility button, or a booking action in a corner. Test those controls with the launcher open and closed. Owlish’s script supports safe side and bottom offsets, while still allowing visitors to move the closed launcher if it overlaps a control:

<script
  src="https://widget.owlish.bot/loader.js"
  data-agent-id="agt_your_agent_id"
  data-side-offset="24"
  data-bottom-offset="88"
  defer>
</script>

Use the exact generated snippet from the Channels page; the example only shows the optional positioning attributes. Do not put a private API key or a custom browser-side AI call into Framer’s Custom Code. A support widget should load a provider-hosted script, not expose credentials in a published page.

Run the nine-prompt published-site test

Most Framer chatbot tutorials stop when the bubble appears. Do not stop there. Run this test on the published URL after every material policy, source, domain, or widget change, and record the prompt, expected result, actual result, source owner, and fix date.

1. Known answer: Ask a common support question from the map. It should answer directly and cite the current source.
2. Reworded answer: Ask the same question in customer language rather than using the page heading. It should still retrieve the right source.
3. Policy detail: Ask about a qualifying condition or exception. Confirm the cited page supports the exact condition, not just the main rule.
4. Unsupported question: Ask for information that is absent from the sources. The bot should say it does not have a current answer and offer a useful next step, not create one.
5. Stale-content probe: Ask a question whose answer changed recently. If an older page is cited, remove, repair, or exclude the competing source before launch.
6. Account-data boundary: Ask about a particular order, invoice, subscription, or appointment. Confirm it does not pretend to see a system it cannot access.
7. Human request: Ask to speak to a person and try a complaint or sensitive exception. Confirm the handoff reaches the right queue with useful context.
8. Domain check: Load the widget from each permitted production and test host, then confirm an unapproved host cannot use it when domain enforcement is on.
9. Phone layout check: On a phone-sized viewport, open the widget beside Framer’s fixed elements, cookie controls, and any booking or help button. Check that the close control, launcher, and underlying page actions remain usable.

Treat a wrong citation, an unsupported confident answer, or a failed human route as a release blocker. The fastest recovery is usually to fix the source boundary or escalation rule, not to rewrite the prompt until the failure is harder to see. Owlish’s citation guide explains how the cited chunk helps locate whether the issue is retrieval, a missing source, or stale content.

Where Owlish fits—and where it does not

Owlish is our product, so this is not neutral third-party editorial. The Framer workflow above is still the right standard regardless of tool: choose a support boundary, prove it on real questions, and make the exit to a person work before sending traffic to it.

For a Framer site, Owlish fits when you need:

• a no-code support agent built from selected website pages and separately uploaded support material;
• source-grounded answers with citations that can be inspected during testing;
• a per-agent web-widget snippet installed through Framer Custom Code; and
• a human route for questions content cannot safely answer. Visitors can ask for a person, the agent can initiate a handoff, and an operator can take over from the shared inbox on Growth and Scale. (Human handoff)

Owlish is not the appropriate first choice when the immediate requirement is authenticated account actions—such as an order lookup, refund, subscription change, or appointment change—and those systems need to be connected on day one. Start with a product or custom implementation that has the verified integration and operational controls for that action. Owlish is a strong fit for a grounded, no-code support front line around the questions your Framer site already documents.

Framer chatbot launch checklist

• Choose Custom Code for sitewide floating support, or an Embed only for a provider-supported inline experience.
• List the first questions the chatbot may answer and the questions it must hand off.
• Assign one canonical, current source and an owner to every safe answer.
• Upload any linked PDFs that contain support answers as files.
• Exclude old promotions, duplicate policies, and pages that should never be cited.
• Add only the intended production and test domains, then enable domain enforcement.
• Check the launcher against cookie, booking, accessibility, and fixed-navigation controls.
• Run all nine prompts on the published URL, including the human and phone-layout checks.
• Keep a short release record and rerun it after source or widget changes.

Frequently asked questions

Can I add an AI chatbot to Framer without writing an API integration?

Yes. Framer’s Custom Code feature supports third-party scripts, including support widgets. Configure the chatbot with the provider, paste the generated widget script in Project Settings, then publish and test the real page. A custom API build is a different project and should not put a secret key in the browser. (Framer: How to add custom code)

Should I use Framer Custom Code or an Embed for a chatbot?

Use Custom Code for a floating support launcher across several pages. Use an Embed only when you specifically need an inline chat panel and the provider documents that embed type. Avoid running the same widget through both routes at once.

Can a chatbot read PDFs linked from my Framer site?

Do not assume it can. A link on a web page is not always an ingested source. In Owlish, linked PDFs are excluded from website crawling by design, so upload a customer-facing PDF separately if it needs to support answers.

Can a Framer chatbot answer “Where is my order?”

Not from a public-site crawl alone. It can explain the shipping policy, but a real order-status answer needs verified access to the customer’s record. Route that question to a person or an authenticated support workflow.

What should I test before publishing a Framer chatbot sitewide?

Test a correct cited answer, a reworded question, a policy detail, an unknown question, stale-content behavior, an account-data request, a human request, domain enforcement, and the phone layout. The nine-prompt test above makes each check reproducible.

The takeaway

On Framer, Custom Code is usually the right place for a floating support chatbot. But the installation only becomes useful when the agent has a narrow, current source boundary, visible proof for its answers, and a human path for the questions it should not attempt.

If you want to use that workflow with Owlish, create an agent in the console, add the support pages and files from your Placement & Source Map, configure the web widget, and complete the nine-prompt test before you announce it.