Opinie klientów jako keyword research: od UGC do zapytania potwierdzonego w GSC

Opinie klientów to najbardziej niedoceniane źródło fraz kluczowych w e-commerce. W naszym pilotażu (19 kart produktowych z 5 sklepów) wyodrębniliśmy 340 unikalnych n-gramów z recenzji, z których tylko 14% miało potwierdzony popyt w GSC lub DataForSEO – ale te 47 fraz to frazy, których żaden producent nie umieścił w opisie produktu. Pipeline jest prosty: wyodrębnij n-gramy z opinii, zwaliduj popyt w GSC/AlsoAsked/DataForSEO, przypisz frazę do PDP, kategorii lub bloga. Warunek: opinie muszą być w HTML, nie w widgecie JavaScript ani iframe – bo tylko wtedy crawler (i systemy AI Search) je widzi. Producent opisuje produkt językiem specyfikacji, copywriter językiem marketingu, a klient pisze „fajne buty ale po 3 miesiącach podeszwa się odkleila”. Ten język – potoczny, oparty na doświadczeniu, nieprzefiltrowany przez marketing – często pokrywa się z zapytaniami, które użytkownicy wpisują w Google. Mechanizm ten łączy się bezpośrednio z extractability – zdolnością systemów AI do wyciągania odpowiedzi z treści: jeśli recenzja jest niewidoczna dla crawlera, żaden system retrieval nie wykorzysta zawartych w niej fraz.

Dlaczego język klientów różni się od opisu producenta?

Producent pisze: „Podeszwa wykonana z termogumy o podwyższonej odporności na ścieranie”. Klient pisze: „podeszwa nie ściera się nawet na betonie” albo „po roku intensywnego użytkowania podeszwa wygląda jak nowa”. Obie wersje opisują tę samą cechę, ale język klienta jest bliższy temu, jak ludzie formułują zapytania w wyszukiwarce. Analogiczne zjawisko opisujemy w kontekście sentymentu i aspektów w recenzjach produktowych – Google analizuje nie tylko słowa, ale także kontekst aspektowy wypowiedzi.

Patent US8700621B1 opisuje mechanizm identyfikacji fraz, które powtarzają się w treściach generowanych przez użytkowników (User-Generated Content) i mogą stanowić sygnał popytu. Patent US8538989B1 (Assigning Weights to Parts of a Document) opisuje mechanizm przypisywania różnych wag poszczególnym częściom dokumentu na podstawie ich struktury DOM – co oznacza, że sekcja UGC na karcie produktowej może być ważona inaczej niż opis producenta. Nie oznacza to, że Google używa recenzji jako źródła keyword research – ale koncepcja jest taka sama: język użytkownika zawiera frazy, których producent nie przewidział, a które mają realny popyt.

Jak bezpiecznie wydobywać frazy z UGC?

Wydobywanie fraz z recenzji wymaga kilku kroków ostrożności. Nie kopiujemy recenzji – wyodrębniamy n-gramy (ciągi 2-4 słów) i liczymy ich powtarzalność. N-gramy warto następnie powiązać z encjami, żeby zrozumieć, które atrybuty produktu klienci opisują najczęściej. Usuwamy dane osobowe (PII): imiona, adresy, numery zamówień. Nie publikujemy surowych cytatów z recenzji jako treści strony – to treść użytkownika, nie nasza. Podejście to ma bezpośredni związek z tym, jak AI wybiera źródła do cytowania – systemy retrieval preferują treści, które jasno prezentują fakty, a nie surowe kopie UGC.

Wartość UGC w e-commerce potwierdzają twarde dane. Według raportu Yotpo (2026), shopperzy widzący UGC konwertują o 161% częściej, a już 10 recenzji generuje 53% wzrost sprzedaży. Problem w tym, że te recenzje muszą być widoczne nie tylko dla użytkownika, ale też dla systemów retrieval.

To podejście odpowiada koncepcji Voice of Customer (VoC) – systematycznemu wydobywaniu insightów z języka klientów. Różnica polega na tym, że tradycyjny VoC służy do rozwoju produktu, a tutaj wykorzystujemy go do keyword research. Pipeline w GSCGA MCP wygląda następująco: pobieramy widoczne recenzje z PDP (ecom_ugc_query_opportunity_audit), wyodrębniamy n-gramy 2-4 słowa, filtrujemy te z minimum 3 powtórzeniami, usuwamy frazy generyczne („bardzo polecam”, „super produkt”) i walidujemy popyt w GSC, AlsoAsked i DataForSEO.

