Diller

SvelteKit Dağıtım SEO'su: Adapter'lar, Prerendering ve Edge Oluşturma

SvelteKit'in adapter'ı ve rota başına prerender ayarları sayfalarınızın nerede ve ne zaman oluşturulacağını belirler — bu da TTFB'yi, LCP'yi ve crawl budget'ı etkiler. Dağıtım odaklı derinlemesine inceleme: adapter-static/node/vercel/cloudflare/netlify seçimi, prerender = true/false/'auto', edge runtime kısıtları ve sitemap.xml ile robots.txt oluşturma.

İlk yayın tarihi: 3 Tem 2026 · Son güncelleme: 8 Ağu 2026 · Advanced
Diller
AIYazanAI v2

SvelteKit'in adapter'ı ve rota başına prerender ayarı, sayfanın nerede ve ne zaman oluşturulacağını — derleme zamanında statik HTML, sunucuda SSR veya edge'de SSR — belirler; bu karar TTFB'yi, dolayısıyla LCP'yi ve tarama kapasitesini etkiler. Saf içerik siteleri için adapter-static, karma içerik ve uygulama siteleri için rota başına prerender kullanan node/vercel/cloudflare adapter'ı, küresel TTFB önemliyse edge adapter'ı seçin (soğuk başlangıçları ve Node fs'inin olmamasını kabul ederek). prerender = 'auto' karma site aracıdır. Edge runtime'ları dosya sistemini okuyamaz. SvelteKit sitemap.xml veya robots.txt üretmez — bunları adapter'ınıza göre +server.js endpoint'leri olarak oluşturmanız gerekir.

TL;DR — Adapter, SvelteKit’in neyi oluşturduğunu değiştirmez — nerede ve ne zaman oluşturduğunu değiştirir: derleme zamanında statik (adapter-static), sizin çalıştırdığınız bir sunucuda istek zamanında (adapter-node) veya serverless/edge fonksiyonlarında istek zamanında (adapter-vercel/-netlify/-cloudflare). Rota başına prerender = true statik HTML oluşturur ve rotayı dinamik manifestten çıkarır; prerender = 'auto' hem prerender eder hem de rotayı manifestte tutar — karma /blog/[slug] siteleri için kullanılan araç budur. Edge runtime’ları V8 isolate’larında çalışır: Node fs yoktur ve soğuk başlangıçlar TTFB’yi kötüleştirir; bu da LCP’yi ve (Google’ın crawl-budget belgesine göre) tarama kapasitesini etkiler. SvelteKit hiçbir sitemap.xml veya robots.txt oluşturmaz — bunları +server.js endpoint’leri olarak kurun ve stratejinin adapter’a bağlı olduğunu unutmayın. Bu, bölümdeki SvelteKit SEO temelleri makalesinin daha dar, dağıtım odaklı eşidir; SvelteKit’in varsayılan olarak SSR kullandığını zaten bildiğinizi ve bunu burada yeniden tartışmayacağımızı varsayıyorum.

Her şeyi yerine oturtan tek fikir

Adapter, neyin oluşturulduğunu değiştirmez. Nerede ve ne zaman oluşturulduğunu değiştirir. Bütün mesele budur. SvelteKit belgeleri bunu kesin olarak şöyle ifade eder: adapter’lar “take the built app as input and generate output for deployment.” 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 Bileşenleriniz, load fonksiyonlarınız ve <svelte:head> metadata’nız her adapter’da aynıdır. Değişenler şunlardır:

  • HTML’nin üretildiği zaman: derleme zamanında (statik/prerender edilmiş) veya istek zamanında (sunucuda, serverless fonksiyonunda ya da edge fonksiyonunda SSR).
  • Üretildiği yer: tek bir origin sunucusu, bölgesel bir serverless fonksiyonu veya ziyaretçiye yakın bir edge ağı.

Aşağıdaki her şey bu iki eksenin sonucudur.

Dağıtım tercihleri neden SEO tercihleridir

Zincir kısa ve iyi belgelenmiştir: TTFB → LCP → tarama kapasitesi.

