Redirects

When you rename a page or post, you don’t want old links to break. Chinaski keeps old URLs working with redirects, and this page explains how they’re created, how they behave, and the export formats for your host.

How redirects work

Your published site is static HTML, so Chinaski implements redirects in two ways:

At the old URL, the site ships a tiny page that tells the browser “this content has moved” and sends the reader straight to the new location, with a proper link when JavaScript is off. Search engines see a canonical link pointing at the new URL, so old pages don’t compete with new ones in results.
A redirect rules file: generated on every build, that your hosting proxy can read (see export formats below), so modern servers can answer with a proper redirect instead of the fallback page.

Redirects are per-language: each old slug belongs to a specific language, and points at the destination in that same language.

Live content always wins: if a published page or post already exists at the old slug, no redirect is generated for it: the content itself is served.

What happens automatically

You usually don’t manage redirects by hand:

Renaming a published page or post slug creates a redirect for the old URL automatically.
Changing the blog post URL prefix (for example moving /journal/ to /blog/) automatically redirects every published post from its old prefix path.
The site root redirects to your blog index or your chosen home page if no root page exists.
Domain canonicalisation: if your site URL is example.com, a rule is generated that sends www.example.com traffic (or vice versa), correct so search engines only index one spelling of your domain.

Manually creating a redirect

The admin area’s Redirects section lets you add one manually. What you supply:

The old slug and the new slug (where old links should land).
The language it applies to.
The type: page or post.
Optional notes, an active flag, and a status code (301/302/307).

Validation has your back:

Old slug, new slug, and language are required, and a redirect can’t point to itself.
You can’t create two redirects for the same old slug in the same language.
Chains are collapsed: if the destination of your new redirect already has its own redirect, your redirect is rewritten to the final destination, so readers don’t bounce through several hops. If this would circle back to the old slug, the redirect is refused as circular.

Before saving, you can test a candidate old-slug/new-slug pair: the test reports the final destination, the full redirect chain it would traverse, whether it forms a loop, and whether the old URL currently has live content.

Pattern redirects

For migrating a whole section at once, use a pattern redirect: an old slug ending in * (like products/*) matches every content slug with that prefix. A $1 placeholder in the new slug passes the matched remainder along: for example, products/* → catalogue/item-$1 maps products/red-sweater to catalogue/item-red-sweater. Patterns work in the static site output; they appear only there and in the redirect editor, not in the host export files (each host’s pattern syntax differs).

Bulk actions in the admin area

From the redirects list you can select multiple entries and delete, activate, or deactivate them in one action; the site rebuilds afterwards so redirects take effect.

The 404 log doubles as a redirect source: paths that have been missing from the site (per the aggregated 404 log) can be turned into redirects in bulk: fill in each row’s destination, submit, and duplicates instantly get flagged while the valid rows are created (and recorded in the audit log). A rebuild is then triggered.

Managing redirects may be restricted by your account: an editor without “redirects” among their allowed content types doesn’t get management access to this section.

Export formats

Every build with a site URL set writes two files at the top of the built output:

_redirects (Netlify format): one rule per line: source path, full destination URL, and status code. Hosts and gateways that understand the Netlify format can serve these directly, avoiding the meta-refresh bounce.
_redirects.caddy (Caddy snippet): redir directives ready to include in your Caddyfile’s site block.

Both respect the same rules: only active redirects are exported, live content at the old slug is skipped, and blog-prefix changes are included with permanent status. Canonical-domain enforcement (sending the www/apex alternate host to your canonical domain) is appended to _redirects as its own labelled block, rewritten clean on every build so repeated builds never duplicate rules.

One nuance: the status code you pick applies to servers reading the export files. The static meta-refresh page always forward instantly; the static host can’t set a custom status code on a plain HTML file. Use a proxy that consumes the exports when exact codes (like temporary moves, 302/307) matter to search engines.