PDF-Speisekarte oder digitale Speisekarte: Ein PDF hinter einem QR-Code bleibt ein PDF

Der Scan funktioniert. Die Speisekarte nicht.

Ein Gast setzt sich, hebt das Smartphone, richtet es auf das kleine schwarz-weiße Quadrat auf dem Tisch, und die Kamera erledigt ihre Arbeit. Der Scan ist fast nie das Problem. Was danach erscheint, meistens schon — denn hinter sehr vielen QR-Code-Speisekarten in Europa steckt eine PDF-Speisekarte: eine Druckdatei mit einer Webadresse davor.

Was der Aufkleber auf dem Tisch eigentlich verspricht

Der Aufkleber verspricht eine digitale Speisekarte. Etwas Aktuelles, lesbar auf dem Gerät, das der Gast ohnehin in der Hand hält, und vom Betrieb noch am selben Tag änderbar. Ein dynamischer QR-Code kann dieses Versprechen tragen, denn er verweist auf eine Adresse, die der Betreiber weiterhin kontrolliert; ein statischer Code, in den der Speicherort der Datei eingebrannt ist, kann das nicht. Kommen noch ein, zwei Kurz-URL-Dienste dazu, durchläuft der Gast eine Weiterleitungskette, bevor auch nur ein Wort der Karte erscheint.

Was der Gast tatsächlich bekommt

Was erscheint, ist ein Dokument für Papier: eine Datei im Drucklayout, die keinen Umbruch kennt, sodass der Gast die Layoutarbeit per Fingerzoom selbst erledigt. Sie wird zusammen mit Office-Dokumenten katalogisiert, weil sie genau das ist.

Der Aufkleber auf dem Tisch verspricht eine digitale Speisekarte. Ein PDF dahinter liefert eine Druckdatei mit einer Webadresse davor — fertig, eingefroren und auf ein Seitenformat gesetzt, das niemand in der Hand hält.

Drei Dinge, die eine Datei nie kann und eine Seite von selbst leistet

Eine Datei ändert sich nach der Veröffentlichung nicht mehr; jemand muss einen Ersatz exportieren und hochladen. Sie passt sich dem Lesenden nicht an — weder größerer Schrift noch einem Screenreader noch einer zweiten Sprache. Und sie verrät dem Betrieb nichts darüber, was geöffnet wurde. Eine Seite leistet alle drei Dinge, ohne gefragt zu werden. Dieser Gegensatz — statische Datei gegen lebende Webseite — zieht sich durch Tempo, Layout, Barrierefreiheit, Sprache, Allergene und die tägliche Arbeit, die Karte aktuell zu halten.

Datei und Seite im direkten Vergleich

Lässt man das Branding weg, bleibt ein struktureller Unterschied: eine statische Datei gegen eine lebende Webseite. Eine PDF-Speisekarte war in dem Moment fertig, in dem sie exportiert wurde. Eine responsive HTML-Speisekarte wird bei jedem Öffnen neu zusammengesetzt, aus Daten, die der Betrieb weiterhin kontrolliert.

Worüber Sie tatsächlich entscheiden

Was jedes Format für den Gast leisten kann

Der Abstand öffnet sich bei der ersten Geste und schließt sich nie ganz: Eine responsive Seite bricht sich auf die Breite um, die sie bekommt, eine Datei nicht. Mit der Sprache verhält es sich genauso. Eine mehrsprachige Speisekarten-Seite kann auf Wunsch umschalten; eine PDF-Speisekarte braucht für jede Sprache, die ein Betrieb anbieten will, eine eigene Datei und einen eigenen QR-Code.

Was jedes Format für den Betrieb leisten kann

Hier geht es um Zeit. Eine Preisänderung in Echtzeit auf einer Seite ist eine Feldänderung, die beim nächsten Scan ankommt. Dieselbe Änderung im PDF heißt: neu exportieren, neu hochladen und hoffen, dass im Layout nichts verrutscht ist. Bei Allergenen steht mehr auf dem Spiel, denn das EU-Lebensmittelinformationsrecht legt die Deklarationspflicht dem Betreiber auf und nicht dem Dokument. Eine als strukturierte Daten gehaltene Allergenangabe wandert mit dem Gericht mit. Im PDF ist sie eine Textzeile, an die jemand denken muss. Eine Seite meldet außerdem zurück — Gerichtsaufrufe, Sitzungen, Sprachverteilung —, eine Datei meldet nichts.

