AIdeazz Blog About Portfolio

Automated Publishing: From GSC Gap to Live Post in 11 Minutes

· by

My first attempt at an AI content pipeline failed to generate a single useful article for three weeks. The problem wasn't the LLM, the orchestrator, or the publishing API. It was the definition of "content gap." Google Search Console (GSC) showed 15 queries for aideazz.xyz with impressions but zero clicks. My initial thought: these are the gaps. I built an agent to pick the highest impression/zero-click query, send it to Claude 3.5 Sonnet, and publish the result. The articles were technically correct, but nobody clicked. Why? Because a "gap" isn't just a missing page; it's a missing intent match.

The GSC Zero-Click Trap: Why "Gap" Isn't Just Missing Content

My GSC data for aideazz.xyz showed queries like "aideazz pricing," "aideazz contact," "aideazz reviews." These are navigational or transactional queries. A blog post titled "Aideazz Pricing Explained" isn't what a user searching "aideazz pricing" wants. They want a pricing page, not an article. The zero-click rate wasn't a content gap; it was a format gap or a conversion gap. My agent was filling a non-existent content void with irrelevant blog posts.

The real content gap for a technical audience lies in informational queries where your site could rank, but doesn't, or where existing content is weak. This requires a more nuanced GSC analysis than simply filtering for zero-click queries.

Redefining "Gap": From Zero-Click to Intent Mismatch

I pivoted the GSC analysis agent. Instead of focusing on zero-click queries, it now looks for:

1. Low-CTR informational queries: Queries with impressions > 500, average position < 20, and CTR < 1%. These indicate potential ranking opportunities where existing content isn't compelling enough, or where a new, targeted article could perform better.
2. Queries with high impressions and no relevant page: This is harder to automate. It requires a semantic search over existing content to confirm no page addresses the query directly. My current agent uses a vector database of existing article embeddings. If a query's embedding similarity to all existing articles is below a threshold (e.g., cosine similarity < 0.7), it's flagged as a potential gap.
3. Competitor keyword overlap (manual step): This is still a manual process. I use Ahrefs to find keywords my competitors rank for where aideazz.xyz has no presence. This informs the GSC agent's filtering criteria.

The agent now pulls GSC data via the API, filters by these criteria, and prioritizes based on a weighted score: (impressions (1 - CTR)) + (position_score 0.5). position_score is (20 - average_position) / 20 to give higher priority to queries closer to page one.

The Multi-Agent Content Generation Pipeline: Oracle Cloud to Dev.to

Once a topic is identified by the GSC analysis agent, it's passed to the content generation pipeline. This is a multi-agent system running on Oracle Cloud Infrastructure (OCI) using OCI Functions and Container Instances.

Agent 1: The Research & Outline Agent

This agent receives the prioritized query. Its first task is to generate a detailed outline. It uses a combination of techniques:

The outline is structured with specific instructions for the drafting agent: "Lead with failure/constraint," "use numbers," "avoid clichés." This outline is then reviewed by a human (me) for 5-10 minutes. This is the only human in the loop for content creation.

Agent 2: The Drafting Agent (Claude 3.5 Sonnet)

The approved outline goes to the drafting agent. I've experimented with various LLMs (GPT-4o, Llama 3, Mixtral), but Claude 3.5 Sonnet consistently produces the best first drafts for technical content, especially when given strict formatting and tone instructions. Its ability to follow complex constraints without hallucinating or becoming overly verbose is superior for this use case.

The prompt for Claude includes:

The drafting agent runs on a dedicated OCI Container Instance, making API calls to Anthropic. The average generation time for a 2000-word article is 90-120 seconds.

Agent 3: The Publishing Agent (Dev.to & Aideazz.xyz Cache)

Once the draft is generated, it's passed to the publishing agent. This agent has two primary functions:

1. Dev.to API integration: It uses the Dev.to API to create a new post. The article content (Markdown), title, and relevant tags are extracted from the draft. It also sets published: false initially, allowing for a final review on Dev.to's platform before going live.
2. Aideazz.xyz caching: A copy of the Markdown content is stored in an OCI Object Storage bucket, which acts as a cache for aideazz.xyz. This ensures the content is immediately available on my own domain, even before Dev.to publishes it. A separate OCI Function triggers a static site regeneration for aideazz.xyz to pull this new content.

The entire process, from GSC query identification to the article being available on aideazz.xyz and staged on Dev.to, takes approximately 11 minutes, including the 5-10 minute human review of the outline.

Performance Metrics: Before and After

Before this refined AI content pipeline GSC gap analysis automated publishing system, my blog posts were sporadic and often missed the mark. I was publishing 1-2 articles per month, with an average CTR of 0.8% from organic search.

Since implementing this system:

The key improvement wasn't just speed or volume, but relevance. By focusing on true intent gaps identified through a more sophisticated GSC analysis, the content now directly addresses what my target audience is searching for, leading to higher engagement.

Infrastructure: Why Oracle Cloud and Groq/Claude Routing

I run AIdeazz on Oracle Cloud Infrastructure (OCI) for several reasons, primarily cost-effectiveness and performance for GPU-intensive workloads. My multi-agent system leverages:

I route LLM calls dynamically. For drafting, Claude 3.5 Sonnet is the default due to its quality. For faster, less critical tasks (e.g., quick rephrasing, simple data extraction), I use Groq's Llama 3 8B or 70B via their API. This routing decision is made by an OCI Function based on the task_type parameter passed to the LLM orchestration layer. Groq offers significantly lower latency (tens of milliseconds) for smaller models, which is critical for interactive agents or high-throughput, low-complexity tasks. For a 2000-word article, Claude's 90-120 second generation time is acceptable, but for real-time chat agents, Groq is indispensable.

Frequently Asked Questions

Q: How do you prevent AI-generated content from sounding generic or repetitive?
A: The key is the detailed outline and strict prompt engineering. The outline agent performs real-time SERP analysis to ensure novelty, and the drafting agent's prompt explicitly forbids clichés and demands specific examples/numbers, forcing it to generate unique content.

Q: What's the cost of running this pipeline?
A: Excluding the LLM API costs (which vary based on usage, but average $50-100/month for content generation), the OCI infrastructure for the agents, functions, and storage costs less than $10/month. This is due to OCI's generous free tier and efficient serverless billing.

Q: How do you handle factual accuracy and potential hallucinations?
A: The research agent's SERP analysis provides a factual grounding. For highly sensitive topics, a human review of the draft (not just the outline) is added. For this blog, the outline review is sufficient, as the topics are within my domain expertise.

Q: Why not use a single, larger LLM for everything?
A: Cost and performance. A smaller, specialized agent for GSC analysis is cheaper and faster than using a large LLM. Routing to Groq for specific tasks optimizes for latency where needed, while Claude handles the heavy lifting of drafting. This multi-agent, multi-LLM approach is more efficient.

— Elena Revicheva · AIdeazz · Portfolio