Ask three AI assistants for flights from Denver to Orlando, and you will get three different-looking answers.
Logged out of ChatGPT, you get a bulleted briefing: which airlines fly nonstop, a flight time of about 3 hours 50 minutes, roughly 10 nonstop flights per day, and typical fares from about $77 one-way and $154 round-trip.
In a logged-in ChatGPT session, the shape is similar, but the pricing is broken out further: one-way from about $77, round-trip from about $154, business class from about $392.
In Google’s AI Mode, you get an actual comparison table: four carriers, flight times, nonstop or connecting, and a starting fare for each, followed by nonstop schedules grouped by time of day and a note that prices are lowest two weeks to three months before departure.
What they have in common is more instructive than what separates them. Every one of those answers leads with fares and flight facts. And in each one, the airlines are named — Frontier, Southwest, United, American — while the citations go to FlightConnections, Airportia, Google Flights, Trip.com, Priceline, and Skyscanner.
That is the pattern we quantified in our research on ChatGPT’s citation behavior: airlines were mentioned constantly in flight answers. Still, they received the link only about a quarter of the time, while OTAs and aggregators were linked more than 90% of the time they came up.
Our playbook article covered the headline fix: make every fare findable. This piece goes a layer deeper, because “show more fares” turns out to be three different problems wearing one coat.
The Role of Fares in AI Flight Answers
Across platforms and model versions, answers to flight queries keep getting denser in exactly three things: fare variety, flight information, and booking insights. What it costs one-way, round-trip, direct, connecting, and in business class. Flight time. Nonstop or connecting. How many flights per day. When to book.
Of those three, fares behave differently from the rest. Prices move daily, so they are the element of a flight answer most likely to force the model to perform a web search. Even before a traveler provides dates, passenger count, or a cabin preference, an assistant needs route-level pricing: a starting one-way fare, a typical round-trip fare, a business-class entry point, and the cheapest month to fly. These don’t require a live availability search. They require a published fare sitting on a flight page.
Fare data is also different from the destination content airlines have spent the last decade building. Guides to neighborhoods, attractions, and the best time to visit answer a different question than a flight search asks. Look at what AI assistants actually cover when someone searches for flights between two cities: prices, flight times, nonstop vs. connecting, flight frequency, and when to book. Destination editorial rarely appears in AI responses for flight searches.
Fares, on the other hand, are universally present in flight-search answers, which means a missing round-trip price can cost you a slot in the answer entirely. That dynamic explains something that surprised us in the original research: airlines lose the link on their own prices.
The Three Dimensions of Fare Coverage
“Make every fare findable”, broken apart, asks three distinct questions of a flight page: can a crawler read the price at all, how many kinds of fare does the page carry, and how far does that pricing extend across time?
Those questions are worth keeping separate, because they land on different desks. An airline can render fares perfectly server-side and still lose the citation because it only publishes round-trip prices. Another can publish every fare type and lose it because they all arrive via JavaScript.
Dimension 1: Retrievability
Search systems do not all process client-rendered content in the same way. Google renders JavaScript, but rendering introduces an additional processing step and can fail; other crawlers may not render it at all. OpenAI does not publicly guarantee JavaScript execution for OAI-SearchBot or ChatGPT-User. Server-rendering critical fare data removes that dependency.
View Source is a useful first test. If a visible price does not appear there, it was not included in the initial HTML response. That does not prove the fare is invisible to every search system, but it does mean that any non-rendering crawler will miss it.
How to check it yourself, in about a minute:
- Open the page and use View Source (Not Inspect Element, which shows the rendered DOM after scripts have run); View Source shows the raw HTML response.
- Search the source for a price string you can see on the page.
- If it isn’t there, the fare is client-side and effectively invisible to non-rendering AI crawlers.
Note: Confirming whether fares are accessible to Google requires a slightly more involved check than the View Source test above.
Server-Rendering Fares With airTRFX
On airTRFX pages, this is handled by default: every Dynamic Pricing airModule (DPA) writes its fares into the HTML response before it leaves the server. If your fares are produced by something else, run the test above against them before assuming they’re visible.
Make Each Fare Self-Describing
Server-side rendering helps crawlers find fares. The next step is making their meaning explicit.
A standalone “From $385” requires context from the page layout. Adding route, trip type, and cabin makes it self-contained: “Recent economy round-trip fares from Boston to Lisbon start at $385.”
This doesn’t ensure AI citation, but it gives search and AI systems a clear, standalone statement.
On airTRFX, the lowest-fare variable can populate:
- Module heading (DPA H2): “Economy round-trip fares from Heraklion to Athens start at €21”
- Supporting text (DPA Subheading): “Find the lowest one-way fares from Heraklion to Athens from €21”
- Meta description: include the lowest current fare
These can be generated from the same fare data as the module, keeping the visible labels and prices consistent.
Dimension 2: Breadth
Breadth is where many airline pages are thinnest, and it is easiest to understand by mapping different pricing views to the queries they serve.
Each row represents a distinct commercial intent, and many are slots an AI answer may need to fill.
You can watch this happen in real answers. The logged-in ChatGPT response to our Denver–Orlando query didn’t stop at a starting price; it split fares into one-way, round-trip, and business-class, all in the same three-line block, and cited a third party for each. Google’s AI Mode went further, giving every carrier its own row with a nonstop-or-connecting label.
Nobody prompted for cabin class or asked about connections. Those responses added fare and itinerary dimensions the user had not explicitly requested, then cited third parties for them.
OTAs cover this ground comprehensively: one-way and round-trip modules, class-specific deal sections, and prices restated in headings and meta descriptions. That breadth of coverage may help explain why they receive citations across so many different query shapes.
Targeting Fare Types With Individual DPAs
Airlines that use airTRFX can build that same breadth of coverage programmatically. Each DPA targets a specific fare type: one module for one-way fares, another for round-trip fares, and others for cabin class or last-minute deals. Because each module publishes its own prices under its own heading, a route page ends up covering several distinct commercial intents rather than restating a single starting price in different words.
Consolidating Fare Modules With the Tab Widget
How many fare modules to run on a page is a design choice, and airlines land in different places. Some are comfortable stacking several down a route page; others prefer a tighter layout. For the latter, the Tab Widget groups related modules into a single component, so multiple fare views share the footprint of a single module. Every panel remains in the server-rendered HTML, so the consolidation is visual rather than informational: the underlying fares remain available to crawlers that process the page.
Publishing Connecting Fares and Layover Data
In our research, “Layover & Connections” was the most common topic in AI answers carrying the highest unlinked rate.
It has also been the hardest row for airlines to fill, because a connecting itinerary isn’t just a price. It’s a price attached to a routing, a layover airport, and a layover duration. Publishing “from $289” tells a model nothing about whether the connection is one stop or two, or whether the traveler sits in Dallas for an hour or five.
The airTRFX Connections DPA is built for exactly this: surfacing connecting itineraries with their fares, along with layover duration and connecting airport, rather than collapsing them into a single starting price. It will begin rolling out in Q3 2026 and depends on the airline sharing connection data through our fare collection.
Dimension 3: Granularity
Breadth asks how many kinds of fare a page publishes. Granularity asks how many prices it publishes for the same kind.
A single “from $299” answers one question. AI answers for flight searches routinely go further, sourcing when it’s cheapest to fly a route, what it costs in a given month, and whether some departure days are cheaper than others.
All of them need the same thing: fares published across time. Lowest fares by month and daily fares within a month turn a static number into a surface from which a model can draw specific claims.
Publishing Monthly and Day-Level Fares With the Histogram
The airTRFX histogram module shows exactly this: monthly lowest fares and day-level pricing, rendered server-side. The page gives search and AI systems the inputs needed to identify the cheapest month for the route and the lowest-priced days within it.
Putting It Together
A practical route-page audit starts with the fare data AI flight answers consistently include:
If the airline’s flight page cannot support one of these elements with accessible, relevant information, an AI assistant may turn to another source.
Conclusion
AI flight answers may appear as bullets, tables, or prose, but they consistently rely on the same core information: fares, flight time, frequency, itinerary type, and booking guidance. When airline pages lack sufficient usable pricing data, AI systems often rely on OTAs and aggregators.
Closing this gap requires more than publishing a single starting fare. Pricing must be accessible in the HTML, cover key traveler views (one-way, round-trip, cabin-specific, and connecting options), and include enough date-level granularity to support “cheapest time to travel” claims.
airTRFX addresses this programmatically. Server-rendered DPAs make fares machine-readable, fare modules expand coverage, and histograms add temporal depth. Dynamic headings and supporting text provide context, while tabbed layouts enable breadth without clutter. This significantly improves an airline’s ability to support the fare claims that appear in AI-generated flight answers.
The goal is not to tailor content for models, but to publish complete, accessible pricing data so the airline can serve as the source, rather than merely be mentioned in the answer.
Fare Coverage and AI Search: Frequently Asked Questions
The OTA may present the fare in a form that is easier to retrieve and interpret. It may also cover a pricing view missing from the airline’s page, such as a different trip type, cabin, or itinerary. As a result, an AI answer may name the airline as the carrier while citing the OTA as the source of the fare.
Full-spectrum fare coverage means publishing a broad range of relevant fare views for a route (e.g., one-way, round-trip, nonstop, connecting, cabin-specific, last-minute, etc.) instead of relying on a single starting price. It also means providing enough month- and day-level detail to answer a wider range of pricing questions from travelers and AI assistants.
Yes. Not every crawler involved in search and AI retrieval is guaranteed to execute client-side JavaScript. If a fare appears only after scripts run, systems that do not render the page may never see it. Server-side rendering places the fare in the initial HTML, making it more consistently accessible to crawlers.
airTRFX creates indexable route pages and populates them with server-rendered Dynamic Pricing airModules for pricing views, including one-way, round-trip, nonstop, cabin-specific, and last-minute fares. Histograms add month- and day-level pricing, while the Tab Widget consolidates multiple fare views within a single page section. Together with connecting-fare functionality, these capabilities help airlines improve pricing retrievability, breadth, and granularity.