Kan AI-crawlere gengive JavaScript? Vores side er React-baseret, og jeg er bekymret

Kort svar: AI-crawlere gengiver for det meste ikke JavaScript godt. Her er overblikket.

Crawler JavaScript-evner:

Den praktiske virkelighed:

Hvis dit indhold kræver JavaScript for at blive vist:

• Det er sandsynligvis usynligt for de fleste AI-crawlere
• Du bliver ikke citeret i ChatGPT-svar
• Perplexity får måske noget indhold, inkonsekvent
• Du mister AI-synlighed

Løsningshierarki:

Bedst: Server-side rendering (SSR)

• Next.js med getServerSideProps
• Nuxt.js i SSR-tilstand
• Indhold i initialt HTML-svar

Godt: Statisk sidesgenerering (SSG)

• Forudgengivet HTML for alle sider
• Generering ved build-tid
• Virker for indhold, der sjældent ændres

Acceptabelt: Pre-rendering-tjenester

• Prerender.io, lignende tjenester
• Opdager bot, serverer forudgengivet HTML
• Yderligere kompleksitet og omkostning

Ikke anbefalet for AI-synlighed:

• Ren client-side rendering
• Indhold loader via API efter sideindlæsning
• Dynamisk indhold uden fallback

Din situation:

Fuld React SPA = sandsynligvis usynlig for AI. SSR-migration er sandsynligvis nødvendig for AI-synlighed.

Vi gennemførte denne migration. Her er, hvad vi lærte.

Vores setup før:

• Create React App (CRA)
• Alt indhold client-renderet
• API-drevet indholdsindlæsning

Migration til Next.js:

Tidslinje: 6 uger for 50 sider

Nøgletrin:

1. Opsæt Next.js-projekt
2. Migrér komponenter (fungerede mest som de var)
3. Implementér getServerSideProps til data-fetching
4. Opdater routing til Next.js-konventioner
5. Test med JS deaktiveret
6. Deploy og verificér

Udfordringer:

• Data-fetching-mønstre ændrede sig markant
• Nogle klientkun-biblioteker skulle udskiftes
• Byggetider steg (SSR har overhead)
• Måtte gentænke caching-strategi

Resultater:

AI-synlighed:

• Før: 5% citeringsrate for vores emner
• Efter: 28% citeringsrate
• Perplexity begyndte at citere os konsekvent

SEO:

• Time to first meaningful paint blev bedre
• Google-rangeringer steg lidt
• Core Web Vitals forbedret

Værd at gøre?

Absolut. Migreringen tjente sig hjem på 3 måneder målt på forbedret synlighed.

Sådan verificerer du, hvad AI-crawlere faktisk ser.

Testmetoder:

Metode 1: Deaktiver JavaScript

I browserens DevTools:

• Indstillinger → Præferencer → Deaktiver JavaScript
• Se din side
• Det du ser = det de fleste AI-crawlere ser

Metode 2: Curl/Wget

curl https://yoursite.com/page

Dette henter rå HTML. Hvis dit indhold ikke er der, ser AI-crawlere det ikke.

Metode 3: Tjek serverlogs

Se efter forespørgsler fra:

• GPTBot
• ClaudeBot
• PerplexityBot

Tjek svartkoder. 200 med tomt indholdsbody = problem.

Metode 4: Google Search Console

Brug “View rendered page”-funktionen. Selvom det er Google (som gengiver JS), viser det, hvad crawlere ideelt bør se.

Metode 5: Overvåg AI-synlighed

Brug Am I Cited til at spore, om du bliver citeret. Hvis du er usynlig trods godt indhold, er JS-gengivelse sandsynligvis problemet.

Den hurtige test:

Hvis dit hovedindhold ikke er synligt i curl-output, har du et problem.

Next.js-implementeringsspecifik for AI-synlighed.

De vigtige mønstre:

For indholdssider:

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

Indhold hentes server-side, inkluderet i initial HTML.

For statisk indhold:

export async function getStaticProps() {
  const data = await fetchContent();
  return {
    props: { data },
    revalidate: 3600 // ISR, genbyg hver time
  };
}

Endnu bedre - forudgengivet ved build-tid.

Almindelige fejl:

1. Brug af useEffect til kritisk indhold

