Post Types, Elements and Checklists Explained

A durable content system separates decisions by scope. The workflow decides what the site should build and verify. The post type decides what job one page must do. The element decides what one block means and how it behaves. When those responsibilities stay separate, a team can improve one definition and reuse it everywhere without rewriting the whole system.

This page explains that architecture. It expands the model introduced on the playbook hub, shows the one-way dependency between its three production layers, and traces a real AmICited academy page from opportunity selection to measurement.

The expanded system diagram

The playbook hub summarizes the system as Plan → Build → Adapt → Improve. It also identifies the document, component, priority, and loop represented by the connected pillars. The expanded view below makes the dependency direction explicit.

FOUNDATIONS: shared reasoning about intent, evidence, structure, and trust
                              │
BUSINESS TYPE: cross-cutting priority lens
                              │ influences opportunity order
                              ▼
┌──────────────────────────────────────────────────────────────────┐
│ PROCESS / CHECKLISTS — operates on the site                     │
│ Select opportunity → sequence work → approve → publish → review │
└──────────────────────────────┬───────────────────────────────────┘
                               │ selects
                               ▼
┌──────────────────────────────────────────────────────────────────┐
│ POST TYPE — operates on one page                                │
│ Defines the page job, evidence burden, shape, and section order │
└──────────────────────────────┬───────────────────────────────────┘
                               │ selects and orders
                               ▼
┌──────────────────────────────────────────────────────────────────┐
│ ELEMENTS — operate on individual blocks                         │
│ Define purpose, fields, content rules, rendering, and variants  │
└──────────────────────────────────────────────────────────────────┘
                               │
                               ▼
                         PUBLISHED PAGE
                               │ observed by
                               ▼
               RESULTS: evidence for the next process decision

The results arrow closes an operating loop; it does not reverse the definition dependency. A weak result may cause the process to select a different post type next time, but it does not allow a report to change what a step-list element means. Likewise, foundations inform every decision without becoming another production layer.

The six pillar hubs are different entrances to this same system. Use SEO foundations for the reasoning, SEO post types for document shapes, SEO content elements for blocks, SEO strategies by business type for prioritization, the SEO process for production controls, and SEO results for measurement and next decisions.

1. The three layers, defined precisely

1. Process and checklists operate on the site

A process is the ordered system of decisions that moves the site from evidence to action. A checklist is a finite verification instrument inside that process. Together they decide which pages should exist, which dependency comes first, who approves the work, whether the page can publish, and when the outcome will be reviewed.

This layer needs a site-wide view because page opportunities compete for the same budget, expertise, development capacity, and crawl attention. A technically blocked site should not accelerate production simply because ten briefs are ready. A process can say, “Complete the technical baseline before publishing another cluster,” because it owns sequencing across pages. It can also say, “Review performance after the agreed observation window,” because it owns the loop after publication.

Process rules have observable inputs and decisions. A useful checklist item names the evidence to inspect, the pass condition, and what happens after a failure. “Check links” is vague. “Confirm every internal destination resolves and every anchor accurately describes it; block publication if either test fails” can be performed and audited.

2. A post type operates on one page

A post type is a contract for the job a single page performs for a reader. The job determines the page’s shape. A how-to guide enables a task; a glossary term establishes meaning; a comparison supports a choice; a case study demonstrates what happened in a specific situation. These are not labels applied after drafting. They imply different questions, evidence burdens, section sequences, and next actions.

The post-type specification answers questions such as:

• What intent must this page satisfy?
• What makes this format a better fit than its neighboring formats?
• Which elements are required, recommended, conditional, or prohibited?
• In what order do those elements appear, and what exception permits a different order?
• What evidence is sufficient for the page’s claims?
• What reader action naturally follows completion of the page’s job?

A post type may require a warning before an irreversible step or put a sources block after the last evidence-backed claim. It owns those position rules because position expresses the logic of the whole document. It does not own the internal fields or visual treatment of either element.

3. An element operates on one block

An element is a typed, reusable content block with one primary purpose. A direct-answer block resolves the main question compactly. A comparison table organizes consistent dimensions. A warning box interrupts the flow because missing the risk could cause harm or failure. A sources block makes evidence inspectable. The element contract specifies what the block contains, which fields are required, what valid variations exist, and how renderers preserve its meaning.

The scope stops at the block boundary. A warning box can define a severity field and require the consequence to be explicit. It cannot say that every how-to guide needs one after step three; that is page-level logic. Similarly, a sources block can require enough publication detail to identify each source. It cannot decide which site opportunity gets researched next.

Ready to Monitor Your AI Visibility?

Track how AI chatbots mention your brand across ChatGPT, Perplexity, and other platforms.

Get Started Contact

