Programmatic Web Development for Hospitality, Food & Drink — The Practitioner’s Playbook.

SectionThe honest reframe most agencies won't tell you

Most agencies build a hospitality site like it's 2014. A pretty homepage, an About page, a Gallery, a Contact form, a 4 MB Menu PDF, and an OpenTable button bolted into the header. Then they wonder why the bookings still flow through Tripadvisor and Booking.com — and why the operator is paying £1 per cover plus 15% on hotel rooms forever.

Hospitality, food and drink is a structurally different build. The operator selling sourdough pizza in Poole is competing on dish-level intent, allergen disclosure, FSA hygiene rating display, and a booking widget that doesn't crater mobile Core Web Vitals. The hotelier in Bournemouth is competing on per-room indexability, ADR-aware booking flow, and a direct-channel that recoups Booking.com's 15% commission. None of that is a "redesign" problem. It is a structural problem the brochure-style build cannot solve.

This playbook fixes the structure. It is not about a redesign — it is about HTML menu indexability, per-dish and per-room programmatic pages, booking-platform integration that respects ADR and cover economics, FSA and allergen schema that do legal and conversion work at the same time, and a build pipeline that lets an operator sleep through a Saturday-night service. Read it, run it yourself, or hand the build over on retainer.

SectionThe eight-point audit we run on day one

Score your own site red / amber / green this week.

1. HTML menu indexability with Menu / MenuItem schema (no PDF-only) — The menu lives as indexable HTML on the site, with Menu, MenuSection and MenuItem JSON-LD on every dish, plus prices and allergen flags. PDF-only menus are functionally invisible to Google's dish-level intent matching, kill mobile Core Web Vitals on the menu tap, and lose every "sourdough pizza Poole" or "Sunday roast Christchurch" long-tail query you could have owned.
2. Per-dish or per-room pages where buyer search-intent justifies them — A separate, indexable page for the venue's signature dishes (the beef shin ragu, the sea bass with brown shrimp butter) and for each room category (sea-view double, family suite, dog-friendly twin, accessible ground-floor). One /menu/ page or one /rooms/ page is the single biggest indexability undershoot in the sector.
3. Hotel availability + ADR-aware booking flow integration — Live availability and rate display on the per-room page, with the direct-booking widget priced at or below Booking.com's parity rate so the buyer sees a reason to book direct. The ADR / RevPAR economics of the property dictate the build, not the other way around.
4. OpenTable / ResDiary / Booking.com deep-link or API integration — Deep links from each dish, room and event page to the right booking platform with proper UTM tagging, plus the API integration where the platform supports it, so the booking happens in two taps and the conversion is properly attributed back to the originating page.
5. FSA hygiene rating displayed prominently — Current rating from food.gov.uk surfaced in a visible footer or trust strip, with FoodEstablishment schema referencing the rating. A 5 displayed builds direct-booking conversion; a rating hidden invites a "[venue] hygiene rating" branded search that surfaces food.gov.uk above your homepage.
6. Allergen disclosure schema — Allergen markup on every menu item using the 14 statutory allergens under Natasha's Law. Visible on-page, structured in JSON-LD, and propagated to the booking widget where the platform supports a dietary-requirements field. Legal floor and conversion lever in one move.
7. Mobile Core Web Vitals under 2.5s on the menu / booking page — LCP under 2.5s, INP under 200ms, CLS under 0.1 specifically on the menu page and the booking flow on a 4G mobile connection. Most hospitality sites pass on the homepage and fail on the two pages that actually take the booking.
8. Per-location LocalBusiness + Restaurant / Hotel schema — LocalBusiness plus the right sub-type (Restaurant, BarOrPub, CafeOrCoffeeShop, Hotel, BedAndBreakfast) on every location page, with NAP, opening hours, accepted payment, accepted cuisine, star rating and price range. One schema block per venue, validated in CI, never out of sync with the GBP listing.

Three or more reds — fix the foundation.

SectionSix productised deliverables we ship per cycle

