Mythos

This 📝Runbook operates one recurring cycle of search-optimization bolstering: pull 📝Google Search Console data for a property, select memos ranking within 📝Striking Distance of page one, upgrade their structure and metadata, and verify position movement four weeks later. Each run consumes the freshest search-analytics window and produces edited memos plus a durable Run Log; the process improves itself through the Change Log at the bottom of this document.

Modes

Feedback loop: delayed — edits land today, but rankings settle over weeks, so a distinct Verify Mode exists to close that gap.

  • Run — execute one full bolstering pass: pull data, select candidates, edit memos, write the Run Log, state the verification date.
  • Verify — close out a prior run: re-pull the run's scope, record results in that run's Run Log, and propose process changes.

The operator names the mode when invoking this runbook. If a prior run's verification date has passed and its Run Log has no Verification Results filled, Verify takes precedence over starting a new run. A run is not complete until its Verify pass has been executed.

Parameters

Preconditions

  1. Tooling — the procedures below call two MCP surfaces: a Google Search Console MCP server (gsc_list_sites, gsc_search_analytics) and the MythOS MCP (read_memo, create_memo, update_memo_seo, update_memo_section). If either is missing, halt and hand the operator this exact list — do not improvise substitutes. A companion GSC MCP Setup Buildbook is planned; until it exists: install a Search Console MCP server authorized against PROPERTY (a Google Cloud project with the Search Console API enabled, credentialed via environment variables — never inline keys), and connect the MythOS MCP from mythos.one Settings → API. This runbook also assumes the content lives in a MythOS library — if yours does not, adapt the edit tools in Run Mode step 8 to your CMS and keep everything else.
  2. GSC access — gsc_list_sites returns PROPERTY. Failing: operator must grant Search Console access before any run.
  3. MythOS write access — get_context succeeds against LIBRARY.
  4. Canonical host check — pull gsc_search_analytics(site_url=PROPERTY, dimensions=["page"], filters=[{dimension:"page", operator:"contains", expression:PAGE_SCOPE}]) over SELECTION_WINDOW and scan for the same path appearing under two hosts (apex and www). Split pages have diluted position data: measure them with both variants summed, and surface persistent splits to the operator as a platform-level canonicalization task.
  5. Data hygiene screen committed — the synthetic-query filter (Run Mode step 3) is not optional; a baseline built on agent-pattern queries invalidates the run's measurement.

Procedure — Run Mode

  1. Pull selection data: gsc_search_analytics(site_url=PROPERTY, start_date=<today − SELECTION_WINDOW>, end_date=<today − 3 days>, dimensions=["page","query"], filters=[{dimension:"page", operator:"contains", expression:PAGE_SCOPE}], row_limit=5000). End the window three days early — recent GSC data is not final.
  2. Compute per-query positions and impressions-weighted position per page.
  3. Filter synthetic queries: drop queries matching agent patterns — keyword-stuffed strings that read as tool-and-domain mashups ("brand tool domain.com category descriptor"), near-duplicate phrasings of one string at volume, and verbatim long-tail sentences repeating across days. The test: would a person type this?
  4. Select candidates: queries inside BAND with surviving human impressions. Exclude brand-dominant queries — they rank by name, and content work cannot move them.
  5. Query-subject match check: for each candidate, ask whether the page's primary subject is the query's subject. Match → bolster in place. Mismatch (the query targets a concept living inside a page about something else) → create a dedicated memo for the concept instead; never bolt a section onto the wrong host.
  6. Assign interventions. Body restructure is the default and the lever: question-shaped headings, an atomic opening definition that directly answers the target query, and concrete figures in extractable bullets, per 📝Generative Engine Optimization (GEO) practice. Metadata rewrite is hygiene applied to every touched memo: seoTitle ≤70 chars and seoDescription ≤160 chars, keyword-front-loaded, in natural query language, describing only what the memo actually contains — the honesty rule. Metadata-only is never the sole intervention for a candidate expected to cross onto page one.
  7. Approval gate: present the plan as a table — memo, target query, baseline position, intervention — to the operator before executing any edit.
  8. Execute: body edits via update_memo_section (or update_memo for full restructures), metadata via update_memo_seo, batched.
  9. Write the Run Log per the format below, including the full scope table and the exact pull parameters from step 1.
  10. State the verification date: run date + VERIFY_DELAY.

