Schema Article i dane autora: jak potwierdzić autorstwo

Google od lat powtarza, że ocenia treść przez pryzmat doświadczenia i kompetencji osoby, która ją napisała. Kłopot w tym, że podpis pod tekstem jest dla maszyny tylko ciągiem znaków. Dopóki nie powiążesz go z danymi strukturalnymi, ani algorytm wyszukiwarki, ani model językowy nie wie, czy „Anna Kowalczyk” to redaktorka z dziesięcioletnim stażem w branży, czy pseudonim wygenerowany razem z tekstem. Zadaniem danych strukturalnych jest zamiana tego podpisu w jednoznacznie zidentyfikowany byt.

Ten materiał rozwija jeden konkretny wątek z szerszego opracowania o danych strukturalnych pod AI: jak technicznie połączyć typy Article, Person i stronę autora w spójny zestaw, który da się zweryfikować.

Autorstwo jako sygnał wiarygodności

W wytycznych oceny jakości Google autor jest jednym z filarów E-E-A-T. Oceniający mają sprawdzić, kto stoi za treścią, jakie ma kwalifikacje i czy da się je potwierdzić poza samą witryną. Ten sam schemat przenosi się na systemy generatywne: modele, które budują odpowiedź z kilku źródeł, chętniej sięgają po materiały, gdzie podmiot odpowiedzialny za tekst jest nazwany i opisany.

Warto rozdzielić dwie rzeczy, które często się mieszają. Pierwsza to deklaracja autorstwa, czyli widoczny podpis, data i zdjęcie. Druga to potwierdzenie autorstwa, czyli zestaw danych, które pozwalają powiązać tę osobę z dorobkiem, instytucją lub profilami zewnętrznymi. Pierwsza bez drugiej nie wnosi niczego, czego nie da się podrobić w pięć minut. Dopiero gdy obie warstwy są spójne, autorstwo zaczyna działać jako sygnał.

Google nie obiecuje za to bonusu w rankingu i nie ma sensu tak tego sprzedawać. Realna korzyść jest inna: przestajesz być anonimowym tekstem w morzu podobnych materiałów, a Twoja strona autora zaczyna się kumulować jako osobny, rozpoznawalny byt w grafie wiedzy.

Praktyczna konsekwencja jest taka, że autorstwo opłaca się budować wokół kilku nazwisk, a nie wokół dwudziestu. Rozproszenie publikacji na wiele profili, z których każdy ma po dwa teksty, nie daje żadnej masy krytycznej. Lepiej mieć trzy strony autorów z realnym dorobkiem i uzupełnionym biogramem niż dwadzieścia pustych archiwów.

Article: pola, które warto wypełnić

Typ Article (albo jego podtypy NewsArticle i BlogPosting) jest kontenerem na wszystko, co dotyczy publikacji. Większość wtyczek SEO wypełnia go automatycznie, ale zwykle bardzo oszczędnie. Poniżej pola, które naprawdę wnoszą informację.

Najważniejszy jest drugi wiersz. Jeśli author jest tekstem, to wszystko kończy się na etykiecie. Jeśli jest obiektem z własnym identyfikatorem, otwierasz drogę do opisania tej osoby raz i wielokrotnego odwołania się do niej. Pole publisher powinno z kolei wskazywać na tę samą encję, którą opisujesz w schemacie Organization i sameAs, a nie tworzyć drugiego, konkurencyjnego bytu dla tej samej marki.

Person i strona autora: co musi się zgadzać

Encja osoby powinna mieszkać pod stałym identyfikatorem, najlepiej adresem strony autora z kotwicą. Dzięki temu każdy artykuł odwołuje się do jednego obiektu, a nie do kopii z literówką w nazwisku.

{
  "@type": "Person",
  "@id": "https://seotrade.pl/autor/anna-kowalczyk/#person",
  "name": "Anna Kowalczyk",
  "jobTitle": "Redaktorka prowadząca",
  "description": "Od 2015 roku zajmuje się technicznym SEO i danymi strukturalnymi.",
  "url": "https://seotrade.pl/autor/anna-kowalczyk/",
  "knowsAbout": ["dane strukturalne", "SEO techniczne"],
  "sameAs": ["https://www.linkedin.com/in/przyklad/"]
}

Teraz część, o którą najczęściej się potykamy. Dane w schemacie muszą odpowiadać temu, co widzi człowiek. Jeżeli jobTitle mówi o redaktorce prowadzącej, a strona autora ma pustą biografię i zero tekstów, rozbieżność jest oczywista dla każdego, kto sprawdzi. Strona autora powinna zawierać minimum: pełne imię i nazwisko, kilka zdań o doświadczeniu z datami, listę publikacji i co najmniej jeden zewnętrzny punkt weryfikacji.