2. Dependency moves in one direction

The dependency chain is process → post type → elements. Process selects a page job. The chosen post type selects and orders blocks. Elements are the atoms from which the page is assembled. Nothing in the definition chain points upward.

That direction prevents circular ownership. If an element contains a condition such as “show only on alternatives pages,” the component now needs to know which document contains it. It stops being reusable, tests require page context, and a renderer must duplicate editorial policy. The correct rule is either “alternatives pages require this element at this position” in the post-type specification or “this block has a distinct purpose” in a separately defined element.

The reverse error is equally damaging. A post type must not redefine a shared element by giving it different required fields, heading behavior, or accessibility rules. It can select a supported variant, but the variant still belongs to the element contract. Otherwise two pages can claim to use the same element while emitting incompatible markup and meaning.

Think of selection and definition as separate powers. The upper layer selects from contracts maintained below it. It never edits those contracts locally.

3. The layering rule: put each rule at the narrowest reusable scope

Rules drift upward or downward when teams organize guidance by the file being edited rather than the behavior being governed. The cure is a three-question test:

1. Does the rule govern one block’s meaning, fields, or rendering? Put it in the element definition.
2. Does it govern one page’s job, evidence pattern, section presence, or section order? Put it in the post type specification.
3. Does it govern opportunity selection, work order, approval, publication, or later evaluation across pages? Put it in the process or checklist.

“Always cite sources” is too broad to implement literally: not every sentence needs a citation. The reusable rule is that evidence-backed claims must be connected to identifiable sources, and the sources element defines the representation and minimum fields. A post type can then require that element when its normal claims demand external evidence.

“This type always ends with a red-flags section” belongs to the post type. The rule exists because a reader using that document shape needs disqualifying conditions before acting. The block may use a warning element, but the page contract owns its presence and final position.

“Never publish before the technical baseline audit passes” belongs to the process. It controls the order and release state of work across the site; neither the page nor any block can verify the site’s technical readiness.

Misplacing a rule may appear harmless on the first page. The cost emerges at the tenth. Authors copy local exceptions, components gain hidden context, checklists accumulate style advice, and nobody knows which definition is authoritative. Reuse disappears even though the same names remain.

Stay Updated on AI Visibility Trends

Get the latest insights on AI mentions, brand monitoring, and optimization strategies.

Email address

Subscribe

4. Worked trace: a Core Web Vitals academy page

Consider the published page How to Check Your Core Web Vitals in AmICited . It is a useful trace because it teaches a bounded task, shows a real product screen, explains unfamiliar metrics, and leads to repeatable action. Here is how the system should produce that page from top to bottom.

1. The process selects the opportunity

During the technical-baseline-audit phase, the team finds that users need to interpret the Web Vitals audit rather than merely see five abbreviations and colored values. The evidence packet records the reader question—“How do I check and act on Core Web Vitals in AmICited?”—the product surface involved, the existing search-result patterns, available product evidence, and the desired outcome: a user can open the audit, interpret every metric, prioritize a fix, and know when to check again.

The phase selects a page because the need is durable, can be answered from verified product behavior, and supports a real task. It also sets dependencies: confirm the product workflow and terminology before drafting; do not invent thresholds or claim that performance alone causes AI citations.

2. The process chooses a post type

The chosen post type is how-to guide because the reader wants to complete a sequence in a product. A what-is-X page would explain Core Web Vitals but would not carry the reader through the interface. An ultimate guide would widen scope into testing methods, engineering fixes, and broader performance strategy, delaying the immediate task. A listicle guide would promise a ranked or enumerated set rather than one coherent workflow.

That choice establishes the page promise: by the end, the reader can find the audit, understand its output, decide what to fix first, and plan a recheck.

3. The post type selects and orders the elements

The how-to contract assembles the page in this order:

Position rules matter. The definition precedes metric interpretation because instructions cannot depend on undefined terms. The screenshot sits beside navigation rather than at the end because visual evidence is most useful at the point of orientation. The note about missing data stays adjacent to the screen state it explains so readers do not mistake an unavailable value for a broken audit.

Each block still follows its own element definition. The page type decides that the note belongs near the product screen; the note element decides its semantics and rendering. The page type decides that an ordered action sequence is required; the step-list element decides how a step is represented. This is the dependency boundary in practice.

4. The page passes the QA gate

The pre-publish QA checklist evaluates the assembled page without rewriting its contracts. It confirms that the product route matches the current interface, the screenshot depicts the stated screen, acronyms are expanded on first use, advice follows from available evidence, internal destinations resolve, heading order is coherent, and the page still completes the task when scanned.

