My first attempt at an automated content pipeline for AIdeazz.xyz failed to move the needle. I built a system that would take a single, high-volume keyword, generate an article with Claude 3 Opus, and publish it to Dev.to and my own site. The problem? My site, AIdeazz.xyz, had 15 indexed pages and zero organic traffic. "High-volume keyword" for a site with no authority is a fantasy. I needed to address the actual content gaps Google Search Console (GSC) was showing me, not the ones I imagined.
The real content gap for a new site isn't about missing a "game-changing" keyword. It's about the queries GSC already shows you, even if they're for impressions with zero clicks. These are the queries Google thinks your site is somewhat relevant for. My GSC for AIdeazz.xyz showed me 15 queries with impressions, average position 80+, and zero clicks. This is where the AI content pipeline needed to start: not with what I wanted to rank for, but with what Google was already hinting at.
From GSC Query to Article Brief: The GSC_Analyzer Agent
The first agent in my revised pipeline is GSC_Analyzer. It connects to the GSC API, pulls the latest performance data for AIdeazz.xyz, and filters for queries with impressions but no clicks, specifically those ranking between positions 50 and 100. Why this range? Queries ranking worse than 100 are too broad a shot in the dark. Queries better than 50 usually have some clicks, indicating I'm already addressing them, even if poorly. The sweet spot for a content gap is where Google sees some relevance but not enough to rank you well or get a click.
The GSC_Analyzer doesn't just pull queries; it enriches them. For each identified query, it performs a quick Google search (using a SerpAPI integration) to understand the current top-ranking content. This informs the article brief. For example, if GSC shows "oracle cloud free tier limitations" with 20 impressions and 0 clicks at position 78, the GSC_Analyzer will generate a brief like:
{
"query": "oracle cloud free tier limitations",
"target_audience": "developers, technical founders using OCI",
"keywords": ["oracle cloud free tier", "oci free tier", "always free resources", "oci limitations", "oracle cloud cost"],
"main_points_to_cover": [
"Specific resource limits (CPU, RAM, storage for VM.Standard.E2.1.Micro)",
"Network egress costs after initial free tier",
"Database limitations (Autonomous Database, MySQL HeatWave)",
"Common pitfalls and how to avoid unexpected charges",
"Comparison with other cloud free tiers (AWS, GCP) if relevant to query context"
],
"tone": "informative, practical, slightly cautionary",
"target_length_words": 1200,
"competing_urls": [
"https://www.oracle.com/cloud/free/",
"https://docs.oracle.com/en-us/iaas/Content/FreeTier/freetier_topic-Overview_of_Always_Free_Resources.htm",
"https://www.reddit.com/r/oraclecloud/comments/..."
]
}
This structured brief is then passed to the next agent.
Drafting with Claude 3 Opus and Groq Routing: The Article_Draft_Agent
The Article_Draft_Agent receives the brief and is responsible for generating the article. I initially used Claude 3 Opus exclusively for drafting. Its long context window and strong reasoning capabilities are excellent for producing high-quality, nuanced content. However, Opus is expensive. A 1200-word article can cost $0.50-$1.00 per generation, and multiple iterations add up.
To optimize cost and speed, I implemented a routing layer. The Article_Draft_Agent first attempts a draft using Groq's Llama 3 8B. Groq is incredibly fast and significantly cheaper (around $0.00008 per 1k tokens). It's often sufficient for the first pass, especially for straightforward, factual topics.
The routing logic is simple:
1. Initial Draft: Generate with Groq Llama 3 8B.
2. Quality Check: A small, fine-tuned Llama 3 8B model (running on Oracle Cloud Infrastructure's Llama 3 endpoint) acts as a critic. It checks the draft against the brief's main_points_to_cover, tone, and target_length_words. It also flags any obvious factual errors or hallucinations by cross-referencing against the competing_urls provided in the brief. This critic model is cheap and fast.
3. Revision Loop: If the Groq draft fails the quality check, the Article_Draft_Agent sends the critic's feedback and the original brief back to Claude 3 Opus for a revised draft. This ensures Opus is used for complex reasoning and refinement, not for initial boilerplate. This significantly reduced my LLM spend for drafting by about 60%.
The output of this agent is a Markdown-formatted article, ready for publishing.
Publishing to Dev.to and AIdeazz.xyz: The Publisher_Agent
The Publisher_Agent takes the final Markdown article and handles multi-platform distribution.
Dev.to Integration
Publishing to Dev.to is straightforward using their API. The agent constructs the JSON payload, including the article content, tags (extracted from the brief's keywords), and a canonical URL pointing back to AIdeazz.xyz. This is crucial for SEO, telling Google that AIdeazz.xyz is the original source. The Dev.to API call looks something like this:
import requests
devto_api_key = os.getenv("DEVTO_API_KEY")
headers = {
"api-key": devto_api_key,
"Content-Type": "application/json"
}
data = {
"article": {
"title": article_title,
"body_markdown": article_content,
"published": True,
"tags": article_tags,
"canonical_url": f"https://aideazz.xyz/blog/{slug}"
}
}
response = requests.post("https://dev.to/api/articles", headers=headers, json=data)
if response.status_code == 201:
print(f"Successfully published to Dev.to: {response.json()['url']}")
else:
print(f"Failed to publish to Dev.to: {response.status_code} - {response.text}")
AIdeazz.xyz Caching and Display
For AIdeazz.xyz, I don't use a traditional CMS. My site is a static site generated from Markdown files. The Publisher_Agent converts the Markdown to HTML, generates a unique slug (e.g., oracle-cloud-free-tier-limitations), and saves it to an Oracle Object Storage bucket. This bucket is configured as a static website, served via an Oracle CDN.
The process:
1. Slug Generation: A simple function converts the article title to a URL-friendly slug.
2. Markdown to HTML: markdown2 library handles the conversion.
3. Metadata Injection: Front matter (title, date, tags, canonical URL) is added to the HTML.
4. Object Storage Upload: The HTML file is uploaded to aideazz-blog-bucket/blog/{slug}/index.html.
5. Cache Invalidation: A call to the Oracle CDN API invalidates the cache for /blog/{slug}/index.html to ensure the new content is immediately visible.
This setup is extremely cost-effective. Oracle Object Storage is $0.025/GB/month, and CDN costs are minimal for a low-traffic site. There's no database, no server-side rendering, just static files.
Monitoring and Iteration: The Feedback_Loop_Agent
The final, crucial agent is Feedback_Loop_Agent. It monitors GSC for new data related to the published articles. After a few weeks, it checks if the average position for the targeted queries has improved, and more importantly, if clicks have started to appear. If an article still performs poorly (e.g., position > 50, zero clicks), it flags the article for revision.
The revision process involves:
1. Re-analyzing GSC: What new related queries have appeared?
2. Re-briefing: The GSC_Analyzer generates an updated brief, potentially including new keywords or main points based on fresh GSC data and competitor analysis.
3. Re-drafting: The Article_Draft_Agent generates a revised article.
4. Re-publishing: The Publisher_Agent updates the existing article on Dev.to and AIdeazz.xyz.
This closed-loop system ensures that the content pipeline isn't a fire-and-forget mechanism. It continuously learns and adapts based on real-world performance data from Google.
My 15 initial GSC queries have now turned into 30 published articles, and my site's average position for those initial queries has improved from 80+ to an average of 45. Clicks are still low, but they exist. This iterative, data-driven approach, starting with the actual GSC gaps, is proving to be a more effective strategy than blindly chasing high-volume keywords.
Frequently Asked Questions
Q: How do you prevent AI-generated content from being flagged by Google?
A: The key is quality and relevance, not origin. My pipeline focuses on addressing specific GSC gaps with detailed, factual content. The Article_Draft_Agent's critic model and human review (for critical articles) ensure accuracy and avoid generic phrasing. Google's guidelines emphasize helpful, reliable content, regardless of how it's produced.
Q: What's the total cost of running this pipeline per article?
A: For a 1200-word article, Groq's initial draft is negligible ($0.0001). Claude 3 Opus for refinement costs $0.20-$0.50. SerpAPI for competitor analysis is $0.01-$0.02. Oracle Cloud Object Storage and CDN are effectively free at low scale. Total per article is typically under $0.60, excluding my own time for setup and occasional review.
Q: How do you handle factual accuracy for technical topics?
A: The GSC_Analyzer provides competing_urls from top-ranking sources, including official documentation. The Article_Draft_Agent's critic model is instructed to cross-reference against these. For highly sensitive technical content, I perform a manual review before final publication.
Q: What if the GSC queries are too broad or nonsensical?
A: The GSC_Analyzer filters for queries with at least 10 impressions and a position between 50-100. If a query is still too broad, the agent's brief generation step will struggle to find relevant main_points_to_cover and competing_urls, which acts as a natural filter. I also have a manual override to discard queries.