Website widget
How to add a recent-work widget to your website
A single script tag, and where it goes in WordPress, GoHighLevel, Wix, Squarespace, Shopify, Webflow and five more builders.
It is one script tag, and it belongs in the page body
A recent-work widget loads itself. There is no stylesheet to add, no library to install, no build step to run. You paste one `<script>` tag where the block should appear, and the script creates everything it needs inside that spot.
That has a consequence worth knowing before you start: the tag has to sit in the visible part of the page — the body — and not in a header or footer injection field. Header fields exist for analytics and verification tags, which have nothing to display. This one has something to display, so it needs to be where you want it seen.
- Paste it exactly as given; do not change the URL or add attributes.
- Put it in the page body, at the position the block should occupy.
- Do not wrap it in another iframe — the script makes its own.
- One page can carry it more than once only if each tag is a different widget.
Find what your builder calls a code block
Every builder has one. The name is the only thing that changes, and each of them means the same: a container whose contents are treated as HTML rather than as text.
**WordPress** calls it a Custom HTML block, and the page builders layered on top of it — Elementor, Divi, Beaver Builder — each ship their own HTML or Code widget. **GoHighLevel** calls it a Custom Code element. **Wix** calls it Embed Code. **Squarespace** calls it a Code block. **Shopify** offers a Custom Liquid section, or the HTML view inside the page editor. **Webflow** and **Framer** both call it an Embed. **GoDaddy** calls it an HTML section, and **Duda** an HTML widget. A hand-built site needs no block at all: open the file and paste the tag inside the body.
Two things that make a working install look broken
The first is the editor preview. Squarespace, Webflow, Framer and GoHighLevel do not run third-party scripts inside their own editing canvas. You will see an empty box, a grey placeholder, or nothing at all, and conclude the code failed. Publish the page and open it as a visitor before judging anything — that is the only view that tells the truth.
The second is plan gating. Wix and Squarespace both reserve custom code for paid plans, and Wix additionally requires a connected domain. If the code block is missing from the menu entirely, or refuses to save, the plan is usually the reason rather than the code.
- Judge the result on the published page, never in the editor.
- Wix places embeds in a fixed-size frame — give the element generous height.
- Not every Shopify theme offers Custom Liquid; the page HTML editor works on all of them.
If an AI maintains the site, hand it the constraints
More sites are edited through an assistant than through a builder's menus now, and an assistant that is only given a tag will often improve it — change the URL, add attributes, move it to the head, wrap it in a container that breaks its sizing. Each of those turns a working widget into a support ticket.
Give it the tag and the rules together: paste it unchanged, put it in the body where the block should appear, no stylesheet or build step, do not wrap it in another iframe, keep it on the published page. Then ask it which page it used and where. That last question is what makes the result checkable.
Check it the way a customer will
Open the published page in a normal browser window, not a preview and not a logged-in editor. The block should appear where you placed it, sized to the space you gave it, and it should still be there after a hard refresh.
If the widget shows an empty state rather than work, the installation is fine and the business has not published anything yet. That is a different problem with a different fix, and telling them apart saves an afternoon: an install problem shows nothing at all; a content problem shows the widget, politely empty.
When it still will not work
Check the three things that account for most of it, in order: the tag is in the body rather than a header field, you are looking at the published page rather than an editor, and the plan actually permits custom code.
If all three are true and the block still does not appear, stop guessing. Builders change their menus with every redesign, and a guide written last season can send you looking for a button that has moved. Ask support with the page URL and what you see — that is faster than another hour of trying.