AI Content Factory — 130 Articles and a 3.5x Jump in Yandex Search

By the team behind the «Директор по коду» ("Code Director") Telegram channel — t.me — and skillmake SEO.

This blog writes itself. Not figuratively: every morning, five scheduled jobs wake up on a timetable — one compiles a report on rankings and traffic, another beefs up the current winning article, a third writes five new articles, a fourth re-checks ten old ones for stale facts, and a fifth ships all of it to the site in a single deploy. A human appears in this scheme exactly twice: to approve edits to an important article and to log in where a robot isn't allowed. Below is a full teardown of our content factory: the architecture, the prompt behind every job, what we send to Yandex and how, real numbers from the first two weeks, and the pitfalls we already hit. All the working prompts, briefs, and scripts are public: github.com/v925619714-droid/ai-seo-article-factory.

The short version of what happened. In three weeks the factory wrote and published 130+ articles. We're building this from Russia, so our primary search engine is Yandex — think Google with its own ranking quirks. On July 11 it finally "got the taste" of the site: impressions grew from ~400 to ~1,400 a day, the number of queries in the top 10 jumped from 56 to 376, and for the query "groq api key" our article turned out to be the only Russian-language result at the top of the SERP. Here's how the whole thing is built — step by step, no magic.

What a content factory is and why you'd want one

A content factory is a system that produces content the way an assembly line produces parts: with task specs, quality control, publishing, and a feedback loop. The terminology floats around — content factory, content automation, content pipeline — the idea is the same. What separates our factory from a classic editorial team: no humans in the flow. One AI writes and checks, another AI manages the process, and Claude Code's scheduled jobs keep the timetable (more on the tool itself in "What is Claude Code").

Let me set the frame right away so nobody feels cheated: our factory makes SEO articles — not videos, not social posts, not product cards. And the second frame, which usually surprises people: the whole system is run by one person. Not a studio, not an editorial team — one owner and two AI workers on subscriptions.

This is what a factory day looks like:

Each job is a detailed plain-text playbook (a prompt) that the worker reads and executes step by step. All five playbooks live in the prompts folder of our repo — take them and adapt.

Division of labor: who writes and who signs off

There are two workers inside the factory with different roles, and that split is deliberate economics.

Kimi Code CLI does all the heavy lifting with text: writes 25–35K-character articles, re-checks old material, compiles the morning report from five data sources. It runs on a fixed-price subscription, so the volume of its work costs almost nothing extra. The current Moonshot flagship this ecosystem is built on is Kimi K3 — we covered it separately.

Claude Code is the foreman. It writes the task briefs, reviews the results (diffs, spot fact-checks, structural integrity), owns deploys, and keeps the logs. Its tokens are pricier, so the playbooks explicitly forbid it from doing anything Kimi can do.

The split didn't come from theory. Claude wrote the first articles itself — the results were good but expensive. Now the scheme is: brief → Kimi generates → Claude reviews. Quality is held by the "strict brief + mandatory review" combo, not by model choice.

One example of how strict the briefs are. The stale-article-check job carries a rule: "an article being up to date is a normal outcome — edits for the sake of the report are forbidden." Without that line, a language model starts inventing changes to show it's been busy. With it, the model honestly answers "everything's fine, here's how I checked." In the very first rotation run Kimi marked one article out of three as current and found one genuine problem in each of the other two. That's exactly the behavior you want.

08:06 — the morning report: numbers instead of vibes

The day starts with numbers. The report job wakes Kimi, which pulls yesterday's:

