Inżynieria Grafu Wiedzy – Entity SEO i Pozycjonowanie Semantyczne Encji

Audyt encji – co sprawdzam na starcie

Audyt encji odpowiada na jedno pytanie: co Google i modele AI „wiedzą” dziś o Twojej marce i skąd to wiedzą. Zanim cokolwiek zmienię, zbieram obraz z kilku miejsc naraz, bo każde z nich pokazuje inną warstwę tego samego problemu.

Do Knowledge Graph Search API podchodzę ostrożnie. Dokumentacja Google opisuje je jako interfejs tylko do odczytu, który zwraca pojedyncze encje bez powiązań między nimi, i zaznacza, że nie nadaje się do zastosowań krytycznych produkcyjnie. Używam go więc jako wskaźnika (czy encja istnieje, jak jest opisana, czy zmienia się w czasie), a nie jako wyroczni.

Pytania, które zadaję asystentom AI

1. Czym zajmuje się [marka]? (sprawdzam kategorię i opis)
2. Kto założył [markę] i kto nią kieruje? (sprawdzam osoby)
3. Gdzie działa [marka] i od kiedy? (lokalizacja, data)
4. Jakie firmy oferują [usługę] w [mieście lub kraju]? (czy marka pojawia się w rekomendacjach)
5. [marka] czy [konkurent] – czym się różnią? (z czym model kojarzy markę)

Każde pytanie zadaję kilka razy, bo pojedyncza odpowiedź modelu jest losowa. Szczegóły metody opisuję w audycie widoczności w AI, który często robię razem z tą usługą.

Arkusz faktów marki – jedno źródło prawdy

Arkusz faktów to tabela, w której każdy fakt o marce ma jedną zatwierdzoną wartość, źródło, które go potwierdza, i listę miejsc, gdzie występuje. To najważniejszy produkt audytu, bo wszystkie późniejsze kroki (strona „O firmie”, JSON-LD, Wikidata, profile) kopiują wartości z tego arkusza, a nie z pamięci.

Przy każdym fakcie zapisuję status: potwierdzony, sprzeczny (z listą miejsc, gdzie jest inna wartość) albo brakujący. Lista sprzeczności to gotowy plan poprawek, uszeregowany według tego, jak ważne jest dane źródło dla Google i dla odpowiedzi AI.

Entity home – strona, która definiuje markę

Entity home to jedna strona w Twojej witrynie, zwykle „O firmie”, która podaje wszystkie fakty z arkusza w formie czytelnej dla człowieka i maszyny. Inne źródła mają ją potwierdzać, a ona ma do nich linkować.

Projektuję ją jak stronę z faktami, a nie jak stronę wizerunkową. Typowy układ:

• Pierwszy akapit to opis z arkusza faktów: nazwa, czym się zajmujesz, dla kogo, gdzie i od kiedy.
• Ludzie z imienia i nazwiska, z rolą i linkiem do ich profili lub stron autorów.
• Dane rejestrowe w stopce lub w osobnym bloku: nazwa prawna, NIP, KRS lub CEIDG, adres.
• Specjalizacje nazwane wprost, tymi samymi słowami, których używasz w ofercie i profilach.
• Potwierdzenia zewnętrzne: publikacje, wystąpienia, nagrody, z linkami do źródeł.
• Linki do oficjalnych profili, widoczne dla użytkownika, a nie tylko ukryte w kodzie.

Google w dokumentacji danych strukturalnych Organization zaleca umieszczenie ich na stronie głównej albo na jednej stronie opisującej organizację. Ja wybieram jedno z tych miejsc jako definicję encji, a na pozostałych podstronach tylko się do niej odwołuję.

Graf JSON-LD – Organization, Person i WebSite połączone przez @id

Graf JSON-LD to zestaw danych strukturalnych, w którym każda encja (firma, osoba, witryna) ma stały identyfikator @id, jest zdefiniowana raz, a inne strony i encje odwołują się do niej. Dzięki temu cała witryna opisuje jedną, spójną firmę, a nie dziesiątki niepowiązanych bytów.

Właściwości, które wypełniam

Google w dokumentacji Organization (aktualizacja z września 2026 r.) nie wymaga żadnej właściwości, ale rekomenduje m.in. name, alternateName, legalName, url, logo, description, address, contactPoint, sameAs, foundingDate, numberOfEmployees oraz identyfikatory: vatID, taxID, iso6523Code i naics. O dwóch ostatnich pisze, że pomagają odróżnić organizację od innych, a o logo, że pomaga Google wybrać logo pokazywane w wynikach i panelu wiedzy.

