404 Management

When your static site has broken links, Chinaski can log every 404 hit, show you the most-hit paths, and turn those paths into redirects with a few clicks.

Where you find 404s

Open Health in the admin and switch to the 404s tab. It shows the top 500 logged 404 paths ranked by hit count, so the busiest broken links are at the top.

For each path you can see:

the path that 404’d
how many times it was hit
the last time it was seen
the referring URL, if known

You can search paths by keyword and filter by period: all time, last 7, 30, or 90 days. 404 log entries are pruned automatically after 90 days, and you can clear the whole log at any time with the Clear Log button (you’ll be asked to confirm).

How 404s get logged

Chinaski does not capture 404s itself: your static host or web server’s access-log processor records them by posting each miss to Chinaski’s 404-log API with an API key that has write permission. Paths are recorded with their referring URL and user agent, and repeat visits to the same path are counted as one entry with an incrementing hit count.

Creating redirects from 404s

Two ways to act on the list:

One at a time: each row has a Create redirect link. The old path is prefilled with the language and blog prefixes already stripped, on the usual redirect creation screen.
In bulk: tick the checkboxes for several paths, then you get a table where, for each path, you fill in the destination slug, the language (default “en”), and whether the redirect is a page or a post. Active is checked by default. A redirect that points to itself is rejected.

How redirects behave

Redirects are per-language: each redirect applies to old paths in one language only.
A redirect only takes effect when the old path is not a currently published page or post. If the old slug is still live, the redirect is skipped; Chinaski warns you of this when you create it.
If the destination doesn’t exist as active content or another redirect target, you get a warning.
Redirects can’t point to themselves, and loops between redirects are refused. If your destination is itself already redirected, the chain is followed to its real end and your redirect is created pointing directly there (“chain collapsed”).
On the redirect creation screen there is a Test Redirect button: fill in old slug, new slug, and language to preview the redirect chain, whether it loops, where it ultimately lands, and whether the destination exists.

Pattern redirects

The Pattern Redirect option lets one redirect cover many paths: use * at the end of the old slug to match any suffix, and $1 in the new slug to substitute it. For example, old products/* → new solutions/$1 sends products/amplifier to solutions/amplifier.

Pattern redirects are served as HTML redirect pages (meta-refresh); they are not included in the generated server redirect config, where plain redirects use HTTP 301, 302, or 307 codes. The HTTP code you pick applies only to that server config; the HTML fallback pages that ship with the static output always use meta-refresh.

Managing redirects in bulk

On the Redirects page you can delete, activate, or deactivate multiple redirects at once (these actions trigger a site build). You can also import or export them as data:

Export: download all redirects as redirects.json, ordered by language then old slug.
Import: upload a CSV with the columns old_slug,new_slug,language,type,active,notes,is_pattern,http_code. Files are capped at 4 MiB and 5,000 rows per import. Type defaults to page, active defaults to on, and HTTP code defaults to 301. Only lowercase letters, digits, and - are allowed in slugs (plus * for old pattern slugs and $// for destinations); invalid rows are skipped rather than failing the whole import.

What happens when the 404 is from a still-live page

Nothing: if a path belongs to a published page or post, no redirect is generated for it, even if it appears in the 404 log.