Agent-ready WordPress z Gutenbergiem — jak sprawdzić czytelność strony dla AI i co poprawić

Ten poradnik pokazuje, jak sprawdzić czytelność strony w WordPressie z blokami — na poziomie struktury, semantyki i treści.

Strona zbudowana w Gutenbergu może wyglądać bardzo dobrze i nadal być słabo czytelna dla agenta AI. Edytor blokowy WordPressa daje lepszy punkt wyjścia do semantycznej struktury niż wiele klasycznych builderów, bo operuje blokami o określonej roli — Heading, Navigation, Query Loop, Template Part. To jednak nie oznacza, że każda strona z Gutenberga jest automatycznie agent-ready. Dużo zależy od motywu, użytych wzorców, dodatkowych wtyczek i od tego, czy treść została złożona zgodnie z przeznaczeniem bloków — a nie tylko z ich wyglądem.

Dla użytkownika wszystko może wyglądać poprawnie. Nagłówek jest duży, przycisk wygląda jak przycisk, sekcja ma ładne tło, a listing wpisów układa się równo. Dla agenta AI różnica między prawdziwym nagłówkiem, akapitem stylizowanym na nagłówek, treścią doładowywaną po JavaScripcie i poprawnym elementem nawigacji jest ogromna. To właśnie na tym poziomie zaczynają się problemy z czytelnością strony dla systemów wyszukiwania, asystentów i agentów, którzy nie zawsze interpretują front tak jak zwykła przeglądarka.

W tym wpisie pokażę cztery najczęstsze rzeczy, które w WordPressie z Gutenbergiem psują czytelność strony dla AI. Dla każdej zobaczysz, jak sprawdzić, czy twoja strona ma ten problem, i co zrobić, żeby go naprawić. To nie jest tekst o tym, jak „zadowolić algorytm”. To jest praktyczna checklista dla właściciela strony, który chce, żeby jego treść była jednoznaczna, dobrze zorganizowana i łatwa do odczytania także poza klasycznym widokiem przeglądarki.

Problem pierwszy — ważna treść znika bez JavaScriptu

Agent AI, który odwiedza twoją stronę, nie zawsze uruchamia JavaScript tak jak przeglądarka użytkownika. Część agentów pobiera tylko surowy HTML. Część nie czeka na dynamiczne dopięcie treści. Jeśli najważniejsze elementy strony pojawiają się dopiero po JS, dla części agentów ta treść po prostu nie istnieje.

Dobra wiadomość: WordPress z Gutenbergiem renderuje podstawowe bloki — nagłówki, akapity, obrazy, listy — po stronie serwera jako zwykły markup. Problem zaczyna się przy wtyczkach i blokach, które doładowują zawartość dynamicznie: slidery, zakładki, feedy, popupy, filtry, karuzele, elementy „show on scroll”.

Jak sprawdzić swoją stronę:

Najszybszy test to jedno polecenie w terminalu:

curl -A "ChatGPT-User/1.0" https://twojadomena.pl/ > strona.html

Otwórz zapisany plik i wyszukaj swoje kluczowe komunikaty — H1, główną ofertę, dane kontaktowe, CTA. Jeśli ich nie ma w pliku, nie ma ich też dla agenta. Możesz też wyłączyć JS w DevTools (Settings → Disable JavaScript) i sprawdzić stronę wizualnie.

Jak poprawić stronę w Gutenbergu:

• przenieś krytyczną treść z modułów dynamicznych do zwykłych bloków,
• nie chowaj głównej oferty wyłącznie w sliderach, tabach i popupach,
• ogranicz animacje startujące od niewidocznego tekstu,
• traktuj JS jako warstwę ulepszającą, a nie warunek istnienia treści.

Problem drugi — motyw i struktura strony nie mówią agentowi, co jest czym

To jest problem specyficznie gutenbergowy i często niedoceniany. WordPress od kilku lat rozróżnia dwa typy motywów: klasyczne i blokowe. W motywie blokowym (Full Site Editing) header, footer i inne stałe elementy układu są Template Parts — osobnymi plikami szablonu edytowalnymi w Site Editor. W motywie klasycznym tego mechanizmu nie ma, a header i footer żyją w plikach PHP poza zasięgiem edytora bloków.

