Gå til indhold
SilktideHjælp

Indhold læsbart uden JavaScript

Sidens hovedindhold – de afsnit, overskrifter, tabeller og priser, som en besøgende kom for – skal være til stede i den HTML, som din server returnerer ved den første anmodning. Forbedringer med er helt fine. Indhold, der kun vises efter at JavaScript er kørt, er usynligt for de fleste AI-crawlere og dermed for assistenterne, der citerer fra dem.

På denne side antager vi, at Fernwood har bygget sit marketingsite om som en single-page-applikation. I en browser ser den fuldendt ud. Vis sidekilde viser et næsten tomt <div id="root"></div>. Det er den tomme skal, som GPTBot, ClaudeBot, PerplexityBot og lignende crawlere modtager.

Hvorfor det virker

Traditionelle søgemaskiner har i vid udstrækning løst dette: Google gengiver JavaScript før indeksering. Svar-motorer har ikke. De crawlere, der forsyner ChatGPT, Claude, Perplexity og lignende systemer, henter typisk den rå HTML-respons og stopper der – de venter ikke på, at dit framework hydreres, de kører ikke dit bundle, og de følger ikke klient-side-ruter. Silktides egen crawl-sammenligning (gengivet side vs. rå HTML) bygger netop på den adfærd; se Indhold uden JavaScript.

Fejltilstanden er tavs og total:

  • En side, der rangerer godt i Google, kan være helt fraværende i AI-svar, fordi assistenterne aldrig modtog teksten.
  • Alle andre AEO-investeringer på den side – strukturerede data, maskinlæsbare datoer, svar-først-skrivning – er værdiløse, hvis crawleren aldrig ser det indhold, som disse signaler beskriver.
  • Menneskelige besøgende med fejlede eller blokerede scripts ser den samme tomme skal, og First Contentful Paint (FCP) forværres, selv når scripts til sidst lykkes.

Dette er et problem med site-arkitektur, ikke et side-redigeringsproblem. At rette én URL i hånden løser ikke skabelonen, der producerer de næste hundrede.

Sådan kontrollerer du, hvad en crawler ser

Bekræft problemet, før du ændrer noget. Tre måder, i faldende styrke:

  1. Silktides tjek. Indhold uden JavaScript sammenligner den meningsfulde brødtekst fra den gengivne side med den rå HTML, der blev indfanget ved crawl-tidspunktet. Den markerer sider, hvor den rå tekst både er under ca. 10% af den gengivne tekst og lille i absolutte tal – et ægte tomt skelet, ikke en side der blot forbedrer sig selv.
  2. Vis sidekilde, ikke DevTools Elementer. I browseren viser "Vis sidekilde" det, som serveren sendte. Panelet Elementer viser DOM'en efter, at JavaScript er kørt. Hvis din artikeltekst findes under Elementer men mangler i Vis sidekilde, vil crawlere, der springer JS over, ikke se den.
  3. Hent uden en browser. Fra en terminal: curl -sL https:\/\/fernwood.example\/pricing | head. Eller brug en tekstbaseret browser. Hvis pristabellen mangler i den output, mangler den også for crawleren.

Bekræft også, at crawleren overhovedet må komme ind – en perfekt HTML-respons er ubrugelig, hvis robots.txt blokerer AI-crawleren, eller en firewall blokerer den i praksis (AI-crawlere blokeret i praksis).

Sådan løser du det

Vælg den tilgang, der passer til din stack. Alle tre giver samme resultat: Det første HTML-svar indeholder indholdet.

1. Server-side rendering (SSR)

Serveren gengiver hver side til HTML ved forespørgsel; JavaScript hydrerer derefter for interaktivitet. Dette er standardvejen for frameworks, der allerede understøtter det:

  • Next.js – brug App Router med Server Components, eller getServerSideProps / getStaticProps i Pages Router. Send ikke en klient-kun rod, der henter indhold efter mount.
  • Nuxt – universel / SSR-tilstand (standard), ikke ssr: false.
  • Remix, SvelteKit, Astro (SSR-tilstand) og tilsvarende – samme idé: dokument-responsen inkluderer brødteksten.

Tommelfingerregel: Hvis det er et useEffect / onMounted-fetch, der placerer artiklen på siden, så flyt det datafetch til serveren.

2. Statisk sidegenerering (SSG)

Forbyg sider som ren HTML ved publicering. Ideelt til indhold, der ikke ændrer sig pr. besøgende – blogindlæg, dokumentation, marketingsider, priser. Astro, Eleventy, Hugo, Next.js output: 'export' og Nuxt generate producerer alle filer, som en crawler kan læse helt uden JavaScript.

SSG er som regel den billigste gevinst for marketing- og indholdssites: ingen render-omkostning pr. forespørgsel, og HTML'en på disken er præcis det, crawleren får.

3. Forrendering som bro

Hvis du endnu ikke kan skifte framework, kan en forrenderings-tjeneste eller et build-step levere et gengivet HTML-snapshot til crawlere (og ofte til førstegangsbesøgende), mens SPA'en fortsætter for interaktive sessioner. Betragt dette som en bro, ikke en destination: snapshot-aktualitet, cache-invalidering og autentificerede ruter bliver hver især en vedligeholdelsesbyrde. Foretræk at rette render-tilstanden, når du kan.

Googles egen vejledning om JavaScript SEO og web.dev's Rendering on the Web dækker det samme spektrum – SSR, SSG og progressiv enhancement – set fra søgemaskinens side af problemet.

Hvad skal være i den første HTML

Ikke hver pixel. Det indhold, et citat ville gengive:

  • Artikel- eller sidekroppen – overskrifter, afsnit, lister, tabeller.
  • Priser, grænser og andre fakta, som du vil have assistenter til at gentage.
  • Strukturerede data i en <script type="application\/ld+json">-blok i den indledende HTML – JSON-LD, der først indsættes efter hydrering, er lige så usynlig som brødteksten.
  • Kanonisk URL, title og meta description i <head>.

JavaScript kan stadig styre menuer, personalisering, diagrammer der forbedrer en allerede tilstedeværende tabel, og progressive funktioner. Silktides tjek er bevidst lempeligt omkring enhancement: Sider, der leverer deres hovedindhold som HTML og lægger adfærd ovenpå, består.

Almindelige fejlmønstre

  • Rene klient-side SPA'er – Create React App, Vite-SPA'er og lignende opsætninger, der leverer en tom skal og henter ruter i browseren. Løsningen er SSR/SSG, ikke mere klientkode.
  • Indhold bag "Indlæs mere" eller faner, der aldrig findes i HTML'en. Hvis den eneste vej til sektion tre er et klik, der henter den, når crawlere aldrig til sektion tre. Foretræk rigtige URL'er, eller inkluder indholdet i det indledende svar.
  • "Det virker i Google, så vi er okay." Googlebots rendering er ikke en erstatning for AI-crawler-læselighed. At bestå hos Google og fejle hos GPTBot er en almindelig, usynlig opsplitning.
  • At blokere crawleren og give JavaScript skylden. Tjek altid AI-crawler-adgang og effektiv rækkevidde sammen med denne teknik.

Sådan hjælper Silktide

Hvis Silktide ikke kan læse dit indhold uden JavaScript, kan de assistenter, du vil citeres af, heller ikke.

Relateret

Sidst opdateret

Var denne side nyttig?

Indhold læsbart uden JavaScript | Silktide Hjælp