Webflow Comments for Client Sites: One Account, Many Sites

If you build Webflow sites for clients, sooner or later one of them asks for a comment section under their blog posts. Webflow does have a feature called Comments, and it is worth being clear about what it is: a collaboration tool that lets Workspace members, guests and reviewers pin feedback to elements on the canvas inside the Designer (Webflow University: Comments, read on 3 September 2026). It is for you and your client while the site is being built. It is not something a visitor to the published site can use.

Reader comments on a Webflow site come from a third-party widget placed in an Embed element. That is a solved problem for one site; the Webflow comments guide walks through it. This post is about the version of the problem an agency actually has: five client sites, each with its own domain, its own moderation needs and its own idea of how the widget should look, run from one login without mixing anything up.

The widget is EchoThread's, a single script under 60 KB gzipped that loads asynchronously and lets readers comment as guests or sign in with Google, GitHub, X or Facebook. Every comment is scored by a machine-learning spam filter before it appears. We build EchoThread, so treat our claims as claims and check the pricing page for the current numbers before you quote a client.

How the account maps to your clients

The unit in EchoThread is a site. A site has a registered domain, an API key, its own moderation queue, its own appearance settings and its own comment export. Your account holds as many sites as your plan allows.

So the mapping is one EchoThread site per client domain. client-one.com is a site, client-two.com is another, each with its own key. Comments posted through a key land in that site's queue, and reader sign-in inside the widget only completes on the domain registered for that site, so keep each client's key in that client's template and nowhere else.

That structure gives you three things an agency needs:

Separate moderation. Each client's queue is its own list. A spam wave on one site does not bury another client's real comments.
Separate appearance. Theme, accent colour and font are set per site or per Embed, so each widget matches the brand it sits inside.
Clean handover. If a client takes their site in-house, their comments are exportable as one file, and a site can be moved without touching the others.

Step 1: add each client as a site

In the dashboard, add a site for the first client with their production domain. Copy the API key. Repeat for each client. While you are still building on Webflow's webflow.io staging subdomain, the widget loads and shows comments there, but reader sign-in only completes on the site's registered domain. If you want to test sign-in before launch, register the staging subdomain as the site's domain for now and change it to the production domain when you connect it.

Step 2: the Embed element on the Collection page template

Webflow custom code goes into an Embed element, and the total across site settings, page settings, Embed elements and CMS rich text is capped at 50,000 characters (Webflow Updates: increased custom code character limit, read on 3 September 2026). The snippet below is well under 500, so the cap is not a concern.

Open the client's Blog Posts Collection page template, drop an Embed element below the post body, and paste:

<div id="echothread"
     data-api-key="CLIENT_ONE_API_KEY"
     data-identifier="[Slug]"
     data-page-title="[Name]"></div>
<script src="https://cdn.echothread.io/widget.js" async></script>

[Slug] and [Name] are not literal text. In the Embed editor, delete each placeholder, leave the cursor inside the quotes, and use + Add Field to insert the Collection's Slug and Name fields. Webflow shows each one as a field pill and substitutes the item's value when it publishes, which is how one Embed on the template produces a unique snippet for every post (Webflow Help: custom code in the CMS, read on 3 September 2026). Use the client's own API key in each site's template.

There is no data-page-url in the snippet on purpose. When the attribute is omitted, the widget reads the page URL from the browser at load time, which is always the real published address, whether the client is on staging or on their own domain.

Publish. Every post on that client's blog now has a comment section.

Why the identifier is the slug and not the URL

data-identifier is the key a discussion is stored under. If you leave it out, the widget uses the page URL, and the day the client moves their blog from /blog/ to /news/ every thread detaches. The Slug field survives that move. It does not survive an editor changing the slug itself, so if a client's team edits slugs often, add a hidden Plain Text field to the Collection holding a permanent ID and use that instead.

Step 3: give each client their own look

Per-site appearance is set in the dashboard, and per-Embed attributes override it. For a client with a dark site and a coral brand:

data-theme="#111111"
data-accent-color="#ff6b6b"
data-font-family="inherit"

data-theme accepts light, dark or a hex background, data-font-family="inherit" uses the site's font, and data-theme-source="--color-bg" reads the background from a CSS variable if the client's site has a theme toggle. The full attribute list is in the docs.

Step 4: moderation, and who does it

By default you, the account owner, see every site's queue. Two common arrangements:

You moderate. Reasonable while a site is new and comment volume is low. Each site's queue is separate, so you review one client at a time.
The client moderates. On the Pro plan and above, moderator roles let you invite a client's team member to their own site, so they see their queue and not your other clients'. That is the arrangement most agencies want once a blog has regular traffic.

Every comment can be held for approval before it appears, and the spam filter's score is shown against each one, so a moderator can clear a queue quickly.

The plan math

The free Hobby plan is for one site, with comments included, no ads and no reader tracking. It is fine for trying the widget on your own agency blog. It is not the plan for client work, because one site is one client, and Hobby shows a small "Powered by EchoThread" line under the widget, which a paying client may not want on their brand.

The self-serve ladder, as of 3 September 2026 (pricing):

Plan	Price	Sites	Page views a month per site*	What it adds
Hobby	Free	1	10,000	Comments included, no ads, no reader tracking
Starter	$9 a month, or $90 a year	3	100,000	Removes the "Powered by" line, adds webhooks and the API, and analytics
Pro	$19 a month, or $190 a year	10	1,000,000	Adds single sign-on and moderator roles
Business	$79 a month, or $790 a year	Unlimited	Unlimited	Adds audit log and retention controls

*Page views are metered only on sites created on or after 1 October 2026. A site created before that date keeps unmetered page views. Comments are unlimited on every plan.

Read that as an agency: Starter covers up to three client sites for $9 a month, with the "Powered by" line gone from all of them. Pro covers ten and lets each client moderate their own site. The per-client cost at Pro with ten sites is under $2 a month, which is a rounding error against a Webflow site plan, so most agencies fold it into the maintenance retainer rather than billing it separately.

Handing a site over

If a client leaves or brings the work in-house, export their site's comments from the dashboard as a JSON or CSV file. The file is theirs to keep, to load into an EchoThread account of their own, or to take to another system. Because the threads are keyed to the post slug rather than to your account, a re-import against the same slugs puts each discussion back under its post.

Troubleshooting

Readers cannot sign in on staging. Sign-in completes only on the site's registered domain. Register the webflow.io subdomain for now, or test sign-in after the production domain is connected.
Comments from one client appear on another. Two templates share an API key. Each Collection page template needs its own client's key.
[Slug] shows literally on the published page. The placeholder was left as text instead of being replaced with Add Field, or the Embed is on a static page rather than a Collection page template. Dynamic fields only resolve inside Collection templates.
Threads detached after a slug edit. The identifier was the slug. Add a permanent ID field to the Collection and use it for data-identifier.

Comment section for Webflow client sites: one account, many sites