JSON-LD

JSON-LD to oparty na JavaScripcie format publikowania ustrukturyzowanych danych, zwykle umieszczany w bloku script type="application/ld+json". Z perspektywy SEO ma to znaczenie, ponieważ Google wprost rekomenduje go do ustrukturyzowanych danych, a wdrożenie i zarządzanie jest znacznie łatwiejsze niż w przypadku Microdata na dużych serwisach.

Dlaczego SEO-wcy używają JSON-LD

Czystsza implementacja. Mniejsze ryzyko po stronie deweloperów. Lepsza kontrola jakości. Na tym polega prawdziwy atut.

Dzięki JSON-LD możesz oznaczyć Product, Article, FAQPage, Organization, LocalBusiness lub BreadcrumbList bez dotykania widocznych elementów HTML. To ma znaczenie w serwisach enterprise, gdzie zmiany w szablonach uruchamiają długie cykle QA. W praktyce większość zespołów wdraża JSON-LD przez pola w CMS, renderowanie po stronie serwera (server-side rendering) lub zarządzanie tagami, a następnie waliduje je w narzędziach Google: Rich Results Test, Google Search Console oraz Screaming Frog (niestandardowe wyciąganie danych).

JSON-LD lepiej skaluje się też między szablonami. Jeśli zarządzasz 20 000 adresów URL produktów albo 5 000 podstron lokalizacji, jeden generator schematów jest łatwiejszy do kontrolowania niż ręcznie utrzymywane Microdata.

Na co realnie wpływa JSON-LD

JSON-LD nie poprawia samodzielnie pozycji w wynikach wyszukiwania. Poprawia jednak kwalifikowalność do wyników rozszerzonych i pomaga wyszukiwarkom interpretować encje bardziej spójnie.

Ta różnica ma znaczenie. Dodanie schematu Product nie przeniesie słabej strony z miejsca 12 na miejsce 3. Może natomiast zdobyć ulepszenia dotyczące ceny, dostępności, opinii lub okruszków (breadcrumbs), które podnoszą CTR. Na stronach już znajdujących się w Top 5 nawet zysk CTR rzędu 5% do 15% może być istotny. Mierzysz to w GSC, a nie przez wpatrywanie się w walidator schematu.

Dokumentacja Google nadal jasno podkreśla regułę: poprawne ustrukturyzowane dane są wymagane dla wielu typów wyników rozszerzonych, ale kwalifikowalność nie jest gwarancją. Google może zignorować oznaczenia, wyłączyć wyświetlanie wyników rozszerzonych lub przepisać to, co pokazuje.

Standardy wdrożeniowe, które się bronią

• Dopasuj schemat do widocznej treści na stronie. Jeśli strona nie wyświetla opinii, nie oznaczaj aggregateRating.
• Używaj kanonicznych adresów URL w polach typu url i utrzymuj spójne odniesienia do encji w różnych wariantach.
• Generuj oznaczenia po stronie serwera, jeśli to możliwe. Schemat renderowany po stronie klienta może działać, ale jest mniej niezawodny na dużych serwisach zdominowanych przez JavaScript.
• Waliduj w Google Rich Results Test, a potem monitoruj raporty dotyczące ulepszeń w GSC.
• Rób crawl na dużą skalę za pomocą Screaming Frog lub Sitebulb, aby wychwycić brakujące pola, niepoprawny JSON i rozjazdy w szablonach.

Ahrefs i Semrush nie weryfikują schematów dogłębnie, ale pomagają priorytetyzować strony, na których ulepszenia wyników rozszerzonych mogą najszybciej przełożyć się na ruch. Surfer SEO i Moz są tu mniej przydatne; to w dużej mierze problem technicznego SEO i funkcji SERP, a nie punktacja jakości treści.

Uwaga, którą większość zespołów pomija

Dane schematu są równie wiarygodne, jak źródło, które je zasila. Jeśli Twój feed produktów jest nieaktualny, nieaktualny będzie też Twój JSON-LD. Właśnie tak dochodzi do sytuacji, w której oznaczasz produkty jako dostępne w magazynie, mimo że nie są, albo publikujesz liczbę opinii niezgodną z treścią na stronie.

John Mueller z Google wielokrotnie powtarzał, że ustrukturyzowane dane muszą odzwierciedlać treść strony, a niespójności mogą prowadzić do ignorowania oznaczeń albo działań ręcznych. Tak — JSON-LD to najlepszy format. Nie — nie jest to skrót. Złe dane w „czystym” formacie nadal są złymi danymi.