SEO Deployment SvelteKit: Adapter, Prerender, dan Rendering Edge

TL;DR — SvelteKit sudah merender halaman Anda di server—bagian itu sudah ditangani. Halaman ini membahas keputusan berikutnya: bagaimana situs Anda dibangun dan diterapkan. Sebuah adapter mengemas aplikasi SvelteKit Anda untuk suatu host (host berkas statis, server Node, atau layanan seperti Vercel atau Cloudflare), sedangkan pengaturan prerender per halaman menentukan apakah halaman diubah lebih awal menjadi berkas HTML biasa atau dirender baru pada setiap kunjungan. Kedua pilihan itu menentukan seberapa cepat perayap menerima HTML Anda—dan SvelteKit tidak akan membuat sitemap atau robots.txt, jadi Anda harus menambahkannya sendiri.

Apa itu adapter (secara sederhana)

Jika Anda sudah pernah membangun situs SvelteKit, Anda tahu bahwa SvelteKit mengirimkan HTML yang sebenarnya ke peramban—kontennya sudah ada sebelum JavaScript dijalankan. Bagus. Masalah SEO yang sulit itu sudah teratasi (dan jika masalah tersebut belum teratasi bagi Anda, artikel dasar-dasar SvelteKit di bagian yang sama membahas mode rendering dan jebakan “kerangka kosong” yang perlu Anda hindari terlebih dahulu).

Sebuah adapter adalah plugin kecil yang mengambil hasil build SvelteKit Anda dan mengubahnya menjadi sesuatu yang dapat dijalankan oleh host tertentu. Bukti untuk klaim ini SvelteKit adapters transform a built application for deployment to a particular environment. Cakupan: SvelteKit adapters. Tingkat keyakinan: tinggi · Diverifikasi: 2026-07-14 SvelteKit: Adapters Situsnya sama, kemasannya berbeda:

• adapter-static mengubah setiap halaman menjadi berkas HTML biasa yang dibangun satu kali. Cocok untuk blog, dokumentasi, atau situs pemasaran yang tidak berubah bagi setiap pengunjung.
• adapter-node membungkus aplikasi Anda dalam server Node.js yang Anda jalankan sendiri.
• adapter-vercel, adapter-netlify, adapter-cloudflare mengemas aplikasi untuk layanan hosting tersebut, yang merender halaman sesuai permintaan— terkadang di server “pada edge”, yang secara fisik dekat dengan pengunjung.

Kontennya sama dalam semua kasus. Yang berubah adalah kapan HTML dibuat (sebelumnya atau pada setiap permintaan) dan di mana HTML dibuat (di satu server atau jaringan global).

Mengapa ini keputusan SEO, bukan sekadar keputusan teknis

Hal utamanya adalah kecepatan. Halaman yang sudah menjadi berkas statis dimuat hampir seketika. Halaman yang harus dibangun di server memerlukan sedikit waktu. Google juga menyatakan dengan jelas bahwa jika situs Anda “responds quickly for a while, the limit goes up, meaning more connections can be used to crawl. If the site slows down… the limit goes down and Google crawls less.” (terjemahan) «merespons dengan cepat selama beberapa waktu, batasnya naik sehingga lebih banyak koneksi dapat digunakan untuk merayapi. Jika situs melambat… batasnya turun dan Google merayapi lebih sedikit.» Jadi, penerapan yang lambat bukan hanya mengganggu pengguna—hal itu dapat membuat Google membaca lebih sedikit bagian situs Anda.

Versi sederhana untuk mengambil keputusan

• Situs konten (blog, dokumentasi, pemasaran) → gunakan adapter-static dan lakukan prerender pada semuanya. Secepat mungkin dan tidak ada proses dinamis yang bisa rusak.
• Situs konten dengan beberapa bagian dinamis (pencarian, komentar) → gunakan adapter server (node/vercel/cloudflare) dan tandai halaman konten Anda dengan prerender = true, sementara bagian dinamis dirender saat diminta.
• Aplikasi atau dasbor dengan halaman yang dipersonalisasi bagi pengguna yang telah masuk → render di server (SSR), dan lakukan prerender hanya pada halaman pemasaran publik.

Jangan lupakan dua berkas yang tidak akan dibuat SvelteKit untuk Anda

SvelteKit tidak menghasilkan sitemap.xml atau robots.txt secara otomatis. Anda menambahkannya sendiri—biasanya sebagai berkas endpoint kecil (sitemap.xml/+server.js) serta berkas di folder static/ atau endpoint lain untuk robots.txt. Bukti untuk klaim ini SvelteKit can serve static assets from its static directory and create custom responses with +server route files. Cakupan: Mechanisms for robots.txt and sitemap.xml; files are not generated automatically. Tingkat keyakinan: tinggi · Diverifikasi: 2026-07-14 SvelteKit: Project structure SvelteKit: Routing Hal ini mudah terlupakan karena sebagian besar framework yang merender HTML bagi Anda terasa “lengkap”. Kedua berkas ini tidak termasuk.

Ingin versi yang lebih mendalam—apa pengaruh setiap adapter terhadap rendering, bagaimana prerender = 'auto' menangani situs campuran, mengapa fungsi edge tidak dapat membaca berkas, dan bagaimana strategi sitemap berubah menurut adapter? Beralihlah ke tab Lanjutan.

TL;DR — Adapter tidak mengubah apa yang dirender SvelteKit—adapter mengubah di mana dan kapan: statis pada waktu build (adapter-static), saat diminta pada server yang Anda jalankan (adapter-node), atau saat diminta pada fungsi serverless/edge (adapter-vercel/-netlify/-cloudflare). prerender = true per rute membangun HTML statis dan menghapus rute dari manifest dinamis; prerender = 'auto' melakukan prerender dan tetap menyimpannya dalam manifest—alat untuk situs campuran /blog/[slug]. Runtime edge berjalan pada isolate V8: tidak ada fs Node, dan inisialisasi dingin merugikan TTFB, yang berdampak pada LCP serta (menurut dokumen anggaran crawling Google) kapasitas crawling. SvelteKit tidak menghasilkan sitemap.xml atau robots.txt—buat keduanya sebagai endpoint +server.js, dan perhatikan bahwa strateginya bergantung pada adapter. Artikel ini adalah pendamping yang lebih sempit dan berfokus pada deployment untuk artikel dasar-dasar SEO SvelteKit di bagian ini; saya menganggap Anda sudah tahu bahwa SvelteKit secara default menggunakan SSR dan tidak akan memperdebatkan hal itu lagi di sini.

