Install PodSaid on Webflow
Webflow’s custom-code support is the cleanest of the hosted site builders — no plugins, no premium-plan-with-connected-domain trap like Wix. There are two clean install paths and a third for finer-grained per-page control. Time: about 3 minutes.
What you need before you start:
- A PodSaid account with a feed set up (see Quickstart).
- The embed snippet from Console → Settings → Embed Code. Your
feed-idandpk_live_key are already substituted. - A paid Webflow plan (Basic or above). Custom code is disabled on the free Starter plan — a Webflow restriction, not ours.
- The domain(s) your site is served from added to your Allowed
Origins. If you’re on the default
*.webflow.iostaging domain before switching to a custom domain, add both — they’re different origins. See Allowed origins.
The 60-second version
Copy the snippet from your PodSaid console:
<script src="https://widget.podsaid.com/v1/widgets.iife.js" defer></script>
<ask-pod-widget
feed-id="yourfeedslug"
api-key="pk_live_xxxxxxxxxxxxxxxx">
</ask-pod-widget> In the Designer, open Project Settings → Custom Code → Footer Code, paste, save, and Publish. View the live URL to verify.
If that just worked, skip to Verifying it works.
Where to paste the snippet
Option A — Project Settings → Footer Code (recommended)
Use this for a persistent chat launcher on every page.
- In the Webflow Designer, click your site’s Project Settings (top-left, gear icon).
- Go to the Custom Code tab.
- Paste the snippet into the Footer Code field (labelled Before
</body>tag). - Click Save Changes.
- Click Publish (top-right) → choose staging (
*.webflow.io) and/or your production domain → Publish to Selected Domains.
The Footer Code field allows up to 50,000 characters — well
above the snippet’s size. Head Code also works but Footer matches
our defer semantic and is very slightly faster to render.
Option B — Page Settings → Custom Code
Use this to embed the widget only on specific pages (e.g. a Sermons or Episodes page).
- In the Designer’s Pages panel, hover the target page and click the gear icon to open its settings.
- Scroll to Custom Code.
- Paste the snippet into the Before
</body>tag field. - Save, then Publish.
Page-level custom code stacks on top of Project-level — if you set both, both fire. Don’t put the same snippet in both, or you’ll get two launchers.
Option C — HTML Embed element (inline)
Use this only if you want the widget rendered inline in a specific place in the page layout — e.g., a bounded “Ask a question” box on one section. For a floating launcher, prefer Option A.
- In the Designer, drag an Embed element from the Add panel onto the page at the position you want.
- In the code editor dialog, paste the snippet. Click Save & Close.
- Publish the site.
The Embed element has a 10,000-character limit — comfortably above the snippet size. It renders inline in the page’s normal document flow (no iframe sandbox, unlike Wix’s per-page element).
Common Webflow gotchas
1. Designer preview vs. published site
Symptom: You added the snippet to Project Settings, saved, and tested in the Designer’s Preview mode. Widget doesn’t appear.
Cause: Webflow does not execute custom code in Designer
Preview. Custom code only runs on published sites — both the *.webflow.io staging URL and your custom domain, once you’ve
clicked Publish.
Fix: Publish the site (Publish button → select domain(s) → Publish to Selected Domains). View the widget on the published URL, not in the Designer preview.
2. Free plan / no paid tier
Symptom: You open Project Settings → Custom Code and the tab is missing, greyed out, or shows an upgrade prompt.
Cause: Custom code is gated on the Basic plan or above. The free Starter plan doesn’t include it.
Fix: Upgrade to Basic (or higher). There is no workaround on the free plan — Webflow enforces this at the account level.
3. Widget appears twice
Symptom: Two launcher buttons show up on the same page.
Cause: You pasted the snippet in both Project Settings → Footer Code and Page Settings → Custom Code and/or an HTML Embed element. Each place is additive.
Fix: Pick one. For a floating launcher, keep Project Settings Footer Code. For an inline embed on one page, keep the HTML Embed element and remove the Project-level entry. Publish again.
4. Publishing to only one domain
Symptom: Widget works on yoursite.webflow.io but not on your
custom domain — or vice versa.
Cause: Webflow lets you publish to selected domains. If you only ticked one, only that one has the new code.
Fix: In the Publish dialog, tick every domain and click Publish to Selected Domains again.
5. The staging URL doesn’t match your allowlist
Symptom: Widget renders on the staging or custom-domain URL but
the API rejects requests. Console shows [podsaid-widget] Auth failed (403): origin_denied.
Cause: Webflow’s staging (*.webflow.io) and your custom
domain are two different origins. Both need to be in Allowed
Origins.
Fix: In Console → Settings → Allowed Origins, add both:
https://yoursite.webflow.iohttps://yoursite.com(andhttps://www.yoursite.comif you serve both)
You can leave the staging domain in the allowlist indefinitely — useful for testing changes.
Verifying it works
Open your published URL in a normal browser window — not the Designer.
Look for the floating launcher (default: bottom-right), or for the widget inline where you placed the Embed element.
Click it. If a chat box slides in, you’re done.
Open DevTools console (⌥⌘I on Mac, F12 on Windows). Look for:
[podsaid-widget] v1.8.2 mounted (feed=yourfeedslug, api=https://api.podsaid.com)
If the widget appears but questions fail, jump to Widget errors — what each one means.
When the widget shows “still preparing your content”
If ingest hasn’t finished for your feed yet, the widget renders a friendly placeholder instead of an error. Your paste is correct — you just don’t have content to answer questions against yet. Watch progress under Console → Feed → Ingest status, or wait for the “your widget is live” email.
See How ingest works (and why it takes hours).
Match your brand
The widget renders inside a Shadow DOM, so your site’s CSS can’t reach the widget and the widget’s CSS can’t leak into your site — nothing in your theme will accidentally break the widget’s look. To make it match your church or podcast brand, the widget exposes a set of CSS custom properties and Shadow Parts you can target from your own stylesheet.
See Customization (CSS) for the full list, with copy-paste examples.
Still stuck?
- Errors index: Widget errors — what each one means
- Book a 15-minute call with Mark: /docs/support
- Email:
[email protected]— include the live URL and a screenshot of the browser console