TL;DR
- ChatGPT, Claude und Perplexity lesen rohes HTML und führen kein JavaScript aus. Eine Speisekarte, die per Skript gezeichnet oder über ein eingebettetes Widget ausgeliefert wird, kann bei Google ranken und trotzdem in jeder KI-Antwort fehlen.
- Eine PDF-Speisekarte versteckt den einzigen Text auf einer Restaurant-Website, der benennt, was die Küche tatsächlich kocht. Diese Gerichtnamen, Zutaten und Erzeuger sind das Vokabular, gegen das eine konkrete Frage abgeglichen werden muss.
- Strukturierte Daten sind weniger wichtig, als die Branche behauptet. Google dokumentiert kein Rich-Result für Menu, sondern nur eine Menü-URL bei Local Business, und eine der besten Speisekartenseiten, die wir getestet haben, hat überhaupt keine strukturierten Daten.
- Mehrere Statistiken, die zu Speisekarten und KI-Suche zitiert werden, halten einer Prüfung nicht stand. Eine populäre Zahl konnten wir bis zu einem einzigen Blogbeitrag ohne Methode und ohne Datensatz zurückverfolgen.
- Jedes Beispiel unten wurde mit curl getestet statt mit einem Browser, denn nur so sehen Sie, was eine Maschine sieht.
Ein Gast fragt einen Assistenten nach einem vegetarischen Degustationsmenü in der Nähe der London Bridge. Er nennt drei Restaurants. Ihre Küche kocht seit zwei Jahren ein vegetarisches Degustationsmenü, und Sie sind nicht eines der drei.
Die üblichen Erklärungen lauten Bewertungen, Autorität oder das allgemeine Rätsel der KI-Suche. Oft ist der Grund banaler. Der Assistent hatte Ihre Speisekarte nie. Er hatte Ihre Startseite, die den Raum beschreibt, und Ihre Buchungsseite, die die Verfügbarkeit beschreibt. Das einzige Dokument, das auflistet, was Sie tatsächlich kochen, war ein PDF, und dessen Inhalt hat die Antwort nie erreicht.
Das ist der Teil der KI-Sichtbarkeit von Restaurants, der am wenigsten Beachtung bekommt, weil er wie eine Design-Entscheidung aussieht statt wie eine Marketing-Entscheidung. Er ist keins von beidem. Es ist ein Retrieval-Problem, und es lässt sich in etwa dreißig Sekunden testen.
Was braucht eine KI-Engine tatsächlich von einer Speisekartenseite?
Drei Dinge müssen der Reihe nach passieren. Ein Restaurant kann an jedem einzelnen davon scheitern, und das Ergebnis sieht von außen identisch aus: Das Lokal wird schlicht nicht erwähnt.
| Ebene | Was gegeben sein muss | Was sie zerstört | Wie Sie es testen |
|---|---|---|---|
| Retrieval | Ein Crawler kann den Text abrufen, ohne Code auszuführen | PDFs, Bilder von Speisekarten, JavaScript-Rendering, iFrames, Anbieter-Subdomains | Rufen Sie die Seite mit curl ab und lesen Sie, was zurückkommt |
| Extraktion | Der Text übersteht das Zerschneiden in Chunks | Mehrspaltige Layouts, Preisspalten, in Fließtext aufgelöste Tabellen | Lesen Sie den extrahierten Text zurück und prüfen Sie, ob Gericht und Preis noch zusammengehören |
| Matching | Es existiert etwas Konkretes, das zu einer konkreten Frage passt | Speisekarten, die in Adjektiven statt Gerichtnamen beschrieben sind | Durchsuchen Sie die Rohantwort nach einem Gericht, für das Sie bekannt sind |
Die meisten Ratschläge konzentrieren sich auf die dritte Ebene und nennen das Content-Strategie. Restaurants scheitern meistens an der ersten.
Warum übersehen KI-Crawler Speisekarten, die Google perfekt indexiert?
Weil die Crawler hinter KI-Antworten nicht der Crawler sind, für den Sie fünfzehn Jahre lang optimiert haben.
OpenAI dokumentiert vier Crawler mit unabhängig steuerbaren robots.txt-Tokens: GPTBot fürs Training, OAI-SearchBot zum Anzeigen von Ergebnissen in der ChatGPT-Suche, ChatGPT-User für einen Live-Abruf, den eine Person auslöst, und OAI-AdsBot [1]. Perplexity dokumentiert PerplexityBot für systematisches Indexieren und Perplexity-User für Live-Abrufe pro Frage [2]. Anthropic dokumentiert ClaudeBot, Claude-User und Claude-SearchBot und erklärt, dass alle drei robots.txt respektieren [3].
Was keine dieser Anbieterseiten dokumentiert, ist ein Rendering-Schritt. Unabhängige Messungen von Crawl-Logs berichten, dass GPTBot, ClaudeBot und PerplexityBot JavaScript-Dateien anfragen, ohne sie je auszuführen, und keinen zweiten Durchlauf machen, nachdem eine Seite fertig gerendert wäre [4]. Das ist eine Beobachtung Dritter und keine Aussage eines Anbieters, behandeln Sie die genauen Zahlen also mit Vorsicht, aber die Richtung ist konsistent und deckt sich mit dem, was jeder mit einem Terminal selbst nachvollziehen kann.
Die praktische Konsequenz ist konkret und teuer. Google rendert JavaScript, also erbt Google AI Overviews diese Toleranz über Googlebot, und Copilot erbt sie über Bingbot. Die eigenständigen ChatGPT, Claude und Perplexity tun das nicht. Eine im Browser zusammengebaute Speisekarte kann deshalb bei Google perfekt sichtbar sein, für Sie selbst beim Nachsehen perfekt sichtbar sein, und in den Assistenten, die Ihre Gäste tatsächlich fragen, vollständig fehlen.
Deshalb ist der einzige ehrliche Test ein Abruf, kein Hinsehen. Wir haben einen Kontrolltest gebaut, um die Größe der Lücke zu zeigen. Dieselbe Speisekarte, aus derselben Datendatei, auf zwei Arten gerendert:
$ curl -s http://localhost:3000/menus/borough-market/dinner | grep -o "Bavette Steak"
Bavette Steak
$ curl -s http://localhost:3000/csr-demo | grep -o "Bavette Steak"
$
Ein Gerichtname, in der ersten vorhanden und in der zweiten nicht. Im Browser sehen die beiden Seiten gleich aus. Für einen Crawler, der keine Skripte ausführt, serviert das zweite Restaurant dieses Gericht nicht.
Führen Sie denselben Befehl gegen Ihre eigene Speisekarte aus, bevor Sie weiterlesen. Wenn Ihre Gerichtnamen nicht zurückkommen, spielt der Rest dieser Seite noch keine Rolle.
Was kostet Sie ein PDF tatsächlich?
Zwei getrennte Dinge, und sie verstärken sich gegenseitig.
Die Extraktionssteuer. Ein PDF speichert visuelle Position, nicht Lesereihenfolge. Forschung zu Retrieval-Pipelines beschreibt genau dieses Problem: textbasiertes Standard-Chunking tut sich schwer mit komplexen Dokumentstrukturen, mehrseitigen Tabellen und Inhalten, die über Seitengrenzen hinweg vom Kontext abhängen, weshalb es überhaupt bildgeführte Chunking-Methoden gibt [5]. Eine Speisekarte ist nahe am schlimmsten Fall für die naive Variante. Gerichtname, Beschreibung und Preis stehen meist in getrennten visuellen Spalten, sodass ein spaltenweiser Extraktor sie durcheinanderwürfelt und Zeilen erzeugt, die wie Unsinn klingen. Der Preis landet am falschen Gericht, oder an gar keinem.
Das Vokabular, das Sie nie veröffentlichen. Das ist der Teil, den Restaurants unterschätzen. Ihre Startseite besteht aus Adjektiven: saisonal, einladend, produktgeführt. Ihre Speisekarte besteht aus Substantiven. Sie ist die einzige Seite auf Ihrer Website, die Nduja, Herdwick, Osietra, Sauternes, Rockpile enthält, die konkreten Wörter, aus denen eine konkrete Frage besteht. Die Information-Retrieval-Forschung fasst das allgemeine Problem als Document Vocabulary Mismatch, bei dem seltene Long-Tail-Anfragen scheitern, weil die Begriffe, nach denen jemand sucht, in keiner abrufbaren Form existieren, und nennt „was sind die Zutaten eines benannten Gerichts" als klassischen Härtefall [6]. Keine Studie hat das speziell an Restaurant-Speisekarten gemessen, behandeln Sie es also als Schlussfolgerung aus etablierter Retrieval-Mechanik und nicht als Speisekarten-Benchmark. Der Mechanismus ist trotzdem nicht umstritten. Text, der nicht abrufbar ist, kann nicht gematcht werden.
Zusammengenommen rankt eine PDF-Speisekarte nicht bloß schlecht. Sie entfernt das Restaurant aus dem gesamten Long Tail an Fragen zu Gericht, Zutat, Erzeuger und Ernährungsform, und das ist heute der Großteil dessen, wie Menschen fragen.
Sieben Speisekartenseiten, die das richtig machen
Jede davon wurde am 5. September 2026 mit curl abgerufen, wobei die Antwort außerhalb von Skript-Tags geprüft wurde. Jede lehrt etwas, das die anderen nicht lehren.
1. Hawksmoor, als Referenzimplementierung für mehrere Standorte
thehawksmoor.com/locations/borough/food/menu ist die vollständigste Implementierung, die wir irgendwo gefunden haben. Gerichtnamen, Cut-Beschreibungen und Preise sind reiner Text in der Antwort, und die Seite trägt einen kompletten Graphen: Restaurant, Menu, MenuSection, MenuItem, Offer, UnitPriceSpecification. Einzelne Gerichte tragen eine Ernährungskennzeichnung, zum Beispiel "suitableForDiet":"https://schema.org/VegetarianDiet". Mehrere Preispunkte pro Cut werden korrekt als separate Offer-Objekte modelliert statt als String.
Die strukturelle Lehre ist das URL-Muster. Jeder Standort hat seine eigene Adresse, /locations/<venue>/food/menu/, und seinen eigenen kompletten Graphen. So vermeidet eine Gruppe das Problem, dass mehrere Standorte zu einer einzigen mehrdeutigen Entität verschwimmen und eine Engine nicht mehr weiß, welchen sie nennen soll. Wir haben separat darüber geschrieben, wie Restaurantgruppen ihre eigenen Standorte in KI-Antworten kannibalisieren.
2. Zizzi, für Allergen- und Ernährungsdaten in Ketten-Größenordnung
zizzi.co.uk/menus veröffentlicht Kalorienangaben und Ernährungs-Tags als sichtbaren Text neben jedem Gericht und untermauert sie mit NutritionInformation und suitableForDiet in strukturierten Daten. Das ist das einzige Beispiel in unserer Auswahl, das beides in dieser Größenordnung kombiniert, und das Datenmodell wurde erkennbar für strukturierte Speisekarteninhalte gebaut statt später an eine Marketing-Website angeflanscht.
Wichtig für alle, die das kopieren wollen: Die gesamte landesweite Speisekarte wird in einer einzigen Antwort von rund drei Megabyte ausgeliefert, wobei der Browser die Abschnitte unter Tabs gruppiert. Jeder Abschnitt steckt trotzdem im HTML. Tabs, die Inhalte per CSS verstecken, sind unproblematisch. Tabs, die Inhalte erst beim Klick nachladen, sind es nicht.
3. The Capital Grille, für eine Weinkarte als Text
thecapitalgrille.com/our-wines bringt Erzeuger, Region, Rebsorte, Verkostungsnotiz und Essensbegleitung in echtes Markup, mit Definitionslisten, sodass jeder Weinname in einem <dt> steckt und seine Beschreibung im passenden <dd>. Das ist ungewöhnlich gute semantische Struktur, und genau das dichte Eigennamen-Vokabular, das eine Frage wie „wo kann ich Pomerol zu einem Dry-Aged-Steak trinken" zum Matchen braucht.
Die Entscheidung dahinter ist ebenso lehrreich wie das Markup. Eine Kette dieser Größe versucht nicht, ihre gesamte rotierende Flaschenliste zu veröffentlichen. Sie veröffentlicht kuratierte, dauerhafte Auswahlen als Text und überlässt die volatile Gesamtliste einem System im Restaurant selbst. Alles zu veröffentlichen ist nicht das Ziel. Den dauerhaften Teil zu veröffentlichen ist es.
4. Core by Clare Smyth, als Beweis dass Text und Schema zwei verschiedene Probleme sind
corebyclaresmyth.com/menus liefert das gesamte Degustationsmenü als Text aus, jeden Gang, den Preis und den Preis der Weinbegleitung, ganz ohne strukturierte Daten auf der Seite. Das ist ein sauberer Beweis, sauberer als jedes Argument, das wir konstruieren könnten: rohe Lesbarkeit und strukturierte Daten sind zwei unabhängige Achsen, und die Lesbarkeit ist die wichtigere.
Es gibt hier auch eine echte Kuriosität. Rufen Sie die Seite ohne Skriptausführung ab, und die vollständige Gangliste steht in der Antwort. Öffnen Sie sie im Browser, und die Gangliste steht erst im Dokument, nachdem Sie sich zu einem Menü durchgeklickt haben. Wir haben beides geprüft: Die Anzahl des Wortes Osietra ist eins im abgerufenen HTML und null auf der gerenderten Seite. Ein Crawler, der JavaScript ignoriert, sieht derzeit mehr von diesem Menü als ein Besucher, bevor er interagiert. Das ist ein Zufall und keine Strategie, aber eine nützliche Erinnerung daran, dass das, was Sie sehen, und das, was eine Maschine bekommt, zwei verschiedene Artefakte sind.
5. Freeman's, als Beweis dass es keinen Individualbau braucht
freemansrestaurant.com ist ein unabhängiges Restaurant auf Squarespace, und es besteht den Abruf-Test vollständig. Dinner, Lunch, Brunch und Dessert stehen allesamt als Text in einer einzigen Antwort, Preise inklusive, ganz ohne individuelle Entwicklung.
Ein Plattform-Detail lohnt sich zu kennen, weil es alarmierend aussieht und es nicht ist. Squarespaces Standard-robots.txt nennt inzwischen KI-Crawler einzeln, darunter GPTBot, ClaudeBot, anthropic-ai, CCBot, Google-Extended und Applebot-Extended. Sie werden genannt, um dieselbe administrative Disallow-Liste anzuwenden, die für alle gilt, mit Pfaden wie /config und /api/. Sie blockiert damit nicht den Zugriff auf Ihre Inhalte.
6. Hans im Glück, für das länderübergreifende Preisproblem
menu.hansimglueck-burgergrill.de ist das einzige nicht englischsprachige Beispiel in unserer Auswahl, und es löst ein Problem, das die meisten Gruppen falsch angehen. Die Preise unterscheiden sich zwischen Deutschland, Österreich, der Schweiz und den Niederlanden, deshalb lässt die gemeinsame Speisekarte den Preis komplett weg, statt die Zahl eines Landes zu veröffentlichen und alle anderen in die Irre zu führen. Was sie veröffentlicht, ist großzügig: Gerichtnamen, Zutatenbeschreibungen, Ernährungs-Tags und ein vollständiges Nährwertfeld pro Artikel, alles als Text, auf Deutsch.
Wenn Sie über mehrere Preiszonen hinweg operieren, ist das das ehrliche Muster. Veröffentlichen Sie alles, was überall zutrifft, und lassen Sie das eine Feld weg, das es nicht tut.
7. L'Enclume, für die Richtung, in die sich robots.txt entwickelt
lenclume.co.uk/sample-menu veröffentlicht eine vollständige Gangliste und fünf Stufen der Weinbegleitung als Text. Zwei Dinge machen es studierenswert. Ihre strukturierten Daten verweisen über eine @id-Referenz auf eine Gruppen-Identität auf einer separaten Domain, eine saubere Art für eine Gruppe mit mehreren Standorten, ihre Standorte zu verknüpfen, ohne das gesamte Organisationsobjekt auf jeder Website zu wiederholen.
Das zweite ist, dass ihre robots.txt nicht mehr wie eine robots.txt aussieht. Sie nutzt Cloudflares neueres Content-Signals-Format, eine Grundsatzerklärung zu den Verwendungszwecken search, ai-input und ai-train statt einer Liste von Allow- und Disallow-Zeilen. Tatsächlich ist in der Datei kein Signal gesetzt, was nach der eigenen Logik des Formats bedeutet, dass die Erlaubnis weder erteilt noch verweigert wird. Wenn Sie Ihre robots.txt nicht mehr angeschaut haben, seit Ihr Hoster sie zuletzt aktualisiert hat, schauen Sie jetzt nach.
Zwei Speisekarten, die gerade unlesbar sind
Beides sind gute Restaurants, die eine ganz gewöhnliche Entscheidung treffen. Das ist der Punkt: Das ist kein Kompetenzproblem, es ist ein unsichtbares.
Noble Rot in der Lamb's Conduit Street ist eine Weinbar mit einer ernstzunehmenden Liste. Die Seite trägt rund 1.600 Zeichen lesbaren Text und überhaupt keine Preise. Speisekarte und Weinkarte sind beide PDF-Downloads, allein die Weinkarte kommt auf 580 KB. Eine Weinkarte ist die dichtestmögliche Quelle für Erzeuger-, Regions- und Jahrgangsvokabular, und nichts davon steht auf der Webseite.
Tim Raue in Berlin trägt zwei Michelin-Sterne. Seine Speisekartenseite beschreibt die Menüs in Fließtext und enthält keine Gerichte und keine Preise; die tatsächlichen Menüs stecken in PDFs unter /wp-content/uploads/menu/DE/. Einer der Menü-Links auf dieser Seite ist zudem fehlerhaft, er zeigt auf http://wp-content/uploads/..., was ins Leere führt. Berlin ist ein Markt, in dem die städtische Tourismusorganisation die mit Abstand meistzitierte Quelle in KI-Antworten zum Essen ist, was die eigene unlesbare Speisekarte eines Restaurants doppelt teuer macht.
Helfen strukturierte Daten wirklich?
Weniger, als man Ihnen erzählt hat, und es lohnt sich, präzise zu sein, denn genau hier übertreiben die meisten Ratschläge zu Speisekarten.
Googles Search Gallery, die kanonische Liste jedes strukturierten Datentyps, den Google für Rich-Results unterstützt, enthält kein eigenes Feature für Menu, Restaurant oder FoodEstablishment [7]. Googles Local-Business-Dokumentation führt menu als empfohlene Eigenschaft vom Typ URL, beschrieben als die vollständig qualifizierte URL der Speisekarte; das Wort hasMenu taucht auf dieser Seite überhaupt nicht auf [8]. Der verschachtelte Graph aus Menu, MenuSection und MenuItem ist also gültiges schema.org-Vokabular, das Sie korrekt veröffentlichen dürfen, aber Google dokumentiert nirgends, dass es das konsumiert oder als eigenes Rich-Result belohnt.
Ob die Assistenten es lesen, ist noch dünner belegt. Wir fanden keine Primärquelle von OpenAI, Anthropic oder Perplexity, die bestätigt, dass ihre Crawler schema.org-Markup parsen oder gewichten. Das ist kein Beweis, dass sie es ignorieren. Es ist ein Mangel an Belegen, den die Branche routinemäßig mit erfundenen Zahlen füllt.
Die vernünftige Position: Markieren Sie Ihre Speisekarte, weil es Ihre Fakten explizit macht und einmalig wenig kostet, und weil die Local-Business-Menü-URL tatsächlich dokumentiert ist. Erwarten Sie nicht, dass sie lesbaren Text ersetzt. Core by Clare Smyth hat davon nichts, und eine perfekt lesbare Speisekarte. Das ist das bessere Versagen, das man haben kann.
Eine Korrektheitsfalle, falls Sie es umsetzen. Die Eigenschaft suitableForDiet akzeptiert nur Werte aus der RestrictedDiet-Enumeration, und das sind genau elf: DiabeticDiet, GlutenFreeDiet, HalalDiet, HinduDiet, KosherDiet, LowCalorieDiet, LowFatDiet, LowLactoseDiet, LowSaltDiet, VeganDiet und VegetarianDiet [9]. Es gibt kein DairyFreeDiet und kein NutFreeDiet. Allergeninformationen müssen als Text geschrieben werden, was Sie ohnehin tun sollten.
Die Speisekarten-Statistiken, die es nicht gibt
Bei der Recherche zu diesem Artikel haben wir versucht, die Zahlen zu belegen, die in Speisekarten- und GEO-Marketinginhalten kursieren. Mehrere davon halten der Prüfung nicht stand.
| Zitierte Behauptung | Was wir gefunden haben |
|---|---|
| „GPT-4 geht mit strukturierten Daten von 16 % auf 54 % korrekte Antworten hoch" | Keine solche Studie auffindbar. Vage einer Quelle zugeschrieben, die sie offenbar nicht enthält. |
| „Strukturierte Daten bringen Ihnen 3,2-mal häufiger ein Zitat" | Zurückverfolgt zu einem einzigen Medium-Beitrag, der eine Analyse von 73 Websites beschreibt, ohne Methode, ohne Datensatz und ohne überprüfbare Referenzen, danach andernorts als „aktuelle Forschung" weiterzitiert. |
| „Speisekarten mit strukturierten Daten erscheinen 30 % häufiger in KI-Antworten" | Nur Anbieter-Blog-Inhalt, keine Stichprobe, keine Methode. |
| „Über 60 % der Restaurant-Websites nutzen PDF-Speisekarten" | Weit verbreitet wiederholt, keine Crawl-Studie oder Umfrage dahinter, die wir finden konnten. |
| „85,73 % der deutschen Gäste bevorzugen gedruckte Speisekarten" | Einer namentlich genannten Umfrage aus 2021 zugeschrieben. Wir haben die Umfrageseite direkt abgerufen, und die Zahl taucht dort nicht auf. |
Wir behaupten nicht, dass diese Zahlen alle falsch sind. Wir sagen, dass niemand gezeigt hat, dass sie stimmen, und dass ein Restaurant kein Geld auf Basis einer Zahl ausgeben sollte, die durch zwei Blogbeiträge gewaschen wurde. Das Argument für lesbare Speisekarten braucht diese Zahlen nicht. Es beruht auf einem Mechanismus, den Sie selbst mit einem einzigen Befehl überprüfen können.
Was kann Ihre Plattform tatsächlich leisten?
Die ehrliche Zusammenfassung, geprüft gegen die aktuelle Live-Dokumentation jedes Anbieters im September 2026. Die entscheidende Unterscheidung ist nicht, ob eine Plattform eine Speisekarte anzeigen kann, sondern ob sie crawlbaren Text plus gültige strukturierte Daten ausgeben kann, die eine technisch nicht versierte Person aktuell halten kann.
| Plattform | Lesbarer Speisekartentext | Strukturierte Daten für die Speisekarte | Die Falle |
|---|---|---|---|
| Squarespace | Ja, natives Menu-Block auf jedem kostenpflichtigen Plan | Nur über Code Injection, das mindestens Core erfordert | Squarespace gibt auf jeder Seite eigenes Website-, Organization- und Local-Business-Schema aus, das mit einem zusätzlich eingefügten Restaurant-Schema kollidieren kann, und der Menu-Block speist Ihr injiziertes Schema nicht, sodass beide still auseinanderdriften |
| Webflow | Ja, CMS Collections | Ja, gebunden an CMS-Felder im Collection Template | Feld- und Zeichenobergrenzen beißen bei einer umfangreichen Speisekarte spät, und jede zusätzliche Sprachversion braucht ihr eigenes Schema |
| WordPress | Ja | Nicht über Yoast oder Rank Math, die vor Menu-Schema haltmachen | Der verbreitete Rat, ein SEO-Plugin zu installieren, deckt das überhaupt nicht ab |
| Wix | Ja, über die App Restaurants Menus | Unbestätigt, die Anbieterdokumentation sagt nicht, was der Schalter für strukturierte Daten ausgibt | Sie können die Ausgabe nicht anhand der Dokumentation prüfen, Sie müssen die Live-Seite testen |
| Shopify | Ja, über Metaobjects | Ja, handgeschrieben im Theme | Gerichte als Produkte zu modellieren zieht Checkout-Mechanik mit sich, die Sie nicht wollen |
| Next.js und Ähnliches | Ja, vorgerendert | Ja, generiert aus derselben Quelle | Braucht ein CMS obendrauf, bevor ein Marketing-Manager es bearbeiten kann |
| Toast, Popmenu, Flipdish, UpMenu | Ja, auf Ihrer eigenen Domain | Variiert je nach Anbieter | Die Domain-Anbindung ist nicht automatisch, und eine nicht angebundene Seite ist unsichtbar |
| Reservierungs- und Bestell-Widgets | Nein | Nein | Ein eingebettetes Buchungs- oder Bestell-Widget ist keine Speisekartenseite, und iframed Anbieterinhalt trägt oft ein eigenes noindex |
Zwei übergreifende Punkte. Erstens: Ein iFrame ist keine Abkürzung. Google kann iframed Inhalt manchmal der übergeordneten Seite zuschreiben, aber das bricht, wenn die eingebettete URL ein noindex trägt, was Anbieter-Widgets häufig tun, und es hilft nicht bei Assistenten, die das Skript ohnehin nie ausführen. Zweitens: Eine Speisekarte, die auf der Subdomain eines Anbieters liegt statt auf Ihrer eigenen Domain, zahlt wahrscheinlich einen Zitationsaufschlag. Der einzige belegte Beleg, den wir gefunden haben, ist klein und branchenübergreifend statt restaurantspezifisch, behandeln Sie ihn also als Richtungsindikator, aber er zeigt in dieselbe Richtung wie alles andere: Veröffentlichen Sie auf Ihrer eigenen Domain.
Der stärkste Einwand, und die Antwort
Ein Restaurantbetreiber im echten Alltag hat eine gute Erwiderung auf all das. Das PDF ist die gedruckte Speisekarte. Ein Designer liefert jede Saison eine Datei, sie geht zur Druckerei und sie geht auf die Website, und eine zweite strukturierte Version zu pflegen ist echte Arbeit, für die niemand im Haus Zeit hat.
Dieser Einwand ist richtig, und jeder Ratschlag, der ihn ignoriert, ist ein Ratschlag für das Restaurant von jemand anderem. Die Antwort ist nicht, zwei Systeme zu pflegen. Sie ist, umzudrehen, welches davon die Quelle ist. Halten Sie die Speisekarte als strukturierte Daten und generieren Sie beide Ausgaben daraus: die Webseite und die druckfertige Datei. Der Designer behält sein Layout, die Küche behält ihren Ablauf, und der Text wird als Nebeneffekt abrufbar statt als lästige Pflicht. Das ist ein Bau-Projekt, und das ist das Thema unserer Schritt-für-Schritt-Anleitung zum Bau einer dynamischen Speisekartenseite.
Genau das übernehmen wir für Restaurants im Rahmen der monatlichen Gebühr statt als separates Angebot, für jeden Standort und jede Speisekarte. Wenn Ihre Speisekarten heute PDFs sind, das ist die Arbeit, die wir übernehmen.
Quellen
- OpenAI, "Overview of OpenAI Crawlers", https://developers.openai.com/api/docs/bots, geprüft 2026-09-05.
- Perplexity, "Perplexity Crawlers", https://docs.perplexity.ai/docs/resources/perplexity-crawlers, geprüft 2026-09-05.
- Anthropic, "Does Anthropic crawl data from the web, and how can site owners block the crawler?", https://support.claude.com/en/articles/8896518-does-anthropic-crawl-data-from-the-web-and-how-can-site-owners-block-the-crawler, aktualisiert 7 April 2026, geprüft 2026-09-05.
- Passionfruit, "JavaScript Rendering and AI Crawlers: Can LLMs Read Your SPA?", https://www.getpassionfruit.com/blog/javascript-rendering-and-ai-crawlers-can-llms-read-your-spa, 2026, geprüft 2026-09-05. Crawl-Messung eines Dritten, keine Aussage eines Anbieters.
- Tripathi, Odapally, Das, Allu und Ahmed, "Vision-Guided Chunking Is All You Need: Enhancing RAG with Multimodal Document Understanding", arXiv:2506.16035, 19 June 2025, https://arxiv.org/abs/2506.16035, geprüft 2026-09-05.
- "Synthetic Data Powers Product Retrieval for Long-tail Knowledge-Intensive Queries in E-commerce Search", arXiv:2602.23620, https://arxiv.org/html/2602.23620v1, geprüft 2026-09-05. Allgemeine Retrieval-Forschung, nicht speisekartenspezifisch.
- Google Search Central, "Structured Data Markup that Google Search Supports", https://developers.google.com/search/docs/appearance/structured-data/search-gallery, zuletzt aktualisiert 15 June 2026, geprüft 2026-09-05.
- Google Search Central, "Local Business (LocalBusiness) Structured Data", https://developers.google.com/search/docs/appearance/structured-data/local-business, zuletzt aktualisiert 10 December 2025, geprüft 2026-09-05.
- Schema.org, "RestrictedDiet" und "suitableForDiet", https://schema.org/RestrictedDiet, geprüft 2026-09-05.
Squarespace
Webflow
Sanity
Shopify
HubSpot