Ta różnica ma znaczenie dla agenta. Motyw blokowy zbudowany z Template Parts i Navigation block produkuje markup z wyraźnymi elementami <header>, <nav>, <main>, <footer>. Motyw klasyczny z widgetem menu wrzuconym gdzieś w sidebar albo z headerem zakodowanym w PHP może dawać zupełnie inny, mniej czytelny dokument.

Problem zaczyna się też wtedy, gdy cała strona jest składana jako dekoracyjny układ bloków Group, Columns i Cover bez myślenia o architekturze dokumentu. Listing wpisów jako ręcznie kopiowane karty zamiast Query Loop, menu jako zestaw linków w dowolnym kontenerze zamiast Navigation block, hero bez jasnej roli w strukturze — agent dostaje wtedy stos wizualnych elementów bez logicznego znaczenia.

Jak sprawdzić swoją stronę:

1. Otwórz stronę i sprawdź źródło HTML. Wyszukaj <header>, <nav>, <main>, <footer>, <article>.
2. Sprawdź w panelu WordPress → Wygląd, czy używasz motywu blokowego czy klasycznego.
3. Użyj rozszerzenia Accessibility Insights lub HeadingsMap i sprawdź, czy widać landmarki i logiczne obszary strony.
4. Wejdź w Site Editor (jeśli masz motyw blokowy) i sprawdź, czy header i footer są zdefiniowane jako Template Parts.

Jak poprawić stronę w Gutenbergu:

• jeśli używasz motywu klasycznego i masz kontrolę nad wyborem — rozważ przejście na motyw blokowy,
• buduj header i footer jako Template Parts,
• używaj Navigation block do głównego menu zamiast widgetów lub hardkodowanych linków,
• listing wpisów opieraj na Query Loop, nie na ręcznie składanych siatkach kart,
• nie zamieniaj całej strony w dekoracyjny układ bez wyraźnej architektury.

Problem trzeci — nagłówki bez hierarchii albo stylizowany tekst zamiast nagłówków

Nagłówki są dla agenta szkieletem strony. WordPress dokumentuje Heading block jako element służący do wprowadzania nowych sekcji i organizowania treści. To jest obszar, w którym popełnia się masę prostych, ale kosztownych błędów — i Gutenberg nie chroni przed nimi automatycznie.

Pierwszy wariant błędu: ktoś używa Paragraph block, pogrubia tekst, zwiększa rozmiar fontu i traktuje to jak nagłówek. Dla człowieka wygląda dobrze. Dla agenta to nadal akapit. Strona bez prawdziwych H2 i H3 nie ma logicznego spisu treści.

Drugi wariant błędu to theme.json. W motywie blokowym globalny plik theme.json definiuje, jak wyglądają poszczególne poziomy nagłówków — ich rozmiar, wagę, odstępy. To dobry mechanizm, ale bywa źródłem problemu: jeśli H2 w theme.json wygląda za małe, ktoś sięga po H1 dla wizualnego efektu. Albo odwrotnie — H3 jest tak duże, że ktoś używa go zamiast H2 żeby „nie dominowało”. Poziom nagłówka powinien wynikać z roli treści, a nie z wartości w theme.json. Wielkość regulujesz stylem. Semantykę ustawiasz poziomem.

Jak sprawdzić swoją stronę:

1. Zainstaluj rozszerzenie HeadingsMap.
2. Otwórz stronę i sprawdź automatyczny spis treści wygenerowany tylko z nagłówków.
3. Sprawdź, czy masz dokładnie jeden H1.
4. Szukaj przeskoków H1 → H3 z pominięciem H2.
5. Szukaj pogrubionych akapitów udających nagłówki.

Jak poprawić stronę w Gutenbergu:

• używaj Heading block wszędzie tam, gdzie tekst naprawdę pełni funkcję nagłówka,
• trzymaj jeden H1 na stronę lub wpis,
• buduj dalszą strukturę przez H2 i H3,
• jeśli domyślny wygląd nagłówka ci nie odpowiada, zmień go w theme.json lub przez style bloku — nie przez zmianę poziomu semantycznego,
• nie dobieraj poziomu nagłówka na podstawie wyglądu.

Problem czwarty — formularze i CTA niewidoczne poza edytorem

W Gutenbergu formularz kontaktowy to najczęściej blok z wtyczki — Contact Form 7, WPForms, Gravity Forms. Sam blok jest prosty: shortcode albo komponent osadzony w treści strony. Problem nie leży w bloku, tylko w tym, gdzie i jak formularz trafia na stronę.