HTML menu architecture with Menu schema. The PDF gets retired. We rebuild the menu as indexable HTML with Menu, MenuSection and MenuItem JSON-LD on every dish, allergen flags from the 14-allergen list, prices, dietary tags (vegan, vegetarian, gluten-free, dairy-free) and dish-level photography where it earns its keep. Each section is internally linked from the homepage and the booking page, and the build pipeline runs schema validation on every deploy so a typo never silently kills the structured data. Time to first signal: 30 days. Owned by you, exportable as Notion + PDF.

Per-dish or per-room programmatic pages. One indexable page per signature dish and per room category, generated from a single template fed by a structured content model. For restaurants and gastropubs that means twelve to thirty signature-dish spokes hung off the cuisine pillars (sourdough pizza, Sunday roast, small plates, plant-based). For hotels and B&Bs that means one page per room category — sea-view double, family suite, dog-friendly twin, accessible ground-floor — with Accommodation / HotelRoom schema, occupancy, bed type, view, amenities, gallery and a direct deep link. Programmatic is the engine; one template ships dozens of indexable pages.

Booking-platform deep-link integration. Every dish, room and event page deep-links to the right platform — OpenTable, ResDiary, SevenRooms for restaurants; Booking.com, SiteMinder, Cloudbeds, Mews or the direct widget for hotels — with UTM tagging that attributes the conversion back to the originating page. Where the platform supports an API (OpenTable's, Cloudbeds', SiteMinder's), we go API-first so live availability and rates render on the page and the booking happens in two taps without a redirect-shuffle.

Allergen + FSA trust strip. Footer or sticky trust strip showing current FSA hygiene rating (live-pulled from food.gov.uk where the API allows, otherwise a quarterly-checked static badge), the 14-allergen disclosure block, plus any sector accreditation in scope (AA Rosette, Michelin Bib Gourmand, Cask Marque, Cicerone, SRA Food Made Good, Sustainable Restaurant Association). FoodEstablishment schema referencing the rating. Lifts on-site conversion at the booking moment and prevents food.gov.uk out-ranking the homepage on branded "[venue] hygiene rating" search.

Per-location schema + GBP integration. LocalBusiness plus the right sub-type (Restaurant, BarOrPub, CafeOrCoffeeShop, Hotel, BedAndBreakfast) on every location page, with NAP, opening hours, accepted payment, accepted cuisine, star rating and price range. The schema is the source of truth and the GBP listing is reconciled to match — opening hours, special hours for bank holidays and Christmas, attributes (outdoor seating, dog-friendly, free Wi-Fi, accepts reservations) all kept in sync via a quarterly audit.

Mobile CWV + menu-page tuning. LCP under 2.5s on the menu page and the booking flow. INP under 200ms on the form-fill or date-picker journey. CLS under 0.1. WebP / AVIF image optimisation, lazy-loading, third-party-script audit on the booking widget (the OpenTable script alone routinely costs 800 ms on a cold-cache mobile load), Lighthouse CI in your build pipeline so future deploys can't regress these without you noticing. Time to first signal: 21 days. Most operators see direct-booking conversion lift 15–25% on the rebuilt menu page alone.

SectionWhat to do this week

Three actions, ranked by leverage. Same first three steps we ship in week one of a Foundation retainer for a hospitality operator.

1. Open your menu page on a mobile, on 4G. Owner: founder or marketing manager. Time: 5 minutes. If it downloads or opens a PDF, you're invisible to Google's dish-level intent matching. If it's HTML but takes more than 2.5 seconds to render the first dish, you're losing direct bookings before the buyer ever sees the price. Run mobile Lighthouse on the same page and write the LCP / INP / CLS down.
2. Count your indexable per-dish or per-room pages. Owner: founder. Time: 10 minutes. Open your site map. Count separate, indexable, schema-marked pages per signature dish (restaurants) or per room category (hotels). If it's one combined page, you're undershooting indexability by an order of magnitude and paying for it in OpenTable cover fees and Booking.com commission.
3. Decide DIY, DWY or DFY for the next 90 days. Owner: founder. See the three ways.

SectionFive questions restaurant / hotel / pub operators ask us about web development

Should we be on WordPress or one of the all-in-one hospitality platforms like Toast, Square for Restaurants or Cloudbeds? Different jobs. The all-in-one POS / PMS platforms (Toast, Square for Restaurants, Lightspeed, Cloudbeds, Mews, Little Hotelier) are excellent at running the venue — orders, payments, table management, channel manager, room inventory. They are weak as a public-facing website because their CMS is constrained, the schema deployment is shallow, and you can't run programmatic page generation. The right pattern for almost every independent: WordPress on a managed host (Kinsta, WP Engine, Pressable) with Cloudflare in front, and a deep deep-link or API integration into Toast / Square / Cloudbeds for the booking and ordering flow. You get the marketing surface where you can ship per-dish and per-room pages, and the operations stack where it belongs.

Will moving the menu from PDF to HTML actually move the needle, or is this an SEO talking point? It moves the needle. Most independents publishing a PDF menu have zero dish-level Google rankings — Google's parser cannot reliably extract dish text, prices and allergen flags from a typical 4 MB PDF, and even when it can, the ranking signal is weak. Operators we have shipped HTML menu rebuilds for typically see twenty to fifty new dish-level rankings within ninety days, plus 15–25% direct-booking conversion lift on the menu page itself purely from the mobile speed gain. The PDF was costing money on three axes — invisibility to long-tail search, mobile speed penalty, and the cover-fee leakage to OpenTable that the direct booking would have prevented.

OpenTable charges roughly £1 per cover. Is the integration worth building properly or should we go direct-only? Run the math venue-by-venue. £1 per cover on a £35 average spend is sub-3% take, lower than card processing — so OpenTable as a discovery channel is rarely the wrong call, especially for a new venue building review velocity. The structural error is sending all booking traffic through OpenTable, including the returning guest who already knows you and is searching your brand name. Build the per-dish pages, ship the direct widget, deep-link OpenTable on the discovery surface and your direct widget on the brand and dish pages, and you keep OpenTable as the discovery layer while reclaiming the repeat-direct booking. Most operators recoup the build cost within 90 days through the direct-booking shift alone.

For hotels, what's the realistic direct-booking lift from a proper rebuild? A hotel paying Booking.com a 15% commission on a £150 ADR is paying £22.50 per night per booked room. A property doing 60% occupancy on 30 rooms loses roughly £148,000 a year to Booking.com commission alone. A proper rebuild — per-room programmatic pages, ADR-aware direct-booking widget priced at parity, LocalBusiness + Hotel schema, mobile CWV under 2.5s, FSA / sector-accreditation trust strip — typically lifts the direct-booking share from 15–20% to 30–40% over twelve months. On the same property that is £45,000–£75,000 a year recovered, against a one-off rebuild cost in the £8,000–£20,000 range. The math is rarely close.

Can we run this ourselves with the playbook + £750 audit? Yes for restaurants, gastropubs, cafes and small B&Bs with a competent in-house marketing manager and one developer half-week per cycle. Hotels with a PMS and channel manager (Cloudbeds, Mews, SiteMinder) usually need DWY support for the per-room schema, the rate-parity logic on the direct widget, and the API integration into the PMS — not because the playbook is unclear, but because the integration touches operational systems where a mistake costs real bookings. The £750 audit gives you a written red/amber/green of all eight points, named-owner / dated next steps, the per-dish or per-room template, and a schema validation pack you can run in CI. Credit toward first cycle if you sign for DWY/DFY within 30 days.

SectionWhere to go from here

If you want this shipped end-to-end on a productised retainer, book a 30-minute discovery call.

If you'd rather have a senior practitioner reviewing your team's work each week — menu pages, per-room pages, schema deploys, Lighthouse scores, booking-widget conversion — the coaching plans start at £750/month. If you have a hard deadline (a menu rebrand, a pre-summer-season launch on the coast, a Christmas-party page sprint, a hotel re-launch), the two-week embedded sprint lands a senior practitioner inside your stack for ten working days at £3,000 fixed.

Or run it yourself. Eight-point audit + one deliverable a month + twice-quarterly office hours.