Jak zaprojektować stronę produktową pod SEO, GEO i pod kupującego

Strona produktowa ma dziś dwóch czytelników naraz. Pierwszy to kupujący, który przesuwa wzrok po nagłówkach, cenie i tabeli parametrów. Drugi to wyszukiwarka: klasyczny ranking Google oraz systemy składające odpowiedzi w AI Overviews, AI Mode, ChatGPT czy Perplexity. Obaj potrzebują tego samego materiału: jednoznacznej encji produktu, jawnych atrybutów i faktów, które da się sprawdzić. Przewodnik rozkłada […]

Mateusz Lomber 21 min czytania

Strona produktowa ma dziś dwóch czytelników naraz. Pierwszy to kupujący, który przesuwa wzrok po nagłówkach, cenie i tabeli parametrów. Drugi to wyszukiwarka: klasyczny ranking Google oraz systemy składające odpowiedzi w AI Overviews, AI Mode, ChatGPT czy Perplexity. Obaj potrzebują tego samego materiału: jednoznacznej encji produktu, jawnych atrybutów i faktów, które da się sprawdzić.

Przewodnik rozkłada projektowanie na warstwy: kolejność bloków, nagłówki, opis, warianty, dane strukturalne, media i sytuację, w której produktu zabrakło w magazynie. Przy mechanizmach opisanych w patentach Google znajdziesz numer dokumentu z odnośnikiem. Patent pokazuje, jak system może działać. Nie dowodzi, że Google używa go dziś w tej samej formie.

Strona produktowa pod SEO i GEO: jedna encja, dwóch odbiorców

SEO decyduje, czy strona trafi do indeksu i jak wysoko stanie w wynikach. GEO decyduje, czy fragment tej strony zostanie wybrany do odpowiedzi generatywnej i podany jako źródło. Obie warstwy pracują na tym samym dokumencie, więc projektujesz go raz, z myślą o obu.

SEO vs GEO dla strony produktowej: co się realnie różni

SEO nagradza wykrywalność i poprawność techniczną: indeksację, linkowanie wewnętrzne, trafność względem zapytania. GEO dokłada wymóg konwersacyjny. Fragment ma odpowiadać na pytanie jednoznacznie, bez czytania reszty strony. Jedna dobrze zbudowana karta produktu spełnia oba warunki jednocześnie.

Infografika porównuje cele SEO i GEO w czterech kategoriach, pokazując że jedna strona wymaga podwójnej optymalizacji.
SEO i GEO to dwa równoległe cele optymalizacji tej samej strony produktowej.

Google opisuje minimum w przewodniku o optymalizacji pod generatywne funkcje wyszukiwarki. Strona musi być zaindeksowana i kwalifikować się do wyświetlenia ze snippetem. Nie potrzebujesz nowych plików dla AI, osobnych znaczników ani wersji w Markdownie, a dane strukturalne nie są warunkiem obecności w wynikach generatywnych. O reszcie decyduje jakość i struktura samej treści.

Dwaj odbiorcy naraz: skanujący kupujący i parser

Kupujący nie czyta strony produktowej, tylko ją skanuje: przesuwa wzrok po nagłówkach, zatrzymuje się na cenie, tabeli parametrów i ocenie gwiazdkowej. Równolegle wyszukiwarka rozkłada treść na encję produktu, atrybuty i bloki odpowiadające na pytania. Potrzeby obu odbiorców zbiegają się przy wyraźnych nagłówkach, tabeli zamiast akapitu i sekcji FAQ.

GEO rozwija SEO i bez niego nie zadziała. Bez skanowania, indeksacji i linkowania model po prostu nie znajdzie strony. Zaufanie w obu kanałach budują te same sygnały doświadczenia, wiedzy, autorytetu i wiarygodności, które Google opisuje skrótem E-E-A-T. Zmienia się skala oceny. W klasycznym wyniku konkuruje cała strona, a w odpowiedzi generatywnej często pojedyncze zdanie, wiersz tabeli albo punkt listy.

AI Overviews i AI Mode mogą korzystać z techniki query fan-out. System rozbija pytanie na podtematy, wysyła kilka powiązanych wyszukiwań i składa odpowiedź z wielu źródeł. Pytanie o buty do biegania po asfalcie może więc uruchomić osobne wyszukiwania o amortyzację, drop czy wagę. Karta, która jawnie opisuje te atrybuty, ma więcej okazji, żeby trafić do któregoś z nich.

Architektura strony produktowej: modularne bloki, które AI potrafi wyciąć i zacytować

Stronę produktową buduj jako sekwencję semantycznie odrębnych bloków. Każdy blok ma sens wyrwany z reszty i jest obecny w HTML wygenerowanym przez serwer, zanim uruchomi się JavaScript.

