Geo Bulk Processor

\r \r

Overview\r

\r geo-bulk-processor is a GEO (Generative Engine Optimization) bulk processing orchestrator designed for large sites and content libraries. It helps an agent:\r

• Design and run batch optimization pipelines over thousands of pages or documents.\r
• Standardize templates and patterns for repeated page types.\r
• Track progress, quality, and rollout phases instead of treating each page as an isolated “single-shot” task.\r \r Use this skill when the user:\r
• Manages a large website, multi-language site, or content library.\r
• Wants to bulk retrofit existing pages for GEO readiness, AI citations, or structured data.\r
• Provides sitemaps, URL lists, spreadsheets, or exports from CMS/analytics tools.\r
• Needs a repeatable, scalable workflow instead of one-off page edits.\r \r This skill focuses on planning, orchestration, and consistency. It does not tie you to any specific GEO framework, but is optimized to work well with the family of geo-* skills (e.g. content optimizers, schema generators, local optimizers).\r \r

When to use this skill\r

\r Always consider using geo-bulk-processor when:\r

• The user mentions “bulk”, “batch”, “mass update”, “large site”, “thousands of pages”, “entire catalog”, “all blog posts”, or similar language.\r
• The user shares CSV/Excel exports, sitemaps, URL lists, or folders of content files.\r
• The user wants to apply similar GEO strategies across many items (e.g., all product pages, all location pages, all support articles).\r
• The task obviously cannot be solved efficiently by optimizing a single page at a time.\r \r If the request is clearly about one page or a very small number of pages (e.g., “fix GEO for this single article”), prefer the more focused single-page GEO skills instead of this bulk processor.\r \r

High-level workflow\r

\r When this skill is invoked, follow this structured workflow:\r \r

1. Clarify the bulk goal\r
   • Identify the primary GEO goals (e.g., AI citations for specific queries, better structured data, consistent FAQ blocks, improved internal linking).\r
   • Ask what content universe is in scope (full site, one section, specific content types, language variants, etc.).\r
   • Ask about constraints (timelines, systems, headcount, tech stack, allowed file formats, risk tolerance).\r \r
2. Ingest and profile the corpus\r
   • Accept inputs such as:\r
     • URL lists or sitemaps (XML, CSV, plain text).\r
     • Content exports from CMS (CSV, JSON, Markdown/HTML files).\r
     • Analytics exports (top pages, landing pages, long-tail queries).\r
   • Build a lightweight inventory summary:\r
     • Number of items by content type, language, directory, or template.\r
     • Obvious clusters (e.g., /blog/, /product/, /docs/, /locations/).\r
     • Known GEO gaps (missing schema, thin pages, duplicated structures).\r \r
3. Define content clusters and page types\r
   • Group content into clusters that can share the same optimization strategy:\r
     • By URL pattern, content type, template ID, language, or topic.\r
   • For each cluster, define:\r
     • A page-type definition (what the pages are, who they serve, business role).\r
     • The GEO opportunities specific to that cluster.\r
     • Risks and special constraints (e.g., legal wording, regulated content).\r \r
4. Design bulk GEO pipelines\r
   • For each cluster, design a pipeline describing:\r
     • Inputs (fields from the CMS/CSV, existing content fields, metadata).\r
     • Transformations (rewrites, new sections, schema generation, FAQ extraction).\r
     • External skills/tools to call (e.g., schema generators, content optimizers).\r
     • Outputs (updated HTML/Markdown, JSON fields, CSV columns, migration specs).\r
   • Capture pipelines in a structured, reusable format, using the guidance in references/bulk_pipelines.md.\r \r
5. Create reusable templates and patterns\r
   • For each major page type, define:\r
     • A content skeleton (sections, headings, FAQs, schema blocks).\r
     • Variable slots tied to data fields (e.g., product name, city, category).\r
     • Style and tone expectations (aligned with GEO and brand constraints).\r
   • Make these templates explicit so they can be applied programmatically to many items.\r \r
6. Plan execution and rollout\r
   • Propose phased rollout:\r
     • Pilot set → expansion → full coverage.\r
   • For each phase, specify:\r
     • Sample size, selection criteria, and evaluation plan.\r
     • Success metrics (GEO readiness scores, AI citation coverage, traffic proxies).\r
     • Feedback loop and how to adjust templates/pipelines between phases.\r \r
