Sprachen

SvelteKit-Deployment-SEO: Adapter, Prerendering und Edge-Rendering

Die Adapter- und pro-Route-Prerender-Einstellungen von SvelteKit bestimmen, wo und wann Ihre Seiten gerendert werden – und das beeinflusst TTFB, LCP und Crawl-Budget. Ein deployment-fokussierter Deep Dive: Auswahl von adapter-static/node/vercel/cloudflare/netlify, prerender = true/false/'auto', Edge-Runtime-Einschränkungen und das Erstellen von sitemap.xml und robots.txt.

Erstveröffentlicht: 3. Juli 2026 · Zuletzt aktualisiert: 3. Aug. 2026 · Fortgeschritten
Sprachen
AIVerfasst vonAI v2

Die Adapter- und pro-Route-Prerender-Einstellung von SvelteKit bestimmt, wo und wann eine Seite gerendert wird – statisches HTML zur Build-Zeit, SSR auf einem Server oder SSR am Edge – und diese Entscheidung beeinflusst TTFB, was sich auf LCP und Crawl-Kapazität auswirkt. Wählen Sie adapter-static für reine Content-Seiten, einen node/vercel/cloudflare-Adapter mit pro-Route-Prerender für gemischte Content-plus-App-Seiten und einen Edge-Adapter, wenn globales TTFB wichtig ist (unter Akzeptanz von Cold Starts und ohne Node-fs). prerender = 'auto' ist das Werkzeug für gemischte Seiten. Edge-Runtimes können nicht auf das Dateisystem zugreifen. Und SvelteKit generiert keine sitemap.xml oder robots.txt – Sie erstellen diese als +server.js-Endpunkte, wobei die Strategie von Ihrem Adapter abhängt.

TL;DR — Der Adapter ändert nicht was SvelteKit rendert – er ändert wo und wann: zur Build-Zeit statisch (adapter-static), zur Anfragezeit auf einem von Ihnen betriebenen Server (adapter-node) oder zur Anfragezeit auf Serverless-/Edge-Funktionen (adapter-vercel/-netlify/-cloudflare). Pro-Route prerender = true erstellt statisches HTML und entfernt die Route aus dem dynamischen Manifest; prerender = 'auto' prerendert und behält sie im Manifest – das Werkzeug für gemischte /blog/[slug]-Websites. Edge-Runtimes laufen auf V8-Isolaten: kein Node-fs, und Kaltstarts schaden dem TTFB, was LCP und (laut Googles Crawl-Budget-Dokumentation) die Crawl-Kapazität beeinflusst. SvelteKit generiert keine sitemap.xml oder robots.txt – erstellen Sie sie als +server.js-Endpunkte, und beachten Sie, dass die Strategie vom Adapter abhängt. Dies ist ein engerer, deployment-fokussierter Begleitartikel zum SvelteKit-SEO- Grundlagenartikel in diesem Abschnitt; ich gehe davon aus, dass Sie bereits wissen, dass SvelteKit standardmäßig SSR verwendet, und werde das hier nicht erneut aufrollen.

Die eine Idee, die das alles verständlich macht

Der Adapter ändert nicht, was gerendert wird. Er ändert wo und wann. Das ist die ganze Sache. Die SvelteKit-Dokumentation formuliert es präzise: Adapter „nehmen die gebauten App als Eingabe und generieren Ausgabe für die Bereitstellung.“ Evidence for this claim SvelteKit adapters take the built application as input and generate deployment-specific output. Scope: Deployment output; adapter choice can still constrain supported runtime features. Confidence: high · Verified: SvelteKit: Adapters Ihre Komponenten, Ihre load-Funktionen, Ihre <svelte:head>-Metadaten – identisch über alle Adapter hinweg. Was sich unterscheidet, ist:

  • Wann das HTML erzeugt wird: zur Build-Zeit (statisch/prerendert) oder zur Anfragezeit (SSR auf einem Server, einer Serverless-Funktion oder einer Edge-Funktion).
  • Wo es erzeugt wird: auf einem einzelnen Ursprungsserver, auf einer regionalen Serverless- Funktion oder auf einem Edge-Netzwerk in der Nähe des Besuchers.

Alles unten ist eine Konsequenz dieser beiden Achsen.

Warum Deployment-Entscheidungen SEO-Entscheidungen sind

Die Kette ist kurz und gut dokumentiert: TTFB → LCP → Crawl-Kapazität.