Kolejność bloków: lead, specyfikacja, korzyści, FAQ, recenzje

Sześć typów bloków układa się w kolejność zgodną ze ścieżką decyzji kupującego:

  1. Lead z encją – pełna nazwa, marka, typ produktu i zdanie o tym, dla kogo jest (w praktyce 2-4 zdania)
  2. Tabela specyfikacji – pary atrybut-wartość, jedna wartość w komórce, jednostka przy liczbie
  3. Korzyści – co liczby z tabeli znaczą dla kupującego
  4. Zastosowania – konkretne scenariusze użycia
  5. FAQ – odpowiedzi na pytania, które klienci naprawdę zadają
  6. Recenzje – opinie klientów z datą i kontekstem użycia
Infografika przedstawia sześć modularnych bloków strony produktowej: lead, tabelę specyfikacji, korzyści, zastosowania, FAQ i recenzje
Sześć modularnych bloków strony produktowej w logicznej kolejności: od leadu do recenzji.

Reguła porządkowa jest jedna: jeden temat na sekcję. Gdy pod nagłówkiem pojawia się drugi wątek, zakładasz nową sekcję. Pierwsze zdanie pod nagłówkiem niesie odpowiedź, kolejne ją rozwijają.

Lead sprawdzisz prostym testem: usuń z niego wszystkie przymiotniki. Jeśli nadal wiadomo, co to za produkt, czyj jest i dla kogo, lead działa. Oto porównanie na fikcyjnym modelu butów:

Lead, który przechodzi test

  • Vento Run 3 to męskie buty do biegania po asfalcie marki Vento, z dropem 8 mm i wagą 270 g w rozmiarze 42.
  • Jedna cecha wyróżniająca w leadzie, pozostałe parametry w tabeli pod spodem.

Lead, który go oblewa

  • Poczuj lekkość każdego kroku! Nasze buty łączą styl, wygodę i nowoczesną technologię.
  • Pięć cech upchniętych w pierwszym zdaniu i ani słowa o nazwie modelu.

Fragmenty passage-ready: test wycięcia bloku

Fragment, który model może zacytować, to zwykle krótki akapit, wiersz tabeli albo punkt listy. W redakcyjnej praktyce dobrze działają akapity rzędu 40-60 słów z odpowiedzią w pierwszym zdaniu. To heurystyka redakcyjna. Google nie ogłosił takiego limitu, więc traktuj ją jako punkt wyjścia do własnych testów. Cytowalność wspierają też jednoznaczne nagłówki, mini-tabele i widoczne metadane: autor, data, źródło danych.

Test wycięcia bloku jest prosty. Skopiuj pojedynczą sekcję i przeczytaj ją bez reszty strony. Jeśli nadal odpowiada na konkretne pytanie, blok jest gotowy. Jeśli traci sens, dodaj kontekst do pierwszego zdania albo podziel blok na dwa. Zwroty „jak wspomnieliśmy wyżej” czy „ten model” bez nazwy to pierwszy sygnał, że fragment nie przetrwa wycięcia.

Renderowanie po stronie serwera kontra treść w JavaScript

Lead, tabela, cena i nazwa produktu powinny trafić do HTML generowanego przez serwer. Googlebot renderuje JavaScript, ale nie każdy odbiorca Twojej strony to robi. Pomiar Vercela z grudnia 2024 roku pokazał, że crawlery ChatGPT i Claude pobierają pliki JavaScript, ale ich nie wykonują, więc treść dorysowaną w przeglądarce pomijają. Merchant Center pisze z kolei wprost, że cena przekazywana skryptem po załadowaniu strony wywoła błąd niezgodności.

Zakładki i akordeony nie są problemem, jeśli ich treść siedzi w HTML od początku, a skrypt tylko ją pokazuje i chowa. Atrybuty główne warto jednak zostawić widoczne bez klikania. Kompletność pod AI obejmuje parametry, porównania wariantów, poradniki zakupowe, recenzje oraz dane o cenie i dostępności, bo pytania zadawane asystentom bywają dłuższe i bardziej sytuacyjne niż te wpisywane w wyszukiwarkę.

Nagłówki strony produktowej: hierarchia atrybutów zamiast listy fraz

H1 ma jedno zadanie: pokazać centralną encję i jej najważniejszy atrybut. Kolejność H1, H2 i H3 porządkuje wagę informacji, a płaska struktura, w której wszystko jest H2, nie mówi, co jest ważniejsze. Pisz językiem encji: pełne nazwy, jawne relacje, jednostki przy liczbach.

Test usunięcia: atrybut główny do nagłówka, pochodny do treści

Atrybut główny to taki, bez którego encja traci tożsamość. Test trwa trzy sekundy: usuń atrybut w myślach. Jeśli produkt przestaje być sobą, atrybut należy do nagłówka. Reszta trafia do treści i tabeli. Żeby sprawdzić, jakie encje maszyna widzi w Twoim tekście, użyj analizy encji w Google Cloud Natural Language API.

