Stop je restaurantmenu in een PDF: wat je in plaats daarvan moet doen
Ik heb ontelbaar veel restauranteigenaren gesproken die trots zeggen: "Ons menu staat al online!" En dan linken ze me naar een 4MB PDF die acht seconden nodig heeft om op mobiel in te laden, niet door Google gelezen kan worden, en eruit ziet alsof het op een kopieermachine uit 2003 is gescand.
Kijk, ik begrijp het. Je hebt goed geld uitgegeven aan dat mooi ontworpen printmenu. Het PDF uploaden voelt als de makkelijke oplossing. Maar het schaadt je bedrijf actief. Elke dag verlaten potentiële klanten je website omdat ze niet kunnen inzoomen op hun telefoon door je voorgerechten sectie. Google kan je gerechten niet goed indexeren. En wanneer je een prijs moet aanpassen of een seizoensgebonden item moet verwijderen? Je zit weer in InDesign, opnieuw exporteren, opnieuw uploaden, en hopen dat je de link niet hebt verbroken.
Er is een beter manier. En het is niet eens zo moeilijk.

Inhoudsopgave
- Waarom PDF-menu's verschrikkelijk zijn voor restaurants
- De werkelijke kosten van PDF-menu's: Op basis van cijfers
- Hoe een op database gebaseerd digitaal menu er werkelijk uitziet
- Het kiezen van je tech stack voor een digitaal menu
- Het opbouwen van het menu databaseschema
- Headless CMS: De perfecte oplossing voor restaurantmenu's
- SEO-voordelen van HTML-menu's ten opzichte van PDF's
- Gestructureerde gegevens en schema-opmaak voor restaurantmenu's
- Toegankelijkheid: Waarom PDF-menu's WCAG-standaarden niet halen
- Ontwerppatronen die werkelijk werken
- Voorbeeld van implementatie in de praktijk
- Veelgestelde vragen
Waarom PDF-menu's verschrikkelijk zijn voor restaurants
Ik zal er niet omheen draaien. PDF-menu's zijn een overblijfsel uit een tijd waarin "een website hebben" betekende dat je een paar statische pagina's online zette en het daarbij liet. Dit is wat er werkelijk mis mee is:
Ze zijn niet mobiel-vriendelijk
Vanaf begin 2025 vindt ongeveer 77% van restaurantzoekopdrachten plaats op mobiele apparaten volgens Google's eigen gegevens. Een PDF op een telefoon is een nachtmerrie. Gebruikers moeten knijpen, inzoomen, schuiven en turen. De tekst is niet responsief. De indeling past zich niet aan. En de meeste mensen verlaten gewoon... de site.
Google's eigen onderzoek toont aan dat 53% van mobiele gebruikers sites verlaat die langer dan 3 seconden nodig hebben om in te laden. Je 3MB PDF-menu? Dit haalt niet eens in de buurt van die limiet op een slechte mobiele verbinding.
Google kan het niet goed indexeren
Ja, technisch gezien kan Google PDF-inhoud crawlen. Maar het behandelt het niet hetzelfde als HTML. PDF-tekst wordt vaak foutief geparseerd, vooral als de PDF uit een ontwerptool is geëxporteerd met tekst weergegeven als contouren of ingebed in afbeeldingen. Zelfs wanneer de tekst te parseren is, zal Google individuele menu-items niet op dezelfde manier in zoekresultaten weergeven als het zou doen met goed gestructureerde HTML-inhoud.
Wanneer iemand zoekt naar "beste bisque bij mij in de buurt", heeft je HTML-menupagina met gestructureerde gegevens een reële kans om te verschijnen. Je PDF? Geen schijn van kans.
Het is lastig om bij te werken
Seizoensgebonden ingrediënten raken op. Prijzen veranderen. Nieuwe gerechten worden toegevoegd. Met een PDF-workflow betekent elke verandering:
- Het bronontwerp openen (hopelijk heb je het nog)
- De bewerking maken
- Een nieuw PDF exporteren
- Uploaden naar je hosting
- Zorg ervoor dat de URL niet veranderd is
- Elke CDN-cache leegmaken
Met een op database gebaseerd menu veranderen je een getal in een veld en druk je op opslaan. Klaar.
De werkelijke kosten van PDF-menu's: Op basis van cijfers
Laten we hier wat werkelijke gegevens achter zetten.
| Metric | PDF-menu | HTML Database Menu |
|---|---|---|
| Gemiddelde laadtijd (mobiel, 4G) | 4-8 seconden | 0,5-1,5 seconden |
| Google-indexeerbaarheid | Gedeeltelijk, onbetrouwbaar | Volledig, met gestructureerde gegevens |
| Mobiele bruikbaarheidsscore | Slaagt niet voor Core Web Vitals | Slaagt voor Core Web Vitals |
| Tijd om een prijs bij te werken | 15-30 minuten | 30 seconden |
| Toegankelijkheid (WCAG 2.1 AA) | Bijna altijd niet geschikt | Haalbaar met juiste opmaak |
| Bounce rate-impact | 40-60% hoger op mobiel | Baseline |
| Schema.org-ondersteuning | Geen | Volledig Menu/MenuItem-opmaak |
| Meertalige ondersteuning | Aparte PDF's nodig | Dynamisch, dezelfde URL |
Dit zijn geen verzonnnen getallen. De laadtijdgegevens komen uit echte prestatieaudits die we op restaurantsites hebben uitgevoerd. Het bounce rate-cijfer sluit aan bij onderzoeken van zowel Google als Akamai over de impact van laadtijd op mobiel.

