Home›Guides›How to Add a Comment Widget to Wix

How to Add a Comment Widget to Wix

The element that looks built for this is the one that breaks it. Body-end Custom Code is the way in.

Mr. Latte
Updated

You can run a real comment thread on Wix, just not through the Embed Code element that looks like it was built for the job. That element is a sandboxed iframe served from a Wix domain, so a widget that checks which site it is on, and asks the visitor to sign in with Google, sees an origin that is not yours and stops. The route that works is Custom Code at Body - end: the loader, plus a few lines that build the mount element and drop it under a container you choose. Custom Code needs a published site with a connected domain, so a paid Wix plan is the price of entry.

First, the plan gate

Wix never writes the sentence "custom code requires plan X." It writes two others that add up to one. The developer docs say a site must be published and have a connected domain before custom code runs. The help center says connecting your own domain requires buying a domain and a Wix site plan. So a free wixsite.com site cannot use Custom Code. The panel is visible, the code just never executes.

No upper tier is required, though. Wix lists Light, Core, Business and Business Elite, and writes that "All plans allow you to have a custom domain," so the entry-level tier clears the gate. Light is the entry-level plan in that lineup, which is a position in the list and not a claim about price: Wix publishes no dollar figures on the help pages consulted here and says Premium prices differ by geographic location, so ranking the tiers by cost is not something this guide can do honestly. The gate is the custom domain, and every paid plan carries one. Wix Studio sites use a separate Studio lineup on the same logic. Check the real numbers on your own account, where they are priced for where you are.

What you are installing

Here is the widget itself, running on this page. Post something if you want to see the whole loop. Mounted correctly it looks the same on a Wix page, because by then it is just a div on your site.

Preview

2 comments

Add a comment…
Commenting as AlexPost
  • M
    Maya2h ago

    One line and done, did not expect setup to be this easy!

  • J
    JordanYesterday

    Shared sign-in means nothing else to wire up. 👍

The thread with sample replies in it. Google sign-in and dashboard moderation come with the install rather than with this preview.

Why the Embed Code element cannot run it

Two editors, two different walks to the same element, so name yours before following anyone's instructions. In the Wix Editor: Add Elements, then Embed Code, then Popular Embeds, then Embed HTML, then Enter Code and Apply. In Wix Studio: Add Elements, then Embed & Social, then Embed Code, then Enter Code and Apply. Studio is the one with the Embed & Social group; the classic Editor files the same thing under Popular Embeds and calls it Embed HTML. Either way a box lands on the canvas, you paste HTML, the HTML renders, and it looks like the obvious home for anything that has to sit in a specific spot.

Wix says otherwise in its own docs: the HTML element creates a sandboxed environment, an iframe, with no direct access to the other elements on your page, and widgets that need access to the rest of the page will not work in it. Inside that box you are not on your site. You are on a Wix sandbox origin drawn inside your layout.

That breaks a comment widget twice over. It reads location.hostname and compares it against the domains registered to your site id, which is what stops a stranger from lifting your embed onto their site. Inside the iframe that hostname belongs to Wix, so the check fails. Google sign-in separately validates the origin of the page requesting it, and the origin is the sandbox rather than your domain. Neither is patchable. The sandbox exists precisely so that code inside it cannot claim to be your page.

The failure is quiet, which is the part that costs you an afternoon. No red error in the editor. An empty box on the published site, or a sign-in popup that opens, closes, and leaves the visitor signed out.

QuestionCustom Code, Body - endEmbed Code element (HTML iframe)
Where the code runsYour real page, on your domainA sandboxed iframe on a Wix origin
Does location.hostname read as your domainYesNo, it reads as the sandbox
Can Google sign-in completeYesNo, the origin is not yours
Can you place it exactly in the layoutOnly by script, using a selectorYes, you drag the element
Can it touch the rest of the pageYesNo, only postMessage crosses the boundary
Plan neededPaid Wix plan with a connected domainNone documented, and free-site use is not documented either
Visible in editor or previewNo, published site onlyYes, after you click Apply
Works for a hosted comment widgetYesNo
Wix splits an ordinary widget install across two features, and only one of them can host this one.