Dlaczego powtarzalność nie wystarcza?

Fraza powtarzająca się w 10 recenzjach nie oznacza automatycznie, że ludzie jej szukają. „Szybka dostawa” pojawia się w recenzjach najczęściej, ale nikt nie szuka „szybka dostawa [nazwa sklepu]” w kontekście produktu. Powtarzalność w UGC sygnalizuje ważność cechy dla kupującego, ale dopiero walidacja w danych popytowych (GSC, volume w DataForSEO, AlsoAsked) potwierdza, że ludzie aktywnie szukają informacji na ten temat. Proces ten jest analogiczny do kalibracji scoringu SEO danymi z GSC – bez twardej walidacji popytowej operujemy na założeniach, nie na danych.

W naszym pilotażu (19 PDP z 5 sklepów) z 340 unikalnych n-gramów o powtarzalności >= 3, tylko 47 (14%) miało potwierdzony popyt w GSC lub DataForSEO. Reszta to frazy ważne dla klientów, ale nie wyszukiwane – co nie znaczy, że są bezwartościowe (mogą trafiać do opisów produktów wzbogaconych o information gain), ale nie nadają się na odrębne landing page’e.

Konwersja n-gramów UGC na potwierdzone frazy

Etap	Liczba fraz	% wejścia	Komentarz
Unikalne n-gramy (2-4 słowa, powtarzalność ≥ 3)	340	100%	Wyodrębnione z 19 PDP
Po usunięciu fraz generycznych	218	64%	„Bardzo polecam”, „super produkt” itp.
Po usunięciu duplikatów semantycznych	183	54%	Lematyzacja + deduplikacja
Z potwierdzonym popytem (GSC / DataForSEO / AlsoAsked)	47	14%	Minimum 1 źródło potwierdza popyt
Silne frazy (2-3 źródła potwierdzające)	12	4%	Priorytet wdrożenia

Walidacja GSC, AlsoAsked i DataForSEO

Każdą frazę z UGC walidujemy w trzech źródłach. GSC pokazuje, czy nasz serwis już pojawia się na zapytania zawierające tę frazę (istniejący popyt). AlsoAsked pokazuje, czy fraza pojawia się w pytaniach powiązanych (pokrewny popyt). DataForSEO pokazuje estymowany wolumen wyszukiwań (potencjalny popyt). Wyszukiwarka wewnętrzna sklepu może dostarczyć dodatkowego kontekstu – zapytania klientów w search box to kolejne źródło fraz kluczowych, które warto korelować z danymi z recenzji.

Fraza jest „potwierdzona”, gdy ma potwierdzenie w minimum jednym z tych źródeł. Fraza jest „silna”, gdy ma potwierdzenie w dwóch lub trzech źródłach. W pilotażu 47 potwierdzonych fraz rozłożyło się następująco: 12 silnych (potwierdzenie w 2-3 źródłach), 35 potwierdzonych (potwierdzenie w jednym źródle).

Kiedy fraza trafia na PDP, kategorię albo blog?

Nie każda fraza z recenzji powinna trafić na stronę produktu. Reguły przypisania: jeśli fraza dotyczy konkretnego atrybutu produktu („rozmiar 42 za mały”), trafia do opisu lub FAQ na PDP – w miejsce, które pełni funkcję nagłówka adresu odpowiedzi na karcie produktu. Jeśli fraza dotyczy kategorii produktów („buty do biegania po asfalcie vs po lesie”), trafia na stronę kategorii lub poradnik. Jeśli fraza dotyczy problemu użytkowego („jak prać buty sportowe”), trafia na blog. Jeśli fraza dotyczy porównania („Nike vs Adidas running”), trafia na dedykowany artykuł porównawczy.

W pilotażu rozkład destination dla 47 potwierdzonych fraz:

Destination potwierdzonych fraz UGC

Destination	Liczba fraz	Udział	Przykład frazy
PDP FAQ	19	40%	„czy rozmiar jest standardowy”
Kategoria / podkategoria	11	23%	„buty do biegania po asfalcie”
Blog / poradnik	13	28%	„jak prać buty sportowe”
Artykuł porównawczy	4	9%	„Nike vs Adidas do biegania”
Razem	47	100%