Satu gagasan yang membuat semuanya mudah dipahami

Adapter tidak mengubah apa yang dirender. Adapter mengubah di mana dan kapan. Sesederhana itu. Dokumentasi SvelteKit menjelaskannya dengan tepat: adapter “take the built app as input and generate output for deployment.” (terjemahan) «mengambil aplikasi hasil build sebagai input dan menghasilkan keluaran untuk deployment.» Bukti untuk klaim ini SvelteKit adapters take the built application as input and generate deployment-specific output. Cakupan: Deployment output; adapter choice can still constrain supported runtime features. Tingkat keyakinan: tinggi · Diverifikasi: 2026-07-14 SvelteKit: Adapters Komponen, fungsi load, dan metadata <svelte:head> Anda sama persis pada setiap adapter. Perbedaannya adalah:

• Kapan HTML dihasilkan: pada waktu build (statis/prerender) atau pada waktu permintaan (SSR di server, fungsi serverless, atau fungsi edge).
• Di mana HTML dihasilkan: di satu server asal, fungsi serverless regional, atau jaringan edge yang dekat dengan pengunjung.

Semua hal di bawah ini merupakan akibat dari kedua sumbu tersebut.

Mengapa pilihan deployment merupakan pilihan SEO

Rantainya pendek dan terdokumentasi dengan baik: TTFB → LCP → kapasitas crawling.

Waktu hingga byte pertama adalah waktu yang diperlukan penyedia hosting untuk mulai mengirimkan respons. Berkas hasil prerender yang disajikan dari cache CDN memiliki TTFB yang mendekati nol. Peladen yang harus merender halaman memiliki TTFB lebih tinggi. Fungsi serverless atau edge yang mengalami inisialisasi dingin dapat memiliki TTFB yang jauh lebih tinggi pada kunjungan pertama. TTFB merupakan masukan langsung bagi Largest Contentful Paint—Anda tidak dapat menampilkan sesuatu yang belum diterima—dan LCP adalah sinyal Core Web Vitals.

Pada sisi crawling, penjelasan Google paling tegas. Dari dokumentasi anggaran crawling: “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.” (terjemahan) «Jika situs merespons dengan cepat selama beberapa waktu, batasnya naik sehingga lebih banyak koneksi dapat digunakan untuk merayapi. Jika situs melambat atau merespons dengan error server, batasnya turun dan Google merayapi lebih sedikit.» Lalu baris praktik terbaiknya: “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.” (terjemahan) «Buat halaman Anda efisien untuk dimuat. Jika Google dapat memuat dan merender halaman Anda lebih cepat, kami mungkin dapat membaca lebih banyak konten dari situs Anda.» Fungsi edge dengan inisialisasi dingin yang lambat merespons menghadapi dinamika yang sama seperti server asal yang lambat.

Satu catatan kejujuran sejak awal: Google tidak menerbitkan panduan khusus SvelteKit. Tidak ada dokumen atau episode Search Off the Record yang menyebut adapter SvelteKit, prerender = 'auto', atau inisialisasi dingin pada edge. Di sini saya menerapkan panduan umum Google tentang rendering dan anggaran crawling pada mekanisme khusus SvelteKit—bukan mengutip perwakilan Google yang mengomentari SvelteKit karena memang tidak ada. Pernyataan Google bahwa “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” (terjemahan) «rendering sisi server atau prerender tetap merupakan gagasan yang sangat baik karena membuat situs Anda lebih cepat bagi pengguna dan perayap, serta tidak semua bot dapat menjalankan JavaScript» adalah landasan resmi yang paling dekat, dan berlaku lintas framework.

Memilih adapter untuk hasil SEO

adapter-auto—pilihan default tanpa konfigurasi dan batasannya

Proyek SvelteKit baru dilengkapi dengan adapter-auto. Adapter ini mendeteksi platform—Vercel, Netlify, Cloudflare Pages, Azure, atau AWS—lalu memasang adapter yang sesuai pada waktu build. Ini merupakan titik awal yang baik, tetapi ada batas tegas yang perlu diketahui: adapter-auto “does not take any options.” (terjemahan) «tidak menerima opsi apa pun.» Begitu Anda memerlukan { edge: true }, binding Cloudflare, ISR Vercel, atau konfigurasi khusus platform apa pun, pasang adapter dasarnya (adapter-vercel, adapter-cloudflare, dan seterusnya) secara langsung. Perlakukan auto sebagai kerangka awal, bukan keputusan produksi.

adapter-static—SSG penuh untuk situs yang mengutamakan konten

adapter-static melakukan prerender pada seluruh situs Anda menjadi berkas statis pada waktu build. Tidak ada peladen yang berjalan; penyedia hosting menyajikan HTML datar. Bukti untuk klaim ini adapter-static prerenders a SvelteKit site as static files. Cakupan: Routes must be prerenderable; performance outcomes depend on hosting and page design. Tingkat keyakinan: tinggi · Diverifikasi: 2026-07-14 SvelteKit: Static site generation Untuk situs yang mengutamakan konten, inilah profil SEO terkuat yang bisa Anda dapatkan—TTFB terendah, tanpa inisialisasi dingin, dan tidak ada proses yang dapat tumbang. Satu persyaratannya adalah jebakan yang dibahas panjang dalam artikel dasar-dasar: SSR harus tetap aktif selama build, atau Anda akan mendapat kerangka kosong alih-alih HTML yang sudah dirender. Saya tidak akan mengulang penjelasannya di sini selain menandainya.

Kekurangannya adalah kekakuan. Apa pun yang benar-benar memerlukan logika server pada setiap permintaan (pencarian sungguhan, konten per pengguna, penanganan formulir tanpa endpoint pihak ketiga) tidak dapat berada dalam build yang sepenuhnya statis—dan itulah kegunaan adapter berikutnya.

adapter-node—server yang Anda kendalikan

adapter-node menghasilkan server Node.js mandiri. Anda menjalankannya, menskalakannya, dan bertanggung jawab atas TTFB-nya. Ini adalah opsi paling fleksibel dengan paling sedikit kejutan saat runtime—API Node lengkap, termasuk fs. Opsi ini cocok bila Anda sudah memiliki infrastruktur, membutuhkan pustaka Node yang tidak dapat berjalan di runtime edge, atau menginginkan waktu respons yang dapat diprediksi (tanpa inisialisasi dingin) dari server yang sudah hangat. Konsekuensinya bersifat operasional: Anda menjalankan server, dan kecepatan serta waktu aktifnya kini menjadi kapasitas crawling Anda.

