How Do You Publish SEO-, AEO-, and GEO-Ready Content on FarmDash?

FarmDash's source-first publishing workflow for Markdown guides: frontmatter, answer-ready headings, evidence labels, internal links, schema, freshness, build validation, and machine-readable discovery.

TLDR: Write the strongest factual source first. FarmDash guides live in src/content/guides/, but publishing is more than dropping in Markdown: every guide should answer a real query directly, separate current evidence from speculation, link to the relevant FarmDash authority surface, survive schema extraction, and pass the same build/audit pipeline that ships the rest of the site. Do not optimize for keyword density or “AI scraping.” Optimize for clear entities, attributable claims, current evidence, useful structure, and machine-readable consistency.

What Are SEO, AEO, and GEO in This Context?

They overlap, but they are not identical.

SEO helps search engines discover, crawl, understand, and rank a page.

AEO makes the page easy to use as a direct answer: a clear question, a concise first answer, then enough supporting detail to justify it.

GEO makes the page useful to generative retrieval systems by keeping entities, evidence, terminology, and canonical machine surfaces consistent across the site.

For FarmDash, the same editorial discipline improves all three:

answer the query early;
define the entity precisely;
explain the evidence;
expose limitations;
link to primary/canonical FarmDash surfaces;
keep runtime capability claims synchronized with machine contracts.

A page that ranks but teaches an old product contract is not successful SEO.

What Is the Source-First Publishing Model?

The durable source for editorial guides is:

src/content/guides/<slug>.md

The build pipeline consumes those sources and creates browser/search delivery artifacts.

Do not make an important factual correction only in a generated HTML copy if the Markdown source still contains the old claim. The next generation pass can restore the defect.

The same principle applies beyond guides:

product FAQ truth belongs in its React/source data;
machine discovery truth belongs in llms.txt, ai.txt, OpenAPI, manifests, and their owning generators;
runtime capability truth belongs in the capability/status contract;
commercial prices and limits should come from their canonical configuration rather than prose constants.

What Makes a Strong FarmDash Guide?

A strong guide answers five questions.

1. What is the user actually trying to understand?

Use the search intent, not just the keyword.

Weak:

“Solana farming guide”

Stronger:

“How should an agent compare Solana DeFi opportunities without confusing cheap transactions with low economic risk?”

2. What is known now?

State current product or protocol facts only when the evidence supports them.

Prefer:

“FarmDash status currently marks this lifecycle stage preparation-only.”

over:

“FarmDash supports autonomous execution.”

if the latter collapses several unproven stages.

3. What is uncertain?

Unknown is a valid product state.

For airdrops, points, incentives, and token launches, distinguish:

confirmed current program;
historical program;
product usage with no confirmed reward;
speculation.

Do not convert investor funding, testnet activity, TVL, or an old points season into a current airdrop claim.

4. What action is safe to take from this information?

Research content should not silently grant execution authority.

A guide may explain a lifecycle such as:

research
→ quote
→ simulation
→ authorization
→ preparation
→ customer signing/broadcast
→ finality
→ reconciliation

but it should not compress that into “click and execute” unless the current runtime contract actually supports the complete path.

5. What is the canonical next source?

Link readers and agents to the strongest next authority:

/api/v1/agent/status for capability readiness;
/agents/openapi.yaml for API operations;
/.well-known/mcp.json for MCP capability metadata;
/methodology for scoring;
/fees and /api/v1/fees.json for commercial terms;
first-party protocol documentation for campaign rules.

Which Frontmatter Fields Matter?

A typical guide uses:

Field	Purpose
`title`	Human-readable H1 and search title input
`description`	Concise page summary
`author`	Article attribution
`date`	Original publication date
`lastUpdated`	Material review/update date
`type`	Content classification
`category`	Guide grouping
`difficulty`	Reader expectation
`tags`	Topical clustering
`related_protocol_slug`	Link to the relevant protocol/tracker when appropriate

Do not change lastUpdated for cosmetic punctuation. Use it when the substantive answer was reviewed or changed.

How Should You Structure an Answer-Ready Section?

A good pattern is:

## Does a FarmDash quote mean a swap executed?

No. A quote is pricing intelligence.

A firm wallet-bound quote must still pass the required simulation and
authorization lifecycle. On the compatibility EVM route, FarmDash then
returns transaction material for a customer-controlled wallet; FarmDash
does not broadcast that transaction.

Use /api/v1/agent/status for current readiness.

Why this works:

the first sentence answers the question;
the rest explains the state machine;
the language is quotable without becoming misleading;
the operational authority is linked.

How Should Trail Heat Be Described?

Use the current quantitative methodology.

Trail Heat is a research-prioritization heuristic, not an airdrop probability, expected return, safety score, or execution instruction.

The current live quantitative model uses:

40 raw points: TVL scale;
25: seven-day momentum;
15: chain diversification;
10: category outperformance.