Wo sich beide überschneiden und wo nicht

Beide Formate lassen sich scannen, und beide überstehen eine schwache Verbindung. Die Überschneidung endet in dem Moment, in dem sich die Karte ändern muss.

Tempo: Was in den ersten fünf Sekunden am Tisch passiert

Ein Gast scannt, blickt auf den Bildschirm und beginnt entweder zu lesen oder legt das Telefon mit dem Display nach unten hin und wartet auf die Bedienung. In diesem kurzen Fenster hören eine PDF-Speisekarte und eine responsive HTML-Speisekarte auf, sich wie zwei Varianten derselben Sache zu verhalten. Die eine muss vollständig angekommen sein, bevor sie überhaupt etwas zeigt; die andere bringt die ersten Gänge auf den Bildschirm, während der Rest noch unterwegs ist.

Die Schwellenwerte, die Google veröffentlicht, und warum sie Ihren Gastraum beschreiben

Die Core-Web-Vitals-Dokumentation von Google bewertet Largest Contentful Paint (LCP) als gut, wenn er innerhalb von 2,5 Sekunden nach Beginn des Seitenaufbaus eintritt, gemessen am 75. Perzentil der Seitenaufrufe. Dieselbe Dokumentation setzt Interaction to Next Paint (INP) auf 200 Millisekunden oder weniger und Cumulative Layout Shift (CLS) auf 0,1 oder weniger, ebenfalls am 75. Perzentil. Google weist außerdem darauf hin, dass diese Kennzahlen für Mobilgeräte und Desktop getrennt erhoben werden — eine Karte, die fast ausschließlich auf dem Smartphone geöffnet wird, wird also an ihren mobilen Felddaten gemessen und nicht daran, wie flott sie auf dem Bürolaptop öffnet.

Diese Zahlen wurden für die Suche geschrieben, sie lesen sich aber wie Servicegrenzen. Zweieinhalb Sekunden entsprechen ungefähr der Geduld eines Menschen, der ein Telefon am Tisch hält, während die Bedienung näher kommt.

Warum eine druckfertige Datei von Natur aus schwer ist

Ein druckfertiges Speisekarten-PDF trägt eingebettete Schriften und Bilder in Druckauflösung, weil eine Druckerei genau das braucht. Neben einer Webseite, die zuerst Text lädt und Bilder nach und nach nachliefert, ist es von Natur aus schwer. Nichts daran ist kaputt; die Datei tut schlicht die Arbeit, für die sie gemacht wurde, auf einem Gerät, für das sie nicht gemacht wurde. Im überlasteten WLAN des Betriebs wird Dateigröße unmittelbar zu Ladezeit im Mobilfunk, und diese Verzögerung landet beim ersten lesbaren Gericht.

Die Weiterleitungskette, die niemand auf den Aufkleber gedruckt hat

Der Aufkleber trägt eine URL, das Telefon geht aber oft einen längeren Weg. Ein typisches Szenario: Der gedruckte Code verweist auf einen Kurz-URL-Dienst, der auf einen Cloud-Speicherordner weiterleitet, der wiederum auf einen Viewer weiterleitet. Jeder Sprung kostet eine Abfrage und einen Roundtrip. Weiterleitungsketten und Kurz-URL-Dienste sind auf dem Tischaufsteller unsichtbar, und sie gehen vollständig zulasten der Mobile UX der Speisekarte.

Mobile UX: Der Gast sollte das Layout nicht selbst machen müssen

Eine Speisekarte wird in den wenigen Minuten zwischen Hinsetzen und Bestellen gelesen, auf einem Telefon in einer Hand, oft an einem Tisch, an dem drei andere Leute reden. Alles an der Mobile UX einer Speisekarte folgt aus dieser Situation und nicht daraus, wie das Dokument auf dem Monitor einer Designerin aussieht.

A4-Proportionen auf einem Fünf-Zoll-Bildschirm

