My blog traffic flatlined. Not just slow growth, but a genuine, terrifying flatline. For a month, Google Search Console (GSC) showed zero new impressions for my AIdeazz portfolio. The problem wasn't a lack of content; it was a lack of relevant content, as defined by Google. My solution wasn't to write more, but to build an AI agent that could identify GSC content gaps, draft articles, and publish them, all without my direct intervention. This isn't about "AI writing your blog" in a fluffy sense; it's about a production system that turns a GSC query into a published article on Dev.to and my own site, using Oracle Cloud Infrastructure (OCI) and a multi-agent architecture.
Defining a "Content Gap" with 15 GSC Queries
A "content gap" isn't an abstract concept when you're looking at GSC. It's a specific set of queries where you have impressions but low click-through rates (CTR), or queries where you rank on page 2 or 3. My initial manual analysis was painful: export GSC data, filter by impressions > 100, position > 10, and CTR < 1%. This yielded about 15-20 target queries per week. The problem was the manual effort: 30 minutes to analyze, 2 hours to draft, 15 minutes to publish. Multiply that by 10 articles, and my entire week was gone.
My agent, which I call "GSC-Gap-Finder," automates this. It connects to the GSC API, pulls data for aideazz.xyz, and applies the following filters:
1. impressions > 50 (lowered from 100 to catch more long-tail)
2. position > 8 (targeting page 1 bottom or page 2 top)
3. ctr < 0.015 (1.5% CTR, indicating a need for better content or targeting)
From the filtered results, it selects the top 5 queries by impression count that meet these criteria. These 5 queries become the "content gaps" for the next publishing cycle. The agent then passes these queries to the next stage: the "Article-Drafter."
The Multi-Agent Architecture on OCI
My entire AIdeazz infrastructure runs on OCI, primarily using Ampere A1 compute instances. This setup is crucial for cost control; I'm operating on zero VC funding. The agents communicate via a custom message queue built on Redis, also running on OCI.
The pipeline consists of three primary agents:
1. GSC-Gap-Finder (Python/GSC API):
* Input: Scheduled cron job (daily).
* Process: Queries GSC API for aideazz.xyz data. Filters queries based on impressions, position, and CTR. Selects top 5.
* Output: JSON object containing 5 target queries, passed to Redis queue.
2. Article-Drafter (Python/LangChain/Claude 3 Opus/Groq):
* Input: JSON object with 5 queries from Redis.
* Process: For each query, it initiates a drafting process. I use a dynamic routing mechanism:
* Initial Draft: Claude 3 Opus for complex topics, Groq for simpler, more factual queries. This decision is made by a small, fine-tuned LLM (Mistral 7B) based on query complexity (token count, presence of technical terms).
* Prompt Engineering: The prompt isn't just "write an article about X." It includes:
* Target audience (technical founders, developers).
* Required structure (H2 headings, bullet points, code examples if relevant).
* Mandatory inclusion of specific keywords from the GSC query.
* A negative prompt to avoid common AI writing clichés.
* A request for a specific word count (1500-2000 words).
* Iterative Refinement: The initial draft is then passed to a "Critique Agent" (also Claude 3 Opus) which checks for:
* Clarity, conciseness, and technical accuracy.
* Adherence to the prompt's negative constraints.
* SEO optimization for the target query (using a small, local BERT model to check keyword density and semantic relevance).
* The Critique Agent provides feedback, and the Article-Drafter attempts a revision. This loop runs up to 3 times.
* Output: Markdown-formatted article content, title, and a list of target keywords, passed to Redis queue.
3. Publisher (Python/Dev.to API/OCI Object Storage):
* Input: Markdown content, title, keywords from Redis.
* Process:
* Dev.to Publishing: Uses the Dev.to API to create a new post. It sets the published flag to false initially, allowing for a final manual review (my only human touchpoint in the entire process). Tags are automatically generated from the keywords.
* AIdeazz Cache: The article is also stored as a static HTML file in OCI Object Storage, which serves as the backend for aideazz.xyz. This ensures I own the content and have a canonical version. A simple Python script updates the index.html on aideazz.xyz to include the new article link.
* Output: Confirmation of Dev.to draft creation and OCI Object Storage update.
This entire process, from GSC query identification to a draft on Dev.to and a cached version on aideazz.xyz, takes an average of 15 minutes per article. The cost per article, including LLM API calls and OCI compute, is approximately $0.85.
The Groq/Claude Routing Decision
The choice between Groq and Claude 3 Opus isn't arbitrary; it's a cost-performance optimization. Groq is incredibly fast and cheap for token generation, but its reasoning capabilities, while good, don't match Claude 3 Opus for complex, nuanced technical writing.
My routing agent, a fine-tuned Mistral 7B model, analyzes the input query and a small sample of existing articles on aideazz.xyz. It makes a binary decision:
- If the query contains terms like "multi-agent system," "Oracle Cloud Infrastructure," "Kubernetes," "vector database," or has a token count > 15 (after stemming): Route to Claude 3 Opus. This indicates a need for deeper technical explanation and potentially code examples.
- If the query is simpler, like "how to use Redis cache," "Python logging best practices," or focuses on a single, well-defined concept: Route to Groq. These articles are often more tutorial-like and benefit from Groq's speed.
This routing saves me significant costs. A typical Claude 3 Opus draft costs around $0.50-$0.70, while a Groq draft is $0.02-$0.05. By routing 60% of my articles to Groq, I reduce my average LLM cost per article by 40%.
The "Human in the Loop" (Barely)
I'm a single mother running a business with no external funding. My time is the most valuable, and scarce, resource. The only human intervention in this pipeline is a quick review of the Dev.to draft before publishing. This takes about 2 minutes per article. I check for:
- Egregious factual errors: Has the AI hallucinated something truly incorrect? (Rare with Claude 3 Opus, more common with earlier models).
- Tone and voice: Does it sound like something I would write? (My prompt engineering helps here).
- Formatting issues: Are the Markdown headings correct? Are code blocks properly formatted?
If there's a minor issue, I fix it directly in Dev.to. If there's a major structural problem, I discard the article and feed the query back into the pipeline with refined negative prompts. This has happened twice in the last month.
This automated content pipeline has allowed me to publish 30 articles in the last month, a feat impossible with manual effort. My GSC impressions are now showing a consistent upward trend, and my CTR for target queries has improved from <1% to an average of 3.2%. The system isn't perfect, but it's a production-grade solution to a real business problem.
Frequently Asked Questions
Q: How do you handle duplicate content concerns between Dev.to and aideazz.xyz?
A: Dev.to allows you to specify a canonical URL. My Publisher agent automatically sets the canonical URL to the aideazz.xyz version of the article, ensuring Google understands the original source and avoids penalizing for duplicate content.
Q: What happens if the LLM generates an article that is too short or too long?
A: My prompt includes a target word count range (e.g., 1500-2000 words). The Critique Agent checks this constraint. If the article is outside the range, the Drafter agent is instructed to expand or condense specific sections during the iterative refinement loop.
Q: How do you ensure the articles are unique and not just rehashes of existing content?
A: The GSC query itself provides a unique angle (a specific gap in my site's coverage). Additionally, the prompt includes instructions to "provide novel insights" or "explain from a practitioner's perspective," which encourages the LLM to synthesize information rather than just summarize. I also use a local embedding model to compare the generated article's embeddings against a corpus of existing articles to flag high similarity.
Q: What's the biggest challenge you faced building this pipeline?
A: Cost optimization was paramount. Balancing the quality of Claude 3 Opus with the speed and cost-effectiveness of Groq, and building on OCI's Ampere A1 instances, required careful architectural decisions and constant monitoring of token usage and compute cycles.