Most advice about structured data for travel is a list of every type schema.org publishes, which is not useful when you have limited engineering time and a catalogue that changes daily. This is the order we actually work in.
Start with one connected graph, not scattered blocks
Before deciding which types to add, decide how they will relate to each other.
The common failure on real sites is four separate <script type="application/ld+json">
blocks, dropped in by four different plugins over five years, each declaring
its own unconnected Organization. A parser then has to guess which one is
authoritative, and guessing is exactly what structured data exists to prevent.
Emit one script per page, containing one @graph, in which every node has a
stable @id and refers to other nodes by @id rather than repeating them:
{
"@context": "https://schema.org",
"@graph": [
{ "@type": "TravelAgency", "@id": "https://example.co.uk/#organization", "name": "..." },
{ "@type": "WebSite", "@id": "https://example.co.uk/#website", "publisher": { "@id": "https://example.co.uk/#organization" } },
{ "@type": "WebPage", "@id": "https://example.co.uk/kenya#webpage", "isPartOf": { "@id": "https://example.co.uk/#website" } }
]
}Getting this shape right first means everything you add afterwards has somewhere to attach.
The four that earn their place
1. The organisation entity
TravelAgency or TourOperator, sitewide, with your legal name, URL, logo,
contact details and — importantly for travel — your accreditations.
ATOL, ABTA, AITO and IATA membership are among the most frequently asked questions about any travel company, and on most sites they exist only as a footer image or a PDF. Neither is readable. Express them explicitly, and give the certificate number.
2. Product and Offer for each trip
This is where travel sites lose the most ground. An itinerary is a structured object — duration, departure points, inclusions, price bands, conditions — and almost none of that reaches a machine in a usable form.
At minimum, every trip page needs a Product (or TouristTrip) carrying the
name and description, with an Offer carrying price, priceCurrency and
availability. If your prices are per person, say so. If they are “from”
prices, use PriceSpecification with minPrice rather than stating a flat
price you cannot honour, which is both a markup error and a consumer-law
problem waiting to happen.
3. FAQPage, where you genuinely have questions
Question-and-answer content is disproportionately useful to answer engines, because it is already in the shape a model wants to quote.
The rule that matters: only mark up questions and answers that are visible on
the page. Marking up content the user cannot see is a spam signal, and on a
travel site it is usually unnecessary anyway — most operators already have fast
facts, “need to know” panels or destination guides that convert cleanly into
FAQPage markup with no new content required.
4. BreadcrumbList
Cheap, mechanical, and it tells a model how your catalogue is organised — that Kenya sits within Africa, that this safari sits within Kenya. Structure is context, and context is what lets a model answer a specific question with a specific page.
The ones to skip, at least at first
Review and AggregateRating are widely abused and increasingly discounted
where they cannot be corroborated. Add them only where real reviews appear on
the page, and prefer pointing at an independent review platform.
Event is rarely a fit for scheduled departures, despite the temptation.
Trip and TouristTrip are useful but less well supported than plain
Product, so where you have limited time, do Product first and layer Trip
on afterwards.
Templated, not hand-written
The last point is the one that determines whether this survives contact with a real business.
Marking up forty pages by hand is a different job from marking up a catalogue that changes daily across several markets and currencies. If your structured data is written into pages by hand, it will be accurate on the day it ships and wrong within a quarter.
Generate it from the same data that renders the page. Then a price change updates both the visible page and the markup, because they are the same fact expressed twice — which is the only arrangement that stays true.