How to Add a Comment Widget to Webflow Without a Backend

Webflow does have commenting, and it is not this

Results for this query get muddled because Webflow ships a commenting feature already. It lives in the Designer and it is for the people building the site: a designer leaves a note on a section, a client replies, the note gets resolved. None of it reaches a published page, and a visitor reading your blog post never sees any of it.

Public comments are a different problem with three parts Webflow does not solve: knowing who is writing, keeping what they wrote, and letting you delete the bad ones. The CMS stores content you author, and Forms collect submissions only you read. Neither of those is a conversation.

Read a live thread before you paste anything

Check your plan before you check anything else

Where each half goes

The loader and the mount element go to different places, and mixing them up is the usual first failure. The loader is site-wide and belongs in Site settings, Custom code tab, Footer code, which Webflow emits before the closing </body> on every page. Webflow recommends script tags go there rather than in Head code so they do not slow the load, and suggests async or defer for any external script that does end up in the head, which is why the loader below carries defer. The mount element is positional and belongs in a Code Embed element, dropped exactly where the thread should sit in the layout.

1. Register both of the hostnames Webflow gives you

   Every Webflow project gets a .webflow.io address the day it is created, and connecting a custom domain later does not retire it: the Code Embed article points you at that address as the staging domain for testing and feedback, and it keeps serving the published site after yourdomain.com goes up. You are therefore running two hostnames, and the widget replies only on hostnames listed in your dashboard. your-project.webflow.io is not a subdomain of yourdomain.com, so registering the live domain does not cover staging. Put both on the same site id, which is the value the loader carries in the next step. Each hostname counts as one domain on your plan, so if the custom domain is not connected yet, register the staging address first and add the live one the day it goes up.

2. Paste the loader once, site-wide

   Site settings, Custom code tab, Footer code field, then Save changes. Webflow emits that field on every page it publishes, including pages you have not built yet, so the tag is pasted once and never again. Each of these fields holds up to 50,000 characters, which a loader tag will never come close to.

   <script src="https://bootsignal.com/bootsignal.js"
           data-site-id="YOUR_SITE_ID" data-lang="en" defer></script>

   Copy

3. Drop a Code Embed where the thread belongs

   Open the Add panel, add a Code Embed element under the post body on your Collection page template, paste the mount element, then save and close the modal. Nothing else goes in here: the loader you already added finds this element and fills it.

   <div data-bootsignal="comments" data-thread-id="page-key"></div>

   Copy

4. Publish to staging and read the thread there

   Webflow says the effects of custom code appear in preview mode, which is true of the tag itself, but the widget adds a condition of its own: it compares the page hostname with your registered domains, and a Designer preview address belongs to Webflow rather than to you. Publish to your .webflow.io address and open it in an ordinary browser tab. On the canvas a Code Embed holding a script tag shows a placeholder box, which is expected and not a sign anything is wrong.

One template, a separate thread per post

Leaving data-thread-id="page-key" as written gives every post on the site the same conversation, which is rarely what anyone wants. The attribute is only a key, so bind it to something unique per post and the split happens on its own.

Inside the Code Embed editor on a Collection page, Webflow lets you insert a CMS field into the code. Put the cursor between the quotes of data-thread-id and add the post Slug field. Webflow substitutes the real slug at publish time, so a single template edit gives every post in the collection its own thread.

What arrives with the widget

• Threaded replies, so a discussion nests instead of flattening into a pile of separate notes.
• Google sign-in, shared across every BootSignal widget, so a reader who signed in to rate the post is already signed in to comment on it.
• No separate password to create or remember, because the Google account is the only sign-in involved.
• Hosted storage behind a per-domain allowlist, so the widget answers only on domains you registered and not on a copy of your page somewhere else.
• Moderation from your dashboard: delete a comment, block a poster.
• Interface text in Korean, English and Japanese, switched with data-lang on the loader.

Three ways to end up with comments on a Webflow site

If you are leaving an existing comment system rather than starting from nothing, the migration questions matter more than the feature list, and the Disqus alternatives page works through those.

What this costs next to the Webflow bill

A Webflow Site plan is billed per site. BootSignal is billed per registered domain, at $20 per month or $200 per year, with every widget included and nothing charged against traffic. If the post does well, the bill does not move, and adding a countdown or a reading progress bar to the same Webflow project later does not move it either. Hostnames are the thing that does move it: staging and live are two registered domains, and the dashboard sells further ones a domain at a time.

The loader is already there, so the next widget is one div

Everything else in the catalog rides the same script tag you just pasted. Two that earn their place on a Webflow blog post:

Start with the hostname, then the two Save buttons

1. The address in the browser bar has to be one of your registered hostnames. your-project.webflow.io and yourdomain.com are separate entries, and a Designer preview URL is neither, so a thread that is blank in preview and present on the published page is behaving correctly.
2. A placeholder box on the Designer canvas is normal for any Code Embed holding a script tag. Judge the install on a published URL.
3. Open the browser console on the published page. A hostname that is not registered says so there rather than failing quietly, and staging is the one people forget.
4. Confirm the site id in the loader matches your dashboard, including any typo introduced in the copy and paste.
5. Confirm the markup landed in a Code Embed and not in a rich text block, which renders the tags as visible text instead of running them.
6. Confirm you saved Site settings. The loader lives in a different screen from the embed, and saving one is not saving the other.