Czy AI crawlery renderują JavaScript? Nasza strona jest oparta na React i się martwię

Krótka odpowiedź: Crawlery AI w większości nie renderują JavaScript dobrze. Oto szczegóły.

Możliwości crawlerów w zakresie JavaScript:

W praktyce:

Jeśli Twoje treści wymagają JavaScript do renderowania:

• Prawdopodobnie są niewidoczne dla większości crawlerów AI
• Nie będziesz cytowany w odpowiedziach ChatGPT
• Perplexity może pobrać część treści, ale niespójnie
• Tracisz widoczność w AI

Hierarchia rozwiązań:

Najlepsze: Renderowanie po stronie serwera (SSR)

• Next.js z getServerSideProps
• Nuxt.js w trybie SSR
• Treści w początkowej odpowiedzi HTML

Dobre: Generowanie statyczne (SSG)

• Pre-renderowany HTML dla wszystkich stron
• Generacja podczas budowania
• Dobre dla treści rzadko zmienianych

Akceptowalne: Usługi pre-renderingu

• Prerender.io i podobne
• Wykrywa bota, serwuje pre-renderowany HTML
• Dodatkowa złożoność i koszty

Niepolecane dla widoczności w AI:

• Czyste renderowanie po stronie klienta
• Treści ładowane przez API po załadowaniu strony
• Dynamiczne treści bez fallbacku

Twój przypadek:

Pełne SPA w React = prawdopodobnie niewidoczne dla AI. Migracja do SSR prawdopodobnie konieczna dla widoczności w AI.

Przeszliśmy przez tę migrację. Oto czego się nauczyliśmy.

Nasz wcześniejszy setup:

• Create React App (CRA)
• Wszystkie treści renderowane po stronie klienta
• Treści ładowane przez API

Migracja do Next.js:

Czas realizacji: 6 tygodni na 50 stron

Kluczowe kroki:

1. Założenie projektu Next.js
2. Migracja komponentów (w większości działały bez zmian)
3. Implementacja getServerSideProps do pobierania danych
4. Aktualizacja routingu na zgodny z Next.js
5. Testowanie z wyłączonym JavaScript
6. Wdrożenie i weryfikacja

Wyzwania:

• Znacząca zmiana wzorców pobierania danych
• Część bibliotek typowo klienckich wymagała zamienników
• Wydłużony czas budowania (SSR generuje narzut)
• Trzeba było przemyśleć strategię cache’owania

Rezultaty:

Widoczność w AI:

• Przed: 5% cytowań naszych tematów
• Po: 28% cytowań
• Perplexity zaczął nas cytować regularnie

SEO:

• Skrócony czas do pierwszego sensownego renderu
• Lekka poprawa pozycji w Google
• Lepsze Core Web Vitals

Warto było?

Zdecydowanie. Wysiłek migracyjny zwrócił się w 3 miesiące dzięki poprawie widoczności.

Jak zweryfikować, co naprawdę widzą crawlery AI.

Metody testowania:

Metoda 1: Wyłącz JavaScript

W DevTools przeglądarki:

• Ustawienia → Preferencje → Wyłącz JavaScript
• Obejrzyj swoją stronę
• To co widzisz = to co widzą crawlery AI

Metoda 2: Curl/Wget

curl https://yoursite.com/page

To pobiera surowy HTML. Jeśli nie ma tam treści – crawlery AI jej nie zobaczą.

Metoda 3: Sprawdź logi serwera

Szukaj żądań od:

• GPTBot
• ClaudeBot
• PerplexityBot

Sprawdź kody odpowiedzi. 200 z pustą treścią = problem.

Metoda 4: Google Search Console

Użyj funkcji “Wyświetl renderowaną stronę”. To co prawda Google (renderuje JS), ale pokazuje ideał.

Metoda 5: Monitoruj widoczność w AI

Użyj Am I Cited, by śledzić cytowania. Jeśli nie jesteś widoczny mimo dobrych treści, problemem jest prawdopodobnie renderowanie JS.

Szybki test:

Jeśli główna treść nie jest widoczna w wyniku curl, masz problem.

Specyfika wdrożenia Next.js pod kątem widoczności w AI.

Kluczowe wzorce:

Dla stron z treścią:

export async function getServerSideProps() {
  const data = await fetchContent();
  return { props: { data } };
}

Treść pobierana po stronie serwera, zawarta w początkowym HTML.

Dla treści statycznych:

export async function getStaticProps() {
  const data = await fetchContent();
  return {
    props: { data },
    revalidate: 3600 // ISR, przebudowa co godzinę
  };
}

Jeszcze lepiej – pre-renderowane podczas budowania.

Częste błędy:

1. Użycie useEffect dla kluczowej treści

// ŹLE – treść ładowana tylko po stronie klienta
useEffect(() => {
  fetch('/api/content').then(setContent);
}, []);

2. Lazy loading głównej treści

