The SEO playbook for content that ranks
Choose the page job with a post type, assemble it from rule-bound elements, and run it through an ordered process that decides what ships and proves what worked.
Why briefs fail and systems work
A brief can describe a desired page, but description is interpretable. As volume grows, unwritten rules become inconsistent choices, reviews become subjective, and each new contributor inherits less context than the last.
- ✓One instruction, many interpretations — ‘include a useful comparison’ does not define rows, evidence, decision criteria, exclusions, or what makes the comparison complete.
- ✓Drift compounds — by article 40, teams review against recent examples instead of the original standard, so accidents quietly become precedent.
- ✓AI fills every blank — an agent does not stop at ambiguity; it chooses a plausible structure, tone, claim, or CTA and presents the choice confidently.
- ✓Typed rules make review observable — required fields, ranges, order, source rules, and done-when conditions turn taste-based feedback into a pass, fail, or documented exception.
What goes wrong without a content system
A content brief is prose. Prose is useful for context, but it is a weak storage format for repeatable decisions because every reader must translate it back into structure.
“Write the definitive guide, add a comparison, cover objections, and make it authoritative.” Each word sounds sensible. None specifies the opening answer, comparison criteria, source threshold, section order, acceptable length, or release test.
One writer produces a long narrative. Another builds a list. A third copies the current top-ranking page. All can claim they followed the brief because the brief described an ambition, not a contract.
Editors then review against personal taste. Feedback such as “make it punchier” or “add more depth” fixes a draft without defining the rule future drafts should follow. By article 40, nobody can say whether the newest page matches the intended standard or merely resembles the last accepted page.
AI agents amplify the failure. They confidently supply a missing comparison axis, claim, heading, or conversion step. Fluent output can hide that the specification never authorized the choice.
The remedy is not a longer universal brief. It is a system that separates stable rules from page-specific inputs. Stable rules belong to post types, elements, and process. The assignment still carries its audience, topic, query evidence, product facts, sources, and commercial constraints.
The three layers: post types, elements, process
Each layer answers a different class of question. Keeping them separate makes the rules reusable; connecting them makes the output coherent.
A post type defines what kind of page this is and what job it must complete. A how-to enables a task; a comparison supports a choice; a glossary term resolves meaning. The type controls the expected reader state, required evidence, section sequence, and next action.
Choose it before drafting because format follows intent. If a page tries to define, compare, teach a procedure, and close a sale as equal priorities, each job weakens the others.
Elements are typed content blocks with exact rules. A direct answer, definition box, comparison table, warning, FAQ, source block, and CTA are not decorations. Each performs a known reader and machine-readable function.
An element specification defines why the block exists before stating placement, fields, length, evidence, accessibility, schema, and failure conditions. That makes it testable and reusable across many post types.
Process is the ordered set of decisions determining which pages get built, in what order, with which inputs, and under whose approval. It begins before writing with goals, access, technical baselines, prompt research, competitors, and information architecture.
It ends after drafting with quality gates, publication evidence, measurement windows, and a next-decision rule. Process prevents a well-specified page from being produced for the wrong opportunity or shipped without proof.
Six pillars of the playbook
The listing is a route into the method, not the method itself. Start with the decision blocking your team today.
54 specifications. Choose the document shape matching the reader's task, from ultimate guides and comparisons to product pages, use-case pages, and case studies.
For: strategists, editors, and anyone deciding what page should exist.
74 specifications. Assemble pages from typed blocks with rules for purpose, position, fields, evidence, schema, accessibility, and QA.
For: writers, designers, developers, and AI-agent operators.
18 operating models. Prioritize formats and topics for ecommerce, SaaS, marketplaces, local services, media and affiliate publishers, B2B services, healthcare, finance, agencies, manufacturing, travel, education, real estate, automotive, legal, nonprofits, job boards and events.
For: owners and growth leads translating a generic playbook into commercial priorities.
18 phases plus 13 checklists. Move from goals and data access through technical readiness, research, competitive gaps, information architecture, and pre-publish QA.
For: agencies, content leads, and teams needing ownership and repeatability.
5 guides. Understand why systems outperform isolated briefs, how consistency scales, how structure signals trust, and how humans and retrieval systems share a page.
For: leaders setting standards and reviewers deciding when an exception is justified.
1 measurement hub. Separate visibility, selection, engagement, and business outcomes, then connect each movement to a time window and next decision.
For: stakeholders asking whether the work changed anything that matters.
Where to start
You do not need to read the playbook in order. Choose the route matching your role, then follow the joins to the other layers only when useful.
If you are planning the portfolio, begin with Post Types and Business Types. If you are repairing one underperforming page, identify its post type, audit its elements, and use Results to define recovery. If you are building an agent workflow, start with Elements for output constraints and Process for tool access, review authority, and stop conditions.
The router is role-based because a large library becomes useful only when a first-time reader can make one confident move. Every guide then exposes the adjacent decision: a business type points to priority post types; a post type names ordered elements; an element names compatible post types; and the process connects the finished page to measurement.
What a specification gives you
The goal is not to make every page identical. It is to make intentional differences visible and accidental differences less likely.
Every rule starts with the reason it exists. A direct answer belongs near the opening because a reader or retrieval system needs a self-contained response before supporting detail. A warning appears before the risky action because a warning delivered afterward cannot prevent the mistake.
Explaining the reason lets an editor judge unusual cases. Without it, a rule becomes ritual: contributors reproduce the shape even when the shape no longer serves the reader.
A typed block names the information it must contain. A comparison needs decision criteria, comparable options, evidence, qualifications, and a conclusion tied to reader needs. “Add a table” names only a visual format.
Fields let a writer gather missing inputs before drafting and let an agent stop when required evidence is absent instead of inventing a plausible value.
“Concise” means different things to different people. A word band, maximum number of takeaways, or defined table scope gives the reviewer an observable boundary. The range should protect the element's function, not force padding or arbitrary uniformity.
When a page needs to break a range, the owner records why. That exception can later become evidence for changing the specification instead of disappearing into editorial memory.
A useful acceptance condition can be observed: every material claim maps to a source; every internal route resolves; the direct answer stands alone; the mobile table does not create page-level overflow; visible FAQ answers match structured data.
This does not eliminate expert review. It reserves expert attention for truth, strategy, nuance, and exceptions instead of spending it on missing fields and preventable formatting defects.
The resulting system still leaves room for voice, examples, original research, argument, and design. It simply places those creative choices inside a declared page job, gives repeated components stable contracts, and records the path from opportunity to outcome. Consistency then means the same standard of reasoning, not the same sentences or layout on every URL.
A playbook AI agents can execute
A content system was always useful for people. It became necessary the moment AI agents started writing at volume, because an agent will fill any gap a brief leaves — confidently, plausibly, and invisibly.
Give an agent a topic and a keyword and it has to invent the page: which sections exist, how deep each goes, what evidence is required, where the answer belongs. Every one of those guesses is a place two articles drift apart.
A human writer at least knows what they don't know and asks. An agent does not stop — it produces something reasonable-looking and moves on. That is why underspecification is more dangerous with agents, not less.
The post type names the job and fixes the section order. The element library defines every block it may use, with required fields, length bands, and the exact position each one occupies. The checklist defines when the work is finished.
Nothing is left to interpretation, so nothing has to be invented. The agent executes a plan instead of authoring one.
Typed fields make missing inputs detectable. If a comparison needs a verified price and no source exists, the agent can halt and flag the gap rather than producing a confident number nobody checked.
This is the difference between an agent that scales your standards and one that scales your errors.
The same specification governs article 1 and article 400, a glossary term and a category page. Because each type declares its own structure, an agent producing forty different page types still produces one consistent standard of reasoning.
Review effort moves where it belongs: to truth, strategy, and nuance, instead of to missing sections and preventable formatting defects.
This is why the playbook is written as a specification rather than as advice. Every page in it is precise enough that a copywriter and an AI agent working from the same document produce the same structure — and precise enough to hand directly to SEO agents or to your own tooling through the AmICited MCP server. Not a prompt that hopes for good output: an exact execution of a declared SEO strategy.
The playbook by the numbers
Library counts were verified from the content tree on August 27, 2026. Outcome figures come from published case studies and are not guarantees.
These outcomes combine strategy, execution, market conditions, tools, and time; the specification alone does not cause them. The narrower claim is useful: a governed content system makes sustained production possible, keeps the rationale inspectable, and gives measurement a stable object to evaluate. That is a prerequisite for learning at scale, not a promise of a multiplier.
How the playbook works with AmICited
A method without observations becomes opinion. A dashboard without a method becomes motion without a decision. Each is most useful when it keeps its own job.
You can use the method with another toolset because its core units are plain operational decisions. AmICited shortens the distance between those decisions and the evidence: which prompts are missing your brand, which competitors are cited, which pages need work, what was published, and how visibility changes afterward.
SEO Playbook FAQ
Yes. The playbook is written as an operational specification: post types define the job and required structure, elements define exact block-level rules, and process pages define inputs, owners, order, and acceptance checks. Product behavior and page counts can change, so each guide should still be checked against the current site before production.
Yes. The playbook is public and usable without an AmICited account. You can adopt one post type, element, or checklist at a time, copy the decision logic into your own workflow, and measure results with your existing tools. AmICited adds instrumentation and automation; it is not a condition of using the method.
They can. The specifications give an AI agent explicit fields, order, constraints, evidence requirements, and pass conditions instead of asking it to infer quality from a prose brief. A human still owns strategy, claims, exceptions, and release approval, while deterministic checks should be automated wherever possible.
A content brief describes one assignment in prose. This playbook defines reusable content types, typed elements, joins between them, and a governed production process. A brief can still carry query research and page-specific evidence, but it inherits stable rules instead of rewriting or improvising them for every page.
Turn the next content idea into a specification
Free check · 7-day trial · no credit card