Standard
Open Blog Baseline
Version 0.6.1 · ratified 2 October 2026 · 37 MUST rules · 9 SHOULD rules
What this is
No single public standard exists for a blog. Many separate sources each cover one part: search engine documentation, accessibility criteria, consumer law, journalism codes, feed and sitemap specifications. The Baseline puts them into one list of rules, in our own words.
It is our own document. No standards body issued it. It is not legal advice.
Most rules here are our own policy. The sources recommend them, or define how to do them, but do not require them. Each rule shows its basis, so a reader can see which rules a source requires and which are our choice.
How to read a rule
MUST: the blog fails the standard without it. SHOULD: recommended. A blog can conform without it.
The basis says why the rule has its level:
| Basis | Meaning |
|---|---|
| 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. |
Definitions
- Post
-
One article on the blog, at one URL, in one language.
- Presented as fact
-
Text that a reader will take as a true statement about the world. Labelled fiction and a clearly marked hypothetical example are not presented as fact. A judgment, a preference or a forecast of the author is not presented as fact. A label "opinion" on a post does not change the facts in it: a figure, a quotation or a statement about an event in an opinion post is presented as fact.
- Claim that needs a source
-
One of these:
- a statistic or a measured value;
- a quotation;
- a finding, a statement or a position of another party;
- a fact that a general reader would not accept without a check.
These do not need a source: common knowledge, arithmetic that the post shows, and a judgment, a preference or a forecast of the author.
- Substantive change
-
A change to a published post that is likely to change how a reader understands it. It includes a change to the body text, a figure, a chart, a table, an image that carries information, a link, or the structured data. It does not include a spelling correction, a format change, a template change, or a save that changes nothing the reader can see. A substantive change can be outside the revision: a change to the structured data is the example. Such a change makes no new revision. It gets its own entry in the publication log, and it moves the modified date.
- Correction
-
A substantive change that repairs an error of fact.
- Material connection
-
A relation between the author or publisher and a party named in the post that can change how much the reader trusts the post, and that the reader does not expect. Examples: payment, an affiliate commission, a free product, ownership, employment.
- AI-assisted post
-
A post where an AI system wrote or rewrote a part of the text that is more than a spelling or grammar correction.
- Provenance
-
How a post was made. It has one of three values:
ai_assisted,human_writtenorunknown. The valueunknownis used when no evidence shows how the post was made. It is not changed to a different value without evidence. - Revision
-
One exact state of the content of a post: the title, the description, the title and the description for search engines when an editor can set them separately, the body, the author name as the reader sees it, each image with its alternative text, and each FAQ entry (the question and the answer) in the sequence in which the page shows them. Each content field that an editor can change and that a reader or a search engine gets is part of the revision. The dates, the template and the structured data are not part of a revision, because the system makes them from the content and from the publication. Each revision has an identifier that is calculated from the content. The conformance specification defines the calculation.
- Public revision
-
The revision that a reader gets today.
- Approval
-
The record that a named human reviewed one revision, checked its facts, and agreed to its publication. An approval is for one revision only. An approval shows that the revision was reviewed. It does not show how the post was made, and it does not change the provenance.
- Modified date
-
The date on which the last substantive change became public. It is a date of public release. It is not the date of an edit. A change in a draft that is not public does not move it.
Editorial rules
Who is responsible
| ID | Level | Rule | Basis |
|---|---|---|---|
| E1 | MUST | Each post shows the name of its author. The author is a person or an organisation. | Recommended by source: Google helpful content; rater guidelines 2.5.2 |
| E2 | MUST | The author is real. The blog does not invent a person, a profile picture or a credential. It does not give an AI-assisted post to a made-up writer. | Recommended by source: rater guidelines 4.5.3; NewsGuard |
| E3 | SHOULD | The author name links to a page about that author. | Recommended by source: Google Article documentation |
| E4 | MUST | The site names the person or company that holds editorial responsibility for the blog, with contact details. A reader can find this easily. | Law in some countries. Germany: DDG § 5; MStV § 18(2). India: Companies Act 2013 s. 12(3)(c) asks for the company name, the registered office and the company number in official publications; it is not settled that a website is one. A condition of the EU AI Act text exemption (guidelines point 138). Elsewhere: our policy. |
Dates and changes
| ID | Level | Rule | Basis |
|---|---|---|---|
| E5 | MUST | Each post shows the date it was published, with a label. | Recommended by source: Google publication dates |
| E6 | MUST | The modified date of a post is the date on which its last substantive change became public. For a post with no such change, it is the publish date. No other event moves it. This is true for the date that the reader sees, if the post shows one, and for the date in the structured data and the sitemap. | Recommended by source: Google sitemap documentation and Google blog of 2019 |
| E7 | MUST | A corrected post carries a note on the same URL. The note has the label "Correction", the date, and what changed. | Our policy. By analogy: SPJ; IFCN commitment 5; JTI 14.2; AP |
| E8 | MUST | The site has a public corrections policy, and it says how a reader reports an error. | Our policy. By analogy: IFCN commitment 5; Trust Project |
Truth and sources
| ID | Level | Rule | Basis |
|---|---|---|---|
| E9 | MUST | Text presented as fact has no invented figure, quotation, person, study or source. | Law for claims about a product or a service. India: Consumer Protection Act 2019 s. 2(28); CCPA Guidelines 2022 clause 12. Recommended by source: ICC Code article 6; rater guidelines 3.4. By analogy: SPJ |
| E10 | MUST | Each claim that needs a source names its source and links to it when a public link exists. | Law in India for a claim in an advertisement that uses independent research: CCPA Guidelines 2022 clause 12 asks for the source and the date. For all other claims: our policy. By analogy: SPJ; IFCN commitment 2; Trust Project |
| E11 | MUST | The named source states the claim. The post does not give the source a meaning that it does not have. | Our policy. By analogy: ICMJE |
| E12 | SHOULD | The source is the primary source when one is available. | Our policy. By analogy: IFCN criterion 2.2; SPJ |
| E13 | MUST | A first-hand claim ("we tested", "we measured") is made only when the work was done and a record of it exists. | Our policy. Recommended by source: ICC Code article 6 |
| E14 | MUST | The body gives what the title and the description promise. | Recommended by source: Google helpful content; NewsGuard |
| E15 | MUST | The post is original and adds value. It is not a copy or a light rewrite of another page. A quotation with its source is permitted. A republished post is permitted when the owner agrees, the post names the original, and the canonical link points to the original. | Required by source, only for the part on copies that add no value: Google spam policies (scaled content abuse). The conditions for a republished post are our policy. By analogy: SPJ |
How the blog is made
| ID | Level | Rule | Basis |
|---|---|---|---|
| E16 | MUST | The site has a public editorial policy. It says how posts are selected, written, reviewed, published and corrected. | Our policy. By analogy: JTI 9.1; IFCN commitment 4 |
| E17 | MUST | The site says how AI is used to make posts. | Our policy. This is our own transparency commitment. It is not a general legal requirement. Recommended by source: Google helpful content. By analogy: JTI 10.6; Paris Charter; NewsGuard |
| E18 | MUST | The public revision of a post with the provenance ai_assisted or unknown has an approval. The approval is made before the revision becomes public. One exception: when a revision became public without an approval, a late approval of that exact revision satisfies this rule from the time of the late approval. |
Our policy. It is also one of the two conditions of the EU AI Act text exemption (guidelines points 133 to 135). |
| E19 | MUST | Each change to an approved revision of a post with the provenance ai_assisted or unknown makes a new revision, and the new revision needs its own approval. This is true for a change by AI and for a change by a human. The text that the reader gets is the text that was approved. |
Our policy. EU AI Act guidelines point 136 |
| E20 | MUST | While a post with the provenance ai_assisted or unknown is public, and E4, E18 or E19 is not obeyed for it or cannot be shown to be obeyed, the post carries a clear label. For ai_assisted, the label says that AI helped to make the post. For unknown, the label says that the use of AI is not known. |
Law in the EU for text that informs the public on a matter of public interest (Regulation (EU) 2024/1689, Article 50(4) and 50(5)). The EU rule also reaches a publisher outside the EU that foresees readers in the EU (Article 2(1)(c); guidelines point 13). India has no duty to label AI text. Elsewhere: our policy. |
E20 is a fallback. It is a precaution for the time in which E4, E18 or E19 has the result "fail" or "not verified". The label does not change those results. The blog can conform only when E4, E18 and E19 have the result "pass" or "not applicable". For a post with those results, the result of E20 is "not applicable".
Two different questions. E18 answers one question: does the public revision of today have an approval? The history answers a different question: was a revision public without an approval in the past? The first question gives the result of the rule. The second question gives an entry in the history. An entry in the history does not change the result of the rule.
| Situation of the public revision | Result of E18 | History |
|---|---|---|
| The approval came before the publication. | Pass | No entry |
| The approval came after the publication (late approval). | Pass, from the time of the late approval | Entry: public without approval, from the publication to the late approval |
| No approval. | Fail | Entry: public without approval, from the publication |
How to repair a failure. A revision that became public without an approval is repaired in one of two ways:
- A named human reviews that exact revision and approves it. This is a late approval. Its true time is recorded.
- An approved revision replaces it.
The assessment record lists each entry of the history, with the dates. The entries are not removed.
Provenance and these rules.
| Provenance | E18 and E19 | E20 |
|---|---|---|
human_written | Not applicable | Not applicable |
ai_assisted | Assessed. Without an approval of the public revision, E18 has the result "fail". | As the rule says |
unknown | Assessed in the same way as ai_assisted, with one difference: without an approval of the public revision, E18 and E19 have the result "not verified" and not "fail", because no evidence shows that AI made the post. With an approval of the public revision, E18 and E19 get the result that the evidence gives. | While E4, E18 or E19 is "fail" or "not verified", the post carries a label that says that the use of AI for this post is not known. The label does not say that AI made the post. When E4, E18 and E19 are "pass", E20 is "not applicable" and the label is removed. |
An approval does not change the provenance. A post with the provenance unknown keeps that value after an approval. The value changes only when evidence shows how the post was made.
Posts from before the adoption of the standard. The blog adopts them as they are. It does not publish them again. Each adopted post has a baseline record. It gives the provenance, the first publish date, the last modified date, and each approval that the old system holds, with the evidence for each of them. A value without evidence is recorded as unknown. The conformance claim states the adoption date.
Money and reviews
| ID | Level | Rule | Basis |
|---|---|---|---|
| E21 | MUST | 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. | Law: India CCPA Guidelines 2022 clause 14; US 16 CFR 255.5 for US readers; EU Directive 2005/29/EC; Germany UWG § 5a(4) |
| E22 | MUST | A post that a third party paid for has a clear label at the top of the post. | Law: India Guidelines for Prevention and Regulation of Dark Patterns 2023, Annexure 1 point 9 (disguised advertisement); EU Directive 2005/29/EC Annex I point 11; Germany DDG § 6. Self-regulation: ASCI Code; UK CAP Code 2.4; ICC Code article 7 |
| E23 | MUST | The blog has no false review and no false testimonial. A review shown as a customer review comes from a real customer. | Law: US 16 CFR Part 465; EU Directive 2005/29/EC Annex I points 23b and 23c; UK DMCC Act 2024 Schedule 20. Voluntary standard in India: IS 19000:2022 |
The reader
| ID | Level | Rule | Basis |
|---|---|---|---|
| E24 | SHOULD | The reader can find, understand and use what the post gives. | Recommended by source: ISO 24495-1:2023 |
| E25 | SHOULD | The post has no filler. Each part supports the purpose of the post. | Recommended by source: rater guidelines 5.2.2 |
Technical rules
Reach
| ID | Level | Rule | Basis |
|---|---|---|---|
| T1 | MUST | Search crawlers can get each post. The post returns HTTP 200 and has content that can be indexed. | Required by source: Google Search Essentials, technical requirements |
| T2 | MUST | Each post is served on HTTPS. | Our policy. Google prefers HTTPS and does not require it. |
| T3 | MUST | Each post has one canonical URL and declares it with rel="canonical". |
Our policy. Google: an optional strong signal. RFC 6596 defines the link. |
| T4 | MUST | A moved post sends a permanent redirect (301 or 308) to its new URL. A removed post returns 404 or 410. | Recommended by source: Google; Bing |
| T5 | MUST | The sitemap lists each post that has its canonical URL on the blog. It does not list a republished post that has its canonical URL on another site. When the sitemap gives a last modified date, that date is the modified date of rule E6. | Our policy. A sitemap and lastmod are optional in the protocol and for Google. The protocol requires a correct date when the date is given. |
| T6 | MUST | The blog has a feed that is valid as RSS 2.0, Atom or JSON Feed. Each page head links to it. | Our policy. The specifications define the formats. No source requires a feed. |
| T21 | MUST | The blog declares one primary type of list page (examples: category pages, tag pages, topic pages). Search crawlers can get and index each page of that type. Each list page that can be indexed has a title and a meta description that no other page of the blog has. This includes each page of a list that has more than one page. A list page of a different type can have noindex. Crawlers can follow its links. |
Our policy. |
Page structure
| ID | Level | Rule | Basis |
|---|---|---|---|
| T7 | MUST | Each post has a <title> that describes it. No two posts have the same title. |
Required by source: WCAG 2.2 criterion 2.4.2 (level A) for a descriptive title. Recommended by source: Google, for distinct titles |
| T8 | SHOULD | Each post has a meta description that no other post has. | Recommended by source: Google |
| T9 | MUST | No heading is more than one level below the heading before it. | Required by source: HTML Living Standard, section 4.3.11 |
| T10 | SHOULD | The post title is the only level 1 heading. | Our policy. The HTML standard says a level 1 heading should exist. No source requires exactly one. |
| T11 | MUST | The page declares its language on the html element. |
Required by source: WCAG 2.2 criterion 3.1.1 (level A) |
| T12 | MUST | The page has a viewport declaration, and the content fits a width of 320 CSS pixels with no horizontal scroll. | Our policy. Recommended by source: Google. WCAG 2.2 criterion 1.4.10 is level AA. |
| T13 | MUST | Each image on the page has an alt attribute. An image that carries information has a text alternative. A decorative image has an empty alt. |
Required by source: WCAG 2.2 criterion 1.1.1 (level A); HTML Living Standard |
| T14 | MUST | Each link on the page that points to the same site goes to a page that returns HTTP 200 to a reader who is not signed in. One exception: a link to a page that needs a sign-in is permitted when its destination is on the declared list of sign-in destinations and its text tells the reader that a sign-in is necessary. | Our policy. Recommended by source: Google; Bing |
Data for machines
| ID | Level | Rule | Basis |
|---|---|---|---|
| T15 | MUST | Each post has Article or BlogPosting structured data with the headline, the author name, the author type, the publish date and the modified date of rule E6. It has the image when the post has one. |
Our policy. Google: "There are no required properties"; these are recommended. |
| T16 | MUST | The structured data agrees with what the reader sees. The author type is Person for a person and Organization for a group. Each date agrees with the same date on the page, when the page shows it. No date is in the future. |
Required by source: Google structured data policies |
| T17 | SHOULD | Each post has the Open Graph properties title, type, image and URL. | Our policy. The Open Graph protocol defines them. |
Fair conduct and quality
| ID | Level | Rule | Basis |
|---|---|---|---|
| T18 | MUST | The page has no hidden text or hidden instruction that is aimed at search engines or AI systems. The page does not change how the back button works. | Required by source: Google spam policies; Bing Webmaster Guidelines |
| T19 | SHOULD | The page meets WCAG 2.2 level AA. | Recommended by source. Law can apply: the European Accessibility Act covers a site that sells to consumers, with an exemption for a microenterprise. |
| T20 | SHOULD | The page has good Core Web Vitals. | Recommended by source: Google |
Not in the standard
These items are known. They are not rules, because no ratified standard exists or because the use is not proven. Status on 28 September 2026.
| Item | Status |
|---|---|
llms.txt |
One person's proposal. Google Search ignores it. |
AI crawler preferences (IETF aipref, Content Signals, RSL, TDMRep) |
Drafts and vendor proposals. None is ratified. |
| C2PA content credentials for HTML | In the C2PA 2.4 specification. Tool support is not checked. |
digitalSourceType for AI text |
The IPTC vocabulary is written for images and media. |
| FAQ structured data | Permitted. Google stopped FAQ rich results on 2026-05-07. |
| IndexNow | Optional. Google does not take part. |
| WCAG 3.0 | Working Draft. WCAG 2.2 stays the reference. |
Some sources can change soon. Each new version of the Baseline starts with a new audit of its sources.
- SPJ members vote on a revised Code of Ethics from 2026-10-01 to 2026-10-04.
- IFCN announced a review of its code.
- The IETF
aiprefdrafts can become RFCs.
How a blog is assessed
The rules are one document. How a blog is assessed against them is a second document, the conformance specification. It defines how a revision is identified, what a publication record holds, and which results a rule can have: pass, fail, not verified, or not applicable. It is not published on this site yet.
Software can read a public page and find some defects. A pass of those surface checks does not establish conformance. Rules such as E9, E11 and E13 need a person who checks the facts.
Where TrustGrowth stands
The TrustGrowth blog does not conform to the Baseline today. On 3 October 2026 this site has no public editorial policy (E16), no public corrections policy (E8), and no statement of how AI is used to make posts (E17). The modified date of a post follows the last save of the record, which E6 does not permit.
We wrote the rules before we met them. The work to meet them runs through open_blog, the open-source engine that records each release. This page will state the adoption date when the TrustGrowth blog moves to it. The first conformance claim will cover posts from that date.
Licence and name
The text of the Baseline has the licence CC BY 4.0. You can copy the official text and you can make a changed version, with attribution, as the licence says.
Separate from the licence, we ask this of a changed version. The official text is the text that TrustGrowth publishes. A changed version says that it is changed, as the licence asks. A changed version does not suggest that TrustGrowth made it or agrees with it.
Found an error in a rule or in a basis? Write to us through the contact page.