Publish and verify a documentation version

Publishing freezes the current default-branch draft into a deployment snapshot. Readers continue to receive the latest ready snapshot until the worker finishes the new one successfully.

Run the pre-publish review

Check the pages that changed:

• The opening paragraph answers the page's primary question.
• Prerequisites appear before actions that depend on them.
• Commands and setting names match the current repository or release.
• Links and redirects reach the final destination.
• Images have useful alternative text and contain no secrets.
• Headings form a logical outline.
• Title, description, slug, indexing, and language relationships are correct.
• Failure recovery is documented for destructive or operational tasks.

For a large change, merge a reviewed documentation branch into the default draft before selecting Publish.

When the CI-check add-on is enabled, the worker runs the configured local gates before creating a ready deployment. Enabled broken-link checks always block on an unresolved internal target. The preview grammar linter can be bypassed only when every finding is grammar-only and an editor explicitly chooses to publish anyway. Disabling the CI-check umbrella skips both checks; record any emergency bypass and restore the gate afterward. See project add-ons.

Publish one coherent version

Select Publish once the default draft is ready. Nibleaf creates a deployment, queues the publish job, serializes the project and page tree, prepares search data, and marks the deployment ready. Do not edit and republish repeatedly to guess past a failing job; inspect its recorded failure first.

Verify as an unauthenticated reader

Open the canonical host while signed out and check:

1. The homepage and a deep page return HTTP 200.
2. An unknown path returns HTTP 404.
3. Search finds a phrase from late in a changed page.
4. The page canonical uses the public host and current path.
5. /robots.txt, /sitemap.xml, /llms.txt, and /llms-full.txt return the expected site and pages.
6. A moved URL reaches its final page in one permanent hop.
7. The mobile sidebar, language switcher, tables, and code blocks remain usable.

A ready status proves that the snapshot job completed. It does not prove DNS, TLS, storage delivery, email, or an external custom domain.

Recover from failure

If the job fails, leave the previous ready version live. Read the deployment failure and worker log, correct the draft or infrastructure cause, and publish a new version. If an incorrect version is already public, restore the intended content to the default draft and publish forward.

Pinning an older application image does not roll back page drafts or a database migration. Self-hosters should use the separate upgrade and restore process. For the merged August capability set, also follow the ordered migration and rollback guide.