Builders differ here, which is why one widget has a different install per platform. Webflow's embed element is not sandboxed, so there the mount div goes straight onto the page: the Webflow install is the short version of this story.

The install that works

Custom Code reaches three places: <head>, body-start and body-end. None of them is "under the post body." So the script builds its own mount element and puts it where you want it. That is the whole trick, and it is about five lines on top of the loader.

  1. Register the connected domain, the one Wix already decided for you

    On other builders this step is a decision: staging host or live host, apex or www, one of several addresses the site answers on. Wix takes the decision away, and for once that helps. Custom code does not run until the site is published on a connected domain, so the domain that switches the feature on is the same domain the widget has to recognize, and there is exactly one of it. Add that hostname in the BootSignal dashboard exactly as it resolves in the address bar, www and all, and the dashboard issues the site id the snippet below needs. The wixsite.com address is not the alternative to register: it is the address you are on while custom code is still inert.

  2. Open Custom Code in the site dashboard

    This panel lives in the site dashboard, not on the editor canvas, and the path is identical in Wix Editor, Wix Studio and Wix Harmony. Go to Settings, find Custom Code under Development & integrations, then click + Add Custom Code at the top right.

  3. Paste both snippets into one entry

    Loader and mount script go in the same text box. Set data-site-id to your site id and TARGET to a CSS selector for the element the thread belongs under. Name the entry something you will recognize later, like "BootSignal comments."

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

<script>
(function () {
  // CSS selector for the element the thread should be appended to.
  var TARGET = '#comments';
  var timer;

  function mount() {
    var host = document.querySelector(TARGET);
    if (!host) return;
    if (host.querySelector('[data-bootsignal="comments"]')) return;
    var el = document.createElement('div');
    el.setAttribute('data-bootsignal', 'comments');
    // One thread per URL. On Wix Blog this is the post slug.
    el.setAttribute('data-thread-id', location.pathname);
    host.appendChild(el);
    // Ask the loader to scan again, in case it already ran.
    if (window.BootSignal && window.BootSignal.activate) window.BootSignal.activate();
  }

  function schedule() { clearTimeout(timer); timer = setTimeout(mount, 150); }

  // Wix warns its renderer may re-render elements, so watch instead of firing once.
  schedule();
  new MutationObserver(schedule).observe(document.body, { childList: true, subtree: true });
})();
</script>

  4. Choose the pages and the position

    Under Add Code to Pages pick All pages, including future pages, or Choose specific pages if only the blog needs threads. Under Place Code in pick Body - end. With All pages selected Wix offers one more choice, in its own words whether to load the code "only once per visit, or on each page your visitor opens." Wix documents the choice without documenting when to pick which, so treat it as a dial rather than a rule: start on once per visit, and if a thread appears on a fresh load but not after clicking through from an index, move it to each page and republish.

  5. Apply, publish, then open the live site

    Custom code does not take effect in the editor and only runs on the published site, and snippets do not appear as elements on the canvas, so there is nothing to look at until the site is live. Apply, publish, open the real URL, scroll to your target.

The December 2025 security layer

One more thing belongs in the same breath as "paste and publish," because it decides whether pasted code runs at all. Wix's custom code page carries this notice: "In December 2025, Wix introduced new frontend security measures for custom code on Wix sites. This means that some code snippets that previously worked may now be blocked until the provider updates them. This change affects all types of custom code, including dashboard custom code, embedded code, and Velo code." Nothing in that is aimed at us in particular. It applies to every third-party script anyone has ever pasted into a Wix site.

