Dane strukturalne na stronie firmowej są warstwą semantycznego opisu treści. Nie zmieniają bezpośrednio projektu wizualnego serwisu, nie zastępują dobrze napisanych tekstów i nie stanowią samodzielnej strategii SEO. Ich zadaniem jest dostarczenie wyszukiwarkom uporządkowanych informacji o tym, co znajduje się na danej podstronie: organizacji, usłudze, artykule lub innym elemencie serwisu.
Dla zarządu, właściciela firmy czy dyrektora marketingu istotne jest przede wszystkim właściwe zaplanowanie zakresu wdrożenia. Oznaczenia powinny wynikać z architektury informacji, rzeczywistej zawartości podstron i możliwości późniejszego utrzymania. Mogą pomóc Google lepiej interpretować stronę i kwalifikować ją do określonych prezentacji w Google Search, ale nie gwarantują wyświetlenia wyniku rozszerzonego ani konkretnej poprawy pozycji.
Najbezpieczniejsze podejście łączy inwentaryzację treści, dobór właściwych typów, implementację, walidację techniczną, kontrolę zgodności z informacjami widocznymi dla użytkownika oraz monitoring po publikacji.
Dane strukturalne na stronie firmowej — definicja i cel biznesowy
Dane strukturalne to ustandaryzowany sposób dostarczania informacji o stronie i klasyfikowania jej treści. Zapis pozwala opisać znaczenie poszczególnych elementów, a nie tylko ich wygląd lub rozmieszczenie. W praktyce oznaczenia są umieszczane na stronie, której dotyczą, i powinny odnosić się do informacji dostępnych użytkownikowi.
Witryna firmowa może zawierać informacje o organizacji, jej nazwie, logo, adresie, telefonie, adresie strony oraz powiązanych profilach online. W zależności od zawartości poszczególnych podstron można także opisywać usługi, artykuły, okruszki nawigacyjne i inne elementy. Nie oznacza to jednak, że każda strona powinna zawierać wszystkie możliwe typy danych strukturalnych.
Warto rozdzielić trzy warstwy. Pierwszą jest treść, z którą zapoznaje się użytkownik. Drugą stanowi warstwa semantyczna, czyli uporządkowany opis tej treści dla systemów takich jak wyszukiwarka. Trzecia obejmuje elementy wizualne i funkcjonalne projektu. Dane strukturalne nie są więc ani logo, ani identyfikacją wizualną, ani elementem interfejsu.
Cel biznesowy polega na uporządkowaniu informacji i ułatwieniu ich interpretacji. Nie należy przedstawiać tego procesu jako gwarancji wzrostu widoczności, ruchu, konwersji czy pozycji w Google Search. Poprawne oznaczenia mogą umożliwiać określone prezentacje, lecz decyzja o ich wyświetleniu pozostaje po stronie wyszukiwarki.
Schema.org, JSON-LD i pozostałe formaty
Schema.org jest słownikiem typów i właściwości, który pozwala opisywać obiekty występujące w treści. Można za jego pomocą uporządkować informacje dotyczące między innymi organizacji, usług i artykułów. Schema.org nie jest systemem CMS, narzędziem do projektowania strony ani gotową strategią marketingową. Dostarcza języka, którym można opisać rzeczywistą zawartość serwisu.
JSON-LD jest formatem implementacji danych strukturalnych rekomendowanym przez Google. Google obsługuje także Microdata i RDFa, jednak w typowym wdrożeniu warto rozważyć JSON-LD jako podstawowy sposób przekazywania oznaczeń. Decyzja powinna uwzględniać strukturę serwisu, sposób zarządzania treścią i zdolność zespołu do utrzymywania zgodności kodu z aktualną zawartością.
Z punktu widzenia organizacji nie jest to wyłącznie decyzja techniczna. Zakres oznaczeń powinien zostać uzgodniony między osobami odpowiedzialnymi za treść, architekturę informacji, CMS, projekt i implementację. Jeżeli dane w kodzie są generowane automatycznie, trzeba ustalić, z jakich pól pobierają informacje i co dzieje się po zmianie nazwy firmy, logo, oferty, autora albo daty publikacji.
Najważniejsza zasada brzmi: należy oznaczać wyłącznie informacje istotne i dostępne dla użytkownika. Nie powinno się dodawać danych ukrytych, fikcyjnych, mylących ani niezgodnych z główną treścią strony tylko po to, aby zwiększyć szansę na określoną prezentację w Google Search.
Jak zaplanować dane dla organizacji, usług i artykułów
Planowanie warto rozpocząć od inwentaryzacji typów podstron i ich głównego celu w architekturze informacji. Najpierw należy ustalić, które strony opisują firmę, które przedstawiają konkretne usługi, a które mają charakter redakcyjny. Dopiero potem można dobierać typy i właściwości. Takie podejście ogranicza ryzyko nadmiarowego oznaczania oraz ułatwia późniejsze zarządzanie wdrożeniem.
Organizacja i dane firmowe
Dane typu Organization powinny być umieszczane na stronie głównej albo na pojedynczej stronie opisującej organizację, na przykład stronie „O nas”. Należy wybrać najbardziej szczegółowy podtyp Organization, który odpowiada rzeczywistej organizacji. Nie chodzi o zastosowanie najbardziej rozbudowanego wariantu, lecz o trafne odwzorowanie charakteru firmy.
Zakres informacji powinien wynikać z tego, co firma faktycznie prezentuje użytkownikom. Mogą to być między innymi:
- rzeczywista nazwa organizacji;
- logo używane i prezentowane w serwisie;
- adres, jeżeli jest dostępny na stronie;
- numer telefonu, jeżeli firma go publikuje;
- adres strony internetowej;
- powiązane profile online, jeżeli są rzeczywiście wskazane.
Każde oznaczenie powinno odpowiadać informacjom widocznym na właściwej podstronie. Nie należy uzupełniać brakujących danych założeniami ani tworzyć dodatkowych informacji wyłącznie na potrzeby kodu.
Usługi i artykuły
Usługę należy oznaczać wtedy, gdy konkretna podstrona rzeczywiście ją przedstawia. Sama ogólna lista ofertowa nie uzasadnia automatycznego tworzenia rozbudowanych oznaczeń dla każdej możliwej usługi. Typ powinien odpowiadać głównemu celowi strony, a jego właściwości muszą odzwierciedlać treść dostępną dla użytkownika.
W przypadku artykułu oznaczenie powinno być powiązane z faktycznym materiałem. Należy zachować zgodność między danymi a widocznym tytułem, autorstwem, datami publikacji oraz innymi informacjami przedstawionymi na stronie. Nie należy dodawać fikcyjnych autorów, dat ani elementów, których użytkownik nie może znaleźć w treści.
Dobór typów nie powinien być próbą oznaczenia wszystkich możliwych elementów. Dla każdej podstrony należy wybrać rozwiązanie adekwatne do jej celu, zawartości i możliwości utrzymania.
Proces wdrożenia: od architektury informacji do publikacji
Wdrożenie danych strukturalnych powinno być procesem, a nie jednorazowym dodaniem kodu do strony. Pierwszym krokiem jest ustalenie zakresu dla poszczególnych typów podstron i szablonów. W tym miejscu warto wskazać, które informacje są źródłem danych, kto odpowiada za ich aktualność oraz w jakich sytuacjach oznaczenia wymagają ponownego sprawdzenia.
Następnie dane należy przygotować w CMS-ie lub w kodzie strony, zgodnie z wybranym słownikiem i formatem. W przypadku JSON-LD trzeba kontrolować relacje między typami, właściwościami i adresami URL. Nieaktualny adres, błędna relacja albo automatycznie skopiowana informacja może sprawić, że kod przestanie odpowiadać stronie.
Osobnej kontroli wymaga wdrożenie generowane przez JavaScript. Należy sprawdzić renderowany HTML, a nie wyłącznie kod dostępny na etapie projektowania lub w konfiguracji CMS-a. Przed publikacją trzeba również potwierdzić, że oznaczenia znajdują się na stronie, której dotyczą, i opisują jej główną treść.
Proces powinien obejmować także plan aktualizacji. Zmiana nazwy firmy, adresu, logo, oferty, autora, daty publikacji lub struktury adresów URL może wymagać aktualizacji danych strukturalnych. Bez przypisania odpowiedzialności łatwo pozostawić w kodzie informacje niezgodne z serwisem.
Walidacja danych strukturalnych przed publikacją
Walidacja powinna łączyć kontrolę techniczną z oceną jakościową. Pierwszym narzędziem może być Rich Results Test, który służy do sprawdzenia, jakie funkcje wyników rozszerzonych mogą być generowane na podstawie wdrożenia. Wynik testu nie jest jednak obietnicą, że dana prezentacja zostanie później wyświetlona.
Drugim narzędziem jest Schema Markup Validator. Służy ono do ogólnej walidacji danych Schema.org, także poza funkcjami specyficznymi dla Google. Rozróżnienie obu narzędzi jest istotne: poprawność względem słownika nie oznacza automatycznej kwalifikacji do konkretnej funkcji Google Search, a kwalifikacja nie oznacza gwarantowanego wyświetlenia.
Przed publikacją warto przejść następującą checklistę:
- sprawdzić kod w Rich Results Test;
- zwalidować dane w Schema Markup Validator;
- porównać oznaczenia z treścią widoczną dla użytkownika;
- sprawdzić renderowany HTML, jeżeli dane są generowane przez JavaScript;
- zweryfikować adres URL narzędziem URL Inspection;
- potwierdzić brak blokady przez robots.txt, noindex lub wymagane logowanie;
- ponownie przetestować stronę po usunięciu błędów i wprowadzeniu zmian.
Sam brak błędów w narzędziu nie potwierdza pełnej zgodności jakościowej. Kontrola musi objąć także sens oznaczeń, ich kompletność oraz zgodność z aktualną treścią podstrony.
Najczęstsze ryzyka i zasady utrzymania
Najpoważniejsze ryzyko powstaje wtedy, gdy dane strukturalne opisują informacje ukryte, nieistotne, fikcyjne albo wprowadzające w błąd. Takie oznaczenia mogą uniemożliwić uzyskanie wyników rozszerzonych lub prowadzić do działań ręcznych. Nie należy dodawać fikcyjnych opinii, ocen, usług, lokalizacji, danych kontaktowych ani relacji biznesowych.
Drugim ryzykiem jest niespójność narastająca po zmianach w organizacji lub serwisie. Aktualizacja logo bez zmiany danych, nowa oferta bez odpowiedniej modyfikacji oznaczeń albo przebudowa adresów URL mogą rozdzielić treść widoczną od informacji zapisanych w kodzie. Dlatego dane strukturalne powinny być objęte procesem utrzymania, podobnie jak treści i szablony.
Po publikacji należy monitorować raporty danych strukturalnych w Search Console. Strony warto ponownie testować po zmianach szablonów, kodu, CMS-a lub struktury adresów. Właściciel procesu powinien mieć możliwość zgłoszenia rozbieżności i doprowadzenia do ich usunięcia.
Dane strukturalne nie zastępują dobrze zaprojektowanej treści, poprawnej struktury strony, dostępności, wydajności ani optymalizacji technicznej. Nie analizowano konkretnej strony BrandingHouse, jej CMS-a, szablonów ani istniejącego kodu JSON-LD, dlatego rzeczywista ocena poprawności wymaga audytu konkretnego adresu URL i kodu.
Podsumowując, dane strukturalne powinny wynikać z rzeczywistej treści i celu każdej podstrony. Schema.org dostarcza słownika typów i właściwości, a JSON-LD jest rekomendowanym przez Google formatem implementacji. Organizację, usługi i artykuły należy oznaczać tylko wtedy, gdy odpowiadają im faktyczne, dostępne dla użytkownika informacje. Wdrożenie wymaga inwentaryzacji, uzgodnienia odpowiedzialności, walidacji w odpowiednich narzędziach oraz monitoringu po publikacji. Jest to element uporządkowania informacji i kwalifikacji do funkcji wyszukiwarki, a nie gwarancja określonego wyniku SEO. Umów konsultację z BrandingHouse, aby stworzyć spójny wizerunek marki i materiały dopasowane do celów Twojej firmy.