Time to First Byte ist die Zeit, die der Host benötigt, um mit dem Senden der Antwort zu beginnen. Eine prerenderte Datei, die aus einem CDN-Cache ausgeliefert wird, hat ein nahezu null TTFB. Ein Server, der die Seite rendern muss, hat ein höheres. Eine kaltstartende Serverless- oder Edge-Funktion kann beim ersten Aufruf ein viel höheres haben. TTFB ist ein direkter Eingangswert für Largest Contentful Paint – Sie können nicht malen, was Sie nicht empfangen haben – und LCP ist ein Core Web Vitals-Signal.

Die Crawl-Seite ist dort, wo Google am explizitesten ist. Aus der Crawl-Budget- Dokumentation: „Wenn die Website eine Weile schnell antwortet, steigt das Limit, was bedeutet, dass mehr Verbindungen zum Crawlen verwendet werden können. Wenn die Website langsamer wird oder mit Serverfehlern antwortet, sinkt das Limit und Google crawlt weniger.“ Und die Best-Practice-Zeile: „Machen Sie Ihre Seiten effizient ladbar. Wenn Google Ihre Seiten schneller laden und rendern kann, können wir möglicherweise mehr Inhalte von Ihrer Website lesen.“ Eine kaltstartende Edge-Funktion, die langsam antwortet, unterliegt derselben Dynamik wie ein langsamer Ursprungsserver.

Ein Hinweis zur Ehrlichkeit vorab: Google veröffentlicht keine SvelteKit-spezifischen Leitlinien. Es gibt kein Dokument oder keine Search-Off-the-Record-Folge, die SvelteKit-Adapter, prerender = 'auto' oder Edge-Kaltstarts nennt. Was ich hier tue, ist, Googles allgemeine Rendering- und Crawl-Budget-Leitlinien auf SvelteKits spezifische Mechanik anzuwenden – nicht, einen Vertreter zu zitieren, der sich zu SvelteKit geäußert hat, denn keiner hat das getan. Die Google-Formulierung, dass „Server-seitiges Rendering oder Pre-Rendering immer noch eine großartige Idee ist, weil es Ihre Website für Benutzer und Crawler schneller macht und nicht alle Bots JavaScript ausführen können“ ist der nächste offizielle Anker, und er ist framework-agnostisch.

Auswahl eines Adapters für SEO-Ergebnisse

adapter-auto – die Null-Konfigurations-Standardoption und ihre Grenzen

Neue SvelteKit-Projekte werden mit adapter-auto ausgeliefert. Er erkennt die Plattform – Vercel, Netlify, Cloudflare Pages, Azure, AWS – und installiert den passenden Adapter zur Build-Zeit. Das ist ein guter Ausgangspunkt, aber es gibt eine harte Grenze, die man kennen sollte: adapter-auto akzeptiert keine Optionen. Sobald Sie { edge: true }, Cloudflare-Bindings, Vercel ISR oder eine andere plattformspezifische Konfiguration benötigen, installieren Sie den zugrunde liegenden Adapter (adapter-vercel, adapter-cloudflare usw.) direkt. Behandeln Sie Auto als Gerüst, nicht als Produktionsentscheidung.

adapter-static – volles SSG, für inhaltsorientierte Websites

adapter-static rendert Ihre gesamte Website zur Build-Zeit in statische Dateien. Es läuft kein Server; ein Host liefert flaches HTML aus. Evidence for this claim adapter-static prerenders a SvelteKit site as static files. Scope: Routes must be prerenderable; performance outcomes depend on hosting and page design. Confidence: high · Verified: SvelteKit: Static site generation Für eine inhaltsorientierte Website ist dies das stärkste SEO-Profil, das Sie haben können – niedrigste TTFB, keine Cold Starts, nichts, was ausfallen kann. Die eine Anforderung ist die Falle, die im Grundlagenartikel ausführlich behandelt wird: SSR muss während des Builds aktiv bleiben, sonst erhalten Sie leere Hüllen statt gerendertem HTML. Ich werde das hier nicht erneut erklären, sondern nur darauf hinweisen.

Der Haken ist die Starrheit. Alles, was wirklich Serverlogik pro Anfrage benötigt (echte Suche, benutzerspezifische Inhalte, Formularverarbeitung ohne Drittanbieter-Endpunkt), kann nicht auf einem rein statischen Build leben – genau dafür sind die nächsten Adapter da.

adapter-node – ein Server, den Sie kontrollieren