Googles Hinweise zur mobilen Benutzerfreundlichkeit auf web.dev benennen die Mechanik klar: Ein PDF im Drucklayout bricht seinen Text nicht um, also behält ein für A4 gebautes Layout seine A4-Proportionen auf einem Fünf-Zoll-Bildschirm. Textumbruch auf kleinen Bildschirmen ist genau das, was ein Browser mit einer responsiven HTML-Speisekarte macht: Er setzt die Zeilen auf die Gerätebreite neu um. Ein PDF reicht diese Arbeit an den Gast weiter, der sie mit Zoomgesten erledigt: vergrößern, zwei oder drei Gerichte lesen, seitwärts ziehen bis zur Preisspalte, wieder herauszoomen, um die nächste Kategorie zu finden. Der Gast setzt die Seite faktisch von Hand, einmal pro Gang.

Suchen, filtern, springen: Navigation, die eine Datei nicht bieten kann

Eine Seite lässt sich befragen, eine Datei nur scrollen. Kategorie-Sprungmarken, ein Suchfeld, ein Filter, der eine lange Liste auf das eingrenzt, was jemand heute Abend tatsächlich essen kann — das sind gewöhnliche Bausteine einer Webseite und in einem flachen Export unmöglich. Dieselbe Struktur trägt weiter: Semantische Überschriften geben einem Screenreader etwas, worin er sich bewegen kann, statt eines einzigen undifferenzierten Blocks, und eine Seite kann ihre Textrichtung je Sprache angeben. Ein PDF bewahrt genau das, was die Designerin exportiert hat, einschließlich der Fehler.

Gedämpftes Licht, eine Hand, ein voller Tisch

Wenig Licht, ein Telefon auf halber Helligkeit, ein Tisch mit vier Personen: In diesem typischen Szenario bemisst sich der Unterschied zwischen Seite und Datei daran, wie viele Gesten einen Gast von einem Preis trennen. Es gibt einen zweiten Grund, sich dafür zu interessieren. Beim Mobile-First-Indexing ist die Smartphone-Ansicht zugleich die Ansicht, die die Suche sieht.

Barrierefreiheit ist jetzt eine Rechtsfrage, kein Nice-to-have

Jahrelang galt eine schwer lesbare Speisekarte als Servicemangel. In der EU ist sie zusätzlich eine Compliance-Frage geworden, und die Antwort hängt weniger am QR-Code als an dem, was dahinter liegt.

Was der European Accessibility Act abdeckt und ab wann

Die Richtlinie (EU) 2019/882, bekannt als European Accessibility Act, gilt laut dem auf EUR-Lex veröffentlichten Text seit dem 28. Juni 2025 für erfasste Produkte und Dienstleistungen, die auf dem EU-Markt bereitgestellt werden. Technischer Maßstab ist EN 301 549, die harmonisierte europäische Norm, die die Erfolgskriterien von WCAG 2.1 Level AA für digitale Inhalte und Dienste übernimmt. Die Gruppe hinter den Regeln ist nicht klein: Eurostat berichtete, dass 2024 23,9 % der Menschen in der EU ab 16 Jahren eine Behinderung (Aktivitätseinschränkung) hatten — nach den Bevölkerungszahlen von Eurostat rund 90 Millionen Menschen.

Warum ein nicht getaggtes PDF an einem Screenreader scheitert

Eine aus einer Designdatei exportierte PDF-Speisekarte ist strukturell eine Sammlung von Zeichenanweisungen. Solange sie niemand getaggt hat, gibt es keine Überschriftenhierarchie, keine Listensemantik und keine verlässliche Lesereihenfolge — ein Screenreader kann also zwei Spalten ineinander verschränkt vorlesen, Preise losgelöst von den zugehörigen Gerichten ansagen oder überhaupt nichts finden, wenn die Seite zu einem Bild verflacht wurde. Eine responsive HTML-Speisekarte besteht aus genau den Elementen, die assistive Software erwartet — deshalb tauchen Screenreader und semantische Überschriften in jeder Prüfliste gemeinsam auf.

Textvergrößerung, Kontrast und Tap-Flächen auf einer echten Seite

Eine Datei mit festem Layout skaliert als Ganzes: Vergrößert man die Schrift, laufen die Zeilen aus dem Bildschirm und erzwingen seitliches Schieben. Eine Seite bricht um. Kontrast- und Tap-Flächen-Regeln lassen sich auf einer Seite außerdem prüfen und sind in einem exportierten Dokument ohne erneutes Öffnen der Originalgrafik kaum zu beheben.