• Yandex Webmaster (Yandex's answer to Search Console) — impressions, clicks, average position, queries in the top 10, top queries;
• Google Search Console — the same for Google;
• Metrika (Yandex's analytics suite) — visits, sources, behavior, best articles of the day;
• the product funnel — signups and payments from the database;
• support — the site widget and the mailbox: any unanswered messages;
• app installs from the stores.

The report follows a "conclusions first, data second" rule: the first twenty lines are what needs action, the headline numbers with deltas, and a recommendation for the day. Detailed tables sit below as the evidence base. Plus a running summary since day one: one line per day in a CSV file that Kimi appends itself.

Why does the factory need this? The report is its feedback loop. The next job reads it and decides which article to boost. Without daily numbers a content factory is blind: it produces, but doesn't know what's working. How to set this data up yourself — see "SEO for beginners: Metrika and Webmaster". The full report brief is in the repo.

09:08 — boosting the winning article

The most interesting job in the factory. Every morning it reads the report and looks for a trigger:

• a new winner — some article suddenly started pulling organic traffic;
• a dip — the main query of a top article lost position;
• impressions without clicks — a query gains impressions while CTR sits near zero;
• stagnation — a top-5 article by traffic hasn't been updated in a while.

No trigger — the job honestly writes "nothing to boost today" and exits. If there is one, a process kicks off that we first ran by hand before baking it into a job.

What it looked like on a live article

Our article on the Groq API was pulling 84% of the site's entire organic traffic, and suddenly its position for the main query "groq api key" started sliding: from 7.45 to 9.24. The trigger fired, the investigation began — and found things nobody expected.

First and foremost: the working example in the article was dead. Groq had decommissioned the model the article's entire code sample was built on — a reader would copy our example and get a 400 error. No SEO magic will hold up an article that teaches broken code. And it wasn't found by reading — it was found by a live check: an API request showed the model was no longer on the list.

Second: the answer to the reader's query started 29% into the text. Someone searching "groq api key" wants the key now, and we were leading with three sections of theory. Meanwhile the competitor outranking us turned out to be several times thinner: four steps, three screenshots, nothing else. We weren't losing on depth — we were losing on ordering.

Then came the edits, strictly under the additivity principle: add, reorder, fix a fact — but don't rewrite. Ranking text is fragile; an aggressive rework tanks positions. A quick-answer block moved above the fold, the "How to get a key" and "Limits" sections moved up, the dead model was swapped for a live one, and the FAQ gained an answer for the "qroq" typo (42 impressions a month for a typo query is still traffic). The risky edit — putting "key" into the title — went in as a separate line item: with the old version saved and a check-in date seven days out. If things get worse, the job rolls it back on its own.

The full research checklist — "through the customer's eyes" (7 questions) and "from our side" (10 questions) — lives in docs/checklists.md, and the complete boost playbook is in prompts/02-article-boost.md.

The human checkpoint

Before the edits ship, the owner gets two links: the old article and the new version (a draft on the live site, closed to indexing). He looks, says "ship it" — and the machine takes it from there. This is the only mandatory human touch in the entire factory, and it stays on purpose: boosting touches articles that already earn traffic.

09:31 — the pipeline: five new articles a day

The pipeline is the heart of the factory — it's what wrote those 130 articles. It works like this:

flowchart TB
    A["Открытые темы из контент-плана"] --> B["Вордстат: частоты кластера"]
    B --> C["Отсев: порог спроса, каннибализация"]
    C --> D["Бриф для Kimi: ключи, структура, перелинковка"]
    D --> E["Kimi пишет 5 статей по 25-35 тыс. знаков"]
    E --> F["Приёмка: структура, FAQ, де-ИИзация, факты"]
    F --> G["Обложки + запись в очередь деплоя"]

Three things in this pipeline matter more than the rest.

Demand validation before writing. A topic from the content plan goes to Wordstat (Yandex's keyword volume tool) first: if the cluster's total search volume is below the threshold, the article doesn't get written at all. Generating text with an LLM is cheap, but pointless text with no demand behind it drags down the whole site's quality in the search engine's eyes. For what it's worth, this article's topic passed validation too: the Russian query for "content factory" gets almost five thousand impressions a month.

A brief with query-driven structure. Kimi doesn't get "write about X." It gets: SEO keys with volumes, an H2 structure matched to real queries, a mandatory FAQ section (the generator builds FAQPage markup from it), links to 2–4 existing articles for internal linking, and legal disclaimers where needed. A sample brief is in the repo.

De-AI-ization at review. What gives machine text away isn't facts — it's habits: "It's important to note," "In today's world," "So, to sum up," triple lists in every paragraph, a dash every other word. Search engines and readers smell it equally well. We have a detector for these tells — ai-tells-scan.mjs — which counts dash density and stock-phrase frequency across the whole site. Every pipeline article passes through it before publication. The full ruleset is in docs/de-aiization.md; we covered prompt-writing itself in "How to write prompts for Claude Code".

10:40 — rotation: old articles must not lie

With 130+ articles and five more daily, you hit a problem you don't think about at the start: articles go stale. Services change prices, kill models, rename buttons. An article that honestly told the truth in June starts lying in July — to the reader and to the search engine.

Rotation handles this by brute force: every day the 10 articles with the oldest freshness date go to Kimi for re-checking. The rules are strict:

• verify facts for real — with a request to the API, the official docs, the service's page — not from the model's "memory";
• edits are surgical: fix what's stale, don't rewrite;
• every fix ships with proof: the link or the command used to verify it;
• "the article is current" is a normal outcome.

Claude reviews the work: checks the diff (edits should amount to a handful of lines), re-verifies one or two facts itself, and rejects anything questionable wholesale. Every checked article gets a refreshed freshness date — and the rotation queue moves on. At our volume a full cycle takes about two weeks: no article goes unchecked for longer than a month.

The playbook is prompts/04-articles-refresh.md, the check brief is briefs/kimi-refresh-brief.md.

15:07 — the finalizer: one deploy instead of four

At first, every job deployed the site itself. By lunchtime that meant three or four rollouts: each with its own rebuild, its own 20-minute wait, its own verification, and its own recrawl. Jobs kept tripping over each other's deploy locks, and the token bill for this overhead ran to tens of thousands of tokens a day.

The fix is a queue. Daytime jobs no longer ship anything: they drop finished files into the repo and append an entry to a shared queue file — which files to commit, which pages to verify, which URLs to submit for recrawl. At 15:07 the finalizer arrives and does everything in one cycle: one build, one secret scan, one commit, one deploy, one check of every page and image, one recrawl, one sitemap.

The side bonus turned out to be worth more than the savings: deploys gained discipline. The finalizer ships exactly what the queue declares — a stray uncommitted tail from parallel work won't ride into production. And if something crashes, the queue survives untouched until the next run. The queue format is described in docs/logs-format.md.

This article is part of skillmake.ru — a Russian-language project about building real products with AI agents. The article you're reading is a translated case study from our production experience.

What we send to Yandex, and how

The SEO side of the factory isn't "publish and pray." After every rollout, signals go out to Yandex:

• Recrawl — every new or changed URL goes into the recrawl queue via the Webmaster API (script). The quota is 150 URLs per day per site, and it has to be rationed: articles re-checked without edits don't get recrawled.
• Sitemap — regenerated on every build; Google gets it via a Search Console API resubmission (Google has no force-indexing for individual articles — only the sitemap and patience).
• FAQPage markup — the site generator builds JSON-LD from each article's FAQ section automatically. Which is why the playbooks explicitly forbid renaming that section: it would break the markup for the whole article.
• Table of contents and anchors — the generator gives every subheading an anchor and assembles a TOC; long articles stop being a wall of text for both the reader and the crawler.

The loop closes through the morning report: positions and CTR from Webmaster flow back into the system and become boost triggers. The factory doesn't just write — it reacts to how search judged what it wrote.

The numbers: what happened in two weeks

The site is young; articles started shipping in late June. For the first days Yandex was sizing it up: impressions sat at 50–150 a day, clicks in the single digits. On July 11 came the inflection:

A 3.5x jump in impressions over two days isn't "gradually gaining weight" — it's the classic trust threshold: Yandex held the site in quarantine, judged how its first visitors behaved, and opened the floodgate. Then the long tail kicked in: 130 articles means thousands of low-volume queries, each nearly meaningless on its own, together a steady stream.

A separate observation: almost all the organic traffic of the first weeks went to a single article — that same Groq API one. That's how a content strategy works early on: you can't know in advance which of the 130 will take off, but when one does, the factory spots it in the morning report and aims the boost exactly there.

In fairness: these visits bring few sales so far, and that's normal. Informational traffic converts slowly; its job is awareness, behavioral signals, and the top of the funnel. Rough back-of-the-napkin math: at ~150 new articles a month on two subscriptions, the cost of one article lands around the price of a cup of coffee — orders of magnitude cheaper than a copywriter, so even rare long-tail conversions pay for production. In a month we'll publish a breakdown of sales from organic — same tables, same honesty as here.

Mistakes that cost us days

A list that will save you days if you set out to build something similar.

1. An LLM invents work if you let it. A "check articles for staleness" task without the rule "current is a normal outcome" turns into a generator of fictional edits. The prohibition must be explicit in the brief.
2. Facts from the model's memory are not facts. A model will confidently tell you things about a service that were true a year ago. The only real check is a live request to the API or the docs. That's exactly how we caught the dead model in our own top article.
3. An HTTP 200 doesn't mean the page is whole. One day two articles shipped with broken covers: the HTML returned 200, but the images physically weren't there. Since then every image gets checked with its own request — the rule is baked into every playbook.
4. Horizontal mermaid diagrams are unreadable in articles. A ~700-pixel column squeezes a horizontal chart into mush. Vertical only, no more than 7–8 nodes, short labels.
5. Cyrillic breaks in command-line arguments. Russian-language API queries sent from bash arrive as mojibake. The fix is simple: put the text into a UTF-8 file and have the script read the file.
6. Two AIs on one subscription throttle each other. When the pipeline and rotation launched Kimi at the same time, both crawled. We spread the start times an hour apart — problem gone.

How to take this for yourself

Everything described above lives in the open repo ai-seo-article-factory: five job playbooks, three Kimi briefs, a site generator with FAQPage markup and TOCs, the AI-tells detector, the recrawl script. MIT license — take it and rebuild it.

Just keep your expectations honest: the repo is a starter kit, not a turnkey factory. Between "downloaded the prompts" and "the system runs itself 24/7" lies a month of debugging: wiring up the Wordstat and Webmaster APIs, configuring the scheduled jobs, adapting the generator to your site, hitting your own versions of our pitfalls. A prompt is text; a system is text plus execution discipline.

What you'll have to adapt: paths and identifiers (replaced with placeholders in the files), the deploy process (we have our own wrapper with locks — you'll have your own hosting), and the project structure if your site isn't on Next.js. The principles themselves — demand validation before writing, de-AI-ization, additive edits, live fact-checking, one deploy a day — port to any stack unchanged.

The skill this all rests on is knowing how to hand tasks to an AI and review its work: it's the same skill whether you're building a content factory or your own app. That's what we teach at skillmake.ru (in Russian) — hands-on, from first prompts to a working product; the factory in this article is simply a grown-up example of what becomes possible later. And if you're at the very beginning, first read "A neural network writes code": it's the foundation without which the factory's prompts will read like incantations.

FAQ

How much does it cost per month?

A Kimi subscription (generation and fact-checks) plus a Claude subscription (management and deploys) — together comparable to what you'd pay a good copywriter for a couple of articles. On that budget the factory ships ~150 new articles a month and keeps the whole archive fresh. One-off costs are the domain, hosting, and small API bills like Yandex Wordstat.

Won't Yandex penalize the site for AI content?

Yandex punishes uselessness, not tools. Our approach: demand validation before writing, verified facts, de-AI-ization of the prose, FAQs, and structure built around real queries. A 3.5x jump in impressions over two weeks is the search engine's answer to that kind of content. Nobody can promise anything, but "written by an LLM" and "useless text" are different things, and the algorithms punish the latter.

Why does Kimi write while Claude manages, and not the other way around?

Economics. Text generation is the most token-hungry part of the job, so it goes to the worker with a fixed-price subscription. Management, review, and deploys need fewer tokens but more discipline — that stays with Claude Code. A "cheap generator + strict reviewer" pair is enough to hold the quality bar.

What happens if a job dies mid-run?

Every job is built so a crash doesn't break the system: the deploy queue survives until the next run, logs record what got done, and Kimi delivers unfinished articles file by file as they're ready — whatever's done gets accepted. Worst case is a day without new articles, which SEO won't even notice.

Do I need to know how to code to replicate this?

Write code — no; read and edit prompts — yes. The factory's entire logic is written up as plain-language playbooks (Russian, in our case). You can use the scripts from the repo as-is, and Claude Code will adapt them to your project if you show it the README and ask it to port everything to your structure.

Where do I start if I don't need 5 articles a day?

With two jobs: the morning report and a one-article-a-day pipeline. The report gives you feedback, the pipeline gives you flow. Boosting and rotation are worth adding after 30–50 published articles, once there's something to boost and something going stale.

I don't know anything about code — is this for me?

Yes, but don't start with the factory. It's a second stage: first you need to get comfortable giving tasks to an AI, reading its output, and not fearing the terminal. The fastest way to build that skill is a small tangible project — at skillmake, our Russian-language program, that project is your own app, and the same moves then scale to a content factory or anything else.

Conclusion

A content factory isn't "hey AI, write articles." It's a system with role separation, demand validation, fact control, search-engine feedback, and deploy discipline. The AIs in it are labor; the value is created by the playbooks — they encode the experience that keeps the system from repeating other people's mistakes.

Build your own — the prompts are open, the rakes are documented, the numbers are honest. The follow-up with a sales breakdown lands in a month, in this same case-studies section: the wins, and the things that won't pan out.

Sources

1. The factory repo (prompts, briefs, scripts): github.com
2. The «Директор по коду» Telegram channel: t.me/+J9kyMU5oZotiN2Ji
3. Yandex Webmaster API (recrawl): yandex.ru/dev/webmaster
4. Yandex Wordstat: wordstat.yandex.ru