Tak jest zbudowana ta strona: jedna encja Person z identyfikatorem https://wiszniewsky.pl/#person i encja firmy, które wskazują się nawzajem (founder i worksFor), a w sameAs osoby jest m.in. rekord w Wikidata. Wpisy na blogu nie definiują autora od nowa, tylko odwołują się do tego @id. Dla Google zalecenia dotyczące autora w Article są proste: każdy autor osobno, w author.name samo imię i nazwisko, a author.url lub sameAs prowadzi do strony, która tę osobę identyfikuje.

Ważna granica: Google pisze w dokumentacji funkcji AI w wyszukiwarce, że do pojawienia się w AI Overviews i AI Mode nie trzeba żadnych specjalnych znaczników. Graf JSON-LD nie jest więc „przepustką”, tylko maszynowo czytelną wersją faktów, które i tak są na stronie. Wdrożenie robię bezpośrednio w kodzie, tak jak w usłudze wdrażania Schema.org, a typy i składnię opisuję w przewodniku po danych strukturalnych.

sameAs – które profile dodać, a których nie

Do sameAs dodaję tylko adresy, które jednoznacznie wskazują tę samą markę lub osobę i które marka kontroluje albo które są uznanymi bazami wiedzy. schema.org definiuje sameAs jako URL strony, która jednoznacznie wskazuje tożsamość obiektu, więc każdy błędny link osłabia, a nie wzmacnia encję.

Wikidata w praktyce – kryteria i ryzyka

Rekord w Wikidata ma sens wtedy, gdy marka spełnia zasady przyjmowania elementów i istnieją publiczne, poważne źródła, które ją opisują. Bez tego wpis zostanie zgłoszony do usunięcia, a próba „przepchnięcia” go zostawia ślad w historii edycji.

Zasady notability Wikidata wymieniają trzy kryteria, z których wystarczy spełnić jedno: element ma link do strony w projekcie Wikimedia (np. Wikipedii), opisuje jasno identyfikowalną encję, którą da się opisać na podstawie poważnych i publicznie dostępnych źródeł, albo jest potrzebny strukturalnie, żeby uzupełnić twierdzenia w innych elementach. Firmy bez hasła w Wikipedii zwykle opierają się na drugim kryterium, dlatego źródła przygotowuję przed utworzeniem rekordu.

• Źródła, które sprawdzają się jako referencje: wpis w rejestrze, artykuły w mediach branżowych lub lokalnych, publikacje, informacje o nagrodach.
• Źródła słabe: własna strona jako jedyne potwierdzenie, komunikaty prasowe przedrukowane bez redakcji, profile społecznościowe.
• Opis elementu ma odróżniać encję od innych o tej samej nazwie (np. „polska firma programistyczna, Białystok”), a nie reklamować.
• Pętla potwierdzenia: w rekordzie wskazuję oficjalną stronę, a na stronie dodaję URL rekordu do sameAs.

Pełną instrukcję tworzenia rekordu, z właściwościami i kolejnością, opisuję w artykule Wikipedia, Wikidata i panel wiedzy. Wikipedii nie edytuję w imieniu klientów: to pole konfliktu interesów i jedyne, co realnie mogę zrobić, to pomóc zdobyć niezależne źródła, na których hasło mogłoby kiedyś powstać.

Panel wiedzy – jak go przejąć i poprawić

Panelu wiedzy nie da się zamówić ani „zgłosić” przez Search Console. Pojawia się, gdy Google ma dość potwierdzonych informacji o encji, a dopiero wtedy można go przejąć i zgłaszać poprawki.

Według pomocy Google proces wygląda tak:

1. Wyszukujesz markę lub osobę i znajdujesz panel wiedzy.
2. Na dole panelu (czasem w sekcji z informacjami) klikasz przycisk przejęcia panelu, w angielskiej wersji „Claim this knowledge panel”.
3. Logujesz się na jedno z oficjalnych kont wskazanych przez Google, np. YouTube lub Search Console witryny. Jeśli Google nie może powiązać żadnego konta, prosi o dodatkowe potwierdzenie tożsamości.
4. Po weryfikacji zgłaszasz zmiany przez opcję opinii (Feedback) pod panelem: zaznaczasz konkretny fakt, opisujesz, co ma się zmienić, i dodajesz linki, które to potwierdzają.
5. Zweryfikowany właściciel może dodać kolejne osoby do zarządzania panelem.