adapter-vercel—serverless, edge, dan ISR

Secara default, adapter-vercel melakukan deployment ke fungsi serverless Vercel, dengan beberapa kendali yang relevan bagi SEO dan ditetapkan per rute melalui export const config:

• runtime: 'edge' memindahkan rute tersebut ke runtime edge Vercel (selengkapnya di bawah).
• regions mengendalikan lokasi fungsi serverless berjalan—lebih dekat ke pengguna (atau basis data) berarti latensi lebih rendah.
• isr mengaktifkan Incremental Static Regeneration: isr: { expiration: 60 } menyajikan aset statis dari cache lalu menghasilkannya kembali setelah interval tersebut, sehingga memberi “the performance and cost advantages of prerendered content with the flexibility of dynamically rendered content.” (terjemahan) «keunggulan kinerja dan biaya dari konten hasil prerender dengan fleksibilitas konten yang dirender secara dinamis.» ISR merupakan jalur keempat yang nyata di antara sepenuhnya statis dan sepenuhnya SSR—tetapi perhatikan peringatan dokumentasinya sendiri: “Using ISR on a route with export const prerender = true will have no effect, since the route is prerendered at build time.” (terjemahan) «Menggunakan ISR pada rute dengan export const prerender = true tidak akan berpengaruh karena rute tersebut sudah diprerender pada waktu build.» ISR dan prerender adalah alternatif, bukan sesuatu yang dapat ditumpuk.

adapter-cloudflare—Workers/Pages dan edge global

adapter-cloudflare ditujukan untuk Cloudflare Workers dan Pages—SSR pada jaringan edge global, yang sering memberi TTFB terendah untuk audiens yang tersebar secara geografis. Batasan pentingnya adalah runtime: Workers berjalan di isolate V8, bukan Node. Menurut dokumentasi: “You can’t use fs in Cloudflare Workers.” (terjemahan) «Anda tidak dapat menggunakan fs di Cloudflare Workers.» Sejumlah API Node hanya berfungsi dengan flag kompatibilitas nodejs_compat, dan sekalipun demikian dukungannya tidak satu banding satu. Jika Anda membaca berkas pada waktu permintaan (peta pengalihan, berkas data, input gambar OG khusus), kode tersebut perlu dipikirkan ulang—hal ini dibahas dalam bagian edge di bawah.

(adapter-cloudflare-workers yang lebih lama sudah tidak digunakan lagi; proyek baru memakai adapter-cloudflare, yang menangani Workers dan Pages. Jika Anda masih menggunakan adapter lama, migrasi adalah jalur yang disarankan.)

adapter-netlify—fungsi atau Edge Functions (Deno)

Secara default, adapter-netlify melakukan deployment ke fungsi Netlify berbasis Node, atau ke Edge Functions berbasis Deno dengan edge: true. Polanya sama seperti Vercel: serverless secara default dengan edge sebagai pilihan. Ada satu catatan khusus SvelteKit—Netlify Forms mengharuskan halaman formulir diprerender agar Netlify dapat mendeteksi markup formulir pada waktu deployment. Ini merupakan persyaratan kecil “lakukan prerender pada rute ini” yang ditambahkan di atas pilihan adapter.

Keputusan untuk setiap kasus, masing-masing dalam satu baris

• Situs konten murni → adapter-static, lakukan prerender pada semuanya.
• Situs konten dengan beberapa bagian dinamis → adapter-node/-vercel/-cloudflare, gunakan prerender = true untuk konten dan false/'auto' untuk rute dinamis.
• Aplikasi/dasbor dengan personalisasi → utamakan SSR (node atau edge), dan lakukan prerender hanya pada kerangka statis (pemasaran, login).
• Audiens global yang sangat mengutamakan TTFB → gunakan adapter edge untuk rute dinamis sambil menerima batasan API Node dan kenyataan inisialisasi dingin.

(Tab Pohon Keputusan memandu Anda melewati pilihan ini sebagai alur bercabang.)

Strategi prerender untuk situs campuran

Apa yang sebenarnya dilakukan true / false / 'auto'

export const prerender adalah opsi halaman per rute (atau per layout), dan ketiga nilainya tidak sekadar aktif/nonaktif:

• true—bangun rute ini menjadi HTML statis pada waktu build. Yang terpenting, rute tersebut “excluded from manifests used for dynamic SSR, making your server (or serverless/edge functions) smaller.” (terjemahan) «dikecualikan dari manifest yang digunakan untuk SSR dinamis sehingga server (atau fungsi serverless/edge) Anda menjadi lebih kecil.» Setelah diprerender, rute tersebut tidak dapat beralih kembali ke rendering dinamis—rute itu sepenuhnya statis.
• false—selalu render ketika diminta. Tidak ada berkas statis.
• 'auto'—alat untuk situs campuran. Nilai ini melakukan prerender pada rute dan mempertahankannya dalam manifest server dinamis, sehingga rute yang sama dapat disajikan secara statis bagi path yang diketahui dan dirender di server bagi path lainnya. Fitur ini dibuat tepat untuk kasus yang dijelaskan dokumentasi: rute seperti /blog/[slug] “where you want to prerender your most recent/popular content but server-render the long tail.” (terjemahan) «ketika Anda ingin melakukan prerender pada konten terbaru atau terpopuler, tetapi merender long tail di server.»

Karena rute hasil prerender memperkecil bundle server, situs yang sebagian besar diprerender dengan beberapa rute 'auto'/false akan menerapkan fungsi yang lebih kecil, murah, dan cepat—keuntungan efisiensi yang berdiri sendiri di luar SEO.

Rute dinamis memerlukan fungsi entries

Perayap prerender menemukan halaman dengan mengikuti tautan <a> dari titik masuk Anda. Cara ini berfungsi untuk rute statis, tetapi rute dinamis seperti /blog/[slug] tidak memiliki URL tetap yang dapat ditemukan perayap. Jika tidak ada yang menautkan ke slug tertentu, SvelteKit tidak akan mengetahui bahwa slug tersebut ada—dan Anda akan menemui error build klasik bahwa rute “were marked as prerenderable, but were not prerendered.” (terjemahan) «ditandai sebagai dapat diprerender, tetapi tidak diprerender.»

Solusinya adalah fungsi entries eksplisit (atau config.kit.prerender.entries) yang mencantumkan nilai parameter:

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

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

Dalam praktiknya, Anda menghasilkan daftar tersebut dari CMS atau direktori konten. Tanpanya, prerender hanya mencakup slug yang kebetulan ditemukan oleh perayap tautan.