Przy okazji warto upewnić się, że archiwum autora nie konkuruje o te same frazy z artykułami. To klasyczne źródło problemów opisanych szerzej przy okazji kanibalizacji słów kluczowych.

Powiązanie autora z profilami zewnętrznymi

Tablica sameAs jest mechanizmem rozwiązywania tożsamości. Mówisz w niej: ta osoba ze mojej witryny i ten profil w serwisie zewnętrznym to ten sam człowiek. Im trudniej podrobić profil po drugiej stronie, tym więcej on wnosi.

• Wysoka wartość: profil instytucjonalny, ORCID, wpis w rejestrze branżowym, strona prelegenta na konferencji, która nadal działa.
• Średnia wartość: LinkedIn z historią zatrudnienia, publiczny profil GitHub z aktywnością.
• Niska wartość: świeże konta w serwisach społecznościowych bez historii, katalogi, do których wpis dodaje się samodzielnie.

Dwie reguły praktyczne. Po pierwsze, nie wpisuj profili, których nie kontrolujesz i których nie da się powiązać zwrotnie. Po drugie, zadbaj o linkowanie w drugą stronę: jeśli profil zewnętrzny pozwala wstawić adres, wskaż nim stronę autora. Jednostronna deklaracja jest słabsza niż para, która się domyka.

Osobna pułapka dotyczy serwisów, które zmieniają autora po publikacji. Jeśli tekst przechodzi z jednego profilu na drugi, stary identyfikator zostaje w cache’u wtyczki i w indeksie, a nowy pojawia się tylko w świeżo renderowanym kodzie. Przez kilka tygodni dla wyszukiwarki istnieją więc dwa autorstwa tego samego artykułu. Przy przenoszeniu wpisów warto od razu wyczyścić cache strony i archiwum autora, a potem sprawdzić renderowany kod, zamiast zakładać, że zmiana w panelu wystarczy.

Wdrożenie na WordPressie krok po kroku

1. Uzupełnij profil użytkownika: pełne imię i nazwisko, pole „Wyświetlaj jako”, biogram na kilka zdań z konkretnymi datami i adres URL.
2. W ustawieniach wtyczki SEO (RankMath, Yoast) włącz schemat autora i sprawdź, czy strony archiwum autora nie są oznaczone jako noindex. Jeśli są, encja nie ma stałego adresu.
3. Ustaw domyślny typ schematu dla wpisów na Article lub BlogPosting i upewnij się, że headline bierze tytuł wpisu, nie tytuł SEO.
4. Dodaj pola własne na profile zewnętrzne, a następnie wstrzyknij je do tablicy sameAs filtrem wtyczki lub własnym fragmentem JSON-LD w stopce.
5. Rozbuduj szablon author.php tak, żeby renderował biogram, listę specjalizacji i odnośniki do profili. Encja bez widocznej treści wygląda jak atrapa.
6. Zablokuj automatyczne podbijanie dateModified przy kosmetycznych zmianach. Data, która zmienia się codziennie bez powodu, przestaje cokolwiek znaczyć.

Jeśli prowadzisz również sklep, ta sama logika identyfikatorów obowiązuje przy ofertach i produktach. Opisaliśmy to osobno przy schemacie Product i Offer, bo tam błędne @id potrafi rozsypać cały graf.

Jak sprawdzić, czy dane są odczytywane

Walidacja składni to dopiero pierwszy krok. Kolejność, która oszczędza czas, wygląda tak.

1. Test wyników z elementami wzbogaconymi w dokumentacji Google dla typu Article: łapie braki w polach wymaganych.
2. Walidator schema.org: pokazuje cały graf, więc od razu widać, czy author jest obiektem, czy stringiem, i czy identyfikatory się spotykają.
3. Raport „Dane strukturalne” w Search Console: jedyne miejsce, gdzie zobaczysz, co Google faktycznie odczytał po przetworzeniu JavaScriptu.
4. Podgląd renderowanego kodu w narzędziu do inspekcji adresu URL: potwierdza, że skrypt JSON-LD w ogóle dotrwał do wersji, którą widzi robot.

Trzy objawy, które najczęściej wychodzą w tej kolejności: dwie encje Person o tej samej nazwie i różnych identyfikatorach, author wskazujący na stronę główną zamiast na stronę autora, oraz pusty graf, bo wtyczka cache’ująca podała wersję sprzed wdrożenia. Ostatni przypadek rozpoznasz po tym, że walidator widzi stary kod, a przeglądarka nowy.

Na koniec perspektywa, która porządkuje priorytety. Potwierdzone autorstwo nie podnosi pozycji samo z siebie. Robi coś innego: usuwa powód, dla którego ktoś mógłby uznać Twoją treść za anonimową masówkę. Przy rosnącym udziale materiałów generowanych maszynowo to różnica, która będzie się pogłębiać.

FAQ