adapter-node erzeugt einen eigenständigen Node.js-Server. Sie betreiben ihn, Sie skalieren ihn, Sie besitzen die TTFB. Dies ist die flexibelste Option und die mit den wenigsten Laufzeit- überraschungen – volle Node-APIs, einschließlich fs. Sie ist eine gute Wahl, wenn Sie bereits Infrastruktur haben, Node-Bibliotheken benötigen, die Edge-Runtimes nicht ausführen können, oder vorhersehbare (nicht kaltstartende) Antwortzeiten von einem warmen Server wünschen. Der Kompromiss ist operativ: Sie betreiben einen Server, und dessen Geschwindigkeit und Verfügbarkeit sind jetzt Ihre Crawl-Kapazität.

adapter-vercel – serverless, Edge und ISR

adapter-vercel stellt standardmäßig auf Vercels Serverless-Funktionen bereit, mit mehreren SEO-relevanten Hebeln, die pro Route über export const config gesetzt werden:

  • runtime: 'edge' verschiebt diese Route in Vercels Edge-Runtime (mehr dazu unten).
  • regions steuert, wo Serverless-Funktionen ausgeführt werden – näher an Ihren Benutzern (oder Ihrer Datenbank) bedeutet geringere Latenz.
  • isr ermöglicht Incremental Static Regeneration: isr: { expiration: 60 } liefert ein gecachtes statisches Asset und regeneriert es nach dem Fenster, was “die Leistungs- und Kostenvorteile von vorgerenderten Inhalten mit der Flexibilität von dynamisch gerenderten Inhalten” bietet. ISR ist ein echter vierter Weg zwischen rein statisch und rein SSR – aber beachten Sie den eigenen Hinweis der Dokumentation: “Die Verwendung von ISR auf einer Route mit export const prerender = true hat keine Auswirkung, da die Route zur Build-Zeit vorgerendert wird.” ISR und Prerendering sind Alternativen, nicht stapelbar.

adapter-cloudflare – Workers/Pages, globales Edge

adapter-cloudflare zielt auf Cloudflare Workers und Pages – SSR in einem globalen Edge- Netzwerk, oft die niedrigste TTFB für ein geografisch verteiltes Publikum. Die wichtige Einschränkung ist die Runtime: Workers laufen auf V8-Isolaten, nicht auf Node. Aus der Dokumentation: “Sie können fs in Cloudflare Workers nicht verwenden.” Einige Node-APIs funktionieren nur hinter dem nodejs_compat-Kompatibilitätsflag, und selbst dann ist die Unterstützung nicht eins zu eins. Wenn Sie zur Anfragezeit Dateien gelesen haben (eine Redirect-Map, eine Datendatei, benutzerdefinierte OG-Bild- Eingaben), muss dieser Code überdacht werden – behandelt im Edge-Abschnitt unten.

(Der ältere adapter-cloudflare-workers ist veraltet; neue Projekte verwenden adapter-cloudflare, das sowohl Workers als auch Pages abdeckt. Wenn Sie den alten verwenden, ist die Migration der empfohlene Weg.)

adapter-netlify – Funktionen oder Edge Functions (Deno)

adapter-netlify stellt standardmäßig auf Netlifys Node-basierten Funktionen bereit, oder auf Deno-basierten Edge Functions mit edge: true. Gleiche Struktur wie Vercel: Standard-Serverless mit Edge-Opt-in. Eine SvelteKit-spezifische Fußnote – Netlify Forms erfordern, dass die Seite des Formulars prerendert wird, damit Netlify das Formular-Markup zur Build-Zeit erkennen kann, was eine kleine „Prerender diese Route“-Anforderung zusätzlich zur Adapter-Wahl darstellt.

Die Entscheidung, jeweils in einem Satz

  • Reine Content-Site → adapter-static, alles prerendern.
  • Content-Site mit dynamischen Bereichen → adapter-node/-vercel/-cloudflare, prerender = true auf Content, false/'auto' auf den dynamischen Routen.
  • App/Dashboard mit Personalisierung → SSR-first (Node oder Edge), nur die statische Hülle prerendern (Marketing, Login).
  • Globale, TTFB-kritische Zielgruppe → ein Edge-Adapter für die dynamischen Routen, mit Akzeptanz der Node-API-Einschränkungen und der Cold-Start-Realität.

(Der Decision-Tree-Tab führt dies als Verzweigungsfluss aus.)

Prerendering-Strategie für gemischte Sites

Was true / false / 'auto' tatsächlich bewirken

