Install PodSaid on WordPress

WordPress powers roughly a third of the web, so this is the most common place PodSaid gets installed. The widget is a single copy-paste — no plugin, no build step, no extra JavaScript to write. The tricky part isn’t pasting it, it’s making sure your WordPress setup doesn’t eat the paste before it renders. This page covers both.

Time: about 5 minutes if your theme is straightforward, 10 minutes if you use a page builder or caching plugin.

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 — you don’t edit anything.
• Admin access to the WordPress site.
• The domain you want to embed on already added to your Allowed Origins. If you skipped the domain field at signup, do that first under Console → Settings → Allowed Origins. Adding it later is fine; the widget won’t work on that page until you do.

The 60-second version

Copy the snippet from your PodSaid console. It looks like this (yours will have your real values already filled in):

<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>

Paste it into a Custom HTML block on any page or post where you want the widget to appear. Publish. Reload the page. Done.

If that just worked for you, skip to Verifying it works. If it didn’t render, or you’re using a page builder, keep reading.

Where to paste the snippet

Pick the option that matches how you build pages on your site.

Option A — Gutenberg block editor (WordPress 5.0+, the default)

This is the recommended path for a single page or post.

1. Edit the page where you want the widget.
2. Click the + button to add a new block.
3. Search for Custom HTML and add it.
4. Paste the snippet.
5. Click Preview to check it renders. If Preview shows a broken render but the live page works, that’s normal — Gutenberg’s preview iframe sometimes blocks third-party scripts.
6. Update / Publish.

Custom HTML blocks are safe by default — WordPress will not strip <script> or <ask-pod-widget> from them for admins. This is why we recommend this path.

Option B — Theme footer (site-wide, appears everywhere)

Use this if you want the widget visible on every page — for example, a persistent chat launcher.

Most modern themes have a Customize → Additional Code or Customize → Footer Code field. If yours doesn’t, install the plugin Insert Headers and Footers by WPCode (free, well-maintained, 2M+ active installs) and paste the snippet in its Footer slot.

The widget’s <ask-pod-widget> tag doesn’t render anything visible by itself when placed in the footer without additional layout — it hooks up its own launcher. That’s fine; that’s what you want for a site-wide floating button.

Option C — Page builder (Elementor, Divi, Beaver Builder, WPBakery)

Every major page builder has a Custom HTML widget. Use it. Do not paste into a “Text” or “Rich Text” widget — those run the input through TinyMCE, which strips <script> tags without telling you.

Option D — Sidebar widget area

You can drop a Custom HTML widget into any sidebar or widget area (Appearance → Widgets). The widget will render inside that sidebar’s container. Fine for a footer sidebar; less good for a narrow right-hand sidebar, where the chat pane may feel cramped.

Common WordPress gotchas

The paste itself almost always works. What breaks it is something between you and the browser rewriting the HTML in transit. Here are the four we see most often, in order of frequency.

1. Cloudflare Rocket Loader

Symptom: Widget doesn’t appear. Browser console shows the widgets.iife.js script never executed.

Cause: Rocket Loader is a Cloudflare optimization that rewrites <script> tags and defers them in a way that breaks Web Components.

Fix: In your Cloudflare dashboard → Speed → Optimization → Content Optimization, turn Rocket Loader off for the pages that host the widget. Or add this attribute to the script tag:

<script src="https://widget.podsaid.com/v1/widgets.iife.js"
        data-cfasync="false" defer></script>

data-cfasync="false" tells Rocket Loader to skip this script.

2. Caching plugins minifying / combining JS

Symptom: Widget worked once, then broke after you enabled a caching plugin. Or the console shows the script loaded but no custom element registered.

Cause: WP Rocket, W3 Total Cache, LiteSpeed Cache, and Autoptimize sometimes combine and minify third-party scripts. When they do that to widgets.iife.js, they can break its runtime.

Fix: In the plugin’s settings, find the JS optimization section and exclude the widget URL from combine / minify / defer. In WP Rocket the field is File Optimization → JavaScript → Excluded JavaScript Files. Paste:

widget.podsaid.com/v1/widgets.iife.js

Then purge the cache.

3. Security plugin stripping the api-key attribute

Symptom: Widget renders as an empty box. Browser console shows [podsaid-widget] Auth failed: key_missing.

Cause: Wordfence, iThemes Security, and a few others have “strip unusual attributes” filters that mistake api-key for a suspicious attribute. They quietly rewrite your HTML on save or on render.

Fix: Add an exception for the domain hosting the widget or disable the “strip attributes” rule for admin-pasted HTML. In Wordfence: Firewall → All Firewall Options → Advanced → Whitelist patterns.

If the plugin lets you see the rendered HTML on the live page and the api-key attribute is missing, you’ve found the culprit.

4. Mixed content on an http:// page

Symptom: Nothing renders. Browser console shows a mixed-content warning about widgets.iife.js.

Cause: Your WordPress page is served over http:// but the widget is loaded from https://widget.podsaid.com/. Modern browsers block that combination.

Fix: Turn on HTTPS for your site. In 2026, running WordPress over HTTP is a bigger problem than PodSaid not loading. Every major host (SiteGround, WP Engine, Kinsta, Bluehost) offers free Let’s Encrypt in one click. The plugin Really Simple SSL handles the redirects for you.

Verifying it works

1. Open the published page in a normal browser window (not the admin preview — see Option A above).

2. Look for the widget in the location you placed it. In a footer placement it appears as a launcher button (default: bottom-right).

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

4. Open your browser’s DevTools console (⌥⌘I on Mac, F12 on Windows). You should see one line:

   [podsaid-widget] v1.8.2 mounted (feed=yourfeedslug, api=https://api.podsaid.com)

If the widget appears but questions fail, jump straight to Widget errors — what each one means.

Adding staging or preview URLs

Your allowlist must contain the exact origin you’re loading the widget from. Common WordPress deploy setups need multiple entries:

www and no-www count as different origins. If your site serves both, add both. The full rules are on Allowed origins — the security allowlist.

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) for what to expect.

Still stuck?

• Errors index: Widget errors — what each one means
• Book a 15-minute call with Mark: /docs/support
• Email: support@podsaid.com — include the URL of the page you’re embedding on and a screenshot of the browser console