Most people who open an airline website want to search for a flight. The search box sits at the top of the page, while availability, fares, seats and payment run on the airline’s commerce platform. Everything around it is content: destination and route pages, offers by market, baggage rules, and travel alerts that must go live within minutes when weather closes an airport, in several languages, with Arabic read right to left.
That split decides how an airline should use SitecoreAI, which Sitecore unveiled in November 2025 as the evolution of XM Cloud. EgyptAir, Egypt’s flag carrier flying to 93 destinations, is rebuilding its digital front door and passenger CRM with Arcsen, and in October 2026 Sitecore announced that SitecoreAI will power its main website, country sites and app content (read the announcement). Here is what a booking-led site needs from the platform.
The booking engine stays in the commerce platform
SitecoreAI should never copy availability, fares or payment. Its job is to start the booking well. With Bring Your Own Components, developers register their own React or web components, which appear in the editor like native ones, with a settings panel generated from a JSON schema. An editor can place the flight search on a destination page and preset the origin, destination or promo code, and the code stays with the airline: Sitecore says it cannot access the source of these components.
Write the hand-off as a contract between the web and commerce teams, listing every parameter the search passes, from market, language and currency to dates, passengers, cabin and campaign codes. Three rules save trouble:
- Prices come from the fare engine. A “from” fare is fetched with its market and timestamp, and hidden when the feed fails. A fare typed into the CMS is wrong the day it changes.
- Language and direction carry across. A search in Arabic lands in an Arabic, right-to-left booking flow.
- Render the search box on the server. Sitecore recommends hybrid rendering whenever possible: prerendered on the server for a faster first view and better SEO, then interactive in the browser.
Destination and route pages at scale
A network multiplies pages: one per destination, one per city pair, each in every language and market. Write destination content once per city and language, and generate route pages from the network schedule. The Authoring and Management GraphQL API creates, updates, copies and deletes items, so a scheduled job can add a route page when a route opens and retire it, with a redirect, when it closes.
Three Experience Edge limits shape the design. Wildcard items are supported on the Preview endpoint only, so every route you want indexed needs a real item. A request returns at most 1,000 entities, so the job pages through results. And Experience Edge holds at most 9,990 redirects, so count old route URLs before a migration. Route pages also answer what travellers ask AI assistants, such as who flies a route direct, so plan them with AI visibility in mind.
This is how we assign each kind of page and data:
| Page or data | Owner and source | What SitecoreAI holds | How it stays current |
|---|---|---|---|
| Flight search and booking | The commerce platform | The search component and its defaults | Defaults set by editors per page |
| “From” fares | The fare engine | Market and route codes | Fetched with a timestamp, hidden if the feed fails |
| Destination pages | Editors | Copy, photos, airport information, FAQs | Reviewed on a set schedule |
| Route pages | The network schedule | The two cities and route copy | Created and retired by a job |
| Offers by market | Marketing and legal | Copy, terms, markets, start and end dates | Approved per language, filtered by date |
| Travel alerts | The operations desk | Alert items with markets, airports and times | Short workflow, refreshed on publish |
| Member content | The loyalty platform | Words and components for each tier | Chosen at sign-in |
Markets, offers and languages
Each market has its own currency, offers, payment methods, phone numbers and legal text, so many airlines run a site per country. Experience Edge allows up to 1,000 sites per environment, and sites can share a start item only when each has its own default language and hostname and a language-based setting is enabled. Settle the site structure first, because it decides how markets share content.
Offers need dates. Page builder can schedule each version of a page with a start and an end, and you must still publish the page or site when each date starts. For a fare sale that opens at midnight in several markets, name the person who publishes, or give offer items start and end fields that the front end filters by time.
Design and test Arabic pages in Arabic, with the booking flow to match; our guide to Arabic-first Sitecore lists the checks. Experience Edge switches language fallback on or off for the whole instance, so decide it once, and publish each offer in all its languages together.
Travel alerts and speed on disruption days
Disruption brings two problems at once: alerts about closed airports, strikes or changed entry rules must go live in every language within minutes, and traffic rises as passengers check what to do. Flight status comes from the operations systems. The alert, the advice and the rebooking link are content.
- Model alerts as their own items, with markets, airports and times, queried by the front end directly. Sitecore notes that datasource changes may require republishing the pages and partial designs that use them, which is too slow for a banner during a storm.
- Give alerts a short workflow, from the operations desk to an approver on duty, with pre-approved wording in each language.
- Refresh on publish. A webhook event handler can call the front end on
publish:end, with rules that limit which items trigger it. Experience Edge webhooks cannot be limited by site, so the front end checks which markets an alert concerns.
Speed comes from the front end. Experience Edge allows 80 requests per second on its delivery API, so pages are pre-rendered and cached at the host. Measure against Google’s Core Web Vitals: Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint under 200 milliseconds, Cumulative Layout Shift under 0.1. Reserve space for the search box so it cannot shift the page, and test in Arabic on mid-range phones.
Personalization by market and loyalty status
Start with the market. Page builder audiences combine time, date, device, geography, visit, user interaction and point of sale conditions. Use geography to suggest a market, and let the visitor choose: a Riyadh resident opening the site in London usually still wants the Saudi site and its offers.
Loyalty status needs a known visitor. Identity resolution links profiles when a visitor gives an email address, phone number or loyalty number, through IDENTITY events sent with the Cloud SDK. It is off by default, an admin must opt in, and Sitecore lists it as a phased rollout. Custom conditions built in Sitecore Personalize also appear in Page builder. A simpler route works for signed-in members: the front end reads the tier from the sign-in session and picks the matching component.
Either way, balances and bookings stay in the loyalty platform, since Experience Edge does not vary its output by user. Personalization relies on cookies, so tie it to each market’s consent banner. Our guide to personalization on SitecoreAI covers what to rebuild from XP.
Where to start
- Write the booking hand-off contract with the commerce team, and test every parameter in Arabic and English.
- Count your pages: destinations, routes, markets and languages, and decide which are generated from the schedule.
- Design the alert path, then time it in a drill in every language.
- Set performance budgets for each page type against the Core Web Vitals, measured on phones.
- Pick one personalization rule for market or loyalty, agree consent with legal, and compare it with the default page.
Frequently asked questions
Can SitecoreAI run an airline booking engine?
No. Availability, fares, seats and payment run on the commerce platform. SitecoreAI holds the flight search component and the content around it, and passes each search to the booking engine.
How can an airline publish a route page for every city pair?
Generate route items from the network schedule through the Authoring and Management GraphQL API. Experience Edge supports wildcard items on its Preview endpoint only, so each indexed route needs its own item.
How fast can a travel alert go live?
It depends on the front end, and Sitecore notes a published change may take time to appear. Model alerts as their own items, refresh on publish, and time the path in a drill.
Can SitecoreAI personalize by loyalty tier?
Yes, once the visitor is known. Identity resolution, off by default and in a phased rollout, links profiles by email, phone or loyalty number. Balances and bookings stay in the loyalty platform.
Does SitecoreAI support Arabic airline sites?
Arabic can be one of a site’s languages, with its own versions and review. Right-to-left layout depends on the front end, and the booking engine must support Arabic too.
Sources
- Sitecore press release: EgyptAir moves passenger experience into the AI era with Sitecore (October 2026)
- Sitecore press release: Sitecore unveils SitecoreAI (November 2025)
- Sitecore documentation: Bring your own components
- Sitecore documentation: Query examples for authoring operations
- Sitecore documentation: Limitations and restrictions of Experience Edge
- Sitecore documentation: Schedule publishing availability of a page
- Sitecore documentation: Webhook event handler configuration fields
- Sitecore documentation: Personalize in SitecoreAI
- Sitecore documentation: Identity resolution
- Google Search Central: Understanding Core Web Vitals
