---
title: "Introduction"
description: "Learn about the motivation behind Nuxt Site Config and a bit about how it works."
canonical_url: "https://nuxtseo.com/docs/site-config/getting-started/introduction"
last_updated: "2026-05-08T10:42:30.861Z"
---

## Background

Site config aims to be two things:

- A single source of truth for site config, for end users and module authors. Multiple modules commonly share this config, filling a gap the Nuxt core does not cover.
- A set of APIs for working with "writeable runtime config", for end-users and module authors.

## Features

- 😌 Minimal config with sensible defaults
- 🎨 Site config from any source: Nuxt Config, Environment Variables or Programmatically
- 🚀 Powerful and runtime agnostic APIs for module authors [`useSiteConfig`](/docs/site-config/api/use-site-config), [`createSitePathResolver`](/docs/site-config/api/create-site-path-resolver), `withSiteUrl`, [`getNitroOrigin`](/docs/site-config/api/get-nitro-origin), etc
- 🤝 Integrates with [`@nuxtjs/i18n`](/docs/site-config/guides/i18n)

## Site Config Examples

### `url`

A canonical site URL is important for [SEO](/docs/nuxt-seo/getting-started/introduction) and performance

### `env`

The environment the site is running in, importing so we can disable indexing for non-production environments.

See [this issue](https://github.com/nuxt/nuxt/issues/19819) on why we can't use `process.env.NODE_ENV`.

### `indexable`

Can the site be indexed by search engines? Used by [robots](/docs/robots/getting-started/introduction) and [sitemap](/docs/sitemap/getting-started/introduction) modules. Sometimes we have production sites that we don't want to be indexed.

### `name`

The name of the site is often used in meta tags and other SEO related tags

### `trailingSlash`

Trailing slashes are important for SEO and performance.

## What's the problem?

Not having a single source of truth for site config can be difficult to maintain and error-prone, for end-users and module authors.

Requiring a lot of duplication and boilerplate code to support the same features across modules.

Nuxt Site Config aims
to unify the experience of site config with a set of powerful and flexible APIs for end-users and module authors.

## Can't we use the Request URL or module config?

Nuxt itself provides a great SSR utility for getting the site URL from the request headers at runtime.

However, this has two major drawbacks:

- It's not available at build time or when prerendering
- When used for SEO content, it can cause duplicate content issues if the URL is not the canonical URL (e.g. `www.example.com` and `example.com`)

## Can't we use `site` on runtime config?

Yes. In fact, this module uses `site` on the runtime config under the hood.

It aims to keep all these in sync, resulting in a single source of truth for site config.

## How does it work?

See [How it works](/docs/site-config/guides/how-it-works) for more details.

## End goal

We should be able to spin up multi-tenant or multi-lingual Nuxt app with minimal effort, and Nuxt modules should work, without any additional configuration.

This is far off, but it sets a good direction for the module.