The developer page behind the notice lists what actually changed. fetch and XMLHttpRequest are replaced with secured versions that, in Wix's wording, "Can't be replaced or reassigned." Writes to Wix cookies through document.cookie fail silently. window.open on the same domain returns an empty object. Iframes created by frontend code on the same domain are automatically sandboxed, and the srcdoc attribute is blocked. URL, JSON, String, Object, addEventListener and removeEventListener, EventTarget and the Service Worker APIs are locked against modification. setTimeout and setInterval reject a string as the first argument.

Read that list next to the snippet above and you can see the shape it was written into. It creates a plain div, appends it, observes the document, and hands setTimeout a function rather than a string. It patches nothing global and builds no iframe of its own. The list is still worth keeping in view, because it is the first thing to check when a script that ran on a Wix site last year stops running on the same site this year, and because any widget, from anyone, that monkey-patches fetch or writes cookies by hand is on borrowed time here.

Picking a selector Wix will not rename

Wix generates class names and element ids dynamically, and its own docs warn that CSS or JavaScript aimed at those identifiers may break when the site is republished. #comp-abc123 is a selector with an expiry date. If you use one, copy it from dev tools on the live site and re-check it after any large editor change.

The durable alternative anchors on content you control instead of markup Wix controls. Type a marker string into a text element where the thread belongs, then find that text and replace it. The string is yours, so it survives republishing, and no visitor ever sees it.

Marker variant: swap the selector lookup for this
<script>
(function () {
  // Type this exact text into a Wix text element where the thread belongs.
  var MARKER = '[[comments]]';
  var timer;

  function slot() {
    var all = document.body.getElementsByTagName('*');
    for (var i = 0; i < all.length; i++) {
      var n = all[i];
      if (!n.children.length && n.textContent.trim() === MARKER) {
        return n.closest('[id^="comp-"]') || n.parentElement || n;
      }
    }
    return null;
  }

  function mount() {
    var host = slot();
    if (!host) return;
    host.textContent = '';
    var el = document.createElement('div');
    el.setAttribute('data-bootsignal', 'comments');
    el.setAttribute('data-thread-id', location.pathname);
    host.appendChild(el);
    if (window.BootSignal && window.BootSignal.activate) window.BootSignal.activate();
  }

  function schedule() { clearTimeout(timer); timer = setTimeout(mount, 150); }
  schedule();
  new MutationObserver(schedule).observe(document.body, { childList: true, subtree: true });
})();
</script>

Why the snippet watches instead of firing once

Wix documents one thing about its rendering that shapes every hand-built mount: the Wix rendering engine "may re-render elements in ways that conflict with direct DOM manipulation, especially during page transitions or viewport changes." That is the vendor saying the ground can move under a node you attached yourself, and naming page transitions as one of the moments it moves. What Wix does not spell out anywhere is what becomes of a snippet as a visitor goes from your blog index into a post. The loading choice in step 4 is offered the same way, as an option with no recommendation attached, so the honest position is that neither the timing nor the survival of your mount is promised to you.

So the snippet does not bet on a fresh page load, and does not bet on the div staying where it was put. A watcher instead of a one-shot: the observer notices new page content, the timeout collapses a burst of mutations into one attempt, and the mount function exits early when a thread is already in the target. The loader tags what it has mounted, so a rescan never draws a second copy. data-thread-id is read from location.pathname as the div is created, so every post gets its own thread with no template work, and a re-render that removes the div is itself a mutation the observer hears.

What it costs on top of Wix

Wix bills you per site plan. BootSignal bills per registered domain, which on a Wix site is the same unit of one: $20 per month or $200 per year per registered domain. That covers all 31 widgets in the catalog and the ones added after you subscribe, and nothing about the bill moves when traffic does. A second Wix site is a second domain in the dashboard rather than a bigger plan. Details on the pricing page.

One domain note specific to Wix, and it bites during testing rather than at install time. If you open the published site through its wixsite.com address to check your work, the hostname check will not recognize that address and the thread stays quiet. Nothing is broken there; that is the allowlist doing the job you registered a domain for. Check on the connected domain, which is the only address a visitor was ever going to be on.