Nie upychaj dziesiątek atrybutów w H1. Każdy dorzucony parametr odbiera nagłówkowi ostrość. Marka i model idą do nagłówka w jednej kanonicznej formie, a szczegóły techniczne do tabeli.

Dobrze

  • H1: Vento Run 3 - męskie buty do biegania po asfalcie
  • H2 nazywa atrybut: Amortyzacja i drop, Jak dobrać rozmiar

Źle

  • H1: Buty biegowe tanie lekkie Vento Run 3 promocja męskie damskie 2026
  • H2 bez informacji: Opis, Dlaczego warto?, Dowiedz się więcej

Atrybuty wariantów w tytule i nagłówkach

Kolor, pojemność czy rozmiar generują długoogonowe zapytania w rodzaju „kurtka zimowa czarna XL”. Jawnie wystawiona wartość 64 GB albo rozmiar L to materiał, z którego wyszukiwarka dopasowuje stronę do takich zapytań. Wartość ukryta wyłącznie w selektorze JavaScript albo w nazwie pliku zdjęcia tego nie daje. Atrybut, który różnicuje warianty, może trafić do tytułu i nagłówka, a pełna lista dostępnych rozmiarów zostaje w treści.

Warianty produktu: jeden adres dla grupy czy osobne strony

Google w dokumentacji wariantów produktu (aktualizacja z 8 września 2026) opisuje dwa poprawne modele. W pierwszym wszystkie warianty wybiera się na jednej stronie, a adres zmienia się tylko parametrem. W drugim warianty są rozłożone na osobne, równorzędne strony. Wybór zależy od tego, czy warianty różnią się czymś więcej niż jednym atrybutem.

Dwa modele stron z wariantami produktu
Funkcja Jedna strona dla grupy Osobne strony wariantów
Wybór wariantu Selektor na stronie, bez przeładowania Przejście na inny adres, np. /kurtka/czarna
Adres kanoniczny Jeden dla całej grupy, zwykle adres bez wybranego wariantu Brak wspólnego adresu grupy, każda strona jest równorzędna
Wymóg adresów Każdy wariant da się otworzyć własnym adresem z parametrem Każdy wariant ma unikalny adres
Dane strukturalne ProductGroup z variesBy, warianty w hasVariant Pełna definicja ProductGroup powtórzona na każdej stronie
Kiedy wybrać Warianty różnią się jednym atrybutem, treść jest wspólna Wariant ma własne zdjęcia, opis i popyt w wyszukiwarce

W obu modelach każdy wariant potrzebuje własnego identyfikatora, np. sku lub gtin, a grupa wspólnego productGroupID. Poniżej skrócony przykład dla jednej strony z wariantami. Grupa ma wspólną nazwę, markę i adres bez wybranego wariantu, a każdy wariant własne SKU, GTIN, kolor, rozmiar i ofertę. Drugi wariant jest niedostępny, więc dostaje OutOfStock i nadal zostaje w znacznikach.

JSON-LD: ProductGroup z wariantami na jednej stronie
{
  "@context": "https://schema.org/",
  "@type": "ProductGroup",
  "name": "Vento Run 3",
  "url": "https://example.com/vento-run-3",
  "brand": { "@type": "Brand", "name": "Vento" },
  "productGroupID": "VR3",
  "variesBy": [
    "https://schema.org/color",
    "https://schema.org/size"
  ],
  "hasVariant": [
    {
      "@type": "Product",
      "name": "Vento Run 3 - czarne, rozmiar 42",
      "sku": "VR3-CZ-42",
      "gtin13": "5901234123457",
      "color": "czarny",
      "size": "42",
      "image": "https://example.com/zdjecia/vento-run-3-czarne.jpg",
      "offers": {
        "@type": "Offer",
        "url": "https://example.com/vento-run-3?wariant=czarne-42",
        "price": 429.00,
        "priceCurrency": "PLN",
        "availability": "https://schema.org/InStock"
      }
    },
    {
      "@type": "Product",
      "name": "Vento Run 3 - granatowe, rozmiar 43",
      "sku": "VR3-GR-43",
      "gtin13": "5901234123464",
      "color": "granatowy",
      "size": "43",
      "image": "https://example.com/zdjecia/vento-run-3-granatowe.jpg",
      "offers": {
        "@type": "Offer",
        "url": "https://example.com/vento-run-3?wariant=granatowe-43",
        "price": 429.00,
        "priceCurrency": "PLN",
        "availability": "https://schema.org/OutOfStock"
      }
    }
  ]
}

