Dane strukturalne (schema.org): dlaczego AI cytuje jedne strony, a inne nie

Czym są dane strukturalne

Maszyna, która czyta Twoją stronę, widzi tekst, ale nie zawsze rozumie, czym jest każda rzecz. Dane strukturalne przyklejają etykiety: to jest produkt, to jego cena, to często zadawane pytanie, to autor. Standardowe słownictwo nazywa się schema.org i korzystają z niego zarówno wyszukiwarki, jak i modele AI. Ten przewodnik wyjaśnia, dlaczego pomagają w byciu cytowanym, jakie typy umieścić na każdej stronie z kompletnymi przykładami, jakie błędy odbierają wiarygodność i jak sprawdzić, czy wszystko się zgadza.

JSON-LD, łatwy sposób

Jest kilka sposobów zapisu schema, ale zalecany to JSON-LD: blok skryptu w formacie JSON, który umieszczasz w nagłówku lub treści strony. Nie zmienia niczego, co widzi użytkownik, i pozostaje oddzielony od widocznego HTML-a, więc łatwo go wygenerować i przejrzeć. Jeśli używasz Cursora, Bolta lub Lovable, poproszenie swojej AI o wygenerowanie JSON-LD dla konkretnej strony to kwestia jednego promptu. Alternatywa, mikrodane osadzone w tagach HTML, działa tak samo, ale jest trudniejsza w utrzymaniu.

Dlaczego pomaga w byciu cytowanym

Gdy model musi streścić Twoją stronę, schema zmniejsza niejednoznaczność. Zamiast wnioskować, że liczba to cena, wie to. Zamiast zgadywać, kto napisał artykuł, czyta to. Zamiast dedukować, że „Scanaris" to firma, a nie osoba, ma to zadeklarowane. Mniej zgadywania to więcej zaufania, a więcej zaufania to większe prawdopodobieństwo bycia użytym jako źródło. Poza tym schema łączy Twoją stronę z resztą internetu: pole sameAs linkuje do Twoich profili i model rozumie, że wszystko mówi o tej samej encji.

Jakie typy dodać i z jakimi właściwościami

Organization na stronie głównej: nazwa, logo, URL, opis w jednym zdaniu i sameAs z Twoimi publicznymi profilami.
SoftwareApplication (lub Product) na stronie produktu lub cennika: nazwa, opis, kategoria, system operacyjny lub platforma oraz offers z ceną i walutą.
FAQPage tam, gdzie są prawdziwe, widoczne pytania i odpowiedzi.
Article lub BlogPosting w postach, z autorem, datą publikacji i modyfikacji.
BreadcrumbList, żeby dać kontekst, gdzie każda strona się mieści.
WebSite na stronie głównej, z nazwą witryny, co pomaga poprawnie pojawiać się w wynikach.

Nie dodawaj ich wszystkich dla zasady. Oznaczaj tylko to, co naprawdę jest na stronie.

Kompletny przykład dla aplikacji

Tak wygląda blok strony głównej produktu software'owego, z organizacją i aplikacją w jednym grafie:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://twojadomena.com/#org",
      "name": "Twój Produkt",
      "url": "https://twojadomena.com",
      "logo": "https://twojadomena.com/logo.png",
      "description": "Twój Produkt to [czym jest] dla [kogo], które [co daje].",
      "sameAs": [
        "https://github.com/twojprodukt",
        "https://www.linkedin.com/company/twojprodukt",
        "https://x.com/twojprodukt"
      ]
    },
    {
      "@type": "SoftwareApplication",
      "name": "Twój Produkt",
      "applicationCategory": "DeveloperApplication",
      "operatingSystem": "Web",
      "url": "https://twojadomena.com",
      "description": "Twój Produkt to [czym jest] dla [kogo], które [co daje].",
      "publisher": { "@id": "https://twojadomena.com/#org" },
      "offers": {
        "@type": "Offer",
        "price": "24",
        "priceCurrency": "EUR",
        "url": "https://twojadomena.com/pricing"
      }
    }
  ]
}
</script>

