Each pass audits one finalized 28-day window of a site's 📝Google Search Console data. It finds queries ranking on page 2 (positions 11–20) that have real impressions but almost no clicks, maps each to the page that ranks, audits those pages, and writes the exact fix for each. Results go to a dashboard, a MythOS worklist, or both, with a summary for the operator. It is built for anyone with Search Console access and is meant to run weekly. Status: prototype. It was converted from a one-shot audit prompt on 2026-10-09 and has not yet run as a scheduled loop.

Purpose

The cheapest SEO wins are queries Google already considers relevant but places just below the first page of results. This loop surfaces them each pass, ranks them by click upside rather than raw volume, and states the exact change for each page: before-and-after title tags, the H2 to add, and which URL redirects into which. It reports only and never edits the site, so whoever owns the pages applies the fixes. Any agent with web access can run it (Claude Code, the Claude desktop app, or a comparable MCP client). A scheduler only needs to point that agent at this memo and run one pass. Every step needs tools, so it cannot run as a single tool-less model call.

Prerequisites

• Parameters — copy the table below and fill in your values. Values marked "set by first pass" are discovered on the first run and recorded.
• Search Console access — one of two paths:
• • Preferred: a Search Console MCP server that exposes search analytics by query and page, such as the read-only 📝Google Search Console MCP. It runs headless, so the loop can run unattended. That server is not yet published for public install. Until it is, use any equivalent Search Console MCP or the Chrome path.
  • Fallback: Chrome with the Claude in Chrome extension, signed into a Google account that has access to the property. It needs the machine awake and Chrome open.
• Page fetching — any web-fetch tool, to read each ranking page's title, meta description, and headings.
• Dashboard publishing (for OUTPUT dashboard) — a way to publish one HTML page to a stable URL. In Claude, that is the Artifact tool.
• MythOS MCP (for OUTPUT worklist) — 📝MythOS MCP connects a MythOS library to your AI client. To install it, add https://mythos.one/api/mcp as a connector in Claude (claude.ai → Customize → Connectors) and sign in, or generate an API key at mythos.one Settings → API for other clients. Without it, choose OUTPUT dashboard.
• Mail connector (optional) — for example Gmail, to draft the summary. Without one, the summary is delivered in the pass's receipt.
• Trigger — a weekly schedule whose only instruction is "read this memo and run one pass": a scheduled task, /loop, cron, or a MythOS Loop handed to an external runner.

The Loop

Step 1 — Discover the pass

• Compute the window: its end is three calendar days before today, in the property's reporting time zone (Pacific), and its start is WINDOW days earlier.
• Read the prior state from the output this loop maintains: the dashboard's embedded audit-data block at DASHBOARD_URL, or the "Last audited window" line in WORKLIST_MEMO.
• If the prior window end equals the computed end, the window has already been audited. Report "no new window; last audited <date>" and stop.
• Otherwise, keep the prior ranked rows (from the dashboard block, when present) as PRIOR for the week-over-week delta. On a first pass, PRIOR is empty.

Step 2 — Connect to Search Console

• MCP path: list the accessible sites and confirm PROPERTY is among them. If it is not, halt and report missing access.
• Chrome path (only without a Search Console MCP): load the Chrome tools in one ToolSearch call (tabs_context_mcp, navigate, computer, find, javascript_tool, browser_batch), check the tab context, and open a new tab.
• Find the account index by testing https://search.google.com/u/N/search-console?resource_id= followed by URL-encoded PROPERTY, for N = 0, 1, 2 and so on. Start from GOOGLE_ACCOUNT_INDEX when it is set, and record the index if it was unset.

Step 3 — Pull the window's query data

