How to Embed a Booking Widget on WordPress, Wix, Squarespace and Webflow
Pasting the snippet takes two minutes. The decision that actually matters is what you leave outside it.
Most guides to this are four screenshots and a paste instruction. They skip the thing that decides whether the page ever gets traffic: a modern booking widget is an application running inside an iframe on someone else's domain. Placement, speed and search all follow from that one fact.
So: what you are actually embedding, then the steps for each of the four builders tour operators actually use, then the parts nobody warns you about. If you want the general version first, adding a booking widget to your tour website covers the ground without the platform detail.
What you are actually embedding
The Travelity widget, like most current booking widgets, is a client-rendered application mounted in an iframe. That is the right architecture for the job: prices, availability and the payment flow stay correct without you touching anything. It also has a consequence operators tend to discover months later, while wondering why a beautiful tour page has no impressions.
Content inside the widget is not content on your page. A search engine crawling a page whose only substance sits in an iframe sees a heading and some whitespace. The widget sells; it does not rank.
Hence the rule that decides every choice below, on every platform: the page owns the content, the widget owns the transaction. Tour name, description, itinerary, photographs, duration, meeting point, price and reviews belong in your site's own editor, as text and images on the page. Live availability, the calendar, checkout and confirmation belong in the widget, because those have to stay current on their own.
Duplicating the price in page text is fine, as long as you change it in both places.
WordPress: use the booking widget plugin
WordPress is the one platform where the SEO problem above is solved for you rather than by you, because there is a plugin for it. If you run a booking widget on WordPress, use it instead of pasting a snippet.
Travelity Widget SEO is published in the official WordPress plugin directory. It pulls the products from your Travelity workspace into WordPress and builds a real, server-rendered page for each one, with the title, description and cover image in the markup where a crawler can read them, plus structured data and Open Graph tags. If you run Yoast or Rank Math it defers the meta output to them and adds only the structured data they do not. The widget is embedded on each page, bound to that product.
Setup is four steps. Install and activate from the WordPress plugins screen; it creates Checkout, Booking Result and Wishlist pages on activation. Go to Settings > Travelity and paste your widget API key from Travelity admin > Integrations > Widget — the only required setting. Press Sync now. Your products appear under Travelity Products and on an archive page.
Two details worth knowing. The three funnel pages are deliberately noindex — they are transactional steps, not content — but the widget navigates to them as real URLs instead of routing inside its own iframe, so every booking step appears in your analytics as a page. And a product you deactivate in Travelity has its WordPress page set to draft rather than deleted, so the URL survives.
To place the full widget somewhere else — a homepage section, a landing page — use the Travelity Booking Widget block, or the shortcode:
[travelity_widget] Requirements are WordPress 6.0 or higher and PHP 7.4 or higher. If your site runs Polylang or WPML, product pages are served under each language prefix automatically with no configuration.
Squarespace
No plugin, so this is the paste-and-write-your-own-content route. Build the tour page first — heading, description, gallery, price, meeting point — then add the widget underneath as the booking step.
Copy the current snippet from Travelity admin, open the tour page, add a Code Block where the booking step belongs, paste, apply, save.
The catch is plans. Squarespace code blocks accept plain text, HTML, Markdown and CSS on every plan, but only render JavaScript and iframes on the paid tiers — Core, Plus, Advanced and the legacy Business and Commerce plans. On a trial or an entry plan the block will save and show nothing to visitors, which looks exactly like a broken snippet. Check the plan before you spend an evening debugging.
Wix
Wix gives you Add Elements > Embed & Social, then either Embed Code, for pasting a snippet, or Embed a Site, for pointing at a URL. Paste into Embed Code and publish.
Wix runs custom code inside a sandboxed iframe of its own, so a widget that already mounts an iframe ends up nested a layer deeper. That usually shows up as height: the outer Wix element has a fixed size you set by dragging, and it will not grow when the widget inside it opens a calendar or moves to payment. Size it for the tallest state of the flow, and check after publishing rather than in the editor.
Two more Wix specifics. Everything you embed must be HTTPS; an HTTP address simply will not display. And code snippets are tied to a specific domain, so if you move the site to a different domain later, expect to add them again.
Webflow
The most forgiving of the three snippet platforms, because the Code Embed element drops your markup into the page itself rather than into a sandbox. Drag it in from the Add panel, paste, save, publish.
It needs a paid Site or Workspace plan, and the element is capped at 50,000 characters, which no widget snippet approaches. One quiet gotcha: newly published Webflow sites include jQuery 3.5.1, so a second copy loaded on the page produces behaviour that is hard to diagnose. Server-side code will not run there; HTML, CSS in style tags and JavaScript in script tags only.
If you run tours as a CMS Collection, put the Code Embed inside the collection template so every tour page gets a widget without building them one by one. Webflow is also where the page-content rule is easiest to honour, since you are designing around the widget rather than wedging it into a theme.
Embed or button-to-hosted-page?
Every platform supports both: embed the widget in the page, or place a button that sends the traveller to a hosted booking page. The trade-off is not the same on each.
| Platform | Recommended | Why |
|---|---|---|
| WordPress | Embed, via the plugin | Indexable pages and the widget on the same URL |
| Webflow | Embed | Code sits in the page; easy to template per tour |
| Squarespace | Embed on a paid plan, button otherwise | Scripts and iframes do not render on entry plans |
| Wix | Either; button if height fights you | Sandboxed element will not resize with the flow |
On whether embedding beats redirecting: for search, embedding wins whenever the page around it carries real tour content, because the page that ranks and the page that converts are the same URL. For speed, redirecting wins, because nothing loads until somebody clicks. And a button is the better answer when the alternative is upgrading a plan to paste one snippet. Booking widget versus booking page goes through the branding and tracking consequences in more depth.
Page speed, Core Web Vitals and mobile
A booking widget is a third-party application, so it costs something. Four habits keep the cost small.
- Only where people book. Tour pages and the booking page. Not the header, not site-wide, not the about page.
- After your content, not before it. The tour photographs and description should render while the widget is still loading, not after.
- Reserve its space. Give the container a defined height so the page does not jump when the widget appears. Layout shift is the vital most commonly failed by embeds, and it is the one most easily fixed.
- Do not stack third parties. A widget plus a chat bubble plus a review carousel plus two pixels is where mobile pages die.
Then measure on mobile, in a free page-speed tool, on your busiest tour page — desktop scores flatter every site and tell you nothing about what your guests experience. Test on a real phone on mobile data, complete a booking, and hand it to somebody who has not seen it before. Mobile booking for tours has the longer version of that test.
When the embed does not work
In rough order of how often each one is the actual cause.
- Nothing renders at all. On Squarespace, check the plan first — scripts and iframes need a paid tier. On Wix and Webflow, check you are looking at the published site rather than the editor.
- You can see your snippet as text on the page. On Squarespace that is the Display Source toggle left on in the code block settings. Turn it off.
- It works for visitors but not for you. Both Squarespace and Webflow can behave differently while you are logged into the editor. Check in a private window before reporting a bug.
- It appears, then gets cut off. Container height, almost always — most visible on Wix. Size for the tallest step in the flow.
- Fine on desktop, broken on a phone. A fixed pixel width somewhere in the container. Widths should be percentages.
- Nothing loads and the browser complains. An HTTP address in a snippet on an HTTPS site, or a stale snippet copied from an old version. Re-copy it from Travelity admin rather than from last year's email.
One last check: complete a real booking yourself, on a phone, and confirm it arrives in your dashboard with the right product, date and guest count. An embed that displays is not the same as an embed that works.
How Travelity helps
The booking widget takes its theme from your workspace, so colours and fonts follow your site, and it connects to live availability and your own payment gateway. On WordPress the plugin above solves the indexability problem outright. The 21-day trial needs no card, which is long enough to embed the widget on a staging page, run the mobile test and take a real test booking before committing to anything.
Frequently asked questions
How do I add a direct booking widget to my existing website?
Copy the widget snippet from your booking platform, then paste it into whatever your site builder calls a code area: a block or plugin on WordPress, a Code Block on Squarespace, an Embed Code element on Wix, a Code Embed element on Webflow. The step most operators skip is writing the tour description, photos and price into the page itself rather than leaving them inside the widget, because a widget that mounts in an iframe is not readable by search engines.
Do booking widgets hurt SEO?
A widget does not damage a page it sits on, but nothing inside it counts as content on that page. If the tour name, description, photos and price exist only in the widget, the page is effectively empty to a search engine. Write that content into the page itself and let the widget handle availability, payment and confirmation, which is the part that has to stay live.
Are embedded booking widgets better than redirecting to a hosted booking page?
For search, the embed wins when the surrounding page carries real tour content, because the ranking page and the booking happen at the same URL. For page speed, the redirect wins, because nothing heavy loads until somebody clicks. A button that opens a hosted page is also the honest answer on builders where scripts are restricted or a plan upgrade would be needed just to paste a snippet.
Will a booking widget slow down my website?
It can, and the fix is placement rather than removal. Put the widget only on pages where somebody books, load it after the page content rather than before it, and reserve its space in the layout so the page does not jump when it appears. Measure the mobile score of your busiest tour page before and after, since desktop scores flatter almost every site.
Why is my booking widget not showing on Squarespace?
Three causes cover nearly all of it. Squarespace renders JavaScript and iframes in code blocks only on its paid plans, so on a trial or entry plan the block saves but shows nothing publicly. The Display Source toggle in the block settings prints your snippet as visible text when it is on. And code sometimes does not render while you are logged in, so check the published page in a private window before concluding it is broken.
Bottom line
On WordPress, install the plugin and the hard part is done for you. On the other three, the paste is trivial and the work is writing the tour page around the widget so there is something for a search engine to find.
Then place it only where people book, give it room to grow, and finish by taking a real booking on a real phone. That last step catches more problems than every preview screen combined.
Related guides
See Travelity in action. Book a Personalized Demo.
30 minutes that can completely change the way you run your travel business. See how Travelity can help you work smarter, sell more, and operate with less stress.