İlk byte’a kadar geçen süre, hostun yanıtı göndermeye başlamasının ne kadar sürdüğüdür. CDN önbelleğinden sunulan prerender edilmiş bir dosyanın TTFB’si neredeyse sıfırdır. Sayfayı oluşturması gereken bir sunucununki daha yüksektir. Soğuk başlayan bir serverless veya edge fonksiyonunun ilk istekteki TTFB’si çok daha yüksek olabilir. TTFB, Largest Contentful Paint için doğrudan girdidir — almadığınız şeyi boyayamazsınız — ve LCP, Core Web Vitals sinyalidir.

Tarama tarafında Google en açık konuştuğu noktadadır. Crawl-budget belgelerinden: “If the site responds quickly for a while, the limit goes up, meaning more connections can be used to crawl. If the site slows down or responds with server errors, the limit goes down and Google crawls less.” En iyi uygulama satırı da şöyledir: “Make your pages efficient to load. If Google can load and render your pages faster, we might be able to read more content from your site.” Yanıt vermesi yavaş olan soğuk başlayan bir edge fonksiyonu, yavaş bir origin sunucusuyla aynı dinamiğe tabidir.

Başta bir dürüstlük notu: Google, SvelteKit’e özgü bir kılavuz yayımlamıyor. SvelteKit adapter’larını, prerender = 'auto'’yu veya edge soğuk başlangıçlarını adlandıran bir belge ya da Search Off the Record bölümü yok. Burada yaptığım, Google’ın genel oluşturma ve crawl-budget kılavuzunu SvelteKit’in mekaniklerine uygulamak — SvelteKit hakkında yorum yapmış bir temsilciden alıntı yapmak değil, çünkü böyle bir yorum yok. “server-side or pre-rendering is still a great idea because it makes your website faster for users and crawlers, and not all bots can run JavaScript” şeklindeki Google çerçevesi, SvelteKit’ten bağımsız en yakın resmî dayanak.

SEO sonuçları için adapter seçmek

adapter-auto — sıfır yapılandırmalı varsayılan ve sınırı

Yeni SvelteKit projeleri adapter-auto ile gelir. Platformu — Vercel, Netlify, Cloudflare Pages, Azure, AWS — algılar ve eşleşen adapter’ı derleme zamanında kurar. İyi bir başlangıçtır, ancak bilinmesi gereken kesin bir sınır vardır: adapter-auto hiçbir seçenek almaz. { edge: true }, Cloudflare binding’leri, Vercel ISR veya platforma özel bir yapılandırmaya ihtiyaç duyduğunuz anda temel adapter’ı (adapter-vercel, adapter-cloudflare vb.) doğrudan kurarsınız. Auto’yu üretim kararı değil, iskelet olarak görün.

adapter-static — içerik öncelikli siteler için tam SSG

adapter-static, sitenizin tamamını derleme zamanında statik dosyalara prerender eder. Sunucu çalışmaz; bir host düz HTML sunar. 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 İçerik öncelikli bir site için bu, sahip olabileceğiniz en güçlü SEO profilidir — en düşük TTFB, soğuk başlangıç yok, devrilecek hiçbir şey yok. Tek gereklilik, temeller makalesinde ayrıntılı biçimde ele alınan tuzaktır: derleme sırasında SSR açık kalmalıdır, yoksa oluşturulmuş HTML yerine boş kabuklar alırsınız. Burada yalnızca buna işaret edeceğim; yeniden açıklamayacağım.

Sorun katılıktır. Gerçekten istek başına sunucu mantığı gerektiren şeyler (gerçek arama, kullanıcıya özel içerik, üçüncü taraf endpoint olmadan form işleme) tamamen statik bir derlemede yaşayamaz — sonraki adapter’lar tam bunun içindir.

adapter-node — kontrol ettiğiniz bir sunucu

