Collect feedback on Webflow projects: paste the snippet into Custom Code, publish, share the link. Notes on the element instead of Designer comments.
In short
In Webflow you paste the nootiz snippet into Project Settings → Custom Code (head) and publish the project. Clients then comment on the published page – no Webflow seat, no Designer licence, and no translating comments back into the Designer.
Create a project in nootiz and copy the snippet.
In Webflow, paste it into Project Settings → Custom Code → Head Code (not Footer Code, so the button loads as early as possible) and save.
For a single page instead of the whole site, use that page's own Page Settings → Custom Code section, e.g. when only one landing page needs feedback.
Publish the project – custom code only runs on published pages, never inside the Designer.
If needed, publish to the free webflow.io subdomain first, test there, and share that link with clients before pushing to the live domain.
For the whole site, add it under Project Settings → Custom Code → Head Code. To enable nootiz on just one page, such as a single campaign landing page, add it in that page's own Page Settings instead – useful when not the whole project needs to collect feedback.
Webflow only injects custom code into published pages, never into the Designer preview or the in-editor "Preview" mode. This is the most common reason the nootiz button appears "missing" – publishing usually fixes it instantly.
Site-wide custom code in the head/footer requires a paid site plan (Basic or above); on a plain starter project without a site plan you cannot permanently add the snippet until you upgrade. Page-specific custom code via Page Settings is sometimes available on lighter plans too, so check your specific plan's allowance.
CMS template pages (blog posts or product pages generated from a collection) automatically inherit the site's head code once published. Each collection page still gets its own URL, and notes stay bound to that specific URL – ideal when clients want to comment on one blog post rather than the template.
Webflow interactions (scroll triggers, hover states) only change appearance, not the underlying DOM structure nootiz attaches to. Notes can be placed on animated states too, and each note also records the screen size and browser the client used.
Webflow's native comments live in the Designer and require a paid workspace seat per commenter. nootiz notes live on the publicly published page, are reachable by anyone with the link, and require no Webflow access or role at all.
Changes made in the Designer but not yet published are invisible to the client – nootiz always reflects the last published version. Notes also stay tied to DOM structure and URL: removing an element entirely or renaming a page can make an old note lose its anchor.
No. Clients open the published page through your link and leave notes without an account.
Webflow comments live in the Designer and require a seat. nootiz notes live on the published page and are open to clients without Webflow access.
Yes, custom code is served there as well.
Yes. Every published CMS page is a normal URL – notes attach per element and stay bound to that URL.
Notes stay. As long as structure and URL remain the same, nootiz finds the element again.
Notes can be pushed to Trello, Asana, Jira or GitHub as tasks, including page URL and element.
For site-wide head code, yes, starting at the Basic plan. If you only need one page, check whether page-level custom code is already included in your current plan.
That's expected: Webflow only runs custom code on published pages, never in the Designer preview. Once you publish, the button shows up reliably.
Deeper pages on platforms, comparisons and hands-on workflows.
In Framer you add the nootiz snippet under Site Settings → General → Custom Code (head) and publish. Clients then give feedback on the published site instead of commenting on the Framer canvas they cannot access without a seat.
→PlatformIn Wix you add the nootiz snippet under Settings → Custom Code in the head section and publish the site.
→GuideWebsite markup means feedback gets placed directly on the element on the live page. Here is how that works, technically and in practice.
→Use caseFor project managers who want to know a site's approval status without calling a status meeting.
→Use caseFor password-protected staging and preview environments that need outside feedback.
→GuideBusiness teams, executives and clients without a technical background give feedback differently. Here's how to still make it usable.
→Add the snippet, share the link, collect feedback right on the page – live in under 5 minutes.
