Przejdź do treści
SilktidePomoc

Treść czytelna bez JavaScript

Główna treść strony — akapity, nagłówki, tabele i ceny, po które przychodzi użytkownik — musi być obecna w kodzie HTML zwracanym przez serwer przy pierwszym żądaniu. Rozbudowanie za pomocą jest w porządku. Treść, która pojawia się wyłącznie po uruchomieniu JavaScript, jest niewidoczna dla większości robotów AI, a tym samym dla asystentów AI, które z nich cytują.

Na całej tej stronie załóżmy, że firma Fernwood przebudowała swoją witrynę marketingową jako aplikację jednostronicową. W przeglądarce wygląda ona na kompletną. Wyświetlenie źródła pokazuje niemal pusty <div id="root"></div>. To właśnie tę pustą powłokę otrzymują GPTBot, ClaudeBot, PerplexityBot i podobne roboty.

Dlaczego to działa

Tradycyjne wyszukiwarki w dużej mierze rozwiązały ten problem: Google renderuje JavaScript przed indeksowaniem. Wyszukiwarki odpowiedzi — nie. Roboty zasilające ChatGPT, Claude, Perplexity i podobne systemy zazwyczaj pobierają surową odpowiedź HTML i na tym kończą — nie czekają na hydratację frameworka, nie wykonują pakietu JavaScript ani nie podążają trasami po stronie klienta. Własne porównanie indeksowania Silktide (strona wyrenderowana względem surowego HTML) opiera się dokładnie na tym zachowaniu; zobacz Treść bez JavaScript.

Tryb awarii jest cichy i całkowity:

  • Strona, która ma dobrą pozycję w Google, może być całkowicie nieobecna w odpowiedziach AI, ponieważ asystenci AI nigdy nie otrzymali jej tekstu.
  • Każda inna inwestycja w AEO na tej stronie — dane strukturalne, daty czytelne maszynowo, pisanie od odpowiedzi — jest bezwartościowa, jeśli robot nigdy nie widzi treści opisywanej przez te sygnały.
  • Użytkownicy odwiedzający stronę przy nieudanym lub zablokowanym działaniu skryptów widzą tę samą pustą powłokę, a pierwsze wyrenderowanie treści cierpi nawet wtedy, gdy skrypty ostatecznie zadziałają.

To problem architektury witryny, a nie problem edycji strony. Ręczne naprawienie jednego adresu URL nie naprawi szablonu tworzącego kolejne sto stron.

Jak sprawdzić, co widzi robot

Zanim cokolwiek zmienisz, potwierdź problem. Trzy sposoby, od najsilniejszego:

  1. Kontrola Silktide. Treść bez JavaScript porównuje znaczący tekst treści wyrenderowanej strony z surowym kodem HTML przechwyconym podczas indeksowania. Oznacza strony, na których surowy tekst stanowi mniej niż około 10% wyrenderowanego tekstu i jest niewielki również w wartościach bezwzględnych — czyli rzeczywiście pustą powłokę, a nie stronę, która jedynie wzbogaca swoją zawartość.
  2. Wyświetl źródło, nie panel Elementy w narzędziach deweloperskich. W przeglądarce opcja „Wyświetl źródło strony” pokazuje to, co wysłał serwer. Panel Elementy pokazuje DOM po uruchomieniu JavaScript. Jeśli tekst artykułu znajduje się w panelu Elementy, ale nie ma go w źródle strony, roboty pomijające JS go nie zobaczą.
  3. Pobierz stronę bez przeglądarki. W terminalu: curl -sL https://fernwood.example/pricing | head. Możesz też użyć przeglądarki tekstowej. Jeśli w danych wyjściowych brakuje tabeli cen, brakuje jej również robotowi.

Sprawdź też, czy robot w ogóle ma dostęp — doskonała odpowiedź HTML jest bezużyteczna, jeśli robots.txt blokuje robota AI albo zapora sieciowa blokuje go w praktyce (Roboty AI blokowane w praktyce).

Jak to naprawić

Wybierz podejście pasujące do Twojego stosu technologicznego. Wszystkie trzy dają ten sam rezultat: pierwsza odpowiedź HTML zawiera treść.

1. Renderowanie po stronie serwera (SSR)

