AI Automation — Research-Based SEO Article Production System V1 → V3
Role: AI Automation Builder, n8n Workflow Architect, SEO Content Strategist & QA Designer
Core Stack: n8n, AI APIs, Local LLMs / LM Studio, Google Search APIs, Research Sources, Structured JSON, WordPress REST/API
This Was Never Meant to Be an “AI Article Generator”
I had already spent years writing SEO content manually with carefully engineered ChatGPT workflows. By late 2025, I wanted to answer a harder question:
Could I turn the research, judgment, writing structure and quality-control lessons I had learned manually into a repeatable AI production system without allowing automation to quietly lower the quality?
The result became an n8n-orchestrated SEO article system that evolved through three major generations.
The interesting part of this project is not that each new version became automatically “better.” It did not. One version became technically safer while accidentally becoming worse at research. Finding that regression and repairing it became one of the most valuable parts of the project.
V1 — Prove the Entire Workflow Can Be Automated
V1 started with a simple goal: take the manual workflow I had been using for years and turn it into connected production stages.
Instead of manually moving information between ChatGPT conversations, research tabs and WordPress, n8n became the orchestrator.
V1 Flow
- Receive article topic / keyword input
- Perform keyword and topic research
- Gather supporting information
- Create an article outline
- Draft and expand sections
- Create FAQs and SEO metadata
- Plan article images
- Prepare WordPress-ready content
- Pass results through review before production use
V1 proved something important: the process could be broken into specialized steps instead of asking one large AI prompt to research, reason, write, optimize and publish everything at once.
What V1 Exposed
Once the workflow became automated, problems that were easy for a human to notice manually became dangerous because downstream nodes would happily continue processing bad upstream data.
The early system exposed issues such as:
- An AI response looking polished even when the underlying research was weak
- Malformed or inconsistent JSON between workflow stages
- AI models adding explanations, markdown or reasoning when a machine expected clean structured output
- Search/fetch failures reaching later stages without enough context
- Weak separation between researched evidence and generated prose
- One poor source potentially influencing too much of the final article
- Difficulty knowing why a source had been selected or rejected
The V1 lesson: automating prompts is easy. Building an automation that knows when its own inputs are bad is much harder.
V2 — Separate Research From Writing
V2 became the major quality upgrade.
I stopped treating “research” as one AI prompt and built it as its own pipeline. The research system could discover multiple perspectives, fetch candidate sources, reduce each source independently, reject weak material and only then create a research package for the writer.
The V2 Research Architecture
- AI-assisted research/query planning
- Diverse Google-search intents rather than one generic query
- Wikipedia/concept discovery where useful
- Additional language/search-provider research
- URL prioritization
- Page fetching and conversion
- Per-source AI reduction
- Keep/reject decisions for individual sources
- Research aggregation
- Final synthesis into an article-ready research pack
- Token-size guards
- Soft-error handling for failed pages
- Structured JSON parsing and validation
Why Per-Source Reduction Mattered
Instead of throwing several full webpages into one huge context window, V2 could examine sources individually.
The reducer asked a much smaller question:
“Does this source contain useful information for this specific article? If yes, extract the useful facts. If not, reject it.”
This made it possible to discard irrelevant pages before they polluted the final synthesis.
The “AI Thinking” Problem
Local and reasoning models did not always behave like clean APIs. Sometimes a node requested JSON and received reasoning, an introduction, markdown fences or other text wrapped around the actual answer.
That is harmless in a chat window. Inside an automation, it can break the next ten nodes.
V2 therefore gained parsing and sanitation logic that could:
- Remove thinking/reasoning blocks
- Strip markdown fences
- Remove common assistant preambles
- Locate the actual JSON object or array
- Parse and validate the structure
- Reject output that still failed the contract
This was an important shift in my thinking: AI output is untrusted input until it passes a machine-readable contract.
Soft Failures Instead of Destroying the Whole Run
Research on the open web is messy. Pages disappear, websites return 403 errors, PDFs behave differently, transcripts fail and APIs occasionally time out.
V2 began separating soft errors from fatal errors.
If one source failed but enough other research survived, the system could record the failure, skip that source and continue. If the research package itself became invalid, the workflow could stop instead of producing a confident article from insufficient evidence.
V2 Became the Research-Quality Benchmark
During later audits, V2 turned out to have something valuable that I initially underestimated: research diversity.
Its broader query planning, semantic review and source-by-source synthesis often produced richer research than the first V3 implementation.
That became important because V3 was supposed to improve V2.
V3 — Production Hardening
V3 began with a different priority: make the system safer, more predictable and easier to operate repeatedly.
I added stronger engineering controls around the AI.
What V3 Added
- Stable normalized input contracts between V2/V3 workflows
- API/HTTP production paths instead of relying on local CLI execution
- Credential-based API access rather than hardcoded secrets
- Deterministic URL filtering
- Search-result caching
- Quota-safe testing modes
- Source manifests
- Source cards
- Evidence ledgers
- Allowed-reference URL locks
- Research quality scores and flags
- Rejected-source tracking
- Diagnostics and stronger blocking behavior
- More explicit provenance between evidence and final content
Architecturally, V3 was much stronger.
Then I tested the actual research quality.
The Surprise: V3 Was Safer but Research Became Worse
This was one of the most useful failures in the whole project.
While hardening the system, I had simplified parts of research discovery. V2’s broader semantic/query-planning behavior had been replaced by a much smaller deterministic query builder.
Technically the workflow looked cleaner.
But the research got weaker.
In one real test, an object was incorrectly passed into the Google query field and became:
[object Object]
The search results then included irrelevant or commercially noisy pages such as Amazon products and unrelated Reddit discussions.
At the same time, strict filtering could reject so much material that the downstream research loop was left starving for useful evidence.
This taught me an engineering lesson that is easy to miss in AI automation:
More deterministic does not automatically mean more intelligent.
V3 Repair — Keep Determinism Where It Protects the System, Keep AI Where Judgment Is Needed
I did not solve the V3 problem by simply making the prompts larger.
I redesigned the boundaries.
1. Fix the Data Contract Before Fixing the Prompt
The first priority was preventing malformed query objects and field-shape differences from leaking into downstream search APIs.
V2 and V3 inputs were normalized into a stable contract before research began.
This reduced errors where one workflow expected a string while another passed an object, array or differently named field.
2. Restore Better Research Discovery
The query system was redesigned to cover useful informational, local, technical and authority-oriented research instead of producing several nearly identical searches.
Where a topic involved regulation, compliance or location-specific facts, authority discovery could be deliberately included rather than hoping Google surfaced it naturally.
3. Deterministic Filtering Became a Guardrail, Not the Research Brain
Deterministic code is excellent for rules such as:
- Reject malformed URLs
- Remove tracking parameters
- Deduplicate sources
- Block known competitor/self domains when required
- Reject marketplaces or social pages when they are inappropriate
- Enforce quotas and candidate limits
- Prevent rejected URLs from accidentally re-entering the pipeline
But semantic usefulness still needs judgment.
That judgment remained in controlled AI stages such as research planning, candidate review and per-source reduction.
4. Evidence-First Source Selection
V3.1.x moved toward selecting sources based on what evidence the article actually required.
For example, an official page might be valuable for a regulation but useless for explaining a practical printing technique. A strong commercial guide might explain implementation but should not be treated as primary evidence for a legal requirement.
The system therefore began recording source role, relevance and limitations instead of treating every URL equally.
5. Competitor & Commercial Noise Locks
One failure mode was allowing commercial or competitor material to survive simply because it contained many matching keywords.
The repaired system could reject known competitor domains before scoring/rescue and prioritize genuinely useful evidence sources instead of keyword-dense sales pages.
6. Evidence Locks for Sensitive Claims
I added strict rules around claims that AI models commonly “helpfully” infer.
- Do not claim a city/country unless the source explicitly supports that location
- Do not invent a law or regulation from the article topic
- Do not use a number unless the number appears in the evidence
- Do not turn a search snippet into stronger certainty than the underlying source supports
- Record source limitations when the full page cannot be fetched
If a source does not support a local claim, the extracted fact must remain location-neutral.
7. Research Quality Became a Machine-Readable Output
The research stage stopped returning only a giant text blob.
It could return structured artifacts such as:
- Source cards
- Evidence ledger
- Source manifest
- Allowed reference URLs
- Rejected-source records
- Research quality score
- Quality flags
- Source-mix information
This means downstream writing can know not only what the research says, but also where it came from and whether the research passed quality checks.
8. Recovery Mode Instead of Fake Confidence
If normal discovery does not produce enough trustworthy research, the correct response is not to tell the writer model to “do its best.”
The V3 direction introduced explicit recovery behavior:
PASS → continue normally
RECOVERY ONLY → search/fetch additional evidence
FAIL → stop rather than manufacture an article
That is one of the biggest differences between a demo automation and a production-minded AI system.
What Happens When Something Goes Wrong?
Google/API quota is being consumed during testing:
Use cache-first/cache-only research so repeated QA runs do not waste live search quota.
A webpage returns 403, 404 or cannot be converted:
Record the limitation, skip/fallback when possible, and continue only if sufficient evidence remains.
The source is irrelevant:
Reject it during source reduction before synthesis.
The result is a marketplace, social discussion or competitor page when that is inappropriate:
Reject it before it can be rescued merely because it contains many keywords.
The model outputs reasoning instead of JSON:
Strip thinking/preambles/fences, extract the structured payload, validate it, and fail or repair if the contract is still broken.
The research is too thin:
Enter recovery research instead of allowing the writing stage to compensate with hallucination.
A local/legal/technical claim is unsupported:
Remove or neutralize the claim. The topic itself is not evidence.
The article is structurally complete but the evidence package failed:
Do not treat formatting success as content success. Block the production path.
The Current Mental Model
The system evolved into a set of specialized responsibilities:
Keyword/Topic Input → Research Planning → Search Discovery → Candidate Filtering → Fetching → Per-Source Reduction → Evidence & Quality Gate → Article Planning → Draft/Expand → SEO Metadata & FAQs → Media Planning → Validation → WordPress/Production Preparation
Different models and tools can be used where they make economic and technical sense. Local LLMs can perform controlled reduction or formatting tasks; stronger API models can be used where broader reasoning or research quality is worth the cost.
The important part is that n8n controls the process rather than giving one model unrestricted authority over the entire production chain.
What I Learned From V1 → V3
V1 taught me orchestration.
Breaking a human workflow into AI-assisted production stages.
V2 taught me research architecture.
Good writing depends on good evidence, and research needs its own discovery, filtering, reduction and synthesis system.
V3 taught me reliability engineering.
Contracts, provenance, caching, deterministic safeguards, evidence locks, diagnostics and recovery paths matter—but they must not destroy the semantic intelligence that made the earlier research good.
The biggest lesson was:
A professional AI automation is not measured by how many steps it removes. It is measured by whether it can produce useful work, explain where that work came from, detect when something went wrong, and refuse to confidently continue when the evidence is not good enough.
Skills Demonstrated
n8n · AI Automation · AI Orchestration · SEO Content Systems · Keyword Research · Web Research · Google Search API · Local LLMs · LM Studio · API Integration · Structured Outputs · JSON Validation · Source Filtering · Research Reduction · Evidence Provenance · AI Quality Assurance · Error Handling · Recovery Loops · Caching · Quota Management · WordPress REST/API · Prompt Engineering · Production AI Systems