Adding an assistant to a Webflow site

Webflow gives you two places to put third party code, and choosing the wrong one causes the two most common problems people hit.

Where the code goes

For a site wide widget, use Project Settings, Custom Code, Footer Code. This injects before the closing body tag on every published page. Putting a widget script in the head is possible but usually unnecessary and more likely to affect render timing.

For a single page, use Page Settings, Custom Code instead. Page level code is the right choice if you only want the assistant on documentation or pricing.

Constraint one: custom code requires a paid plan

Custom code in Project Settings is not available on the free Webflow plan and requires a site plan. This catches people out mid setup. Check before you promise a client a same day install.

Constraint two: code only runs on published sites

Custom code does not execute in the Designer preview. You have to publish, including to the staging webflow.io subdomain, to see the widget at all. Testing in the Designer and concluding the embed failed is a common false alarm.

Training sources on a Webflow site

Webflow sites usually have a clean sitemap at /sitemap.xml, which makes source selection straightforward. Two things to exclude:

• CMS collection item pages that are near duplicates, such as a large tag or category archive.
• Any staging webflow.io URLs, so the assistant does not index and quote a staging copy of your site.

That second one matters more than it sounds. If both the custom domain and the webflow.io subdomain are crawlable, you can end up with two copies of every page in the index and inconsistent answers depending on which chunk retrieval picks.

Interaction conflicts

Webflow Interactions are a common source of z-index and scroll conflicts with a fixed position widget. If your site has a sticky nav, a full screen menu overlay or a scroll driven animation, check the widget launcher at mobile widths with the menu open. The usual fix is a z-index adjustment on your own overlay rather than on the widget.

A note on performance

Webflow sites often already carry jQuery plus the Interactions runtime. Adding a widget script is additive, so check your measured page performance before and after rather than assuming the impact is negligible. If the site was already close to a threshold, a third party script can push it over.

Where the embed goes in Webflow

Project settings, custom code, before body tag. That places it on every published page, which is the fast path and the one that needs a second thought.

Page level custom code is the alternative when you want the assistant on some templates and not others. It is more work to maintain, because a new template will not inherit it and nobody will notice for weeks.

The pragmatic arrangement is site wide placement plus exclusion rules in the assistant's own configuration. One place to change, and a new template is covered by default rather than forgotten.

What Webflow does to your content before a crawler sees it

Most Webflow output is server rendered, so a crawler reads it without difficulty. The exceptions are the ones worth knowing.

Content inside interactions that start hidden is usually present in the markup and therefore indexable, which surprises people who assume hidden means absent. That includes accordion panels and tab contents, so an FAQ built as tabs is generally readable.

Content loaded from an external embed or a third party widget is not readable, because it arrives after the page does. Anything in an iframe is effectively invisible.

CMS collection pages index cleanly and are often the best source on a Webflow site, since they are structured and consistently formatted in a way hand built pages are not.

The Webflow specific failure to plan for

Publishing is the moment your site and your index diverge. Webflow publishes instantly and there is no build step to hook, so a scheduled reindex is the default and the gap between publishing a price change and the assistant knowing about it is however long that schedule is.

For most content that is acceptable. For pricing, policy and opening hours it is not, because those are exactly the pages where a confidently outdated answer creates a dispute.

The workable practice is a manual reindex as the last step of any publish that touches those pages. It is a habit rather than a feature, and habits need to be written into whoever owns the site's checklist rather than assumed.

Testing before you publish

Webflow's preview does not run site wide custom code, so the assistant will not appear there and its absence tells you nothing. The first place you see it working is the staging domain.

Publish to the webflow.io subdomain first and test there. It runs the same custom code as production, so the widget loads and the embed can be verified before anything reaches the live domain.

Check three things on staging. That the launcher appears on the templates you expect and not the ones you excluded. That it does not overlap a sticky element at 390 and 320, which is where it usually collides. And that the crawler reached your CMS collection pages, which is easy to assume and easy to get wrong when a collection is set to draft.

Only then publish to the custom domain. The reindex should run against the live domain rather than the staging one, or the citations will point at URLs your visitors cannot open.

If the site uses Webflow localisation

Localised pages are separate URLs with separate content, so a crawler will index each locale as its own source unless told otherwise.

That is usually correct, and it means a visitor asking in one language can be answered from that locale's pages. It also means the source count multiplies by the number of locales, which matters against a plan limit.

Where locales are partially translated, the risk is an answer assembled from two languages. Scoping each agent to one locale avoids it and is worth the extra setup.

Working with a Webflow CMS as the primary source

On most Webflow builds the CMS collections are the best content available and the least considered as a source.

They are consistently structured, which is the property that matters most for chunking. Every item has the same fields in the same order, so passages come out uniform and predictable in a way hand built pages never are.

They are also the content most likely to be current, because a CMS item is edited by whoever owns that thing rather than by whoever last opened the designer.

The caveat is that collection pages often carry a lot of template chrome around a small amount of unique content. If the extraction picks up the surrounding layout, every item produces a passage that is mostly identical to every other item, and retrieval degrades sharply.

Check one indexed collection item before indexing the whole collection. If the extracted text is mostly the unique fields, index it all. If it is mostly template, the template needs attention before the collection is worth using.

Terms in this articleRetrieval Augmented GenerationChunkingIndex