Twoje ramki znikają z odpowiedzi AI. Winny jest jeden znacznik HTML

👁 115 przeczytań

Wniosek mojego artykułu siedział w eleganckiej ramce zbudowanej na znaczniku aside. Kiedy zapytałem model językowy o tezę tego tekstu, dostałem odpowiedź złożoną ze środkowych akapitów - tak, jakby ramki nie było. Przepuściłem stronę przez bibliotekę ekstrakcji treści i zobaczyłem dlaczego: aside został usunięty przed analizą, razem z nav i footer.

Skąd się bierze problem: pipeline nie czyta strony, czyta oczyszczony tekst

Model językowy nie dostaje twojego HTML-a. Między stroną a modelem stoi warstwa ekstrakcji treści, której zadaniem jest wyrzucić menu, stopkę, banery i paski boczne, a zostawić artykuł. Ta warstwa działa na regułach dotyczących struktury dokumentu, nie na sensie treści.

Reguła jest brutalnie prosta: aside to semantycznie „treść powiązana, ale nie główna”. Skoro autor specyfikacji HTML tak to zdefiniował, a ty użyłeś tego znacznika, biblioteka przyjmuje to za oświadczenie woli. Wycina i idzie dalej. Nie sprawdza, czy w środku jest reklama, czy najważniejszy akapit w całym tekście.

To jest pułapka dla ludzi, którzy robią rzeczy porządnie. Semantyczny HTML uczy się jako dobrą praktykę, a aside wygląda na oczywisty wybór dla ramki, callboksa czy boksu „warto wiedzieć”. W kontekście geo optymalizacji ta sama decyzja działa dokładnie odwrotnie do intencji.

Co dokładnie znika

Sprawdziłem trzy typy bloków, które w moich tekstach najczęściej leżały w ramkach. Wynik był ten sam za każdym razem - i za każdym razem naprawa polegała na zamianie jednego znacznika.

Zwróć uwagę na drugi wiersz. Tabela porównawcza to najczęściej najgęstszy informacyjnie fragment artykułu - dokładnie taki materiał, który model chętnie cytuje, bo ma jasną strukturę i konkretne wartości. Jeśli twój szablon owija tabelę w aside, żeby wyświetlić ją obok tekstu, oddajesz najlepszą część tekstu do kosza.

Trzeci wiersz jest mniej bolesny pod kątem treści, ale wart odnotowania. Wezwanie do działania w aside znika, więc model opisujący twój materiał nie ma pojęcia, co proponujesz zrobić czytelnikowi. To moja opinia, ale sądzę, że to jeden z powodów, dla których odpowiedzi AI o produktach często omijają konkretną ofertę i zostają na poziomie ogólników.

Dlaczego nav i footer są w tym samym worku

nav i footer giną razem z aside i tu logika jest bardziej zrozumiała - to zwykle menu i dane kontaktowe. Problem pojawia się wtedy, gdy ktoś wykorzystuje te znaczniki niestandardowo.

Widziałem footer użyty jako pojemnik na informacje o autorze i datę aktualizacji. Widziałem nav użyty na spis treści z opisami sekcji. Obie rzeczy są cenne dla widoczności w AI: autor i data to sygnały wiarygodności, a spis treści to gotowa mapa artykułu. Obie idą do wycięcia razem z menu głównym.

Jeśli chcesz mieć spis treści widoczny dla ekstrakcji, zrób go zwykłym div z listą w środku. Nawigacja po dokumencie działa identycznie, bo to nadal linki wewnętrzne, a treść zostaje w wyekstrahowanym tekście.

Jak pisać pod AI, nie psując dostępności

Pierwsza reakcja, którą słyszę, brzmi: przecież semantyczny HTML jest po to, żeby czytniki ekranowe rozumiały strukturę. To prawda i nie trzeba z tego rezygnować.

Rozwiązanie jest tanie. Używaj div jako kontenera i opisz rolę oraz znaczenie bloku tekstem widocznym w środku - nagłówkiem, który mówi wprost, co to za blok. Nagłówek typu „Wniosek w jednym akapicie” robi dla modelu językowego więcej niż jakikolwiek znacznik strukturalny, bo trafia do wyekstrahowanego tekstu i jednoznacznie etykietuje fragment.

Moja zasada roboczo brzmi tak: aside rezerwuję dla rzeczy, które naprawdę mogą zniknąć bez straty - powiązane linki, boks z newsletterem, banery. Wszystko, co chcę zobaczyć w odpowiedzi modelu, lądzuje w div. To odwrócenie typowego myśleniu o jak pisać pod AI: zamiast dodawać znaczniki, usuwam te, które sygnalizują „to jest poboczne”.

Najczęstsze miejsca, gdzie aside wchodzi bez pytania

Rzadko decydujesz o tym świadomie. Znacznik przychodzi z szablonem albo z komponentem.

• Bloki typu callout w systemach CMS - domyślny markup często opiera się na aside, bo tak wyglądało to „po bożemu” przy projektowaniu komponentu.
• Ramki pull quote i wyróżnione cytaty - klasyczny przypadek, w którym aside jest podręcznikowo poprawny, a praktycznie szkodliwy.
• Boksy z podsumowaniem na górze artykułu - najgorszy możliwy wybór, bo to zwykle najlepiej napisany fragment całego tekstu.
• Kolumny z tabelami technicznymi, wyświetlane obok treści na szerokich ekranach.

Sprawdzenie zajmuje minutę na szablon i działa raz na wszystkie przyszłe teksty. Warto zrobić to przed kolejną rundą pisania, nie po.

Jak to sprawdzić u siebie

1. Wybierz jeden ze swoich artykułów, który ma ramkę z wnioskiem, callbox albo tabelę w bocznej kolumnie.
2. Otwórz źródło strony i wyszukaj aside. Zanotuj, ile bloków i jakie treści siedzą w tym znaczniku. Przy okazji poszukaj nav i footer użytych do czegoś innego niż menu i stopka.
3. Przepuść adres URL przez bibliotekę ekstrakcji treści typu readability - lokalnie albo przez dowolny podgląd czystego tekstu artykułu.
4. Porównaj wynik z oryginałem. Sprawdź, czy treść z ramek jest obecna w wyekstrahowanym tekście. Jeśli nie ma jej ani w całości, ani we fragmencie - masz potwierdzenie.
5. Zamień kontener z aside na div, zachowując te same klasy CSS. Wygląd się nie zmieni, bo stylowanie oparte na klasach działa identycznie.
6. Dodaj w środku bloku nagłówek, który nazywa jego funkcję, żeby model dostał jasną etykietę treści.
7. Powtórz ekstrakcję i sprawdź, czy blok jest teraz w wyniku.
8. Zapytaj model językowy o tezę albo o dane z tabeli z tego artykułu i porównaj odpowiedź z tą, którą dostawałeś przed zmianą.