Airport transfer SEO: how to rank for every route you actually drive

Almost every operator site I audit has a page called Airport Transfers. It mentions four or five airports in one paragraph, says something about meeting flights, and ranks nowhere. Meanwhile the sites taking the bookings have a separate page for Heathrow to Oxford, a separate page for Heathrow to Reading, a separate page for Gatwick to Brighton. Same company, same fleet, thirty pages instead of one. That is not a content-marketing trick. It is the difference between a page that answers a specific question and a page that answers none.

This article is about how to build that set of pages properly: which routes to pick, what goes on each page, how to avoid the near-duplicate trap that gets sites penalised, and how to link them so Google understands the whole cluster rather than thirty isolated pages. It sits underneath the wider structural argument I make in why your chauffeur company doesn't show up on Google, so read that one first if you have not.

Why a generic airport page cannot win

Nobody searches "airport transfers". They search "Heathrow Terminal 5 to Oxford taxi price" or "JFK to Greenwich CT car service" because they have a flight number, a destination, and usually a budget in mind. Google can only match a page to a query if the page contains the ideas in the query. A paragraph that lists five airports in passing contains none of them in the way the search actually needs — it has no drive time, no price, no terminal detail, nothing a person can act on.

A route page fixes that by being about exactly one thing. Heathrow T5 to Oxford is a different page from Heathrow T5 to Reading, even though they share 40 miles of the same motorway, because the destination, the price, and the local pickup detail at the far end are all different. Google treats these as different documents because they answer different queries, and a searcher treats them as trustworthy because the page clearly knows their specific journey rather than reciting a service area.

How to pick which routes to build first

Do not guess. Pull your last twelve months of completed jobs, group them by airport and drop-off town, and rank by frequency. In a Reading-based UK operator's job sheet I reviewed this year, four routes made up 61% of all airport work: Heathrow to Reading, Heathrow to Oxford, Gatwick to Reading, and Heathrow to Bracknell. None of those had a dedicated page. That is where you start, not with routes you wish you drove more of.

The anatomy of a route page that actually converts

A good route page reads like an answer to a phone call, not a marketing paragraph. There is a fixed structure I use across every market, UK, US, Australian or UAE, because the questions a traveller has after a nine-hour flight do not change by country.

• Terminal specificity. Name the actual terminal, not the airport. Heathrow T5 arrivals is a different walk and a different pickup point than T2 or T3, and naming it correctly signals you actually do this route.
• Honest drive time, both figures. State the free-flowing time and the bad-traffic figure separately: "75 minutes off-peak, up to 105 minutes on a Friday evening with M40 congestion." A single average number reads as guesswork.
• Fixed price by vehicle class. A table, not a range with the word "from". £185 in an E-Class, £245 in a V-Class, stated plainly.
• Waiting time and delayed-flight policy. How many minutes of free waiting on international versus domestic arrivals, and what happens if the flight is two hours late. This is the single most-asked question on the phone and the least-answered thing on websites.
• Meet and greet detail. Where exactly the driver stands, whether there is a name board, whether they track the flight.
• Luggage capacity for that specific vehicle class, loaded rather than copied from a brochure spec sheet.

Six real routes, worked through

These are illustrative structures, not live prices, since your own costs and traffic patterns will differ. The point is the level of specificity each page needs, not the exact figures.

Notice none of these mention "the world's finest chauffeur experience". They mention roads, toll systems and drop zones a local traveller would recognise. That specificity is also what AI assistants pull from when someone asks ChatGPT or Gemini for a transfer recommendation, a topic I cover in more depth in how AI assistants pick which operator to recommend.

Avoiding the near-duplicate trap

The obvious risk with 20 route pages is writing the same page 20 times with the town name swapped, which is precisely what Google's spam policies are built to catch. I have seen this happen: an operator's agency delivered 30 route pages in a week, all built from one template with £X and [destination] as the only variables, and 26 of them never indexed. The fix is not fewer pages, it is more genuine variation per page.

• Vary the traffic detail: name the specific road and the specific bottleneck for that route, not a generic "traffic can vary".
• Name a real landmark at the destination end that a local would recognise, not just the town name.
• Include a genuinely different FAQ per page — the question a Chester wedding party asks is not the question a Greenwich commuter asks.
• Vary sentence structure and paragraph order. If every page follows the identical six-sentence pattern, that pattern itself becomes a duplication signal even with different facts inserted.

Internal linking into an airport hub

Route pages work far better as a cluster than as isolated pages scattered through your site navigation. Build one hub page per airport, Heathrow Transfers or JFK Transfers, that lists every route you serve out of that airport with a one-line summary and a link. Each route page links back up to its airport hub, and sideways to the vehicle class page most used on that job. This gives Google a clear map of the cluster within days of publishing a new page, rather than leaving it to discover an orphaned page through your sitemap alone.

The commercial upside of the hub matters as much as the SEO upside. A customer landing on your Gatwick to Brighton page from a Google search is one click from your Brighton area page and your V-Class fleet page, which is how a single £95 transfer becomes a return booking plus an upgrade. I go into hub-and-spoke structure for the whole site, not just airports, in why your chauffeur company doesn't show up on Google.

Schema and FAQ blocks

Add FAQPage schema to each route page using two or three questions your office actually answers on the phone: "What happens if my flight is delayed?", "Is meet and greet included?", "Do you charge for waiting time?". This does two things at once: it can win a rich result in Google, and it gives an AI assistant a clean, quotable sentence to lift when someone asks it for a recommendation. TravelAgency or Service schema on the page, with the origin and destination named, reinforces the same specificity to search engines that the copy already gives to readers.

How many pages, in what order

1. Weeks 1–2. Pull the job sheet, rank routes by volume, pick the top 8.
2. Weeks 2–5. Write one route page every one to two days. Keep the terminal, price table, waiting policy and FAQ consistent in structure but genuinely different in content.
3. Week 6. Build the airport hub pages and link every route page in and back out.
4. Weeks 7–10. Add the next 10–15 routes from the job sheet, lower-frequency but still real.
5. Ongoing. Revisit prices quarterly. A route page with a stale 2024 price is worse for trust than no price at all.

For operators wondering whether to hand this whole process to an agency or run it with a tool, I have laid out the actual cost and time trade-off in agency retainer versus AI content tool, and a full worked example of a fleet that ran this exact route-page build in the 90-day autopilot case study.

Measuring it in Search Console

Do not judge a route page on bookings in the first month. Watch impressions and average position for the specific route query first. In the accounts I track, a new route page typically starts showing impressions for its target phrase within three to five weeks, and moves from position 40-plus to somewhere in the top 15 by week eight or nine if the page is genuinely specific. Clicks lag position, and enquiries lag clicks by another few weeks because airport transfers are often booked days or weeks ahead of the flight, not on the day someone first searches.

Segment your Performance report by page rather than only by query, filter to the /transfers/ or /routes/ folder, and check month over month whether the number of routes generating any impressions at all is growing. That coverage metric tells you whether the cluster is working before revenue does.

The honest limit of this strategy

Route pages will not take the single biggest head terms away from Google Flights-adjacent aggregators, price-comparison marketplaces, or the big national booking platforms with tens of thousands of automatically generated route pages. "Heathrow to central London taxi" is going to have an aggregator and two national brands above you indefinitely, and that is fine. The routes worth building are the ones specific enough that an aggregator's templated page cannot compete on local detail: named hotels, named colleges, named toll roads, your actual fixed price. That is a smaller pool of searches than the aggregators own, but it is the pool that converts into bookings for a company your size, and it is one nobody automatically generated their way into.