export const prerender ist eine Seitenoption pro Route (oder pro Layout), und die drei Werte sind nicht nur an/aus:

  • true — diese Route zur Build-Zeit als statisches HTML bauen. Entscheidend ist, dass sie “von den Manifests für dynamisches SSR ausgeschlossen ist, wodurch Ihr Server (oder Serverless-/Edge-Funktionen) kleiner wird.” Einmal prerendert, kann die Route nicht auf dynamisches Rendering zurückfallen – sie ist statisch, Punkt.
  • false — immer bei Anfrage rendern. Keine statische Datei.
  • 'auto' — das Werkzeug für gemischte Sites. Es prerendert die Route und behält sie im dynamischen Server-Manifest, sodass dieselbe Route für bekannte Pfade statisch und für den Rest servergerendert ausgeliefert werden kann. Dies ist genau für den Fall gebaut, den die Doku beschreibt: eine Route wie /blog/[slug] “wo Sie Ihre neuesten/populärsten Inhalte prerendern, aber den Long Tail serverrendern möchten.”

Da prerenderte Routen das Server-Bundle verkleinern, stellt eine größtenteils prerenderte Site mit einigen 'auto'/false-Routen eine kleinere, günstigere, schnellere Funktion bereit – ein Effizienzgewinn unabhängig von SEO.

Dynamische Routen benötigen eine entries-Funktion

Der Prerender-Crawler entdeckt Seiten, indem er <a>-Links von Ihren Einstiegspunkten folgt. Das funktioniert für statische Routen, aber eine dynamische Route wie /blog/[slug] hat keine feste URL, die der Crawler finden kann. Wenn nichts auf einen bestimmten Slug verlinkt, weiß SvelteKit nicht, dass er existiert – und Sie stoßen auf den klassischen Build-Fehler, dass Routen “als prerenderbar markiert, aber nicht prerendert wurden.”

Die Lösung ist eine explizite entries-Funktion (oder config.kit.prerender.entries), die die Parameterwerte aufzählt:

// src/routes/blog/[slug]/+page.server.js
export const prerender = true;

export function entries() {
  return [
    { slug: 'hello-world' },
    { slug: 'sveltekit-deployment-seo' },
  ];
}

In der Praxis generieren Sie diese Liste aus Ihrem CMS oder Inhaltsverzeichnis. Ohne sie umfasst das Prerendering nur die Slugs, die der Link-Crawler zufällig findet.

Das /blog/[slug]-Muster in der Praxis

Setzen Sie beides zusammen und Sie haben das kanonische Setup für gemischte Sites: prerender = 'auto' plus eine entries-Funktion, die Ihre neuesten und populärsten Beiträge zurückgibt. Diese erhalten zur Build-Zeit statisches HTML; alles, was nicht in der Liste ist, fällt bei Bedarf auf SSR zurück. Neue Beiträge werden dynamisch gerendert, bis der nächste Build sie prerendert. Es ist der pragmatische Mittelweg zwischen “alle 40 000 Beiträge bei jedem Build prerendern” und “jeden Beitrag bei jeder Anfrage rendern.”

Edge-Runtime-Einschränkungen, die SEO beeinflussen

config.runtime = 'edge' ist pro Route (auf Vercel)

Edge ist kein Alles-oder-nichts-Schalter. Auf Vercel ist es eine Seitenoption pro Route:

// +page.server.js or +server.js
export const config = { runtime: 'edge' };

Das bedeutet, Sie können stark frequentierte, cachebare Routen an den Edge pushen für niedrigen TTFB, während Sie Node-abhängige Routen auf der Standard-Serverless- (Node-) Runtime in derselben Bereitstellung halten. Bewusst mischen.

Kein fs, keine beliebigen Node-APIs

Die Edge-Runtimes – Cloudflare Workers, Vercel Edge Functions, Netlify’s Deno Edge Functions – bieten kein Node-fs. Cloudflares Doku: “You can’t use fs in Cloudflare Workers.” Vercels: “You can’t use fs in edge functions.” Beide verweisen auf dieselben zwei Auswege: Nutzen Sie den read-Helper aus $app/server, um gebündelte Assets zu erreichen, oder “prerender the routes in question”, sodass der Dateizugriff zur Build-Zeit statt zur Request-Zeit erfolgt.