• MCP path: query search analytics for PROPERTY over the window, grouped by query. When PAGE_SCOPE is set, filter to pages containing it. Request enough rows to cover everything at MIN_IMPRESSIONS or above.
• Chrome path: open /u/N/search-console/performance/search-analytics for the property with num_of_days=28&breakdown=query&metrics=CLICKS%2CIMPRESSIONS%2CCTR%2CPOSITION. When PAGE_SCOPE is set, add a page filter. Then set "Rows per page" to 500, following the dropdown convention below, and extract the rows with the snippet in Conventions.
• Count the parsed rows before trusting anything. If the Chrome path yields only 10, the dropdown didn't take: retry it once, then proceed with what parsed and say so.
• Record site totals (clicks, impressions, CTR, average position) from the same pull.

Step 4 — Screen and rank

• When SYNTHETIC_SCREEN is on, drop matching query families and list what was dropped.
• Filter to BAND with at least MIN_IMPRESSIONS impressions.
• Score each row as impressions × (TARGET_CTR − CTR), where CTR is a fraction, and floor the score at 0. Sort by score and keep the top TOP_N.
• Build SNIPPET_LIST and FAR_LIST from the same pull.
• When PRIOR exists, compute each query's change in impressions, position, and score, and mark queries that are new to or gone from the band.

Step 5 — Map queries to ranking pages

• For each of the top PAGE_LOOKUP_N queries, pull the page breakdown with an exact-match query filter. On the MCP path, group by page and filter the query with equals. On the Chrome path, append &breakdown=page&query=! plus the URL-encoded exact query, and slice the extraction from Top pages. Batch the navigate-and-extract pairs into browser_batch calls.
• When more than one URL from the site ranks for a query, flag it as cannibalization. Name each URL with its position, pick the winner (the URL already ranking best, not the one that "should" win by topic), and plan 301 redirects from the others into it.

Step 6 — Audit the ranking pages

• For each distinct ranking URL, fetch the page and record verbatim its title tag, meta description, H1, and full H2 list. If the page is a MythOS memo and the MythOS MCP is connected, also read the memo and record its SEO title and description.
• Check each page against its queries:
• • Is the query phrase in the title, and in the H1?
  • Intent: does the page answer what was asked, or a neighbouring question? ("Why does X take so long" ranking for "how long does X take" is a mismatch.)
  • Spelling and word form: one word vs. two, singular vs. plural.
  • Is the meta description missing, leaving Google to write the snippet?
  • Is the metadata a leftover placeholder, such as "Home" or a bare product name?
• Give each row one diagnosis: Cannibalization, Metadata, Intent mismatch, Content depth, or Spelling.

Step 7 — Write the fixes

• Order fixes by summed score. For each, state what is wrong, list the affected queries with impressions and position, and give the exact change: the before and after title tag, the H2 to add and where it goes, and which URL 301s into which.
• Where the on-page work is already done and the real limit is content depth or domain authority, say so plainly. Never pad the list with invented tweaks; five real fixes beat ten padded ones.

Step 8 — Publish the dashboard

• Run this step only when OUTPUT is dashboard or both.
• Build one HTML page:
• • A stat strip: estimated clicks in play, queries in band, band impressions, and site totals.
  • The ranked table: query, ranking page, impressions, clicks, position, estimated gain, diagnosis chip, and the week-over-week delta column.
  • A per-row position scale with a page-one marker.
  • The ordered fixes.
  • The SNIPPET_LIST and FAR_LIST side lists.
  • Notes that the 0.06 target CTR is a planning number, not a forecast, and that the band is not exhaustive.
• Embed this pass's data as <script type="application/json" id="audit-data"> with windowStart, windowEnd, property, pageScope, the ranked rows, both side lists, and the site totals.
• Republish to DASHBOARD_URL when it is set. Otherwise publish new and record the URL as DASHBOARD_URL.

Step 9 — Write the worklist

