Canonical Domain

When your site is reachable at both www.example.com and example.com, search engines see two copies of every page. Chinaski solves this by making your Site URL setting canonical and generating a redirect rule for the other host automatically at each build. This page explains what to set, what gets generated, and what else lives in the redirects file the builder manages.

Choosing the canonical host

Set Site URL in Settings → General to your preferred domain in full, including the scheme, e.g. https://example.com or https://www.example.com. The host in that setting is the canonical one.

At every build, the builder writes a generated block into _redirects at the top of your output directory:

If your Site URL host starts with www., the bare domain (and everything under it) is 301-redirected to the www. host.
If it doesn’t start with www., the www. host redirects to the bare host.

The redirect is permanent (301) and sends the full path along; only the authority changes. No other domains are touched. If you leave Site URL empty, no canonical-domain redirect is generated.

Two things to know:

The generated block is idempotent: each build drops any previous canonical block and rewrites it fresh, so incrementing builds never duplicate lines.
The rule uses the redirect syntax of Caddy’s redir directive with the force-external ! marker (https://www.example.com/* https://example.com/:splat 301!). Chinaski’s own deploy examples serve statically through Caddy, which understands this format. If you publish the output directory somewhere that expects a different redirect syntax, review that file before pointing a third-party hosting product at it.

If you switch the Site URL from bare to www (or the reverse), the next rebuild regenerates the block to match; no manual edits needed.

Other redirects the builder manages in the same file

The _redirects file is shared between the canonical-domain rule and the redirects you define in the admin area:

Slug redirects: when a page or post slug is retired or deliberately redirected, the old URL maps to the new one with the HTTP code you choose (301, 302, or 307; 301 if unspecified). Redirects only fire for URLs that no longer resolve to live content: if the old slug is still attached to a published page or post, the rule is skipped so a live URL isn’t hijacked.
Prefix-change redirects: changing the post URL prefix automatically redirects the old paths to the new ones on the next rebuild.
Redirect rules without a pattern (plain old-slug/new-slug pairs) are simple path rewrites that work across hosting types. Pattern redirects (ones using * and capture placeholders) are deliberately skipped when the builder generates these files, because they require syntax the simple file format doesn’t express; pattern rules need to be implemented in your reverse proxy config directly.
A companion _redirects.caddy file is also generated in Caddy’s native redir syntax; its header comment tells you to include it in your Caddyfile site block if you deploy with Caddy.

Consistency with canonical tags

The same Site URL drives the canonical URL on every page (<link rel="canonical"> and og:url), so the domain your redirect sends visitors to and the canonical name your pages declare always agree. If you serve a multilingual site, generated canonical URLs use each language’s configured base.

If the Site URL is left blank, no canonical redirect block is written and canonical tags fall back accordingly; pick your domain before going live.