Pola /blog/[slug] dalam penggunaan nyata

Gabungkan keduanya untuk mendapatkan penyiapan baku situs campuran: prerender = 'auto' ditambah fungsi entries yang mengembalikan postingan terbaru dan populer. Postingan tersebut mendapatkan HTML statis pada waktu build; apa pun yang tidak ada dalam daftar akan beralih ke SSR sesuai permintaan. Postingan baru dirender secara dinamis sampai build berikutnya melakukan prerender. Ini adalah jalan tengah yang pragmatis antara “lakukan prerender pada semua 40,000 postingan setiap kali build” dan “render setiap postingan pada setiap permintaan”.

Batasan runtime edge yang memengaruhi SEO

config.runtime = 'edge' berlaku per rute (di Vercel)

Edge bukan pilihan yang harus diterapkan ke semuanya atau tidak sama sekali. Di Vercel, edge adalah opsi halaman per rute:

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

Artinya, Anda dapat mendorong rute yang ramai dan dapat disimpan dalam cache ke edge untuk memperoleh TTFB rendah, sementara rute yang bergantung pada Node tetap menggunakan runtime serverless standar (Node) dalam deployment yang sama. Padukan keduanya dengan sengaja.

Tanpa fs, tanpa API Node sembarang

Runtime edge—Cloudflare Workers, Vercel Edge Functions, dan Edge Functions berbasis Deno milik Netlify—tidak menyediakan fs Node. Dokumentasi Cloudflare: “You can’t use fs in Cloudflare Workers.” (terjemahan) «Anda tidak dapat menggunakan fs di Cloudflare Workers.» Dokumentasi Vercel: “You can’t use fs in edge functions.” (terjemahan) «Anda tidak dapat menggunakan fs dalam fungsi edge.» Keduanya menunjukkan dua jalan keluar yang sama: gunakan helper read dari $app/server untuk mengakses aset yang dibundel, atau “prerender the routes in question” (terjemahan) «lakukan prerender pada rute yang dimaksud» agar akses berkas terjadi pada waktu build, bukan pada waktu permintaan.

Kasus yang berkaitan dengan SEO dan terdampak oleh batasan ini meliputi pembuatan gambar OG dinamis yang membaca berkas font atau templat, peta pengalihan berbasis berkas, atau endpoint sitemap yang membaca konten dari disk. Semua itu harus beralih ke helper $app/server bernama read() atau dipindahkan ke waktu prerender/build. Ini bukan penghambat—melainkan batasan yang harus diketahui sebelum memilih edge.

Cold start dan TTFB—kapan edge membantu dan kapan tidak

Fungsi edge tetap mengalami inisialisasi dingin. Fungsi edge yang dingin pada permintaan pertamanya dapat lebih lambat daripada server Node yang hangat, dan jauh lebih lambat daripada berkas hasil prerender yang disajikan dari cache. Edge unggul ketika fungsi tetap hangat atau ketika dipadukan dengan caching agresif sehingga sebagian besar permintaan tidak pernah mencapai fungsi tersebut. Edge tidak secara otomatis menjadi opsi tercepat—“melakukan deployment ke edge” tidak sama artinya dengan “lebih cepat”. Untuk situs konten, keluaran statis hasil prerender selalu mengalahkan SSR edge dalam TTFB karena tidak ada fungsi yang harus dimulai.

Menghasilkan sitemap.xml dan robots.txt (SvelteKit tidak melakukannya)

Inilah celah yang dilewatkan oleh sebagian besar tutorial SvelteKit dan ditemukan oleh sebagian besar audit. SvelteKit tidak menghasilkan sitemap.xml dan tidak menghasilkan robots.txt secara otomatis—apa pun adapternya dan berapa pun jumlah halaman yang Anda prerender. Situs yang sepenuhnya statis dengan ribuan halaman hasil prerender tetap dikirim tanpa sitemap kecuali Anda membuatnya.

Pola endpoint +server.js

Sitemap idiomatis berupa endpoint rute yang mengembalikan XML dengan Content-Type yang tepat:

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

Strateginya bergantung pada adapter Anda

Inilah bagian yang menyatukan seluruh artikel ini: strategi sitemap Anda merupakan kelanjutan dari pilihan adapter.

• Pada adapter-static, endpoint sitemap memerlukan export const prerender = true agar disertakan dalam keluaran statis—tidak ada server saat runtime untuk menghasilkannya ketika diminta. Sitemap dibentuk pada waktu build sehingga hanya akan semutakhir build terakhir Anda.
• Pada adapter Node/serverless/edge, endpoint yang sama dapat menghasilkan sitemap secara dinamis pada setiap permintaan dari CMS atau basis data—selalu mutakhir tanpa memerlukan build ulang. (Pada adapter edge, ingat batasan fs: ambil URL dari API atau binding, bukan dengan membaca disk.)

Jadi, pertanyaan “haruskah sitemap saya statis atau dinamis?” bukan keputusan terpisah—jawabannya mengikuti adapter yang sudah Anda pilih.

robots.txt: berkas statis atau endpoint

Ada dua pilihan. Taruh robots.txt biasa dalam folder static/ (otomatis disajikan di /robots.txt), yang merupakan pilihan paling sederhana dan cocok untuk sebagian besar situs. Atau, hasilkan berkas itu dari endpoint src/routes/robots.txt/+server.js bila isinya perlu berbeda menurut lingkungan (misalnya memblokir perayap di staging dan mengizinkannya di produksi). Apa pun pilihannya, jangan blokir bundle /_app/ atau CSS Anda—tindakan itu merusak rendering bagi mesin yang memang melakukan rendering.

Jika Anda melihatnya dari sudut pandang SEO framework atau SEO JavaScript yang lebih luas, logika “di mana dan kapan rendering terjadi” di sini sama dengan logika yang mengatur SEO JavaScript secara umum. Artikel dasar-dasar SvelteKit di bagian ini membahas mode rendering dan pola metadata yang menjadi landasan artikel ini.

Ringkasan AI

Ringkasan padat dari versi Lanjutan:

