You added a ＜script＞ to a Custom HTML block, saved, and your JavaScript doesn’t run. The script tag is often gone when you reopen the block. In almost every case this is WordPress removing the tag on save, not a fault in your code. Here’s how to tell what’s happening and how to fix it.
First, are you looking at the editor or the live page?
Scripts in a Custom HTML block don’t run inside the block editor preview. They run on the published page. Before anything else, view the live front end of the page, not the editor, and check there.
Why the tag disappears on save
When you save a post or page, WordPress runs the content through a filter that strips tags it treats as unsafe for the current account, including ＜script＞. Whether your script survives comes down to a user capability called unfiltered_html. Accounts that have it keep raw script and style. Accounts that don’t have it lose those tags on save. A Custom HTML block stores raw markup, but it’s still subject to this filter.
Check the account
- On a standard single-site install, administrator and editor accounts have
unfiltered_htmlby default, so their scripts are kept. - On WordPress multisite, the rule is tighter: only network (super) admins have it, so even a site administrator’s script tags get stripped.
- If the role is right and the script still vanishes, a security plugin, a host-level filter, or the
DISALLOW_UNFILTERED_HTMLconstant may be removing it.
A cleaner place for site-wide scripts
Even when your account keeps script tags, scattering them across Custom HTML blocks is hard to manage. With Loupely Canvas, site-wide scripts go in the head or body code box once, under Appearance, Loupely Canvas, instead of being pasted into every block. The theme renders your markup as written, so what you add is what loads. A one-off script for a single page still works in a Custom HTML block when your account has the capability.
