Skip to main content
Skip to main content

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-id and pk_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.io staging 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

Use this for a persistent chat launcher on every page.

  1. In the Webflow Designer, click your site’s Project Settings (top-left, gear icon).
  2. Go to the Custom Code tab.
  3. Paste the snippet into the Footer Code field (labelled Before </body> tag).
  4. Click Save Changes.
  5. 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).

  1. In the Designer’s Pages panel, hover the target page and click the gear icon to open its settings.
  2. Scroll to Custom Code.
  3. Paste the snippet into the Before </body> tag field.
  4. 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.

  1. In the Designer, drag an Embed element from the Add panel onto the page at the position you want.
  2. In the code editor dialog, paste the snippet. Click Save & Close.
  3. 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.io
  • https://yoursite.com (and https://www.yoursite.com if you serve both)

You can leave the staging domain in the allowlist indefinitely — useful for testing changes.


Verifying it works

  1. Open your published URL in a normal browser window — not the Designer.

  2. Look for the floating launcher (default: bottom-right), or for the widget inline where you placed the Embed element.

  3. Click it. If a chat box slides in, you’re done.

  4. 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?