Jak AI crawlują strony z nieskończonym przewijaniem? Nasza treść nie jest indeksowana

Wyjaśnię, jak różne AI crawlujące radzą sobie z JavaScriptem:

Wsparcie JavaScript przez AI crawlujące:

Sedno problemu:

Nieskończone przewijanie wymaga:

1. Wykonania JavaScriptu
2. Wywołania zdarzenia przewijania
3. Dodatkowych żądań HTTP
4. Renderowania nowej treści

Większość AI crawlujących odpada na etapie 1 lub 2.

Dlaczego SSR to za mało:

SSR serwuje początkową stronę. Ale treść ładowana przez nieskończone przewijanie nie jest “początkowa” – ładuje się po interakcji. SSR nie rozwiązuje zależności od interakcji.

Fundamentalny problem:

Nieskończone przewijanie jest z natury niekompatybilne z obecnymi możliwościami AI crawlujących. Potrzebujesz alternatywnego podejścia.

Mieliśmy dokładnie ten sam problem. Oto nasze rozwiązanie:

Implementacja podejścia hybrydowego:

// Struktura URL
/blog              // Nieskończone przewijanie (domyślne dla użytkownika)
/blog/archive/1    // Paginacja (dostępne dla crawlerów)
/blog/archive/2

Kluczowe szczegóły wdrożenia:

1. Mapa witryny zawiera tylko paginowane adresy

   • AI crawlujące znajdują strony /blog/archive/*
   • Te renderują pełną treść po stronie serwera

2. Strona z nieskończonym przewijaniem ładuje tę samą treść

   • Wykorzystuje pod spodem API paginacji
   • Lepszy UX dla ludzi

3. Linki wewnętrzne prowadzą do poszczególnych artykułów

   • Nie do pozycji na liście nieskończonego przewijania
   • Każdy artykuł ma własny URL

4. robots.txt:

# Skup crawlerów na poszczególnych artykułach
# Nie na kontenerze nieskończonego przewijania
Sitemap: /sitemap.xml

Efekty:

• UX dla ludzi bez zmian (nieskończone przewijanie)
• AI crawlujące mają dostęp do całej treści przez strony archiwalne
• Wszystkie artykuły zindeksowane
• Liczba cytowań wzrosła 4x po wdrożeniu

Podejście specyficzne dla Next.js:

Wykorzystanie getStaticPaths + getStaticProps:

// pages/blog/page/[page].js
export async function getStaticPaths() {
  const totalPages = await getTotalPages();
  const paths = Array.from({ length: totalPages }, (_, i) => ({
    params: { page: String(i + 1) }
  }));
  return { paths, fallback: false };
}

export async function getStaticProps({ params }) {
  const posts = await getPostsForPage(params.page);
  return { props: { posts, page: params.page } };
}

Korzyści:

• Statyczne strony dla każdej paginacji
• Pełna treść w HTML już podczas budowania
• AI crawlujące dostają kompletną treść
• Szybkie ładowanie (statyczne)

Dodatkowo nieskończone przewijanie jako ulepszenie:

• Po stronie klienta nieskończone przewijanie korzysta z tego samego API
• Podejście progresywnego ulepszenia
• Działa także bez JS

To daje Ci najlepsze z obu światów.

Dodając prerenderowanie jako opcję:

Prerendering dla AI crawlujących:

Możesz wykrywać user-agentów AI i serwować prerenderowaną treść:

// middleware
if (isAICrawler(req.headers['user-agent'])) {
  return servePrerenderedVersion(req.url);
}

Wykrywanie AI crawlujących:

const aiCrawlers = [
  'GPTBot',
  'ChatGPT-User',
  'Google-Extended',
  'ClaudeBot',
  'PerplexityBot',
  'anthropic-ai'
];

function isAICrawler(userAgent) {
  return aiCrawlers.some(crawler =>
    userAgent.includes(crawler)
  );
}

Opcje prerenderowania:

• Prerender.io
• Rendertron
• Własne rozwiązanie na Puppeteerze
• Prerenderowanie na etapie budowania

Uwaga:

Nie wszystkie AI crawlujące jednoznacznie się identyfikują. Niektóre mogą zostać pominięte. To podejście uzupełniające, a nie zamiennik poprawnej paginacji.

Metodologia testowania dostępności dla AI crawlujących:

Testy manualne:

1. Wyłączenie JavaScript:

   • Otwórz bloga w przeglądarce
   • Wyłącz JavaScript
   • Jaka treść jest widoczna?
   • To przybliżony widok crawlów bez JS

2. Podgląd źródła strony:

   • Obejrzyj źródło strony (nie “zbadaj element”)
   • Czy treść jest w HTML?
   • Czy tylko jako placeholdery JS?

3. Test curl:

   curl -A "GPTBot/1.0" https://yoursite.com/blog/
   

   • Czy odpowiedź zawiera faktyczną treść?

Testy automatyczne:

4. Google Search Console:

   • Narzędzie Inspekcja adresu URL
   • “Wyświetl renderowaną stronę” pokazuje widok Googlebota
   • (Nie AI crawlujących, ale podobne renderowanie JS)

5. Audyt Lighthouse:

   • Sprawdź kategorię “SEO”
   • Wskazuje problemy z crawlowalnością

Co powinno się pojawić:

• Treść w początkowej odpowiedzi HTML
• Linki do wszystkich stron wykrywalne
• Treść widoczna bez JS

Perspektywa e-commerce:

Mamy 10 000+ produktów z funkcją “załaduj więcej”. Oto nasze rozwiązanie:

Struktura strony kategorii:

/category/shoes                    # Pierwsze 24 produkty + załaduj więcej
/category/shoes?page=2            # Produkty 25-48
/category/shoes?page=3            # Produkty 49-72

Wdrożenie:

1. Na stronie zawsze dostępne linki do paginacji

   • Nawet gdy nieskończone przewijanie jest włączone
   • W stopce linki do stron 1, 2, 3…

2. Parametry ?page= są canonical

   • Każda strona to osobna treść
   • Nie duplikat strony głównej

3. Mapa witryny obejmuje wszystkie paginowane adresy

   • Nie tylko bazowy URL przewijania

4. Produkty mają własne adresy

   • Paginacja kategorii służy do wykrywania
   • Produkty to właściwa treść

Efekt:

Platformy AI cytują nasze strony produktów, które znajdują dzięki paginacji kategorii.

To było niesamowicie pomocne. Oto mój plan wdrożenia:

Podejście: hybrydowa paginacja

Faza 1: Dodanie tras paginowanych (tygodnie 1-2)

• Stworzenie tras /blog/archive/[page]
• SSR dla pełnej treści w HTML
• Dodanie nawigacji paginacyjnej
• Aktualizacja sitemap, by je uwzględniała

Faza 2: Aktualizacja obecnego nieskończonego przewijania (tydzień 3)

• Pozostawienie nieskończonego przewijania na /blog
• Strony archiwalne jako źródło danych
• Canonical z /blog na /blog/archive/1

Faza 3: Testy i walidacja (tydzień 4)

• Testy z wyłączonym JS
• Testy curl dla user-agentów AI
• Monitoring liczby cytowań przez AI

Implementacja techniczna:

/blog                 → Nieskończone przewijanie (dla ludzi, canonical do archive/1)
/blog/archive/1       → Paginacja (dla crawlerów, canonical do siebie)
/blog/archive/2       → Paginacja (dla crawlerów)
/blog/[slug]          → Pojedyncze artykuły (główna treść)

Kluczowe zasady:

• Treść dostępna bez JavaScriptu
• Każdy fragment treści ma bezpośredni adres URL
• Sitemap obejmuje wszystkie strony z treścią
• Nieskończone przewijanie to ulepszenie, nie wymóg

Dzięki wszystkim za szczegółowe, techniczne wskazówki.