adapter-node bağımsız bir Node.js sunucusu üretir. Siz çalıştırır, ölçeklendirir ve TTFB’sine sahip olursunuz. Bu, en esnek seçenek ve çalışma zamanında en az sürpriz çıkarandır — fs dahil tüm Node API’leri vardır. Altyapınız hazırsa, edge runtime’larının çalıştıramadığı Node kütüphanelerine ihtiyacınız varsa veya sıcak bir sunucudan öngörülebilir (soğuk başlangıçsız) yanıt süreleri istiyorsanız iyi seçimdir. Ödün operasyoneldir: bir sunucu çalıştırıyorsunuz ve artık hızıyla çalışma süresi sizin tarama kapasitenizdir.

adapter-vercel — serverless, edge ve ISR

adapter-vercel varsayılan olarak Vercel’in serverless fonksiyonlarına dağıtım yapar; SEO açısından önemli birkaç kaldıraç rota başına export const config ile ayarlanır:

  • runtime: 'edge', rotayı Vercel’in edge runtime’ına taşır (aşağıda daha fazla bilgi var).
  • regions, serverless fonksiyonların nerede çalışacağını belirler — kullanıcılarınıza (veya veritabanınıza) daha yakın olmak gecikmeyi azaltır.
  • isr, Incremental Static Regeneration’ı etkinleştirir: isr: { expiration: 60 }, önbelleğe alınmış statik varlığı sunar ve pencereden sonra yeniden oluşturur; böylece “the performance and cost advantages of prerendered content with the flexibility of dynamically rendered content.” elde edilir. ISR, tamamen statik ile tamamen SSR arasında gerçek bir dördüncü yoldur — ancak belgelerin kendi uyarısına dikkat edin: “Using ISR on a route with export const prerender = true will have no effect, since the route is prerendered at build time.” ISR ve prerender alternatiflerdir; üst üste eklenemezler.

adapter-cloudflare — Workers/Pages, küresel edge

adapter-cloudflare, Cloudflare Workers ve Pages’i hedefler — küresel bir edge ağında SSR; coğrafi olarak dağınık bir kitle için çoğu zaman en düşük TTFB. Önemli kısıt runtime’dır: Workers Node değil, V8 isolate’larında çalışır. Belgelerden: “You can’t use fs in Cloudflare Workers.” Bazı Node API’leri yalnızca nodejs_compat uyumluluk bayrağının arkasında çalışır; o durumda bile destek birebir değildir. İstek zamanında dosya okuyorsanız (yönlendirme haritası, veri dosyası veya özel OG görsel girdileri), bu kodun yeniden düşünülmesi gerekir — aşağıdaki edge bölümünde ele alınır.

(Eski adapter-cloudflare-workers kullanımdan kaldırılmıştır; yeni projeler hem Workers hem Pages’i yöneten adapter-cloudflare kullanır. Eskisini kullanıyorsanız geçiş önerilen yoldur.)

adapter-netlify — fonksiyonlar veya Edge Functions (Deno)

adapter-netlify varsayılan olarak Netlify’nin Node tabanlı fonksiyonlarına veya edge: true ile Deno tabanlı Edge Functions’a dağıtır. Vercel’e benzer: varsayılan serverless, isteğe bağlı edge. SvelteKit’e özgü bir dipnot — Netlify Forms, Netlify’nin dağıtım sırasında form işaretlemesini algılayabilmesi için formun sayfasının prerender edilmesini gerektirir; bu, adapter seçiminin üzerine eklenen küçük bir “bu rotayı prerender et” gerekliliğidir.

Karar, her biri tek satırda

  • Saf içerik sitesi → adapter-static, her şeyi prerender edin.
  • Dinamik küçük bölümleri olan içerik sitesi → adapter-node/-vercel/-cloudflare, içerikte prerender = true, dinamik rotalarda false/'auto'.
  • Kişiselleştirmeli uygulama/kontrol paneli → SSR öncelikli (Node veya edge), yalnızca statik kabuğu (pazarlama, giriş) prerender edin.
  • Küresel, TTFB’nin kritik olduğu kitle → dinamik rotalar için bir edge adapter; Node API kısıtlarını ve soğuk başlangıç gerçeğini kabul edin.

(Karar Ağacı sekmesi bunu dallanan bir akış olarak yürütür.)

Karma siteler için prerender stratejisi

