Dane strukturalne autora i strony „O nas”: techniczna strona E-E-A-T

TL;DR
Dane strukturalne autora i firmy (Organization, Person, ProfilePage, Article/BlogPosting, LocalBusiness) pomagają Google jednoznacznie rozpoznać, kto stoi za stroną i treścią. Nie gwarantują pozycji ani wyników rozszerzonych, co Google pisze wprost.
Dla Article, Organization i ProfilePage Google nie wymaga wielu pól: Article i Organization nie mają właściwości obowiązkowych, ProfilePage wymaga tylko głównej encji z nazwą.
Najważniejsza zasada: znaczniki opisują treść widoczną dla człowieka. Strona „O nas” i strona autora muszą istnieć i być konkretne, zanim dodasz do nich JSON-LD.
Spójność danych firmy (nazwa, adres, telefon, NIP, KRS) na stronie, w Profilu Firmy, w rejestrach i w kontach reklamowych jest równie ważna jak sam kod.
Sprawdzisz to w Teście wyników z elementami rozszerzonymi, walidatorze schema.org i Search Console, przy czym raport w Search Console istnieje tylko dla części typów, np. stron profilu.

Aktualizacja: 1 października 2026 · Autor: Szymon Sanecznik, SEMownia

Po lekturze o E-E-A-T większość firm robi dwie rzeczy: dopisuje biogram autora i instaluje wtyczkę, która „dodaje schema”. Po kilku tygodniach nikt nie wie, czy znaczniki działają, czy nie dublują się z motywem i czy dane firmy w kodzie zgadzają się z tymi w KRS i w Profilu Firmy w Google. Efekt psują zwykle właśnie te rozbieżności.

W tym artykule opisuję techniczną stronę E-E-A-T: co powinno być na stronie „O nas” i stronie autora, które typy danych strukturalnych mają sens, jakie właściwości zaleca Google (stan dokumentacji na wrzesień 2026), jak połączyć firmę, autora i artykuł w jednym grafie JSON-LD i jak to sprawdzić. Na końcu jest symulacja kosztu wdrożenia w trzech wariantach. Część strategiczną, czyli czym E-E-A-T jest i czym nie jest, opisuję we wpisie E-E-A-T w praktyce.

Czym są dane strukturalne autora i firmy?

Dane strukturalne autora i firmy to fragment kodu (zwykle JSON-LD w słowniku schema.org), który opisuje maszynowo to, co człowiek widzi na stronie: kim jest firma (Organization lub LocalBusiness), kim jest autor (Person na stronie ProfilePage) i kto napisał oraz opublikował artykuł (Article lub BlogPosting z właściwościami author i publisher).

Google obsługuje trzy formaty: JSON-LD, Microdata i RDFa, ale zaleca JSON-LD, bo najłatwiej go wdrożyć i utrzymać. Czy kod może zastąpić treść? Nie może. Jest jej opisem, a Google wymaga, żeby ten opis zgadzał się z tym, co widzi użytkownik.

W kontekście E-E-A-T dane strukturalne pełnią przede wszystkim funkcję rozpoznania tożsamości (ujednoznacznienia, czyli wskazania, o którą dokładnie osobę lub firmę chodzi): pomagają powiązać „Jan Kowalski” z konkretnego artykułu z tym Janem Kowalskim, który ma profil na LinkedIn, wpis w rejestrze zawodowym i stronę autora w Twojej domenie, żeby jego dorobek nie mieszał się z dorobkiem imiennika z innej branży.

Co dane strukturalne dają, a czego nie dają?

Ile w ogóle warto w to inwestować? Odpowiedź zależy głównie od ograniczeń, więc od nich zacznę.

• Brak gwarancji. Google pisze, że nie gwarantuje wyświetlenia danych strukturalnych w wynikach, nawet jeśli znaczniki są poprawne.
• Brak wymogu dla AI. Według dokumentacji Google do pojawienia się w AI Overviews i AI Mode nie są potrzebne żadne specjalne znaczniki schema.org ani pliki dla AI. Dane strukturalne nie są też wymagane w generatywnych funkcjach wyszukiwarki.
• Nie wszystkie wyniki rozszerzone przetrwały. Google stopniowo upraszcza wyniki. Od 7 maja 2026 wynik rozszerzony FAQ nie wyświetla się w wyszukiwarce, a dokumentację usunięto 15 czerwca 2026. We wrześniu 2025 zniknęła dokumentacja m.in. dla informacji o kursach, szacunkowych wynagrodzeń i ofert pojazdów.
• Ryzyko kary za nadużycia. Za znaczniki niezgodne z wytycznymi (ukryta treść, fałszywe opinie, treść niezwiązana ze stroną) grozi ręczne działanie (sankcja nałożona przez pracownika Google), które odbiera kwalifikację do wyników rozszerzonych, choć według Google nie wpływa na zwykłe pozycje.