Problem zaczyna się przy układzie, którego dokumentacja nie przewiduje: osobnych stronach różniących się jednym słowem w tytule i niczym więcej. Takie adresy konkurują ze sobą, a wyszukiwarka może pokazać tylko jeden. Różnicuj je realną treścią albo scal na jednej stronie.

Opis produktu pod GEO: rekord danych zamiast tekstu reklamowego

Opis przegrywa, gdy algorytm nie wyciągnie z niego czystej encji. Marka, model i atrybuty muszą być jednoznaczne i spójne w treści oraz w danych strukturalnych. Traktuj każdy opis jak rekord: co to jest, czyje, z jakimi parametrami i do czego służy.

Marka i model w jednej kanonicznej formie

Nazwę marki i modelu zapisuj zawsze tak samo. Jeśli model występuje raz jako „Vento Run 3”, raz jako „Run3”, a raz jako „nowy Vento”, dopasowanie encji staje się mniej pewne. To samo dotyczy jednostek: waga podana raz w gramach, a raz w kilogramach utrudnia porównanie. Im jaśniej zapisujesz relację między produktem a cechą, tym mniej system zgaduje, czy liczba typu ekran 6,1 cala dotyczy tego produktu.

Dlaczego kopia opisu producenta nic nie wnosi

Opis producenta występuje w identycznej formie na dziesiątkach sklepów. Google traktuje duplikaty jako kwestię wyboru wersji: gdy strony są takie same, sam wskazuje tę, którą uzna za najlepszą do pokazania. Kolejna kopia tego samego tekstu nie ma w tym wyborze żadnego atutu. Unikalny opis odpowiada na cztery pytania: dla kogo, jaki problem rozwiązuje, jakie ma kompromisy i z czym go łączyć.

Opis jak rekord

  • Czas pracy na baterii: 11 h przy jasności 50% (pomiar własny, wrzesień 2026).
  • Klienci chwalą cichą pracę wentylatora, część zwraca uwagę na wagę 1,4 kg przy noszeniu w plecaku.

Opis jak slogan

  • Wyjątkowo wydajna bateria zapewni Ci wolność na długie godziny!
  • Deklaracja „do 14 h pracy” bez warunków pomiaru, choć opinie mówią o 6 h.

Unikalna wartość z UGC i własnych testów

Unikalność bierze się z własnego wkładu: analiz, testów, pomiarów i wniosków z recenzji. Google w wytycznych o pomocnych treściach pyta, czy strona dostarcza oryginalnych informacji, badań lub analiz i czy wnosi istotną wartość w porównaniu z innymi wynikami. Pyta też, czy piszesz pod konkretną liczbę słów, bo słyszałeś, że Google taką preferuje, i od razu odpowiada, że nie.

Krótki, zmierzony fakt (waga z opakowaniem, realna kompatybilność, wada zauważona przez klientów) daje więcej niż akapit ogólników.

Recenzje to materiał dowodowy o produkcie, którego konkurencja nie skopiuje. Żeby pracowały na widoczność, muszą być w HTML bez logowania i klikania, z datą przy każdej opinii. Na górze sekcji dodaj krótką syntezę („klienci chwalą cichą pracę, część narzeka na wagę”), a w formularzu zapytaj o kontekst: do czego, jak długo, w jakich warunkach. Pytanie o same gwiazdki daje wyłącznie gwiazdki.

Gdy deklaracja na stronie kłóci się z opiniami, popraw deklarację albo dopisz warunek pomiaru i nie usuwaj krytycznych recenzji.

Treść karty celuj we frazy zakupowe: model z parametrem, „opinie”, „cena”, „rozmiar”. Pytania poradnikowe w rodzaju „jak wybrać buty do biegania” lepiej obsłuży osobny poradnik z linkiem do karty.

Dane strukturalne strony produktowej: Product, Offer i spójność feedu ze stroną

Schema.org Product z Offer to techniczna deklaracja tego, co widać na stronie. Feed z Merchant Center i strona to dwa źródła informacji o tym samym produkcie, więc identyfikatory (SKU, GTIN, MPN), cena i dostępność muszą zgadzać się co do znaku.

Product snippet czy merchant listing: które właściwości są wymagane

Google rozróżnia dwa rodzaje wyników. Product snippet dotyczy stron, na których nie da się kupić produktu, np. recenzji czy porównań. Merchant listing dotyczy stron, na których klient może dokonać zakupu. Wymagania są różne:

Wymagane właściwości Product według Google
Funkcja Product snippet Merchant listing (kolumna wyróżniona)
Typ strony Recenzja, porównanie, strona bez zakupu Karta produktu w sklepie
Wymagane name oraz jedno z: review, aggregateRating, offers name, image, offers z price i priceCurrency
Zalecane w Offer nie dotyczy availability, itemCondition, shippingDetails, hasMerchantReturnPolicy