true / false / 'auto' gerçekte ne yapar

export const prerender, rota (veya layout) başına bir sayfa seçeneğidir ve bu üç değer yalnızca aç/kapa değildir:

  • true — bu rotayı derleme zamanında statik HTML olarak derler. Kritik nokta: “excluded from manifests used for dynamic SSR, making your server (or serverless/edge functions) smaller.” Prerender edildikten sonra rota dinamik oluşturmaya geri dönemez — tamamen statiktir.
  • false — her zaman istekte oluşturur. Statik dosya yoktur.
  • 'auto' — karma site aracıdır. Rotayı prerender eder ve dinamik sunucu manifestinde tutar; böylece aynı rota bilinen yollar için statik, geri kalanlar için sunucu tarafından oluşturulmuş olarak sunulabilir. Belgelerin tanımladığı şu durum için tasarlanmıştır: en yeni/popüler içeriği prerender etmek, uzun kuyruğu sunucuda oluşturmak istediğiniz /blog/[slug] rotası.

Prerender edilmiş rotalar sunucu paketini küçülttüğü için, birkaç 'auto'/false rotası olan çoğunlukla prerender edilmiş bir site daha küçük, daha ucuz ve daha hızlı bir fonksiyon dağıtır — SEO’dan bağımsız bir verimlilik kazancı.

Dinamik rotalar bir entries fonksiyonuna ihtiyaç duyar

Prerender tarayıcısı sayfaları giriş noktalarından gelen <a> bağlantılarını izleyerek keşfeder. Statik rotalarda bu işe yarar, ancak /blog/[slug] gibi dinamik bir rotanın tarayıcının bulabileceği sabit bir URL’si yoktur. Belirli bir slug’a hiçbir bağlantı vermiyorsa SvelteKit onun var olduğunu bilmez — ve rotaların “were marked as prerenderable, but were not prerendered.” şeklindeki klasik derleme hatasıyla karşılaşırsınız.

Çözüm, parametre değerlerini listeleyen açık bir entries fonksiyonudur (veya config.kit.prerender.entries):

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

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

Bunu pratikte CMS’nizden veya içerik dizininizden üretirsiniz. Bu liste olmadan prerendering yalnızca bağlantı tarayıcısının tesadüfen bulduğu slug’ları kapsar.

Gerçek dünyada /blog/[slug] deseni

İkisini birleştirdiğinizde kanonik karma site kurulumuna ulaşırsınız: yakın tarihli ve popüler yazılarınızı döndüren prerender = 'auto' ile bir entries fonksiyonu. Bunlar derleme zamanında statik HTML alır; listede olmayanlar isteğe göre SSR’a düşer. Yeni yazılar, bir sonraki derleme onları prerender edene kadar dinamik oluşturulur. Bu, her derlemede “40.000 yazının tamamını prerender et” ile “her istekte her yazıyı oluştur” arasındaki pratik orta yoldur.

SEO’yu etkileyen edge runtime kısıtları

config.runtime = 'edge' rota başınadır (Vercel’de)

Edge, ya hep ya hiç anahtarı değildir. Vercel’de rota başına bir sayfa seçeneğidir:

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

Bu, yüksek trafikli ve önbelleğe alınabilir rotaları düşük TTFB için edge’e taşırken Node’a bağlı rotaları aynı dağıtımda standart serverless (Node) runtime’ında tutabileceğiniz anlamına gelir. Bilinçli biçimde karıştırın.

fs yok, rastgele Node API’leri yok

Edge runtime’ları — Cloudflare Workers, Vercel Edge Functions, Netlify’nin Deno Edge Functions’ı — Node’un fs modülünü sağlamaz. Cloudflare belgeleri şöyle der: “You can’t use fs in Cloudflare Workers.” Vercel belgeleri de: “You can’t use fs in edge functions.” Her ikisi aynı iki kaçış yolunu gösterir: paketlenmiş varlıklara erişmek için read içindeki $app/server yardımcısını kullanın veya dosya erişiminin istek zamanında değil derleme zamanında gerçekleşmesi için “prerender the routes in question”.

