How to Add a Comment Widget to Framer
The script has a panel. The thread has a component. Neither one runs until you publish.
You need two panels in Framer and about five minutes. The loader script goes in Project Settings > Custom Code, the thread itself goes in an Embed component you drag onto the canvas, and both are documented Framer features rather than workarounds. The catch: code added through Settings does not run on the canvas or in preview, so nothing shows up until you publish and open the live site.
Framer gives both halves a real home
A hosted comment widget is always two pieces of markup: a script tag that loads the widget code once for the whole site, and an empty element marking the spot where the thread gets drawn. On plenty of builders, one of those two has nowhere sensible to live and you spend the afternoon fighting the tool.
Framer is not one of those. The script tag belongs in Project Settings > Custom Code, which injects it into every published page, or only the pages you pick. The empty element belongs in an Embed component: search for Embed in the Insert menu, drag it onto the canvas, paste HTML into it. Framer documents this exact pairing in its own Trustpilot walkthrough, vendor loader in Custom Code and mount markup in the Embed.
What Framer bills for, and what its pricing page does not list
No plan requirement for custom code turns up on the Framer pages checked on 2026-08-25. The comparison table on the pricing page has no custom code row at all, the help article on adding custom code names no plan, and the article on site plans never raises custom code. An undocumented gate is not the same thing as a documented absence of one, so read that as unconfirmed rather than as a promise about your account, and open the Custom Code tab in your own Project Settings before you build a plan around it.
Framer does document a different set of limits, and they sit close enough to matter. A free site publishes on the subdomain Framer generates for it and carries a Made in Framer banner, and connecting a custom domain takes a paid plan. Staging is Pro or higher, which decides more than it looks: on Free or Basic, the published site is the only place your script ever runs.
What the Embed ends up drawing
2 comments
- M
One line and done, did not expect setup to be this easy!
- J
Shared sign-in means nothing else to wire up. 👍
The comments widget drawing itself, sample thread included. One div inside a Framer Embed produces the same thing on your page.
Half one: the loader in Project Settings
Start from the address Framer publishes to
Framer chooses your first address, not you. Publishing generates a free subdomain and puts the site there, and a custom domain only attaches later, on a paid plan. Read the suffix off the address bar instead of copying it out of a tutorial: sites turn up on
framer.websiteaddresses, while Framer's own publishing help still calls it the framer.app domain. Whichever string is actually in front of you is the hostname to type into the BootSignal dashboard, spelled the way the browser spells it. Saving the entry puts a site id on the dashboard, and that id is the one piece of the two snippets below that belongs to your site alone.Open Project Settings > Custom Code
In the Framer editor, open Project Settings and select the Custom Code tab in the left sidebar. Click Add Script if you have not added any code yet, or the + icon if you already have snippets. Name it something like BootSignal loader, because this panel shows you a list of names and nothing else.
Paste the loader and choose where it goes
Framer asks where the code should be placed on your site. Its own vendor walkthrough puts a loader script in the Custom Code section at the start of the
<head>tag, and that is the placement to copy here. The tag carriesdefer, so the browser fetches it early and runs it once the HTML is parsed, which keeps a comment thread from delaying anything a reader is waiting on.<script src="https://bootsignal.com/bootsignal.js" data-site-id="YOUR_SITE_ID" data-lang="en" defer></script>Scope it, or leave it site wide
The same panel can restrict a snippet to specific pages. If comments only appear on your blog template, selecting those pages keeps the loader off your marketing pages. Planning to add other BootSignal widgets? Leave it site wide, because one loader powers all of them.
Once, or run on every page visit
Framer then asks how often the code should run, and this is the choice worth slowing down for. The help article states both options plainly: Once adds and executes the code a single time, such as when adding event listeners, while Run on every page visit executes the code each time someone visits the page. A new snippet starts on Once, which the December 2025 changelog for this panel describes as similar to how code ran previously and usable for third-party scripts.
That changelog sentence is written for the analytics case, where firing once per visit is exactly right. A comment thread is the other case. A published Framer site moves between pages without a full browser reload, so a snippet set to Once loads at the start of a visit and is never run again as the visitor clicks through the nav, while a client-side widget has to find its mount on whatever page is currently on screen.
One page with comments: Once is fine. Comments across a blog template or several pages: choose Run on every page visit. Learn the symptom now. If the thread appears when you load the post URL directly, then vanishes when you reach that same post by clicking a link inside the site, the install is not broken. The frequency is wrong.
Half two: the mount in an Embed component
Back on the canvas, open the Insert menu, search for Embed, and drag the component to where the thread belongs, usually below the post body and above the footer. The Embed takes either a URL or raw HTML. You want the HTML section.
<div data-bootsignal="comments" data-thread-id="page-key"></div>That div is the whole mount. Give the Embed a sensible width and let its height grow, because a thread gets taller as people post. Framer warns that some integrations need extra wrapping code inside the Embed; this one does not, since the loader in Custom Code does the work.
Choosing a thread id
The data-thread-id separates one page's comments from another's. Two pages sharing a value share a conversation, which is occasionally what you want and usually not. On a one-off page, hard-code it: data-thread-id="pricing". A CMS collection template is the trap, because one Embed serves every post and a literal value there merges the whole collection into a single thread. Check whether your Embed accepts a CMS field in the attribute value before you build a template around it.
Publish, then look at the real site
Framer states that custom code added through Settings will not appear in the preview, and its Trustpilot walkthrough gives the reason: scripts in the head and the body execute in a browser, not in the editor. Click Publish in the top right and open the live URL.
Check two things there. The thread renders with a sign-in prompt, and after signing in with Google you can actually post. If it renders but refuses your comment, compare the address bar against the domain in your dashboard, character for character and Framer subdomain included. It is usually a hostname nobody registered.
The install at a glance
| What you paste | Where it goes in Framer | Setting that matters | Visible before publish |
|---|---|---|---|
| Loader script tag | Project Settings > Custom Code > Add Script | Placement: start of <head>. Frequency: Run on every page visit for multi-page use | No |
| Comments mount div | Embed component, HTML section | None, it is static markup | No |
data-site-id | Attribute on the loader tag | One per site, from your BootSignal dashboard | Not applicable |
data-thread-id | Attribute on the mount div | One value per conversation, not per site | Not applicable |
Who ends up holding the comments
Three honest routes for a Framer site. Build it yourself, which means auth, a database, an API and a moderation screen before anyone types a word, and since Framer will not run server code, that stack lives somewhere else. Use an ad-supported hosted thread, where your readers pay in attention. Or pay for a hosted widget. The alternatives section compares hosted options with their current prices, which is where numbers belong.
What this costs on a Framer site
One subscription sits behind the site id in your Custom Code snippet: $20 per month or $200 per year per registered domain, every widget included, 31 paid widgets today and 31 free browser tools, plus whatever ships later. Nothing is metered by traffic, which is the line to hold a shortlist against, because a traffic-priced comment tool sends its largest bill in the month a post finally does well. Extra domains are a separate purchase.
- Threaded replies, so a conversation does not flatten into a stack of unrelated notes.
- Google sign-in, shared across every BootSignal widget.
- A moderation screen in the dashboard: delete one comment, or block the person who wrote it.
- A per-domain allowlist, so your site id only answers on hostnames you registered.
- Widget interface text in Korean, English and Japanese, chosen with
data-langon the loader.
One snippet in Custom Code, one div in an Embed, then Publish.
The second widget is one more div
The loader is not comments-specific. It powers every BootSignal widget on the site, so the next one costs an Embed and a single div, with no second script tag and no change to the bill. Reactions pair well with comments: most readers will never write a paragraph, and plenty of them will tap an emoji.
React with multiple emojis · one per user
Reactions, for the readers who will not write a comment. Same loader, one more div.
Four things are easier on day one than in month three. Register the exact hostname you publish from. Name the Custom Code snippet so a stranger recognizes it. Set the run frequency while you are still in the panel that offers it. And settle your thread id scheme before there are comments to lose, because the conversation is keyed to that string: change it later and you get an empty thread, with the old comments on the old id.
Questions people ask
- The thread is there when I open the post URL directly and gone when I arrive by clicking a link inside the site. What broke?
- Nothing broke. The snippet is running at the wrong frequency. A published Framer site moves between pages without a full browser reload, so a Custom Code snippet left on Once runs at the start of the visit and never runs again while the visitor clicks around, which leaves the mount div on the second page with nobody to draw into it. Open Project Settings > Custom Code, select the snippet and switch it to Run on every page visit. Once is only the right answer when the thread lives on a single page that readers reach by loading its URL.
- If I set Run on every page visit, does the widget get fetched again on every page?
- No, and it does not stack two threads on top of each other either. The loader tag carries
defer, so the first page pays for one fetch that blocks neither parsing nor rendering, and the browser serves it from cache after that. When the loader runs again it looks for mount points that have not been drawn yet, marks each one at the moment it mounts it, and skips anything already marked, so a repeat run on a page that is already showing its thread does nothing at all. The visible cost is the same on either setting: the thread fills in a beat after the surrounding page, because it fetches its own comments. - Nothing appears on the canvas or in preview. Did I paste it in the wrong place?
- Probably not. Framer states that custom code added through Settings will not appear in the preview, because those scripts run in a browser on the published site rather than in the editor. Publish and open the live URL. Staging is Pro or higher, so on Free or Basic that first look happens on the production site: put the Embed on a page nothing links to yet, check the thread there, and move it once the width and spacing are right.
- Can I do this on the Free plan?
- No plan requirement for custom code appears on any Framer page checked on 2026-08-25: the plan comparison table has no custom code row, the help article on adding custom code names no plan, and the site plans article does not raise custom code at all. Treat that as unconfirmed rather than as permission. What Framer definitely does gate sits right beside it: connecting a custom domain takes a paid plan, a free site publishes on the Framer subdomain with a Made in Framer banner, and staging starts at Pro. Your own Custom Code tab settles the question in about ten seconds.
- Every post in my CMS collection shows the same conversation, so what needs to change?
- One Embed on a collection template carries one literal
data-thread-id, and every post rendered through that template inherits it, so the whole collection reads and writes a single thread. A hard-coded value is the right answer on a one-off page such asdata-thread-id="pricing"and the wrong one here: on a collection template the string has to vary per post, so check whether your Embed accepts a CMS field in the attribute value before you build the template around it. Settle it before anyone posts. The conversation is keyed to that string, so changing it later opens an empty thread and leaves the existing comments on the old id. - What happens to the thread when I redesign the page?
- Nothing, as long as
data-thread-idstays the same. The conversation is keyed to that value, not to the layout or the URL, so you can move the Embed, restyle the section around it or rebuild the page and the same comments come back. Change the id and you start an empty thread.
Register the domain you publish from, then paste one line into Custom Code.
Services in this guide
Read next
Where these numbers come from
- Framer Help: How to add custom code (Project Settings, Custom Code tab, Once vs Run on every page visit) (checked 2026-08-25)
- Framer Help: How to add an iframe or embed script (Insert menu, Embed component, HTML section) (checked 2026-08-25)
- Framer Help: Previewing your site (custom code added through Settings does not appear in preview) (checked 2026-08-25)
- Framer pricing (no custom code row in the plan comparison table; custom domain requires a paid plan) (checked 2026-08-25)
- Framer Help: Embedding a Trustpilot widget (loader script in Custom Code at the start of <head>, mount markup in an Embed component) (checked 2026-08-25)
- Framer Help: Publishing your Framer website (Publish button, the subdomain generated at publish, staging on Pro and above) (checked 2026-08-25)
- Framer Help: Best use cases for each Framer plan (Free publishes on a Framer domain with a Made in Framer banner) (checked 2026-08-25)
- Framer Updates: Custom Code, 2025-12-15 (snippets in Project Settings; code is set to execute Once by default) (checked 2026-08-25)