Tak wygląda poprawny zestaw dla karty w sklepie: trzy wymagane właściwości plus identyfikatory, marka i ocena. Kod wklejasz w <script type="application/ld+json">, a każda wartość musi odpowiadać temu, co widać na stronie. Dla czytelności pominęliśmy zalecane shippingDetails i hasMerchantReturnPolicy.

JSON-LD: Product na karcie w sklepie
{
  "@context": "https://schema.org/",
  "@type": "Product",
  "name": "Vento Run 3 - męskie buty do biegania",
  "image": [
    "https://example.com/zdjecia/vento-run-3-bok.jpg",
    "https://example.com/zdjecia/vento-run-3-podeszwa.jpg"
  ],
  "description": "Buty do biegania po asfalcie, drop 8 mm, waga 270 g w rozmiarze 42.",
  "sku": "VR3-CZ-42",
  "gtin13": "5901234123457",
  "brand": {
    "@type": "Brand",
    "name": "Vento"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": 4.6,
    "reviewCount": 128
  },
  "offers": {
    "@type": "Offer",
    "url": "https://example.com/vento-run-3",
    "price": 429.00,
    "priceCurrency": "PLN",
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition"
  }
}

Właściwości takie jak brand, gtin, sku, color czy description są zalecane, a każda z nich domyka opis encji. Od 7 lipca 2026 roku category w merchant listings przyjmuje tekst albo kod z taksonomii Google Product Category. Specyfikację spoza listy Google opiszesz w additionalProperty jako pary PropertyValue. Takie znaczniki sprawdzisz w Schema Markup Validator, bo Rich Results Test pokazuje tylko typy obsługiwane w wynikach rozszerzonych.

Spójność identyfikatorów feedu i strony

Spójność feedu i strony to praca priorytetu zero. Według dokumentacji Merchant Center produkt z niezgodną ceną może zostać odrzucony, a utrzymujące się rozbieżności mogą doprowadzić do zawieszenia konta. Ceny w HTML muszą dokładnie odpowiadać cenom przesłanym do Merchant Center. Tak samo pilnuj dostępności. Przy GTIN Google wymaga numeru nadanego przez producenta: nieprawidłowy lub cudzy numer to osobny błąd w Merchant Center, a jego brak ogranicza skuteczność oferty.

Diagram porównuje GTIN, cenę i dostępność między feedem Merchant Center a stroną produktową, wskazując że zgodność danych decyduje o akceptacji produktu
Zgodność GTIN, ceny i dostępności między feedem a stroną produktową warunkuje akceptację produktu w Merchant Center

Trzy źródła zgodne

  • Strona: komunikat o chwilowej niedostępności i zapis na powiadomienie
  • Schema: availability ustawione na OutOfStock
  • Feed: out_of_stock, ta sama cena co na stronie

Trzy źródła w rozjeździe

  • Strona: aktywny przycisk „Dodaj do koszyka”
  • Schema: InStock
  • Feed: out_of_stock i cena 399 zł przy 429 zł na stronie

Trzy warstwy strony muszą mówić to samo: widoczna treść, nagłówki i dane strukturalne. Zasady danych strukturalnych Google zabraniają oznaczania treści, której czytelnik nie widzi na stronie. AggregateRating ma odpowiadać ocenie widocznej na karcie, a marka i model mają jedną kanoniczną formę w treści i w znacznikach.

Rich Results Test i nowe raporty AI w Search Console

Weryfikację zaczynasz od Rich Results Test: wklejasz adres lub kod JSON-LD i sprawdzasz kwalifikację do wyników rozszerzonych. Raporty wyników rozszerzonych znajdziesz też w Search Console. Google nie gwarantuje jednak wyświetlenia danych strukturalnych, a same znaczniki nie zapewniają cytowania w AI Overviews.

Produkt niedostępny: co zrobić ze stroną, której nie da się kupić

Brak towaru to moment, w którym łatwo zmarnować lata pracy nad adresem. Decyzję ustawiają dwa pytania: czy produkt wróci i ile wart jest jego adres, czyli ile ma linków i ruchu. Google daje tu jasne wskazówki.

Przy chwilowym braku Google zaleca zostawić stronę i oznaczyć produkt jako niedostępny, bo kupujący nadal rozumie, co się dzieje, nawet jeśli nie może złożyć zamówienia.

Przy produkcie wycofanym na stałe liczy się, czy masz stronę, która zaspokaja tę samą potrzebę. Jeśli tak, przekierowanie 301 zaprowadzi tam klienta i wyszukiwarkę. Jeśli nie, adres powinien zwracać 404 lub 410. Google traktuje oba kody tak samo, więc wybór między nimi nie ma dla wyszukiwarki znaczenia.

