GSC Gap Analysis: From 15 Queries to Automated Publishing

Originally published on AIdeazz — cross-posted here with canonical link.

My first attempt at an automated content pipeline failed to generate a single useful article. The goal was simple: identify content gaps using Google Search Console (GSC), draft articles with Claude, and publish them. The reality was a stream of irrelevant drafts, costing me $0.08 per article in API calls and zero organic traffic. The core problem wasn't the LLM, but my definition of "content gap" when GSC showed only 15 queries for a new domain.

Defining "Content Gap" for a New Domain

A "content gap" on a mature site with thousands of indexed pages and millions of impressions is a well-understood concept: identify queries where you rank on page 2 or 3, but competitors rank higher, then create better content. For a brand-new domain like AIdeazz.xyz, launched just months ago, GSC shows a handful of impressions and clicks. My initial GSC data for AIdeazz.xyz had 15 queries, 20 impressions, and 1 click. Trying to find a "gap" in this data is like looking for a specific grain of sand on an empty beach.

My first agent, GSC_Analyzer, was designed to pull queries with high impressions but low clicks. With 20 impressions total, every query fit this criteria. The agent then passed these "gaps" to Article_Drafter. The output was predictable: generic articles on broad topics like "AI" or "cloud computing" that had no chance of ranking. I burned through $5 in Claude 3 Haiku calls for 60 articles, none of which were publishable.

The pivot was to redefine "gap" not as a missing piece in existing coverage, but as an opportunity to establish initial relevance. This meant targeting specific, long-tail queries that indicated user intent for a niche I wanted to rank for, even if GSC showed zero current impressions. I manually curated a list of 10 target keywords related to "production AI agents," "Oracle Cloud AI," and "Groq LLM routing." This became the seed for the next iteration.

The Multi-Agent Architecture for Automated Publishing

My current pipeline runs on Oracle Cloud Infrastructure (OCI) with a custom multi-agent system. It's built on Python, leveraging langchain for agent orchestration and fastapi for API endpoints.

1. Topic_Selector (Python script, manual input): For now, this is me. I feed it 3-5 specific, long-tail keywords per week. Example: "Oracle Cloud Groq LLM routing," "production AI agents OCI," "Panama AI startup." This is the critical human-in-the-loop step that prevents LLM hallucination and ensures relevance.
2. GSC_Query_Expander (Python agent): This agent takes the seed keywords and uses a combination of Google Search API (for related searches) and a small, fine-tuned local LLM (Llama 3 8B on an OCI VM) to generate 10-15 semantically similar long-tail queries. It filters out overly broad or competitive terms based on a simple heuristic: if the top 3 Google results are from major publications (e.g., Forbes, TechCrunch), it discards the query. This costs about $0.001 per query expansion.
3. Article_Drafter (Langchain agent, Claude 3 Opus/Sonnet/Haiku): This is the core content generation engine.
   • It receives a batch of 3-5 expanded queries.
   • For each query, it performs a quick web search (via serper.dev) to understand current top-ranking content and identify potential angles.
   • It then drafts a 1200-1800 word article. I route requests based on complexity:
     • Claude 3 Haiku: For simple, informational "what is X" type articles. Cost: ~$0.0025 per 1k tokens.
     • Claude 3 Sonnet: For more detailed "how-to" guides or comparisons. Cost: ~$0.03 per 1k tokens.
     • Claude 3 Opus: Reserved for highly technical deep-dives or opinion pieces where nuance is critical. Cost: ~$0.15 per 1k tokens.
   • The agent uses a custom prompt that emphasizes specific structure (headings, bullet points, code examples where relevant) and a direct, no-fluff tone. It also includes a "self-correction" step where it reviews its own draft against the initial query and a checklist of common SEO best practices (e.g., keyword density, readability). This adds 1-2 API calls but significantly improves quality.
4. Article_Reviewer (Python script, human-in-the-loop): This is another critical manual step. I review each draft for accuracy, tone, and factual correctness. I'm looking for specific errors, not just stylistic improvements. This takes 5-10 minutes per article. If an article requires more than 15 minutes of editing, it's discarded and the Article_Drafter is prompted to try again with refined instructions.
5. Publisher_DevTo (Python agent): Once approved, this agent formats the article for Dev.to using Markdown, adds relevant tags, and publishes it. It uses the Dev.to API.
6. Publisher_Aideazz (Python agent): Simultaneously, the article is published to AIdeazz.xyz. This involves storing the Markdown in an OCI Object Storage bucket and updating a static site generator (Hugo) via a webhook, triggering a rebuild and deployment to OCI CDN. This ensures my primary domain always has the latest content.
7. Indexer_Notifier (Python agent): After publishing, this agent pings Google Search Console's Indexing API to request immediate indexing for both Dev.to and AIdeazz.xyz URLs. This helps accelerate discovery.

