workflowseogeosignalsUpdated 2026-11-03

SEO GEO Radar Workflow

SEO, GEO, and AEO radar promotes only evidence that changes search visibility strategy or implementation guidance.

The SEO GEO radar tracks AI search optimization and traditional SEO frontier. Source: retired seo-geo-radar automation, 2026-05-31

Routing

Use this workflow for search, answer-engine, and crawler behavior. Use Content Pipeline Workflow for social posts and Frontend Frontier Radar Workflow for frontend implementation trends.

Trigger

  • Its scheduled automation was retired on 2026-11-03 (never ran); run the workflow on request.
  • Manual request after official crawler/platform changes, competitive search teardown, or a public-site launch.
  • Before shipping changes to public docs, llms.txt, sitemap, JSON-LD, or content architecture.
  • After a scaled page launch, indexation shift, traffic spike/drop, or Search Console manual action.

Inputs

  • SEO + GEO and relevant SEO/GEO skill docs.
  • Official crawler docs for Googlebot, Bingbot, GPTBot, ChatGPT-User, ClaudeBot, PerplexityBot, and related AI agents.
  • Google Search Central, Ahrefs, Semrush, Search Engine Land, GitHub tools, reproducible studies, and competitive teardowns.
  • Sources published or materially updated in the last 30 days unless Kevin asked for a historical review.
  • For programmatic SEO claims, the current first-party domain state: raw HTTP, rendered pages, robots.txt, child sitemaps, status/canonical/index policy, example page families, Search Console evidence when authorized, and removals.

Promotion criteria

Promote only sources that add at least one of:

  • a scoring or measurement framework
  • deployable implementation: schema, config, crawler handling, test harness, or code
  • official platform behavior
  • reproducible data study
  • firsthand competitive teardown with concrete methodology
  • a post-launch or failure outcome that changes page-generation, index-admission, maintenance, consolidation, or removal policy

Keep anecdotal claims as evidence, then split their reusable method from their efficacy claim. A useful architecture may be promoted while self-reported traffic, causality, or safety remains unverified or contradicted.

Runbook

  1. Read SEO + GEO and the current playbook before scanning.
  2. Collect candidate sources and record exact publish/update dates.
  3. Classify each candidate as promoted, rejected as hype, watchlist, or no-op.
  4. For promoted items, name the implementation or strategy change.
  5. Update SEO + GEO only when guidance changes.
  6. Propose Dedalus or portfolio-site tasks only when the change is concrete and testable.

Programmatic SEO replay lane

  1. Expand the complete article/thread and every named example before judging it.
  2. Capture current robots.txt, sitemap index and child sitemap counts, raw response metadata, and representative rendered pages from each page type.
  3. Separate generation architecture, page utility, reported outcome, current operating state, and platform policy into distinct claims.
  4. Compare the claim with current first-party Google policy and Manual Actions guidance; never infer safety from early traffic or partial indexation.
  5. Interrogate the executable programmatic-seo skill for taxonomy, typed schema, validator, renderer, similarity, raw/rendered proof, staged index admission, cohort metrics, maintenance owner, and removal/recovery path.
  6. Preserve later contradiction and failure evidence. A 60-day success report can be useful and still fail as a durable operating rule.

Credentialed automation lane

Search Console, keyword providers, a warehouse, and CMS access make an SEO agent powerful because they join observation to publication. They also combine several trust domains. Keep provider credentials outside prompts and committed .env files; use a scoped secret store or proxy, minimum read scopes by default, named site/property/account bindings, expiry/revocation, cost limits, and request logs. Separate these stages:

  1. fetch and normalize source data with completeness/freshness receipts;
  2. analyze and draft with citations, query/page/date scope, and uncertainty;
  3. preview sitemap, metadata, internal-link, schema, or content changes;
  4. approve the exact diff and target;
  5. publish or submit through an idempotent, rollback-capable write boundary;
  6. measure crawl, indexation, visibility, qualified traffic, conversion, and later manual-action/removal outcomes.

Google's current official Googlebot documentation states a 2 MB uncompressed fetch limit for supported file types and 64 MB for PDFs. The crawler stops the fetch at the limit and considers the bytes already received; it does not prove that every fact before the boundary is indexed or that a page past the boundary is wholly rejected. Measure representative raw responses, ensure critical metadata/content is early and server-readable, and keep HTML far below the cap without turning one crawler limit into a generic frontend architecture rule. Source: Google Search Central, reviewed 2026-08-12

For AI-generated or scaled content, keep the bar people-first: accuracy, quality, relevance, original value, and clear ownership. Generation assistance is not itself disqualifying, but publishing many unoriginal pages primarily to manipulate rankings is scaled-content abuse. Treat "free high-authority backlink," domain-authority, fast-indexation, and short-window traffic claims as testable acquisition hypotheses—not durable rules—until dated Search Console, referral, conversion, counterfactual, and later spam/manual-action evidence are available. Source: Google Search Central guidance on generative AI content and spam policies, reviewed 2026-08-12

Saved GEO audits, AutoResearch copy loops, OpenSEO, keyword/entity/schema tips, backlink budgets, and blanket warnings about programmatic SEO are all retained as candidate methods. None is a universal rule. Reproduce them against an owned site cohort with the exact query set, crawl/render/index state, page family, content and schema diff, link source and commercial relationship, spend, time window, Search Console and analytics exports, qualified conversion definition, control or counterfactual, and later spam/manual-action/removal evidence. Repository openness or a large star count helps inspection; it does not prove ranking efficacy, scraping permission, data completeness, or safe publication. The geo-seo-claude source at commit ca6adbec and OpenSEO product signal stay available for bounded evaluation, while official search policy and owned first-party measurements govern promotion. Source: X 2031050007957184934, 2036461256006357409, 2031934727096320474, 2031347339936329992, 2031982527997510046, 2078737738493301060; zubair-trabzada/geo-seo-claude@ca6adbec; reviewed 2026-08-12

Output

Write outputs/<YYYY-MM-DD>/seo-geo-radar/<agent>.md with promoted sources, rejected hype, playbook updates needed, and one optional implementation recommendation. A no-op run should still list sources checked and rejected.

Validation

Every promoted item needs a dated source link and a reason tied to crawler behavior, ranking visibility, entity strategy, schema, or measurement. For scaled-page claims, proof must also state page-family scope, source of metrics, rollout window, current domain state, and whether later manual-action/removal evidence exists. Missing efficacy proof blocks the efficacy claim, not a separately verified architecture lesson.

Run Contract

This workflow follows Wiki Brain Operating Model: name the sources, write output or no-op proof, promote only durable facts, update state only when the run really completed, refresh generated surfaces when durable pages or skills change, and log user-visible work.

Timeline

Related Pages

Writing and Content SkillsWriting and Content SkillsWriting and Content SkillsWiki Brain Operating ModelGenerated Surface Contract

3 pages link here

Frontend Frontier Radar WorkflowWorkflowsSignal Radar CadenceHEARTBEATSignal Radar WorkflowWorkflows