Agent-ready Divi 5 — jak sprawdzić czytelność strony dla AI i co poprawić

Jest taka rzecz, którą widać od razu, kiedy ogląda się strony zbudowane w Divi. Wyglądają dobrze. Sekcje są uporządkowane, typografia spójna, kolory przemyślane, responsywność przetestowana. Właściciel takiej strony ma prawo sądzić, że jeśli jego strona wygląda dobrze i szybko się wczytuje, to jest również czytelna — dla Google, dla czytników ekranu, dla tego nowego rodzaju czytelnika, którym jest agent AI.

Problem w tym, że Divi daje bardzo dużo swobody, która jest świetna dla projektanta, ale nie zawsze dobra dla tego, co dzieje się pod spodem w HTML-u. Moduły są elastyczne — możesz zrobić prawie wszystko z prawie wszystkiego. I wielu ludzi robi. Nagłówek staje się modułem Text. Przycisk staje się stylizowanym linkiem. Sekcja staje się warstwą div-ów. Dla oka to wszystko wygląda identycznie. Dla agenta AI — są to cztery różne poziomy czytelności, z których trzy sprawiają problemy.

W tym wpisie pokażę cztery najczęstsze rzeczy, które w Divi 5 psują czytelność strony dla agenta AI. Dla każdej z nich zobaczysz jak sprawdzić, czy twoja strona ma ten problem, i co zrobić żeby go naprawić. To jest praktyczny towarzysz do wcześniejszego wpisu „Trzy pytania, które agent zadaje twojej stronie”, który rozpisał warstwę czytelności koncepcyjnie. Tu schodzimy do Divi Buildera, do modułów, do konkretów.

Zakładam, że pracujesz w Divi 5 (czyli wersji z nową architekturą, w której frontend renderuje się natywnie, bez warstwy shortcode’ów jak w Divi 4). Większość rzeczy, które opisuję, działa też w Divi 4, ale panele i opcje wyglądają miejscami inaczej.

Problem pierwszy — strona, która się nie renderuje bez JavaScript

Zacznijmy od fundamentu. Agent AI, który odwiedza twoją stronę, często nie uruchamia JavaScript w taki sam sposób jak przeglądarka użytkownika. Część agentów robi tylko surowy pobór HTML-a. Część uruchamia JS, ale nie czeka na dynamiczne dopięcie treści. Jeśli twoja strona renderuje istotną treść dopiero po wykonaniu JS, dla dużej części agentów ta treść nie istnieje.

Dobrą wiadomością jest, że Divi standardowo renderuje frontend jako statyczny HTML. Sekcje, wiersze, moduły tekstowe, obrazy, nagłówki — wszystko to trafia do HTML-a zwracanego przez serwer, bez konieczności uruchamiania JS po stronie klienta. Pod tym względem Divi jest dobrze przygotowany.

Złą wiadomością jest, że wielu użytkowników Divi dodaje do swoich stron rozszerzenia, które łamią ten domyślny stan. Najczęściej:

• Animacje ładowane po JS — tekst, który pojawia się „fade in” po scrollu. Efekt jest ładny, ale jeśli animacja jest zrealizowana przez opacity: 0 na starcie i JS, który zmienia na opacity: 1, agent z ograniczonym renderowaniem może widzieć stronę z niewidocznym tekstem. Sprawdź to wyłączając JS w przeglądarce — jeśli tekst znika, masz problem.
• Treści ładowane lazy load ze zbyt agresywnymi ustawieniami — np. sekcje, które pojawiają się dopiero po scrollu. W Divi 5 można włączyć lazy loading dla sekcji i to jest przydatne, ale agent, który nie scrolluje, nie zobaczy treści poniżej fold.
• Wtyczki zewnętrzne, które tworzą content przez JS — slidery produktów z WooCommerce zbudowane w niektórych wtyczkach, mapy, osadzone feedy social media. To, co wygląda jak integralna część strony, dla agenta może być puste miejsce.

Jak sprawdzić twoją stronę:

