Krótka odpowiedź: zanim zgłosisz reindeksowanie strony z menu, sprawdź osobno każdą właściwość Schema.org Restaurant powiązaną z menu — menu, hasMenuItem, name, offers z price i priceCurrency oraz opcjonalnie suitableForDiet — pod kątem obecności, poprawnego formatu i zgodności z faktyczną ofertą lokalu. Braki lub błędy w tych polach są częstą przyczyną tego, że wyszukiwarka nie generuje wyniku rozszerzonego, nawet jeśli sam znacznik JSON-LD został poprawnie umieszczony na stronie.
Dlaczego sam znacznik JSON-LD nie wystarczy
Operatorzy restauracji często zakładają, że umieszczenie bloku danych strukturalnych na stronie automatycznie skutkuje pojawieniem się rozszerzonego wyniku z cenami dań czy ikonami diety. Schema.org dostarcza słownictwo — zestaw właściwości, którymi można opisać fakty o menu — ale nie decyduje o tym, jak konkretna wyszukiwarka wykorzysta te dane. Zgodnie z dokumentacją schema.org/Restaurant, typ Restaurant dziedziczy właściwości po LocalBusiness i dodaje pole menu, które może wskazywać na obiekt typu Menu lub bezpośrednio na adres URL karty dań.
Rama audytu: pięć właściwości do sprawdzenia
Poniższa rama porządkuje audyt wokół pięciu elementów, które najczęściej decydują o tym, czy oznaczone menu jest kompletne i wewnętrznie spójne. Nie jest to lista wymagań narzucanych przez jedną platformę — to zestaw punktów kontrolnych wynikających ze struktury słownika Schema.org.
| Właściwość | Co sprawdzić | Typowy błąd |
|---|---|---|
| menu | Czy pole wskazuje na obiekt Menu lub prawidłowy URL karty dań, a nie na pustą wartość lub stronę główną | menu wskazuje na stronę kontaktową zamiast na faktyczną kartę dań |
| hasMenuItem | Czy każda sekcja Menu zawiera listę MenuItem lub MenuSection odpowiadającą realnym pozycjom w karcie | Sekcja istnieje w znaczniku, ale nie zawiera żadnych pozycji hasMenuItem |
| name (w MenuItem) | Czy nazwa dania w znaczniku jest identyczna z nazwą widoczną na stronie | Nazwa w znaczniku różni się od nazwy wyświetlanej użytkownikowi |
| offers / price / priceCurrency | Czy cena jest liczbą bez symbolu waluty, a priceCurrency podane w formacie ISO 4217 (np. PLN) | Cena zawiera symbol złotówki zamiast liczby, brak priceCurrency |
| suitableForDiet | Czy wartość jest stosowana tylko przy potwierdzonej, aktualnej informacji o diecie | Etykieta „wegańskie” dodana masowo bez weryfikacji składu |
Jak przeprowadzić audyt krok po kroku
- Wyeksportuj aktualny blok JSON-LD ze strony menu i porównaj go linia po linii z realną kartą dań — nie z pamięci, tylko z dokumentem źródłowym.
- Dla każdej pozycji w menu sprawdź, czy istnieje odpowiadający jej obiekt MenuItem w znaczniku.
- Zweryfikuj, czy każda cena w offers jest zapisana jako liczba, a waluta podana osobno w priceCurrency.
- Jeśli używasz suitableForDiet, potwierdź źródło informacji dietetycznej (np. recepturę lub deklarację dostawcy) przed pozostawieniem etykiety.
- Dopiero po usunięciu rozbieżności zgłoś stronę do ponownego zaindeksowania w narzędziach wyszukiwarki, których używasz.
Ograniczenia tego podejścia
Warto jasno oddzielić to, co audyt danych strukturalnych może wykazać, od tego, czego nie gwarantuje. Poprawność znaczników nie jest tożsama z decyzją wyszukiwarki o wyświetleniu rozszerzonego wyniku — każda platforma stosuje własne, zmienne w czasie kryteria kwalifikacji, których operator restauracji nie kontroluje i które nie są w pełni publiczne. Audyt opisany w tym artykule dotyczy wyłącznie tradycyjnych wyników wyszukiwania opartych na Schema.org; nie odnosi się do czytelności treści dla systemów generujących odpowiedzi oparte na AI ani do zgodności pól LocalBusiness niezwiązanych z menu — to są odrębne zagadnienia wymagające osobnej analizy. Właściwości Schema.org, w tym suitableForDiet, należy traktować jako dostępne słownictwo do opisu faktów, a nie jako listę obowiązkowych pól, które trzeba wypełnić w każdej sytuacji.
Pomiar: co obserwować po audycie
Po wprowadzeniu poprawek warto zweryfikować efekt techniczny, nie zaś zakładać efekt widoczności. Konkretne kroki pomiarowe:
- Uruchom walidator znaczników strukturalnych i sprawdź, czy błędy oraz ostrzeżenia dotyczące właściwości menu, hasMenuItem i offers zniknęły.
- W narzędziach dla webmasterów danej wyszukiwarki sprawdź status indeksowania strony menu po zgłoszeniu jej do ponownego przeszukania.
- Zapisz datę audytu i listę wprowadzonych poprawek, aby przy kolejnej aktualizacji karty dań móc szybko zlokalizować, które pozycje wymagają odświeżenia w znaczniku.
- Nie traktuj samego pojawienia się lub braku wyniku rozszerzonego jako jedynego miernika poprawności audytu — brak widocznego efektu w wynikach wyszukiwania nie oznacza automatycznie błędu w znaczniku, ponieważ decyzja o wyświetleniu leży po stronie platformy.
Gdzie w tym procesie może pojawić się ChefNet
ChefNet rozwija produkty związane z odkrywalnością restauracji i operacjami gastronomicznymi, w tym narzędzia dotyczące danych o menu. Ponieważ zakres funkcji rozwijanych przez ChefNet zmienia się w czasie, operatorzy powinni samodzielnie zweryfikować, które konkretne możliwości — na przykład wsparcie przy generowaniu lub audycie znaczników menu — są obecnie dostępne w danej wersji produktu, zamiast zakładać ich istnienie na podstawie ogólnego opisu kategorii.
Podsumowanie praktyczne
Audyt danych strukturalnych menu ma sens jako powtarzalna procedura, wykonywana za każdym razem, gdy karta dań się zmienia lub gdy planowane jest zgłoszenie strony do ponownego indeksowania. Skupienie się na pięciu właściwościach — menu, hasMenuItem, name, offers/price/priceCurrency oraz suitableForDiet — pozwala odróżnić błędy techniczne możliwe do naprawienia od decyzji wyszukiwarki, na którą operator nie ma bezpośredniego wpływu.
Przypadki brzegowe pomijane przez podstawowy audyt
Rama pięciu właściwości opisana wcześniej zakłada menu jednojęzyczne, stałe i jednolokalizacyjne. W praktyce operatorzy spotykają sytuacje wymagające dodatkowej decyzji przed zgłoszeniem reindeksowania.
Menu w wielu wersjach językowych
Jeśli karta dań istnieje w kilku językach pod osobnymi adresami URL, każdy z nich powinien mieć własny blok danych strukturalnych z polem menu wskazującym na właściwą wersję — nie jeden wspólny znacznik powielony bez zmian. Schema.org nie definiuje mechanizmu automatycznego łączenia wersji językowych menu; to zależy od struktury samej strony.
Pozycje sezonowe i czasowo niedostępne
Danie obecne w hasMenuItem, ale aktualnie niedostępne w lokalu, powinno zostać usunięte ze znacznika lub oznaczone w sposób odzwierciedlający realną dostępność, jeśli strona faktycznie to komunikuje. Pozostawienie w danych strukturalnych pozycji, której nie ma w karcie fizycznej lub cyfrowej, jest tym samym rodzajem niespójności co błędna nazwa dania omówiona wcześniej.
Ceny zmienne lub „na zapytanie”
Gdy cena dania zależy od wagi, dodatków lub jest ustalana indywidualnie, wpisanie sztywnej wartości liczbowej w price wprowadza rozbieżność z rzeczywistością. W takich przypadkach należy albo pominąć pole offers dla tej pozycji, albo opisywać w danych strukturalnych wyłącznie dania o stałej cenie, zamiast wpisywać przybliżoną lub nieaktualną liczbę.
Zagnieżdżone sekcje menu
Karty dań podzielone na sekcje i podsekcje wymagają sprawdzenia, czy hasMenuItem jest przypisane na właściwym poziomie zagnieżdżenia Menu/MenuSection, a nie tylko na poziomie głównym. Spłaszczenie hierarchii w znaczniku, podczas gdy strona prezentuje strukturę wielopoziomową, jest odrębnym typem błędu od tych ujętych w podstawowej tabeli pięciu właściwości.
Workflow wdrożeniowy: kiedy powtarzać audyt
Audyt nie jest jednorazowym zdarzeniem. Poniższe wyzwalacze pomagają zdecydować, kiedy konieczna jest jego powtórka przed kolejnym zgłoszeniem do indeksowania.
- Zmiana jakiejkolwiek ceny w karcie dań — nawet pojedynczej pozycji.
- Dodanie lub usunięcie sekcji menu, np. wprowadzenie menu śniadaniowego.
- Zmiana dostawcy składników wpływająca na deklaracje w suitableForDiet.
- Migracja strony na nową platformę lub zmiana adresu URL karty dań.
- Otrzymanie ostrzeżenia w narzędziach dla webmasterów dotyczącego typu Restaurant lub Menu.
Każdy z tych wyzwalaczy powinien uruchamiać cały pięcioetapowy proces opisany w głównej części artykułu, a nie tylko punktową poprawkę jednego pola.
Ograniczenia audytu w praktyce operacyjnej
Nawet w pełni poprawny znacznik nie eliminuje ryzyka rozbieżności powstających poza kontrolą osoby odpowiedzialnej za dane strukturalne — na przykład gdy personel sali zmienia cenę w systemie POS bez informowania osoby zarządzającej stroną. Audyt danych strukturalnych obejmuje wyłącznie zgodność między znacznikiem a treścią widoczną na stronie internetowej; nie obejmuje zgodności między stroną a rzeczywistą ofertą w lokalu, jeśli te dwa źródła nie są aktualizowane w tym samym cyklu. Ustalenie, kto aktualizuje cenę na stronie, a kto w znaczniku, jest elementem organizacyjnym wykraczającym poza sam proces techniczny.
Rozszerzona lista kontrolna: przypadki szczególne
| Sytuacja | Zalecane działanie |
|---|---|
| Menu w dwóch językach na osobnych URL | Osobny blok danych strukturalnych dla każdej wersji, pole menu wskazujące właściwy adres |
| Danie sezonowe czasowo niedostępne | Usunięcie z hasMenuItem do czasu przywrócenia pozycji w realnej karcie |
| Cena zależna od wagi lub dodatków | Pominięcie offers dla danej pozycji zamiast wpisania przybliżonej liczby |
| Wielopoziomowa struktura sekcji | Zachowanie hierarchii Menu/MenuSection zgodnej z prezentacją na stronie |
| Rozbieżność między systemem POS a stroną | Ustalenie jednego źródła prawdy i cyklu aktualizacji przed kolejnym audytem |
Źródła pierwotne
FAQ
Czy dodanie znaczników menu Schema.org gwarantuje pojawienie się wyniku rozszerzonego?
Nie. Dane strukturalne opisują fakty o menu w formacie zrozumiałym dla maszyn, ale to, czy dana wyszukiwarka wyświetli wynik rozszerzony, zależy od jej własnych, niepublicznych zasad kwalifikacji. Poprawny znacznik usuwa barierę techniczną, ale nie zobowiązuje żadnej platformy do wyświetlenia konkretnej funkcji.
Która właściwość Schema.org powinna wymieniać poszczególne dania?
Właściwość menu w typie Restaurant może wskazywać na obiekt Menu, który z kolei używa hasMenuItem do wymienienia sekcji MenuSection lub pozycji MenuItem. Każdy MenuItem powinien mieć własną nazwę, a tam gdzie to zasadne, blok offers z ceną i priceCurrency, zgodnie ze słownikiem schema.org/Restaurant.
Czy suitableForDiet jest wymagane dla każdego dania?
Nie jest wymagane. suitableForDiet to opcjonalny element słownika opisujący ograniczenia dietetyczne, np. wegetariańskie czy bezglutenowe, za pomocą wyliczenia RestrictedDiet. Operatorzy powinni go stosować wyłącznie tam, gdzie mają zweryfikowane, dokładne informacje, ponieważ deklaracje dietetyczne niosą konsekwencje prawne i bezpieczeństwa wykraczające poza samą poprawność znacznika.
Nota redakcyjna: ChefNet publikuje ten przewodnik i rozwija produkty wspierające odkrywanie restauracji oraz ich działalność. Ogólne zalecenia operacyjne są oddzielone od twierdzeń o produkcie. Funkcje mogą się zmieniać wraz z rozwojem pilotaży. Opublikowano 2026-08-02.