Hoe een op database gebaseerd digitaal menu er werkelijk uitziet
In plaats van een plat bestand (de PDF) sla je je menugegevens op in een gestructureerde database. Elk gerecht wordt een record met velden zoals naam, beschrijving, prijs, categorie, diëtetische labels, afbeeldings-URL en beschikbaarheidsstatus.
De front-end geeft deze gegevens weer als mooi, responsief HTML. Het resultaat ziet eruit als een ontworpen menu -- maar het is eigenlijk livegegevens die kunnen worden gezocht, gefilterd, geïndexeerd door Google, gelezen door schermlezers en in seconden kunnen worden bijgewerkt.
Hier is het mentale model:
[Content Management] → [API/Database] → [Front-End Rendering] → [User's Browser]
(staff edits) (structured data) (HTML/CSS/JS) (fast, accessible)
Dit is hetzelfde patroon achter elke moderne webapplicatie. Het wordt zojuist toegepast op je menu.
Het kiezen van je tech stack voor een digitaal menu
Je hebt opties. Laat me door de belangrijkste benaderingen lopen.
Optie 1: Statische sitegenerator + Headless CMS
Dit is mijn aanbeveling voor de meeste restaurants. Gebruik een framework zoals Astro of Next.js voor de front-end, gecombineerd met een headless CMS voor contentbeheer.
Voordelen: Bliksemssnel (statische HTML), geweldige SEO, goedkope hosting, makkelijk voor niet-technisch personeel om bij te werken. Nadelen: Vereist initiële ontwikkelingsinvestering.
Optie 2: WordPress met een Menu-plugin
Plugins voor restaurantmenu's bestaan. Ze zijn oké voor eenvoudige setups.
Voordelen: Lage drempel als je al op WordPress zit. Nadelen: Plugin-kwaliteit varieert sterk, prestatieoverhead van WordPress, beveiligingsonderhoudslast.
Optie 3: Platforms van derden voor menu's
Services zoals Popmenu, BentoBox of Toast integreren menu-widgets op je site.
Voordelen: Snel ingesteld, sommige hebben bestelmogelijkheden. Nadelen: Je bezit de gegevens niet, SEO-waarde gaat naar hun domein (iframes!), maandelijkse kosten van €100-€500+, beperkte ontwerpcontrole.
Optie 4: Custom build met een Headless CMS
Voor restaurantgroepen of high-end etablissementen geeft een volledig custom headless CMS-setup je totale controle over gegevensmodellering, ontwerp en beheer op meerdere locaties.
| Aanpak | Inrichtingskosten | Maandelijkse kosten | SEO-controle | Update-gemak | Ontwerpvrijheid |
|---|---|---|---|---|---|
| Statisch + Headless CMS | €3.000-€10.000 | €0-€50 | Volledig | Uitstekend | Volledig |
| WordPress + Plugin | €500-€3.000 | €20-€100 | Goed | Goed | Matig |
| Platform van derden | €0-€1.000 | €100-€500 | Slecht (iframes) | Uitstekend | Beperkt |
| Custom Headless Build | €8.000-€25.000 | €0-€100 | Volledig | Uitstekend | Volledig |
Het opbouwen van het menu databaseschema
Laten we praktisch worden. Dit is wat een solide menu databaseschema eruit ziet:
// Menu Category
interface MenuCategory {
id: string;
name: string; // "Appetizers", "Entrées", "Desserts"
slug: string; // "appetizers"
description?: string;
sortOrder: number;
image?: string;
isActive: boolean;
}
// Menu Item
interface MenuItem {
id: string;
categoryId: string;
name: string; // "Pan-Seared Diver Scallops"
slug: string; // "pan-seared-diver-scallops"
description: string; // "With cauliflower purée, brown butter, capers"
price: number; // 3400 (cents, always store money as integers)
priceLabel?: string; // "Market Price" for variable pricing
dietaryTags: string[]; // ["gluten-free", "dairy-free"]
allergens: string[]; // ["shellfish"]
spiceLevel?: number; // 0-3
isAvailable: boolean;
isNew: boolean;
isFeatured: boolean;
image?: string;
sortOrder: number;
calories?: number;
variants?: MenuItemVariant[];
}
// For items with size options
interface MenuItemVariant {
label: string; // "Small", "Large"
price: number;
}
Twee dingen om op te merken. Sla prijzen op in centen (of de kleinste eenheid van je valuta). Drijvende-kommaberekening en geld gaan niet goed samen -- dit is een les die je maar één keer hoeft te leren. En maak isAvailable een eersteklas veld. Wanneer je een gerecht tijdens de service niet hebt (86), moet iemand dit direct kunnen uitschakelen.
Headless CMS: De perfecte oplossing voor restaurantmenu's
Een headless CMS laat je keukenmedewerkers (of wie ook het menu beheert) items bijwerken via een vriendelijke beheerdersinterface, terwijl je ontwikkelaars volledige controle hebben over hoe de front-end wordt weergegeven.
Populaire opties in 2025:
- Sanity -- Uitstekend voor aangepaste schema's, real-time samenwerking, genereuze gratis laag (tot 100K API-aanvragen/maand)
- Contentful -- Meer op ondernemingen gericht, €300/maand voor het Team-plan
- Strapi -- Open source, zelf gehost, geen kosten per plaats
- Payload CMS -- Gebouwd op Node.js, zelf gehost, geweldige TypeScript-ondersteuning
- Hygraph -- GraphQL-native, goed voor complexe menu-relaties
Dit is wat een Sanity-schema voor een menu-item eruit kan zien:
// sanity/schemas/menuItem.js
export default {
name: 'menuItem',
title: 'Menu Item',
type: 'document',
fields: [
{
name: 'name',
title: 'Dish Name',
type: 'string',
validation: Rule => Rule.required()
},
{
name: 'slug',
title: 'Slug',
type: 'slug',
options: { source: 'name' }
},
{
name: 'description',
title: 'Description',
type: 'text',
rows: 3
},
{
name: 'price',
title: 'Price (in cents)',
type: 'number',
validation: Rule => Rule.min(0)
},
{
name: 'category',
title: 'Category',
type: 'reference',
to: [{ type: 'menuCategory' }]
},
{
name: 'dietaryTags',
title: 'Dietary Tags',
type: 'array',
of: [{ type: 'string' }],
options: {
list: [
{ title: 'Vegetarian', value: 'vegetarian' },
{ title: 'Vegan', value: 'vegan' },
{ title: 'Gluten-Free', value: 'gluten-free' },
{ title: 'Dairy-Free', value: 'dairy-free' },
{ title: 'Nut-Free', value: 'nut-free' }
]
}
},
{
name: 'isAvailable',
title: 'Currently Available',
type: 'boolean',
initialValue: true
},
{
name: 'image',
title: 'Photo',
type: 'image',
options: { hotspot: true }
}
]
}
Niet-technisch personeel kan dit beheren. Het is gewoon een formulier. Geen InDesign, geen PDF-exports, geen FTP-uploads. We bouwen dit soort setups regelmatig -- bekijk onze headless CMS-ontwikkelingsmogelijkheden als je wilt zien hoe we dit benaderen.
SEO-voordelen van HTML-menu's ten opzichte van PDF's
Dit is waar het werkelijk interessant wordt voor restauranteigenaren die ervoor zorgen dat ze online worden gevonden.
Afzonderlijke pagina's voor gerechten
Met een op database gebaseerd menu kunt je optioneel afzonderlijke pagina's voor handtekeninggerechten maken. Een pagina op /menu/pan-seared-diver-scallops kan rangeren voor "scallops restaurant [jouw stad]" en vergelijkbare long-tail-zoekopdrachten. Probeer dat maar eens met een PDF.
Lokale SEO-signalen
Google's lokale algoritme besteedt aandacht aan inhoudsrelevantie. Wanneer je menu HTML-tekst op je site is, begrijpt Google welke cuisine je serveert en welke gerechten. Dit voert direct in op je Google Business Profile-relevantie voor zoekopdrachten zoals "Italiaans restaurant dicht bij mij" of "waar krijg ik ramen in Amsterdam".
Paginasnelheid
Core Web Vitals zijn een rankingfactor. Een statische HTML-menupagina gebouwd met Astro of Next.js kan een score van 95+ behalen op PageSpeed Insights. Een pagina die een PDF-download activeert? Google meet zelfs geen Core Web Vitals voor bestanddownloads -- het ziet gewoon een slechter gebruikerservarcingssignaal.
Gestructureerde gegevens en schema-opmaak voor restaurantmenu's
Dit is het geheime wapen dat de meeste restaurants volledig negeren. Schema.org heeft specifieke woordenschat voor restaurants en menu's. Dit is wat juiste opmaak eruit ziet:
{
"@context": "https://schema.org",
"@type": "Restaurant",
"name": "The Example Kitchen",
"address": {
"@type": "PostalAddress",
"streetAddress": "123 Main St",
"addressLocality": "Amsterdam",
"addressRegion": "NH"
},
"hasMenu": {
"@type": "Menu",
"hasMenuSection": [
{
"@type": "MenuSection",
"name": "Appetizers",
"hasMenuItem": [
{
"@type": "MenuItem",
"name": "Pan-Seared Diver Scallops",
"description": "With cauliflower purée, brown butter, and capers",
"offers": {
"@type": "Offer",
"price": "34.00",
"priceCurrency": "EUR"
},
"suitableForDiet": "https://schema.org/GlutenFreeDiet"
}
]
}
]
}
}
Deze gestructureerde gegevens helpen Google je menu-items, prijzen en diëtetische voorzieningen te begrijpen. Het kan verschijnen in uitgebreide resultaten, kennisvensters en Google Maps-aanbiedingen. Je kunt dit letterlijk niet doen met een PDF.
Toegankelijkheid: Waarom PDF-menu's WCAG-standaarden niet halen
Toegankelijkheid is niet optioneel. Naast dat het het juiste is om te doen, is de ADA van toepassing op restaurantwebsites, en PDF-toegankelijkheidszaken zijn sinds 2023 toegenomen.
De meeste restaurantPDF's zijn op deze manieren niet toegankelijk:
- Geen leesvolgordering gedefinieerd -- schermlezers kunnen de indeling niet parseren
- Tekst weergegeven als afbeeldingen -- gebruikelijk in ontworpen menu's, volledig onzichtbaar voor ondersteuningstechnologie
- Geen alt-tekst op decoratieve elementen
- Geen koppen-structuur -- geen manier om tussen secties te navigeren
- Vaste lettertypegroottes -- gebruikers kunnen tekst niet vergroten
Een HTML-menupagina behandelt dit alles natuurlijk wanneer deze is gebouwd met semantische opmaak. Koppen, lijsten, juiste ARIA-labels, responsieve tekstgrootte -- het is allemaal gewoon standaard webontwikkeling.
Ontwerppatronen die werkelijk werken
Ik weet wat je denkt: "Maar mijn PDF-menu ziet er mooi uit en een HTML-pagina ziet er generiek uit." Nope. Met modern CSS kun je een webmenu geweldig laten uitzien.
Ingedeelde indeling met vaste navigatie
Een tabblad- of vaste-nav-indeling laat gebruikers tussen Voorgerechten, Hoofdgerechten, Desserts en Dranken springen zonder door alles heen te schuiven. Dit patroon alleen verbetert de bruikbaarheid al dramatisch.
Diëtetische filtertoggles
Voeg filterknopen toe voor Vegetarisch, Veganistisch, Glutenvrij, enz. Bij activering vervagen niet-overeenkomende items of verbergen zich. Dit is onmogelijk in een PDF en het is een van de meest gewenste functies door diners.
Prijsopmaak
Zet niet zomaar "$34,00" naast een gerechtnaam. Gebruik juiste typografie -- punt-lijnen, rechtsgejustificeerde prijzen, duidelijke visuele hiërarchie. CSS Grid maakt dit triviaal:
.menu-item {
display: grid;
grid-template-columns: 1fr auto;
gap: 0.5rem;
align-items: baseline;
}
.menu-item__name {
font-weight: 600;
border-bottom: 1px dotted #999;
}
.menu-item__price {
font-variant-numeric: tabular-nums;
white-space: nowrap;
}
Progressief afbeeldingladen
Als je gerechttoto's opneemt, gebruik je moderne afbeeldingsformaten (WebP/AVIF), responsieve srcset-attributen en lui laden. Een enkele niet-geoptimaliseerde voedselauto kan alle prestatiewinsten tenietdoen.
Voorbeeld van implementatie in de praktijk
Hier is een vereenvoudigd Astro-onderdeel voor het weergeven van een menusectie. Dit is het soort ding dat we zouden bouwen in een Astro-ontwikkelingproject:
---
// src/components/MenuSection.astro
import { formatPrice } from '../utils/format';
interface Props {
category: {
name: string;
description?: string;
items: Array<{
name: string;
description: string;
price: number;
priceLabel?: string;
dietaryTags: string[];
isAvailable: boolean;
}>;
};
}
const { category } = Astro.props;
const availableItems = category.items.filter(item => item.isAvailable);
---
<section class="menu-section" id={category.name.toLowerCase().replace(/\s+/g, '-')}>
<h2>{category.name}</h2>
{category.description && <p class="section-desc">{category.description}</p>}
<div class="menu-items">
{availableItems.map(item => (
<article class="menu-item">
<div class="menu-item__header">
<h3 class="menu-item__name">{item.name}</h3>
<span class="menu-item__price">
{item.priceLabel || formatPrice(item.price)}
</span>
</div>
<p class="menu-item__description">{item.description}</p>
{item.dietaryTags.length > 0 && (
<div class="menu-item__tags">
{item.dietaryTags.map(tag => (
<span class="dietary-tag" data-tag={tag}>{tag}</span>
))}
</div>
)}
</article>
))}
</div>
</section>
Dit genereert zuiver statische HTML op buildtijd. Nul JavaScript naar de client verzonden voor de menu-inhoud zelf. Snel, toegankelijk, indexeerbaar.
Wanneer gekoppeld aan een headless CMS-webhook, kan de site automatisch herbouwen wanneer het menu wordt bijgewerkt. Personeel wijzigt een prijs in Sanity, de webhook start een build, en het nieuwe menu is in minder dan 60 seconden live.
Veelgestelde vragen
Hoeveel kost het om een op database gebaseerde restaurantmenusit te bouwen? Voor een restaurant op één locatie verwacht je €3.000-€10.000 voor een aangepaste build met een headless CMS. Dit omvat het menusysteem, ontwerp en basistraining voor personeel. Restaurantgroepen op meerdere locaties met complexe menu's liggen in het bereik van €10.000-€25.000. Controleer onze prijspagina voor meer specifieke schattingen. De maandelijkse hostingkosten bedragen doorgaans minder dan €50.
Kunnen mijn medewerkers het digitale menu zonder developer bijwerken? Ja, dat is het hele idee. Met een headless CMS zoals Sanity of Strapi is het bijwerken van het menu net zo eenvoudig als het bewerken van een formulier en het klikken op publiceren. Geen code, geen ontwerpbestanden, geen FTP. We voegen doorgaans een trainingssessie en geschreven documentatie toe, zodat je team vanaf dag één zelfstandig werkt.
Zal een digitaal menu het ontwerp van mijn restaurant schaden? Helemaal niet. Moderne webtechnologieën geven je volledige controle over typografie, indeling, kleuren en afbeeldingen. Je webmenu kan het esthetiek van je printmenu perfect evenaren -- het gebeurt alleen ook snel, toegankelijk en SEO-vriendelijk te zijn. Enkele van de mooiste ontworpen restaurantmenu's die ik heb gezien, zijn HTML, geen PDF.
Hoe zit het met QR-code-menu's -- zou ik die moeten gebruiken? QR-codes die linken naar een HTML-menupagina? Geweldig idee. QR-codes die linken naar een PDF-download? Verschrikkelijk idee. De QR-code is gewoon het leveringsmechanisme. Wat telt is wat de gebruiker ziet wanneer hij daar aankomt. Een snelle, responsieve webpagina is altijd het juiste antwoord.
Hoe helpt een digitaal menu met lokale SEO? Google's lokale zoekalgoritme houdt rekening met de inhoud op je website bij het bepalen van relevantie. HTML-menu-inhoud betekent dat Google weet dat je "oven-gestookt Napolitaans pizza" of "dry-aged rib-eye" serveert. Gecombineerd met Schema.org Menu-opmaak kunnen je specifieke gerechten verschijnen in Google Maps-resultaten en kennisvensters. PDF-inhoud is grotendeels onzichtbaar voor dit systeem.
Kan ik nog steeds een PDF-versie hebben voor mensen die het menu willen downloaden? Absoluut. Je kunt een PDF uit je database auto-genereren voor download of afdrukinformatie. Het sleutel is dat de PDF een secundaire uitvoer is, niet de primaire ervaring. Veel headless CMS-setups kunnen afdrukbare PDF's genereren met tools zoals Puppeteer of speciale PDF-generatie-API's.
Wat gebeurt er als ik het menu tijdens het diner moet veranderen? Met een headless CMS kunnen wijzigingen in seconden tot minuten live gaan, afhankelijk van je setup. Als je ISR (Incremental Static Regeneration) gebruikt met Next.js of on-demand revalidation, kan een prijswijziging of 86'd-item-update bijna onmiddellijk op de live site worden weergegeven. Dit is dramatisch sneller dan het opnieuw exporteren en uploaden van een PDF.
Zijn er gratis tools om een digitaal restaurantmenu te maken? Er zijn gratis niveaus op platforms zoals Sanity (ruim voor kleine sites) en gratis hosting op Vercel of Netlify. Als je team ontwikkelingsvaardigheid heeft, zou je een basis-menusit voor gewoon de kosten van je tijd kunnen bouwen. Echter, voor de meeste restaurants, werken met een professioneel ontwikkelingsteam zorgt ervoor dat het resultaat gepolijst, toegankelijk en van het begin af aan geoptimaliseerd is.