Structured data is a block of code, invisible to visitors, that tells search engines what a page contains: this is a tour, it costs this much, it starts here, it has these reviews, it belongs to this company. For a tour operator or a rental business, it lets Google and AI assistants understand what you offer without guessing from the copy. It is usually written as JSON-LD using the schema.org vocabulary, and it only works when it’s consistent: a company described twice in two different ways, or an average rating that doesn’t match the reviews, does more harm than having no structured data at all.
What it is, in practice
To a person, a tour page is obvious: there’s a title, a gallery, a price, a “book” button. To a search engine it’s text and images to interpret. Structured data adds an explicit description in a standard format that says: this is a TouristTrip, this is its offer with price and currency, this is the organisation selling it.
It isn’t a shortcut to higher rankings. It does three concrete things:
- makes the page eligible for rich results, such as prices, ratings or breadcrumb trails shown directly in Google (which then decides whether to show them);
- removes ambiguity about who you are, what you sell and where you operate;
- provides clean information to the AI systems that read the web to answer questions.
Useful schema.org types for tours and activities
You don’t need all of them. You need the right ones for each kind of page.
| Page | Most useful types | What they describe |
|---|---|---|
| Home and company pages | Organization or LocalBusiness, WebSite |
Who you are, contact details, logo, social profiles, on-site search. |
| A tour or activity page | TouristTrip, Product, Offer |
Itinerary, duration, price, currency, availability. |
| Reviews | Review, AggregateRating |
Individual reviews and the average rating. |
| Listings (catalogue, category) | ItemList |
The ordered list of tours or services. |
| All inner pages | BreadcrumbList |
The navigation path: home, category, page. |
| Blog articles | BlogPosting |
Author, date, headline. |
| FAQs | FAQPage |
The questions and answers on the page. |
Two reality checks. Google now shows FAQ rich results only for a small number of authoritative sites, so FAQPage mainly helps describe your content well rather than win an extra box. And review stars that a business publishes about itself are no longer shown in search results: the rating is still useful information, but it has to be reported honestly and consistently.
One graph, not scattered fragments
The most robust way to write structured data is a single graph per page: one JSON-LD block in which the nodes (organisation, website, page, tour, offer) reference each other through an identifier, the @id field. The organisation is described once, and the tour simply says “I’m sold by that organisation”.
Problems start when several tools each write their own piece: the site theme, an SEO plugin, the reviews widget, a script added years ago. Each one has its own idea of who you are, and the result is a company described three times with different details.
The most common mistakes
They are almost always the same:
- two organisation nodes with the same identifier but different content: the address in one, the phone number in the other, slightly different names;
- inconsistent ratings: one average rating in one block and a different rating, or a different review count, in a second block on the same page;
- breadcrumbs that don’t match the site: paths to pages that no longer exist, or categories that differ from the menu;
- outdated prices: the offer in the structured data says one price, the page another;
- auto-generated data nobody has checked: the plugin outputs something, and nobody has ever read it.
None of these mistakes is visible on the site itself. You only see them by reading the code or running the page through validation tools.
If your site runs on WordPress
On WordPress, the first step is finding out who is already writing structured data. The SEO plugin often generates it automatically, and other plugins add their own. Pick a single source: either configure the plugin properly, or switch off its JSON-LD output and generate the graph with one dedicated component that knows which types to use for each kind of page.
The second route takes more work up front, but makes the outcome predictable: a tour’s structured data comes from the same data that builds the page, so it can’t contradict it.
If your site runs on a closed CMS
Many tourism businesses use proprietary platforms where you can’t edit the page templates. That isn’t a dead end. You can almost always add a script to the pages, and from there you can:
- switch off or neutralise the incorrect structured data block the platform produces;
- insert the correct one in its place, built for each kind of page;
- leave alone whatever already works, such as the reviews widget.
Google also reads structured data added through JavaScript. It’s an intervention that needs care, with tests that check the output page by page, but it lets you fix the data without changing platform.
Validating with Google’s tools
Every change should be checked. The tools are free:
- Rich Results Test: tells you whether the page is eligible for rich results and flags errors and warnings.
- Schema.org validator: checks correctness against the vocabulary, including types Google doesn’t use for rich results.
- Google Search Console: after publishing, its enhancement reports show the errors detected across the whole site over time.
Alongside these manual checks, it pays to have automated tests that confirm, on every change, that each kind of page produces the expected graph.
Two real examples
I’ve worked on the structured data of two tourism websites, on my own, starting from different situations.
The first is a multilingual WordPress site with a block theme. The SEO plugin generated its own JSON-LD, and the audit found two organisation nodes sharing the same identifier with ratings that contradicted each other, plus breadcrumbs that needed fixing. I switched off the plugin’s automatic output and wrote a single graph generator per page type, covering TouristTrip, Product, Offer, Review, AggregateRating, BreadcrumbList, ItemList, BlogPosting and WebSite with on-site search.
The second runs on a proprietary CMS with no access to the page templates. Here a script switches off the incorrect organisation block produced by the platform and inserts the correct one, leaving the reviews widget untouched. Each page’s structured data comes from a single bundle generated from twelve models (tours, services, product pages, FAQs, blog, legal pages). To build it I extracted an inventory of the pages while excluding any personal data; the output is covered by automated tests and checked with the Rich Results Test.
On one of the two, an excursion agency’s website, the work did not stop at JSON-LD. I also handled the launch, with forced HTTPS and 301 redirects to the main domain, caching and compression for speed, Google Tag Manager for tracking, and an llms.txt file listing the articles in both languages for AI-based search engines.
Frequently asked questions
Does structured data improve rankings?
Not directly. It makes pages eligible for rich results and clearer to search engines, which can improve visibility and clicks. It doesn’t replace useful content and a fast site.
Isn’t the SEO plugin enough?
Sometimes, if it’s configured well and no other tool adds conflicting data. It’s still worth checking what it outputs: it often produces generic types and has no idea a page describes a tour.
Can it be fixed without rebuilding the site?
Yes. On WordPress you work on the theme or add a dedicated component; on a closed CMS, almost always, with a script added to the pages.
Where to start
If your site sells tours, activities or rentals and you’re not sure what it tells search engines about you, we can review it together. You can see how I work on booking engines and on maintaining and evolving existing software, or get in touch directly; the initial analysis is free.