Hoppa till innehåll
SilktideHjälp

Innehåll läsbart utan JavaScript

Sidans huvudinnehåll – stycken, rubriker, tabeller och priser som besökaren är ute efter – måste finnas i den HTML som din server returnerar på första begäran. Förbättringar med är okej. Innehåll som bara dyker upp efter att JavaScript körts är osynligt för de flesta AI-crawlare, och därmed osynligt för assistenterna som citerar från dem.

Genom hela denna sida, anta att Fernwood byggde om sin marknadsföringswebbplats som en ensidesapplikation (SPA). I en webbläsare ser den komplett ut. Att visa källkoden visar ett nästan tomt <div id="root"></div>. Det tomma skalet är vad GPTBot, ClaudeBot, PerplexityBot och liknande crawlare får.

Varför det fungerar

Traditionella sökmotorer har till stor del löst detta: Google renderar JavaScript innan indexering. Svarsmotorer har inte gjort det. Crawlern som förser ChatGPT, Claude, Perplexity och liknande system hämtar i regel det råa HTML-svaret och stannar där – de väntar inte på att ditt ramverk ska hydrera, kör inte din bundle och följer inte klientroutning. Silktides egen jämförelse mellan crawlningar (renderad sida vs. rå HTML) bygger exakt på det beteendet; se Innehåll utan JavaScript.

Felbilden är tyst och total:

  • En sida som rankar bra i Google kan vara helt frånvarande i AI-svar, eftersom assistenterna aldrig fick texten.
  • Varje annan AEO‑investering på den sidan – strukturerad data, maskinläsbara datum, svar‑först‑skrivning – är värdelös om crawlare aldrig ser innehållet som dessa signaler beskriver.
  • Mänskliga besökare med misslyckade eller blockerade skript ser samma tomma skal, och First Contentful Paint försämras även när skripten till slut lyckas.

Detta är ett arkitekturproblem för webbplatsen, inte ett redigeringsproblem per sida. Att laga en URL för hand lagar inte mallen som producerar de nästa hundra.

Så kontrollerar du vad en crawler ser

Bekräfta problemet innan du ändrar något. Tre sätt, starkast först:

  1. Silktides kontroll. Innehåll utan JavaScript jämför den meningsfulla brödtexten i den renderade sidan med den råa HTML som fångades vid crawlning. Den flaggar sidor där den råa texten både ligger under cirka ~10% av den renderade texten och är liten i absoluta tal – ett genuint tomt skal, inte en sida som bara förstärker sig själv.
  2. Visa källkoden, inte DevTools Elements. I webbläsaren visar ”Visa sidkällkod” vad servern skickade. Panelen Elements visar DOM:en efter att JavaScript har körts. Om din artikeltext finns i Elements men saknas i Visa sidkällkod kommer crawlare som hoppar över JS inte att se den.
  3. Hämta utan en webbläsare. Från en terminal: curl -sL https:\/\/fernwood.example\/pricing | head. Eller använd en textbaserad webbläsare. Om pristabellen saknas i det utdata saknas den även för crawlern.

Bekräfta också att crawlern alls tillåts in – ett perfekt HTML‑svar är värdelöst om robots.txt blockerar AI‑crawlern, eller om en brandvägg blockerar den i praktiken (AI‑crawlare blockerade i praktiken).

Så åtgärdar du det

Välj det angreppssätt som passar din stack. Alla tre ger samma resultat: det första HTML-svaret innehåller innehållet.

1. Server-side rendering (SSR)

Servern renderar varje sida till HTML vid begäran; därefter hydrerar JavaScript för interaktivitet. Detta är standardvägen för ramverk som redan stöder det:

  • Next.js – använd App Router med Server Components, eller getServerSideProps / getStaticProps i Pages Router. Skicka inte en klient‑endast rot som hämtar innehållet efter att komponenten har monterats.
  • Nuxt – universal / SSR‑läge (standard), inte ssr: false.
  • Remix, SvelteKit, Astro (SSR‑läge) och motsvarigheter – samma idé: dokumentsvaret inkluderar brödtexten.

Tumregel: om en hämtning i useEffect / onMounted är det som lägger artikeln på sidan, flytta den datahämtningen till servern.

2. Statisk sidgenerering (SSG)

Förbygg sidor som ren HTML vid publicering. Idealiskt för innehåll som inte ändras per besökare – blogginlägg, dokumentation, marknadssidor, prissättning. Astro, Eleventy, Hugo, Next.js output: 'export' och Nuxt generate producerar alla filer som en crawler kan läsa helt utan JavaScript.

SSG är oftast den billigaste vinsten för marknads- och innehållssajter: ingen renderingskostnad per begäran, och HTML:en på disk är precis det crawlern får.

3. Prerendering som en brygga

Om du inte kan byta ramverk ännu kan en prerenderingstjänst eller ett byggsteg leverera en renderad HTML‑ögonblicksbild till crawlare (och ofta till förstagångsbesökare) medan SPA:n fortsätter att köra för interaktiva sessioner. Behandla detta som en brygga, inte en slutpunkt: färskhet i snapshots, cache‑invalidering och autentiserade rutter blir alla egna underhållsbördor. Föredra att åtgärda renderingsläget när du kan.

Googles egna riktlinjer för JavaScript‑SEO och web.dev:s Rendering on the Web täcker samma spektrum – SSR, SSG och progressiv förbättring – från sökmotorsidan av problemet.

Vad som måste finnas i det första HTML‑svaret

Inte varje pixel. Det innehåll som ett citat skulle återge:

  • Själva artikeln eller sidans brödtext – rubriker, stycken, listor, tabeller.
  • Priser, begränsningar och andra fakta som du vill att assistenter ska upprepa.
  • Strukturerad data i ett <script type="application\/ld+json">‑block i den initiala HTML:en – JSON‑LD som injiceras först efter hydrering är lika osynlig som brödtexten.
  • Kanonisk URL, titel och metabeskrivning i <head>.

JavaScript kan fortfarande äga menyer, personalisering, diagram som förstärker en redan närvarande tabell och progressiva funktioner. Silktides kontroll är medvetet förlåtande kring förbättringar: sidor som levererar sitt huvudinnehåll som HTML och lägger beteende ovanpå blir godkända.

Vanliga felmönster

  • Klient‑endast SPA:er – Create React App, Vite‑SPA:er och liknande upplägg som skickar ett tomt skal och hämtar rutter i webbläsaren. Åtgärden är SSR/SSG, inte mer klientkod.
  • Innehåll bakom ”Ladda mer” eller flikar som aldrig finns i HTML:en. Om enda sättet att nå avsnitt tre är ett klick som hämtar det, kommer crawlare aldrig till avsnitt tre. Föredra riktiga URL:er eller inkludera innehållet i det initiala svaret.
  • ”Det fungerar i Google, så vi är klara.” Googlebots rendering ersätter inte läsbarhet för AI‑crawlare. Att klara Google men falla på GPTBot är en vanlig, osynlig klyfta.
  • ”Blockera crawlern och skylla på JavaScript.” Kontrollera alltid AI‑crawler‑åtkomst och effektiv räckvidd tillsammans med denna teknik.

Så hjälper Silktide

Om Silktide inte kan läsa ditt innehåll utan JavaScript, kan inte heller de assistenter du vill bli citerad av.

Relaterat

Senast uppdaterad

Var den här sidan hjälpsam?