Editorial Policy

This page documents the standard every resource on this site has to meet, and the gate every URL has to pass before it can be indexed. It is public because a publishing standard nobody can check is a marketing claim.

The principle

The single rule this site is built around:

Never create an indexable URL merely because data exists that could populate it.

A great deal of technical publishing works the other way round. A database row becomes a page, the page enters the sitemap, and the sitemap is submitted to a search engine. Volume becomes the metric, and the reader gets thousands of pages that each answer a fraction of a question.

We invert the order. Content lives in the application first. It becomes an indexable URL only after an editor decides that this specific URL deserves to exist in search results — a decision recorded in the file, with a written reason.

The practical consequence is that our database will be much larger than our sitemap, permanently and by design. We hold hundreds of prompts and none of them is a page.

The indexability gate

Before a resource can carry index,follow and appear in sitemap.xml, every one of the following has to be answered. Some are checked automatically from the file. The rest are human attestations an editor records in frontmatter — and an unanswered question counts as a no.

Does it satisfy a distinct user intent? The intent has to be written down in the editor’s own words, not implied by the title.
Is there already a page satisfying the same intent? If yes, the work becomes an addition to that page rather than a new URL.
Does it contain meaningful original value? Measured by the concrete evidence it carries: commands, real output, diagrams, decision trees, failure modes, validation steps.
Has the content been editorially reviewed? By a human.
Are the commands and configuration contextually correct? Reviewed by an engineer who knows the system, not just proofread.
Does it carry substantially more value than a database record? Enforced as a minimum depth of prose plus at least two distinct kinds of evidence.
Does it belong to an established site pillar? Content that fits nowhere usually should not exist.
Would a reader bookmark or share it? An explicit attestation that this is a reference, not a passing note.
Does it have meaningful internal-link relationships? A page with nothing to connect to is usually a page nobody needed.
Can we clearly explain why this URL deserves indexing? Written out, in full sentences, stored in the file.

The gate lives in one module and is the only thing that decides both the robots directive and sitemap membership. They cannot drift apart, because they are the same function call.

Default: not indexed

New content starts at indexable: false and status: draft. Nothing becomes indexable by being added, by building, or by being deployed. It becomes indexable when someone decides it should be and records why.

Published is not the same as indexable

These are two separate states and we keep them separate deliberately:

Published — live on the site, discoverable through navigation and site search.
Indexable — has passed the gate and is submitted to search engines.

A resource can be the first without being the second, and many are. Internal discoverability does not require search indexability. When a resource is live but has not completed review, it carries a visible banner saying so, so no reader has to guess.

What we will not do

Create a page per error message, per version, or per cloud provider by substituting a name into a template.
Publish a resource because a keyword has search volume, when the reader would be better served by a section inside an existing page.
Expand a complete 900-word answer to 3,000 words to look more authoritative.
Publish near-duplicates. Our similarity audit flags overlapping content and the recommendation is consolidation, not publication.
Put individual database records — prompts, error signatures, commands — into the sitemap.
Invent testimonials, customer counts, case studies, awards, or usage statistics. If we have no social proof, we show technical proof instead.
Add structured data describing something that is not on the page. No review ratings, no fabricated FAQ blocks.

Consolidation before creation

Before a new resource is written, the question is not “is this a good topic” but “should this be its own URL”. The alternatives considered first are: a section in an existing guide, a step in a runbook, a subsection of an Academy lesson, a database record, a tool result, or a glossary entry. A new URL is the last option, not the first.

Troubleshooting content follows this most visibly. Rather than a page for each failure string, we write one guide per failure class — container startup failures, scheduling failures, volume provisioning failures — and cover the variants inside it, where a reader can see how they relate.

Corrections

When something here is wrong, we fix the page and record the change in its updated date. For a material correction — one that could have led a reader to do the wrong thing — we say what was wrong in the page itself rather than editing silently.

If you find an error, tell us. Corrections from readers who have actually run this in production are the most valuable feedback we get.

How we test — what “tested” means on this site, and what it does not
AI use policy — where AI is used in producing content, and where it is not