• Adapter mengubah di mana dan kapan, bukan apa. Adapter “take the built app as input and generate output for deployment” (terjemahan) «mengambil aplikasi hasil build sebagai input dan menghasilkan keluaran untuk deployment»—kontennya sama, tetapi waktunya berbeda (waktu build atau permintaan) dan lokasinya berbeda (asal atau edge).
• Mengapa ini keputusan SEO: TTFB → LCP → kapasitas crawling. Google: jika situs “responds quickly… the limit goes up… If the site slows down… Google crawls less.” (terjemahan) «merespons dengan cepat… batasnya naik… Jika situs melambat… Google merayapi lebih sedikit.» Tidak ada panduan Google yang secara khusus menyebut SvelteKit—ini adalah panduan umum yang diterapkan pada mekanisme SvelteKit.
• Adapter: adapter-auto (tanpa konfigurasi, tanpa opsi); adapter-static (SSG, situs konten, TTFB terendah); adapter-node (server yang Anda kendalikan, API Node lengkap); adapter-vercel (serverless + edge + ISR); adapter-cloudflare (Workers pada edge global, tanpa fs; adapter-cloudflare-workers sudah tidak digunakan lagi); adapter-netlify (fungsi atau Edge Functions Deno).
• Prerender: true membangun HTML statis dan menghapus rute dari manifest dinamis; false selalu menggunakan SSR; 'auto' melakukan prerender dan mempertahankan rute sebagai dinamis—alat untuk situs campuran /blog/[slug] (prerender konten populer, SSR untuk long tail).
• Rute dinamis memerlukan fungsi entries atau Anda akan menemui error “marked as prerenderable, but were not prerendered” (terjemahan) «ditandai sebagai dapat diprerender, tetapi tidak diprerender».
• Batasan edge: runtime: 'edge' berlaku per rute (Vercel); tanpa fs (“You can’t use fs in Cloudflare Workers” (terjemahan) «Anda tidak dapat menggunakan fs di Cloudflare Workers» / fungsi edge)—gunakan helper $app/server bernama read() atau lakukan prerender; cold start dapat membuat edge lebih lambat daripada server hangat atau berkas statis.
• Tidak ada sitemap/robots.txt bawaan. Buat endpoint sitemap.xml/+server.js (prerender = true pada adapter-static; dinamis pada adapter server/edge). Sediakan robots.txt melalui static/ atau endpoint.
• ISR ≠ prerender-plus: “Using ISR on a route with export const prerender = true will have no effect.” (terjemahan) «Menggunakan ISR pada rute yang sudah diatur untuk prerender tidak akan berpengaruh.» Keduanya merupakan alternatif.

Dokumentasi resmi

Dokumentasi sumber primer dari SvelteKit dan mesin pencari.

SvelteKit

• Adapter • Dokumentasi SvelteKit — gambaran umum: adapter mengambil aplikasi hasil build dan menghasilkan keluaran penerapan.
• Penerapan tanpa konfigurasi (adapter-auto) • Dokumentasi SvelteKit — deteksi per penyedia dan batasan “does not take any options” (terjemahan) «tidak menerima opsi apa pun».
• Peladen Node (adapter-node) • Dokumentasi SvelteKit — peladen Node mandiri, variabel lingkungan, dan penghentian yang tertib.
• Pembuatan situs statis (adapter-static) • Dokumentasi SvelteKit — SSG seluruh situs, persyaratan SSR, dan peringatan SEO untuk fallback SPA.
• Vercel (adapter-vercel) • Dokumentasi SvelteKit — runtime, regions, split, dan Incremental Static Regeneration per rute.
• Cloudflare (adapter-cloudflare) • Dokumentasi SvelteKit — Workers/Pages, binding platform.env, nodejs_compat, dan batasan fs.
• Cloudflare Workers (adapter-cloudflare-workers, tidak digunakan lagi) • Dokumentasi SvelteKit — adapter lama yang tidak digunakan lagi dan jalur migrasinya.
• Netlify (adapter-netlify) • Dokumentasi SvelteKit — Node Functions dibanding Edge Functions berbasis Deno (edge: true), serta persyaratan prerender untuk Forms.
• Opsi halaman (prerender, ssr, csr, config) • Dokumentasi SvelteKit — prerender = true/false/'auto', fungsi entries, dan config per rute, termasuk runtime: 'edge'.

Google

• Memahami Dasar-dasar SEO JavaScript — antrean rendering dan “not all bots can run JavaScript” (terjemahan) «tidak semua bot dapat menjalankan JavaScript».
• Mengoptimalkan anggaran crawling — kapasitas crawling yang berkaitan dengan kecepatan respons; “make your pages efficient to load” (terjemahan) «buat halaman Anda efisien untuk dimuat».

Bing / Microsoft

• Seri bingbot: JavaScript, Dynamic Rendering, dan Cloaking. Wah! — rekomendasi Bing tentang prerender/rendering dinamis dan penjelasan tentang cloaking.
• Kinerja Front-End Cepat untuk Microsoft Bing — arsitektur SSR + CDN/node edge milik Bing sebagai contoh nyata.

Kutipan dari sumber

Pernyataan resmi dari dokumentasi SvelteKit, Google, dan Bing. Setiap tautan merupakan deep link yang menuju bagian kutipan pada halaman sumber.

Dokumentasi SvelteKit—adapter & opsi halaman

• “adapter-auto does not take any options.” (terjemahan) «adapter-auto tidak menerima opsi apa pun.» — tentang adapter default tanpa konfigurasi. Buka kutipan
• Tentang prerender = true—rute hasil prerender “excluded from manifests used for dynamic SSR, making your server (or serverless/edge functions) smaller.” (terjemahan) «dikecualikan dari manifest yang digunakan untuk SSR dinamis sehingga server (atau fungsi serverless/edge) Anda menjadi lebih kecil.» Buka kutipan
• Tentang 'auto'—kasus /blog/[slug] ketika Anda ingin “prerender your most recent/popular content but server-render the long tail.” (terjemahan) «melakukan prerender pada konten terbaru atau terpopuler, tetapi merender long tail di server.» Buka kutipan
• Tentang batasan fs pada edge—“You can’t use fs in Cloudflare Workers.” (terjemahan) «Anda tidak dapat menggunakan fs di Cloudflare Workers.» Buka kutipan
• Tentang ISR Vercel dibanding prerender—“Using ISR on a route with export const prerender = true will have no effect, since the route is prerendered at build time.” (terjemahan) «Menggunakan ISR pada rute dengan export const prerender = true tidak akan berpengaruh karena rute tersebut diprerender pada waktu build.» Buka kutipan

Google—rendering & anggaran crawling

