Why a company blog needs one list of rules

The short answer

A company blog answers to several separate rule sources: search documentation, accessibility criteria, consumer law, journalism codes, and feed and sitemap specifications. No single public list joins all of those sources for a content lead.

We wrote one list in our own words: the Open Blog Baseline, version 0.6.1, ratified 2026-10-02. It contains 37 MUST rules and 9 SHOULD rules, divided between editorial rules E1–E25 and technical rules T1–T21. Each rule has a basis label that explains where the rule comes from.

In the Baseline, MUST identifies a rule we treat as necessary for the document’s review framework. SHOULD identifies a recommended rule that still belongs in the review, but is distinct from a MUST rule. A basis label identifies the reason a rule is present: law, self-regulation, required by source, recommended by source, or our policy.

The boundary matters. The Open Blog Baseline is TrustGrowth’s own document, issued by no standards body. It is not legal advice and is not an industry standard. The TrustGrowth blog does not conform to it today.

Why one list is useful to a content lead

A content lead rarely owns only editorial decisions. The same blog may need a writer to check attribution, a developer to check page markup, an accessibility reviewer to check language declarations, and a legal reviewer to check disclosures. Each person may work from a different source, use different terminology, and record findings in a different place.

One list makes the review surface explicit. It puts the rule, its identifier, and its stated basis together. That does not settle every question. It gives the team a common document for deciding which question belongs with which reviewer.

A practical review can follow four steps:

1. Find the rule in one place. Use the rule ID and wording in the Baseline rather than starting from an unstructured collection of notes.
2. See the basis. Check whether the rule is labelled law, self-regulation, required by source, recommended by source, or our policy.
3. Give it to the right reviewer. A legal basis may need a jurisdiction-specific review. A technical basis may belong with a developer or accessibility specialist. An editorial policy may belong with the content lead.
4. Record the current state. Mark what has not been reviewed, what meets the rule, and what does not meet it. Recording a state is not the same as claiming that the site conforms to the whole document.

This is a coordination use. We make no claim about what the Baseline does for search, readers, or publishing speed.

How the basis label works

The Baseline uses five labels. Their meanings are specific:

• Law: a legal duty in the named jurisdiction, under the named conditions. The rule applies to every blog. The law applies only where its conditions are true.
• Self-regulation: a code of an industry body. It is not law.
• Required by source: the source states a requirement and a consequence.
• Recommended by source: the source recommends it. We made it a rule.
• Our policy: no source requires it for a company blog. Sources written for news media support it by analogy, or a specification defines how to do it.

These labels are not interchangeable. “Required by source” does not mean “law”. “Our policy” does not mean that an industry body requires the rule. Keeping those distinctions visible is the point of attaching a basis to each item.

Example 1: E21, labelled Law

The official rule text is:

A material connection is disclosed in the post, near the claim it relates to. A disclosure only in the footer, or only behind a link, does not satisfy this rule.

The basis is stated as: Law: India CCPA Guidelines 2022 clause 14; US 16 CFR 255.5 for US readers; EU Directive 2005/29/EC; Germany UWG § 5a(4).

The label tells the reviewer both the stated basis and the jurisdictions named in the Baseline. It also signals that the reviewer cannot treat the rule as a general editorial preference. The relevant legal question depends on the facts and the jurisdiction that applies.

The Baseline is not legal advice. A reader needs to check the law that applies to their own publication and circumstances.

Example 2: T11, labelled Required by source

The official rule text is:

The page declares its language on the html element.

Its basis is: Required by source: WCAG 2.2 criterion 3.1.1 (level A).

This label marks a requirement stated by an external source, not a TrustGrowth choice. The rule belongs in the technical section because it concerns page markup, while the basis points the reviewer to the named accessibility criterion.

That distinction helps a team ask the next useful question: who should review the implementation, and what does the named source actually say? The Baseline identifies the starting point; it does not replace the source or specialist review.

Example 3: E8, labelled Our policy

The official rule text is:

The site has a public corrections policy, and it says how a reader reports an error.

Its basis is: Our policy. By analogy: IFCN commitment 5; Trust Project.

This label means we chose the rule. It is not a legal or industry requirement for every company blog. The named journalism and trust-related sources support the rule by analogy, but the Baseline presents it as our policy rather than changing that basis.

The TrustGrowth blog does not meet this rule today. That current-state statement is separate from the reason we included the rule.

What the Open Blog Baseline is, and is not

Field Current-state detail Document Open Blog Baseline Version 0.6.1 Ratified 2026-10-02 Rules 37 MUST and 9 SHOULD Sections Editorial E1–E25; technical T1–T21 Basis labels Law; self-regulation; required by source; recommended by source; our policy Text licence CC BY 4.0 Issued by TrustGrowth; no standards body

The document is a labelled reference list authored by TrustGrowth. It is not legal advice, and it is not an industry standard. Reading the list does not make a site conform to it. A team still needs to inspect its own pages, systems, sources, and publishing practices.

The CC BY 4.0 text licence describes how the document’s text may be reused under that licence. It does not change the basis of an individual rule or turn the Baseline into an external authority.

What we have not done on our own blog

The TrustGrowth blog does not conform to the Baseline today, and it has not moved to open_blog. Publishing the list and meeting it are separate facts. A later post in this series gives the detail.

Do this next

Use the Baseline as a review aid for your own blog:

• Open the current Baseline and record the version and ratification date.
• Separate MUST rules from SHOULD rules.
• Group the work into editorial and technical items.
• For each rule, record its basis label and follow the named source.
• Mark each item as not reviewed, meets the rule, or does not meet the rule.
• Record exceptions and open questions.

Keep the record specific. If a rule has a legal basis, record the jurisdiction and conditions that need checking. If it has a source basis, read the named source. If it is labelled our policy, record it as a chosen policy rather than attributing it to an external requirement.

This checklist is a review aid, not legal advice and not a certification. It gives a team a shared way to document questions and current states; it does not resolve those questions by itself.

Method note

This article describes a document, not an experiment. It reports no measured data. Document status: Open Blog Baseline version 0.6.1, ratified 2026-10-02. No re-run date.