Największa pula trafia do FAQ na kartach produktowych – bo klienci pytają o konkretne cechy produktów. Warto to skorelować z pytaniami generowanymi z treści strony i walidowanymi w GSC. Prawidłowa warstwa semantyczna Product schema jest kluczowa, aby te FAQ były poprawnie zindeksowane i widoczne jako rich results.

Google dokumentacja Review Snippet wymaga ratingValue, reviewCount i ratingCount w typie schema.org AggregateRating, a indywidualne recenzje powinny być oznaczone typem Review z właściwościami author, reviewBody i reviewRating. Ale samo schema to za mało – Reviews System Google priorytetyzuje „in-depth, expert-written content with original research”, co oznacza, że identyczne recenzje skopiowane z feeda producenta mogą zostać zdegradowane, nawet jeśli mają poprawne znaczniki.

Trzy różne znaczenia „opinia jest na stronie”

Sklep mówi: „mamy opinie na stronie”. Ale to może oznaczać trzy różne rzeczy techniczne, z których każda ma inny wpływ na retrieval. Problem ten jest bezpośrednio powiązany z koncepcją rendering readiness – czy AI widzi treść strony: forma renderowania recenzji determinuje, które systemy mogą z nich korzystać.

Opinia w HTML. Treść recenzji jest wyrenderowana w HTML i widoczna zarówno dla użytkownika, jak i crawlera. To idealna sytuacja. Retrieval widzi tekst recenzji, może wyodrębniać z niego frazy, a schema AggregateRating/Review ma potwierdzenie w widocznej treści.

Opinia w widgecie JavaScript. Recenzje ładowane są przez widget (Trustpilot, Opineo, własny API). W raw HTML ich nie ma – pojawiają się dopiero po wykonaniu JavaScript. Crawler, który nie renderuje JS, nie widzi treści recenzji. Google renderuje JS (Googlebot WRS), ale z opóźnieniem i nie zawsze kompletnie. Systemy AI Search mogą nie renderować JS w ogóle. Patent US20250094511A1 (Proactive Query and Content Suggestion) opisuje mechanizm proaktywnego generowania sugestii zapytań i treści na podstawie zdarzeń zmiany – co oznacza, że zmiana w sekcji recenzji (nowa opinia) może wyzwalać ponowną analizę treści strony przez system.

Opinia w iframe/API. Recenzje ładowane z zewnętrznej domeny w iframe. Treść technicznie nie jest częścią strony – jest osadzona z innego źródła. Crawler nie przenosi treści iframe do indeksu strony macierzystej. Z perspektywy retrieval te recenzje nie istnieją.

Porównanie trzech typów renderowania recenzji

Cecha	HTML natywny	Widget JS	Iframe / API zewnętrzne
Crawlowalność (Googlebot)	Pełna	Częściowa (wymaga WRS)	Brak (treść na innej domenie)
Indeksowalność treści recenzji	Tak	Tak, z opóźnieniem	Nie
Widoczność dla AI Search	Pełna	Ograniczona (zależy od crawlera)	Brak
Obsługa schema Review	Pełna zgodność	Schema bez widocznej treści w raw HTML	Schema bez potwierdzenia w DOM
Extractability dla n-gramów	Natychmiastowa	Po renderze JS	Niedostępna
Ryzyko rich snippet	Niskie	Średnie	Wysokie (utrata gwiazdek)
Rekomendacja	Preferowany	Akceptowalny z fallback SSR	Do migracji na HTML

Jak wykonujemy test raw vs rendered?

Dla każdego PDP porównujemy pięć warstw: raw HTML (źródło strony bez JavaScript), rendered HTML (po pełnym renderze), Review/AggregateRating JSON-LD (schema), widoczny tekst recenzji (to co widzi użytkownik), treść dostępna bez kliknięcia (recenzje widoczne od razu vs recenzje ukryte za „Pokaż więcej”). Patent US11609943B2 (Contextual Content Distribution) opisuje mechanizm dystrybucji treści w oparciu o kontekst sekcji strony – system analizuje tematykę poszczególnych fragmentów dokumentu, co implikuje zdolność do rozróżniania sekcji UGC od treści producenta na tej samej stronie.