Wer ausgenommen ist und warum die Ausnahme enger ist, als sie klingt

Das Gesetz nimmt Kleinstunternehmen — weniger als 10 Beschäftigte und ein Jahresumsatz oder eine Jahresbilanzsumme von höchstens 2 Millionen EUR — von seinen Dienstleistungspflichten aus. Ein einzelnes inhabergeführtes Café fällt oft darunter. Eine kleine Gruppe, ein Hotel-F&B-Betrieb oder ein Lokal innerhalb eines größeren Unternehmens in der Regel nicht — und die Ausnahme betrifft die Rechtspflicht, nicht den Gast, der die Karte nicht lesen kann.

Sprachen: eine Seite, viele Gäste

Europa verzeichnete 2024 laut dem World Tourism Barometer von UN Tourism 747 Millionen internationale Touristenankünfte — 1 % über dem Niveau von 2019 und 5 % über 2023 — und Eurostat zählte in der EU in diesem Jahr erstmals mehr als 3 Milliarden Übernachtungen in touristischen Beherbergungsbetrieben, 2,7 % mehr als 2023. In der Nähe eines Bahnhofs, eines Strands oder einer Kathedrale liest der Gast an Tisch sechs die Karte oft in einer Sprache, die die Küche nicht spricht.

Warum vier PDF-Dateien vier Wartungsprobleme sind

Eine mehrsprachige Speisekarte aus PDFs besteht aus vier Dokumenten, vier Exportzyklen und meist vier QR-Codes auf dem Tisch. Ändert sich ein Preis, muss die Änderung viermal gemacht werden, in vier Layouts. Vergisst man eines — ein typisches Szenario —, dann bepreist die deutsche Fassung stillschweigend ein Gericht, das die italienische längst nicht mehr führt. Auf einer responsiven HTML-Speisekarte ist Sprache ein Umschalter über einem Datenbestand: eine Änderung wirkt überall.

Den Namen des Gerichts behalten, das Gericht erklären

Die Studie „Can’t Read, Won’t Buy“ von CSA Research mit 8.709 Verbraucherinnen und Verbrauchern in 29 Ländern ergab, dass 76 % der Online-Käufer lieber Produkte kaufen, deren Informationen in ihrer eigenen Sprache vorliegen, und dass 40 % niemals auf Websites in einer anderen Sprache kaufen; unter den Befragten ohne Englischkenntnisse steigt dieser Wert auf 89 %. Die Regel lautet nicht, alles zu übersetzen. Behalten Sie den Eigennamen des Gerichts — er ist das, was der Gast bestellt und was die Bedienung hört — und übersetzen Sie die Beschreibung darunter.

Was maschinelle Übersetzung anfassen darf und was nicht

Automatische Übersetzung mit menschlicher Prüfung ist für Beschreibungen und Rubriktitel vertretbar. Sie ist für Allergene nicht geeignet, denn dort ist ein falsches Wort eine Sicherheitsfrage und keine Stilfrage. Von rechts nach links geschriebene Schriften und bidirektionaler Text — eine arabische Fassung neben lateinischen Ziffern — ergeben ein Layout, das ein starres PDF nicht umbrechen kann; eine als Seite ausgelieferte QR-Code-Speisekarte kann die Textrichtung je Sprache setzen und die Preise unangetastet lassen.

Allergene: das Feld, das nie veraltet sein darf

Von allem, was auf einer Speisekarte steht, ist die Allergenzeile die eine Stelle, an der eine veraltete Datei aufhört, bloß unbequem zu sein. Ein Preis, der einen Euro zu niedrig steht, kostet das Haus einen Euro. Eine Allergenangabe, die das Rezept des Vormonats beschreibt, kann einen Gast ins Krankenhaus bringen.

Was die Verordnung (EU) Nr. 1169/2011 von einem Restaurant verlangt

