Svelte SEO

TL;DR — The most important thing to know about Svelte SEOSvelte SEO is the practice of making sure search engines and AI crawlers can see content built with Svelte. Plain Svelte is client-side rendered (a blank shell), so the key is to use SvelteKit, which renders pages on the server by default. is that Svelte and SvelteKit are not the same thing. Plain Svelte builds the page in the visitor’s browser, so search engines first see a blank shell. SvelteKit — Svelte’s official framework — builds the page on the server and sends finished HTML. Use SvelteKit for anything you want to rank.

Svelte vs. SvelteKit

Svelte is a tool for building user interfaces. It’s clever: instead of shipping a big JavaScript library to the browser, it compiles your components down to small, plain JavaScript at build time. That makes Svelte pages fast.

But “fast” and “search-friendly” aren’t the same thing. A plain Svelte app is client-side rendered — the server sends a nearly empty page, and JavaScript fills in the content once it loads in the browser. If a crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. looks at the raw HTML, there’s almost nothing there.

SvelteKit is the official framework built on top of Svelte. It does the thing that matters most for SEO: it renders your pages on the server first, so the HTML that arrives already has your content, your headings, and your links in it. This is the default behavior. If you’re building a site that needs to show up in Google, you want SvelteKit, not bare Svelte.

Why this matters for search

• Google can run JavaScript, so it will eventually see a client-rendered Svelte page — but there’s a delay, and delay hurts fresh contentContent freshness is how recent or up-to-date a page is — by its original publish date, its last substantive revision, or the currency of the facts inside it. It only helps rankings when the query itself benefits from recent results (Query Deserves Freshness), and cosmetic date changes with no real update don't count..
• Bing and other search engines are less reliable at running JavaScript.
• AI crawlersAI crawlers are bots from AI companies that fetch web pages to train language models, build AI-search indexes, or answer live user questions. They come in three categories, each with its own user-agent tokens and its own robots.txt controls. (GPTBot, ClaudeBot, PerplexityBot, and similar) generally fetch static HTML, and renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. behavior varies by provider and changes over time — current provider documentation doesn’t establish one shared render step you can count on filling in a blank shell.

SvelteKit’s server-side renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. sidesteps all of this. The content is in the HTML from the start, so every kind of crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. can read it without depending on a render step it may or may not perform.

The simple checklist