Narzędzia: Crawl4AI do porównania raw vs rendered, content_rendered_component_inventory_pack do identyfikacji komponentów recenzji, ecom_template_leakage_audit do sprawdzenia, czy widget recenzji jest szablonem czy unikatową treścią.

Schema z oceną, ale bez treści recenzji

Częsty problem: sklep ma AggregateRating w JSON-LD (np. ratingValue 4.7, reviewCount 89), ale na stronie nie ma widocznych treści recenzji. Ocena istnieje w schema, ale dowodu – treści recenzji – nie ma ani w DOM, ani w widocznej treści. To sytuacja analogiczna do schema-only w naszym badaniu DOM vs Product schema: deklaracja bez potwierdzenia.

Google w wytycznych dotyczących danych strukturalnych wyraźnie mówi, że AggregateRating powinno odpowiadać widocznym recenzjom na stronie. Jeśli schema deklaruje 89 recenzji, a na stronie nie ma żadnej – to ryzyko utraty rich snippets i obniżenia zaufania do danych strukturalnych serwisu.

Opinie negatywne, moderacja i duplikacja recenzji

Opinie negatywne to paradoksalnie najcenniejsze źródło fraz kluczowych. Klient piszący „bateria trzyma tylko 2 godziny zamiast deklarowanych 6” generuje frazę, której nie ma w opisie producenta, a która odpowiada na realne zapytanie („bateria [model] ile trzyma”). Usuwanie negatywnych opinii z myślą o lepszym wizerunku oznacza jednoczesne usuwanie unikalnych fraz kluczowych z karty produktowej.

Moderacja opinii jest konieczna (spam, wulgaryzmy, dane osobowe), ale powinna być chirurgiczna. Usunięcie opinii zawierającej spam to jedno, a usunięcie opinii, bo zawiera krytykę produktu – to drugie. Reviews System Google analizuje autentyczność i różnorodność recenzji. Profil opinii złożony wyłącznie z ocen 5/5 i fraz typu „super polecam” jest sygnałem niskiej wiarygodności, nie wysokiej jakości.

Osobny problem to duplikacja recenzji między sklepami. Jeśli 20 sklepów wyświetla identyczne opinie pobrane z feeda producenta, żaden z nich nie zyskuje przewagi informacyjnej. Google traktuje to jako zduplikowaną treść – nawet jeśli technicznie to UGC. Wartość mają recenzje unikalne dla danego sklepu, napisane przez jego klientów, bo tylko one generują frazy, których konkurencja nie ma.

Ile recenzji potrzebuje karta produktowa?

Nie istnieje jeden próg, ale dane z naszego pilotażu i badań zewnętrznych wskazują trzy poziomy. Poniżej 5 recenzji na PDP n-gramy nie mają wystarczającej powtarzalności, żeby wyodrębnić wiarygodne frazy – to zbyt mała próba. Między 5 a 20 recenzjami pojawiają się pierwsze powtarzalne n-gramy (bigramy i trigramy), ale walidacja popytowa zwykle potwierdza mniej niż 10% z nich. Powyżej 20 recenzji zaczynamy widzieć stabilne wzorce – w naszym pilotażu PDP z ponad 20 opiniami generowały średnio 3,2 potwierdzone frazy kluczowe na produkt.

Dane Yotpo wskazują, że 10 recenzji generuje 53% wzrost konwersji, a 50+ recenzji to punkt, w którym AggregateRating w schema staje się statystycznie wiarygodny dla systemów retrieval. Z perspektywy keyword research z UGC rekomendujemy minimum 15-20 recenzji na PDP, zanim warto uruchamiać pipeline ekstrakcji n-gramów.

Checklista dla właścicieli e-commerce

Zweryfikuj, w jakiej warstwie są Twoje recenzje (HTML, JS widget, iframe). Jeśli w widgecie JS – sprawdź, czy Google je indeksuje (Search Console > Sprawdź URL > Testuj na żywo). Jeśli w iframe – przenieś treść recenzji do HTML strony. Upewnij się, że schema AggregateRating/Review ma potwierdzenie w widocznej treści. Wyodrębnij n-gramy z recenzji i zwaliduj popyt w GSC/DataForSEO. Potwierdzone frazy przypisz do właściwego destination (PDP FAQ, kategoria, blog). Nie kopiuj treści recenzji jako opisu produktu – to jest treść użytkownika, nie Twoja. Jeśli nie masz zasobów wewnętrznych na przeprowadzenie tego procesu, audyt treści zidentyfikuje luki w pokryciu fraz z UGC, a kompleksowe pozycjonowanie sklepu internetowego obejmuje wdrożenie tych fraz w strukturze serwisu.