Die SEO-nahen Fälle, in denen das zwickt: dynamische OG-Bildgenerierung, die eine Schrift- oder Vorlagendatei liest, dateibasierte Redirect-Maps oder ein Sitemap-Endpunkt, der Inhalte von der Festplatte liest. Jeder davon wandert entweder zu $app/server’s read() oder in die Prerender-/Build-Zeit. Es ist kein Blocker – es ist eine Einschränkung, die man kennen sollte, bevor man sich für Edge entscheidet.

Cold Starts und TTFB – wann Edge hilft und wann nicht

Edge-Funktionen haben weiterhin Cold Starts. Eine kalte Edge-Funktion kann bei ihrer ersten Anfrage langsamer sein als ein warmer Node-Server und deutlich langsamer als eine prerenderte Datei, die aus dem Cache ausgeliefert wird. Edge gewinnt, wenn die Funktion warm bleibt oder wenn sie mit aggressivem Caching kombiniert wird, sodass die meisten Anfragen die Funktion gar nicht erst erreichen. Es ist nicht automatisch die schnellste Option – „deploy to the edge” ist kein Synonym für „faster.” Für eine Content-Site schlägt prerenderter statischer Output Edge-SSR bei TTFB jedes Mal, weil es keine Funktion gibt, die gestartet werden muss.

sitemap.xml und robots.txt generieren (SvelteKit tut es nicht)

Das ist die Lücke, die die meisten SvelteKit-Tutorials überspringen und die meisten Audits finden. SvelteKit generiert keine sitemap.xml und keine robots.txt automatisch – unabhängig vom Adapter, unabhängig davon, wie viele Seiten Sie prerendern. Eine vollständig statische Site mit Tausenden prerenderten Seiten wird weiterhin ohne Sitemap ausgeliefert, es sei denn, Sie bauen eine.

Das +server.js-Endpunktmuster

Die idiomatische Sitemap ist ein Routen-Endpunkt, der XML mit dem richtigen Content-Type zurückgibt:

// src/routes/sitemap.xml/+server.js
export const prerender = true; // needed on adapter-static

export async function GET() {
  const urls = await getAllUrls(); // from your CMS/content
  const body = `<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
${urls.map((u) => `  <url><loc>${u}</loc></url>`).join('\n')}
</urlset>`;

  return new Response(body, {
    headers: { 'Content-Type': 'application/xml' },
  });
}

Die Strategie hängt von Ihrem Adapter ab

Hier ist der Teil, der diesen gesamten Artikel zusammenhält: Ihre Sitemap-Strategie ist eine Folge Ihrer Adapterwahl.

  • Bei adapter-static benötigt der Sitemap-Endpunkt export const prerender = true, damit er in den statischen Output aufgenommen wird – es gibt zur Laufzeit keinen Server, der ihn auf Anfrage generiert. Er wird zur Build-Zeit eingebacken, was bedeutet, dass er nur so aktuell ist wie Ihr letzter Build.
  • Bei einem Node-/Serverless-/Edge-Adapter kann derselbe Endpunkt die Sitemap dynamisch pro Anfrage aus Ihrem CMS oder Ihrer Datenbank generieren – immer aktuell, kein Rebuild nötig. (Bei einem Edge-Adapter beachten Sie die fs-Einschränkung: Ziehen Sie URLs aus einer API oder einer Bindung, nicht aus einem Festplattenzugriff.)

Die Frage „Soll meine Sitemap statisch oder dynamisch sein?” ist also keine separate Entscheidung – sie ergibt sich aus dem Adapter, den Sie bereits gewählt haben.

robots.txt: statische Datei vs. Endpunkt

Zwei Optionen. Legen Sie eine einfache robots.txt in Ihrem static/-Ordner ab (automatisch unter /robots.txt ausgeliefert), was die einfachste Wahl und für die meisten Sites ausreichend ist. Oder generieren Sie sie aus einem src/routes/robots.txt/+server.js-Endpunkt, wenn Sie sie umgebungsabhängig benötigen (z. B. Crawler auf Staging blockieren, in Produktion erlauben). Blockieren Sie in jedem Fall nicht Ihr /_app/-Bundle oder CSS – das bricht das Rendering für Engines, die rendern.

Wenn Sie aus der breiteren Framework- oder JavaScript-SEO-Perspektive kommen, ist die Logik „Wo und wann findet Rendering statt?” hier dieselbe Logik, die JavaScript-SEO allgemein steuert, und der SvelteKit-Grundlagenartikel in diesem Abschnitt behandelt die Rendering-Modi und Metadatenmuster, auf denen dieser Artikel aufbaut.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.