7. Generate concrete artifacts\r
   • Depending on user needs, generate:\r
     • A master plan document summarizing clusters, pipelines, and rollout.\r
     • CSV/JSON specs for engineers or operators to implement changes.\r
     • Example before/after content and schema for each major page type.\r
   • Use scripts/geo_bulk_pipeline.py conceptually as a helper reference: it describes how to represent content items, clusters, and pipelines in code or data. You do not have to execute it, but you may mirror its structures.\r \r
8. Quality assurance and risk management\r
   • Recommend:\r
     • Sampling and manual review before full rollout.\r
     • Regression checks for critical pages (homepage, top products, legal pages).\r
     • Monitoring plan for GEO and traffic indicators after deployment.\r \r

Input formats and expectations\r

\r Typical inputs for this skill:\r

• URL lists / sitemaps\r
  • Plain-text lists of URLs.\r
  • XML sitemaps (possibly multiple).\r
• Spreadsheets / tables\r
  • CSV or Excel exports listing URLs, titles, categories, traffic, etc.\r
• Content exports\r
  • Folders of HTML/Markdown files.\r
  • CMS exports with JSON per document.\r \r When possible, normalize these into a tabular or record-based view:\r
• One row or record per content item.\r
• Columns / fields for URL, path, language, category, template, and any key metrics.\r \r If files are not already in a structured format, design and describe a simple manifest format that the user’s team can produce (for example, a CSV with id,url,type,cluster,language columns).\r \r

Output expectations\r

\r Unless the user asks for something highly specific, structure your main outputs as:\r \r

1. High-level GEO bulk strategy\r
   • Clear description of scope, goals, and constraints.\r
   • Overview of clusters, page types, and priorities.\r \r
2. Cluster-by-cluster plan\r
   • For each cluster:\r
     • Description and rationale.\r
     • Proposed pipeline steps and external skills/tools.\r
     • Suggested templates and content patterns.\r \r
3. Implementation-ready specifications\r
   • Tables or pseudo-schemas describing:\r
     • Required input fields and data sources.\r
     • Output fields/files and where they should be written.\r
     • Recommended automation approach (ETL, scripts, CMS workflows).\r \r
4. Rollout and QA plan\r
   • Phased rollout with criteria and success metrics.\r
   • QA checklists for sampling and sign-off.\r
   • Monitoring and iteration loops.\r \r When the user explicitly requests machine-consumable artifacts (for example, “give me a CSV spec that my data team can use”), prioritize precise, unambiguous formats (clear column names, data types, and examples).\r \r

Use of bundled resources\r

\r This skill ships with additional reference material and helper code:\r \r

• references/bulk_pipelines.md\r
  • Explains common GEO bulk pipeline patterns.\r
  • Provides example cluster definitions, pipeline step types, and rollout patterns.\r
  • Read this when you need inspiration for how to structure pipelines or explain them to the user’s team.\r \r
• scripts/geo_bulk_pipeline.py\r
  • Contains lightweight data models and helper functions that show one way to model content items, clusters, and pipelines.\r
  • You can mirror its structures when designing data formats, but you do not need to execute it to complete user requests.\r
  • If the environment allows executing scripts, they can be adapted into real automation helpers, but this skill does not require that.\r \r When in doubt, prefer clear written plans and specs over over-engineered code. The primary value of this skill is in designing scalable GEO bulk workflows, not in implementing full production systems inside the skill.\r \r

Style and collaboration guidelines\r

\r

• Think like a systems designer.\r
  • Aim for solutions that will still work when the corpus doubles or triples.\r
  • Avoid plans that require per-page manual tweaking unless limited to a small, high-value subset.\r \r
• Explain the “why”, not just the “what”.\r
  • Connect GEO decisions (clusters, templates, schema types) to the user’s business goals and constraints.\r \r
• Be opinionated but adaptable.\r
  • Suggest defaults and best practices, but clearly mark them as such.\r
  • Offer alternative paths when user constraints are unclear or strict.\r \r
• Make it easy to operationalize.\r
  • Prefer concrete artifacts: specs, templates, checklists, and example records.\r
  • Avoid vague recommendations that cannot be turned into tickets or automation.\r \r If the user already uses other geo-* skills, explicitly reference where they fit into each pipeline step (for example, “use geo-schema-gen here to generate Product and FAQ schema for this cluster”).\r \r