1. Otwórz stronę w Chrome. Naciśnij F12 żeby otworzyć DevTools.
2. Wejdź w ustawienia DevTools (trzy kropki w prawym górnym rogu → Settings → Preferences).
3. Przewiń do sekcji Debugger i zaznacz „Disable JavaScript”.
4. Odśwież stronę (Ctrl+R lub Cmd+R).
5. Porównaj z wersją z JS. Co zniknęło? Co się popsuło?

Jeśli najważniejsza treść — nagłówek hero, główna oferta, opisy produktów, dane kontaktowe — jest widoczna bez JS, jesteś w porządku. Jeśli pół strony zniknęło, wiesz gdzie zacząć. Najczęściej rozwiązaniem jest rezygnacja z animacji na rzecz statycznego ładowania, albo przeniesienie krytycznej treści z dynamicznych modułów do statycznych.

Drugi test, bardziej wymagający, to pobranie strony przez curl z linii komend:

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

Otwórz powstały plik i poszukaj w nim swoich najważniejszych treści. To, co tam znajdziesz, to dosłownie to, co widzi najprostsza wersja agenta. Jeśli pustka — problem. Jeśli pełna treść — dobrze.

Problem drugi — moduły, które generują <div> zamiast sensownych tagów

To jest problem, który dotyczy praktycznie każdego buildera, ale w Divi 5 ma konkretne przełożenie na ustawienia modułów. Sekcja w Divi może być wyrenderowana jako <section> albo jako <div>. Wiersz może być <div> albo czymś bardziej semantycznym. Moduł Text generuje treść w <div> z klasą et_pb_text, co dla agenta znaczy „nie wiem co to jest”. Dla porównania: ta sama treść w module Post Content byłaby w <article>, co już coś mówi.

W Divi 5 kontrola nad tagami HTML modułów jest lepsza niż w Divi 4, ale wciąż nie oczywista. Kluczowe miejsce: zakładka Advanced w ustawieniach modułu, sekcja dotycząca atrybutów HTML lub ustawień dostępności. Dla sekcji (moduł Section w Divi 5) możesz jawnie ustawić, jaki tag ma być używany — section, article, aside, div, nav, header, footer. Domyślnie Divi używa section dla sekcji, co jest dobrym wyborem. Problem zaczyna się, kiedy ludzie dodają więcej sekcji w roli kontenerów, i wtedy cała strona staje się zbiorem <section> bez <main>, bez <header>, bez <footer>.

Zdrowa struktura strony Divi powinna wyglądać mniej więcej tak:

• Całość strony otoczona przez <main> (domyślnie Divi umieszcza treść w elemencie, który jest odpowiednikiem main, ale warto sprawdzić w kodzie)
• Nagłówek strony (menu, logo) jako <header> — jeśli używasz Divi Theme Buildera, header template powinien to renderować poprawnie
• Stopka jako <footer> — analogicznie
• Sekcje treści jako <section>, z tym że kluczowe sekcje tematyczne (np. pojedynczy artykuł na stronie wpisu) jako <article>
• Boczne kolumny czy widżety jako <aside>

Jak sprawdzić twoją stronę:

1. Otwórz stronę w przeglądarce i naciśnij Ctrl+U (albo Cmd+Option+U na Macu), żeby zobaczyć źródłowy HTML.
2. Użyj Ctrl+F i wyszukaj kolejno: <main, <header, <footer, <nav, <article, <aside>, <section.
3. Policz wystąpienia każdego. Jeśli masz dziesiątki <section> i zero <main>, zero <header>, zero <footer> — mieszkasz w krainie sekcji bez hierarchii.

Drugi, szybszy test — zainstaluj rozszerzenie HeadingsMap albo Accessibility Insights for Web i uruchom je na stronie. Pokażą ci strukturę landmarków. Dobra strona powinna mieć wyraźnie oznaczone: header, main, footer, ewentualnie nav i aside.

Struktura html

Jak poprawić w Divi 5:

• Dla sekcji, które są głównymi kontenerami treści wpisu czy strony, sprawdź w ustawieniach modułu Section → Advanced → HTML Attributes, jaki tag jest wybrany. Domyślnie section, ale dla strony wpisu warto rozważyć zmianę na article.
• Header i footer strony powinny być zbudowane w Divi Theme Builder jako osobne szablony. Sprawdź, czy template headera generuje faktyczny tag <header> — jeśli używasz standardowego modułu Menu od Divi 5, powinno być OK, ale wtyczki modyfikujące menu mogą to psuć.
• Menu główne powinno być otoczone przez <nav>. Divi to zapewnia domyślnie przy module Menu, ale sprawdź w kodzie źródłowym.