Gary Illyes ostrzega przed konsekwencjami niskiej jakości UGC w podcaście Search Off the Record: jeśli Google wykryje wzorzec niskiej jakości w sekcji UGC, może obniżyć priorytet crawlowania tej konkretnej części strony. Renderowanie opinii w sposób widoczny dla crawlera, ale bez zapewnienia ich unikalności, może przynieść efekt odwrotny od zamierzonego.

Case study: opinie w DOM vs brak opinii w schema – neonet.pl

Przeanalizowaliśmy stronę produktową neonet.pl (ASUS TUF Gaming A16, sierpień 2026) pod kątem obecności i dostępności treści UGC dla systemów AI.

DOM: opinie istnieją. Strona zawiera sekcję opinii dostępną pod kotwicą #Opinie, a meta tag og:title explicite reklamuje „tysiące opinii w Neonet.pl”. Użytkownik widzi opinie, może je przewijać i filtrować.

Schema: opinie nie istnieją. JSON-LD Product nie zawiera ani aggregateRating, ani review. System AI czytający schema widzi produkt bez żadnych opinii – tak jakby nikt go nie oceniał. To klasyczna rozbieżność DOM/schema: widoczna treść UGC nie jest wystawiona w formacie maszynowym.

Implikacja dla AI visibility: według danych Yotpo, UGC podnosi konwersję o 161%. Ale z perspektywy AI Search opinie mają dodatkową funkcję – dostarczają fraz kluczowych w języku użytkownika (np. „cichy wentylator”, „ciężki, ale mocny”, „bateria trzyma 6h”), których nie ma w oficjalnym opisie producenta. Jeśli te opinie istnieją tylko w renderowanym DOM (często lazy-loaded), systemy AI mogą ich w ogóle nie widzieć. neonet.pl traci podwójnie: retrieval nie znajduje opinii w schema, a crawlery AI mogą nie renderować sekcji ładowanej dynamicznie. Problem ten jest częścią szerszego zjawiska opisanego w naszym badaniu retrieval AI Search na danych z GSC.

Dane porównawcze: neonet.pl nie pojawia się w top 4 polskich e-commerce pod kątem AI citations (mediaexpert 27 929 cytowań ChatGPT, euro 25 179, morele 8 946, x-kom 6 755). Brak opinii w schema to jeden z potencjalnych czynników – sklepy z bogatszą warstwą danych strukturalnych (w tym recenzjami) mogą być preferowane przez retrieval jako źródła bardziej kompletne informacyjnie.

Case study cross-industry: zooplus vs hebe – jak recenzje wpływają na AI retrieval

Jeśli neonet.pl miał recenzje w DOM, ale nie w schema, to jak wygląda rendering opinii w innych branżach? Porównaliśmy dwa serwisy z różnym podejściem do UGC. Dane z Ahrefs i crawla (szacunkowy snapshot, sierpień 2026).

zooplus.pl: aggregateRating bez indywidualnych recenzji. Na stronach kolekcji zooplus (np. FURminator) JSON-LD zawiera aggregateRating z ratingValue i ratingCount dla większości produktów – ale brak jest indywidualnych obiektów Review w schema. AI retrieval widzi „4.8/5 na podstawie 234 ocen”, ale nie ma dostępu do treści poszczególnych opinii przez schema. Mimo to zooplus osiąga 5 364 cytowań ChatGPT – co sugeruje, że sama obecność aggregateRating (nawet bez pełnych recenzji) jest sygnałem wiarygodności dla retrieval.

hebe.pl: strona produktowa w top pages. W top 10 stron hebe.pl pod kątem ruchu organicznego pojawia się konkretna strona produktowa – missha-krem-bb z 16,1 tys. sesji i 103 keywords. To rzadkość: w większości sklepów top pages to kategorie, nie produkty. Fakt, że pojedyncza PDP dominuje ranking, sugeruje silny UGC (recenzje, pytania użytkowników) lub unikalny content na stronie produktowej. Hebe ma 3 058 cytowań ChatGPT i aż 2 653 w Copilot – proporcja Copilot/ChatGPT (86%) jest jedną z najwyższych w analizowanych sklepach.

