Menü-Strukturdaten-Audit: Schema.org Restaurant-Eigenschaften und Rich-Result-Fähigkeit prüfen

Warum erscheint mein Menü-Markup nicht als Rich Result?

Die kurze Antwort: In den meisten Fällen liegt es nicht an einem einzelnen fehlenden Feld, sondern an einer Kombination unvollständiger oder inkonsistenter Schema.org-Eigenschaften innerhalb des Restaurant-Typs. Bevor Sie eine Neuindexierung anfordern, sollten Sie systematisch prüfen, ob die menu-Eigenschaft korrekt auf ein Menu-Objekt verweist, ob hasMenuItem tatsächlich MenuItem- oder MenuSection-Einträge enthält, ob Preisangaben im offers-Block strukturiert hinterlegt sind und ob optionale Felder wie suitableForDiet nur dort auftauchen, wo sie belegbar sind. Ein Audit nach festem Ablauf ist zuverlässiger als das wiederholte Anstoßen einer Neuindexierung in der Hoffnung, dass sich etwas von selbst löst.

Das MENU-Prüfraster als Arbeitsrahmen

Für ein wiederholbares Audit hat sich ein vierstufiges Raster bewährt, das sich als Akronym merken lässt: MENU – Markup-Grundstruktur, Einzelposten, Nährwert- und Diätangaben, Umsetzung prüfen. Jede Stufe entspricht einer Gruppe von Schema.org-Eigenschaften, die gemeinsam geprüft werden sollten, bevor man zur nächsten übergeht.

M – Markup-Grundstruktur

• Ist der Seitentyp korrekt als Restaurant (oder ein passender Subtyp) ausgezeichnet?
• Verweist die menu-Eigenschaft auf ein eigenständiges Menu-Objekt oder zumindest auf eine URL mit der Speisekarte?
• Ist das Menu-Objekt eindeutig einem einzigen Restaurant-Eintrag zugeordnet, nicht mehreren Standorten gleichzeitig?

E – Einzelposten

• Nutzt das Menu-Objekt hasMenuItem, um auf MenuSection- oder direkt auf MenuItem-Einträge zu verweisen?
• Trägt jedes MenuItem einen eigenen name-Wert, der dem tatsächlichen Gerichtsnamen entspricht?
• Enthält jedes MenuItem, wo ein Preis existiert, einen offers-Block mit price und priceCurrency?
• Stimmen die im Markup hinterlegten Preise mit den auf der Karte oder Website sichtbaren Preisen überein?

N – Nährwert- und Diätangaben

• Wird suitableForDiet nur bei Gerichten verwendet, für die eine tatsächlich geprüfte Einordnung existiert?
• Stammen Diät-Zuordnungen aus einer verlässlichen internen Quelle, nicht aus einer Vermutung?
• Werden Zutatenänderungen zeitnah nachgezogen, damit veraltete Diät-Kennzeichnungen nicht bestehen bleiben?

U – Umsetzung prüfen

• Wurde das Markup mit einem strukturierten Daten-Testwerkzeug validiert, nicht nur visuell gegengelesen?
• Wurden Warnungen und Fehler aus der Validierung einzeln abgearbeitet, nicht pauschal ignoriert?
• Erst nach bestandener Validierung wird eine Neuindexierung angestoßen, nicht als erster Reflex.

Checkliste in Tabellenform

Grenzen dieses Audits

Ein bestandenes Audit garantiert kein Rich Result. Ob und wie eine Suchmaschine strukturierte Daten in ein sichtbares Feature übersetzt, hängt von den eigenen Eligibility-Regeln dieser Plattform ab, die sich ändern können und die Betreiber nicht steuern. Strukturierte Daten drücken lediglich Fakten in einem maschinenlesbaren Format aus, sie erzwingen keine bestimmte Darstellung in Suchergebnissen. Ebenso wenig lässt sich aus diesem Audit eine Aussage über Ranking-Verbesserungen, Traffic-Zuwächse oder eine geringere Zahl von No-Shows ableiten, dafür fehlen belastbare, restaurantspezifische Daten. Auch juristische Fragen rund um Diät- oder Allergenkennzeichnung werden hier nicht beantwortet, das Audit prüft ausschließlich technische Markup-Korrektheit, nicht die rechtliche Tragweite einer Angabe.

Messung: Wie Sie den Fortschritt nachvollziehen

