Documentation Maintenance and SEO/GEO Rules

This page defines how the Dokki API documentation stays useful to developers, search engines, and AI answer engines.

One page, one intent

Each page should answer one primary question. Use a descriptive title that includes the resource or workflow, such as Create and Update a Document or Pagination, Errors, and Rate Limits.

Keep the first paragraph answer-first:

• what the endpoint or concept does

• who can use it

• the minimum scope required

• the canonical API path

Recommended page structure

Use this order for endpoint pages:

1. Summary

2. Authentication and required scopes

3. Request

4. Parameters

5. Response

6. Errors

7. Examples

8. Related endpoints

Use stable headings and literal HTTP methods and paths. Keep examples executable and ensure every example uses the current https://dokki.one/api/v1 base URL.

Search and GEO rules

• Define important terms in one short sentence before introducing details.

• Prefer concrete nouns, endpoint paths, status codes, and scope names over vague marketing language.

• Put the direct answer near the top of the page.

• Use short lists and tables for facts that should be extracted by answer engines.

• Include one canonical example for each common workflow.

• Add a focused FAQ to overview pages when users ask predictable questions.

• Link related pages using stable document links and keep anchor text descriptive.

• Avoid duplicate pages that describe the same endpoint with different wording.

• Keep public pages indexable unless they contain secrets or internal operational data.

Versioning and change control

When an endpoint changes:

1. Update the reference page and its example.

2. Add a dated entry to 07 Changelog / Changelog.

3. Review authentication, scopes, error codes, and rate-limit notes.

4. Re-run the production API checklist.

5. Check all inbound links from Quickstart, Guides, and related reference pages.

Quality bar

A page is ready to publish when a developer can answer these questions without opening the source code:

• What does this API do?

• What URL and HTTP method should I call?

• Which authentication method and scope are required?

• What is the smallest valid request?

• What does success look like?

• How should common errors be handled?

• Where do I go next?

Treat the published site as the public contract. If implementation and documentation disagree, fix the documentation and the API contract together before announcing the change.