JSON-LD w WordPressie, Divi i WooCommerce — jak zrobić to dobrze, nie popełniając typowych błędów

W poprzednim wpisie pokazałem, dlaczego dane strukturalne przestały być dodatkiem do SEO, a zaczęły być warunkiem tego, żeby agent w ogóle wiedział, czym jest twoja strona. Tekst opowiada, dane twierdzą. Teraz schodzimy do praktyki — jak te twierdzenia zbudować w WordPressie, z Divi 5 jako builderem, z WooCommerce jako sklepem.

Zakres wpisu jest świadomie ograniczony. Skupiam się na trzech typach schema.org, które pokrywają zdecydowaną większość polskich stron: Organization (fundament każdej strony firmowej i bloga), Article (każdy wpis tekstowy) oraz Product z Offer (sklepy WooCommerce). Na końcu dorzucam krótko FAQPage, bo jest często pytany i często źle robiony. Inne typy — LocalBusiness, Event, Course, Recipe, Review — zasługują na osobne omówienia, których nie chcę upychać w tym wpisie.

Dla każdego typu pokazuję dwie rzeczy: co warto mieć w danych strukturalnych, i gdzie najczęściej ludzie to psują. Bo problem z JSON-LD rzadko polega na tym, że go nie ma. Częściej — że jest, ale nie działa tak, jak właściciel strony myśli.

Zanim wybierzesz narzędzie — kilka opcji

W WordPressie dane strukturalne generuje się zazwyczaj przez jedną z wtyczek SEO albo przez dedykowaną wtyczkę do schematów. Każda ma inny zakres, inne domyślne ustawienia i inną filozofię. Nie rekomenduję konkretnie żadnej z nich — wybór zależy od tego, co już masz na stronie i jaką ilością konfiguracji jesteś w stanie zarządzać.

Najpopularniejsze narzędzia generujące JSON-LD w WordPressie:

Yoast SEO — generuje podstawowe schematy (Organization, WebSite, BreadcrumbList, Article, Person), łączy je w graf JSON-LD. W wersji darmowej pokrywa typowe przypadki, w Premium daje więcej typów.

Rank Math — szerszy zakres typów w wersji darmowej niż Yoast, z ręczną edycją per wpis/strona. Obsługuje FAQ, HowTo, Product, LocalBusiness i kilkanaście innych.

SEOPress — mniej popularny w Polsce, ale ma solidny generator schematów z edytorem wizualnym. Wersja Pro dokłada więcej typów.

Schema & Structured Data for WP & AMP — wtyczka dedykowana tylko schematom, bez SEO. Sensowna jeśli już masz wtyczkę SEO bez schematów.

WooCommerce — natywnie generuje Product + Offer dla każdego produktu, niezależnie od wtyczki SEO. Wtyczki SEO zazwyczaj wykrywają to i nie duplikują.

Divi 5 — nie generuje schematów samodzielnie. Polega na wtyczce SEO albo dedykowanej wtyczce schematów. To jest istotne — zmiana motywu nie zmienia tego, co dostaje agent.

Wybór narzędzia jest mniej ważny niż dyscyplina jego używania. Każde z nich, dobrze skonfigurowane, załatwi 80% pracy. Każde, źle skonfigurowane, wygeneruje JSON-LD, który istnieje, ale jest bezużyteczny albo szkodliwy. O tym dalej.

Organization — fundament, którego większość stron nie ma dobrze

Organization to typ, który opisuje firmę albo wydawcę treści. Jedna deklaracja na całą stronę, zazwyczaj na stronie głównej albo we wszystkich podstronach przez wtyczkę SEO. Mimo że wydaje się podstawowa, to właśnie ten typ jest najczęściej wdrożony niekompletnie albo z błędami.

Minimum, które warto mieć:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "WebFlux",
  "url": "https://webflux.pl",
  "logo": "https://webflux.pl/logo.png",
  "sameAs": [
    "https://twitter.com/webfluxpl",
    "https://linkedin.com/company/webflux",
    "https://www.facebook.com/webfluxpl"
  ],
  "contactPoint": {
    "@type": "ContactPoint",
    "email": "kontakt@webflux.pl",
    "contactType": "customer service"
  }
}