Die Verordnung (EU) Nr. 1169/2011 gilt seit dem 13. Dezember 2014, und wie die Europäische Kommission in ihren Rechtsvorschriften zur Lebensmittelinformation für Verbraucher darlegt, verpflichtet sie Lebensmittelunternehmer, in jedem Gericht 14 bestimmte Allergene anzugeben — auch bei nicht vorverpackten Lebensmitteln, die in Restaurants, Cafés und Kantinen serviert werden. Damit endet die Pflicht nicht. Für nicht vorverpackte Lebensmittel verlangen die Verordnung und die darauf aufbauenden Leitlinien der nationalen zuständigen Behörden, dass die Allergeninformation am Ort des Angebots schriftlich vorliegt: auf der Karte, einer Tafel oder einem Begleitdokument. Ein mündlicher Hinweis der Bedienung genügt nicht.

Ein PDF kann diese Schriftform tragen. Was es nicht kann, ist zu garantieren, dass die Schriftform in der Hand des Gastes die aktuelle ist.

Allergene als strukturierte Daten, nicht als Fußnote

Im PDF überleben Allergene meist als Symbolreihe oder nummerierte Legende am Seitenfuß, in einer Schriftgröße, die die Information technisch vorhanden und praktisch unbrauchbar macht — und für einen Screenreader unsichtbar. Auf einer responsiven HTML-Speisekarte ist jedes Gericht ein Datensatz, und die daran hängenden Allergene sind ein Feld dieses Datensatzes. Ein Feld lässt sich filtern, vorlesen, mit dem Rest der Seite übersetzen und an einer Stelle korrigieren.

Warum Rezeptänderung und Kartenänderung dieselbe Handlung sein müssen

Küchen wechseln mitten in der Woche Lieferanten. Ein typisches Szenario: Das übliche Dressing ist nicht lieferbar, der Ersatz enthält Senf, und das Gericht geht drei Tage lang raus, bevor jemand die Datei neu exportiert. Auf einer Seite schreibt dieselbe Änderung, die eine Preisaktualisierung in Echtzeit erzeugt, auch das Allergenfeld um. Eine Handlung, ein Datensatz, live beim nächsten Scan. Die Lücke entsteht, wenn die Allergenangabe als Dokument behandelt wird, das neu herausgegeben werden muss, statt als Daten, die man ändert.

Der Alltag des Betriebs: eine Preisänderung, ein ausverkauftes Gericht, eine neue Saison

Eine Speisekarte ist kein Dokument, das einmal fertig wird. Lieferanten erhöhen Preise, Gerichte gehen mitten im Service aus, und die Karte muss wechseln, wenn die Saison wechselt. Die Frage ist nicht, ob sich die Karte ändert, sondern wie viel Abend eines Betreibers jede Änderung kostet.

Die PDF-Schleife: Designer, Export, Upload, jeden Link erneut prüfen

Eine PDF-Speisekarte zu ändern heißt meist, zur ursprünglichen Layoutdatei zurückzugehen, die oft bei der Designerin liegt, die sie gebaut hat. Jemand passt die Zahl an, exportiert erneut, prüft, dass nichts verrutscht ist, lädt die neue Datei hoch und kontrolliert anschließend, dass jeder QR-Code auf jedem Tisch sowie der Link auf der Reservierungsseite und im Portal-Eintrag nun auf die neue Fassung zeigt und nicht auf die alte. Diese Kette muss für einen einzigen korrigierten Preis erneut abgelaufen werden.

Die Seiten-Schleife: ein Feld, ein Speichern

Eine digitale Speisekarte dreht die Reihenfolge um. Eine Preisaktualisierung in Echtzeit ist ein Feld, das am Telefon geändert und gespeichert wird; der nächste Gast, der scannt, sieht die neue Zahl. Ein ausverkauftes Gericht zu markieren — in der Küche „86“ genannt — ist ein Schalter, der das Gericht für den Rest des Service ausgraut und es am Folgetag wiederherstellt. Saisonale Kartenpflege wird zur Sache des Veröffentlichens vorbereiteter Positionen statt des Neuauflegens von Grafik.

Die versteckten Kosten der Fassung, die niemand ersetzt hat

Der teure Fehler ist selten die Änderung selbst. Es ist die Kopie, die nie getauscht wurde: die alte Datei noch im Cache eines Telefons, der Link in einem Verzeichniseintrag, der niemandem gehört, die gedruckte Einlage an der Bar. Bei einer Datei hängt Richtigkeit daran, jede Kopie zu verfolgen. Bei einer Seite gibt es nur eine Kopie zu korrigieren.

