Schema.org pod AI Search: Budowanie grafu encji

AEO w stosunku do SEO przenosi dyskusje z prezentacji w wynikach wyszukiwania, na poprawne zrozumianie i zacytowanie przez model. Model nie czyta strony jak człowiek, tylko ją parsuje, szuka bytów, relacji i powtarzalnych sygnałów. Jeśli dostarczysz mu spójne dane o encjach, nie musi wszystkiego odtwarzać z prozy, więc chętniej będzie cytował stronę. Oczywiście to nie oznacza, że będzie robił, ale jest to krok w tym kierunku.

Schema.org dla AI: od pól do encji i grafu wiedzy

Klasyczne podejście do Schema.org jest atrybutowe i polega na tym, że bierzemy typ (Product, FAQPage), wypełniamy pola i otrzymujemy wyniki rozszerzone. To nadal działa i od tego warto zacząć. Podstawy dla strony usługowej opisałem w poradniku o LocalBusiness, Service i FAQ w Next.js. Trzeba pamiętać, że model AI szuka czegoś więcej, on chce widzieć relacje między bytami. Model chce wiedzieć, kim jesteś, kto to napisał, czego dotyczy tekst i z czym jest powiązany. Sam tytuł i cena mu nie wystarczają.

Strona produktowa z poprawnym Product dostanie gwiazdki w Google, ale ta sama strona, w której Product jest powiązany przez brand z Organization mającą stały identyfikator i komplet sameAs, daje modelowi kontekst encji. W ten sposób model wie, czyj to produkt, że ta firma istnieje też na LinkedInie czy w Wikipedii, i że można jej zaufać jako źródłu. Pierwsze optymalizuje wygląd, a drugie wpływa na zrozumienie.

Graf encji z @id jako fundament Schema.org pod AI

Sercem schema pod AI jest @id, czyli stały identyfikator, dzięki któremu różne fragmenty danych wskazują tę samą encję, zamiast tworzyć jej kopie. Zacznij od centralnej encji organizacji:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Acme",
  "url": "https://example.com",
  "logo": "https://example.com/logo.png",
  "description": "Studio tworzące szybkie strony i aplikacje w Next.js i Astro.",
  "sameAs": ["https://www.linkedin.com/company/acme", "https://github.com/acme"]
}

Teraz każda inna encja może się do niej odwołać przez @id, zamiast powtarzać dane organizacji:

{
  "@type": "Article",
  "@id": "https://example.com/blog/jakis-wpis/#article",
  "headline": "Tytuł wpisu",
  "author": { "@id": "https://example.com/#person-jan" },
  "publisher": { "@id": "https://example.com/#organization" },
  "about": { "@id": "https://example.com/#organization" }
}

Artykuł nie duplikuje danych autora ani wydawcy, tylko na nie wskazuje. To zamienia zbiór luźnych bloków w spójny, uporządkowany graf, w którym model potrafi prześledzić, że ten artykuł napisała ta osoba, pracująca dla tej organizacji, opisanej tymi linkami sameAs.

sameAs w Schema.org: jak ujednoznacznić encje dla AI

sameAs to prawdopodobnie najważniejsza pojedyncza właściwość w schema pod AI. Łączy Twój byt z jego reprezentacjami na zewnętrznych, zaufanych platformach. Bez niej model widzi izolowaną nazwę, np. „Acme", jedną z potencjalnie wielu. Z nią widzi byt osadzony w sieci, czyli ten sam podmiot, co profil na LinkedInie, repozytorium na GitHubie, wpis w bazie firm.

{
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Acme",
  "sameAs": [
    "https://www.linkedin.com/company/acme",
    "https://github.com/acme",
    "https://www.crunchbase.com/organization/acme"
  ]
}

Ta sama zasada dotyczy osób i warto to zapamiętać. Encja Person z sameAs do LinkedIna, profilu naukowego czy GitHuba pozwala modelowi powiązać autora treści z realną, weryfikowalną tożsamością. To bezpośrednio wpływa na to, czy potraktuje go jako wiarygodne źródło. Warto dołożyć do niej także jobTitle, knowsAbout oraz url prowadzący do strony autora. To sygnały z rodziny E-E-A-T i biorąc ostatnie zmiany w podchodzeniu przez Google do AI i tworzenia treści, to jedna z fundamentalnych moim zdaniem kwestii w nadchodzących latach.

Implementacja Schema.org w Next.js: graf encji w jednym miejscu

W Next.js najczystsze jest trzymanie centralnych encji w jednym module i składanie z nich grafu per strona. Dzięki temu @id organizacji i autorów istnieje w jednym źródle prawdy:

// lib/schema/entities.ts
export const ORGANIZATION = {
  '@type': 'Organization',
  '@id': 'https://example.com/#organization',
  name: 'Acme',
  url: 'https://example.com',
  sameAs: ['https://www.linkedin.com/company/acme', 'https://github.com/acme'],
} as const
 