A co zyskujesz?

• Logo i dane w panelu wiedzy. Właściwość logo w Organization pomaga Google zrozumieć, które logo pokazywać, np. w wynikach wyszukiwania i panelach wiedzy. Minimalny rozmiar to 112 × 112 px.
• Ujednoznacznienie firmy. Identyfikatory (vatID, taxID, legalName, url, sameAs) pomagają odróżnić Twoją firmę od innych o podobnej nazwie.
• Lepsze rozpoznanie autorów. Google ma osobną sekcję dobrych praktyk dla znaczników autora i pisze, że rozumie zarówno url, jak i sameAs przy ujednoznacznianiu autorów.
• Dokładniejsze daty. datePublished i dateModified ze strefą czasową dają Google pewniejszą informację o dacie niż tekst na stronie.

Ujmę to tak. Zaufanie budujesz treścią, opiniami i reputacją, a dane strukturalne pomagają maszynie prawidłowo je przypisać.

Strona „O nas” i strona autora: co musi być w treści

Wytyczne Google zabraniają oznaczania treści niewidocznej dla czytelnika, więc kolejność jest stała i nie widzę sensu w jej odwracaniu: najpierw strona dla człowieka, potem kod.

Strona „O nas” (i stopka)

• pełna nazwa prawna i nazwa handlowa, jeśli się różnią,
• adres siedziby, NIP, numer KRS lub informacja o wpisie do CEIDG, e-mail i telefon (art. 5 ustawy o świadczeniu usług drogą elektroniczną wymaga podania adresu elektronicznego, nazwy, siedziby i adresu),
• rok założenia, zakres działalności, obszar obsługi,
• osoby odpowiedzialne: imię, nazwisko, rola, zdjęcie, link do strony autora,
• linki do oficjalnych profili firmy (LinkedIn, Facebook, YouTube, Profil Firmy w Google) — te same, które trafią do sameAs.

Strona autora

Google wymienia strony autorów, strony „O mnie” na blogach i strony pracowników w witrynach firm jako właściwe miejsca na znaczniki ProfilePage. Na takiej stronie powinny być:

• imię i nazwisko (to samo, które jest w podpisie pod artykułami),
• krótki opis specjalizacji i doświadczenia z konkretami: staż, typy projektów, uprawnienia z numerem, który da się sprawdzić,
• zdjęcie, najlepiej z pracy (zdjęcie ze stocku nic tu nie wnosi),
• linki do profili zewnętrznych i publikacji,
• lista artykułów autora.

Pod każdym artykułem podpis z imieniem i nazwiskiem powinien prowadzić do tej strony. Google w poradniku o pomocnych treściach pyta, czy podpisy prowadzą do informacji o autorach i obszarach, o których piszą. Mało kto to sprawdza.

Które typy danych strukturalnych i jakie właściwości?

Poniższa tabela zbiera to, co Google pisze w dokumentacji (stan na wrzesień 2026). „Obowiązkowe” oznacza wymagane do kwalifikacji do funkcji w wyszukiwarce; wymagania samego schema.org to osobna sprawa.

Typ	Obowiązkowe wg Google	Zalecane wg Google	Gdzie umieścić
Organization (lub podtyp, np. OnlineStore)	brak	name, url, logo, legalName, address, telephone, email, contactPoint, vatID, taxID, sameAs, foundingDate, description	strona główna albo „O nas”; nie musi być na każdej podstronie
LocalBusiness (podtyp, np. AccountingService)	name, address	telephone, url, geo, openingHoursSpecification, priceRange	strona lokalizacji lub kontaktu
ProfilePage z Person	mainEntity (Person lub Organization) z name	alternateName, identifier, image, sameAs, description, dateCreated, dateModified	strona autora, strona pracownika
Article / BlogPosting	brak	headline, image, datePublished, dateModified, author (z name i url)	każdy artykuł

