Jak zapisać całodobową dostępność firmy w danych strukturalnych

Całodobowej dostępności firmy nie powinno się zapisywać jako zakresu 00:00–00:00. Taki zapis wygląda intuicyjnie, ale w danych strukturalnych obsługiwanych przez Google oznacza zamknięcie przez cały dzień, a nie pracę bez przerwy. Dla firmy działającej 24 godziny na dobę właściwy zakres to 00:00–23:59.

To drobna różnica w kodzie, lecz jej skutki są konkretne. Błędne godziny mogą powodować rozbieżności między stroną internetową, Profilem Firmy w Google i informacjami interpretowanymi przez wyszukiwarkę. Samo dodanie znacznika również nie gwarantuje wyświetlenia komunikatu „Otwarte 24 godziny”. Dane strukturalne są wskazówką dla systemów Google, a nie poleceniem, które musi zostać pokazane w wynikach.

Poprawny zapis godzin 24/7 w JSON-LD

Dla lokalnej firmy najbezpieczniejszym rozwiązaniem jest wykorzystanie typu odpowiadającego rzeczywistej działalności, na przykład Restaurant, Pharmacy, AutoRepair, Hotel albo bardziej ogólnego LocalBusiness. Godziny należy umieścić we właściwości openingHoursSpecification.

Podstawowy zapis firmy otwartej przez całą dobę, siedem dni w tygodniu, może wyglądać tak:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "@id": "https://example.pl/#firma",
  "name": "Przykładowa Firma",
  "url": "https://example.pl/",
  "telephone": "+48 22 123 45 67",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "ul. Przykładowa 10",
    "postalCode": "00-001",
    "addressLocality": "Warszawa",
    "addressCountry": "PL"
  },
  "openingHoursSpecification": {
    "@type": "OpeningHoursSpecification",
    "dayOfWeek": [
      "Monday",
      "Tuesday",
      "Wednesday",
      "Thursday",
      "Friday",
      "Saturday",
      "Sunday"
    ],
    "opens": "00:00",
    "closes": "23:59"
  }
}
</script>

Najważniejsze elementy tego kodu to:

• dayOfWeek — wskazuje dni objęte danym harmonogramem;
• opens — określa godzinę rozpoczęcia dostępności;
• closes — określa godzinę zakończenia dostępności;
• 00:00–23:59 — oznacza całodobowe działanie według sposobu interpretacji zalecanego dla danych lokalnych Google;
• @type — powinien opisywać faktyczny rodzaj działalności, a nie być wybierany wyłącznie dlatego, że najłatwiej go wdrożyć.

Nazwy dni zapisuje się po angielsku, ponieważ są to wartości słownika Schema.org. Nie należy tłumaczyć ich na Poniedziałek, Wtorek czy Niedziela. Można też stosować pełne adresy wartości, na przykład https://schema.org/Monday, ale krótki zapis Monday jest w JSON-LD czytelniejszy i powszechnie stosowany.

W praktycznych wdrożeniach lepiej przypisać wszystkie dni do jednej specyfikacji niż tworzyć siedem identycznych obiektów. Kod jest wtedy krótszy, łatwiejszy do aktualizacji i mniej podatny na sytuację, w której ktoś zmieni godziny dla sześciu dni, a siódmy pozostawi bez korekty.

Istnieje również prostsza właściwość openingHours, pozwalająca zapisać całotygodniową dostępność tekstowo, na przykład:

"openingHours": "Mo-Su"

Schema.org dopuszcza taki zapis dla firmy działającej przez cały dzień od poniedziałku do niedzieli. Mimo to przy wdrożeniach nastawionych na czytelność i kontrolę danych lepszym wyborem pozostaje openingHoursSpecification. Pozwala jednoznacznie podać dni, godziny oraz wyjątki sezonowe. Jest też łatwiejsza do rozbudowania, gdy firma przestaje działać w identycznym trybie przez cały rok.

Całodobowy numer telefonu to nie to samo co całodobowo otwarty lokal

Najczęstszy błąd nie dotyczy składni, lecz znaczenia danych. Firma może przyjmować zgłoszenia telefoniczne przez 24 godziny, ale obsługiwać klientów w lokalu tylko od 8:00 do 18:00. W takiej sytuacji oznaczenie całego punktu jako otwartego przez całą dobę jest merytorycznie nieprawdziwe.

Przed wdrożeniem trzeba ustalić, co dokładnie jest dostępne przez 24 godziny:

• fizyczny lokal z obsługą na miejscu;
• telefon alarmowy lub infolinia;
• formularz internetowy;
• automat samoobsługowy;
• odbiór przesyłek;
• pomoc drogowa działająca w terenie;
• rezerwacje przyjmowane automatycznie.

Godziny otwarcia w danych strukturalnych powinny odpowiadać informacji widocznej dla użytkownika na stronie. Jeżeli witryna podaje „biuro czynne 8:00–16:00”, a kod JSON-LD deklaruje 00:00–23:59, powstaje sprzeczność. Nie warto liczyć, że ukryty znacznik „poprawi” widoczność firmy. Dane strukturalne nie powinny opisywać lepszej wersji działalności, lecz jej stan faktyczny.

Dobrym przykładem jest pomoc drogowa. Dyspozytor może odbierać telefon przez całą dobę, chociaż siedziba nie przyjmuje klientów w nocy. Jeżeli strona opisuje usługę mobilną, całodobowość można komunikować w treści oraz w danych dotyczących konkretnej jednostki biznesowej. Nie należy jednak automatycznie oznaczać stacjonarnego biura jako dostępnego 24/7.

Podobny problem występuje w hotelach. Recepcja może działać bez przerwy, ale restauracja hotelowa, strefa SPA i dział rezerwacji mają inne godziny. W takim przypadku nie wolno przypisywać jednego harmonogramu wszystkim częściom obiektu. Odrębne jednostki lub działy powinny otrzymać własne dane, jeżeli mają osobne godziny, numery telefonów albo zakres obsługi.

Przed publikacją kodu trzeba odpowiedzieć na trzy pytania:

1. Czy klient rzeczywiście może skorzystać z opisanej działalności o 3:00 w nocy?
2. Czy całodobowość dotyczy wszystkich siedmiu dni, również niedziel i świąt?
3. Czy identyczna informacja znajduje się na stronie oraz w Profilu Firmy w Google?

Jeżeli odpowiedź na którekolwiek pytanie brzmi „nie”, stały harmonogram 00:00–23:59 dla całego tygodnia będzie zbyt szeroki.

Nie należy też wpisywać całodobowych godzin „na zapas”, ponieważ formularz kontaktowy działa bez przerwy. Formularz może przyjąć wiadomość o dowolnej porze, lecz nie oznacza to, że przedsiębiorca zapewnia natychmiastową obsługę. Taki zabieg jest szczególnie ryzykowny w branżach, w których klient podejmuje pilną decyzję: przy usługach medycznych, weterynaryjnych, ślusarskich, hydraulicznych czy drogowych.

Wyjątki, święta i kontrola wdrożenia

Stałe godziny 00:00–23:59 nie rozwiązują problemu dni wyjątkowych. Firma może działać całodobowo przez większość roku, a mimo to zamykać lokal w Wigilię, Nowy Rok, podczas inwentaryzacji albo na czas prac technicznych. Takie odstępstwa należy zapisać za pomocą specialOpeningHoursSpecification.

Przykład zamknięcia firmy 25 grudnia:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "@id": "https://example.pl/#firma",
  "name": "Przykładowa Firma",
  "openingHoursSpecification": {
    "@type": "OpeningHoursSpecification",
    "dayOfWeek": [
      "Monday",
      "Tuesday",
      "Wednesday",
      "Thursday",
      "Friday",
      "Saturday",
      "Sunday"
    ],
    "opens": "00:00",
    "closes": "23:59"
  },
  "specialOpeningHoursSpecification": {
    "@type": "OpeningHoursSpecification",
    "validFrom": "2026-12-25",
    "validThrough": "2026-12-25",
    "opens": "00:00",
    "closes": "00:00"
  }
}
</script>

W tym przypadku identyczne wartości opens i closes ustawione na 00:00 oznaczają zamknięcie przez cały dzień. To właśnie dlatego nie można stosować takiego zakresu do oznaczania dostępności 24/7.

Jeżeli wyjątkowe godziny obowiązują tylko przez jeden dzień, validFrom i validThrough powinny wskazywać tę samą datę. Przy kilkudniowej przerwie należy podać pierwszy oraz ostatni dzień okresu. Daty zapisuje się w formacie RRRR-MM-DD, na przykład 2026-12-24.

W kodzie produkcyjnym warto dopilnować jeszcze kilku elementów:

• umieścić znacznik na stronie opisującej konkretną firmę lub placówkę;
• używać jednego, stabilnego identyfikatora @id, na przykład https://example.pl/#firma;
• podać pełny numer telefonu z prefiksem kraju, np. +48;
• wpisać rzeczywisty adres placówki;
• zachować zgodność nazwy, adresu, telefonu i godzin między witryną a Profilem Firmy w Google;
• nie generować równocześnie dwóch sprzecznych zestawów danych przez motyw WordPressa i wtyczkę SEO;
• po wdrożeniu sprawdzić kod w teście wyników z elementami rozszerzonymi oraz w walidatorze Schema.org;
• po indeksacji skontrolować adres strony w Google Search Console.

Najbardziej irytującym problemem w praktyce są duplikaty JSON-LD. Jeden znacznik dodaje wtyczka SEO, drugi system rezerwacyjny, a trzeci motyw strony. Każdy może podawać inne godziny. Kod przechodzi wtedy test składni, ale przekazuje trzy wersje tej samej informacji. Walidacja techniczna nie zastępuje więc ręcznego sprawdzenia źródła strony.

Samo wyświetlenie komunikatu o poprawnym kodzie również nie gwarantuje, że Google pokaże godziny w wynikach wyszukiwania. Wyszukiwarka zestawia dane strukturalne z treścią strony, informacjami z Profilu Firmy i innymi sygnałami. Poprawny znacznik ogranicza ryzyko błędnej interpretacji, lecz nie daje prawa do określonego wyglądu wyniku.

Aktualizację godzin najlepiej wdrażać jednocześnie w trzech miejscach:

1. w widocznej treści strony;
2. w kodzie danych strukturalnych;
3. w Profilu Firmy w Google.

Zmiana tylko jednego źródła tworzy okres niespójności. Przy firmie całodobowej szczególnie łatwo go przeoczyć, ponieważ stały harmonogram rzadko trafia na listę danych wymagających okresowego przeglądu.

Dodatkowe informacje na: naphub.pl.

FAQ

Czy 00:00–00:00 oznacza firmę otwartą przez całą dobę?
Nie. W danych lokalnych interpretowanych zgodnie z dokumentacją Google taki zapis oznacza zamknięcie przez cały dzień. Dla działalności 24/7 należy użyć 00:00–23:59.

Czy trzeba tworzyć osobny wpis dla każdego dnia tygodnia?
Nie. Wszystkie siedem dni można umieścić w jednej tablicy dayOfWeek, jeżeli obowiązują w nich identyczne godziny.

Czy można użyć polskich nazw dni?
Nie należy tego robić. Wartości Schema.org zapisuje się jako Monday, Tuesday, Wednesday, Thursday, Friday, Saturday i Sunday.

Czy dane strukturalne zastępują godziny w Profilu Firmy w Google?
Nie. Profil Firmy i kod strony są odrębnymi źródłami. Powinny podawać te same informacje, ale aktualizacja JSON-LD nie jest automatyczną aktualizacją profilu.

Czy firma z całodobowym telefonem może oznaczyć się jako otwarta 24/7?
Tylko wtedy, gdy całodobowa dostępność rzeczywiście opisuje oznaczoną działalność. Jeżeli przez całą dobę działa wyłącznie telefon, a lokal jest zamknięty, trzeba wyraźnie rozdzielić te informacje.

Jak zapisać zamknięcie przez cały dzień?
W OpeningHoursSpecification należy ustawić zarówno opens, jak i closes na 00:00. Przy jednorazowym zamknięciu trzeba dodatkowo wskazać datę przez validFrom i validThrough.

Czy poprawny JSON-LD gwarantuje wyświetlanie godzin w Google?
Nie. Google samodzielnie decyduje o sposobie prezentacji informacji. Poprawne dane zwiększają czytelność strony dla systemów wyszukiwarki, ale nie gwarantują konkretnego elementu wyniku.

Gdzie umieścić kod JSON-LD?
Najczęściej w sekcji <head> albo w treści dokumentu HTML. Skrypt musi znaleźć się w kodzie strony dostępnej dla robotów i nie może być blokowany przez logowanie, noindex ani reguły uniemożliwiające indeksowanie.

Pierwsze działanie powinno być proste: wyszukaj w kodzie strony wszystkie wystąpienia openingHours, openingHoursSpecification i specialOpeningHoursSpecification. Jeżeli znajdziesz opens: "00:00" oraz closes: "00:00" przy zwykłych godzinach firmy, usuń ten błąd w pierwszej kolejności i zastąp zakres wartością 00:00–23:59 — ale dopiero po potwierdzeniu, że klient naprawdę otrzymuje obsługę przez całą dobę.