• “Keep in mind that 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.” (terjemahan) «Ingatlah bahwa rendering sisi server atau prerender tetap merupakan gagasan yang sangat baik karena membuat situs Anda lebih cepat bagi pengguna dan perayap, serta tidak semua bot dapat menjalankan JavaScript.» Buka kutipan
• “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.” (terjemahan) «Jika situs merespons dengan cepat selama beberapa waktu, batasnya naik sehingga lebih banyak koneksi dapat digunakan untuk merayapi. Jika situs melambat atau merespons dengan error server, batasnya turun dan Google merayapi lebih sedikit.» Buka kutipan
• “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.” (terjemahan) «Buat halaman Anda efisien untuk dimuat. Jika Google dapat memuat dan merender halaman Anda lebih cepat, kami mungkin dapat membaca lebih banyak konten dari situs Anda.» Buka kutipan

Bing—prerender & arsitektur edge miliknya sendiri

• “We encourage detecting our bingbot user agent, prerendering the content on the server side and outputting static HTML for such sites…” (terjemahan) «Kami menyarankan agar Anda mendeteksi user agent bingbot kami, melakukan prerender konten di sisi server, dan menghasilkan HTML statis untuk situs tersebut…» — Fabrice Canel & Frédéric Dubut, Microsoft Bing. Buka kutipan
• “User traffic routes first to the closest CDN node (called an ‘edge node’).” (terjemahan) «Lalu lintas pengguna pertama-tama diarahkan ke node CDN terdekat (disebut ‘node edge’).» — Bing Search Quality Insights, tentang arsitektur SSR + edge milik Bing. Buka kutipan

Checklist SEO deployment SvelteKit

Pemeriksaan untuk memastikan penyiapan adapter, prerender, dan sitemap Anda tidak merugikan perayap:

• Anda telah beralih dari adapter-auto ke adapter eksplisit jika memerlukan konfigurasi apa pun (edge, ISR, binding).
• Adapter sesuai dengan jenis situs—adapter-static untuk konten murni, serta adapter server/edge untuk segala sesuatu yang memiliki logika per permintaan.
• Rute konten menggunakan prerender = true (atau 'auto'); hanya rute yang benar-benar dinamis yang tetap menggunakan SSR.
• Rute dinamis campuran (/blog/[slug]) menggunakan prerender = 'auto' dengan fungsi entries yang mencantumkan path yang diketahui.
• Tidak ada error build “marked as prerenderable, but were not prerendered” (terjemahan) «ditandai sebagai dapat diprerender, tetapi tidak diprerender» yang belum terselesaikan.
• Jika ada rute yang menggunakan runtime: 'edge', rute tersebut tidak memanggil fs Node—akses berkas menggunakan helper $app/server bernama read() atau dilakukan saat prerender.
• Anda telah memperhitungkan inisialisasi dingin pada edge/serverless—gunakan cache, keluaran statis, atau jaga agar tetap hangat ketika TTFB penting.
• Tersedia endpoint sitemap.xml (prerender = true pada adapter-static; dinamis pada adapter server/edge).
• Tersedia robots.txt (dalam static/ atau sebagai endpoint +server.js) dan berkas tersebut tidak memblokir /_app/ atau CSS.
• Anda tidak mencoba menumpuk ISR pada rute prerender = true (tidak berpengaruh).
• Anda memverifikasi HTML hasil rendering dan kecepatan respons dalam Inspeksi URL GSC serta PageSpeed Insights.

Model mental

1. Di mana dan kapan, bukan apa. Adapter tidak pernah mengubah konten Anda—adapter mengubah kapan HTML dibuat (waktu build dibanding waktu permintaan) dan di mana (asal dibanding edge). Setiap pertanyaan SEO tentang deployment bermuara pada kedua sumbu tersebut. Tanyakan keduanya sebelum menyentuh konfigurasi.

2. Prerender menghapus rute dari server. prerender = true bukan sekadar “membuatnya statis”—nilai ini mengeluarkan rute dari manifest dinamis. Hal itu memperkecil fungsi dan meniadakan fallback dinamis. 'auto' adalah pengecualian: sudah diprerender dan tetap berada dalam manifest.

3. Pembagian /blog/[slug]. Pola default bagi situs konten nyata: lakukan prerender pada entri yang dapat Anda sebutkan (fungsi entries mengembalikan entri terbaru/populer), lalu gunakan SSR untuk long tail. 'auto' adalah sakelar yang memungkinkan keduanya berlaku sekaligus.

4. Edge adalah pertukaran, bukan peningkatan. Edge memberi kedekatan geografis (TTFB rendah saat hangat) dengan konsekuensi kehilangan API Node (tanpa fs) dan risiko inisialisasi dingin. Edge hanya terkadang mengalahkan server Node yang hangat, dan selalu kalah dari keluaran statis hasil prerender dalam TTFB. Pilih edge karena suatu alasan, bukan secara default.

5. Sitemap mengikuti adapter. “Sitemap statis atau dinamis?” bukan keputusan terpisah. adapter-static → sitemap hasil prerender, hanya mutakhir saat build. Adapter server/edge → sitemap per permintaan, selalu mutakhir. Adapter sudah menjawab pertanyaan tersebut.

6. Tidak ada yang menghasilkan kedua berkas tersebut. SvelteKit tidak membuat sitemap.xml maupun robots.txt, pada adapter apa pun. Jika Anda tidak menulisnya, kedua berkas itu tidak ada. Masukkan hal ini ke dalam checklist peluncuran Anda.

Kombinasi adapter + prerender mana yang harus saya pilih?

Pertanyaan inti “jalur mana yang harus saya ambil?” dalam deployment SvelteKit adalah bagaimana situs ini harus dikirimkan? Ikuti alur berikut untuk situs Anda:

1. Apakah ada halaman yang memerlukan logika server per permintaan—autentikasi, personalisasi, pencarian langsung, penanganan formulir, atau data per pengguna? → Tidak (setiap halaman sama bagi semua pengunjung): lanjut ke 2. → Ya: lompat ke 3.

2. Situs konten murni (blog, dokumentasi, pemasaran). → Gunakan adapter-static, tetapkan prerender = true untuk seluruh situs (atau di layout root). Tambahkan sitemap.xml/+server.js yang diprerender (prerender = true) serta static/robots.txt. TTFB terendah, tanpa inisialisasi dingin, dan tidak ada proses yang harus dijalankan. Berhenti di sini.

3. Apakah seluruh situs dinamis, atau hanya beberapa rute? → Hanya beberapa rute (sebagian besar konten, beberapa bagian dinamis): lanjut ke 4. → Sebagian besar/seluruhnya dinamis (aplikasi, dasbor, ecommerce dengan data per pengguna): lanjut ke 5.