• Run this step only when OUTPUT is worklist or both and the MythOS MCP is connected. If it isn't connected, skip this step and say so in the receipt, with the install pointer from Prerequisites.
• First pass (WORKLIST_MEMO unset): create a private memo in MYTHOS_LIBRARY titled Page-2 SEO Worklist — {SITE}.
• • If that library has a template named "Worklist Memo Template", pass its id. Otherwise build this shape:
  • A preamble naming the site, this audit as the seed source, and the seed date, followed by a Last audited window: {windowStart} → {windowEnd} line.
  • The agent-instructions callout: completed items move from Working to Completed with an ISO date, and Completed keeps the 25 most recent.
  • The sections ## Backlog, ## Working, and ## Completed, then # Contexts with [#worklist](/tag/worklist).
  • Record the new memo's path as WORKLIST_MEMO.
• Each fix becomes one checkbox line: - [ ] {exact change} on {page URL} — {diagnosis}; {queries with impressions and position}; est. +{n} clicks/mo. The five highest-scoring fixes go to Working and the rest to Backlog. SNIPPET_LIST fixes join Backlog, and FAR_LIST is not itemized.
• Later passes: update the "Last audited window" line. An open item is identified by page URL plus diagnosis, so refresh its numbers in place instead of adding a duplicate. Add new fixes to Backlog. Never move or reword an item the owner has already moved, edited, or completed. When a fix's queries have left the band, append — out of band as of {windowEnd} to the item rather than deleting it.
• Edit section by section, never by rewriting the whole memo.

Step 10 — Send the summary

• Write a plain-text summary of at most 400 words with no marketing tone: the top three opportunities with estimated monthly gain, the specific fix for each, notable week-over-week movement, and the dashboard and worklist links.
• Apply EMAIL_MODE: create a draft to REPORT_EMAIL, send it to REPORT_EMAIL, or skip email. Never address anyone else. Without a mail connector, put the summary in the receipt.

Step 11 — Close-out receipt

• Report the window audited, the access path used (MCP or Chrome), rows parsed, the synthetic queries dropped, the queries in band, the cannibalization flags, the number of fixes, the dashboard URL, the worklist path with items added and refreshed, the email status, and any parameters recorded.
• Name every step that degraded, such as a partial row parse, an unfetchable page, a skipped page lookup, or a missing connector, rather than reporting a clean pass.

Conventions

• Runtime: the MCP path can run headless as a scheduled routine. The Chrome path needs a desktop session, Chrome, and an awake machine, and fails on a closed laptop. Prefer the MCP for unattended runs.
• Recording parameters: the loop's only writes to its own instructions are values marked "set by first pass". Keep your filled-in parameter table wherever your copy of this runbook lives, and record those values there.
• Rows-per-page dropdown (Chrome): the first click usually only starts the open animation. Use find with "the option labelled 500 in the rows-per-page dropdown menu", click that ref, wait 10 seconds, and then check the row count.
• Extraction (Chrome): the table renders as tab-delimited text. Never return anything containing a URL query string from javascript_tool, because a security guard blocks the result and the call is lost.

const t=document.body.innerText;
const seg=t.slice(t.indexOf('Top queries'));
const re=/^(.+?)\t([\d,]+)\t([\d,]+)\t([\d.]+)%\t([\d.]+)$/gm;
const rows=[];let m;
while((m=re.exec(seg)))rows.push({q:m[1],c:+m[2].replace(/,/g,''),i:+m[3].replace(/,/g,''),ctr:+m[4],p:+m[5]});

• Ranking rule: sort by click upside, never by raw impressions. A 500-impression query at position 12 outranks a 3,000-impression query at position 28.
• Coverage: Search Console anonymizes low-volume queries, and its UI tables cap at 1,000 rows, so the band is real but never exhaustive.
• Window: 28 days. Shorter windows are noisy, and the three-month view smears over mid-period changes.
• Patience: position movement from an on-page change typically appears in two to four weeks. The week-over-week column is for watching, not a prompt to re-edit a page every week.
• No unprompted questions: a pass makes its judgment calls, states each assumption in the receipt, and keeps going. It halts only on missing access.

Contexts

• 🏷️#runbook
• 🏷️#seo