Was die Karte Ihnen sagt und was sie Google sagt

Eine PDF-Speisekarte ist ein geschlossenes Objekt. Sie wird abgerufen, am Tisch geöffnet und sagt der Küche danach nichts zurück. Eine responsive HTML-Speisekarte hinterlässt eine Spur: welches Gericht geöffnet wurde, in welcher Sprache, an welchem Abend. Laut dem Bericht State of the Restaurant Industry 2021 der National Restaurant Association gaben 50 % der Betreiber von Full-Service-Restaurants an, seit März 2020 digitalen Kartenzugang per QR-Code eingeführt zu haben — viele Betriebe lassen also längst scannen, ohne irgendetwas daraus zu sammeln.

Aufrufe je Gericht statt Downloads je Datei

Ein statisches Datei-Hosting kann melden, wie oft ein Dokument angefordert wurde. Das ist eine einzige Zahl, und sie deckt die ganze Karte auf einmal ab: Die Vorspeisen, die niemand liest, und das Gericht, auf das die Küche am stolzesten ist, sind darin nicht zu unterscheiden. Speisekarten-Auswertung auf einer digitalen Karte arbeitet auf Positionsebene — Gerichtsaufrufe, Sitzungen je Service, die Reihenfolge, in der Kategorien geöffnet werden. In einem typischen Szenario steht ein Gericht mit hoher Marge weit unten auf einer langen Seite und wird selten geöffnet; die Lösung ist eine Positionsänderung, kein neues Rezept. Mit einer PDF-Speisekarte ist dieses Muster unsichtbar, weil die Datei nichts darüber verrät, was nach dem Öffnen geschah.

Sprachverteilung als Signal für die Personalplanung

Die Sprachwahl ist operative Information, bevor sie Marketinginformation ist. Wenn in einem Monat ein großer Teil der Sitzungen auf eine einzige Sprache umschaltet, ist das ein Argument dafür, wer in diesem Monat im Service stehen sollte, welche Lieferantenprospekte sich zu übersetzen lohnen und welches Menü eine zweite Fassung verdient. Eine QR-Code-Speisekarte, die die Sprachverteilung erfasst, macht aus einer Vermutung über den Gastraum etwas, worauf sich ein Dienstplan bauen lässt.

Die Daten lesen, ohne Datenschutzregeln zu brechen

Nützliche Kartendaten sind aggregiert und dünn: Zählungen von Positionsaufrufen, Sitzungen, Sprachen. Sie brauchen keine Namen, keine Konten und kein seitenübergreifendes Tracking, was sie weit von den schwereren Pflichten des EU-Datenschutzrechts fernhält. Betreiber sollten trotzdem prüfen, was ihre Plattform im Browser setzt und ob vor nicht notwendiger Auswertung eine Einwilligung erforderlich ist.

Indexiert ist nicht dasselbe wie nützlich

Google Search Central führt Adobe Portable Document Format (.pdf) als indexierbaren kodierten Dateityp auf, neben Word-, Excel- und PowerPoint-Dokumenten. Eine PDF-Speisekarte kann also indexiert werden. Dieselbe Dokumentation bietet aber keine Hinweise zu mobiler Benutzerfreundlichkeit, strukturierten Daten oder Rich Results für PDFs; sie behandelt sie als einfache Binärdokumente.

Was ein Mobile-First-Crawler sieht

Beim Mobile-First-Indexing verwendet Google die mobile Fassung der Inhalte einer Website, gecrawlt mit dem Smartphone-Agent, für Indexierung und Ranking. Eine Seite, die zum Lesen auf dem Telefon gebaut ist, wird nach ihren eigenen Maßstäben beurteilt. Ein für A4 gebautes Dokument nicht.

Strukturierte Daten, Sprachfassungen und interne Links

Eine HTML-Speisekarte kann Menu- und Restaurant-Markup tragen, ihre Sprachfassungen angeben und auf Reservierungs-, Standort- und Kontaktseiten verlinken. Ein PDF trägt nichts davon und führt nirgendwohin.

Die zwei ehrlichen Einwände: schwaches Signal und der Druck, den Sie weiterhin brauchen

Warum der Tisch im Kellergeschoss der eigentliche Test ist

