Why this matters
People look up restaurants and cafés on their phone, often when they are hungry or in a hurry. If your site is slow, confusing, or hides key information, they go somewhere else.
Hospitality sites that work do three things well: menus, bookings, and mobile.
1) Menus that load and read properly
Menus are the most looked-at content on a hospitality site. Most get it wrong.
What to avoid
- Menus as huge PDFs: Slow to load, impossible to read on small screens, often inaccessible.
- Menus as image dumps: Same problems: slow, unreadable when zoomed, no structure for screen readers Source 3 .
- Menus buried in downloads: People want to see the menu now, not download it.
- Out-of-date menus: Wrong prices or items frustrate visitors and damage trust.
What to do instead
- HTML menus: Real text, fast to load, readable on any device, accessible.
- Simple structure: Sections (Starters, Mains, Drinks), items, prices. No need for fancy design.
- Allergen and dietary info: Clear, easy to find. Important for accessibility and trust.
- Keep images light if you use them: Optimise size and format. See image and video performance.
Fast, readable menus improve experience and help your site perform better in search Source 4 .
2) Booking links that work
If you take bookings, the link to book should be obvious and work on mobile.
What to include
- Clear booking call-to-action: "Book a table" or "Reserve" - same place on every page, usually in the header.
- One tap to book on mobile: Button or link that goes straight to your booking system.
- Opening times next to booking: So people know when you are open before they try to book.
- Consistent info: Same opening times and booking link on your site, Google, and socials.
What to avoid
- Burying the booking link in the footer or on a separate "Contact" page.
- Multiple competing links (e.g. "Book now", "Reserve", "OpenTable") with no clear primary action.
- Booking systems that are slow or broken on mobile.
3) Mobile-first layout
Most hospitality site traffic is mobile. Your site must work on a phone first.
What to include
- Fast load times: Menus and key info should appear quickly. Slow pages lose visitors Source 1 .
- Readable text: No tiny font sizes. Good contrast. No horizontal scrolling.
- Tap-friendly buttons: Booking, phone, map - big enough to tap easily.
- Location and map: Address, postcode, link to Google Maps or similar. Easy to find.
- Opening times: Visible without digging. Update them when they change.
What to avoid
- Heavy animations or video that slow the page and distract from the basics.
- Pop-ups that block content, especially on mobile.
- Inconsistent opening times across the site.
4) Accessibility matters
Accessible menus and clear structure help everyone: people with disabilities, people on slow connections, and people in a hurry.
- Text-based menus: Screen readers can read them. People can resize text.
- Headings and structure: Clear sections (Starters, Mains) help people navigate.
- Allergen information: Critical for some users. Make it easy to find.
- Contrast and font size: Readable for as many people as possible.
For more, see what accessibility means.
5) Keep it simple to update
Menus and opening times change. You need a way to update them without waiting for a developer.
- Simple CMS or editing workflow: So you can update the menu when items or prices change.
- One source of truth: Update in one place, and it appears everywhere (site, Google, etc.) where possible.
- No PDFs to re-upload: Edit text, not documents.
Summary
Hospitality sites that work have: HTML menus that load fast and read well, obvious booking links that work on all devices, responsive layout with fast load times, accessible structure and allergen info, and a simple way to update menus and opening times.
If you need a site that does this properly, see websites for hospitality or website build services. For performance, see fast websites: what fast means. For accessibility, see accessibility services. You can also get in touch to discuss your project.
Sources
- [1] web.dev. Web Vitals. Back to article
- [2] web.dev. Largest Contentful Paint (LCP). Back to article
- [3] W3C. Web Content Accessibility Guidelines (WCAG) 2.2. Back to article
- [4] Google Search Central. Search Console. Page Experience report. Back to article