• Build with SvelteKit, not plain Svelte, for content that needs to rank.
• Give every page a unique <title> and <meta name="description"> using SvelteKit’s <svelte:head> element.
• Don’t turn off server-side rendering (don’t use “SPA mode”) for pages you want foundA 302 (\"Found\") is a temporary redirect: it forwards users to a new URL while telling search engines the original URL should stay in the index. It's a weak canonicalization signal, not the zero-equity dead end of SEO folklore..
• Create a sitemapA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing. and a robots.txt (SvelteKit doesn’t make these for you).
• Don’t block your JavaScript or CSS files in robots.txt.

Want the deeper version — the four rendering modes, the adapter trade-offs, the ssr: false trap, and the load-function pattern for metadata? Switch to the Advanced tab.

TL;DR — Svelte SEOSvelte SEO is the practice of making sure search engines and AI crawlers can see content built with Svelte. Plain Svelte is client-side rendered (a blank shell), so the key is to use SvelteKit, which renders pages on the server by default. is really a SvelteKit conversation. Bare Svelte is CSR-only — content isn’t in the raw HTML. SvelteKit defaults to SSR, supports prerenderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. (SSG) per route, and lets you mix modes. Manage metadata with <svelte:head> and feed it from +page.server.js load functions so it lands in the initial HTML. The sharpest trap: adapter-static with ssr: false does not prerenderThe Speculation Rules API is a Chromium browser API (Chrome/Edge 109+) that lets a site tell the browser which same-site pages to prefetch (download the HTML document) or prerender (fully load and render in an invisible tab) before a visitor clicks — so the next navigation can be near-instant. It's a browser-side performance feature for real users, not a crawling, indexing, or ranking signal. — it produces empty shells; SSR must stay on during the build. SvelteKit’s own docs warn SPA fallback has “large negative performance and SEO impacts.” Use History API routing (the default), configure trailingSlash, and pick an adapter to match — static for content, node/vercel/cloudflare for SSR.

Svelte is not SvelteKit — and for SEO that’s everything

Svelte is a compiler. It turns your .svelte components into lean vanilla JavaScript with no virtual DOM and no runtime library shipped to the browser. That gives Svelte a real performance edge — but it’s a bundle-size optimization, not a renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. one. A plain Svelte app (Vite-bundled, no meta-framework) is still a client-side-rendered SPA: the server returns a blank HTML shell and the browser constructs the page. View source on one and your content isn’t there.

This is the #1 source of confusion when people search “Svelte SEO.” The compile step doesn’t put content in the HTML. SvelteKit does. SvelteKit is Svelte’s official meta-framework — the equivalent of Next.js for React or Nuxt for Vue — and it renders pages on the server by default, shipping fully populated HTML before any JavaScript runs. It adds SSR, static prerendering, file-based routing, load functions, and deployment adapters. The headline: bare Svelte = CSR-only; SvelteKit = SSR-first. Everything else in this guide assumes SvelteKit.

Two scoping notes worth stating precisely, because they’re where generic “Svelte SEO” advice goes wrong: SvelteKit’s rendering options (ssr, csr, prerender, trailingSlash) are set per route and inherit hierarchically — a +layout.js or +layout.server.js can set a default for everything beneath it, and a child route can override it. So “is this SvelteKit site SEO-friendly” isn’t a project-level question; check the specific route. And of SvelteKit’s rendering options, it’s specifically ssr: false — not SSR being merely absent, and not “using SvelteKit” in general — that the docs tie to an empty output: “If you set ssr to false, it renders an empty ‘shell’ page instead.” This guide is current for Svelte 5.x and SvelteKit 2.x (the current majors as of this update); Svelte 5 made runes the default reactivity model, but runes are a component-authoring concern, not a rendering mode — they don’t change any of the SEO guidance below.

Why the rendering mode matters comes straight from how search engines workSearch works in three stages — crawling, indexing, and serving (ranking). A page has to clear each one to appear in results: getting crawled doesn't mean you're indexed, and getting indexed doesn't mean you rank.. Google processes JavaScript in three phases — crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor., rendering, and indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. — and “all pages with a 200 HTTP status codeAn HTTP status code is the three-digit number a server returns with every response to tell a browser or crawler what happened to its request — success, redirect, client error, or server error. For SEO the code matters as much as the content: it tells Google and Bing whether to index a page, follow a redirect, retry later, or drop the URL from the index. are sent to the rendering queue, no matter whether JavaScript is present on the page.” The render queue adds a delay, and as Google’s own guidance puts it, “server-side or pre-rendering is still a great idea because it makes your website faster for users and crawlersA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index., and not all bots can run JavaScript.” That last clause is doing a lot of work in 2026 — see the AI-crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. section.

The four rendering modes in SvelteKit

SvelteKit’s strength is that rendering is a per-route decision via page options. These options are hierarchical: set a default in a +layout.js/+layout.server.js and every nested route inherits it, unless a child route exports its own value to override it. Check the option that actually applies to the specific route you care about — not just the value set at the top of the project.

• SSR (the default). Pages are rendered server-side and the full HTML is in the initial response. Best for dynamic, personalized, or frequently changing content. This is on unless you turn it off.
• Prerender (export const prerender = true). Pages are generated as static HTML at build time. Maximum speed and maximum crawlabilityCrawlability is how well search engine crawlers can discover, access, and fetch a site's pages. A crawlability issue is any technical condition — blocked access, broken links, server failures, or bloated URL inventory — that stops pages from reaching the index. — ideal for blog posts, docs, and marketing pages. Crucially, prerendering is SSR run at build time, so SSR must remain enabled for it to work.
• SPA fallback (ssr: false). A single-page-app shell with no server rendering. The SvelteKit docs are blunt that this mode “has large negative performance and SEO impacts” and is really meant for things like wrapping in a mobile app — not for content you want indexed.
• Hybrid. Mix modes per route: prerender your marketing pages, SSR your product pages, run an SPA-style admin behind a login. This is SvelteKit’s killer feature — you don’t pick one rendering mode for the whole site.

The ssr: false trap (the mistake to avoid)

This is the most expensive misunderstanding in SvelteKit SEO, so it gets its own section. People reach for adapter-static to “make a static site,” and then set ssr: false thinking they’re getting prerendered HTML. They aren’t.

Prerendering is server-side rendering executed at build time. If you disable SSR, there is nothing to render — the docs are explicit that ssr: false “renders an empty ‘shell’ page instead,” and that’s exactly what adapter-static then ships as your prerendered output. The content only appears once the client-side JavaScript runs, which puts you right back in CSR territory (with all its crawler problems) despite having a “static” build. The rule: with adapter-static, leave ssr on (its default) so prerendering outputs real HTML. Use ssr: false only when you genuinely want an SPA shell and accept the SEO cost.

Managing metadata with <svelte:head>

SvelteKit has a special element, <svelte:head>, that injects content into the document <head> — and you don’t need a third-party library to manage your title and meta tagsMeta tags are HTML elements in a page's head that pass metadata about the page to search engines and browsers. For SEO only a few matter — the title element, the meta description, and the robots meta tag — while meta keywords and most others are ignored.. Every page should have a unique <title> and <meta name="description">, plus canonical, Open GraphOpen Graph (OG) tags are `<meta>` elements in a page's head, defined by the Open Graph protocol (ogp.me, created by Facebook), that describe a page as a shareable object — its title, description, image, URL, and type. They control how a link preview card looks when the page is shared on Facebook, LinkedIn, Slack, Discord, WhatsApp, and iMessage. They are not a direct Google ranking factor, though Google reads og:title, og:image, and og:site_name as inputs to how a result appears., Twitter Card, hreflang, robots directives, and JSON-LDJSON-LD (JavaScript Object Notation for Linked Data) is a script-based structured data format, typically paired with the schema.org vocabulary to describe page content for search engines and AI systems. Google recommends it over Microdata and RDFa because it's the easiest format to implement and maintain at scale — but all three work, and structured data isn't a ranking signal. as needed.

The pattern the official docs recommend for dynamic metadata:

1. Return SEO metadata from a +page.server.js load() function.
2. Access it via page.data in your layout.
3. Render it in <svelte:head> in the root +layout.svelte.

<!-- +layout.svelte -->
<script>
  import { page } from '$app/state';
</script>

<svelte:head>
  <title>{page.data.title}</title>
  <meta name="description" content={page.data.description} />
  <link rel="canonical" href={page.data.canonical} />
</svelte:head>

If you’d rather use a component wrapper, the third-party svelte-seo package wraps <svelte:head> with props for the common tags — but it’s a convenience, not a requirement.

<svelte:head> gets your tags into the head; it doesn’t verify you got them right. That’s still your job: confirm every route renders a unique title and description (not one inherited from the layout by accident), that the canonical you emit is consistent between the direct-request HTML and what a client-side navigation renders, and that robots directives and JSON-LD are present in the raw response — not only visible after hydrationActivating server-rendered HTML in the browser by attaching JavaScript handlers..

Load functions: where you fetch SEO data matters

This is the metadata bug that bites people. +page.server.js load() runs on the server, so its data is in the initial HTML response. +page.js load() runs on the server for the first render and on the client during client-side navigation. The mistake is fetching your title/description/canonical in a <script> block with onMount() — that runs client-side only, so the initial HTML ships with no metadata and the crawler sees nothing on the first fetch. Fetch SEO-critical data in a load function (server load for anything that must be in the first response), not in onMount.

Don’t assume the file name alone proves the boundary, though — +page.js load() also runs on the server for the first request, then re-runs client-side on navigation, and its return value has to survive serialization to be reused safely on the client. If SEO-critical data ever depends on a value that isn’t safely serializable, verify both the direct-request HTML and a client-navigated view of the same route, not just one or the other.

Routing and URL structure

• File-based routing with [param] for dynamic segments gives you clean, predictable URLs.
• History API routing is the default — SvelteKit doesn’t use hash/fragment routing, and that’s exactly what you want. Google can’t reliably resolve hash-based (#/page) URLs, so History API routing is the SEO-safe choice and SvelteKit makes it the default.
• trailingSlash in svelte.config.js accepts 'always', 'never', or 'ignore'. SvelteKit handles the canonical redirectA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. for you, but leaving it misconfigured (especially 'ignore') can create duplicate-content variants. Pick one and be consistent.
• Dynamic routes you want prerendered need an entries function to enumerate the paths at build time, or SvelteKit won’t know which URLs to generate.

Choosing an adapter for SEO

The adapter decides how and where your SvelteKit app is deployed, and that has SEO consequences (mostly via TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good., which feeds LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good.):

For a blog or docs site, adapter-static with prerendering gives you maximum speed and crawlabilityCrawlability is how well search engine crawlers can discover, access, and fetch a site's pages. A crawlability issue is any technical condition — blocked access, broken links, server failures, or bloated URL inventory — that stops pages from reaching the index.. For dynamic sites, adapter-cloudflare or adapter-vercel put SSR at the edge, which can shrink TTFB and help Largest Contentful Paint — but the adapter only picks the deployment shape. Actual TTFB depends on your data fetching, caching, and the runtime’s cold-start behavior, so measure the deployed page rather than assuming the adapter alone delivers the win.

An adapter is a boundary, not just a deploy target: streaming, the filesystem, caching, edge/runtime APIs, redirects, and error handling can all behave differently between adapters. A route that looks correct with the local dev server or adapter-node isn’t guaranteed to behave identically once deployed through adapter-cloudflare or adapter-vercel — test the production build on the actual target, not just npm run preview.

Sitemaps and robots.txt

SvelteKit has no built-in sitemapA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing. or robots.txtA plain-text file at the root of a host that tells crawlers which URLs they may and may not request. It controls crawling, not indexing — a blocked URL can still be indexed if it's linked from elsewhere. — like a headless setup, you build them explicitly.

• Sitemap, manual: create src/routes/sitemap.xml/+server.js that returns the XML. Add export const prerender = true if you’re on adapter-static.
• Sitemap, dynamic: a server-rendered endpoint that queries your CMSA content management system (CMS) is software that lets users create, manage, and publish digital content — like blog posts and pages — without writing raw code. WordPress, Drupal, and Joomla are the most common open-source CMS platforms./database and returns fresh XML on each request — best for large or fast-changing sites.
• Sitemap, packages: svelte-sitemap scans routes post-build (for SSG), and sveltekit-static-sitemap generates from prerendered routes.
• robots.txt: drop a static file in static/ (served at /robots.txt automatically) or generate it from a src/routes/robots.txt/+server.js endpoint. Whichever you choose, don’t block your .js/.css — Google won’t render from blocked files.

Performance and Core Web Vitals

SvelteKit’s compiler and framework mechanics give you a structural head start on performance, and Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. are a ranking input — but the mechanics themselves don’t guarantee a score. The compiler outputs vanilla JS with no virtual DOM and no runtime library, so a typical SvelteKit page ships less JavaScript than an equivalent React-based app; automatic per-route code splitting, built-in asset and link preloading, file-hashing for long-lived caching, and edge deployment via several adapters are all available. What you build with those mechanics — page weight, image handling, third-party scripts, hydration cost, and the deployment target you actually choose — still decides your measured CWV and your rankings. Treat the framework as removing obstacles, not as delivering the result. The SvelteKit docs point you at the right measurement tools: “Google’s PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. and WebPageTestWebPageTest is a free, open-source, lab-based website performance testing tool — created by Patrick Meenan in 2008 and acquired by Catchpoint in 2020 — that runs pages on real browsers from distributed locations and produces deep diagnostics (waterfalls, filmstrips, connection views, Core Web Vitals). It's a diagnostic tool, not a Google ranking input. are excellent ways to understand the performance characteristics of a site.” Image optimization is available via @sveltejs/enhanced-img.

AI crawlers and the SSR imperative

Here’s the 2026 wrinkle the older SvelteKit SEO guides miss. Rendering behavior for GPTBot (OpenAI), ClaudeBot (Anthropic), PerplexityBot, and the BingbotBingbot is Microsoft Bing's primary web crawler — the bot that discovers, fetches, and renders pages to build the Bing index. That index also powers Yahoo, DuckDuckGo, Ecosia, and Microsoft Copilot, so Bingbot's reach is far wider than Bing's own search-market share. fetch behind Copilot is provider- and version-specific, and current provider documentation doesn’t establish one shared render step you can rely on. Treat “generally fetches static HTML without executing JavaScript” as the safe planning assumption, not a guarantee about every provider forever. A CSR route (bare Svelte, or SvelteKit with ssr: false) ships every one of these crawlers the same empty shell a first-fetch GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. request sees; SvelteKit’s default SSR puts your content in the raw HTML so no crawler has to depend on a render step at all. That’s the argument for keeping SSR on for anything you want AI systems to see — not a promise that SSR guarantees inclusion in an AI answer, which depends on factors well beyond rendering.

Common SvelteKit SEO mistakes

• Fetching SEO data in onMount() instead of a server load function — metadata isn’t in the initial HTML.
• Shipping SPA fallback mode (ssr: false) for content you want ranked.
• adapter-static with ssr: false — empty shells, not prerendered pages.
• Blocking JS/CSS in robots.txt — breaks rendering.
• Skipping trailingSlash configuration — duplicate-content variants.
• Using hash/fragment routing — Googlebot can’t resolve those URLs (SvelteKit’s History API default already protects you here).

If you’re coming at this from the broader framework angle, Svelte/SvelteKit is one of the decoupled frontends a headless CMSA content management system that separates the content repository from the presentation layer, delivering content via API to any front-end framework rather than rendering HTML server-side itself. It doesn't specify the rendering mode, hosting, cache, preview security, or publishing workflow — those are separate decisions. pairs with, and the rendering-mode logic here is the same logic that governs JavaScript SEOMaking sure search engines can crawl, render, and index content that depends on JavaScript. generally — those topics live alongside this one in the cluster.

AI summary

A condensed take on the Advanced version:

• Svelte ≠ SvelteKit. Bare Svelte compiles to lean vanilla JS but is CSR-only — content isn’t in the raw HTML. SvelteKit renders SSR by default and ships full HTML. Use SvelteKit for anything that must rank.
• Why renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. mode matters: Google queues all 200 pages for renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. (delay); Bing is less reliable at JS; AI-crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. rendering (GPTBot, ClaudeBot, PerplexityBot) is provider-specific and generally treated as fetch-only. SSR/prerenderThe Speculation Rules API is a Chromium browser API (Chrome/Edge 109+) that lets a site tell the browser which same-site pages to prefetch (download the HTML document) or prerender (fully load and render in an invisible tab) before a visitor clicks — so the next navigation can be near-instant. It's a browser-side performance feature for real users, not a crawling, indexing, or ranking signal. puts content in the first response so no crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. depends on a render step.
• Four modes: SSR (default), prerender/SSG (prerender = true, build-time HTML), SPA fallback (ssr: false, docs warn “large negative performance and SEO impacts”), and hybrid (mix per route — SvelteKit’s killer feature).
• The trap: adapter-static + ssr: false produces empty shells, not prerendered HTML. Prerendering is SSR at build time — keep SSR on.
• Metadata: manage <title>/meta with <svelte:head> (no library needed). Feed it from a +page.server.js load function, not onMount() (client-only).
• Routing: History API by default (good — hash routing is bad for SEO); configure trailingSlash; prerendered dynamic routes need an entries function.
• Adapters: adapter-static (SSG, content sites) vs. adapter-node/vercel/ cloudflare (SSR; edge adapters can cut TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good., which helps LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. — but measure the deployed route, since adapters differ in streaming, cachingCaching stores a copy of a page or resource — in a browser, a CDN edge node, or a search crawler's own cache — so it can be served again without regenerating or re-downloading it. It isn't a direct ranking factor, but it feeds page speed and crawl efficiency., and runtime behavior).
• No built-in sitemapA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing./robots.txtA plain-text file at the root of a host that tells crawlers which URLs they may and may not request. It controls crawling, not indexing — a blocked URL can still be indexed if it's linked from elsewhere. — build them (manual +server.js route, dynamic endpoint, or a package). Never block .js/.css.
• CWV head start: compiler output ships less JS than React; code splitting, preloading, caching, edge deployment are all available — but page weight, images, third-party scripts, and your deployment choice still decide the measured score.

Official documentation

Primary-source documentation from SvelteKit and the search engines.

SvelteKit

• SEO • SvelteKit Docs — SSR-by-default, <svelte:head> for metadata, trailing-slash normalization, performance, and the sitemapA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing. endpoint pattern.
• Page options (prerender, ssr, csr) • SvelteKit Docs — how to set renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. mode per route, and the SPA-mode warning.
• Static site generation (adapter-static) • SvelteKit Docs — prerendering to static files and the ssr requirement.
• Loading data • SvelteKit Docs — server vs. universal load functions (where your SEO data should be fetched).
• Performance • SvelteKit Docs — code splitting, preloading, cachingCaching stores a copy of a page or resource — in a browser, a CDN edge node, or a search crawler's own cache — so it can be served again without regenerating or re-downloading it. It isn't a direct ranking factor, but it feeds page speed and crawl efficiency., and measurement tools.

Google

• Understand JavaScript SEO Basics — the three-phase process, the render queue, History API routing, and the “not all botsA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. can run JavaScript” guidance.
• The new evergreen Googlebot — GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer.’s move to evergreen Chromium and what it still doesn’t support.
• SEO Guide for Web Developers — SSR/prerendering recommendation for indexable content.

Quotes from the source

On-the-record statements from the SvelteKit docs and Google. Each link is a deep link that jumps to the quoted passage on the source page.

SvelteKit docs — renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. & SEO

• “This option has large negative performance and SEO impacts” — on running an app as a client-side-rendered SPA (ssr: false fallback). Jump to quote
• “Google’s PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. and WebPageTestWebPageTest is a free, open-source, lab-based website performance testing tool — created by Patrick Meenan in 2008 and acquired by Catchpoint in 2020 — that runs pages on real browsers from distributed locations and produces deep diagnostics (waterfalls, filmstrips, connection views, Core Web Vitals). It's a diagnostic tool, not a Google ranking input. are excellent ways to understand the performance characteristics of a site.” Jump to quote

Google — JavaScript & renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM.

• “All pages with a 200 HTTP status codeAn HTTP status code is the three-digit number a server returns with every response to tell a browser or crawler what happened to its request — success, redirect, client error, or server error. For SEO the code matters as much as the content: it tells Google and Bing whether to index a page, follow a redirect, retry later, or drop the URL from the index. are sent to the rendering queue, no matter whether JavaScript is present on the page.” Jump to quote
• “Server-side or pre-rendering is still a great idea because it makes your website faster for users and crawlersA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index., and not all bots can run JavaScript.” Jump to quote
• “Google Search won’t render JavaScriptMaking sure search engines can crawl, render, and index content that depends on JavaScript. from blocked files or on blocked pages.” Jump to quote

Patrick Stox (my own work — JavaScript SEO: A Definitive Guide)

• “JavaScript is not bad for SEO, and it’s not evil. It’s just different from what many SEOs are used to, and there’s a bit of a learning curve.”
• On rendering modes: “Any kind of SSR, static rendering, and prerendering setup is going to be fine for search engines.”
• On CSR: “The most problematic one is going to be full client-side rendering where all of the rendering happens in the browser. While Google will probably be OK client-side rendering, it’s best to choose a different rendering option to support other search engines.”

SvelteKit SEO checklist

A quick pass to confirm search engines and AI crawlersAI crawlers are bots from AI companies that fetch web pages to train language models, build AI-search indexes, or answer live user questions. They come in three categories, each with its own user-agent tokens and its own robots.txt controls. can see your SvelteKit content:

• You’re using SvelteKit, not bare Svelte, for anything that needs to rank.
• SSR is on (the default) for indexable routes — no accidental ssr: false.
• Content-heavy pages use prerenderThe Speculation Rules API is a Chromium browser API (Chrome/Edge 109+) that lets a site tell the browser which same-site pages to prefetch (download the HTML document) or prerender (fully load and render in an invisible tab) before a visitor clicks — so the next navigation can be near-instant. It's a browser-side performance feature for real users, not a crawling, indexing, or ranking signal. (export const prerender = true) where they can.
• With adapter-static, ssr is left on so prerenderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. outputs real HTML (not empty shells).
• Every page has a unique <title> and <meta name="description"> via <svelte:head>.
• SEO metadata is fetched in a +page.server.js load function, not in onMount().
• Canonical, Open GraphOpen Graph (OG) tags are `<meta>` elements in a page's head, defined by the Open Graph protocol (ogp.me, created by Facebook), that describe a page as a shareable object — its title, description, image, URL, and type. They control how a link preview card looks when the page is shared on Facebook, LinkedIn, Slack, Discord, WhatsApp, and iMessage. They are not a direct Google ranking factor, though Google reads og:title, og:image, and og:site_name as inputs to how a result appears., and JSON-LDJSON-LD (JavaScript Object Notation for Linked Data) is a script-based structured data format, typically paired with the schema.org vocabulary to describe page content for search engines and AI systems. Google recommends it over Microdata and RDFa because it's the easiest format to implement and maintain at scale — but all three work, and structured data isn't a ranking signal. are rendered server-side, not injected client-side.
• trailingSlash is set explicitly in svelte.config.js.
• Prerendered dynamic routes have an entries function enumerating paths.
• A sitemapA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing. exists (+server.js route or package) and a robots.txtA plain-text file at the root of a host that tells crawlers which URLs they may and may not request. It controls crawling, not indexing — a blocked URL can still be indexed if it's linked from elsewhere. is in static/ or a route.
• robots.txt does not block .js or .css.
• Routing is History API (SvelteKit default) — no hash/fragment routes.
• You verified the rendered HTML in GSCA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. URL Inspection (content + metadata present on first fetch).

The mental models

1. The Svelte-vs-SvelteKit fork. Before anything else, answer: bare Svelte or SvelteKit? Bare Svelte is CSR-only — content isn’t in the HTML. SvelteKit is SSR-first. Nearly every “Svelte SEOSvelte SEO is the practice of making sure search engines and AI crawlers can see content built with Svelte. Plain Svelte is client-side rendered (a blank shell), so the key is to use SvelteKit, which renders pages on the server by default. problem” traces back to someone using plain Svelte (or disabling SvelteKit’s SSR) for content that needs to rank.

2. PrerenderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. = SSR at build time. “Static” doesn’t mean “no renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM..” Prerendering runs your server render at build time and saves the HTML. That’s why ssr: false can’t prerenderThe Speculation Rules API is a Chromium browser API (Chrome/Edge 109+) that lets a site tell the browser which same-site pages to prefetch (download the HTML document) or prerender (fully load and render in an invisible tab) before a visitor clicks — so the next navigation can be near-instant. It's a browser-side performance feature for real users, not a crawling, indexing, or ranking signal. — there’s nothing to render. Keep SSR on; choose when it runs (request time = SSR, build time = prerender).

3. The rendering-mode-per-route decision. SvelteKit lets you choose per route, so match mode to content:

• Static-ish content (blog, docs, marketing) → prerender (SSG).
• Fresh/dynamic content (listings, personalized pages) → SSR.
• Behind-a-login, not-indexedStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. UI → SPA fallback is acceptable there only.

4. HTML-first metadata. Anything a crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. needs — title, description, canonical, JSON-LDJSON-LD (JavaScript Object Notation for Linked Data) is a script-based structured data format, typically paired with the schema.org vocabulary to describe page content for search engines and AI systems. Google recommends it over Microdata and RDFa because it's the easiest format to implement and maintain at scale — but all three work, and structured data isn't a ranking signal. — belongs in the server-rendered HTML via <svelte:head> fed by a server load function. onMount() metadata is seen late by Google, and providers that treat AI crawlersAI crawlers are bots from AI companies that fetch web pages to train language models, build AI-search indexes, or answer live user questions. They come in three categories, each with its own user-agent tokens and its own robots.txt controls. as fetch-only won’t see it at all.

5. The adapter = the deployment shape. The adapter decides where SSR runs (or whether it’s all static). Static for content sites; node/vercel/cloudflare for SSR. Edge adapters can shrink TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good., which can help LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. — but the adapter is one input; your data fetching, caching, and the runtime’s cold-start behavior decide what you actually measure. Adapters also differ in streaming, filesystem access, and error handling, so verify production behavior per adapter rather than assuming feature parity.

6. Plan for crawlersA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. that don’t run your JavaScript. Rendering behavior for AI crawlersAI crawlers are bots from AI companies that fetch web pages to train language models, build AI-search indexes, or answer live user questions. They come in three categories, each with its own user-agent tokens and its own robots.txt controls. is provider- and version-specific, and current provider documentation doesn’t guarantee a shared render step. The safe planning assumption is fetch-only: if content isn’t in the initial HTML, treat it as invisible to that class of crawler. SSR/prerender removes the dependency on any crawler’s rendering capability at all — the strongest lever you have, not a guarantee about what any one AI system does with the result.

SvelteKit SEO — cheat sheet

RenderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. modes (set per route via page options)

The trap

• adapter-static + ssr: false → empty shells, not prerendered HTML. Keep ssr on with adapter-static.

Adapters

Fast rules

• Metadata → <svelte:head> (no library needed); feed from +page.server.js load, never onMount(). Confirm each route’s title/description is unique.
• Routing → History API (default). Never hash/fragment routes.
• Set trailingSlash explicitly.
• Prerendered dynamic routes → add an entries function.
• No built-in sitemapA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing./robots.txtA plain-text file at the root of a host that tells crawlers which URLs they may and may not request. It controls crawling, not indexing — a blocked URL can still be indexed if it's linked from elsewhere. — build them (+server.js route or package).
• Never block .js/.css in robots.txtA plain-text file at the root of a host that tells crawlers which URLs they may and may not request. It controls crawling, not indexing — a blocked URL can still be indexed if it's linked from elsewhere..
• AI crawlersAI crawlers are bots from AI companies that fetch web pages to train language models, build AI-search indexes, or answer live user questions. They come in three categories, each with its own user-agent tokens and its own robots.txt controls. → generally fetch-only, provider-specific → keep SSR on so content doesn’t depend on a render step.
• Options (ssr/csr/prerender/trailingSlash) are hierarchical — check the value that applies to the specific route, not just the project default.

Plain Svelte or SvelteKit?

Svelte SEO mistakes

• Using plain client-only Svelte for search landing pages. Move rankable routes to SvelteKit SSR or prerenderingTurning HTML, CSS, and JavaScript into the final visual page and DOM..
• Setting ssr = false globally. That turns the site into an SPA and removes complete initial HTML. Scope client-only behavior to routes that do not need search visibility.
• Updating <svelte:head> only after browser fetches. Load metadata with the same server/build data that renders the page.
• Using hash-based URLs for content routes. Hash fragments are not separate server routes. Use normal pathname routing.
• Testing only after hydrationActivating server-rendered HTML in the browser by attaching JavaScript handlers.. Compare raw HTML with rendered DOM so client code cannot hide missing source content.

Raw HTML is an empty app shell

Likely cause: plain Svelte SPA output or ssr = false. Fix: use SvelteKit SSR/prerenderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. for the route and move essential loading to server-compatible load. Confirm: curl returns the heading, content, and internal linksAn internal link is a hyperlink from one page on a website to another page on the same website. Internal links help search engines discover your pages and pass ranking signals (PageRank and anchor-text context) between them..

Titles and canonicals appear only after JavaScript

Likely cause: head values depend on client lifecycle or browser-only fetching. Fix: return the data during SSR/prerenderThe Speculation Rules API is a Chromium browser API (Chrome/Edge 109+) that lets a site tell the browser which same-site pages to prefetch (download the HTML document) or prerender (fully load and render in an invisible tab) before a visitor clicks — so the next navigation can be near-instant. It's a browser-side performance feature for real users, not a crawling, indexing, or ranking signal. and render it through <svelte:head>. Confirm: raw and rendered head values agree.

A dynamic route is missing from a static build

Likely cause: the prerenderer cannot discover the parameterized path. Fix: expose crawlable links or configure entries, or render that route on demand. Confirm: the deployed route returns a complete 200 page.

The page works locally but fails after deployment

Likely cause: adapter mismatch, missing server support, or environment-dependent data fetching. Fix: test the production adapter output and its runtime variables. Confirm: production source HTML matches the tested build.

Confirm SvelteKit is actually serving rendered HTML

The whole point of SvelteKit’s SSR is that content is in the raw HTML — before any JavaScript runs. The fastest way to confirm you didn’t accidentally ship a CSR shell is to fetch the raw response and look for your content. A plain curl doesn’t run JavaScript, so it sees exactly what a non-renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. sees.

macOS / Linux

# Raw HTML as the server sends it (no JS executed)
curl -sL "https://example.com/your-page/" -o raw.html

# Is your real content in the raw HTML? (empty result = you're shipping a CSR shell)
grep -o "Your unique headline text" raw.html

# Is your title/description in the initial response?
grep -iE "<title>|name=\"description\"" raw.html

Windows (PowerShell)

Invoke-WebRequest -Uri "https://example.com/your-page/" -OutFile raw.html
Select-String -Path raw.html -Pattern "Your unique headline text"
Select-String -Path raw.html -Pattern "<title>","name=`"description`""

If your headline and metadata are present in raw.html, SSR/prerendering is working. If they’re missing but visible in the browser, your content depends on client-side renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. — check that ssr isn’t set to false and that you’re not fetching content only in onMount().

Check you’re not blocking JS/CSS

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

A Disallow matching /_app/ (SvelteKit’s bundled output) or your CSS means Google can’t render the page — almost always a mistake.

Tools for debugging SvelteKit SEO

• URL InspectionA Google Search Console feature that reports how Google sees one specific URL on a property you own. By default it shows the last-indexed snapshot; a separate \"Test live URL\" mode fetches the current version. (Google Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results.) — the source of truth. Run a live test, then check the rendered HTML, screenshot, and page resources to confirm your content and metadata are present (and that nothing is blocked).
• PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. — the SvelteKit docs explicitly recommend it; checks Core Web Vitals (LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good./INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good./CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good.) that SvelteKit’s lean output is built to win.
• WebPageTestWebPageTest is a free, open-source, lab-based website performance testing tool — created by Patrick Meenan in 2008 and acquired by Catchpoint in 2020 — that runs pages on real browsers from distributed locations and produces deep diagnostics (waterfalls, filmstrips, connection views, Core Web Vitals). It's a diagnostic tool, not a Google ranking input. — the other tool the SvelteKit docs name; waterfall + filmstrip view for diagnosing TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good. and render timing.
• Rich ResultsRich results (formerly 'rich snippets') are enhanced search listings — stars, images, prices, breadcrumbs, video thumbnails, and more — that Google and Bing build from structured data. They're a display feature, not a ranking factor, and eligibility never guarantees they'll show. Test — fast way to confirm JSON-LDJSON-LD (JavaScript Object Notation for Linked Data) is a script-based structured data format, typically paired with the schema.org vocabulary to describe page content for search engines and AI systems. Google recommends it over Microdata and RDFa because it's the easiest format to implement and maintain at scale — but all three work, and structured data isn't a ranking signal. made it into the rendered output.
• Screaming Frog SEO Spider — crawl with JS renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. on/off to diff raw vs. rendered HTML across the whole SvelteKit site.
• Ahrefs Site Audit — surfaces broken canonicals, missing metadata, redirectA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. chains, and indexability issues at scale.
• View source / curl — the quickest “is my content in the raw HTML?” check (see the Scripts tab).

Test yourself: Svelte SEO

Five quick questions on how Svelte and SvelteKit affect search visibility. Pick an answer for each, then check.

Resources worth your time

My related writing

• JavaScript SEO: A Definitive Guide — my full reference on renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM., DOM parityWhether the rendered DOM matches what you expect the raw HTML to become., and the renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM.-mode trade-offs that underpin everything here. It mentions Svelte alongside React, Vue, and Angular as frameworks with head/meta modules for SEO.
• The Beginner’s Guide to Technical SEO — where rendering and crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. fit in the bigger picture.

My speaking

• How Search Works (SlideShare) — my walkthrough of crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor., rendering, indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed., and ranking. (My standing disclaimer applies: “This is my understanding of systems… not going to be 100% complete or accurate.”)

From around the industry

• SEO • SvelteKit Docs — the official, authoritative starting point: SSR by default, <svelte:head>, trailing slashesA trailing slash is the forward slash (/) at the end of a URL — example.com/page/ versus example.com/page. Except at the bare root domain, the two versions are different URLs to search engines, so you pick one format and enforce it., and the sitemapA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing. pattern.
• Page options (prerender, ssr, csr) • SvelteKit Docs — the per-route rendering controls and the SPA-mode SEO warning, in the team’s own words.
• Understand JavaScript SEO Basics (Google Search Central) — the render queue, “not all botsA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. can run JavaScript,” and the History API guidance.
• SvelteKit SEO: Your Secret Weapon (Okupter) — a practitioner guide covering meta tagsMeta tags are HTML elements in a page's head that pass metadata about the page to search engines and browsers. For SEO only a few matter — the title element, the meta description, and the robots meta tag — while meta keywords and most others are ignored., prerendering, rendering modes, structured dataStructured data is a standardized way of labeling page content (using the schema.org vocabulary in JSON-LD, Microdata, or RDFa) so search engines can understand its meaning. It's not a direct ranking factor — its value is rich results and entity understanding., and sitemapsA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing..
• SvelteKit SEO: Search Engine Optimization Metadata (Rodney Lab) — the essential meta tagsMeta tags are HTML elements in a page's head that pass metadata about the page to search engines and browsers. For SEO only a few matter — the title element, the meta description, and the robots meta tag — while meta keywords and most others are ignored., an SEO component pattern, social cards, and language declaration.
• How to add a basic SEO component to SvelteKit (Thilo Maier) — a code-focused walkthrough of a reusable SEO component.
• Creating a Sitemap in SvelteKit (Bryan Anthonio) — a clear, current guide to the +server.js sitemap-endpoint approach.
• Rich Harris explains why SvelteKit pushes for SSR (DEV Community) — context on why SvelteKit’s creator made SSR the default and pushes against SPA/CSR.

Svelte SEO

Svelte SEO is the practice of making sure search engines and AI crawlers can see content built with Svelte. Plain Svelte is client-side rendered (a blank shell), so the key is to use SvelteKit, which renders pages on the server by default.

Related: JavaScript SEO, Headless CMS SEO

Svelte SEO

Svelte SEO is the practice of making content built with the Svelte UI compiler crawlable, renderable, and indexable. The single most important distinction is between Svelte and SvelteKit. Svelte by itself compiles components to lean vanilla JavaScript with no virtual DOM and no runtime library — but a bare Svelte app is still client-side rendered (CSR): the server returns a near-empty HTML shell and the browser builds the page. That content is not in the raw HTML, which is a problem for crawlersA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. that don’t render JavaScriptMaking sure search engines can crawl, render, and index content that depends on JavaScript..

SvelteKit is Svelte’s official meta-framework (the analogue of Next.js for React or Nuxt for Vue). It renders pages on the server by default (SSR), supports static prerenderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. (SSG) per route, and lets you mix renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. modes route by route. Because SvelteKit ships fully populated HTML before any JavaScript runs, content is available to GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer., BingbotBingbot is Microsoft Bing's primary web crawler — the bot that discovers, fetches, and renders pages to build the Bing index. That index also powers Yahoo, DuckDuckGo, Ecosia, and Microsoft Copilot, so Bingbot's reach is far wider than Bing's own search-market share., and AI crawlersAI crawlers are bots from AI companies that fetch web pages to train language models, build AI-search indexes, or answer live user questions. They come in three categories, each with its own user-agent tokens and its own robots.txt controls. on the first fetch.

The practical core of Svelte SEO: use SvelteKit (not bare Svelte) for anything that needs to rank; manage <title> and meta tagsMeta tags are HTML elements in a page's head that pass metadata about the page to search engines and browsers. For SEO only a few matter — the title element, the meta description, and the robots meta tag — while meta keywords and most others are ignored. with the <svelte:head> element; fetch SEO data in +page.server.js load functions so it lands in the initial HTML; pick an adapter that fits your rendering needs; and avoid the SPA fallback trap (ssr: false), which the SvelteKit docs warn has “large negative performance and SEO impacts.”

Related: JavaScript SEO, Headless CMS SEO

Changelog