Zwei Einwände gegen den Ersatz einer PDF-Speisekarte durch eine gehostete Seite verdienen eine klare Antwort. Der erste ist die Verbindung. Eine einmal heruntergeladene Datei liegt auf dem Telefon; eine Seite braucht, so die übliche Erzählung, jedes Mal das Netz. Zu klären ist das nicht auf der Terrasse mit vier Balken Empfang, sondern im Kellergastraum mit dicken Wänden, am Hoftisch am Rand der Router-Reichweite oder bei vollem Haus an einem Samstag, an dem alle einen Access Point teilen.

Caching, leichte Bilder und ein gedruckter Rückfallplan

Der Einwand ist berechtigt, gilt aber genauso für die Datei: Das oben beschriebene Gewicht in Druckauflösung ist genau das, womit eine überlastete Verbindung am schlechtesten umgeht, und ein Download, der vollständig ankommen muss, kann das erste Gericht nicht früh zeigen. Eine leichte Seite kann das LCP-Ziel auf einer normalen Verbindung erreichen; eine schwere Datei in der Regel nicht. Offline-Caching der Karte, zurückhaltendes Bildgewicht und eine Handvoll laminierter Karten hinter der Bar schließen die verbleibende Lücke.

Eine Quelle der Wahrheit, mehrere Ausgaben

Der zweite Einwand ist der Druck, und er hört auf, ein Einwand zu sein, sobald die Architektur stimmt. Derselbe Datensatz, der die QR-Code-Speisekarte speist, kann einen druckfertigen PDF-Export als Ausgabe erzeugen: identische Preise, identische Allergene, dasselbe Saisongericht, gesetzt für A4 statt für die Mobile UX. Was scheitert, ist die umgekehrte Anordnung, in der das Dokument der Stammsatz ist und die digitale Karte eine Kopie davon, die zwischen zwei Nachdrucken still veraltet.

Bankette, Weinkarten und Portal-Uploads

Vieles muss weiterhin auf Papier oder als Datei existieren. Ein Bankettangebot geht per E-Mail an einen Firmenkunden. Eine lange Weinkarte hält man lieber in der Hand, als sie zu scrollen. Ein Portal will die Karte vielleicht als Upload in einem festen Format. Irgendetwas muss für Passanten im Fenster stehen. Nichts davon spricht dafür, die Seite aufzugeben; es spricht dafür, jedes dieser Erzeugnisse aus denselben Daten zu erzeugen.

Wann ein PDF weiterhin die ehrliche Antwort ist

Ein kleiner Betrieb mit kurzer Karte, die sich selten ändert, überschaubarer Allergenlage und überwiegend lokalem Publikum ist mit einem Dokument nicht schlecht bedient. Hier geht es um Betriebe, deren Karte in Bewegung ist.

Umsteigen, ohne einen einzigen QR-Code neu zu drucken

Die meisten Betreiber nehmen an, ein PDF hinter sich zu lassen bedeute neue Tischaufsteller, neue Aufkleber, neue Fensterfolien. Meist stimmt das nicht. Alles hängt davon ab, was das gedruckte Muster tatsächlich kodiert.

Die Domain besitzen, auf die der Code zeigt

Ein statischer QR-Code speichert das Ziel im Muster selbst — wer ändern will, wohin er führt, muss neu drucken. Ein dynamischer QR-Code speichert eine kurze Adresse, die auf das auflöst, was der Eigentümer später festlegt; das ist das praktische Gewicht der Unterscheidung dynamischer QR-Code gegen statischen QR-Code. Idealerweise liegt diese kurze Adresse auf einer Domain, die der Betrieb kontrolliert. Der Kurz-URL-Dienst eines Dritten fügt die oben beschriebenen Sprünge hinzu und lässt den Betrieb einen kaputten Link nicht reparieren, wenn der Anbieter verschwindet.

Eine Zwei-Wochen-Checkliste für einen kleinen Betrieb

In einem anschaulichen Beispiel baut ein Bistro mit dreißig Plätzen in der ersten Woche die Seite und liest sie Korrektur, und in der zweiten Woche leitet es um, testet jede gedruckte QR-Code-Speisekarte im Gastraum und weist das Personal ein, bevor die alte Datei außer Betrieb geht.

Häufige Fragen