The 90-point quantitative maximum is normalized to a 0–100 headline score.

Editorial notes are separate metadata and are excluded from the quantitative score.

A good sentence is:

“Trail Heat 84/100 means the protocol ranks highly under the current quantitative research heuristic; it does not mean an 84% chance of an airdrop.”

How Should FAQ JSON-LD Be Written?

FAQ schema must match visible page content.

Do not create a schema-only answer that the user cannot read on the page.

Good:

### Is x402 a swap router?

No. x402 is FarmDash's API payment/access layer. Liquidity routing and wallet
authority are separate systems.

Weak:

### x402
Payment stuff.

The question format improves direct-answer extraction, but the content still has to be true.

What Claims Should Trigger Extra Review?

Treat these as high-drift claims:

exact protocol TVL;
active points seasons;
“confirmed airdrop” labels;
token launch dates;
payout estimates;
exact API limits or prices;
route/provider availability;
tool counts;
chain execution parity;
“best price” or “best product” claims;
exact supported-client/install instructions.

For these, either link to a canonical source or phrase the answer so it remains true when the underlying value changes.

How Should External Protocol Claims Be Sourced?

Use a source hierarchy.

First-party protocol docs, terms, campaign pages, governance or official announcements.
Authoritative on-chain or protocol API evidence.
Reputable analytics for market context.
Community claims only as attributed, lower-confidence context.

Never make a current campaign claim solely because an old FarmDash guide says it was active.

What Is the Correct Build and Verification Flow?

The repository's production build performs more than Markdown rendering.

Use the repository scripts rather than assuming one generator is the whole deployment pipeline:

npm run typecheck
npm test -- --run tests/contentTrustContract.test.ts tests/answersClaimsTruth.test.ts
npm run audit:seo
npm run build

The full build also regenerates machine and static surfaces, runs release-contract checks, pre-renders routes, curates search surfaces, and audits generated assets.

When working in a multi-agent release train, avoid committing broad generated public/ churn unless the integration plan explicitly calls for it. Fix the source first, then regenerate deliberately at convergence.

How Should You Validate the Deployed Page?

After deployment, verify both humans and crawlers.

Check:

canonical URL;
title and meta description;
visible H1 and direct answer;
index/noindex state;
JSON-LD validity;
internal links;
no stale generated copy;
no contradictory machine files;
live /api/v1/agent/status where capability claims are involved.

Then fetch the public page without relying on the React client. If a crawler sees old text while the SPA shows new text, the SEO problem is not fixed.

What Is the FarmDash Machine-Content Consistency Rule?

A fact should not have five different meanings across:

homepage;
FAQ;
guide;
llms.txt;
ai.txt;
OpenAPI;
MCP;
OpenClaw;
status endpoint.

For dynamic operational facts, prefer one authority and make the other surfaces point back to it.

Examples:

Execution readiness: /api/v1/agent/status

Trail Heat calculation: quantitative methodology/data-quality contract

Commercial terms: runtime commercial config + machine fees contract/live 402

MCP install status: public mirror + npm registry readback

What Should You Avoid for GEO?

Do not write for an imaginary “LLM crawler.”

Avoid:

repetitive brand stuffing;
fake certainty;
keyword piles;
unsupported superlatives;
copied FAQ variants with slightly different facts;
hidden schema that contradicts visible content;
stale numbers presented without dates;
“according to FarmDash” loops with no underlying evidence.

Generative systems benefit from the same things users do: clear definitions, evidence, timestamps, boundaries, and consistent entities.

How Do You Strengthen an Existing Thin Guide?

Add substance, not adjectives.

A useful expansion usually adds:

definitions;
mechanism;
inputs and outputs;
risk model;
cost model;
lifecycle/state distinctions;
examples;
failure modes;
source hierarchy;
FAQs;
links to canonical runtime or methodology surfaces.

For example, “Solana is cheap” is thin.

A stronger section explains:

base fee;
priority fee;
compute budget;
associated token account creation;
rent;
protocol fee;
slippage;
failed attempts;
bridge cost;
finality/reconciliation.

That is better for readers, search engines, and answer engines because it contains real explanatory structure.

Frequently Asked Questions

Does a question heading automatically make a page rank?

No. It improves answer extraction, but relevance, authority, usefulness, crawlability, internal linking, and source quality still matter.

Should every guide include exact current TVL and airdrop values?

No. Include them only when they materially help the answer and can be kept current. Otherwise describe the mechanism and link to a live data source.

Is Trail Heat an airdrop probability?

No. It is a quantitative research-prioritization heuristic.

Should generated HTML be edited directly?

Only when that static file is itself the owned canonical source or during an explicitly controlled repair. For generated guide artifacts, fix the Markdown/source generator first.

Can SEO copy override runtime product truth?

No. Runtime and machine contracts win. Editorial content should explain them, not redefine them.