Deployment checks

Keep your URLs correct across dev, preview, and production, so canonicals, sitemap entries, and links never leak localhost to the live site. The mechanics are mostly Eleventy and environment variables; this chapter is the small set of habits that keep them honest.

Three terms used below:

Canonical. The <link rel="canonical"> URL Baseline writes into every page's head.
pathPrefix. Eleventy's option for deploying under a subpath (e.g. /docs/). It reaches the links inside your pages and the sitemap. It does not reach the absolute URLs the head emits; see deploying under a subpath.
Preview build. A non-production deploy (a Netlify deploy preview, for instance) where the origin differs from production.

Prerequisites

Somewhere to deploy the site to.

Set settings.url (and, separately, pathPrefix)

Use the src/_data/settings.js you already have from the previous tutorials. The field that matters for this chapter is url, the canonical origin:

url: process.env.BASELINE_URL; // one value, supplied per environment

If you're deploying under a subpath, set pathPrefix in eleventy.config.js (e.g. /my-site/) – it lives on the Eleventy config, not in settings. Eleventy rewrites the links in your pages with it, and the sitemap picks it up too. The head's absolute URLs are the exception, and deploying under a subpath has that caveat in full.

Set environment URLs (local and CI)

Dev or local preview: create a local .env (don't commit it):

ELEVENTY_ENV="development"
BASELINE_URL="http://localhost:8080/"

Production: set BASELINE_URL to the live origin (e.g. https://www.example.com) in your hosting or CI environment.
Hosted previews (optional, e.g. Netlify): the host sets its own variables. URL points at production while DEPLOY_PRIME_URL points at the preview. Baseline reads neither. Pick whichever one you want the build to claim and assign it to settings.url yourself.

ELEVENTY_ENV is the development-versus-production switch. What it changes is on project structure, next to the Eleventy variable it is easy to confuse it with.

A .env file is optional. Plenty of projects never have one and set their variables in npm scripts or in the host, which works with no extra packages. If you do keep one, loading it is yours to do: install dotenv and import it at the top of the file that reads the value, normally _data/settings.js:

import 'dotenv/config';

Keep that import in the same file as the read. Put it somewhere else, in eleventy.config.js say, and whether it has run by the time settings.js is evaluated depends on the order the import lines happen to be in, which fails silently. Leaving it in on a host that has no .env costs nothing; dotenv finds no file and moves on.

The variable name is yours: Baseline only reads settings.url, so whatever your host calls it, put it there.

Pick a name nothing else has claimed. `URL` is defined by Netlify, and on a deploy preview it stays pointed at production, so a preview build would quietly claim the live domain. `BASE_URL` is reserved by Vite, which defaults it to `/`, so anything running through Vite or Vitest reads a relative value instead of yours. Both failures are silent, which is what makes them expensive. `BASELINE_URL` is the name these docs use because it is specific enough that nothing else wants it.

Everything absolute in the build comes from that single value, and leaving it unset makes Baseline warn at startup rather than guess an origin. Site settings lists what it anchors and what goes missing without it.

Run with the right URL per environment

Dev: confirm your .env is loaded (e.g. BASELINE_URL="http://localhost:8080/"), then:

npm start

Production: set BASELINE_URL in hosting or CI to the live origin (not an inline shell export), then:

npm run build

Spot-check the rendered pages: canonical and sitemap entries should use the origin you expect.

Preview builds (optional)

On Netlify, DEPLOY_URL and DEPLOY_PRIME_URL provide the preview origin. Feed one of them to your own variable on the build command, since netlify.toml does not expand variables inside an [environment] block:
```
[context.branch-deploy]
  command = "BASELINE_URL=$DEPLOY_PRIME_URL npm run build"
```
Other hosts differ; set an equivalent preview origin for whichever staging environment you have.
Confirm the rendered canonical and the sitemap root both match the preview domain.

Verify outputs

View source on a rendered page. The <link rel="canonical"> and every absolute link in the head should use the right origin. If BASELINE_URL is set in CI or production, none of them should say localhost.
Inspect dist/sitemap.xml (and the per-language sitemaps if multilingual is on). URLs should start with the expected origin, plus pathPrefix if you've set one.

PathPrefix checklist (if applicable)

For the full subpath setup, see Deploy Under a Subpath.

Next steps

Add a CI check that fails the build if BASELINE_URL is missing in production. One small step, lots of headaches saved.
Pair with the multilingual site tutorial to confirm hreflang URLs use the correct origin once multilingual is on.