Search Console pełni tu tylko rolę jednego ze sposobów weryfikacji. Dlatego przy wdrożeniu pilnuję, żeby witryna była zweryfikowana w Search Console na koncie, do którego firma ma dostęp, a oficjalny kanał YouTube był podpięty w sameAs. Skraca to drogę, gdy panel się pojawi.

Encje osób – założyciele, eksperci i autorzy

W wielu firmach, zwłaszcza usługowych i eksperckich, to osoba założyciela jest najbardziej rozpoznawalną encją. Model, który pyta „kto jest ekspertem od [tematu]”, szuka ludzi, nie tylko firm, dlatego encje Person traktuję jako część tej samej pracy.

• Strona autora lub eksperta w witrynie z biogramem, specjalizacją, zdjęciem i linkami do profili.
• Person w JSON-LD z jednym @id, powiązany z firmą przez worksFor i founder.
• Spójny podpis we wszystkich artykułach, wywiadach i wystąpieniach: to samo imię i nazwisko, ta sama rola.
• Profile zewnętrzne (LinkedIn, profile autorskie w mediach) z tym samym opisem i linkiem do strony firmy.

Jak budować rozpoznawalność eksperta w odpowiedziach AI, opisuję w artykule Marka osobista eksperta. Zakres usługi obejmuje osoby kluczowe, jeśli ustalimy to na starcie, bo od liczby osób zależy część kosztu.

Trudne przypadki – rebranding, fuzja i nazwa wspólna z inną firmą

Najwięcej pracy wymagają sytuacje, w których dane o marce są nie tylko niepełne, ale i sprzeczne z definicji: zmiana nazwy, połączenie firm albo nazwa, którą nosi też ktoś inny.

Przy zmianie domeny encja jest tylko jednym z elementów. Jeśli rebranding obejmuje nowy adres strony, łączę tę pracę z migracją SEO, żeby nie stracić pozycji przy okazji porządkowania danych. Gdy model powtarza nieprawdziwe informacje, pomocny będzie też wpis o tym, co zrobić, gdy ChatGPT mówi o firmie nieprawdę.

Powiązanie marki z tematami – wzmianki, które budują encję

Encja, która jest rozpoznana, ale nie jest kojarzona z żadnym tematem, nie trafi do rekomendacji. Drugim celem tej usługi jest więc powiązanie nazwy marki z kategoriami, w których chcesz być polecany.

Robię to na trzy sposoby: konsekwentnie łącząc nazwę z tematami na własnej stronie (opis, specjalizacje, knowsAbout w danych strukturalnych), dbając o to, żeby profile zewnętrzne opisywały te same specjalizacje, oraz planując wzmianki w miejscach, które piszą o Twojej kategorii. Plan wzmianek jest częścią wyników usługi, ale samo pozyskiwanie publikacji to osobna praca, opisana w strategii cytowań LLM i we wpisie o digital PR i wzmiankach o marce.

Przykład pełnej ścieżki, od architektury encji przez treści po wzmianki w mediach branżowych, pokazuje case study marki modowej, w którym wyszukiwania nazwy marki wzrosły z 840 do 2 350 miesięcznie.

Jak mierzę postęp w budowaniu encji

Postęp mierzę stałym zestawem wskaźników, sprawdzanych przed wdrożeniem i potem co miesiąc, a nie pojedynczym zrzutem ekranu panelu wiedzy.

Do testów odpowiedzi AI używam własnego narzędzia opisanego w case study AnswerLyzer, które ocenia odpowiedzi modeli metodą LLM-as-a-judge. Ręczną wersję takiego pomiaru opisuję w artykule o audycie widoczności w AI.

Harmonogram – co zależy ode mnie, a co od Google i modeli AI

Część pracy ma przewidywalny termin, bo wykonuję ją sam. Reszta zależy od tego, kiedy Google ponownie przetworzy strony i kiedy zewnętrzne źródła oraz modele uwzględnią zmiany, i tego terminu nikt uczciwie nie zagwarantuje.

Usługa jest częścią szerszego GEO, czyli pozycjonowania w AI. Jeśli nie wiesz, od czego zacząć, zwykle proponuję najpierw audyt widoczności, bo pokazuje, czy problemem jest encja, treści czy brak wzmianek.