Kluczowe pola, które zmieniają to z „szablonu” w „prawdziwe dane”:

• name — pełna nazwa firmy, ta sama co w rejestrze i na stronie kontaktowej. Nie slogan, nie skrót, nie wariant.
• url — kanoniczny URL strony głównej, z https://, bez slasha na końcu jeśli tak masz ustawione, albo z — ważne żeby konsekwentnie.
• logo — pełny URL do logo, nie względny link. Agent czytający JSON-LD nie zawsze wie, z jakiej domeny pochodzą dane.
• sameAs — linki do wszystkich profili reprezentujących tę samą firmę. Twitter/X, LinkedIn, Facebook, YouTube, GitHub jeśli masz. To jest pole, które Google i agenci używają do weryfikacji tożsamości organizacji.
• contactPoint — dla firm mających kontakt z klientem to pole bywa ważniejsze niż ludzie zakładają. Brakuje go w większości Organization JSON-LD na polskich stronach.

Najczęstszy błąd: pole sameAs pominięte albo z jednym profilem. Agent nie może zweryfikować, że strona, którą czyta, to ta sama organizacja co konto na LinkedIn z pięciotysięcznym followingiem. W rezultacie traci część sygnału zaufania, który mógł użyć przy rekomendacji.

Drugi najczęstszy błąd: name w JSON-LD inny niż w tekście strony. „WebFlux Studio Sp. z o.o.” w JSON-LD, „WebFlux” na stronie, „Pracownia WebFlux” w stopce. Agent widzi trzy warianty i nie wie, który jest kanoniczny. Wybierz jeden i trzymaj się go wszędzie.

Gdzie w WordPressie to ustawisz: w wtyczce SEO zazwyczaj w sekcji „Schema” albo „Knowledge Graph”. W Yoast — Yoast SEO → Settings → Site representation. W Rank Math — Titles & Meta → Global Meta → Knowledge Graph. W obu przypadkach wypełnij wszystkie pola, nie tylko te z gwiazdką.

Article / BlogPosting — pułapka daty i autora

Dla każdego wpisu blogowego albo artykułu powinien być JSON-LD typu Article (ogólniej) albo BlogPosting (specyficznie dla bloga). Większość wtyczek SEO generuje to automatycznie, co jest dobre — ale domyślne ustawienia rzadko są optymalne.

Minimum, które warto mieć:

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "Tytuł wpisu",
  "description": "Zwięzły opis wpisu, 100–200 znaków",
  "image": "https://webflux.pl/wp-content/.../obrazek.jpg",
  "datePublished": "2026-04-19T10:00:00+02:00",
  "dateModified": "2026-04-19T14:30:00+02:00",
  "author": {
    "@type": "Person",
    "name": "Imię Nazwisko",
    "url": "https://webflux.pl/autor/..."
  },
  "publisher": {
    "@type": "Organization",
    "name": "WebFlux",
    "logo": "https://webflux.pl/logo.png"
  }
}

Rzeczy, na które warto zwrócić uwagę:

• headline — ten sam tytuł, który jest widoczny w H1 wpisu. Nie krótszy, nie dłuższy, nie wariant SEO.
• datePublished i dateModified — oba w formacie ISO 8601, z pełnym czasem i strefą. Daty w formacie polskim (19 kwietnia 2026) nie są akceptowane przez walidatory schema.org.
• author — z typem Person i własnym URL-em prowadzącym do strony autora. WordPressowe archive-authorwystarczy.
• image — URL do featured image, preferowanie w proporcji 16:9 i minimum 1200px szerokości (to wymagania Google dla rich results, ale agenci też z tego korzystają).

Najczęstszy błąd — data modyfikacji, która się nie aktualizuje. WordPress i wtyczki SEO domyślnie aktualizują dateModified przy każdym zapisie wpisu, nawet jeśli zmiana dotyczy tylko kategorii czy taga. Albo odwrotnie — jeśli wpis został istotnie przepisany, a zmiana była w bazie danych bez użycia edytora, dateModified może nie odzwierciedlać rzeczywistego stanu. Efekt: agent widzi datę publikacji sprzed dwóch lat i uznaje wpis za nieaktualny, mimo że treść jest świeża. W Rank Math i Yoast warto sprawdzić, jak wtyczka obsługuje tę datę, i czy nie trzeba ręcznie wymusić aktualizacji po dużej edycji.