Problem trzeci — nagłówki bez hierarchii albo z błędną hierarchią

Nagłówki to dla agenta szkielet strony. Jeden <h1>, potem <h2> dla głównych sekcji, <h3> dla podsekcji. Proste, od dekad, i wciąż masowo łamane. W Divi dzieje się to w dwóch wariantach.

Wariant pierwszy — moduł Text z pogrubionym tekstem zamiast nagłówka. Ktoś pisze „Nasze usługi”, robi go bold, zwiększa rozmiar, i wygląda to jak nagłówek. W HTML-u to jednak <p><strong>Nasze usługi</strong></p>. Dla oka identycznie jak <h2>. Dla agenta — zupełnie nie to. Agent nie widzi nagłówka, widzi pogrubiony paragraf.

Wariant drugi — moduł Heading (albo Advanced Heading, jeśli używasz dodatkowych pakietów) z niepoprawnie ustawionym poziomem. Ktoś chce, żeby nagłówek był duży, więc wybiera poziom H2 — nawet jeśli jest to pierwszy nagłówek na stronie (powinien być H1). Albo odwrotnie — chce żeby był mały, więc wybiera H4, przeskakując H2 i H3.

W Divi 5 moduł Heading ma jasno widoczne pole wyboru poziomu nagłówka (H1–H6). Problem polega na tym, że decyzja o wyborze poziomu jest często projektowa („chcę, żeby był taki duży”), a nie semantyczna („to jest główna sekcja strony, więc H2″). Wielkość i poziom to dwie różne rzeczy. Wielkość regulujesz CSS-em. Poziom — semantyką.

Jak sprawdzić twoją stronę:

1. Zainstaluj rozszerzenie HeadingsMap w Chrome albo Firefoksie.
2. Otwórz swoją stronę i uruchom rozszerzenie.
3. Zobaczysz spis treści strony wyłącznie na podstawie nagłówków. Powinien wyglądać jak logiczny spis treści książki.
4. Szukaj: (a) strony bez żadnego H1, (b) strony z wieloma H1, (c) przeskoków (z H1 od razu na H3), (d) zastępowania nagłówków bold-em w paragrafach.

Jak poprawić w Divi 5:

• Każda strona powinna mieć dokładnie jeden <h1> — zwykle to tytuł strony albo tytuł wpisu. W Divi Theme Builder warto to ustalić na poziomie szablonu.
• Zamień moduły Text z pogrubionym tekstem pełniącym funkcję nagłówka na moduły Heading z odpowiednim poziomem.
• W module Heading ustaw poziom zgodnie z semantyką (pierwszy nagłówek sekcji = H2, podsekcja = H3), a wielkość reguluj przez styl, nie przez zmianę poziomu.
• Jeśli chcesz kontroli nad wieloma nagłówkami na raz, Divi 5 pozwala ustawić globalne style dla poziomów H1-H6 w ustawieniach motywu — to dobra droga, bo rozdziela semantykę od prezentacji.

Problem czwarty — przyciski i formularze, które agent rozumie tylko z trudem

Przycisk w Divi wygląda prosto. Dodajesz moduł Button, wpisujesz tekst, ustawiasz link, stylujesz. Pod spodem generuje się <a> z odpowiednimi klasami, nie <button>. To jest świadoma decyzja Divi — przyciski, które prowadzą do innych stron, powinny być linkami, nie przyciskami, i z tym się zgadzam. Agent to rozumie.

Problem zaczyna się w trzech innych miejscach.