Bunun SEO’ya komşu olduğu durumlar şunlardır: yazı tipi veya şablon dosyası okuyan dinamik OG görseli üretimi, dosya tabanlı yönlendirme haritaları veya diskteki içeriği okuyan bir sitemap endpoint’i. Bunların her biri ya $app/server içindeki read()’e taşınır ya da prerender/derleme zamanına alınır. Bu bir engel değil — edge’i seçmeden önce bilinmesi gereken bir kısıttır.

Soğuk başlangıçlar ve TTFB — edge ne zaman yardımcı olur, ne zaman olmaz

Edge fonksiyonları yine de soğuk başlayabilir. İlk isteğinde soğuk başlayan bir edge fonksiyonu sıcak bir Node sunucusundan daha yavaş, önbellekten sunulan prerender edilmiş bir dosyadan ise çok daha yavaş olabilir. Edge, fonksiyon sıcak kaldığında veya isteklerin çoğu fonksiyona hiç ulaşmayacak kadar agresif önbellekleme ile birlikte kullanıldığında kazanır. Otomatik olarak en hızlı seçenek değildir — “edge’e dağıt” ifadesi “daha hızlı” ile eş anlamlı değildir. Bir içerik sitesi için prerender edilmiş statik çıktı TTFB’de her zaman edge SSR’ı geçer, çünkü başlatılacak fonksiyon yoktur.

sitemap.xml ve robots.txt üretmek (SvelteKit üretmez)

Bu, çoğu SvelteKit eğitiminde atlanan ve çoğu denetimde yakalanan boşluktur. SvelteKit, adapter’dan veya kaç sayfayı prerender ettiğinizden bağımsız olarak sitemap.xml ve robots.txt dosyalarının hiçbirini otomatik üretmez. Binlerce prerender edilmiş sayfası olan tamamen statik bir site bile, siz oluşturmadıkça sitemap olmadan yayınlanır.

+server.js endpoint deseni

İdiyomatik sitemap, doğru Content-Type ile XML döndüren bir rota endpoint’idir:

// 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' },
  });
}

Strateji adapter’ınıza bağlıdır

Bu makalenin tamamını bağlayan kısım şudur: sitemap stratejiniz, adapter seçiminizin sonucudur.

  • adapter-static üzerinde, sitemap endpoint’inin statik çıktıya dahil edilmesi için export const prerender = true olması gerekir — runtime’da isteğe göre üretecek sunucu yoktur. Derleme sırasında gömülür; yani yalnızca son derlemeniz kadar günceldir.
  • Node/serverless/edge adapter üzerinde, aynı endpoint sitemap’i CMS’nizden veya veritabanınızdan her istekte dinamik olarak üretebilir — her zaman güncel, yeniden derleme gerekmez. (Edge adapter’da fs kısıtını hatırlayın: URL’leri diskten okumak yerine API veya binding üzerinden alın.)

“Sitemap’im statik mi, dinamik mi olmalı?” sorusu ayrı bir karar değildir — seçtiğiniz adapter’dan çıkar.

robots.txt: statik dosya mı endpoint mi

İki seçenek vardır. Düz bir robots.txt dosyasını static/ klasörünüze bırakın (otomatik olarak /robots.txt adresinde sunulur); bu en basit seçenektir ve çoğu site için yeterlidir. Ya da ortamlar arasında farklı olması gerekiyorsa (örneğin staging’de tarayıcıları engelleyip üretimde izin vermek) src/routes/robots.txt/+server.js endpoint’inden üretin. Her iki durumda da /_app/ paketini veya CSS’i engellemeyin — bu, oluşturan motorların sayfayı oluşturmasını bozar.

Buraya daha geniş framework veya JavaScript SEO açısından geliyorsanız, oluşturmanın “nerede ve ne zaman” gerçekleştiği mantığı JavaScript SEO’yu genel olarak yöneten mantığın aynısıdır; bu bölümdeki SvelteKit temelleri yazısı da bu makalenin üzerine kurulduğu oluşturma kiplerini ve metadata kalıplarını kapsar.

Add an expert note

Pin an expert quote

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