SvelteKit SEO: metadata, canonicals and indexing checks
Resources
Examples checked: Svelte 5.55.0 / SvelteKit 2.55.0 · September 14, 2026
SvelteKit gives you server rendering, route-level metadata and HTTP response control. Those tools make technical SEO easier to implement. They do not guarantee rankings, traffic or sales. Start by checking what your public URLs actually return to a crawler.
This checklist is for public pages you want people to discover in search. Private application screens need authentication; a robots rule is not an access-control mechanism. The metadata example was type-checked, built and checked in the initial HTTP response with Svelte 5.55.0 and SvelteKit 2.55.0.
1. Return useful HTML on the first request
SvelteKit renders pages on the server by default. Keep the main heading, article or service copy, and important links in that initial response. Loading the entire article in onMount leaves the first HTML response without the content people came for. Google can render JavaScript, but rendering introduces another step and not every crawler executes it.
Prerender stable public content when it can be built ahead of time; use server rendering when the response needs fresh request-time data. Inspect inherited page options before changing them. Setting ssr=false in a root layout affects routes below it unless a child layout or page overrides that option. Neither rendering mode fixes poor content, broken navigation or an unavailable server.
SvelteKit rendering and prerender options
2. Give each page a clear title and description
Create src/routes/seo/+page.svelte to try the example:
<script lang="ts">
// Replace these demo values with validated CMS fields for this page.
const title = 'SvelteKit dashboard development | Example Studio';
const description = 'Development help for SvelteKit dashboards, including filters, permissions and reporting.';
const canonical = 'https://example.com/services/dashboards';
</script>
<svelte:head>
<title>{title}</title>
<meta name="description" content={description} />
<link rel="canonical" href={canonical} />
<meta property="og:title" content={title} />
<meta property="og:description" content={description} />
<meta property="og:url" content={canonical} />
<meta property="og:type" content="website" />
</svelte:head>
<h1>SvelteKit dashboard development</h1>
<p>Build reporting screens your customers can use.</p>
<a href="/contact">Discuss a dashboard</a>This is a complete demo page, with example.com placeholders. Replace those values with your own production URL and actual page copy. For a CMS route, return the fields through load and derive them from data so client navigation updates them. Keep one owner for each metadata field rather than rendering conflicting canonical or description tags from multiple components.
Write titles that identify the page: a specific problem, service or resource. The description should help someone decide whether to visit. Google may choose a different title link or snippet; there is no character count that guarantees the exact text will appear.
Open Graph tags help describe a shared link on platforms that use them. They are separate from the HTML title and search snippet. Add a suitable og:image using an absolute public image URL if you want a preview image; this small example deliberately does not invent one.
3. Set canonicals deliberately
Use an absolute canonical URL on indexable pages, and keep it consistent with internal links, redirects and sitemap entries. A canonical is a signal about duplicate or very similar content, not a command that forces Google to select your preferred URL.
Do not generate the canonical blindly from an arbitrary request host. Use your configured production origin and the intended path. A tracking parameter such as utm_source usually should not create a new canonical page. A parameter that changes the content requires a deliberate indexing policy.
Pagination is a common trap: page 2 contains different items, so do not point every page in a sequence at page 1. Give each indexable paginated page its own canonical URL and link to other pages with real href attributes. Decide separately whether filter combinations deserve indexing.
See A working URL-state example for filters and pagination. A private dashboard and a public product directory need different indexing decisions even if their UI looks similar.
4. Check status codes, robots and redirects
A missing article should return 404, not a successful page containing "not found". A permanent URL move should redirect to its replacement, and internal links should point directly at that replacement. Test the deployed response: local routing success does not verify CDN or hosting rules.
Use noindex for a crawlable page that should not appear in search. Google must be allowed to fetch the page to see that rule. Blocking it in robots.txt can prevent that fetch, and a blocked URL can still appear in search without its content. Do not ship a site-wide staging noindex to production.
Google robots meta tag specification
Password-protect private or staging content that must not be publicly accessible. Robots directives are requests to crawlers, not a way to secure records. Check HTML meta robots and response-level X-Robots-Tag together, including headers added by your host.
5. Keep the sitemap aligned with public canonical pages
Include the absolute canonical URLs you want discovered. Exclude unpublished drafts, authenticated screens and redirecting or missing URLs. A sitemap is a discovery hint, not a promise of indexing. Use lastmod only when you can supply an accurate date of a significant page update; do not reset it to the current time on every request.
For a CMS site, check the publication filter and pagination of the query generating your sitemap. A query limited to the first batch of posts can silently omit the rest. Confirm that the live endpoint returns XML, escapes URLs correctly, and is reachable from your robots.txt or submitted in Search Console.
On HaulFacts, one of my own SvelteKit projects, the public directory and guides have canonical URLs and sitemap entries, while arbitrary lookup results stay out of the index. The HaulFacts case study explains how the directory, lookup, and content fit together.
6. Add structured data only where it matches the page
Structured data should describe visible, accurate page content using an appropriate supported type. Do not invent ratings, reviews, authors or publication dates. Passing a syntax validator does not guarantee that Google will show a rich result, and eligibility is separate from ranking.
Google structured data introduction
Use the Rich Results Test for Google-supported features and inspect any required fields for your chosen type. If a CMS supplies JSON-LD, serialize it safely before inserting it into HTML; untrusted raw JSON or text must not be able to close a script tag. This article does not include an untested schema generator.
7. Verify the deployed URLs
For each important page, inspect the initial HTML response and the rendered page. Confirm one intended title, description and canonical, the main heading and content, and crawlable links. Repeat after navigating from a sibling page so stale client-side metadata is caught. Test a valid page, a missing slug, a redirect, and a URL with a tracking parameter.
In Search Console, inspect the URL and compare the declared canonical with the Google-selected canonical when available. Investigate indexing exclusions using the actual response and page content. A successful live test is useful evidence that Google can access a page; it does not guarantee indexing.
Measure performance on representative mobile pages, including real images, fonts and third-party scripts. Use field data when available and lab tools to diagnose a specific bottleneck. A framework choice alone says little about your deployed page performance.
SvelteKit performance guidance
Fix the failure you can reproduce
If an article is missing from the sitemap, fix the query. If its HTML contains only a loading state, fix the data-loading path. If search impressions arrive for a question the article never answers, revise the article. Technical correctness and useful content are both necessary work; adding another metadata library cannot substitute for either.