Kilka zasad z dokumentacji Article, które często są łamane:

• W author.name wpisuj tylko imię i nazwisko, bez tytułu, stanowiska czy nazwy firmy. Wydawcę podajesz w publisher.
• Każdy autor osobno. „Jan Kowalski i Anna Nowak” w jednym polu to błąd.
• author to Person albo Organization, a author.url prowadzi do strony, która jednoznacznie identyfikuje autora. Jeśli to strona w Twojej domenie, Google zaleca oznaczyć ją jako ProfilePage.
• Daty w formacie ISO 8601 ze strefą czasową, np. 2026-08-29T08:30:00+02:00. Bez strefy Google przyjmie strefę Googlebota.

Dla firm lokalnych Google zaleca najbardziej szczegółowy podtyp, który pasuje do działalności, np. OnlineStore dla sklepu lub podtyp LocalBusiness dla firmy z siedzibą, w której obsługuje klientów.

Przykładowy JSON-LD: firma, autor i artykuł w jednym grafie

Poniżej przykład dla fikcyjnego biura rachunkowego. Trzy encje są połączone identyfikatorami @id: artykuł wskazuje autora i wydawcę, autor wskazuje pracodawcę. Dzięki temu dane firmy podajesz raz, a pozostałe obiekty tylko się do nich odwołują. Kod umieszczasz w znaczniku <script type="application/ld+json"> w nagłówku lub treści strony.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "AccountingService",
      "@id": "https://example.pl/#firma",
      "name": "Biuro Rachunkowe Przykład",
      "legalName": "Biuro Rachunkowe Przykład sp. z o.o.",
      "url": "https://example.pl/",
      "logo": "https://example.pl/logo-512.png",
      "telephone": "+48 22 000 00 00",
      "email": "biuro@example.pl",
      "vatID": "PL0000000000",
      "taxID": "0000000000",
      "identifier": {
        "@type": "PropertyValue",
        "propertyID": "KRS",
        "value": "0000000000"
      },
      "foundingDate": "2012-03-01",
      "address": {
        "@type": "PostalAddress",
        "streetAddress": "ul. Przykładowa 1",
        "addressLocality": "Warszawa",
        "postalCode": "00-001",
        "addressCountry": "PL"
      },
      "sameAs": [
        "https://www.linkedin.com/company/przyklad",
        "https://www.facebook.com/przyklad"
      ]
    },
    {
      "@type": "ProfilePage",
      "@id": "https://example.pl/autorzy/anna-nowak/#profil",
      "url": "https://example.pl/autorzy/anna-nowak/",
      "dateModified": "2026-08-29T08:30:00+02:00",
      "mainEntity": {
        "@type": "Person",
        "@id": "https://example.pl/autorzy/anna-nowak/#osoba",
        "name": "Anna Nowak",
        "description": "Doradczyni podatkowa, 14 lat praktyki w obsłudze spółek",
        "image": "https://example.pl/zdjecia/anna-nowak.jpg",
        "worksFor": { "@id": "https://example.pl/#firma" },
        "sameAs": [
          "https://www.linkedin.com/in/anna-nowak-przyklad"
        ]
      }
    },
    {
      "@type": "BlogPosting",
      "headline": "Jak rozliczyć samochód w firmie w 2026 roku",
      "image": [
        "https://example.pl/zdjecia/samochod-16x9.jpg",
        "https://example.pl/zdjecia/samochod-4x3.jpg",
        "https://example.pl/zdjecia/samochod-1x1.jpg"
      ],
      "datePublished": "2026-08-29T08:30:00+02:00",
      "dateModified": "2026-08-29T08:30:00+02:00",
      "author": {
        "@type": "Person",
        "@id": "https://example.pl/autorzy/anna-nowak/#osoba",
        "name": "Anna Nowak",
        "url": "https://example.pl/autorzy/anna-nowak/"
      },
      "publisher": { "@id": "https://example.pl/#firma" }
    }
  ]
}

Uwagi do przykładu:

