Yes, you can add timetables, upcoming departures and booking search to the website you already have, without rebuilding it. The cleanest route is a widget built as a web component: a small component you drop into a WordPress page, or a page in another CMS, with a few lines of code. It reads its data from an external system and sends the customer on to the booking engine. Your site stays as it is, with its copy, its design and its search rankings; what changes is what visitors can do on those pages.
Why you don’t need a new website
When an operator wants to sell more online, the first suggestion they hear is often “let’s redo the website”. Sometimes that’s right. Often, though, the site works: it ranks, it has been paid for, and whoever updates it knows how. What’s missing is one specific feature: showing timetables, upcoming departures and prices, and letting people start a booking without leaving the page.
Rebuilding everything to add one feature brings costs and risks you can avoid:
- rankings can drop if page addresses and structure change;
- whoever manages the content has to learn a new tool;
- timelines stretch, because the new feature comes bundled with redoing everything else.
A widget separates the two problems: the site remains the container, the widget brings the data and the booking.
How a web component widget works
A web component is a custom element that the browser treats like any other tag. You add a tag and a script to the page, and from then on the widget appears in that spot, with its own logic and data.
Compared with the usual alternatives:
| Approach | Pros | Cons |
|---|---|---|
| Iframe | Fully isolated from the host site. | Height has to be managed, looks detached from the site, harder to track. |
| CMS-specific plugin | Built into that CMS’s admin panel. | Only works there; has to be rebuilt for each platform. |
| Web component | One component for WordPress and other CMSs, blends into the page. | Has to be designed to coexist with the host site’s styles. |
The practical benefit is that the same widget fits into sites built with different tools. If you run several sites, or your site moves to another platform later, the widget moves with a few lines.
You manage the timetables from a panel
A widget showing the wrong times does more harm than no widget at all. So the key question isn’t “how do I embed it” but “who updates the data, and where”.
My preferred answer is a headless CMS: a content management panel that is separate from the website and serves the data to the widget. With Strapi, for instance, office staff update seasonal timetables and fares through a simple interface, and the widget picks them up automatically. No more tables pasted into pages by hand, no more timetable PDFs to re-upload every season.
This way:
- each timetable lives in one place, and every page that shows it is always current;
- fares can have different categories (for example adults, children, seniors, groups);
- the website is still managed as before, by the people who already manage it.
What the widget can do
It depends on what you sell, but for an operator running scheduled departures the most useful features are:
- route search, with departure, arrival, number of passengers and a calendar for outbound and return;
- upcoming departures that update themselves: past or suspended sailings disappear, and once the day’s departures are over the widget moves on to the next day;
- seasonal timetables and fares, filterable by port or departure point;
- a hand-off to the booking engine, with the search already filled in and in the right language.
If the actual booking happens in a booking engine, the widget is the front door: it captures the customer’s choice at the point on the page where interest is highest and takes them to the next step without making them search again.
Living alongside the host website
This is where a well-built widget differs from one that “breaks sometimes”. The host site has its own styles, menus and scripts. The widget has to work inside that context without disturbing it, and without being disturbed by it.
The typical problems are few but recurring:
- styles leak: a font, margin or colour from the site ends up in the widget, or the other way round;
- elements overlap: a calendar or pop-up opens underneath the site’s sticky header instead of on top of it;
- there isn’t enough room on phones: a full search is best opened in a full-screen window that also covers the site’s header;
- the search disappears as you scroll: on long pages a search bar that stays visible helps.
There is a less visible issue too. If the API providing the data doesn’t accept requests from another domain (the browser’s CORS restriction), the widget can’t read it. The fix is a small proxy on the site’s own domain that forwards only the permitted paths and nothing else.
Measuring what happens
A widget is only useful if you know how much it’s used. Connected to Google Tag Manager, every meaningful action (a search, picking a date, moving on to the booking) becomes an event you can read in your analytics tools. That shows where people stop and which pages actually lead to bookings.
A real example
For sea transport operators I built several timetable, departures and booking widgets to embed in existing websites built with WordPress and other CMSs. The widgets are web components made with Angular Elements; seasonal timetables and fares are managed in a content back office on Strapi, with filters by port.
The search covers departure, arrival, passengers and an outbound and return calendar, and opens the booking engine in the right language. Upcoming departures update on their own, leave out past or suspended sailings and roll over to the next day; there are desktop and mobile versions, in Italian and English. On mobile, the search opens in a window that hides the host site’s header, and on long pages a sticky search bar stays available.
The trickiest parts were the ones described above: making the widgets coexist with the host sites’ styles and stacking order, and routing requests through a same-origin proxy with whitelisted paths where the API didn’t allow requests from other domains. Each widget ships as a single file, with cache busting so browsers fetch the new version after every update.
When a widget makes sense, and when it doesn’t
A widget is the right choice when the site works and one specific feature is missing. It’s less suitable when:
- the site needs rebuilding anyway, for other reasons;
- the whole booking flow, payment included, has to happen inside the page, and you don’t control the host site;
- the data you want to show doesn’t exist in any system yet and needs organising first.
In that last case the real work comes earlier: deciding where timetables, availability and prices live. I cover that in the article on how a booking engine works for tour operators, activities and rentals and, for connecting different systems, in the one on APIs and business software integration.
Frequently asked questions
Will the widget slow down my site?
A well-built widget is light and loads like any other script. It’s best shipped as a single file, with cache busting so browsers download the new version after each update.
Does it work if my site isn’t on WordPress?
Yes. Web components are a browser standard: they work in any CMS that lets you add a tag and a script to a page.
Who updates the timetables?
You or your staff, from a content panel separate from the website. The widget reads the data automatically, so the pages don’t need touching.
Where to start
If your website works but doesn’t sell as much as it could, we can look together at what to add and where. You can see how I handle integrations and booking engines, or tell me about your case; the initial analysis is free.