My first attempt at an AI content pipeline failed to move the needle. After two months, 30 articles, and $120 in API costs, Google Search Console (GSC) showed zero new impressions for the target keywords. The core problem wasn't the LLM output; it was the input. "Content gap" is a marketing term, not an engineering specification. For a developer, a content gap is a specific GSC query with high impressions, low clicks, and no existing page ranking for it. My system needed to find those gaps, not just generate more text.
This article details the current iteration of my automated publishing pipeline, running on Oracle Cloud Infrastructure (OCI). It starts with GSC data, uses Claude 3.5 Sonnet for drafting, and publishes to Dev.to and my own site, aideazz.xyz. The entire process, from gap identification to publishing, runs without human intervention, costing under $0.05 per article.
Identifying Gaps: The GSC Query Filter
The initial GSC data extraction is simple: query the GSC API for the last 90 days of performance data. The challenge is filtering. My first mistake was looking for "low competition" keywords, a subjective metric. Now, I focus on a precise definition of a content gap:
1. Impressions > 500: The query has significant search volume.
2. Clicks < 50: Users are seeing the query, but not clicking through to my site.
3. CTR < 1%: Confirms the low click-through.
4. Average Position > 20: My existing content isn't ranking well for this query.
5. No existing page ranks for this query: This is the critical part. I cross-reference the query against my sitemap and existing GSC page data. If a page does rank, even poorly, for this query, it's not a gap; it's an optimization target.
This filter typically yields 10-20 viable queries per month for a site like aideazz.xyz. Each query becomes a potential article topic. For example, a recent gap identified was "OCI free tier always free limits". My site had content on OCI, but nothing specific to the limits of the free tier, despite high impressions for that exact phrase.
Orchestration with OCI Functions and Groq/Claude Routing
The entire pipeline is a series of OCI Functions, triggered by a daily cron job. I use a custom Python agent framework that routes requests to different LLMs based on cost and task complexity.
The core agents are:
1. GSC_Analyzer: Fetches GSC data, applies the gap filter, and outputs a list of (query, impressions, clicks, position) tuples.
2. Topic_Generator: For each gap query, this agent uses a small, fine-tuned Llama 3 8B model (running on Groq for speed) to expand the query into 3-5 potential article titles and a brief 2-sentence summary. This step is crucial for giving the drafting LLM enough context.
3. Article_Drafter: This is where Claude 3.5 Sonnet shines. It receives the chosen title and summary from Topic_Generator. The prompt is structured to enforce a specific markdown format, include code examples where relevant, and maintain a technical, skeptical tone. I've found Claude 3.5 Sonnet to be superior for long-form, structured technical content compared to other models at its price point. Its context window handles the detailed instructions and reference material well.
4. SEO_Optimizer: A smaller agent (again, Groq-powered Llama 3) that takes the drafted article and suggests 3-5 internal links to existing aideazz.xyz content, based on semantic similarity. It also generates a meta description and 5 relevant tags.
5. Publisher: This agent handles the actual posting. It uses the Dev.to API for publishing and a custom script to create a static HTML page on aideazz.xyz, which is then cached by Cloudflare.
The routing logic is simple: if the task is short, low-complexity, and latency-sensitive (like title generation or internal linking), it goes to Groq. If it's long-form content generation or requires complex reasoning, it goes to Claude. This hybrid approach keeps costs down and throughput high. My average LLM cost per article is $0.03 for Claude and $0.01 for Groq, plus OCI Function execution costs.
The Claude 3.5 Sonnet Drafting Prompt
The prompt for Article_Drafter is highly structured. It's less about "write an article" and more about "fill these markdown sections with specific content, adhering to these constraints."
You are an expert technical writer for developers. Your task is to write a detailed, skeptical, and practical article about [TOPIC].
The article must be at least 1200 words.
Use the following structure:
## [Chosen Title]
[Opening paragraph: Lead with a failure, a constraint, a hard number, or a decision. Never with background or context-setting. The reader decides in the first three sentences whether to continue.]
## [Section 1 Heading - technical focus]
[Content for Section 1. Include specific numbers, error messages, or cost figures. Avoid adjectives where a number can be used.]
## [Section 2 Heading - implementation detail]
[Content for Section 2. Focus on "how it's done" with code snippets or configuration examples.]
## [Section 3 Heading - challenge or tradeoff]
[Content for Section 3. Discuss a specific problem encountered or a design tradeoff made. Take a clear position.]
## [Section 4 Heading - results or future work]
[Content for Section 4. Present concrete outcomes or next steps. Avoid vague predictions.]
## Frequently Asked Questions
**Q: [specific, non-obvious question]**
A: [direct, factual answer, 2-4 sentences, with a concrete number or tradeoff]
**Q: [another practitioner-level question]**
A: [answer]
(continue for 3-5 Q&A pairs)
Ensure the tone is direct, factual, and assumes the reader is a skeptical practitioner. Avoid startup clichés. Use Markdown.
This prompt consistently produces articles that require minimal editing. The "lead with failure/constraint" instruction is particularly effective at setting the right tone and grabbing attention.
Automated Publishing to Dev.to and aideazz.xyz
Once the article is drafted and optimized, the Publisher agent takes over.
For Dev.to, I use their API to create a new post. The article content is sent as Markdown. The SEO_Optimizer agent provides the title, tags, and canonical URL (pointing back to aideazz.xyz). This ensures that Dev.to acts as a distribution channel, not the primary source.
For aideazz.xyz, the process is slightly more involved. My site is a static site generated by a custom Python script. The Publisher agent:
1. Creates a new Markdown file in the _posts directory.
2. Adds YAML front matter with title, date, tags, and meta description.
3. Triggers the static site generator.
4. Pushes the updated site to an OCI Object Storage bucket, which is then served via OCI CDN.
This setup means aideazz.xyz always has the latest content, and the CDN ensures fast global delivery. The entire publishing process takes less than 30 seconds.
Results and Future Iterations
After three months with this refined pipeline, the results are promising. The 15-20 articles generated monthly now consistently target specific GSC gaps. I've seen a 15% increase in organic impressions for these targeted queries and a 3% increase in overall site clicks. The cost per article remains under $0.05, making it highly scalable.
The next iteration will focus on a feedback loop. Currently, the system identifies gaps and publishes. I want to build an agent that monitors GSC performance for published articles and, if they underperform after 60 days, triggers an Article_Reviser agent. This agent would analyze GSC data for the underperforming article, identify new sub-gaps or related queries, and then use Claude to rewrite or expand sections of the article. This closes the loop, moving beyond just publishing to continuous optimization. The challenge here is defining "underperform" with enough precision to avoid unnecessary rewrites.
Frequently Asked Questions
Q: How do you handle duplicate content concerns between Dev.to and your own site?
A: I use the canonical URL feature on Dev.to, pointing all posts back to the original article on aideazz.xyz. This tells search engines that aideazz.xyz is the primary source, preventing duplicate content penalties.
Q: What if the LLM generates incorrect technical information or code?
A: This is a real risk. For critical topics, I have a human review step for the first 5-10 articles in a new domain. Once confidence is established in the LLM's accuracy for that domain, I reduce human oversight. For code, I primarily use LLMs for boilerplate or well-understood patterns, not novel algorithms.
Q: Why Oracle Cloud Infrastructure (OCI) instead of AWS/GCP/Azure?
A: OCI's always-free tier offers generous compute and storage resources (4 OCPU, 24GB RAM, 200GB block storage) that are sufficient for running my OCI Functions and static site hosting without incurring costs. This was a critical factor for bootstrapping without VC funding.
Q: How do you prevent the LLM from going off-topic or hallucinating?
A: The highly structured prompt, combined with specific instructions to "lead with failure/constraint" and "use specific numbers," significantly reduces hallucination. I also provide a small set of reference URLs to the Article_Drafter agent for factual grounding, though this adds to prompt token costs.
Q: What's the biggest challenge in maintaining this pipeline?
A: GSC API rate limits and data consistency. Sometimes the API returns inconsistent data for the same query over short periods. I've implemented retry logic and a 24-hour cache for GSC data to mitigate this, but it's a constant monitoring point.