You will not find competitor prices on this page, because a stale number in a comparison is worse than none. The alternatives section carries those, with sources and check dates.

Put a Comment Thread on a Published Wix Page

Register your connected domain, paste one Custom Code entry at Body - end, publish.

The same loader carries the rest

Every other widget reuses the loader you just pasted and the same mounting trick, so the second one costs you a copy of the mount function with a different data-bootsignal value. Feedback pairs well on Wix: the people who will not post in public will often tell you something in private.

Preview
Leave your feedback…
Send

The Feedback widget. Same install shape, different mount value. More on the Feedback page.

One widget deserves a specific note, since Wix sites often sell something. The Social Proof Toast only replays activity your site actually has: comments, reactions, ratings and votes already stored for your domain. It cannot invent a shopper in Ohio and will not try. With no activity yet it shows nothing, which is the intended behavior.

When the published page comes up empty

Work down this list in order. Wix is explicit that it will not work through it with you: "We cannot provide support for external codes that were not created or tested by Wix. If you are experiencing an issue with your code snippet, please contact the provider directly." Knowing which step failed is what turns that into a two-line message to us instead of a guessing match.

  1. Are you on the published site? Custom code never runs in the editor or in preview.
  2. Is bootsignal.js in the Network tab? If not, the Custom Code entry does not apply to this page.
  3. Does document.querySelector(TARGET) return an element in the live page console? null means the selector is wrong or Wix renamed it.
  4. Any console warning about a missing site id or thread id? The div mounted, an attribute did not.
  5. Does the domain in the address bar match the registered one, www and all? A near miss counts as a miss.
  6. Did this exact snippet work on this site before December 2025? Wix says its new frontend security measures can block code that previously worked until the provider updates it.
  7. Inspect the empty area: if your div sits inside an <iframe>, the snippet went into an Embed Code element and will never work there.

Questions people ask

Can I paste it into the Embed Code element instead?
No. Wix documents that element as a sandboxed iframe with no direct access to the rest of your page, served from a Wix origin rather than yours. The domain check fails and Google sign-in cannot complete. You get an empty box rather than an error, which is why it wastes so much time.
Will the comments show up in the editor or in preview?
No. Wix states that custom code does not take effect in the editor and only runs on the published site, and that snippets do not appear as elements in the editor. Publish, open the live URL, and check with browser dev tools. There is no in-editor preview for this.
My Google Analytics tag never fired from Custom Code either. Same cause?
No, that one is a documented carve-out rather than a sandbox or a security block. Wix states that tracking scripts for Google Analytics, Google Tag Manager, and Facebook and TikTok pixels do not work through custom code; those go through Wix's own marketing integrations instead. A comment widget is not a tracking script and runs normally from a Body - end entry, so a dead analytics tag is not evidence that the panel is broken.
How does each blog post get its own thread?
The snippet sets data-thread-id from location.pathname when it creates the div, so each post URL becomes its own thread automatically. Change a post URL later and its thread stays attached to the old path, so settle your URL structure before you collect many comments.
How much does this add to what a Wix page already loads?
The loader tag is deferred, so it does not block rendering, and it fetches the comments module only when it finds a mount element on the page. The mount script is a few dozen lines with a debounced observer. Nothing is free, but this is smaller than the images on a typical Wix page.
Is the site id a secret?
No, and it cannot be. Wix warns that injected code is visible to anyone viewing the page source, which is true of any front-end embed. What protects a site id is the domain allowlist: the widget only answers on domains registered to it, so a copied snippet does nothing elsewhere. Real API keys still do not belong in a Custom Code snippet.
Register Your Wix Domain and Get a Site ID

One hostname to register, one Custom Code entry to paste. The site id is what joins them.

Services in this guide

Read next

Where these numbers come from

Family Site