Publish With Standards – A Practical Framework for Website Owners
Most advice about SEO and AI-assisted publishing arrives as a checklist. This page is not a checklist. It is a way of thinking about publishing that helps you — or an AI agent working on your behalf — decide whether a page should exist at all, what makes it worth building, what must be true before it ships, and what the evidence says to do after it goes live.
The aim is narrow and deliberate: remove avoidable reasons a page would be weak, redundant, disconnected, technically blocked, or strategically misplaced before search engines and readers ever see it.
What this framework is, and is not
It is a small set of standards a website owner can apply across stacks — WordPress, static sites, headless setups, AI builders — and a set of rules an AI agent can be pointed at when it does the actual work. The standards are versioned, evidence-classified, and revisable as Google guidance, Bing guidance, and platform behavior change.
It is not a promise about rankings, indexation, or AI-search visibility. It is not a prompt library, a plugin score, or a 50-step launch checklist. It is not stack-specific. Where a rule depends on context, the rule says so.
A note on language used throughout this framework: where a child page says a pattern “tends to” produce a result — for example, “tends to perform less well” or “tends to underperform” — the claim is a practitioner observation, not a confirmed search-engine mechanic. Where a sentence uses “will” or “is” instead, the claim is one this framework will defend against a primary source in the rule registry.
The four phases
Publishing a useful page well moves through four phases. They are not deadlines. They are decision points triggered by what has already happened.
1. Decide
Before a page exists, the question is whether it should. The job of this phase is to qualify the opportunity — does the topic match a real reader task, does the site already cover it under a different angle, is there a distinct value case beyond what an AI can summarise from public sources, does it belong inside an existing silo or extend one?
A page that fails to qualify here is cheaper to skip than to write and later consolidate.
Read more: Deciding whether to publish a page.
2. Build
Once a topic qualifies, the job is to design the page so it is genuinely useful — clear reader task, defensible distinct value, structure that matches search intent, accurate facts, honest schema only where the page truly contains the underlying entity, internal-link relationships planned before drafting rather than retrofitted after.
Read more: Website page viability before build.
3. Release
A page that is built well can still be ineligible for search. The job of release is to verify a small set of preconditions — the rendered HTML actually contains the primary content, the canonical points where it should, robots and noindex agree with intent, the page is reachable from at least one navigable page, deployment and analytics are correct — before search engines are asked to see it.
Read more: Release readiness for a website page.
4. Evaluate
After release, evidence decides what happens next. The phase is event-driven, not calendar-driven. When the page is discovered, when it is crawled, when it is indexed, when its first impressions appear, when its query relevance settles — each event is an invitation to monitor, diagnose, improve, consolidate, or retire. Arbitrary timeframes (14 days, 90 days) are not part of this framework because they are not part of how search behaves.
Read more: Evaluating a published page with evidence.
How the rules work
Behind the four phases is a small rulebook organised in three layers:
- Article Viability — what makes a single page worth publishing
- Search Readiness — what must be true before a page is exposed to search
- AI Evidence and Verification — how AI output gets treated as a proposal until evidence accepts or rejects it
Each rule is classified as MUST, SHOULD, MAY, or MUST NOT, and tagged with the kind of support that backs it — confirmed by Google or Bing, confirmed by a platform vendor, a durable industry operating practice, a practitioner heuristic, a site policy choice, an experimental technique, or — for any rule whose evidence has not yet been verified against a primary source — needs-verification.
Article Viability
- AV-001 MUST Named reader task before drafting
-
A page is not drafted until its reader task can be stated as one sentence with a concrete verb and a concrete object.
- AV-002 MUST Distinct value case stated before drafting
-
A page is not drafted until it can articulate what it offers beyond a generic AI summary of the same topic from public sources.
- AV-003 SHOULD Silo fit or planned silo seeding
-
A new page either extends an existing silo on the site, or seeds a new silo with at least three other related pages planned alongside it.
- AV-004 MUST Structure matches intent shape observed in current SERP
-
The structural shape of the page (comparison, how-to, definition, buyer-decision, news) is chosen to match the dominant intent shape of the current SERP for the target query, not the writer or agent preference.
- AV-005 SHOULD Factual claims have a source identified before drafting
-
Every numeric, vendor-specific, dated, or attributed claim the page intends to make has a source identified before drafting begins.
- AV-006 MUST NOT Pages produced primarily to add volume
-
A page is not published if its primary purpose is to add page count rather than serve a named reader task.
Search Readiness
- SR-001 MUST Primary content present in rendered HTML
-
The page headline, opening paragraph, and primary body content are present in the HTML response a search engine receives, not only after client-side rendering.
- SR-002 MUST Canonical points to the URL the page wants indexed
-
The rel=canonical tag points to the URL the page is published at, matching the site trailing-slash convention.
- SR-003 MUST Robots directives match publication intent
-
The page does not carry a noindex directive it is not supposed to carry; robots.txt does not disallow the URL or its parent; no X-Robots-Tag header conflicts with the in-page directive.
- SR-004 MUST At least one inbound internal link from a navigable page
-
The page is linked from at least one page that is itself reachable through site navigation.
- SR-005 MUST Page returns 200 from the production HTTPS URL
-
A direct fetch of the production HTTPS URL returns a 200 status with the expected rendered content; redirects from prior URLs resolve without chains.
- SR-006 SHOULD Analytics and tracking events verified live
-
If the page is part of how the site measures conversion, the relevant tracking events are confirmed firing on the production URL before the release is considered done.
AI Evidence and Verification
- AE-001 MUST AI-generated factual claims are proposals until verified
-
A claim produced by an AI agent is treated as a hypothesis to verify against a primary source, not as content ready to publish.
- AE-002 MUST No published claim the producing agent cannot cite
-
A factual claim that cannot be traced to a primary source by the agent that produced it is either removed, rewritten as stated opinion, or held until a source is found.
- AE-003 SHOULD Producing agent is not the only validator
-
A draft produced by an AI agent is reviewed by a different reviewer (a person, a separate agent, or a deterministic check) before publication.
- AE-004 MUST NOT Inflated certainty language on unsupported claims
-
Claims the source does not back are not published with certainty language (always, never, definitely, guaranteed, proven).
What this framework does not standardise
Some things look like they want a rule and do not get one. Word counts, posting cadence, exact internal-link counts per page, ratios of long-tail to head-term targeting, the right percentage of pages with schema — these are site-specific and competition-specific. Where a number appears in this framework, it is a window backed by evidence on this site, not a universal threshold.
Using this with an AI agent
The four-phase structure is small enough to put inside an agent’s working context as constraints rather than instructions. An agent told to “draft an article” without further constraint will draft. An agent told to “follow the Article Viability standard before drafting, then the Search Readiness standard before release” has a structure it can be checked against.
Two practical patterns make this work without producing rigid pipelines. First, the agent producing a draft is not the agent verifying the draft — the same context that generated a claim tends to confirm it. A separate reviewer pass, whether by a different agent or by a deterministic check, catches what self-review misses. Second, claims the agent cannot cite are treated as candidates for removal, not as content that needs softening hedging. The discipline is structural; the prose follows from it.
Versioning
This framework is at v1.0. The rulebook will gain rules, retire rules, and re-classify rules as primary-source evidence accumulates. Deprecated rules are kept with a reason rather than deleted. Changes are summarised on a changelog page when one exists.