# Sveltepress > SvelteKit docs & blog SSG — Svelte 5 in Markdown, versioning, i18n, and Pagefind. # [SvelteKit docs & blog SSG](https://sveltepress.site/) --- ## guide # [Configuration](https://sveltepress.site/guide/blog-theme/configuration) All options are passed to `blogTheme()` in `vite.config.ts`. ## `BlogThemeOptions` | Option | Type | Default | Description | |---|---|---|---| | `title` | `string` | — | Site title. Used in `
this would also be focus
// [svp! fc]
{JSON.stringify(fm, null, 2)}
```
## Site frontmatter
The global shared frontmatter for every +page.md file
```ts
interface SiteConfig {
title?: string
description?: string
}
```
---
# [Svelte in markdown](https://sveltepress.site/guide/markdown/svelte-in-markdown)
This feature allows you to write
`
```
## Create a release snapshot
:::since[Advance before editing the next version]{version="2026-08-31" id="next-version-doc-workflow" summary="Freeze outgoing docs before editing and marking the new current version."}
Start from clean, complete outgoing documentation. Build and create the next version before editing its pages or adding its `:::since` markers. `create` freezes the outgoing current version and makes the supplied ID current; only then should new documentation use that ID.
```sh
pnpm exec sveltepress versions build
pnpm exec sveltepress versions create 8.2 --label "8.2"
# 8.2 is now current: edit docs and add version="8.2" markers
pnpm exec sveltepress versions build
pnpm exec sveltepress versions validate
```
Never run `versions create` over documentation that already contains the next version's edits. Those edits would be frozen into the outgoing version. If work started early, restore the known clean outgoing state, build and advance it, then reapply the edits to the new current version.
:::
:::since[CLI --locale for per-locale manifests]{version="2026-09-03" id="versions-cli-locale" summary="Pass --locale to target sveltepress.versions.