// ŹLE dla AI – treść ładuje się po pierwszym renderze
const Content = lazy(() => import('./Content'));

3. Brak fallbacku w dynamicznych trasach

// DOBRZE – fallback dla stron generowanych w locie
export async function getStaticPaths() {
  return { paths: [...], fallback: 'blocking' };
}

Złota zasada:

Jeśli treść jest ważna dla widoczności w AI, musi być w początkowej odpowiedzi HTML. Bez wyjątków.

Perspektywa Nuxt.js dla użytkowników Vue.

Te same zasady:

Tryb SSR (domyślny w Nuxt 3):

// nuxt.config.ts
export default defineNuxtConfig({
  ssr: true
})

Pobieranie danych przez useAsyncData:

const { data } = await useAsyncData('content',
  () => $fetch('/api/content')
);

Wykonywane po stronie serwera, treść w początkowym HTML.

Generowanie statyczne:

npx nuxi generate

Pre-renderuje wszystkie strony do statycznego HTML.

Zalety Nuxt:

• SSR domyślnie
• Tryb hybrydowy (część stron statyczna, część SSR)
• Dobra wygoda migracji z Vue SPA

Weryfikacja:

Te same testy – wyłącz JS, sprawdź czy treść się pojawia.

Dla Vue SPA: Migracja do Nuxt to ścieżka do widoczności w AI.

Wydajność SSR – na co zwrócić uwagę.

Kompromisy:

SSR zwiększa obciążenie serwera:

• Każde żądanie renderuje stronę
• Większe zużycie CPU
• Potrzebne dobre cache’owanie

Jak temu zaradzić:

CDN z cache’owaniem na krawędzi:

Cache-Control: public, max-age=3600, stale-while-revalidate=86400

Cache’uj renderowany HTML zarówno dla botów, jak i użytkowników.

Incremental Static Regeneration (ISR):

Najlepsze z obu światów:

• Strony statyczne dla szybkości
• Odświeżanie w tle dla aktualności
• Świetne dla stron z treścią

Renderowanie na krawędzi:

Vercel Edge Functions, Cloudflare Workers:

• Renderowanie na edge
• Niższe opóźnienia
• Bliżej użytkownika i bota

W kontekście AI:

Crawlery AI nie potrzebują spersonalizowanych treści. Możesz śmiało cache’ować:

• Wykrywaj user agent bota
• Serwuj cache’owany HTML
• Wystarczająco świeże dla widoczności

Wydajność + widoczność dla AI są możliwe:

SSR nie musi oznaczać wolnego działania. Przy odpowiednim cache’owaniu masz i widoczność dla AI, i dobrą wydajność.

Architektura CMS pod widoczność w AI.

Problem z headless:

Wiele rozwiązań headless:

• CMS przechowuje treść
• Frontend pobiera przez API
• Treści ładują się po stronie klienta

To jest niewidoczne dla crawlerów AI.

Docelowa architektura:

CMS → Warstwa Build/SSR → CDN → Użytkownicy/Boty
         ↓
    Pre-renderowany HTML

Opcje wdrożenia:

Generowanie statyczne podczas builda:

• Pobieranie z CMS podczas budowania
• Generowanie statycznego HTML
• Trigger na rebuild przy zmianie treści

SSR z cache’owaniem:

• Pobieranie z CMS na żądanie
• Renderowanie po stronie serwera
• Cache na CDN

Typowe wzorce CMS:

Contentful/Sanity + Next.js:

export async function getStaticProps() {
  const content = await cmsClient.getContent();
  return { props: { content }, revalidate: 60 };
}

WordPress + Gatsby:

• Pobranie podczas builda
• Generowanie statycznej strony
• Webhooki do rebuildu przy publikacji

Klucz:

Treść musi trafić z CMS do HTML zanim strona dotrze do crawlera AI.

W tym wątku znalazłem odpowiedzi na wszystkie pytania.

Czego się dowiedziałem:

1. Crawlery AI nie renderują JS – nasze SPA jest dla nich niewidoczne
2. SSR to rozwiązanie – migracja do Next.js to właściwa ścieżka
3. Testowanie jest proste – wyłącz JS, curl strony, sprawdź logi
4. Migracja jest realna – 6 tygodni wydaje się osiągalne
5. Wydajność do opanowania – cache i ISR rozwiązuje problem

Nasz plan:

1. Test obecnego stanu – potwierdzić problem z widocznością za pomocą curl
2. Propozycja dla zespołu – przedstawić case migracji do Next.js
3. Zacząć od kluczowych stron – blog, strony produktów najpierw
4. Zweryfikować widoczność w AI – monitorować przez Am I Cited po migracji
5. Dokończyć migrację – wdrożyć na całą stronę

Biznesowy argument:

Jesteśmy niewidoczni dla 70%+ Amerykanów korzystających z AI search. Warto poświęcić 6 tygodni na migrację.

Dzięki za techniczną głębię!