export const PERSON_AUTHOR = {
  '@type': 'Person',
  '@id': 'https://example.com/#person-jan',
  name: 'Jan Kowalski',
  url: 'https://example.com/o-mnie',
  jobTitle: 'Frontend Developer',
  worksFor: { '@id': ORGANIZATION['@id'] },
  knowsAbout: ['Next.js', 'SEO', 'Dane strukturalne'],
  sameAs: ['https://www.linkedin.com/in/jankowalski'],
} as const

Na stronie składasz z nich pełny graf przez @graph — tablicę powiązanych encji emitowaną jako jeden blok JSON-LD:

// app/blog/[slug]/page.tsx
import { ORGANIZATION, PERSON_AUTHOR } from '@/lib/schema/entities'
 
export default async function ArticlePage({ params }) {
  const post = await getPost(params.slug)
 
  const graph = {
    '@context': 'https://schema.org',
    '@graph': [
      ORGANIZATION,
      PERSON_AUTHOR,
      {
        '@type': 'Article',
        '@id': `https://example.com/blog/${post.slug}/#article`,
        headline: post.title,
        author: { '@id': PERSON_AUTHOR['@id'] },
        publisher: { '@id': ORGANIZATION['@id'] },
        datePublished: post.datePublished,
      },
    ],
  }
 
  return (
    <>
      <script
        type="application/ld+json"
        dangerouslySetInnerHTML={{
          __html: JSON.stringify(graph).replace(/</g, '\\u003c'),
        }}
      />
      <ArticleBody post={post} />
    </>
  )
}

@graph robi tu najważniejszą robotę, czyli zamiast trzech osobnych skryptów JSON-LD, które model musi sam ze sobą powiązać, dostarczasz jeden spójny graf z jawnymi połączeniami. Taka forma jest łatwiejsza do interpretacji.

Co w Schema.org realnie pomaga AI zrozumieć stronę

Nie każda właściwość robi to samo. @id i @graph spinają całość w jeden graf. Bez nich reszta łatwo zamienia się w kilka niepowiązanych ze sobą elementów JSON-LD. sameAs ujednoznacznia encję względem zewnętrznych źródeł, a author, publisher i worksFor pokazują, kto odpowiada za treść. about i mentions mówią, o czym jest artykuł i jakie byty są w nim ważne. knowsAbout przy Organization lub Person deklaruje obszary kompetencji bez czekania, aż model sam je wywnioskuje.

Dla about i mentions wystarczy kilka linijek, żeby artykuł przestał być anonimowym tekstem, a stał się treścią o konkretnych, nazwanych bytach:

{
  "@type": "Article",
  "@id": "https://example.com/blog/jakis-wpis/#article",
  "about": { "@id": "https://example.com/#organization" },
  "mentions": [
    { "@type": "SoftwareApplication", "name": "Next.js" },
    { "@type": "Thing", "name": "JSON-LD" }
  ]
}

Walidacja grafu encji: jak sprawdzić Schema.org pod AI

Do weryfikacji grafu używaj walidatora Schema.org, który parsuje pełny JSON-LD razem z @graph i pokazuje encje wraz z ich powiązaniami. Równolegle uruchom test wyników z elementami rozszerzonymi Google: sprawdza dane obsługiwane przez Google i potrafi zgłosić błędy albo opcjonalne pola, które warto dodać, np. streetAddress oraz postalCode w adresie firmy. Te narzędzia odpowiadają na różne pytania, więc musisz używać obu.

Trzy rzeczy sprawdź ręcznie. Czy JSON-LD trafia do initial HTML (podgląd źródła strony albo curl), a nie jest dokładany dopiero po hydracji, bo część botów nie wykonuje JavaScriptu. Czy każdy @id, do którego coś się odwołuje, ma w grafie swoją pełną definicję, ponieważ wiszące odwołanie to najczęstszy błąd przy przechodzeniu z luźnych bloków na graf. I na końcu zobacz, czy graf zgadza się z widoczną treścią, ponieważ encja musi opisywać coś, co na stronie istnieje.

Czego Schema.org pod AI i AEO nie załatwi

Dane strukturalne nie są panaceum na wszystko. Modele nadal patrzą na trafność, autorytet tematyczny oraz klarowność treści. Schema z kolei pomaga im nie pomylić bytów, ale też nie sprawi, że słabej jakości strona nagle stanie się źródłem wartym cytowania. Na to trzeba zapracować w różny sposób i nie ma drogi na skróty.

Dzięki schema mamy natomiast redukcję niejednoznaczności, bo mówi modelowi wprost, czym jest Twój byt, kto za nim stoi i z czym jest powiązany, zamiast kazać mu to samemu wszystko wnioskować. Działa najlepiej tam, gdzie treść jest już na odpowiednio dobrym poziomie. Wtedy dane strukturalne domykają interpretację i zwiększają szansę na poprawny, przypisany do Ciebie cytat.