Testimonials on WordPress, in one script tag

In the block editor, the tag goes in a Custom HTML block placed wherever the testimonial section belongs.

1. Open the page or post you want the testimonials on.
2. Click the + Block Inserter and search for HTML, then click Custom HTML. Faster: type /html in an empty paragraph and press Enter.
3. Click Edit HTML to open the block’s editing modal — on WordPress 7.0 and later, the tag goes in its HTML panel.
4. Paste the script tag into the code pane. The pane on the right previews the output; a script tag has nothing to draw there, so an empty preview at this point is normal.
5. Press Update, then publish or update the page.

Drag the block by its six-dot handle to move the section up or down. The Custom HTML block has no sidebar settings of its own — there is nothing else to configure.

For every page at once. Put the same Custom HTML block into a template part instead of a page: in a block theme, that is Appearance → Editor → Patterns → the footer or a template you use everywhere. On a classic theme, Appearance → Widgets has a Custom HTML widget that does the same job in a sidebar or footer widget area. One block, every page it appears on.

Self-hosted WordPress has no plan gate — it has a permission gate. The capability is called unfiltered_html, and WordPress describes it as what “allows user to post HTML markup or even JavaScript code in pages, posts, comments and widgets”. Without it, WordPress runs your saved content through wp_kses() and strips disallowed tags including <script>.

• On a single-site install, Administrators and Editors have it. Authors, Contributors and Subscribers do not.
• On Multisite, WordPress is explicit: “only Super Admins have the unfiltered_html capability”. A site Administrator on a network install cannot save the tag.
• The block will tell you which of those you are, if you ask it. WordPress’s documentation for the Custom HTML block says that “starting in WordPress 7.0” it “introduces separate editing panels for HTML, CSS, and JavaScript”, and that those last two “are only available to users with the unfiltered_html capability”. So on 7.0 or later, a block offering you all three panels is a block that will keep your script tag; a block offering only HTML is the gate, showing itself before you have wasted a save on it.

WordPress.com is the one with a plan gate. The Custom HTML block is in the same place, but WordPress.com lists the tags it holds back: “To add the following tags, you will need a paid plan with hosting features activated: embed, frame, iframe, form, input, object, textarea, script, style, link”. A widget tag is a script tag, so it is on that list.

Note the second half of that sentence, because paying is only the first of two steps. A paid plan has to be activated on the site before it will accept custom code, and WordPress.com’s remedy for a tag that vanishes after saving is a single instruction: “Install at least one plugin on your site to activate your plan to accept custom code.” Any plugin will do — you are not installing it for what it does, you are installing it to flip the site into the tier that runs scripts. Which means the plan you need is a plugin-enabled one, since a plan that cannot install a plugin cannot take that step either.

You saved the block, and the tag is gone when you reopen it.

That is wp_kses() doing its job: the account you saved from does not have unfiltered_html, so the disallowed markup was removed when the post was saved. Nothing is broken and nothing needs reinstalling — publish the page from an Administrator account instead, or on Multisite ask a network Super Admin to save it once. Afterwards the block stays put; only the save is gated.

You are on WordPress.com, paid, and the tag still disappears.

Hosting features have not been activated on the site yet. Install any one plugin, which is what flips the site into accepting custom code, and paste the tag again.

You approved a new testimonial and the site still shows the old set.

This one is usually blamed on a caching plugin, and on WordPress it usually is not the cause. A page cache stores your HTML, and your HTML only ever contains the one unchanging script tag. The widget itself is served with cache-control: no-store, so every visit fetches the current set of approved testimonials even when the surrounding page is served from cache. If the list looks stale, check the approval queue in Testymo before you clear anything.

The theme’s styles are fighting the widget.

They cannot. The widget renders inside an open shadow root with its own reset, so theme CSS does not reach in and widget CSS does not leak out. If the section looks wrong, the cause is the container you dropped the block into — a narrow column or a fixed-height wrapper — not the theme.