• Właściwości identifier z KRS i worksFor są poprawne w schema.org, ale Google nie wymienia ich w dokumentacji Organization ani ProfilePage. Traktuj je jako uzupełnienie opisu. Wyniku rozszerzonego z nich nie będzie.
• vatID i taxID muszą odpowiadać krajowi z adresu. W przykładzie vatID to numer VAT UE z prefiksem PL, a taxID to NIP.
• Na żywej stronie graf Organization dodajesz raz (strona główna lub „O nas”), ProfilePage na stronie autora, a BlogPosting na każdym artykule. Wyżej pokazuję je razem tylko dla czytelności.
• Jeśli używasz wtyczki SEO w WordPressie, sprawdź najpierw, co już generuje. Dwa niezależne obiekty Organization z różnymi danymi to gorsza sytuacja niż brak znaczników.

Spójność danych firmy w sieci: NAP, KRS, NIP i profile

Dane strukturalne to tylko jedno z miejsc, w których Google widzi dane firmy, obok Profilu Firmy w Google, rejestrów publicznych, profili społecznościowych, katalogów branżowych i kont reklamowych. Co, jeśli te źródła mówią co innego? Wtedy kod na stronie tego nie naprawi.

NAP (Name, Address, Phone) to nazwa, adres i telefon. Dla polskiej firmy dochodzą NIP, KRS lub CEIDG i nazwa prawna. Typowe rozbieżności, które widzę w audytach:

• stary adres w Profilu Firmy po przeprowadzce, nowy na stronie,
• nazwa handlowa w jednym miejscu, pełna nazwa spółki w drugim, a nazwa z dopisanymi słowami kluczowymi w trzecim,
• różne numery telefonów (stacjonarny, komórka handlowca, numer śledzący z kampanii) bez wskazania głównego,
• dane w profilu płatności Google Ads lub w Merchant Center inne niż na stronie.

Ostatni punkt kosztuje najwięcej. Weryfikacja reklamodawcy w Google Ads wymaga zgodności danych z dokumentami rejestrowymi, o czym piszę w tekście o ograniczonym wyświetlaniu reklam nowej firmy. W Merchant Center niespójne dane firmy to jedna z typowych przyczyn zawieszenia za wprowadzanie w błąd, opisana w artykule o zawieszeniu konta Merchant Center.

Dla firm lokalnych głównym źródłem danych w Mapach jest Profil Firmy w Google. Dane w LocalBusiness na stronie powinny być z nim identyczne, łącznie z formatem adresu i godzinami otwarcia. Jak spójność danych i opinie wpływają na pozycję w mapach, opisuję w artykule o pozycjonowaniu wizytówki Google.

Jedna pułapka dotyczy opinii. Google pisze, że jeśli firma kontroluje opinie o sobie, jej strony z danymi LocalBusiness lub innym typem Organization nie kwalifikują się do gwiazdek w wynikach. Wstawianie aggregateRating z opinii zebranych na własnej stronie nic więc nie da. Od lipca 2026 dokumentacja zakazuje też jednoznacznie oznaczania fałszywych opinii i opinii za korzyści bez wyraźnego ujawnienia. Zasady zbierania opinii w Google rozpisuję w tekście o opiniach Google.

Panel wiedzy: czy można go „zamówić”?

Nie. Panel wiedzy (Knowledge Panel) Google tworzy automatycznie na podstawie informacji z sieci. Nie ma formularza, którym można go zamówić. Można natomiast:

• Przejąć istniejący panel. Pod panelem pojawia się opcja „Przejmij ten panel wiedzy”. Weryfikacja odbywa się przez zalogowanie na oficjalne konto powiązane z podmiotem, np. YouTube, Search Console lub profil społecznościowy. Google zaznacza, że nie każdy panel da się obecnie przejąć.
• Proponować zmiany po weryfikacji albo przez opcję „Prześlij opinię”, jeśli panelu nie da się przejąć.
• Dla firmy lokalnej Google kieruje do Profilu Firmy w Google, który wyświetla się w wyszukiwarce i Mapach.

Na decyzję Google wpływa to, co da się znaleźć o podmiocie w niezależnych źródłach, i choć dane strukturalne z logo, sameAs i identyfikatorami ułatwiają powiązanie, wzmianek w mediach, rejestrach i serwisach branżowych nimi nie zastąpisz.