A failure returns to the owner of the problem. A wrong product route returns to content verification. A missing required section returns to the post-type implementation. An inaccessible note style returns to the element renderer. The checklist reports the failure; it does not absorb the quality rule and become the permanent definition of a good note or how-to guide.

5. The result report measures the page’s job

The measurement record starts with a publication baseline and an observation window. It tracks whether the page becomes visible for its intended question, whether search or answer systems select it, whether readers engage with the instructions, and whether they move to the relevant product workflow. These are separate levels of evidence: visibility is not task completion, and a product visit is not proof that the article caused a commercial outcome.

At review time, the report supports a process decision: keep the page, revise unclear sections, refresh changed interface details, expand only when new reader needs are verified, consolidate overlap, or retire it. Measurement closes the operating loop by informing the next process decision without changing any lower-layer contract.

5. Business type is a facet, not a fourth layer

A business type describes commercial context: how the organization creates value, what customers must understand before buying, and which journeys deserve content investment. It cuts across the architecture because that context affects prioritization at several decision points. It does not add another level between a post type and an element.

For a SaaS product, comparison, use-case, product, and how-to pages may deserve early attention because evaluation, adoption, and retention are important. An ecommerce business may prioritize category, product, comparison, and best-for-use-case pages because discovery and product selection work differently. Those are ranking hypotheses that research must validate, not new definitions of the formats.

The same comparison table remains the same element in both contexts. The same how-to post type keeps the same page job. Business context changes which pages enter the roadmap, the commercial evidence they need, and their priority relative to other opportunities. If a “SaaS comparison table” gains different semantics simply because it appears on a SaaS site, the model has leaked business logic into an element.

6. Versioning without silent reinterpretation

Published pages were approved against specific contracts. A later improvement must preserve that history rather than pretending every old page already complies.

When an element definition changes, first classify the change. A compatible rendering fix—such as corrected spacing or improved accessible markup with the same meaning and fields—can update all instances through the shared renderer. A semantic or structural change—such as making source dates mandatory or changing what severity means—creates a new version. Existing pages continue to render under the contract they used until they pass a validated migration.

The migration record should identify affected instances, map old fields to new ones, flag content that needs editorial judgment, test every supported output, and record completion. If a reliable mapping is impossible, do not manufacture missing evidence. Put the instance into a review queue.

When a post type gains a required section, new drafts adopt the revised specification immediately. Already-published pages enter a retrofit backlog. Inventory them by post-type version, assess whether the new section is relevant and supportable, prioritize by risk and value, update the source, run QA, and record the new version. Until migration is complete, dashboards should distinguish “published under version 1” from “compliant with version 2.”

Process checklists also need versions, but their change affects future executions rather than silently editing the historical result of a completed review. Keep the evidence showing which checklist version approved each release.

7. Anti-patterns that expose a broken boundary

A post type that is one element in disguise

“FAQ post” often names a single accordion rather than a document job. The reader’s real job may be learning a concept, evaluating a product, or solving a problem. FAQ is then an element chosen because multiple discrete questions remain, not the page’s governing type. Promote something to a post type only when it defines a distinct intent, document shape, evidence burden, and next action.

An element used by only one post type

Single use is not automatic proof of an error, but it is a strong review signal. If the block has no independent purpose outside one page contract, it may simply be a required section in that post-type specification. Creating an element too early adds a renderer, schema, documentation, and versioning burden without reuse. Keep it in the post type until a second genuine use demonstrates a stable, shared purpose.

A checklist step that is really a quality rule

“Write clear warnings” is not an executable check because “clear” has no defined acceptance condition. The warning element should require the risk, triggering condition, and consequence. QA can then verify that those fields are present and supported. The checklist observes compliance; it should not be the only place the quality standard exists.

Local redefinitions with familiar names

Calling a custom box “sources” does not make it the sources element. If a post-type template changes its fields or meaning locally, authors cannot know which contract wins. Use the canonical element, propose a supported variant, or keep genuinely page-specific prose in the post-type spec under a different name.

Process logic embedded in page copy

Editorial instructions such as “do not publish until engineering approves this” should not remain in the public page or an element’s authored content. Approval belongs in workflow state and checklist evidence. Mixing production control with reader-facing copy makes exports unsafe and leaves the real gate dependent on someone noticing a sentence.

A practical ownership test

When a new rule appears, write it as a complete sentence and underline its subject. If the subject is this block, the element owner decides. If it is this kind of page, the post-type owner decides. If it is this site, release, campaign, or production run, the process owner decides. Then ask whether the upper layer is selecting a lower contract or secretly redefining it.

That small discipline keeps the system legible. Process and checklists govern site work. Post types govern documents. Elements govern blocks. Business types rank opportunities across the system, and results send evidence back to the next process decision. Each layer can evolve because every rule has one home and every dependency travels in one direction.