Procedure — Verify Mode

  1. Read the target run's Run Log; recover its scope table, baseline positions, and pull parameters.
  2. Pull the current COMPARE_WINDOW (finalized data) with the same dimensions and filters; pull the same window one year prior only if seasonality is suspected.
  3. For each scoped memo, compare target-query position, clicks, and impressions, plus the page's impressions-weighted position, against baseline.
  4. Zero-impression check: any scoped page with zero impressions gets a URL inspection to distinguish deindexing from decay below the impression floor; record the finding either way.
  5. Re-screen for synthetic queries before interpreting movement — a demand-side collapse from vanished agent traffic is not a ranking loss.
  6. Record results in the Run Log's Verification Results section with one verdict per memo: page one, improved, flat, regressed, or dropped out.
  7. Write Learnings & Proposed Process Changes in the Run Log. On operator approval, apply accepted changes to this runbook and add a Change Log entry citing the Run Log as evidence.
  8. If results warrant outside review, produce a Report per the format below.

Run Log Format

Title: GSC-Driven SEO Bolstering — Run Log YYYY-MM-DD, dated to the run's edit date. Visibility: private. Tags: run-log and PROCESS_TAG. Run Logs are durable — never deleted; they are the process's empirical memory and the evidence the Change Log cites. Required sections:

  • Scope — table: memo ID, title, target query, baseline position, intervention applied.
  • Input Parameters — the exact GSC pull parameters (property, dates, dimensions, filters) so verification is reproducible.
  • Changes Shipped — what was edited, per memo.
  • Verification Results — filled by the Verify pass: comparison table and per-memo verdicts.
  • Learnings & Proposed Process Changes — what the run taught, and concrete proposals for this runbook.

Report Format

Produce when a run's verification results warrant stakeholder or advisor review. Title: GSC-Driven SEO Bolstering — {Month Year} Results or equivalent. Visibility: REPORT_VISIBILITY. Required sections: playbook summary, measurement windows, per-memo scorecard, what worked and what didn't, data-hygiene caveats, and open questions for the reviewer. Exemplar: "June 2026 SEO Bolstering Run — Playbook & Results" (unlisted; cited by title).

Troubleshooting

  • Previously-ranking page shows zero impressions at verification → deindexed, or decayed below the impression floor → run URL inspection; if dropped from the index, request reindexing and re-verify in two weeks; if merely decayed, treat as a regression and consider content depth.
  • Baseline queries read unnaturally or one string repeats at volume → synthetic agent traffic in the window → re-baseline with the synthetic filter applied; do not credit or blame edits for demand-side swings.
  • Target query ranks an unintended page → query-to-page mismatch or duplicate memos splitting signal → consolidate into the canonical memo (redirect plan first — never delete a URL with ranking traffic) or strengthen internal pointers.
  • Position regresses after a body restructure → possible subject dilution: the page's primary subject no longer matches the query → re-run the query-subject match check; spin the concept into a dedicated memo, or revert the body edit via the memo's version history.
  • Same path appears under two hosts in GSC → canonicalization split diluting rank signal → sum both variants for measurement and surface the redirect fix as a platform task.

Change Log

  • v2.2 — 2026-07-10 — Added the explicit feedback-loop characterization ("delayed") to Modes, following the template change that made Verify Mode conditional on delayed feedback rather than universal. Evidence: the Git Agent Protocol conversion showed recurrence and delayed feedback are orthogonal — that runbook ships Run-only; this one keeps the Run/Verify pair because rankings settle over weeks.
  • v2.1 — 2026-07-10 — Added the Tooling precondition: the runbook now names its required MCP surfaces (a Search Console MCP and the MythOS MCP) with halt-and-surface behavior when either is absent, and points to the planned GSC MCP Setup Buildbook. Evidence: operator review ahead of the first v2.0 cold run — an adopter without the GSC MCP would have hit a wall at step one. The Agent Runbook template gained the matching first-precondition-is-always-Tooling rule in the same pass.
  • v2.0 — 2026-07-10 — Converted to Agent Runbook format from the original two-track workflow, incorporating six evidence-based changes: (1) body restructure promoted to default intervention, metadata demoted to hygiene; (2) query-subject match check added to selection; (3) Run Log made a mandatory Run-mode output; (4) synthetic-query filter added to selection and verification; (5) zero-impression URL-inspection check added to verification; (6) canonical-host check added to preconditions. Evidence: Run Log 2026-06-12 — two of three body restructures crossed onto page one, all four index dropouts were metadata-only edits, and one baseline proved synthetic.
  • v1.0 — 2026-04-14 — Inaugural two-track workflow (metadata rewrites plus AEO cluster upgrades), created after the first run against the 2026-04-10 GSC export: 17 metadata rewrites, one canonical consolidation, nine cluster satellites upgraded.

Contexts

Created with 💜 by One Inc | Copyright 2026