How Regional Airports Can Fix Agent-Driven Flight Search
A regional airport website serves two purposes: providing flight information and directing passengers to airline booking pages. That second function depends on flight search working properly, and for AI agents it often does not work at all.
The Typical Starting Point
A common airport flight search page has three inputs: departure date, return date, and destination. The destination field is a custom dropdown with country flags and grouped destinations (Beach, City Break, Ski). The date fields use a custom JavaScript datepicker that renders a calendar overlay. None of these are native HTML form elements.
The datepicker is usually the primary problem. It is a div-based calendar grid with no semantic markup. Each date cell is a span with a click handler. Dates in the past are greyed out via CSS class. Available dates (those with scheduled flights) have a different background colour. There are no text indicators, ARIA attributes, or button roles.
The destination dropdown is similarly opaque. It renders as a styled div containing nested divs for each category and destination. The selected destination is stored in a JavaScript variable, not in a form field that would appear in the DOM. An agent interacting with the page cannot determine which destinations are available, much less select one.
Route information is often scattered across the site. Each destination has its own page with seasonal schedule information, but these pages are not linked in any structured way. There is no single data source an agent can query to answer "What flights go to Malaga in July?" Audit a site like this and the result is consistent: agents cannot complete a flight search.
What to Change
Focus on three deliverables.
Structured route and schedule data. Create a dedicated /routes page listing every active route with its destination, operating airline, frequency (e.g., "3 flights per week"), operating period (e.g., "May to October"), and a link to the airline's booking page for that route. Mark up each route with Schema.org FlightReservation-adjacent properties including the departure airport (IATA code, name, geo-coordinates), arrival airport, and operating carrier. This single page gives agents everything they need to answer route and schedule queries.
Native form controls. Replace the destination dropdown with a native select element, grouped by region using optgroup. Replace the datepicker with native date inputs for departure and return dates. A hidden datalist can suggest dates with available flights, serving as a helpful hint rather than a constraint. Update the visual design to match the airport's brand standards using CSS, keeping the look polished while maintaining standard form behaviour.
Search results as structured HTML. When a search is submitted, show matching flights in a table with proper th and td elements: route, airline, departure time, days of operation, and a "Book on [airline name]" link. Mark up each row with structured data, and put the search criteria in the results page URL as query parameters, so agents can construct search URLs directly.
What Improves
Once the route data lives on a single structured page, agents can answer the most common queries (which destinations are served, what flies where and when) directly, and click through to the right airline booking page. Native form controls remove the datepicker and dropdown as blockers, so agents that do use the search form can complete it.
In practice, agents often prefer the structured route list to the search form, because it answers "What destinations can I fly to from this airport?" in a single page load. There is a useful side effect too: well-structured route data tends to improve visibility in general search results, so route pages can start surfacing for queries like "flights from this airport to Malaga," bringing human traffic alongside agent traffic.
Lessons for Regional Airports
Regional airports are in an interesting position for agent compatibility. They are not booking platforms themselves; they are information hubs that route passengers to airlines. This means their job is simpler in some ways: they do not need to handle payment or complex booking flows. They just need to present route and schedule data clearly enough for agents to work with.
The custom datepicker and dropdown pattern is almost universal on airport websites. Nearly every airport site uses some variant of this, and it breaks agent interaction every time. Native form controls fix the problem with minimal visual compromise.
The biggest win, though, is the structured route data page. Agents do not want to use a flight search form the way a human does. They want a data source they can query efficiently. A well-structured routes page serves as an informal API that costs almost nothing to build and maintain. If you run an airport website, check your site's agent compatibility and prioritise getting your route data into structured, machine-readable HTML.