// DÅRLIGT - indhold loader kun client-side
useEffect(() => {
  fetch('/api/content').then(setContent);
}, []);

2. Lazy loading af hovedindhold

// DÅRLIGT for AI - indhold loader efter initial rendering
const Content = lazy(() => import('./Content'));

3. Manglende fallback i dynamiske ruter

// GODT - giver fallback for sider, der endnu ikke er genereret
export async function getStaticPaths() {
  return { paths: [...], fallback: 'blocking' };
}

Guldfingerreglen:

Hvis indhold er vigtigt for AI-synlighed, skal det være i det initiale HTML-svar. Ingen undtagelser.

Nuxt.js-perspektiv for Vue-brugere.

Samme principper gælder:

SSR-tilstand (default i Nuxt 3):

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

Data-fetching med useAsyncData:

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

Kører på serveren, indhold i initial HTML.

Statisk generering:

npx nuxi generate

Pre-renderer alle sider til statisk HTML.

Nuxt-fordele:

• SSR som standard
• Hybridtilstand (nogle sider statiske, nogle SSR)
• God DX for migration fra Vue SPA

Verificeringen:

Samme tests gælder - deaktiver JS, tjek om indholdet vises.

For Vue SPA’er: Nuxt-migration er din vej til AI-synlighed.

Performance-overvejelser for SSR.

Afgivelserne:

SSR øger serverbelastning:

• Hver forespørgsel gengiver siden
• Mere CPU-forbrug
• Kræver ordentlig caching

Afhjælpningsstrategier:

CDN med edge-caching:

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

Cache gengivet HTML for både bots og brugere.

Incremental Static Regeneration (ISR):

Bedst fra begge verdener:

• Statiske sider for hastighed
• Baggrundsregenerering for friskhed
• Virker godt for indholdssider

Edge rendering:

Vercel Edge Functions, Cloudflare Workers:

• Gengiv ved kanten
• Lavere latenstid
• Tættere på brugere og bots

AI-bot-overvejelsen:

AI-crawlere har ikke brug for personligt indhold. Du kan cache aggressivt for dem:

• Opdag bot user agent
• Server cachet HTML
• Frisk nok for synlighed

Performance + AI-synlighed er opnåelig:

SSR betyder ikke langsomt. Med ordentlig caching får du både AI-synlighed OG god performance.

CMS-arkitektur for AI-synlighed.

Headless-udfordringen:

Mange headless-opsætninger:

• CMS gemmer indhold
• Frontend henter via API
• Indhold loader client-side

Dette er usynligt for AI-crawlere.

Løsningsarkitektur:

CMS → Build/SSR-lag → CDN → Brugere/Bots
         ↓
    Forudgengivet HTML

Implementeringsmuligheder:

Statisk generering ved build:

• Hent fra CMS ved build-tid
• Generér statisk HTML
• Udløs rebuild ved indholdsændring

SSR med caching:

• Hent fra CMS ved forespørgsel
• Gengiv server-side
• Cache ved CDN

Almindelige CMS-mønstre:

Contentful/Sanity + Next.js:

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

WordPress + Gatsby:

• Hent ved build-tid
• Statisk sidesgenerering
• Webhook-rebuilds ved publicering

Det vigtigste:

Indholdet skal fra CMS til HTML, før siden når AI-crawlere.

Denne tråd besvarede alle mine spørgsmål.

Hvad jeg lærte:

1. AI-crawlere gengiver ikke JS – Vores SPA er usynlig for dem
2. SSR er løsningen – Next.js-migration er vejen frem
3. Test er nem – Deaktiver JS, curl siden, tjek logs
4. Migration er gennemførlig – 6 ugers tidsramme virker realistisk
5. Performance er håndterbar – Caching og ISR løser bekymringer

Vores plan:

1. Test nuværende tilstand – Bekræft AI-synlighedsproblem med curl
2. Forslag til teamet – Præsenter Next.js-migrationscase
3. Start med kritiske sider – Blog, produktsider først
4. Verificér AI-synlighed – Overvåg med Am I Cited efter migration
5. Færdiggør migration – Udrul til hele siden

Forretningscase:

Vi er usynlige for 70%+ af amerikanere, der bruger AI-søgning. Det er værd at bruge 6 uger på migrationen.

Tak for den tekniske dybde!