Short answer: the no-code route is the design configuration in the Magento admin, where each store view has fields for scripts in the HTML head and miscellaneous HTML before the closing body tag. Paste the widget script into the footer-side field, save, then flush the cache. Magento caches aggressively, so if you skip the flush you will think the install failed.
Magento is not a website builder, so expect more moving parts
Magento gives you real power and charges for it in complexity. There are multiple valid places to inject a script, several layers of cache between your change and a visitor's browser, and the concept of store views meaning a setting can apply to one storefront and not another.
None of this is hard. It just punishes people who assume it works like Wix.
Route one: design configuration in the admin
This is the route to use unless you have a specific reason not to.
In the Magento admin, go to the content area and open the design configuration. You will see a grid with rows for the global default, each website, and each store view. Edit the row at the level you want the change to apply to. Editing the default applies it everywhere, which is usually what you want.
Inside that screen, expand the HTML head section and the footer section. The head section has a field for scripts and stylesheets. The footer section has a miscellaneous HTML field that outputs before the closing body tag.
Put the chat widget script in the footer miscellaneous HTML field. Save the configuration.
Why the footer rather than the head: everything in the head is parsed before your storefront renders. A chat widget has no reason to be there, and Magento storefronts are heavy enough already.
Route two: a layout XML update in a custom theme
If you maintain a custom theme through a proper deployment pipeline, you can add the script via a layout update or a template block instead. It is version-controlled, reviewable and repeatable across environments, which is genuinely better practice for a team.
It is also completely unnecessary for a single script tag on a single-store shop, and it means every change needs a deploy. Choose based on whether you have a development process or a person with an admin login.
Route three: an extension
There are extensions whose whole job is injecting custom code. They add an admin UI, per-page rules and sometimes scheduling.
For one script tag, an extension is overhead: another dependency to keep compatible across Magento upgrades, for something the core admin already does. Skip it unless you are managing many scripts with complex rules.
Flush the caches, properly
This is where most Magento installs appear to fail.
After saving, go to the cache management screen and flush the invalidated caches. Magento usually flags the relevant cache types as invalidated after a design configuration change, and they will be sitting there highlighted.
If your store sits behind full page caching or Varnish, that layer needs clearing too. And if you are in production mode with a CDN in front, allow time for propagation or purge it explicitly.
In production mode, changes made through the admin configuration do not require a static content deploy, because you are storing configuration values rather than editing files. If you took the theme route instead, you do need to deploy static content and clear generated files.
How to verify
Open the storefront on the live domain in a private browser window. Not the admin preview, not a stale tab.
Check the homepage, a category page and a product page. If you edited a specific store view rather than the default, check that you are actually looking at that store view, because multi-store Magento setups make it easy to test the wrong storefront.
View the page source and search for the script tag. If it is missing, either the cache has not cleared or you saved it at a scope that does not apply to the storefront you are viewing. If it is present but no bubble appears, open the browser console and read the error.
Common gotchas
Scope confusion. Saving at the store view level applies to that view only. In a multi-store or multi-language setup you may need it at the default scope, or repeated per view.
Cache, again. If you changed something and nothing happened, the answer is cache roughly eight times out of ten.
Content security policy. Magento ships with a CSP framework and merchants often tighten it. If the widget domain is not allowed, the browser blocks the script and reports it in the console. Add the domain to the allowed sources.
Checkout pages. Consider excluding checkout. A floating bubble over a payment form is a distraction at the exact moment you want the visitor focused.
Theme upgrades. If you took the theme route, an upgrade can overwrite your change. The admin route does not have this problem.
Escaped output. Some fields sanitise input. If your script appears on the page as visible text rather than executing, you used a field meant for text, not HTML.
What to actually do with it
Magento stores tend to have deep catalogues and long policy pages that nobody reads. That is the ideal condition for a chat widget: the answer exists on your site, but the customer will not find it, so they email you instead or leave.
Point it at your store to crawl the published pages, upload the internal documents that never made it to the site, and set the guardrails so it hands off rather than guessing on anything involving money. For pre-sales questions that turn into real enquiries, capture the contact details and route them to your inbox and to whichever notification channel your team actually watches, which is what lead capture is for; the lead capture chatbot page shows that flow end to end. Pricing is flat, from $19 a month on the pricing page, so a busy sale period does not change the bill.
If you are weighing this against just doing nothing, do I need a chatbot for my business is the honest version of that argument.
Frequently asked questions
Does this work on Magento Open Source and Adobe Commerce?
The design configuration approach exists in both, since they share the same core admin. Exact menu wording can differ by version, so if the labels do not match, look for the design configuration under the content area.
Do I need developer access?
Not for the admin route. You need an admin account with permission to edit design configuration and flush cache. The theme and extension routes need developer access.
Will it hurt my page speed scores?
Loaded in the footer and asynchronously, it does not block rendering. Magento's own bundle size is a far larger factor in your scores than a chat widget.
Can I put it on some store views only?
Yes, that is exactly what the scope selector is for.
Is it safe for a store handling customer data?
Clerkzo is SOC 2 Type II examined, GDPR compliant and HIPAA assessed. Keep it off checkout regardless, as a matter of principle.