The entire automated flow, from GSC_Query_Expander to Indexer_Notifier, takes about 15 minutes per article, with the LLM drafting being the longest component. Total cost per article (excluding my time) is between $0.05 and $0.25, depending on the Claude model used.

Oracle Cloud Infrastructure for Cost-Effective Operations

Running this on OCI has been crucial for keeping costs down without VC funding.

• Always Free Tier: My GSC_Query_Expander and Indexer_Notifier agents run on an OCI Always Free VM (1 OCPU, 1 GB RAM). This handles the lighter, burstable workloads.
• Flexible VMs: The Article_Drafter and Publisher agents run on a Flexible VM (E3.Flex, 2 OCPUs, 16 GB RAM) that I scale down to 1 OCPU, 4 GB RAM when not actively drafting. This VM costs about $0.03/hour when running at full capacity.
• Object Storage: AIdeazz.xyz content is stored in OCI Object Storage, which is dirt cheap (around $0.025/GB/month).
• OCI CDN: My static site is served via OCI CDN, costing about $0.085/GB for egress. With a small site, this is negligible.
• Networking: Ingress is free, and egress is metered but generous.

My total OCI bill for this entire pipeline, including the website hosting, is consistently under $10/month. This is critical for a bootstrapped operation.

The "Gap" in Action: From Zero to 100 Impressions

The initial manual keyword selection was the turning point. Within two weeks of publishing articles targeting "Oracle Cloud Groq LLM routing" and "production AI agents OCI," I started seeing impressions in GSC for these exact terms. My GSC data now shows 100+ impressions for these specific long-tail queries, with a few clicks. This is still tiny, but it's relevant traffic.

The next iteration of GSC_Analyzer will be able to use this new, relevant data. Instead of looking for gaps in an empty dataset, it will identify queries where I have impressions but low CTR, or where I'm ranking on page 2-3. This feedback loop is essential. The current GSC_Analyzer is being rewritten to:

1. Pull all queries with >50 impressions.
2. Filter for queries where average position is >10.
3. Prioritize queries with a CTR < 1%.
4. Pass these to Article_Drafter for content improvement or expansion, not just new content.

This shift from "create anything" to "optimize what's working" is the natural progression for an AI content pipeline as the domain gains traction. The initial "gap" was simply the absence of any relevant content. Now, the gap is about performance.

Frequently Asked Questions

Q: Why not use a cheaper LLM like Llama 3 for drafting?
A: I've tested Llama 3 8B and 70B locally on OCI. While cheaper for raw token generation, the quality and adherence to complex instructions for article drafting are not yet on par with Claude 3 Sonnet/Opus. The additional human editing time required for Llama 3 drafts would negate any API cost savings.

Q: How do you handle factual accuracy and hallucinations, especially for technical topics?
A: The Article_Reviewer (human-in-the-loop) is the primary safeguard. For highly technical articles, I also integrate a Fact_Checker agent that uses serper.dev to cross-reference specific claims against reputable sources (e.g., official documentation, academic papers). If a claim cannot be verified, the Article_Drafter is prompted to rephrase or remove it.

Q: What about content originality and avoiding duplicate content penalties?
A: The Article_Drafter is prompted to synthesize information from multiple sources and generate unique phrasing. I also run a quick plagiarism check (using a custom script leveraging diff-match-patch against top search results) before publishing. So far, I haven't encountered any issues.

Q: Why publish to Dev.to and your own site? Isn't that duplicate content?
A: Dev.to allows canonical URLs, pointing back to AIdeazz.xyz. This tells search engines that my site is the original source, preventing duplicate content penalties and consolidating SEO authority. Dev.to provides immediate audience reach and backlinks, while my site builds long-term domain authority.

Q: How do you manage the LLM API costs and prevent runaway spending?
A: I implement strict token limits for each API call within the Article_Drafter agent. Each article draft is capped at 30k tokens for input/output. I also have daily and weekly spending alerts configured with Anthropic and Oracle Cloud. If costs exceed a predefined threshold ($5/day for LLMs), the pipeline pauses and notifies me via Telegram.

— Elena Revicheva · AIdeazz · Portfolio