Kontrast z eobuwie.pl: eobuwie.pl, bez crawlowalnych stron produktowych i prawdopodobnie bez renderowanych recenzji w HTML (serwis jest JS-heavy), ma 0 cytowań. Brak UGC dostępnego dla crawlerów = brak sygnałów wiarygodności = brak cytowań. CCC (ccc.eu) z 2 370 cytowaniami ChatGPT i crawlowalnymi kategoriami przynajmniej oferuje AI retrieval jakieś treści do ekstrakcji – nawet jeśli to listy produktów, a nie recenzje.

Wniosek: rendering opinii w kontekście AI retrieval to spectrum: od pełnych obiektów Review w schema (idealnie), przez aggregateRating bez treści recenzji (zooplus – dobre), po brak jakichkolwiek sygnałów UGC (eobuwie – katastrofalne). Niezależnie od branży, minimalne wymaganie to aggregateRating w JSON-LD – to „bilet wstępu” do pool cytowań AI.

Źródła i narzędzia

Dane popytowe: Google Search Console (zapytania z kliknięciami i wyświetleniami), DataForSEO (estymowany wolumen wyszukiwań i SERP features), AlsoAsked (pytania powiązane z People Also Ask). Analiza UGC: GSCGA MCP (ecom_ugc_query_opportunity_audit, ecom_review_sentiment_ranking_audit), Crawl4AI (porównanie raw vs rendered HTML). Rendering: content_rendered_component_inventory_pack, ecom_template_leakage_audit. Schema: ecom_product_schema_audit, ecom_feed_page_schema_consistency_audit. Patenty Google analizowane jako źródła koncepcyjne – opisane w sekcji zastrzeżeń poniżej.

Zastrzeżenie dotyczące patentów

Patenty przywołane w tym artykule opisują mechanizmy zidentyfikowane w zgłoszeniach patentowych Google. Sam fakt istnienia patentu nie stanowi dowodu na to, że dany mechanizm jest obecnie aktywnie wykorzystywany w algorytmach wyszukiwania lub rankingu. Patenty analizowane są tutaj jako źródło koncepcyjne – pomagają zrozumieć kierunki myślenia inżynierów Google, ale nie powinny być traktowane jako dokumentacja aktualnie działających systemów.

• US8700621B1 (Generating Query Suggestions from User Generated Content) – generowanie sugestii zapytań z UGC poprzez ekstrakcję powtarzalnych bigramów z recenzji i blogów produktowych.
• US8538989B1 (Assigning Weights to Parts of a Document) – przypisywanie różnych wag poszczególnym częściom dokumentu na podstawie struktury DOM.
• US20250355958A1 (On-Demand Generative Response Simplification) – upraszczanie odpowiedzi generatywnych na żądanie, w kontekście przetwarzania treści UGC przez systemy AI.
• US20230342411A1 (Multi Source Extraction and Scoring of Short Query Answers) – ekstrakcja i scoring odpowiedzi z wielu źródeł, w tym treści generowanych przez użytkowników.
• US20170011116A1 (Generating Elements of Answer-Seeking Queries and Elements of Answers) – dekompozycja zapytań i odpowiedzi na elementy składowe w kontekście wyszukiwania.
• US8898296B2 (Detection of Boilerplate Content) – wykrywanie szablonowej treści boilerplate, istotne dla odróżniania unikalnych recenzji od zduplikowanych opisów.
• US12222995B2 (Web Page Transformer for Structure Information Extraction) – wykorzystanie modeli transformer do ekstrakcji informacji strukturalnej ze stron, w tym sekcji recenzji.
• US9665617B1 (Generating Stable Identifiers for Nodes Including Primary Content) – generowanie stabilnych identyfikatorów dla węzłów DOM zawierających treść główną, istotne dla rozpoznawania sekcji UGC.
• US20250094511A1 (Proactive Query and Content Suggestion) – proaktywne generowanie sugestii zapytań i treści na podstawie zdarzeń zmiany w dokumencie.
• US11609943B2 (Contextual Content Distribution) – dystrybucja treści w oparciu o kontekst tematyczny sekcji strony.