4. Situs konten dengan beberapa bagian dinamis. → Gunakan adapter server/edge (adapter-node, -vercel, atau -cloudflare). Tandai rute konten dengan prerender = true dan rute dinamis dengan false. Untuk rute bergaya /blog/[slug] dengan konten populer yang diketahui, gunakan prerender = 'auto' + fungsi entries. Hasilkan sitemap secara dinamis dari CMS Anda. Selesai.

5. Aplikasi / dasbor / ecommerce (utamakan SSR). Sekarang pilih di mana SSR berjalan: → Latensi yang dapat diprediksi, pustaka Node, dan Anda memiliki infrastruktur: adapter-node (server hangat, API Node lengkap, tanpa kejutan inisialisasi dingin). → Audiens global, TTFB paling penting, tanpa dependensi Node berat: adapter edge (adapter-cloudflare, atau adapter-vercel dengan runtime: 'edge' per rute)—terima kondisi tanpa fs (gunakan helper $app/server bernama read() atau lakukan prerender) dan inisialisasi dingin. Lakukan prerender hanya pada kerangka yang benar-benar statis (pemasaran, login).

Jalur keempat (khusus Vercel): jika suatu rute “sebagian besar statis tetapi sesekali berubah”, pertimbangkan ISR (isr: { expiration }) sebagai pengganti prerender = true—jangan pernah gunakan keduanya karena “ISR on a route with export const prerender = true will have no effect.” (terjemahan) «ISR pada rute dengan export const prerender = true tidak akan berpengaruh.»

Haruskah sitemap saya statis atau dinamis?

Menggunakan adapter-static? → Endpoint sitemap statis/hasil prerender (prerender = true). Sitemap dibentuk pada waktu build; ini cocok untuk situs yang membangun ulang ketika menerbitkan konten.

Menggunakan adapter Node/serverless/edge? → Sitemap dinamis yang dihasilkan per permintaan dari CMS/basis data—selalu mutakhir tanpa build ulang. (Pada edge, ambil URL dari API atau binding, bukan dengan membaca fs dari disk.)

Jangan pernah: mengirim situs tanpa sitemap karena “semua halamannya statis”. Keluaran statis dan keterlihatan melalui sitemap tidak berkaitan— SvelteKit tidak menghasilkan kedua berkas tersebut pada adapter apa pun.

SEO deployment SvelteKit—lembar ringkas

Sekilas tentang adapter

Nilai prerender

Aturan cepat

• Rute dinamis yang diprerender → tambahkan fungsi entries (atau temui error “not prerendered” (terjemahan) «tidak diprerender»).
• runtime: 'edge' berlaku per rute (Vercel)—padukan rute edge dan Node.
• Edge = tanpa fs → gunakan helper $app/server bernama read() atau lakukan prerender.
• Cold start membuat edge lebih lambat daripada server hangat/berkas statis pada permintaan pertama.
• ISR ≠ prerender—isr pada rute prerender = true tidak berpengaruh.
• Tidak ada sitemap/robots.txt otomatis—buat keduanya. Gunakan prerender = true pada endpoint sitemap untuk adapter-static; gunakan versi dinamis pada server/edge.
• Jangan pernah blokir /_app/ atau CSS dalam robots.txt.

Rute hasil prerender tidak ada dalam deployment

Kemungkinan penyebab: perayap tidak dapat menemukan path, nilai entries tidak tersedia, atau prerender gagal. Perbaikan: tambahkan tautan yang dapat dirayapi atau entri eksplisit, dan perlakukan peringatan build sebagai kegagalan rilis. Konfirmasi: manifest keluaran memuat rute tersebut dan produksi mengembalikan HTML lengkap.

adapter-static gagal pada rute dinamis

Kemungkinan penyebab: rute tidak dapat dicantumkan sepenuhnya pada waktu build. Perbaikan: berikan entri yang jumlahnya terbatas, rancang ulang rute, atau gunakan adapter yang mendukung server untuk path tersebut. Konfirmasi: adapter yang dipilih berhasil melakukan build dan setiap rute perwakilan mengembalikan respons yang dimaksud.

Deployment edge menimbulkan error sistem berkas atau API Node

Kemungkinan penyebab: kode rute atau dependensi mengasumsikan fitur Node yang tidak tersedia di runtime edge. Perbaikan: ganti dependensi, pindahkan proses ke layanan yang kompatibel, atau pilih adapter Node. Konfirmasi: SSR produksi berhasil tanpa pengecualian runtime.

Sitemap atau robots.txt mengembalikan HTML

Kemungkinan penyebab: rute fallback menangkap endpoint atau handler +server menetapkan isi/header yang salah. Perbaikan: buat handler endpoint eksplisit dengan jenis konten yang benar. Konfirmasi: permintaan langsung mengembalikan respons teks/XML yang diharapkan dan status 200.

Metadata berbeda antara rute hasil prerender dan rute SSR

Kemungkinan penyebab: data head dimuat melalui jalur kode yang berbeda atau bergantung pada keadaan peramban. Perbaikan: pusatkan pembuatan metadata dari data halaman yang aman digunakan di server/build. Konfirmasi: HTML mentah untuk kedua jenis rute memuat logika judul, kanonis, dan robots yang setara.

Pastikan apa yang sebenarnya dikirimkan oleh adapter Anda

Tujuan memilih adapter dan melakukan prerender adalah agar perayap memperoleh HTML lengkap dengan cepat. Pemeriksaan ini memastikan hal itulah yang benar- benar terjadi—dari respons mentah, bukan peramban.

Apakah halaman diprerender/menggunakan SSR (konten ada dalam HTML mentah)?

Perintah curl biasa tidak menjalankan JavaScript sehingga menampilkan persis apa yang dilihat perayap yang tidak melakukan rendering.

macOS / Linux

# Raw HTML as the host sends it (no JS executed)
curl -sL "https://example.com/your-page/" -o raw.html
grep -o "Your unique headline text" raw.html   # empty = CSR shell, not prerendered

Windows (PowerShell)

Invoke-WebRequest -Uri "https://example.com/your-page/" -OutFile raw.html
Select-String -Path raw.html -Pattern "Your unique headline text"

Apakah TTFB cepat (atau apakah fungsi mengalami inisialisasi dingin)?

TTFB berdampak pada LCP dan kapasitas crawling, jadi ukurlah. Akses URL dalam kondisi dingin, lalu hangat:

# Time to first byte, twice — a big first number then a small one = cold start
for i in 1 2; do
  curl -s -o /dev/null -w "TTFB: %{time_starttransfer}s\n" "https://example.com/your-page/"
done

Halaman hasil prerender/statis semestinya memiliki nilai yang rendah secara konsisten. Nilai pertama yang besar lalu turun pada akses kedua merupakan tanda klasik inisialisasi dingin pada serverless/edge.

Apakah rute ini diprerender atau disajikan secara dinamis?

Host statis dan CDN biasanya mengungkapkannya dalam header (status cache, age, x-vercel-cache, cf-cache-status):

curl -sI "https://example.com/your-page/" | grep -iE "cache|age|x-vercel|cf-"

HIT (atau age yang tidak nol) berarti Anda menerima konten dari cache/hasil prerender; MISS/DYNAMIC pada setiap permintaan berarti konten dirender pada setiap permintaan.

Apakah sitemap benar-benar ada dan mengembalikan XML?

Karena SvelteKit tidak menghasilkannya, pastikan sitemap Anda benar-benar ada dengan jenis konten yang tepat:

curl -sI "https://example.com/sitemap.xml" | grep -iE "HTTP/|content-type"
# Want: 200 + content-type: application/xml (not text/html or a 404)

Perintah satu baris di konsol DevTools

Tempelkan di konsol peramban untuk membandingkan DOM hasil rendering dengan yang dibutuhkan perayap—jika judul utama Anda ada di sini tetapi tidak ada dalam keluaran curl di atas, judul tersebut dirender di sisi klien:

// Is the content in the DOM, and does the sitemap resolve?
console.log('headline in DOM:', document.body.innerText.includes('Your unique headline text'));
fetch('/sitemap.xml').then(r => console.log('sitemap status:', r.status, r.headers.get('content-type')));

Pastikan robots.txt tidak memblokir bundle

curl -sL "https://example.com/robots.txt" | grep -iE "disallow.*(/_app|\.js|\.css)"

Disallow yang cocok dengan /_app/ (keluaran bundle SvelteKit) atau CSS Anda berarti mesin pencari tidak dapat merender halaman—hampir selalu merupakan kesalahan.

Alat untuk men-debug SEO deployment SvelteKit

• Inspeksi URL (Konsol Penelusuran Google)—sumber informasi utama. Uji URL aktif dan periksa HTML hasil rendering, tangkapan layar, serta resource halaman untuk memastikan konten dan metadata tersedia dan tidak ada yang diblokir.
• PageSpeed Insights—alat yang direkomendasikan oleh dokumentasi SvelteKit sendiri; menampilkan TTFB dan Core Web Vitals (LCP/INP/CLS) yang paling dipengaruhi oleh pilihan adapter Anda.
• WebPageTest—waterfall + filmstrip untuk mendiagnosis TTFB dan waktu cold start pada deployment edge/serverless.
• curl -w "%{time_starttransfer}"—pemeriksaan mentah tercepat untuk TTFB dan inisialisasi dingin (lihat tab Skrip).
• Dasbor penyedia hosting (Vercel / Cloudflare / Netlify Analytics)—jumlah pemanggilan fungsi, tingkat inisialisasi dingin, dan rasio cache hit per rute—bukti nyata apakah edge/serverless memang cepat bagi Anda.
• Screaming Frog SEO Spider—rayapi dengan rendering JS aktif/nonaktif untuk membandingkan HTML mentah dan hasil rendering di seluruh situs serta memastikan rute hasil prerender sudah lengkap.
• Ahrefs Site Audit—menampilkan sitemap yang hilang/diblokir, rantai pengalihan, kanonis rusak, dan masalah keterindeksan dalam skala besar.

Uji diri Anda: SEO Deployment SvelteKit

Lima pertanyaan singkat tentang adapter, prerender, dan rendering edge di SvelteKit. Pilih satu jawaban untuk setiap pertanyaan, lalu periksa hasilnya.

Resource yang layak Anda baca

Tulisan saya yang terkait

• SEO JavaScript: Panduan Lengkap — referensi lengkap saya tentang mode rendering (SSR, rendering statis, prerender, dan masalah CSR) yang mendasari setiap keputusan adapter di sini. Seperti yang saya tulis di sana, segala bentuk penyiapan SSR, rendering statis, atau prerender akan baik-baik saja bagi mesin pencari—dan itulah jaring pengaman di balik pilihan adapter ini.
• Panduan Pemula untuk SEO Teknis — tempat rendering, crawling, dan Core Web Vitals berada dalam gambaran yang lebih besar.

Presentasi saya

• Cara Kerja Penelusuran (SlideShare) — penjelasan saya tentang crawling, rendering, pengindeksan, dan pemeringkatan, yang menjadi latar belakang mengapa TTFB dan waktu rendering penting. (Penyangkalan saya yang selalu berlaku: “This is my understanding of systems… not going to be 100% complete or accurate.” (terjemahan) «Ini adalah pemahaman saya tentang sistem… dan tidak akan 100% lengkap atau akurat.»)

Dari sumber industri

• Adapter • Dokumentasi SvelteKit — gambaran resmi tentang setiap adapter resmi dan cara menentukannya dalam svelte.config.js.
• Opsi halaman (prerender, ssr, csr, config) • Dokumentasi SvelteKit — nilai prerender per rute, fungsi entries, dan config per rute termasuk runtime: 'edge', menurut kata-kata tim tersebut sendiri.
• Vercel (adapter-vercel) • Dokumentasi SvelteKit — runtime edge, wilayah, dan peringatan ISR dibanding prerender.
• Cloudflare (adapter-cloudflare) • Dokumentasi SvelteKit — deployment Workers/Pages, binding, dan batasan fs.
• SvelteKit • Dokumentasi Cloudflare — mekanisme penerapan dan binding platform dari sisi Cloudflare.
• SEO SvelteKit: Senjata Rahasia Anda (Okupter) — panduan praktisi untuk prerender, tag meta, dan pola sitemap/RSS +server.js.
• Pembahasan Mendalam tentang Teknik Rendering SvelteKit (This Dot Labs) — mekanisme SSR/SSG/CSR dan konfigurasi per rute/per layout, dengan konsekuensi beban server “SSR can be expensive” (terjemahan) «SSR bisa mahal».
• Memahami Dasar-dasar SEO JavaScript (Pusat Penelusuran Google) — antrean rendering dan “not all bots can run JavaScript” (terjemahan) «tidak semua bot dapat menjalankan JavaScript», yaitu panduan umum yang mendasari setiap pilihan adapter.

Log perubahan