Pierwsze miejsce — przyciski, które nie prowadzą do linku, tylko wywołują akcję JavaScript (np. otwarcie modalu, pokazanie popupu, scroll do sekcji). W Divi takie rzeczy często robi się jako moduły Button z pustym linkiem i JavaScriptem doczepionym przez klasę. Dla agenta taki przycisk jest zagadką — widzi link, który prowadzi do # albo donikąd, i nie wie, że po kliknięciu coś się dzieje. Jeśli musisz robić takie przyciski, rozważ użycie w kodzie własnego <button> z type="button" i atrybutem aria-label opisującym akcję. Divi pozwala na dodawanie własnego kodu HTML przez moduł Code.

Drugie miejsce — formularze. Divi ma moduł Contact Form, który generuje formularze z etykietami. Dobrze. Ale wielu ludzi używa zewnętrznych wtyczek do formularzy — WPForms, Contact Form 7, Gravity Forms — i osadza je w Divi przez shortcode. Wtedy jakość HTML-a formularza zależy od wtyczki, a nie od Divi. Niektóre wtyczki generują świetne, semantyczne formularze z labelami i atrybutami autocomplete. Niektóre nie. Sprawdź w kodzie źródłowym swojej strony: czy każde pole ma <label for="…"> pasujące do id pola input? Czy pola email mają type="email" i autocomplete="email"? Czy pola telefonu mają type="tel"? Bez tego agent, który próbuje wypełnić twój formularz w imieniu użytkownika, musi zgadywać, co jest polem na co.

Trzecie miejsce — linki z bezsensownymi anchorami. „Czytaj więcej”, „kliknij tutaj”, „zobacz”. Dla Divi 5 to często wynik używania modułu Blog w domyślnej konfiguracji, gdzie „Read more” jest generyczne. Można to zmienić w ustawieniach modułu Blog — zamiast „Read more” użyj tytułu wpisu albo frazy opisowej w stylu „Czytaj: [tytuł]”. Drobna zmiana, duża różnica dla agenta próbującego zrozumieć, dokąd prowadzą linki.

Jak sprawdzić twoją stronę:

1. Otwórz stronę, naciśnij Ctrl+U żeby zobaczyć kod.
2. Wyszukaj <button i <a — sprawdź, co robią. Czy przyciski to linki (OK, jeśli prowadzą do stron) czy <button> (OK, jeśli wywołują akcje)?
3. Otwórz kod formularza i sprawdź: każde <input> ma przypisaną etykietę przez <label for="…">? Pola mają atrybut autocomplete?
4. Przejrzyj linki z artykułów blogowych — ile z nich ma anchor w stylu „więcej”, „czytaj”, „zobacz” bez kontekstu?

Co z tego wynika

Jeśli przeszedłeś przez cztery problemy powyżej i dla każdego wiesz, jak stoi twoja strona, masz całkiem konkretny obraz tego, w jakim stopniu twoja strona Divi jest czytelna dla agentów AI. Nie jest to pełen audyt agent-readiness — jest to audyt tylko pierwszego filaru, czytelności. Ale to jest filar, bez którego reszta nie działa, więc warto go mieć pod kontrolą jako pierwszy.

Najbardziej znacząca obserwacja z tego wpisu jest moim zdaniem taka: Divi 5 nie jest problemem dla agent-readiness. Domyślnie generuje całkiem przyzwoity HTML — statyczny frontend, semantyczne sekcje, poprawne linki. Problemy pojawiają się wtedy, kiedy użytkownicy zaczynają używać Divi w sposób, który łamie te domyślne stany — zastępują nagłówki pogrubionym tekstem, dodają animacje ładowane po JS, osadzają zewnętrzne formularze bez sprawdzenia ich jakości, robią przyciski bez semantyki. Innymi słowy, problem nie leży w Divi, tylko w decyzjach projektowych, które Divi umożliwia, ale nie wymusza.

Dobre dla twórcy — masz wolność. Wymagające dla twórcy — wolność oznacza, że jakość semantyki strony zależy od twojej świadomości, nie od domyślnych ustawień buildera. W kolejnych wpisach serii Agent-ready Divi będziemy schodzić do następnych filarów — dane strukturalne w Divi i WooCommerce, sygnały dla agentów na poziomie WordPressa, warstwa działania (formularze, API, narzędzia) — i w każdym z nich wrócimy do tej samej zasady. Divi nie jest przeciwnikiem czytelności dla agentów. Divi jest neutralne. Ty decydujesz.