SytuacjaCo zrobićNa co uważać
Chwilowy brak, produkt wróciZostaw adres i treść, oznacz OutOfStock, dodaj powiadomienie o dostępności i alternatywyStrona, schema i feed pokazują ten sam stan
Produkt sezonowyZostaw stronę przez cały rok z informacją o sezonieUsunięcie i ponowne dodanie to odbudowa widoczności od nowa
Wycofany, jest następcaPrzekierowanie 301 na nowy modelNastępca musi zaspokajać tę samą potrzebę
Wycofany, brak następcyKod 404 lub 410 i pomocna strona błędu z linkamiBez przekierowania na stronę główną
Nie wiesz, czy wróciZacznij od OutOfStockTę decyzję łatwo cofnąć, przekierowanie trudniej
Co zrobić z kartą niedostępnego produktu

Przy tysiącach wygaszonych SKU posortuj adresy według linków zewnętrznych i ruchu z Search Console. Adresy z wartością obsłuż ręcznie, resztę regułą. Po wdrożeniu sprawdź w Search Console, czy stare adresy nie trafiają do grupy soft 404.

FAQ, zdjęcia i wideo: warstwy, które trafiają do bezpośrednich odpowiedzi AI

Sekcję FAQ buduj z realnych pytań: z PAA, Search Console, wyszukiwarki wewnętrznej sklepu, recenzji i obsługi klienta. Zdjęcia ze spójnym tekstem alternatywnym oraz wideo z transkrypcją to materiał dowodowy o produkcie.

FAQ z realnych pytań i aktualne ograniczenia Google

Format pytanie-odpowiedź jest bliski temu, jak asystenci AI budują odpowiedzi. Zacznij odpowiedź od konkretu, zmieść sedno w jednym lub dwóch zdaniach (w praktyce zwykle 10-30 słów) i nazwij produkt w kanonicznej formie. Taka odpowiedź sprawdza się też w wyszukiwaniu głosowym.

Spójność obrazu, tekstu alternatywnego, podpisu i ImageObject

Każde zdjęcie potrzebuje opisowego tekstu alternatywnego, spójnego z podpisem i opisem produktu. Tekst alternatywny, podpis i ewentualne ImageObject mają mówić to samo co zdjęcie, bo systemy wizyjne potrafią same rozpoznać, co na nim jest. Własne zdjęcia z realnego użycia są trudniejsze do skopiowania niż packshot producenta. Obrazy skaluj pod wymiary wyświetlania, żeby nie spowalniały strony.

Wideo bez transkrypcji to treść, której system nie przeczyta

Wideo bez transkrypcji jest dla wielu systemów w dużej części nieczytelne, choć sklep płaci za jego produkcję. Transkrypcja pod nagraniem oraz VideoObject ze znacznikami Clip w hasPart zamieniają minuty nagrania w tekst i wskazują, w której sekundzie pada odpowiedź. Znaczniki JSON-LD sprawdzisz w Rich Results Test.

Boty systemów AI: kogo wpuścić w robots.txt

Dostawcy rozdzielają dziś roboty według celu, więc blokada jednego nie wyłącza pozostałych. Przed zmianą w robots.txt sprawdź, za co odpowiada dany bot:

RobotDo czego służySkutek blokady
OAI-SearchBot (OpenAI)Wyszukiwanie w ChatGPTStrona nie pojawi się w odpowiedziach wyszukiwania ChatGPT
GPTBot (OpenAI)Trenowanie modeliBrak wpływu na wyszukiwanie w ChatGPT
PerplexityBotWyniki Perplexity, bez trenowania modeliStrona nie będzie pokazywana w wynikach Perplexity
Google-ExtendedTrenowanie i grounding modeli GeminiBrak wpływu na Google Search i ranking
GooglebotIndeks Google, w tym AI Overviews i AI ModeStrona znika z wyszukiwarki, także z funkcji AI
Roboty wyszukiwarek i systemów AI

Poniżej przykład dla sklepu, który chce być polecany w wyszukiwaniu ChatGPT i Perplexity, ale nie oddaje treści do trenowania modeli. Robot czyta tylko jedną grupę reguł, tę z najbardziej pasującą nazwą, i pomija resztę, także User-agent: *. Dlatego blokady koszyka i konta klienta trzeba powtórzyć w grupie wpuszczonych botów.

robots.txt: wyszukiwanie AI tak, trenowanie nie
# Wyszukiwanie w ChatGPT i Perplexity: wpuszczamy
User-agent: OAI-SearchBot
User-agent: PerplexityBot
Disallow: /koszyk/
Disallow: /moje-konto/

# Trenowanie modeli OpenAI i Gemini: nie wpuszczamy
User-agent: GPTBot
User-agent: Google-Extended
Disallow: /

# Pozostałe roboty, w tym Googlebot
User-agent: *
Disallow: /koszyk/
Disallow: /moje-konto/