Na marginesie: od 4 czerwca 2026 Google udostępnia twórcom i wydawcom profile w wyszukiwarce (Search profiles), których przejęcie może utworzyć lub wzbogacić panel wiedzy, a od 16 września 2026 dokumentuje znaczek takiego profilu do umieszczenia na stronie. Na start funkcja działa w USA, dla twórców z dużą liczbą obserwujących, i na koniec września 2026 nie znalazłem potwierdzenia, że jest dostępna w Polsce.

Jak sprawdzić wdrożenie: test, walidator i Search Console

Używam czterech narzędzi. Każde pokazuje co innego.

Narzędzie	Co pokazuje	Ograniczenie
Test wyników z elementami rozszerzonymi (Rich Results Test)	wykryte typy obsługiwane przez Google, błędy i ostrzeżenia, test adresu lub kodu	sprawdza tylko typy, które Google wykorzystuje w wynikach; reszty grafu nie oceni
Walidator schema.org (validator.schema.org)	poprawność całego grafu względem słownika schema.org, także worksFor czy identifier	nie mówi nic o kwalifikacji do funkcji Google
Sprawdzenie adresu URL w Search Console	wersję strony widzianą przez Google, wykryte elementy rozszerzone po indeksacji	pojedynczy adres, nie cała witryna
Raporty wyników rozszerzonych w Search Console	poprawne i błędne elementy w skali witryny, trendy po wdrożeniach	raport pojawia się tylko dla wybranych typów, m.in. strony profilu i fragmenty opinii; dla Article, Organization i LocalBusiness go nie ma

Brak raportu dla Article czy Organization zaskakuje wiele osób, które szukają go w Search Console po wdrożeniu. To nie błąd. Google tworzy raport tylko dla obsługiwanych typów wyników rozszerzonych (np. stron profilu, fragmentów opinii czy produktów) i tylko wtedy, gdy znajdzie na stronie poprawne znaczniki, więc pusta lista przy artykułach mówi tylko tyle, że ten typ nie ma osobnego raportu. Jak włączyć Search Console w comiesięczną rutynę, opisuję w poradniku Google Search Console: jak korzystać.

Po publikacji zmian Google potrzebuje zwykle kilku dni na ponowne przeskanowanie i zaindeksowanie strony. Ważne adresy (strona główna, „O nas”, strony autorów) możesz zgłosić do ponownego zindeksowania w narzędziu do sprawdzania adresów URL.

Najczęstsze błędy przy danych strukturalnych autora i firmy

Błąd	Skutek	Poprawka
„dr Jan Kowalski, CEO, Firma X” w author.name	Google gorzej rozpoznaje autora	samo imię i nazwisko; stanowisko w opisie na stronie autora
autor jako „Redakcja” lub „admin”	brak powiązania treści z osobą	prawdziwy autor albo Organization, jeśli tekst jest firmowy
dane w JSON-LD inne niż w stopce lub Profilu Firmy	sprzeczne sygnały, ryzyko w weryfikacjach Google Ads i Merchant Center	jedno źródło danych firmy, z którego korzystają szablon, wtyczka i profile
dwa obiekty Organization (motyw i wtyczka)	niejednoznaczny opis firmy	wyłączenie jednego źródła, jeden @id
aggregateRating z własnych opinii na stronie firmy	brak gwiazdek, ryzyko ręcznego działania przy nadużyciu	usunięcie; opinie zbierane w Profilu Firmy i serwisach zewnętrznych
dateModified zmieniane bez zmiany treści	sygnał sprzeczny z wytycznymi o pomocnych treściach	aktualizacja daty tylko przy realnej zmianie
sameAs do profili, które nie należą do firmy lub autora	błędne powiązanie tożsamości	tylko oficjalne, aktywne profile

Ile kosztuje wdrożenie? Przykład liczbowy (symulacja)

Ile dodatkowych zapytań musiałoby przynieść wdrożenie, żeby się zwrócić? Policzyłem to dla firmy usługowej w pierwszym roku. To symulacja na założonych stawkach, żadna wycena konkretnego projektu.

Założenia: stawka pracy marketingowej 150 zł/h, stawka developera 200 zł/h. Wartość zapytania: marża z klienta w pierwszym roku 2 400 zł × 30% skuteczności zamykania, czyli 720 zł na zapytanie. Wariant A: konfiguracja wtyczki SEO i uzupełnienie danych firmy i autorów (8 h), utrzymanie 0,5 h miesięcznie. Wariant B: ręczny graf JSON-LD w motywie (16 h developera) plus przepisanie stron „O nas” i autorów (12 h), utrzymanie 1 h developera miesięcznie. Wariant C: wariant B plus porządek danych firmy w 20 katalogach i profilach (po 0,5 h na każdy).