Drugi częsty błąd — autor jako Organization zamiast Person. Niektóre wtyczki, kiedy nie wykryją konkretnego autora, ustawiają author jako Organization z nazwą firmy. To formalnie poprawne, ale dla agenta daje słabszy sygnał autorytetu niż konkretny człowiek z własnym profilem. Jeśli blog prowadzi jedna osoba, używaj Person z imieniem i nazwiskiem.

Gdzie w Divi 5 się to łączy: Divi nie generuje Article JSON-LD. To robi wtyczka SEO na podstawie treści wpisu. Co ważne — jeśli masz niestandardowe typy postów (custom post types) z Divi Theme Builder, niektóre wtyczki SEO nie dodają do nich automatycznie JSON-LD. Trzeba to włączyć ręcznie w ustawieniach wtyczki, albo generować schemat osobno.

Product i Offer — gdzie WooCommerce załatwia sporo, ale nie wszystko

WooCommerce od wersji 3 generuje natywnie JSON-LD typu Product dla każdej strony produktu, z zagnieżdżoną Offer zawierającą cenę, dostępność i walutę. To jest dobra wiadomość — większość pracy jest zrobiona, jeszcze zanim zainstalujesz jakąkolwiek wtyczkę SEO.

Zła wiadomość — natywny JSON-LD WooCommerce jest minimalny. Zawiera to, co niezbędne, ale pomija wiele pól, które dla agenta mają wartość.

Przykład rozszerzonej struktury Product, której warto dążyć:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Nazwa produktu",
  "description": "Opis produktu, pełny, spójny z opisem na stronie",
  "image": ["https://.../zdjecie-1.jpg", "https://.../zdjecie-2.jpg"],
  "sku": "PROD-123",
  "brand": {
    "@type": "Brand",
    "name": "Nazwa marki"
  },
  "offers": {
    "@type": "Offer",
    "price": "2490.00",
    "priceCurrency": "PLN",
    "availability": "https://schema.org/InStock",
    "priceValidUntil": "2026-12-31",
    "url": "https://webflux.pl/produkt/nazwa-produktu/",
    "shippingDetails": {
      "@type": "OfferShippingDetails",
      "shippingRate": {
        "@type": "MonetaryAmount",
        "value": "0",
        "currency": "PLN"
      },
      "deliveryTime": {
        "@type": "ShippingDeliveryTime",
        "businessDays": {
          "@type": "QuantitativeValue",
          "minValue": 1,
          "maxValue": 3
        }
      }
    }
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.7",
    "reviewCount": "124"
  }
}

Co warto dodać ponad to, co daje natywne WooCommerce:

• brand — WooCommerce natywnie nie obsługuje marek. Trzeba użyć wtyczki (WooCommerce Brands albo wbudowanego w wtyczki SEO) albo dodać ręcznie.
• shippingDetails — obecnie jeden z mocniejszych sygnałów dla agentów zakupowych. WooCommerce generuje je tylko częściowo, w zależności od konfiguracji wysyłki.
• priceValidUntil — pole, które informuje agenta do kiedy cena jest aktualna. Jeśli brakuje, niektóre narzędzia traktują to jako sygnał że cena może być już nieważna.
• aggregateRating i review — jeśli masz system recenzji, te pola są generowane automatycznie przez WooCommerce. Jeśli nie masz recenzji, nie wpisuj fałszywych — to narusza reguły schema.org i Google karze to ręcznymi akcjami.

Najczęstszy błąd — rozbieżność ceny w JSON-LD i ceny promocyjnej na stronie. WooCommerce radzi sobie z tym domyślnie, ale wtyczki do promocji flash, pakietów, dynamicznych cen często wpływają na cenę wyświetlaną człowiekowi bez aktualizacji JSON-LD. Rezultat: strona pokazuje 1990 zł (po promocji), JSON-LD mówi 2490 zł (cena regularna). Agent widzi drugie. Pisałem o konsekwencjach w poprzednim wpisie.