Blokada GPTBot nie zmienia widoczności w wyszukiwaniu ChatGPT. Blokada Google-Extended nie rusza Google Search, ale Gemini nie użyje wtedy Twoich treści także do groundingu odpowiedzi, więc tę decyzję podejmij świadomie.

Audyt strony produktowej pod SEO i GEO: kroki i 3 błędy, które kosztują widoczność

Audyt zacznij od próbki kart z jednej kategorii, a wnioski przenieś na cały katalog. O wyniku decyduje architektura i to, czy stronę da się rozłożyć na encje i fakty. Styl opisu ma tu drugorzędne znaczenie.

  1. Sprawdź, co widać bez JavaScriptu

    Otwórz kartę z wyłączonym JavaScriptem albo sprawdź wyrenderowany HTML w narzędziu do sprawdzania adresów URL w Search Console. Nazwa, cena, tabela parametrów i opinie mają być w kodzie strony.

  2. Przejdź test wycięcia bloków

    Czytaj każdą sekcję osobno. Fragment bez nazwy produktu i kontekstu przepisz tak, żeby pierwsze zdanie działało samodzielnie.

  3. Porównaj feed, stronę i schema

    Na próbce 20-30 SKU zestaw GTIN, cenę i dostępność z trzech źródeł. Każdy rozjazd to ryzyko odrzucenia oferty w Merchant Center.

  4. Zweryfikuj dane strukturalne

    Adres sprawdź w Rich Results Test, a właściwości spoza wyników rozszerzonych, np. additionalProperty, w Schema Markup Validator.

  5. Sprawdź unikalność opisu

    Wklej losowe zdanie opisu w cudzysłowie do Google. Jeśli wracają kolejne sklepy z tym samym tekstem, opis potrzebuje własnych faktów.

  6. Przejrzyj frazy w Search Console

    Filtruj zapytania z nazwą atrybutu („64 gb”, „rozmiar l”), pytaniami („czy”, „jak”) i ocenami („opinie”, „wady”). Braki w treści widać od razu.

  7. Zrób listę niedostępnych produktów

    Dla każdego adresu zapisz czas niedostępności, linki i ruch, a potem przypisz decyzję: OutOfStock, 301 albo 404 lub 410.

Infografika przedstawia trzy błędy stron produktowych ograniczające widoczność w SEO i GEO: skopiowane opisy, atrybuty ukryte w JavaScript oraz rozjazd danych między feedem a stroną
Trzy typowe błędy stron produktowych, które ograniczają widoczność w SEO i GEO.

Trzy błędy kosztują najwięcej: skopiowany opis producenta, atrybuty dostępne dopiero po wykonaniu JavaScriptu oraz rozjazd danych między feedem a stroną. Mechanizmy z patentów traktuj jako kierunek myślenia, a skutki sprawdzaj pomiarem. Zapisz stan wyjściowy z datą, wprowadź poprawki i porównaj wyniki po kwartale.

Najczęstsze pytania o stronę produktową pod SEO i GEO

Jak zaprojektować stronę produktową pod SEO i GEO?

Zbuduj ją z modularnych bloków: lead z encją, tabela specyfikacji, korzyści, zastosowania, FAQ i recenzje. Każdy blok ma sens wycięty z reszty i jest w HTML z serwera. Pierwsze zdanie pod każdym nagłówkiem niesie odpowiedź.

Co powinna zawierać strona produktowa pod SEO?

Jednoznaczny lead z marką i modelem, tabelę parametrów, unikalny opis z własnymi faktami, FAQ z realnych pytań, recenzje oraz dane strukturalne Product z Offer. Google nie wymaga konkretnej liczby słów. Liczy się to, czy strona odpowiada na pytania kupującego lepiej niż konkurencja.

Jakie znaczniki schema dodać do strony produktowej?

Na karcie, na której można kupić produkt, dodaj Product z wymaganymi name, image i offers (z price i priceCurrency). Warto dołożyć brand, gtin, sku, availability i aggregateRating zgodny z widoczną oceną. Warianty opisz przez ProductGroup.

Jak napisać opis produktu przyjazny dla AI i wyszukiwarek?

Pisz opis jak rekord danych: marka i model w jednej formie, jawne relacje między produktem a cechą, własne fakty z testów i recenzji. Kopia opisu producenta nie daje stronie niczego, czym mogłaby się wyróżnić. Odpowiedz na cztery pytania: dla kogo, jaki problem rozwiązuje, jakie ma kompromisy, z czym go łączyć.

Co zrobić ze stroną produktu, którego zabrakło w magazynie?

Jeśli produkt wróci, zostaw stronę i oznacz go jako OutOfStock w treści, schema i feedzie. Jeśli wycofano go na stałe, przekieruj adres 301 na następcę, a gdy następcy nie ma, zwróć 404 lub 410. Unikaj przekierowań na stronę główną.