Najczęstszy błąd wygląda tak: jedyna droga kontaktu jest schowana w popupie uruchamianym przyciskiem. Button block z akcją otwierającą modal wtyczki popup — dla człowieka to wygodne, dla agenta ścieżka urywa się w miejscu kliknięcia. Nie ma docelowego URL, nie ma kontekstu formularza, nie ma informacji o tym, czego dotyczy kontakt. Agent widzi przycisk i nic za nim.

Drugi wariant: formularz jest na stronie, ale otoczony wyłącznie wizualnym layoutem bez semantycznego kontekstu. Sekcja contact to Group block z tłem, ikoną i przyciskiem stylizowanym przez wtyczkę page buildera. Heading nad formularzem ma poziom H4 bo „tak ładniej wygląda w tym miejscu”. Dla agenta ta sekcja nie wygląda jak formularz kontaktowy — wygląda jak kolejna dekoracyjna sekcja.

Jak sprawdzić swoją stronę:

1. Sprawdź, czy formularz kontaktowy jest osadzony bezpośrednio na stronie czy wyłącznie w popupie.
2. Pobierz stronę przez curl i wyszukaj shortcode lub markup formularza w pliku HTML.
3. Sprawdź, jaki nagłówek poprzedza formularz i czy jego poziom jest logiczny w hierarchii strony.
4. Przejdź po wszystkich głównych CTA i sprawdź, czy tekst przycisku jasno mówi, co się stanie po kliknięciu.

Jak poprawić stronę w Gutenbergu:

• osadź główny formularz kontaktowy bezpośrednio na stronie, nie tylko w popupie,
• jeśli używasz popupu, traktuj go jako dodatek — formularz powinien istnieć też bez niego,
• poprzedź formularz prawdziwym nagłówkiem z odpowiednim poziomem (H2 jeśli to główna sekcja strony),
• zamiast „Napisz do nas” czy „Kontakt” używaj tekstów CTA które mówią o intencji: „Umów bezpłatną konsultację”, „Zapytaj o wycenę”, „Skontaktuj się w sprawie projektu”,
• nie polegaj na tym, że agent domyśli się celu akcji na podstawie wyglądu przycisku.

Dlaczego Gutenberg jest dobrym punktem wyjścia dla agent-ready

Warto to powiedzieć wprost: WordPress z Gutenbergiem i motywem blokowym ma strukturalnie lepszy start niż wiele środowisk, które przez lata uczyły budować strony z przypadkowych kontenerów. Heading block porządkuje treść. Navigation block organizuje nawigację. Query Loop prezentuje listy wpisów w przewidywalny sposób. Template Part daje powtarzalne, edytowalne części układu. theme.json centralizuje wygląd tak, żeby decyzje wizualne nie musiały zaburzać semantyki.

Ale fundament to nie gotowy dom. Jeśli motyw jest źle złożony, treść stylizowana zamiast strukturyzowana, krytyczne elementy znikają bez JS, a formularz żyje wyłącznie w popupie — nawet Gutenberg nie uratuje czytelności strony. Agent-ready nie bierze się z narzędzia. Bierze się z dyscypliny w budowaniu treści i layoutu.

Checklista agent-ready dla WordPressa z Gutenbergiem

Jeśli chcesz sprawdzić stronę szybko, przejdź przez pięć punktów:

• Czy najważniejsza treść istnieje bez JavaScriptu?
• Czy strona ma czytelny szkielet: header, nav, główną treść, footer?
• Czy nagłówki są prawdziwymi nagłówkami, a nie stylizowanym tekstem?
• Czy H1, H2 i H3 budują logiczną hierarchię — niezależnie od tego, jak wyglądają w theme.json?
• Czy formularz kontaktowy i główne CTA są widoczne i jednoznaczne bez skryptowych obejść?

Jeśli na większość z tych pytań odpowiadasz „tak”, jesteś blisko strony, którą łatwiej zrozumie nie tylko użytkownik, ale też agent AI. Jeśli nie — najczęściej wystarczy uporządkować strukturę, poprawić nagłówki i przenieść krytyczne elementy z efektownych dodatków do normalnego HTML. To są zwykle małe decyzje edytorskie, ale ich wpływ na czytelność strony jest duży.