Drugi częsty błąd — availability ustawione na InStock dla produktów, które są na backorder albo preorder.schema.org ma osobne wartości: InStock, OutOfStock, BackOrder, PreOrder, Discontinued. Jeśli używasz tylko pierwszych dwóch, tracisz niuans, który dla agenta może być decydujący.

Gdzie to ustawić w WooCommerce: natywne Product JSON-LD jest generowane automatycznie. Rozszerzenia (brand, dokładne shipping details) najłatwiej przez wtyczkę SEO z obsługą schematu Product albo przez dedykowaną wtyczkę schematów. Niezależnie od wyboru — zawsze waliduj po wdrożeniu (o tym za chwilę).

FAQPage — bonus, który łatwo zepsuć

Jeśli masz na stronie sekcję FAQ albo lista pytań i odpowiedzi (np. na stronie produktu, na lądowisku usługowym), JSON-LD typu FAQPage to jeden z prostszych sposobów na zwiększenie widoczności zarówno w Google (rich results), jak i w odpowiedziach agentów. Problem w tym, że jest bardzo łatwy do nadużycia, i właśnie dlatego Google w 2023 ograniczył widoczność rich results z FAQPage tylko do „well-known authoritative government and health websites” — ale w kontekście agentów AI ten sygnał nadal ma znaczenie.

Prosty schemat:

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Pytanie dokładnie jak na stronie?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Odpowiedź dokładnie jak na stronie, bez modyfikacji, bez dopisywania linków ani promocji."
      }
    }
  ]
}

Kluczowa reguła: pytania i odpowiedzi w JSON-LD muszą być dokładnie tymi samymi, które widzi użytkownik na stronie. Jeśli na stronie masz trzy pytania, a w JSON-LD dziesięć (bo wtyczka dopisuje dodatkowe pod kątem SEO) — to narusza reguły schema.org i Google karze takie praktyki. Agent też traktuje to jako sygnał, że danym nie warto ufać.

Gdzie to ustawić w Divi 5: jeśli używasz modułu Accordion do FAQ, niektóre wtyczki SEO (Rank Math, Schema Pro) potrafią go automatycznie wykryć i wygenerować JSON-LD. Inne nie. Sprawdź w kodzie źródłowym strony, czy JSON-LD faktycznie zawiera twoje pytania, i czy jest ich dokładnie tyle samo co na stronie.

Walidacja — bez tego nie wychodzisz z tematu

Niezależnie od typu, niezależnie od wtyczki, niezależnie od konfiguracji — każdy JSON-LD waliduj po wdrożeniu. Błędy w strukturze danych są niewidoczne dla człowieka (nie wpływają na wygląd strony), ale dla agenta i dla Google mogą całkowicie unieważnić twój schemat.

Narzędzia, których warto używać:

• Schema.org Validator (validator.schema.org) — waliduje względem pełnej specyfikacji schema.org, nie tylko wymagań Google. Najściślejszy.
• Google Rich Results Test (search.google.com/test/rich-results) — pokazuje czy twój JSON-LD kwalifikuje się do konkretnych rich results w Google.
• Yandex Structured Data Validator — czasem wyłapuje błędy, które inne narzędzia przepuszczają.

Waliduj po każdej znaczącej zmianie — nowa wtyczka SEO, zmiana szablonu, aktualizacja WooCommerce, dodanie custom fields. Błędy w JSON-LD pojawiają się często po niewinnych zmianach gdzie indziej.

Co dalej

To jest filar drugi w warstwie praktycznej. Następny wpis koncepcyjny w serii SEO/Agent-ready to filar trzeci — sygnały dla agentów: llms.txt, robots.txt pod AI-boty, .well-known. Potem towarzysz Divi/WordPress pokaże jak to ustawić konkretnie.

Zasada, która wraca: agent nie jest nową dyscypliną. Dane strukturalne były ważne od dekady. Różnica polega na tym, że dziś rozbieżność między tym, co na stronie, a tym, co w JSON-LD, jest bardziej kosztowna niż kiedykolwiek — bo agent działa na podstawie drugiego, a użytkownik widzi pierwsze. Domknięcie tej luki to w zasadzie cały zakres pracy w filarze danych strukturalnych.