Serwer renderuje każdą stronę do HTML na żądanie; JavaScript następnie zapewnia hydratację na potrzeby interaktywności. To domyślna ścieżka dla frameworków, które już ją obsługują:

  • Next.js — użyj App Routera z komponentami serwerowymi albo getServerSideProps / getStaticProps w Pages Routerze. Nie dostarczaj głównego komponentu tylko po stronie klienta, który pobiera treść po zamontowaniu.
  • Nuxt — tryb uniwersalny / SSR (domyślny), a nie ssr: false.
  • Remix, SvelteKit, Astro (tryb SSR) i odpowiedniki — ta sama zasada: odpowiedź dokumentu zawiera tekst treści.

Praktyczna zasada: jeśli pobieranie danych przez useEffect / onMounted powoduje umieszczenie artykułu na stronie, przenieś to pobieranie danych na serwer.

2. Generowanie witryny statycznej (SSG)

Twórz strony wcześniej jako zwykły HTML w momencie publikacji. To idealne rozwiązanie dla treści, które nie zmieniają się zależnie od użytkownika — wpisów na blogu, dokumentacji, stron marketingowych i cen. Astro, Eleventy, Hugo, Next.js output: 'export' oraz Nuxt generate tworzą pliki, które robot może odczytać bez żadnego JavaScript.

SSG jest zwykle najtańszym sposobem na poprawę witryn marketingowych i contentowych: nie ma kosztu renderowania dla każdego żądania, a HTML na dysku jest dokładnie tym, co otrzymuje robot.

3. Wstępne renderowanie jako rozwiązanie przejściowe

Jeśli nie możesz jeszcze zmienić frameworka, usługa wstępnego renderowania lub etap kompilacji może dostarczać robotom wyrenderowany zrzut HTML (a często także użytkownikom odwiedzającym stronę po raz pierwszy), podczas gdy SPA nadal działa w interaktywnych sesjach. Traktuj to jako rozwiązanie przejściowe, a nie cel: aktualność zrzutów, unieważnianie pamięci podręcznej i trasy wymagające uwierzytelnienia stają się osobnym obciążeniem utrzymaniowym. Jeśli możesz, napraw tryb renderowania.

Wskazówki Google dotyczące SEO JavaScript oraz artykuł web.dev Renderowanie w sieci opisują to samo spektrum — SSR, SSG i stopniowe ulepszanie — z perspektywy problemu wyszukiwarek.

Co musi znaleźć się w pierwszym HTML

Nie każdy piksel. Chodzi o treść, którą cytat mógłby przytoczyć:

  • Treść artykułu lub strony — nagłówki, akapity, listy, tabele.
  • Ceny, limity i inne fakty, które mają powtarzać asystenci AI.
  • Dane strukturalne w bloku <script type="application/ld+json"> w początkowym HTML — JSON-LD wstrzyknięty dopiero po hydratacji jest równie niewidoczny jak zwykły tekst.
  • Kanoniczny adres URL, tytuł i opis meta w <head>.

JavaScript może nadal obsługiwać menu, personalizację, wykresy uzupełniające już obecną tabelę oraz funkcje stopniowego ulepszania. Kontrola Silktide celowo łagodnie traktuje ulepszenia: strony, które dostarczają główną treść jako HTML i dodają do niej zachowania, przechodzą kontrolę.

Typowe wzorce awarii

  • SPA działające tylko po stronie klienta — Create React App, SPA Vite i podobne konfiguracje, które dostarczają pustą powłokę i pobierają trasy w przeglądarce. Rozwiązaniem jest SSR/SSG, a nie więcej kodu po stronie klienta.
  • Treść za przyciskiem „Wczytaj więcej” lub w kartach, które nigdy nie pojawiają się w HTML. Jeśli jedynym sposobem dotarcia do trzeciej sekcji jest kliknięcie, które ją pobiera, roboty nigdy do niej nie dotrą. Preferuj prawdziwe adresy URL albo uwzględnij treść w początkowej odpowiedzi.
  • „Działa w Google, więc wszystko jest w porządku”. Renderowanie przez Googlebota nie zastępuje czytelności dla robotów AI. Przejście testów Google i niepowodzenie w GPTBot to częsty, niewidoczny podział.
  • Blokowanie robota i obwinianie JavaScript. Zawsze sprawdzaj dostęp robotów AI oraz rzeczywistą dostępność obok tej techniki.

Jak pomaga Silktide

Jeśli Silktide nie może odczytać Twojej treści bez JavaScript, nie mogą tego zrobić również asystenci AI, które chcesz, aby Cię cytowały.

Powiązane

Ostatnio zaktualizowano

Czy ta strona była pomocna?