Duże platformy WordPress nie wypadają z odpowiedzi generowanych przez AI dlatego, że mają słabą treść. Wypadają, bo przez lata rozwoju nikt nie odpowiadał za architekturę informacji, a dostęp crawlerów bywa zablokowany na poziomie, którego nie widać w panelu WordPressa. Ten artykuł pokazuje, co da się w tym kontrolować, co jest udokumentowane, a co pozostaje hipotezą.
Co się zmienia, a co zostaje bez zmian
Użytkownik coraz częściej dostaje jedną odpowiedź zamiast listy linków. AI Overviews i AI Mode w Google, ChatGPT, Perplexity i Copilot syntetyzują treść z kilku źródeł i mogą wskazywać źródła wspierające wygenerowaną odpowiedź.
Zmienia się sposób, w jaki użytkownik dociera do treści. W przypadku Google nie oznacza to jednak powstania odrębnego zestawu zasad optymalizacji. Google potwierdza, że AI Overviews i AI Mode wykorzystują podstawowe systemy rankingowe i systemy jakości wyszukiwarki. Z perspektywy Google optymalizacja pod generatywną AI nadal jest więc SEO.
Fundament SEO zostaje. Poprawna indeksacja, sensowna struktura, wiarygodne źródła i jakość techniczna działają zarówno na wyniki klasyczne, jak i funkcje generatywne. Google wykorzystuje między innymi RAG, czyli generowanie wspomagane wyszukiwaniem, oraz rozszerzanie zapytań, w ramach którego model może wykonywać równocześnie kilka powiązanych wyszukiwań, aby zebrać informacje potrzebne do przygotowania odpowiedzi.
Powiedzmy też wprost rzecz, którą część rynku pomija: spełnienie wymagań technicznych i stosowanie dobrych praktyk nie gwarantuje indeksowania ani pojawienia się treści w funkcjach AI. Wszystko, co można dziś zrobić odpowiedzialnie, to zadbać o techniczne fundamenty, dostępność treści oraz ich rzeczywistą wartość dla odbiorcy. Google szczególnie podkreśla znaczenie unikalnych treści eksperckich, które wnoszą informacje i perspektywę niedostępne powszechnie w innych źródłach.
Cztery warstwy, które realnie kontrolujesz
Kolejność jest istotna. Praca nad treścią przy zablokowanym dostępie crawlerów to koszt bez efektu.
| Warstwa | Pytanie, na które odpowiada | Właściciel po stronie organizacji |
|---|---|---|
| Dostęp crawlerów AI | Czy systemy AI mogą w ogóle pobrać nasze treści? | Infrastruktura, DevOps |
| Dane strukturalne i encje | Czy informacje o organizacji, autorach i treściach są spójnie opisane? | Zespół deweloperski |
| Architektura informacji | Czy użytkownik i wyszukiwarka mogą zrozumieć strukturę naszej wiedzy? | Marketing i architekt platformy |
| Jakość techniczna | Czy wyszukiwarka może znaleźć, wyrenderować i zindeksować całą istotną treść? | Zespół deweloperski, hosting |
1. Dostęp crawlerów AI: najczęstszy pojedynczy błąd
Dostawcy modeli rozdzielili crawlery treningowe od crawlerów odpowiadających za pobieranie treści w momencie zapytania. To rozróżnienie decyduje o sposobie wykorzystania treści, a większość plików robots.txt w dużych serwisach powstała przed jego wprowadzeniem.
| User-agent | Rola | Konsekwencja blokady |
|---|---|---|
| GPTBot | crawler treningowy OpenAI | brak treści w danych dostępnych do trenowania modeli |
| OAI-SearchBot | crawler związany z ChatGPT Search | ograniczenie możliwości pojawienia się treści w wynikach ChatGPT Search |
| ChatGPT-User | pobranie strony na żądanie użytkownika | użytkownik może nie uzyskać dostępu do treści przez ChatGPT |
| ClaudeBot | crawler Anthropic | ograniczenie dostępu Anthropic do treści |
| Claude-User | pobranie strony na żądanie użytkownika | ograniczenie pobierania treści w odpowiedzi na działanie użytkownika |
| PerplexityBot / Perplexity-User | indeks i pobranie na żądanie | ograniczenie wykorzystania treści przez Perplexity |
| Google-Extended | token kontrolny, nie crawler | kontroluje wykorzystanie treści w określonych systemach generatywnej AI Google, ale nie służy do sterowania indeksowaniem Google Search |
| Applebot-Extended | token kontrolny | kontroluje wykorzystanie treści w określonych funkcjach AI Apple |
| CCBot | Common Crawl | ogranicza obecność treści w danych Common Crawl |
Decyzja jest biznesowa, nie techniczna. Można świadomie zablokować określone sposoby wykorzystywania treści albo umożliwić do nich dostęp. Najważniejsze, żeby decyzja była świadoma, a nie wynikała z reguły wklejonej trzy lata temu.
W przypadku Google sytuacja wygląda inaczej niż w przypadku części niezależnych asystentów AI. Aby strona mogła pojawiać się w funkcjach generatywnej AI w Google Search, musi przede wszystkim być zindeksowana i kwalifikować się do wyświetlania w standardowej wyszukiwarce. Google wskazuje wprost, że podstawą pozostają zwykłe zasady crawlowania i indeksowania.
Poprawny robots.txt nie wystarczy. W dużych serwisach blokada zwykle siedzi wyżej:
- reguły WAF i bot management na CDN, w tym ustawienia dotyczące botów AI,
- limity rate limiting, które odrzucają crawlery przy większym wolumenie,
- ustawienia dotyczące kwalifikowania treści do funkcji generatywnej AI w Google Search.
Search Console. Google udostępnia raport skuteczności dotyczący generatywnej AI, który pozwala monitorować widoczność treści w funkcjach generatywnej AI w Search i Discover. To obecnie oficjalne źródło danych Google do oceny widoczności w tych funkcjach.
Weryfikacja dostępu innych crawlerów jest prosta i tania: filtr po user-agent w logach serwera i CDN plus reverse DNS tam, gdzie dostawca udostępnia odpowiednią metodę weryfikacji, bo nagłówek user-agent każdy może podrobić.
Osobno kwestia llms.txt. W przypadku Google odpowiedź jest już jednoznaczna: wyszukiwarka nie używa llms.txt do zwiększania widoczności ani pozycji strony, również w funkcjach generatywnej AI. Plik może być utrzymywany na potrzeby innych usług, które faktycznie z niego korzystają, ale nie jest elementem optymalizacji pod Google Search.
2. Dane strukturalne po zmianach z 2026 roku
Dane strukturalne pozostają elementem SEO, ale nie są specjalnym mechanizmem optymalizacji pod generatywną AI. Google wprost wskazuje, że nie są wymagane do pojawiania się w funkcjach generatywnej AI i nie trzeba wdrażać żadnego dodatkowego ani specjalnego schema markup pod AI Search.
Ich praktyczna rola pozostaje istotna tam, gdzie pomagają Google prawidłowo interpretować zawartość strony i kwalifikować ją do obsługiwanych wyników rozszerzonych. Dane strukturalne powinny odpowiadać treści rzeczywiście widocznej dla użytkownika.
Zmiana, którą trzeba znać, bo unieważnia większość poradników z ostatnich lat: 7 maja 2026 Google wycofał FAQ rich results z wyników wyszukiwania. Wsparcie w Rich Results Test i raport w Search Console zniknęły w czerwcu 2026, dane w API Search Console w sierpniu 2026. HowTo nie generuje rich resultów od 2023 roku.
Sam markup FAQPage pozostaje poprawnym typem schema.org. Wniosek praktyczny: FAQ warto utrzymywać przede wszystkim wtedy, gdy jest użyteczne dla użytkownika i odpowiada rzeczywistej zawartości strony. Nie należy jednak traktować FAQ schema jako techniki zwiększającej widoczność w generatywnej AI. Google wprost przestrzega przed nadmiernym skupieniem na danych strukturalnych w tym kontekście.
| Typ | Po co dziś | Uwaga |
|---|---|---|
| Organization | opis organizacji | wdrażaj zgodnie z dokumentacją i rzeczywistymi informacjami o firmie |
| Person | opis autora | dane powinny odpowiadać realnej osobie i treści widocznej w serwisie |
| Article | temat, autor, data publikacji i modyfikacji | dateModified musi odpowiadać rzeczywistej aktualizacji |
| BreadcrumbList | kontekst miejsca strony w strukturze | nadal może kwalifikować się do odpowiednich funkcji Google |
| Service | semantyczny opis usługi | nie jest specjalnym markupem AI Search |
| Product, Offer, AggregateRating | e-commerce | dane muszą zgadzać się z tym, co widzi użytkownik |
| FAQPage | semantyczny opis pytań i odpowiedzi | brak potrzeby wdrażania go specjalnie pod generatywną AI |
| HowTo | semantyczny opis instrukcji | bez efektu rich result od 2023 |
Walidacja: validator.schema.org dla poprawności schema.org, Rich Results Test tylko dla typów, które nadal mają wsparcie. Najczęstszy błąd w dużych instalacjach to duplikaty i sprzeczności: dwie aktywne wtyczki SEO albo motyw generujący własne znaczniki obok wtyczki.
3. Architektura informacji: dlaczego 300 artykułów przegrywa z 30
Dla systemu, który musi znaleźć i zrozumieć informacje odpowiadające na pytanie użytkownika, znaczenie ma nie liczba publikacji, ale ich jakość, użyteczność i sposób zorganizowania.
Google opisuje mechanizm rozszerzania zapytania, w ramach którego system może wykonywać wiele powiązanych wyszukiwań, aby zebrać informacje potrzebne do odpowiedzi na bardziej złożone pytanie. Nie oznacza to jednak, że warto tworzyć osobną stronę pod każdy wariant zapytania. Google wprost przestrzega przed masowym produkowaniem treści w celu manipulowania rankingami lub odpowiedziami generatywnej AI i podkreśla, że jego systemy rozumieją trafność treści także bez dokładnego dopasowania fraz.
Jeśli serwis ma kilkaset wpisów o przypadkowych tematach, trudno stworzyć z nich użyteczną i intuicyjną bazę wiedzy. Jeśli treści są zorganizowane w klastry, użytkownik może przechodzić pomiędzy kolejnymi zagadnieniami w logiczny sposób. Dla platformy enterprise klaster wokół cyklu życia platformy wygląda tak: architektura, audyt techniczny, dług technologiczny, wydajność i Core Web Vitals, bezpieczeństwo, migracje, utrzymanie, skalowanie infrastruktury. Każdy materiał odpowiada na inne pytanie i linkuje do sąsiednich.
Trzy rzeczy, które w dużych organizacjach psują ten obraz szybciej niż cokolwiek innego:
Publikowanie zamiast rozwijania. Kilkadziesiąt nowych artykułów rocznie przy zerowej aktualizacji starych daje zestaw materiałów konkurujących ze sobą o to samo pytanie. Rozwinięcie jednego kompletnego opracowania jest tańsze i działa lepiej niż piąty tekst o tym samym.
Niespójne nazewnictwo. Ta sama usługa opisana raz jako utrzymanie, raz jako opieka techniczna, raz jako maintenance utrudnia użytkownikowi zrozumienie oferty i zachowanie spójności całego serwisu. Wybierz jedną nazwę główną, synonimy stosuj świadomie.
Brak właściciela architektury informacji. Landing page’e powstają w kampaniach, dokumentacja w zespole produktowym, blog w marketingu. Każdy element osobno jest poprawny, całość nie układa się w strukturę. To problem governance, nie contentu, i nie rozwiąże go żadna wtyczka.
Unikalna wiedza ma większe znaczenie niż kolejna publikacja na ten sam temat
Sama rozbudowa klastra tematycznego nie wystarczy. Google szczególnie mocno podkreśla obecnie znaczenie treści, które dostarczają informacji nieobecnych powszechnie w innych źródłach. Mogą to być doświadczenia ekspertów, własne analizy, dane, obserwacje z projektów czy szczegółowe rozwiązania konkretnych problemów.
Dla firmy technologicznej oznacza to istotną zmianę w podejściu do contentu. Kolejny artykuł zbierający ogólnodostępne informacje o optymalizacji WordPressa wnosi niewiele. Większą wartość może mieć analiza pokazująca, jak konkretna decyzja architektoniczna wpłynęła na wydajność dużej platformy, jakie problemy pojawiły się podczas jej skalowania albo jakie rozwiązanie sprawdziło się w rzeczywistym projekcie.
Źródłem contentu powinny być więc nie tylko analizy słów kluczowych, ale również wiedza znajdująca się wewnątrz organizacji: doświadczenia developerów, wyniki audytów, rozwiązane problemy, decyzje architektoniczne i ich konsekwencje.
4. Jakość techniczna: co jest udokumentowane, a co nie
Nie ma publicznego dowodu, że Core Web Vitals są kryterium cytowania w odpowiedziach AI. Warto to mówić wprost, bo w obiegu jest dużo tez postawionych odwrotnie.
Google wskazuje natomiast jasno, że strona musi spełniać wymagania techniczne wyszukiwarki, być dostępna do crawlowania i indeksowania oraz kwalifikować się do prezentowania w standardowych wynikach Google. W przypadku JavaScriptu nadal obowiązują zwykłe dobre praktyki JavaScript SEO. Google rekomenduje również dobrą jakość strony dla użytkownika, poprawne działanie na różnych urządzeniach, ograniczanie opóźnień oraz eliminowanie zbędnej duplikacji treści.
Dlatego wydajność zostaje na liście, tylko z uczciwym uzasadnieniem.
| Metryka | Próg dobry | Typowa przyczyna problemu na dużej platformie WordPress |
|---|---|---|
| LCP (Largest Contentful Paint) | < 2,5 s | nieoptymalizowane obrazy hero, brak CDN, długi czas odpowiedzi serwera |
| INP (Interaction to Next Paint), od 2024 zamiast FID | < 200 ms | nadmiar skryptów, wtyczki blokujące wątek główny |
| CLS (Cumulative Layout Shift) | < 0,1 | obrazy bez wymiarów, elementy doładowywane dynamicznie |
Dwie uwagi operacyjne. Pierwsza: dane polowe z raportu Core Web Vitals w Search Console i z CrUX są ważniejsze niż pojedynczy laboratoryjny wynik z PageSpeed Insights, bo pokazują doświadczenia rzeczywistych użytkowników. Druga: jeśli w waszej procedurze audytu nadal są Mobile-Friendly Test i raport użyteczności mobilnej w Search Console, procedura jest nieaktualna. Google wycofał oba 1 grudnia 2023. Zastępują je między innymi PageSpeed Insights, Lighthouse i raport Core Web Vitals.
Jak to zmierzyć
Bez ustalonej metryki ta praca zostanie po pół roku oceniona złą miarą i uznana za nieskuteczną.
Search Console. Google udostępnia raport skuteczności generatywnej AI, który pozwala sprawdzać, jak użytkownicy odkrywają treści za pomocą funkcji generatywnej AI w Search i Discover. To właśnie oficjalne dane Search Console powinny być podstawą oceny widoczności w generatywnych funkcjach Google.
Logi serwera i CDN. Odpowiadają na najbardziej podstawowe pytanie dotyczące zewnętrznych systemów AI: czy ich crawlery w ogóle nas odwiedzają i czy nie dostają odpowiedzi 403.
GA4. Ruch referral z domen asystentów AI. Wolumen jest mały, intencja może być wysoka, dlatego warto go wydzielić w raportowaniu zamiast analizować wyłącznie w zagregowanych kanałach.
Narzędzia monitorujące cytowania. Traktujcie je jako próbkowanie, nie źródło wewnętrznych danych Google. Google podkreśla, że żadne zewnętrzne narzędzie nie ma dostępu do jego wewnętrznych systemów rankingowych ani systemów AI.
Konsekwencja dla raportowania: widoczność w odpowiedzi generatywnej nie zawsze prowadzi bezpośrednio do wizyty na stronie. Ustalcie z zarządem, co jest wynikiem, przed rozpoczęciem prac, nie po kwartale.
Checklista AI-readiness dla dużej platformy WordPress
| # | Obszar | Pytanie kontrolne | Gdzie sprawdzić |
|---|---|---|---|
| 1 | Crawlowanie i indeksacja | Czy wszystkie istotne treści są dostępne dla crawlerów i mogą zostać zindeksowane? | robots.txt, Search Console, logi |
| 2 | Warstwa CDN | Czy WAF lub bot management nie blokuje potrzebnych crawlerów? | panel CDN, logi |
| 3 | Search Console | Czy ustawienia dotyczące kwalifikowania treści do funkcji generatywnej AI są zgodne z decyzją organizacji? | Search Console |
| 4 | Dane strukturalne | Czy stosowane dane strukturalne odpowiadają rzeczywistej zawartości strony i nie są ze sobą sprzeczne? | validator.schema.org |
| 5 | Unikalna wiedza | Czy najważniejsze materiały zawierają własne doświadczenia, dane, analizy lub wiedzę ekspertów? | audyt contentu |
| 6 | Aktualność | Czy najważniejsze artykuły są regularnie przeglądane i rzeczywiście aktualizowane? | CMS, audyt contentu |
| 7 | Klastry | Czy kluczowe obszary biznesowe mają logicznie powiązany zestaw treści eksperckich? | mapa serwisu |
| 8 | Nazewnictwo | Czy usługi i technologie nazywamy w całym serwisie tak samo? | audyt terminologii |
| 9 | Renderowanie | Czy Google może prawidłowo wyrenderować i przetworzyć kluczową treść, również gdy serwis wykorzystuje JavaScript? | URL Inspection, testy renderowania |
| 10 | Wydajność | Czy strona zapewnia dobre doświadczenie użytkownika na różnych urządzeniach? | raport CWV, CrUX, Lighthouse |
Dwie lub trzy odpowiedzi przeczące to zadanie na jeden sprint. Sześć i więcej oznacza, że problemem nie jest AI Search, a architektura, którą AI Search tylko uwidocznił. Wtedy poprawki punktowe kosztują więcej niż uporządkowanie struktury.
Jak podchodzimy do tego w WLC
Zaczynamy od diagnozy, nie od wdrożenia. W tej kolejności: dostępność serwisu dla crawlerów i indeksowania, jakość techniczna, spójność struktury oraz architektura informacji, dopiero potem plan rozwoju treści. Taka kolejność wynika z jednej obserwacji: w większości audytów najdroższy problem leży niżej, niż zakłada zamawiający, a najtańsza poprawa jest w warstwie, o której nikt nie pamiętał.
W praktyce rzadko rekomendujemy przebudowę serwisu. Częściej wystarcza uporządkowanie tego, co już jest, plus governance, który utrzyma porządek przy kolejnych kampaniach i nowych sekcjach.
Jeśli rozwijasz platformę WordPress i chcesz sprawdzić, gdzie realnie stoisz przed inwestycją w treści, porozmawiajmy o diagnozie.
FAQ – AI Search a WordPress
Czy AI Search zastąpi SEO?
Nie. W przypadku Google oficjalne stanowisko jest jednoznaczne: funkcje generatywnej AI wykorzystują podstawowe systemy rankingowe i systemy jakości wyszukiwarki. Google traktuje działania określane jako GEO czy AEO jako część SEO, a nie odrębną dyscyplinę wymagającą specjalnych technik.
Czy dane strukturalne są konieczne, żeby pojawić się w generatywnej AI Google?
Nie. Google wprost wskazuje, że structured data nie są wymagane do wyszukiwania z generatywną AI i nie trzeba wdrażać specjalnego schema markup. Nadal mają zastosowanie w ogólnej strategii SEO, szczególnie w kontekście obsługiwanych wyników rozszerzonych.
Czy FAQ schema ma jeszcze sens po zmianach z maja 2026?
Może mieć sens jako poprawny sposób opisania rzeczywistej zawartości strony, ale nie należy wdrażać go specjalnie pod AI Search. FAQ powinno przede wszystkim odpowiadać na rzeczywiste pytania użytkowników. Google podkreśla, że dane strukturalne nie są wymagane dla funkcji generatywnej AI.
Czy trzeba przebudować serwis?
W większości przypadków nie. Uporządkowanie linkowania, nazewnictwa, indeksacji i najważniejszych materiałów może przynieść efekt bez naruszania architektury aplikacji. Przebudowa wchodzi w grę wtedy, gdy problemem jest sama architektura albo skala nagromadzonego długu technologicznego.
Czy blokować crawlery AI?
To decyzja biznesowa, którą należy podejmować osobno dla konkretnych dostawców i sposobów wykorzystywania treści. W przypadku Google podstawą widoczności w AI Overviews i AI Mode pozostaje możliwość crawlowania i indeksowania treści w Google Search.
Jak szybko widać efekty?
Nie ma wiarygodnego uniwersalnego terminu. Usunięcie problemu technicznego może umożliwić ponowne crawlowanie i indeksowanie strony, ale spełnienie wszystkich wymagań nie gwarantuje ani indeksacji, ani pojawienia się treści w funkcjach generatywnej AI. Google wskazuje to wprost w swojej dokumentacji.
Czy AI Search ma znaczenie w B2B?
Tak. Proces zakupowy w B2B zaczyna się od zdobywania wiedzy, a funkcje generatywnej AI tworzą kolejny sposób docierania do informacji o rozwiązaniach, dostawcach i technologiach. Z punktu widzenia strategii contentowej szczególnie istotne staje się więc publikowanie własnej wiedzy eksperckiej, analiz i doświadczeń, zamiast powielania informacji łatwo dostępnych w innych źródłach. Google wskazuje właśnie unikalne, wartościowe treści jako jeden z najważniejszych obszarów optymalizacji pod wyszukiwanie generatywne.