Zwróć uwagę, że opis to to samo zdanie w obu blokach, i powinno być tym samym, które pojawia się na stronie głównej, w meta description i w llms.txt. To dokładne powtórzenie jest tym, co modele ostatecznie cytują.

I jeden dla często zadawanych pytań

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Czy Twój Produkt modyfikuje moją stronę?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Nie. Wykonuje kontrole tylko do odczytu na publicznych informacjach."
      }
    }
  ]
}
</script>

Każde pytanie z JSON-a musi istnieć, z tym samym tekstem, w widocznej części strony.

Najczęstsze błędy

Oznaczanie tego, czego nie widać. Często zadawane pytania, których nie ma na stronie, zmyślone recenzje, cena w JSON-ie inna niż na stronie. Odbiera wiarygodność i może ściągnąć ręczne działanie Google.
Nieaktualne dane. Zmieniasz cenę na stronie i zapominasz o schema. Generuj JSON-LD z tego samego źródła danych co stronę, nie ręcznie.
Niespójna nazwa. „Twój Produkt" na stronie głównej, „TwójProdukt" w schema, „twoj-produkt" w profilach. Wybierz jedną pisownię i używaj jej wszędzie.
Zły typ. Fizyczny Product dla usługi webowej albo Article na stronie cennika.
Nieprawidłowy JSON. Jeden przecinek za dużo i cały blok jest po cichu ignorowany.

Gdzie to umieścić w zależności od frameworka

W Next.js element script z type="application/ld+json" w layoucie lub na stronie, z JSON-em serializowanym z obiektu. W Nuxt przez useHead i skrypt tego samego typu. W SPA na Vite w index.html, jeśli blok jest statyczny, albo wstrzyknięty podczas prerenderingu, jeśli różni się między stronami. Ważne, żeby docierał w początkowym HTML-u: JSON-LD, który istnieje dopiero po wykonaniu JavaScriptu, nie jest czytany przez boty, które nie renderują.

Jak sprawdzić, czy jest poprawnie

Pobierz stronę curlem i poszukaj bloku:

curl -s https://twojadomena.com/ | grep -o 'application/ld+json' | wc -l

Jeśli wyjdzie zero, nie dociera w HTML-u. Potem zweryfikuj treść testem wyników z elementami rozszerzonymi Google albo walidatorem schema.org, które wskazują błędy składni i nieznane właściwości. I przeczytaj to sam: czy mówi to samo co strona? Jeśli nie, jedno z nich kłamie.

Scanaris sprawdza Twoje schema

Filar widoczności dla AI w Scanaris wykrywa, czy masz dane strukturalne, jakiego typu, czy docierają w HTML-u bez JavaScriptu i czy mają sens dla strony, a także daje fix prompt z proponowanym JSON-LD do wklejenia w Twoją AI. To kontrola tylko do odczytu na publicznym HTML-u Twojej strony. Jest częścią przewodnika po AEO i omówienia SEO i AEO na tej samej stronie.

Często zadawane pytania

Czy Google karze za błędne schema?

Schema z błędami składni jest po prostu ignorowane. Schema wprowadzające w błąd (oznaczanie recenzji lub pytań, których nie ma) może dostać ręczne działanie, które odbiera Ci wyniki z elementami rozszerzonymi. Oznaczaj tylko to, co widoczne.

JSON-LD czy mikrodane?

JSON-LD. To zalecają Google i schema.org, generuje się z danych bez dotykania widocznego HTML-a i jest dużo łatwiejszy w utrzymaniu.

Czy potrzebny jest na każdej stronie?

Na publicznych, które mają być zrozumiane: główna, produkt, cennik, blog, FAQ. Prywatny panel go nie potrzebuje, bo nikt z zewnątrz go nie czyta.