Building a Restaurant Website? Please Don't Ship the Menu as a PDF

#wordpress #webdev #seo #freelancing

Ask anyone how they choose a new restaurant or café and the answer is almost always the same three steps on a phone: look at the food, check the menu, find out how to get there. A restaurant website has one job, and that's making those three steps fast.

I'm a freelance WordPress and Flutter developer in Famagusta, North Cyprus. Small local businesses are a big part of what I think about, and restaurant sites are where the same few technical decisions matter most. Here is how I'd build one, from a developer's point of view.

The menu is a web page, not a file

The most common mistake is uploading the menu as a PDF or a photo of the printed card. On a phone, a PDF has to be downloaded, pinch-zoomed and scrolled sideways. Search engines also get very little from it, so a search like "breakfast in Famagusta" has nothing to match.

In WordPress I build the menu as real content: a custom post type or a simple repeater with sections, dish names, short descriptions and dietary tags (vegan, gluten-free, spicy). Then:

The owner edits a dish from the dashboard in a minute, without asking a developer.
The page is plain HTML, readable on any screen and fully indexable.
If they still want a printable version, a "Download PDF" link sits under the web menu, not instead of it.

Tell search engines it's a restaurant

Local search is where restaurants live: "restaurant near me", "best coffee in Famagusta". Structured data helps Google connect the website with the place. A minimal Restaurant block looks like this:

{
  "@context": "https://schema.org",
  "@type": "Restaurant",
  "name": "Example Café",
  "servesCuisine": ["Mediterranean", "Breakfast"],
  "address": {
    "@type": "PostalAddress",
    "addressLocality": "Famagusta",
    "addressCountry": "CY"
  },
  "telephone": "+90 000 000 0000",
  "openingHours": ["Mo-Sa 08:00-22:00"],
  "hasMenu": "https://example.com/menu/",
  "acceptsReservations": "True"
}

Then the part developers often skip: the name, address, phone number and opening hours must be exactly the same on the website, the Google Business Profile and the social pages. Mismatched data makes Google trust all of it less, and it sends guests to a closed door.

Photos sell, and photos make it slow

Food photos do more selling than any copy, and they're also the number one reason restaurant sites are slow. My routine:

Resize to the size actually displayed, compress, serve WebP with srcset.
loading="lazy" on everything below the fold, but not on the hero image, because lazy-loading the largest image hurts LCP.
Set width and height so the layout doesn't jump while photos load.

On a four-language real estate site I work on, a colleague and I raised the median mobile PageSpeed score from 51 to 75 and desktop from 81 to 97 without changing the design. Most of that came from exactly this kind of image and asset discipline.

One obvious next step

Every page should make the next action a single tap:

tel: link for calling,
a https://wa.me/ link with a pre-filled message, which in North Cyprus is often how people actually book,
a short reservation form, or a link to the delivery platform the place already uses.

Online ordering with WooCommerce is possible, but I usually start with the simple version and add ordering only when the owner really needs it.

Languages: real pages, not a translate button

A restaurant in North Cyprus serves locals, visitors from Turkey, tourists from Europe and the UK, and a lot of international students. With WPML, each language gets its own URLs and hreflang tags, so Google can show the Turkish menu to Turkish searches. An automatic "translate" widget doesn't do that.

What I leave out

Autoplay music, a long intro video, a newsletter pop-up in the first second, a slider with eight slides. Each one makes the site slower and pushes the menu further down. A small, fast site with a clear menu wins.

When an app makes sense

Once a place has regular customers, a Flutter app can do what a website can't: a loyalty card on the phone, push notifications for a weekend event, fast reordering. The nice part is that the app can read the menu from the same WordPress site through the REST API, so the owner updates one place and both stay in sync. For most restaurants, though, the website and the Google profile come first.

I wrote a longer, client-facing version of this for restaurant and café owners here: Restaurant & Café Website Design in North Cyprus.

What's the worst restaurant-website pattern you keep running into?

DEV Community