How SEO methodology and authorship work

The problem: SEO bolted on after publication is archaeology. The platform’s approach is constructive: every page carries its search and trust signals by construction, emitted by the same pipeline that writes the content — so on-page SEO is a property of the system, not a checklist someone runs later.

Layer 1 — what every article page carries

FAQ with schema. Generation produces a five-question FAQ per article; the renderer emits it twice — as the visible accordion and as FAQPage JSON-LD with exactly one home in the head. Structured data and visible content come from the same source field, so they cannot drift apart. (A subtle lesson learned: the JSON-LD copy needs its own markdown-stripping path — structured data may not carry HTML.)
Internal links are the site engine’s native related-content engine over tag and category indexes — deliberately boring, deterministic machinery rather than LLM-invented links.
Host canonicalization — one canonical scheme and host per site, enforced at the edge with permanent redirects and HSTS; sitemaps and feeds are the site generator’s native output.

Layer 2 — the AI-readable layer

Every site in the fleet publishes its own llms.txt — brand, niche, author roster, recent articles — generated as a native output format of the site build and announced via a standard Link header. The accompanying robots policy is explicit and consistent: search allowed, AI-answering allowed, AI-training disallowed, with the major AI crawlers addressed by name. The platform practices what this portal preaches: machine consumers are a first-class audience on the content sites too.

Layer 3 — authorship as a system

Authorship is data, not decoration:

Each contract owns an author roster — name, position, bio, weight, avatar. Article bylines are drawn from it by weighted random selection, and the chosen author’s bio feeds the writing pipeline’s VOICE owner — the byline and the prose style are the same fact.
Each author has a profile page on the site with the full bio and a Person JSON-LD block — name, job title, bio, absolute-URI social links, portrait — the machine-readable E-E-A-T anchor.
The site renders the author consistently across five surfaces (index, profile, byline, footer, cards) from one data file.

Honest note: author selection is weight-based, not topic-aware — an author’s expertise does not yet steer which topics they byline; that is a known, documented candidate improvement rather than a hidden gap.

Layer 4 — the editorial rule above all mechanics

One rule outranks every optimization: promote only your own. It lives as the first line of every contract’s editorial standards, enforced mechanically by the brand-defense battery (details), and it shapes SEO strategy itself — the platform builds authority on its own brands’ expertise rather than borrowing it. Publish-path detectors (brand mis-serve, canonicalization drift, dead crawlers, rising 404s, title overflow) watch the fleet continuously, turning SEO regressions into alerts instead of quarterly surprises.

The trade-offs, honestly

Search-engine ping-on-publish (IndexNow) is written and wired but currently switched off pending its enablement decision — by the platform’s own hard rule, that means it is not called “deployed” here. Structured-data breadth is deliberately narrow (FAQ + Person, article schema left to the theme) — fewer schema types, each guaranteed consistent with visible content, over a wide surface nobody re-verifies.

See it in two minutes

View source on any fleet article: the FAQ JSON-LD, canonical link and author markup are right there; /llms.txt on the same domain shows the AI-readable layer.

Specs: SPEC-074 D5 (schema single-home), SPEC-096 (publish-path detectors + ping flag), SPEC-111 (brand defense), author-pool lifecycle specs.