Wariant	Wdrożenie	Utrzymanie / rok	Koszt w 1. roku	Zapytania do zwrotu / rok	Zapytania / mies.
A: wtyczka i dane	1 200 zł	900 zł	2 100 zł	2,9	0,24
B: własny graf i treść stron	5 000 zł	2 400 zł	7 400 zł	10,3	0,86
C: B + spójność danych w sieci	6 500 zł	2 400 zł	8 900 zł	12,4	1,03

Wnioski:

• Wariant A zwraca się przy około 3 dodatkowych zapytaniach w roku. Dla większości małych firm to rozsądny start, pod warunkiem że ktoś sprawdzi, co wtyczka generuje.
• Wariant C kosztuje ponad 4 razy więcej niż A, ale porządkuje dane, które sprawdzają też Google Ads i Merchant Center. Jeśli prowadzisz kampanie, część wartości to uniknięty przestój konta, którego ta tabela nie liczy.
• Efektu samych znaczników nie da się czysto zmierzyć. Zarządowi pokazuję więc próg zamiast obietnicy wzrostu ruchu: ile zapytań musiałoby przybyć, żeby wydatek się bronił, i porównuję go z konwersją stron przed i po zmianach treści.

Kolejność prac, którą stosuję przy wdrożeniu

1. Inwentaryzacja. Spisz wszystkie miejsca z danymi firmy: strona, Profil Firmy, KRS/CEIDG, profile społecznościowe, katalogi, Google Ads, Merchant Center. Ustal jedną wersję nazwy, adresu i telefonu.
2. Treść. Przepisz stronę „O nas” i utwórz strony autorów z konkretami. Podepnij podpisy pod artykułami do stron autorów.
3. Przegląd istniejących znaczników. Sprawdź stronę główną, „O nas” i jeden artykuł w teście wyników rozszerzonych i walidatorze schema.org. Zanotuj, co generuje motyw, a co wtyczka.
4. Graf. Organization (lub podtyp) na stronie głównej albo „O nas”, ProfilePage z Person na stronach autorów, BlogPosting z author i publisher na artykułach, LocalBusiness na stronach lokalizacji. Połącz je przez @id.
5. Test przed publikacją. Kod testujesz w Teście wyników rozszerzonych, a po wdrożeniu sprawdzasz adresy w Search Console.
6. Spójność poza stroną. Popraw dane w Profilu Firmy, profilach i katalogach, zaczynając od tych, które widać w wynikach wyszukiwania nazwy firmy.
7. Monitoring. Raz w miesiącu przejrzyj raporty wyników rozszerzonych w Search Console i ręczne działania. Po każdej zmianie motywu lub wtyczki SEO powtórz test na trzech wzorcowych adresach.

Dobrze uporządkowane dane firmy przydają się też poza Google, bo asystenci AI budują obraz firmy z wielu źródeł naraz, a sprzeczne informacje w rejestrach, katalogach i na stronie obniżają szansę, że opiszą Cię poprawnie. Jak to sprawdzić, pokazuję w artykule Czy ChatGPT poleca Twoją firmę.

Na czym opieram ten tekst

• Google Search Central: Article structured data
• Google Search Central: Organization structured data
• Google Search Central: ProfilePage structured data
• Google Search Central: Local business structured data
• Google Search Central: Review snippet structured data
• Google Search Central: General structured data guidelines
• Google Search Central: FAQ rich result — informacja o wycofaniu
• Google Search Central: Search Central documentation updates
• Google Search Central: AI features and your website
• Google Search Central: Optimizing for generative AI features on Google Search
• Google Search Central: Creating helpful, reliable, people-first content
• Search Console Help: Rich result status reports
• Search Console Help: Rich Results Test
• Schema.org: Schema Markup Validator
• Google Knowledge Panel Help: Get verified on Google
• Google Search Central: Add a Search profile badge to your website
• 9to5Google: Google Search profiles (4 czerwca 2026)
• Ustawa o świadczeniu usług drogą elektroniczną: art. 5 — informacje podawane przez usługodawcę