Nach Abschluss des MENU-Prüfrasters lässt sich der technische Zustand des Markups mit einem strukturierten Daten-Testwerkzeug objektiv festhalten, indem Sie Fehler- und Warnmeldungen vor und nach der Überarbeitung dokumentieren. Ergänzend kann die Search-Console-Property der Website Hinweise geben, ob strukturierte Daten überhaupt erkannt wurden, wobei ein zeitlicher Verzug zwischen Aktualisierung und Erfassung normal ist. Sinnvoll ist ein einfaches internes Protokoll:

1. Datum der Markup-Änderung festhalten.
2. Validierungsergebnis (Anzahl Fehler, Anzahl Warnungen) notieren.
3. Er

   Schritt-für-Schritt-Ablauf vor der Neuindexierung

   Ein Audit ist nur dann wiederholbar, wenn er als fester Ablauf und nicht als Ad-hoc-Kontrolle durchgeführt wird. Der folgende Ablauf ergänzt das MENU-Raster um die konkrete Reihenfolge der Arbeitsschritte, bevor überhaupt eine Neuindexierung angestoßen wird.

   1. Aktuellen JSON-LD- oder Microdata-Block der Menüseite vollständig extrahieren und in einer separaten Datei sichern, bevor Änderungen vorgenommen werden.
   2. Jede Eigenschaft einzeln gegen das Schema.org-Vokabular für Restaurant, Menu, MenuSection, MenuItem und Offer abgleichen, nicht nur stichprobenartig.
   3. Abweichungen dokumentieren: fehlende Pflichtfelder, veraltete Werte, doppelte oder leere Einträge.
   4. Korrekturen am Markup vornehmen und dabei nur Eigenschaften ergänzen, für die tatsächlich geprüfte Daten vorliegen.
   5. Erneute Validierung mit einem strukturierten Daten-Testwerkzeug durchführen und das Ergebnis mit dem Ausgangszustand vergleichen.
   6. Erst nach fehlerfreier Validierung die Neuindexierung über den dafür vorgesehenen Kanal der jeweiligen Suchplattform anstoßen.
   7. Ergebnis nach einigen Tagen erneut prüfen, da Erfassung und Darstellung zeitlich versetzt erfolgen können.

   Edge Cases, die im Standard-Audit häufig übersehen werden

   Mehrsprachige Speisekarten

   Wenn eine Speisekarte in mehreren Sprachversionen existiert, reicht es nicht, dieselbe JSON-LD-Struktur mit übersetzten Textwerten auf allen Sprachvarianten einzusetzen. Prüfen Sie, ob jede Sprachversion tatsächlich mit dem sichtbaren, in dieser Sprache angezeigten Menüinhalt übereinstimmt, statt auf allen Varianten die Werte einer einzigen Ausgangssprache zu wiederholen.

   Saisonale oder wechselnde Karten

   Wird die Speisekarte täglich oder wöchentlich angepasst, entsteht ein erhöhtes Risiko, dass MenuItem-Einträge im Markup noch Gerichte enthalten, die auf der sichtbaren Seite bereits ersetzt wurden. Ein Audit, das nur einmalig durchgeführt wird, deckt dieses Problem nicht ab; hier ist eine wiederkehrende Prüfroutine notwendig, deren Intervall sich an der tatsächlichen Änderungsfrequenz der Karte orientiert.

   Mehrere Standorte mit gemeinsamer Vorlage

   Bei Restaurantketten oder Filialbetrieben wird das Markup oft aus einer gemeinsamen Vorlage generiert. Prüfen Sie gezielt, ob standortspezifische Abweichungen bei Preisen, Verfügbarkeit einzelner Gerichte oder Diät-Kennzeichnungen korrekt in die jeweilige Standortseite einfließen, statt eine identische Struktur über alle Standorte hinweg zu übernehmen.

   Menüdaten aus Drittanbieter-Bestellsystemen

   Wird die Speisekarte über ein eingebettetes Bestellsystem eines Drittanbieters dargestellt, etwa per iframe, sollten Sie prüfen, ob das strukturierte Markup tatsächlich im crawlbaren HTML der eigenen Seite liegt und nicht ausschließlich innerhalb des eingebetteten Fremdinhalts, der möglicherweise separat oder gar nicht erfasst wird.

   Nur als PDF hinterlegte Speisekarten

   Verweist die menu-Eigenschaft ausschließlich auf eine PDF-Datei, fehlen in der Regel die einzelnen MenuItem- und Offer-Strukturen, die für eine detaillierte Darstellung einzelner Gerichte notwendig wären. Ein PDF-Link allein erfüllt die Eigenschaft menu formal, ersetzt aber keine strukturierte Auflistung einzelner Posten.

   Messkadenz über mehrere Wochen

   Eine einmalige Vorher-Nachher-Messung zeigt nur, ob die Validierung unmittelbar nach der Änderung fehlerfrei ist. Um Rückschlüsse auf die Stabilität des Markups zu ziehen, empfiehlt sich eine wiederkehrende Prüfung über mehrere Wochen, bei der folgende Punkte separat festgehalten werden:

   Messpunkt	Was dokumentiert wird
   Validierungsstatus	Fehler- und Warnanzahl je Prüfzeitpunkt
   Erfassungsstatus	Ob strukturierte Daten laut Search-Console-Property erkannt wurden
   Konsistenz	Ob Preise und Gerichtsnamen im Markup weiterhin mit der sichtbaren Karte übereinstimmen
   Änderungsanlass	Ob zwischenzeitliche Karten- oder Preisänderungen im Markup nachgezogen wurden

   Diese Tabelle ersetzt keine Ranking- oder Traffic-Auswertung; sie dokumentiert ausschließlich den technischen Zustand des Markups über Zeit.

   Grenzen der Messung selbst

   Auch eine sorgfältig geführte Messkadenz kann nicht zeigen, ob eine bestimmte Darstellung in Suchergebnissen ursächlich auf die Markup-Korrektur zurückgeht. Suchplattformen ändern ihre eigenen Eligibility-Kriterien unabhängig vom Betreiber, testen Rich-Result-Features teils nur für einen Teil der indexierten Seiten und können Darstellungsentscheidungen jederzeit anpassen. Eine Korrelation zwischen Markup-Verbesserung und späterem Erscheinen eines Rich Results ist daher kein Nachweis eines ursächlichen Zusammenhangs. Ebenso wenig lässt sich aus wiederholten Validierungsdurchläufen eine Aussage über Nutzerverhalten, Buchungsaufkommen oder eine veränderte Zahl von No-Shows ableiten, da hierfür keine belastbaren, restaurantspezifischen Daten vorliegen.

   Einordnung im Produktkontext

   Die vorstehenden Schritte, Tabellen und Prüfpunkte sind allgemeine, werkzeugunabhängige Empfehlungen zur Pflege von Schema.org-Markup und unabhängig von einer bestimmten Software anwendbar. ChefNet entwickelt Produkte im Bereich Restaurant-Discovery und -Betrieb; welche Funktionen zur Markup-Erstellung, Validierung oder Unterstützung bei Neuindexierungs-Anfragen davon aktuell tatsächlich verfügbar sind, sollten Betreiber direkt bei ChefNet erfragen, da sich der Funktionsumfang solcher Produkte im Zeitverlauf ändern kann.

   Primärquellen

   • Schema.org Restaurant

   FAQ

   Garantiert Menü-Markup nach Schema.org ein Rich Result?

   Nein. Strukturierte Daten drücken Fakten über Ihre Speisekarte in einem maschinenlesbaren Vokabular aus, ob ein Rich Result tatsächlich erscheint, entscheidet die jeweilige Suchmaschine anhand eigener Regeln, auf die Betreiber keinen Einfluss haben. Korrektes Markup beseitigt lediglich eine technische Hürde, es verpflichtet keine Plattform zur Darstellung eines bestimmten Features.

   Welche Schema.org-Eigenschaft listet einzelne Gerichte auf?

   Die menu-Eigenschaft des Restaurant-Typs kann auf ein Menu-Objekt verweisen, das wiederum über hasMenuItem MenuSection- oder MenuItem-Einträge listet. Jedes MenuItem sollte einen eigenen Namen sowie, wo zutreffend, einen offers-Block mit price und priceCurrency tragen, gemäß dem Vokabular unter schema.org/Restaurant.

   Ist suitableForDiet für jedes Gericht Pflicht?

   Nein, es handelt sich um optionales Vokabular zur Beschreibung von Ernährungseinschränkungen wie vegetarisch oder glutenfrei über die RestrictedDiet-Aufzählung. Betreiber sollten es nur dort einsetzen, wo tatsächlich geprüfte und zutreffende Information vorliegt, da Diät-Angaben über die reine Markup-Korrektheit hinaus rechtliche und sicherheitsrelevante Bedeutung haben können.

   Redaktioneller Hinweis: ChefNet veröffentlicht diesen Leitfaden und entwickelt Produkte für Restaurantsuche und -betrieb. Allgemeine Betriebshinweise sind von Produktaussagen getrennt. Funktionen können sich im Verlauf der Pilotphase ändern. Veröffentlicht 2026-08-02.