Short answer: Ghost has a code injection panel in its settings with a site header and a site footer field. Paste the chat widget script into the site footer, save, and it appears on every page of your Ghost site. There is also a per-post code injection panel if you only want it on one page.
Ghost makes this genuinely easy
Of all the platforms in this series, Ghost has the cleanest story. Code injection is a first-class feature rather than an afterthought bolted onto a page builder, and it lives in settings where you would expect it.
Open your Ghost admin, go to settings, and find the code injection area. You get two fields: one whose contents go into the site header, and one whose contents go before the closing body tag on every page.
Paste your script tag into the footer field. Save. That is the install.
Footer over header, for the usual reason: a chat widget is not part of your content and should never be in the critical path for rendering your article. Ghost sites are typically fast and readable, and the widget should not be the thing that changes that.
The install, step by step
If you want it as a sequence rather than a paragraph:
- Get your script tag. In Clerkzo, create your agent, give it your website URL so it can crawl your published pages, and copy the one-line embed snippet. Done-for-you setup is available if you would rather not.
- Test it before it goes near your site. The playground behaves exactly like the live widget. Ask five questions your readers actually ask, and fix anything embarrassing in private.
- Open Ghost admin and go to settings. Find the code injection area. Ghost has moved this between versions, so search the settings screen for "code" if it is not where you expect.
- Paste into the site footer field. Not the header field.
- Save, and give any CDN a moment to catch up.
- Open your live site in a private window and check the widget appears.
- Check a post, the homepage and a static page, because Ghost renders them through different templates.
That is about five minutes of work. The step that takes thought is the second one. There is a broader walkthrough on how it works if you want to see where crawling, files and corrections sit.
Per-post injection, and when to use it
Every individual post and page in Ghost also has its own code injection panel, tucked into the post settings. Code there applies to that post only, and stacks on top of whatever is in the site-wide fields.
This is useful in two situations. One is testing: put the widget on a single high-traffic post, see what people ask, then decide whether to roll it out. The other is a dedicated landing page where you want chat but do not want it across your whole publication.
If you use per-post injection while site-wide injection is also active, you will load the widget twice. Pick one.
The single-post test is worth doing if you are unsure. Run it on your best-performing post for a fortnight and read the transcripts. You learn whether your readers want to ask anything, and what.
The publication question
Ghost is used for two fairly different things, and which one you are doing changes whether a chat widget makes sense.
If Ghost is your business website, with services pages and a contact page, a chat widget is straightforwardly useful. Visitors ask about what you do and you capture the ones worth following up.
If Ghost is a newsletter or publication, think about intent. Your readers are not enquiring, they are reading. A widget can still earn its keep by answering questions about your archive, your membership tiers and your billing, which otherwise land in your inbox one at a time. But do not expect it to behave like a sales tool on a site where nobody is buying a service.
Either way, feed it your site by crawling it, so it can answer from your actual published content rather than guessing.
For a publication, the wins are narrow but real. "Do you have anything about X?" answered from your archive saves a reader trawling your tag pages. "What do I get on the paid tier?" saves you an email. "How do I update my card?" routed to a human saves you a churned subscriber.
What to feed it on a Ghost site
Crawling gets you the published archive, which is most of it. Two additions usually make the difference.
First, make sure the practical pages exist and are public: what the publication covers, what the membership tiers include, how billing works, and how to contact a human. Publications often have all of that scattered across old announcement posts, which retrieve badly. One clear page beats five posts mentioning it in passing.
Second, upload what is not published and should not be: your internal FAQ, your sponsorship rate card, your editorial guidelines. That material sits in the knowledge base without going on the site.
One honest limit worth planning around: the widget answers from your content, so it inherits your archive's gaps. If nowhere on your site explains your refund policy, the widget cannot either. It should decline and offer a person rather than invent one, but the real fix is to write the page.
Members, paid content and the widget
Ghost's membership features mean parts of your site may be gated. A chat widget trained by crawling your public pages will only know your public content, which is correct behaviour. You do not want a widget cheerfully summarising paywalled posts to logged-out visitors.
If you want it to answer questions about member benefits, pricing tiers or how to update a card, put that information on a public page or into an uploaded knowledge file, and set the guardrails so anything account-specific hands off to a human rather than being invented. Account questions are exactly the category where a confident wrong answer costs you a subscriber.
Draw the line clearly: general questions about how membership works are content questions, and the widget should answer them. Questions about a particular member's account, payment or access are not, and the right outcome is a human handoff with their details captured.
Verifying the install
Open your live site in a private browser window. Check a post, the homepage and a static page, because Ghost renders these through different templates and it is worth confirming all three.
View the page source and search for the script tag. Ghost injects code injection content reliably, so if the tag is missing, you most likely saved it in a per-post panel rather than the site-wide settings, or you are looking at a different site than the one you edited. If the tag is present but nothing renders, open the browser console.
Then check it on a phone, properly, not by resizing your browser. A widget that sits neatly in the corner on a laptop can cover a subscribe button on a small screen.
Finally, have a real conversation with it as a reader would. Ask something your archive covers well, something it covers badly, and something it should refuse. You are checking three behaviours: it answers, it declines honestly, and it offers a person when it should.
Common gotchas
AMP. Ghost has historically offered AMP versions of posts. AMP does not permit arbitrary JavaScript, so your widget will not appear on AMP pages, and no configuration fixes that. If AMP matters to you, accept the gap. If it does not, consider whether you still need AMP at all, since its original advantages have largely evaporated.
Caching and CDN. Ghost sites are commonly served through a CDN. Purge or wait, and always test in a private window.
Theme preview versus live. If you are previewing an unpublished theme, code injection may behave differently. Test the live site.
Custom themes that omit the footer helper. Ghost's code injection relies on the theme calling the standard footer helper. A well-built theme does. A hand-rolled theme missing it will silently drop your injected code. If the tag never appears in the source on any page, this is the likely cause.
Double loading. Site-wide plus per-post injection means two widgets. Remove one.
Content API and headless setups. If your Ghost install is headless, with a separate front end pulling posts through the Content API, Ghost's code injection fields have nothing to inject into. Add the script to your front-end application instead. The same one-line tag works; it just goes in your own template.
Switching themes. Code injection settings survive a theme change, but a new theme missing the foot helper drops them silently. Re-check the live site after any swap.
Making it feel like part of the publication
Ghost sites tend to be quiet, typographic and deliberate. A loud chat bubble undoes that in one move, so spend five minutes on the styling.
Widget Studio gives you theme, light or dark, launcher shape and size, position, offsets, and your own brand colour. Match your accent, keep the launcher small, and pick the corner that does not collide with your subscribe prompt.
Then write the greeting properly, because it does more work than any visual setting. "Ask me about anything in the archive" sets a far more useful expectation than "How can I help you today?", which invites the wrong questions. More on that in what your chat greeting should say.
If you run a reading-first site, consider turning off auto-open. Interrupting somebody four paragraphs into an article is a good way to have your widget dismissed and never reopened.
Frequently asked questions
Does this work on Ghost Pro and self-hosted Ghost?
Yes. Code injection is a core Ghost feature, not a hosting add-on.
Will it appear on every post automatically, including future ones?
With site-wide footer injection, yes, including posts you have not written yet.
Can I style it to match my publication?
Yes. Widget Studio gives you eight themes, light and dark, three shapes and a brand colour, so it can match a minimal publication rather than shouting over it.
Will it interfere with Ghost's Portal or subscribe popups?
The widget renders in its own isolated Shadow DOM. If both sit in the same corner you may want to reposition one for visual reasons, but they do not technically conflict.
Will it slow down my site?
The script loads asynchronously and is not in the rendering path for your article, which is why it goes in the footer field. Measure your own pages before and after if speed matters to you.
Can it read my paid posts?
Not unless you make that content available to it. A crawl of your public site sees your public site. That is the safe default, and you should leave it that way.
Is a chat widget better than my contact form?
Usually, because it answers rather than only collecting. The full argument is in chatbot vs contact form, and if you are still weighing it up, do I need a chatbot for my business is the honest take. For a publication whose enquiries are really reader or sponsor leads, the lead capture chatbot page shows that side, and plans are flat from $19 on the pricing page.