Czym różni się GEO od SEO dla stron produktowych?

SEO odpowiada za wykrywalność i pozycję w wynikach. GEO odpowiada za to, czy fragment strony trafi do odpowiedzi ChatGPT, Perplexity czy AI Overviews jako źródło. To jedna strona optymalizowana podwójnie, bo GEO bez indeksacji i spójnej semantyki nie zadziała.

Źródła

  1. developers.google.com/search/docs/fundamentals/ai-optimization-guide – Google Search Central: optymalizacja witryny pod generatywne funkcje wyszukiwarki (wymóg indeksacji i snippetu, brak specjalnych plików i znaczników)
  2. developers.google.com/search/docs/appearance/ai-features – Google Search Central: funkcje AI a Twoja witryna (query fan-out, ruch z funkcji AI w raporcie skuteczności)
  3. developers.google.com/search/blog/2026/06/gen-ai-performance-reports – Google Search Central Blog: raporty skuteczności funkcji generatywnych w Search Console (czerwiec 2026)
  4. developers.google.com/search/docs/appearance/structured-data/product – Google Search Central: dane strukturalne produktu (product snippets i merchant listings, wymagane właściwości)
  5. developers.google.com/search/docs/appearance/structured-data/product-variants – Google Search Central: warianty produktu (ProductGroup, strony jedno- i wielostronicowe)
  6. developers.google.com/search/docs/appearance/structured-data/sd-policies – Google Search Central: ogólne zasady danych strukturalnych (zakaz oznaczania niewidocznej treści)
  7. developers.google.com/search/docs/fundamentals/creating-helpful-content – Google Search Central: tworzenie pomocnych, wiarygodnych treści (oryginalność, brak preferowanej liczby słów)
  8. developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls – Google Search Central: konsolidacja zduplikowanych adresów (wybór wersji kanonicznej)
  9. developers.google.com/search/docs/crawling-indexing/pause-online-business – Google Search Central: wstrzymanie sprzedaży online (produkt niedostępny zostaje na stronie)
  10. developers.google.com/search/blog/2011/05/do-404s-hurt-my-site – Google Search Central Blog: Do 404 errors hurt my site? (301 kontra 404 i 410, przekierowanie na stronę główną jako soft 404)
  11. developers.google.com/crawling/docs/troubleshooting/http-status-codes – Google: kody stanu HTTP a wyszukiwarka (jednakowe traktowanie błędów 4xx)
  12. developers.google.com/search/updates – Google Search Central: aktualizacje dokumentacji (wycofanie wyników rozszerzonych FAQ)
  13. developers.google.com/search/docs/appearance/structured-data/qapage – Google Search Central: dane strukturalne QAPage (strony z odpowiedziami użytkowników)
  14. support.google.com/merchants/answer/12159029 – Pomoc Merchant Center: niezgodna cena produktu (odrzucenie produktu, cena wstawiana skryptem)
  15. support.google.com/merchants/answer/12468409 – Pomoc Merchant Center: nieprawidłowy GTIN (wymogi numeru GTIN)
  16. vercel.com/blog/the-rise-of-the-ai-crawler – Vercel: The rise of the AI crawler (crawlery AI a JavaScript, grudzień 2024)
  17. developers.openai.com/api/docs/bots – OpenAI: roboty OpenAI (OAI-SearchBot, GPTBot, ChatGPT-User)
  18. docs.perplexity.ai/docs/resources/perplexity-crawlers – Perplexity: roboty Perplexity (PerplexityBot i Perplexity-User)
  19. developers.google.com/crawling/docs/crawlers-fetchers/google-common-crawlers – Google: popularne roboty Google (Google-Extended)
  20. developers.google.com/crawling/docs/robots-txt/robots-txt-spec – Google: jak Google interpretuje specyfikację robots.txt (jedna obowiązująca grupa reguł na robota)
  21. search.google.com/test/rich-results – Google Rich Results Test (kwalifikacja do wyników rozszerzonych)
  22. validator.schema.org – Schema Markup Validator (walidacja pełnego słownika schema.org)
  23. schema.org/additionalProperty – Schema.org: additionalProperty (parametry jako PropertyValue)
  24. salsify.com/blog/how-to-do-generative-engine-optimization-geo-for-ecommerce – Salsify: GEO dla e-commerce (strukturyzowanie danych produktowych, źródło EN)
  25. whippetcreative.com/product-page-seo-mistakes-ecommerce-sales – Whippet Creative: błędy SEO na stronach produktowych (frazy zakupowe kontra informacyjne, źródło EN)
Udostępnij:

Dodaj komentarz

Twój email nie zostanie opublikowany. Pola wymagane oznaczone są gwiazdką.