TL;DR
When people hear “build an article site with AI,” they often imagine this:
Ask AI to write 100 articles, upload them, done.
Nope.
That is like buying a photocopier and announcing that you have built a library.
A real AI-powered content site must stay understandable as it grows. Readers should not get lost. Old translations should not masquerade as current ones. Language versions should not cross wires. Links should not rot. Two automations should not overwrite each other. And when something breaks, the system should be able to detect the problem and recover safely.
So do not treat AI as a “writing machine.” Treat it as a team of writers, editors, inspectors, librarians, road builders, and maintenance workers.
The whole system can be understood in ten steps:
- Decide what the site is for.
- Build the land and warehouse where content lives.
- Give every article a stable identity and a fingerprint.
- Create one strong source-language article first.
- Run quality checks before translation.
- Expand into 12 languages without copying mistakes.
- Build internal links and hub pages as roads and information desks.
- Run the factory by state, not by the clock alone.
- Do not call something “published” until the real production page is verified.
- Compare the site with a 100-point ideal state and repair gaps continuously.
If you simply tell AI, “Make a nice content site,” the AI neighborhood association may happily build three copies of the same house and six roads to nowhere.
The most important technology is not smarter AI.
It is a safer system.
First mental model: the site is a library + road network + factory
Use these analogies:
- Article = a book
- Site = a library
- Category = a bookshelf
- Hub article = an information desk
- Internal link = a road between useful places
- URL = an address
- Article ID = a permanent registration number
- Hash / SHA = a fingerprint of a particular version
- GitHub = a warehouse containing files and history
- QA = a teacher checking homework with a red pen
- Deploy = actually opening the library to visitors
- Monitoring routine = a night guard
- CAS / conditional update = “replace this only if it is still edition 3”
- Stage token = a stamp proving that this exact version passed a stage
Once this picture makes sense, most of the “scary technical words” become ordinary traffic rules.
1. Decide what the site is actually for
1-1. Do not make article count the goal
A terrible goal is:
Publish 100 articles per day.
If those 100 articles answer the same question, have broken links, repeat each other, and contain stale translations, you did not create knowledge.
You created 100 trash bags at high speed.
A better goal describes what readers can do:
- find an answer quickly
- know where beginners should start
- move naturally to deeper explanations
- understand how related articles fit together
- reach equivalent information in their own language
1-2. Define rules AI is never allowed to break
AI becomes more useful when it has freedom, but unlimited freedom creates accidents.
Set non-negotiable rules first:
- never expose personal information
- never silently change dates or numbers
- never invent sources
- never treat stale translations as current
- never publish broken URLs
- never send a Japanese reader to an unrelated English article as a content fallback
- never let two workers silently overwrite the same work
- never accept “AI says it is done” as proof of completion
These are the guardrails around the factory.
1-3. Write down the 100-point ideal state
If the ideal is explicit, the system can ask:
What score are we at now?
Why are points missing?
Which gaps can be repaired safely?
What is the score after repair?
That is the basic QC loop: define quality, observe the gap, fix the cause, and verify again.
2. Build the land and warehouse
2-1. Minimal stack
A beginner-friendly setup needs only a few pieces:
- a domain
- GitHub for files and change history
- a web framework
- hosting
- analytics
Astro, Next.js, Eleventy, or another framework can work. The key architectural idea is more important than the brand:
separate content data from the program that renders the site.
2-2. Separate source content from generated results
Do not let every automated worker directly rewrite the source file.
Keep different layers for things such as:
- source article
- edited version
- translations
- internal-link overlays
- QA evidence
- publication state
Imagine raw chicken in a kitchen. You do not let every cook pour random sauce directly into the refrigerator.
Preparation, cooking, plating, and inspection should be separate stages.
2-3. Use Git history as a time machine
Git records what changed and allows rollback.
Automation should therefore:
- make small, explainable changes
- record why the change exists
- avoid force-overwriting history
- save checkpoints during long batches
3. Give every article a stable identity and fingerprint
3-1. Do not use the URL as the only identity
URLs and titles can change.
Give each logical article a stable ID, for example:
articleFamilyId = article_000123
This is the article’s registration number.
Japanese, English, and Korean versions that represent the same logical article share the same family ID.
3-2. Treat locale as a separate dimension
Think of the content as:
article_000123 + ja
article_000123 + en
article_000123 + ko
Now the system can represent:
- English is stale
- Korean is missing
- Japanese changed today
- French is current
without confusing the entire article family.
3-3. A hash is a fingerprint
A content hash changes when the content changes.
This answers a crucial question:
Which source version was this translation made from?
If Japanese changes but the English translation still points to the old Japanese fingerprint, English is stale.
No debate is required.
The evidence says so.
3-4. Keep explicit states
Useful states include:
- draft
- source-language QA passed
- translating
- translation QA passed
- navigation validated
- eligible for publication
- published
- stale
This state machine becomes the backbone of automation.
4. Create one strong source-language article first
4-1. Fix the source before translating it
If the source is bad and you translate it into 11 more languages, you have simply globalized the bug.
Congratulations: the mistake now has international distribution.
Finish one source language first.
4-2. Minimum standard for a strong article
A good article should have:
- a title that clearly says what the page solves
- an opening that addresses the reader’s question
- headings that make sense even when skimmed alone
- plain-language explanations of technical terms
- concrete examples
- preserved numbers, dates, names, and uncertainty
- clear separation of fact and opinion
- sources when the claim needs them
- no personal information
- little pointless repetition
- less generic “AI template” phrasing
4-3. Humor should help meaning
Useful joke:
Translating a broken source into 11 languages is like cloning a crooked house eleven times.
The joke makes the rule easier to remember.
A joke that has nothing to do with the topic is just street performance in the middle of a road construction zone.
5. Run QA before translation
5-1. “Generated” does not mean “finished”
AI output is a submission, not a passing grade.
Check at least:
- title and body agree
- facts did not change
- dates, prices, and units remain correct
- URLs exist
- citations were not damaged
- Markdown or HTML still parses
- heading hierarchy is sensible
- personal data is removed
- risky certainty was not added
- the page does not duplicate an existing article’s purpose
5-2. Store evidence, not just a green label
A strong system records:
- article ID
- source fingerprint
- output fingerprint
- QA result
- what changed
- which rule passed or failed
“Did you do your homework?”
“Yes.”
That is weak evidence.
“Show me the notebook.”
Much better.
5-3. One bad item should not stop the entire factory
If one of 100 articles is unsafe to process:
- defer that article
- record why
- continue with another eligible item
One missing screw should not trigger a city-wide blackout.
6. Expand to 12 languages without copying the mistakes
6-1. Fix the supported locale list
For example:
ja / en / ko / zh-Hans / zh-Hant / es / pt-BR / id / th / vi / fr / de
A fixed set simplifies routes, QA, hreflang, sitemaps, and navigation.
6-2. Use a distinct URL for each language
For example:
/ja/articles/...
/en/articles/...
/ko/articles/...
Then use hreflang to describe which URLs are language alternatives of the same content.
6-3. Reuse translations that are still current
Do not retranslate everything on every run.
- current translation → reuse
- stale translation → update that locale
- missing translation → create it
This reduces cost and reduces the number of places where new bugs can appear.
6-4. Do not copy source-language word order
Translation is not find-and-replace.
Adapt:
- sentence length
- heading wording
- transitions
- jokes
- anchor text
- explanation order
Preserve meaning, not the shape of the original sentence.
6-5. QA each article × locale independently
Passing English QA tells you nothing about Thai QA.
Treat each articleFamilyId × locale as its own quality unit.
A failure in one locale should not automatically stop the other eleven.
7. Build internal links and hubs as roads and information desks
7-1. Do not add links just to add links
Google recommends descriptive, relevant anchor text and internal links that actually help readers discover useful pages.
Good:
Beginners may want to start with the guide to choosing retinol concentration.
Bad:
Click here.
A road sign that says “somewhere” is not a useful road sign.
7-2. Separate link types
At minimum, distinguish:
- Hub structural links — information desk to detailed pages
- Body contextual links — natural references inside a paragraph
- Related recommendations — onward reading
- Language alternates — same article, another language
- Breadcrumbs — navigation back through the site hierarchy
If all links are treated as one bucket, rules eventually collide.
7-3. Content navigation should stay in the same language
A Japanese article should not fall back to a random English article merely because the Japanese target is unavailable.
Changing language is one action.
Moving to another topic is another action.
Keep them separate.
7-4. A hub is not a pile of links
A good hub explains:
- what the theme covers
- who the hub is for
- where a beginner should start
- the main subtopics
- which detailed article fits which question
- how readers can go deeper
Twenty naked URLs are not a hub.
That is an information desk where the employee went home and left a route map on the chair.
7-5. Promote an existing broad article before creating a new hub
Otherwise you end up with:
- Complete Guide
- Ultimate Guide
- Full Guide
- Everything You Need Guide
all fighting each other for the same intent.
That is not information architecture.
That is an SEO battle royale.
7-6. Use machine candidates plus semantic review
Large sites such as GOV.UK have used semantic similarity, link graphs, and user-journey data to generate related-link candidates.
The safer pattern is:
- machine produces candidates and evidence
- semantic reviewer checks intent and usefulness
- validated writer applies changes
- audit confirms the result
The candidate should explain why the relationship exists, not just return a mysterious score.
8. Run the factory by state, not by the clock alone
8-1. Schedules are alarm clocks
You might schedule:
- minute 02: hub processing
- minute 07: source-language editing
- minute 27: translation
- minute 37: internal links
- minute 58: publication
That is fine.
But “it is minute 27, therefore source-language editing must be finished” is not fine.
The clock wakes the worker.
State decides whether the worker may proceed.
8-2. Check the upstream stamp
Before translation:
- source is current
- QA is current
- article ID matches
- source fingerprint matches
Before internal-link application:
- locale content is current
- route is current
- quality state is current
Before publication:
- content
- locale
- navigation
- canonical
- hreflang
- sitemap
- validation
all need current evidence.
8-3. Use content-addressed stage tokens
A weak token is:
done = true
A stronger token represents what was completed, for example:
article ID
+ locale
+ content hash
+ route
+ rule version
+ upstream token
If upstream content changes, the downstream token no longer matches and becomes stale automatically.
8-4. Use conditional updates / CAS
Two AI workers may read version 3 at the same time.
Worker A writes version 4.
Worker B then tries to write its result based on version 3.
Without a guard, B can erase A’s work.
The safer rule is:
Apply my write only if the resource is still the version I read.
If not, re-read and retry or defer.
It is how you stop two AI students from erasing each other’s homework in the hallway.
8-5. Save checkpoints
If a batch targets 50 articles, save progress every few successful items.
If the run stops at item 20, resume from item 21 instead of restarting from zero.
Video games solved this problem decades ago.
Use save points.
9. “Committed to GitHub” is not the same as “published”
9-1. Publication is a sequence
A healthy pipeline resembles:
content complete
↓
translations current
↓
navigation validated
↓
validation passed
↓
publication allowed
↓
deploy
↓
production HTML checked
↓
production verified
9-2. Do not force unfinished locales live
If Japanese, English, and German are current but Korean is stale, your architecture should be capable of deferring Korean without pretending it is current.
Depending on your publication policy, other eligible locales may continue.
One student tying a shoelace does not require closing the school.
9-3. Validate SEO plumbing
Check:
- title
- description
- canonical
- hreflang
- sitemap
- robots/indexability
- structured data
- redirects and 404s
- internal links
Multilingual routing is especially easy to mis-wire.
9-4. Fetch the real production page
A commit exists.
The build passed.
Deployment reports success.
Still not enough.
Fetch the actual URL and verify:
- HTTP 200
- current content
- correct locale
- correct title and metadata
- correct canonical and hreflang
- working internal links
Do not say “delivery complete” because the lunchbox is sitting by your own front door.
10. Build a site that keeps returning to 100 points
10-1. Run the QC loop every time
A useful auditor follows:
observe
↓
score
↓
find gaps
↓
classify root cause
↓
repair safely
↓
re-test
↓
re-score
10-2. Hard gates beat score gaming
Even if weighted scoring reaches 100, do not allow a 100-point claim when there is:
- a broken link
- a cross-locale content link
- stale translation treated as current
- a missing hub member
- duplicate formal success
- a lost update
- fake validation evidence
These are hard gates.
10-3. Repeated incidents should improve the factory
If the same broken-link accident happens repeatedly, do not spend eternity patching individual links.
Ask:
- contract problem?
- validator missing?
- state model weak?
- concurrency guard missing?
- schedule collision?
- external infrastructure problem?
Then fix the layer that allowed the accident.
The goal moves from:
repair the defective product
to:
build a factory that produces fewer defects.
10-4. Do not stop monitoring at 100
A site can be perfect today and regress tomorrow after new content arrives.
That is normal.
The auditor’s job is to bring:
98 → 100
again.
Firing the guard because no thief came yesterday is a strange security policy.
The whole system in 30 seconds
Human sets goal + non-negotiable rules
↓
100-point ideal state
↓
AI creates source-language content
↓
QA + evidence
↓
11-language expansion
↓
per-locale QA
↓
internal links + hubs
↓
state / fingerprint / token checks
↓
validation
↓
publication policy
↓
deploy
↓
real URL / HTML verification
↓
user-behavior measurement
↓
compare with ideal state
↓
safe repair
└────────→ repeat
Ten classic AI-content-site accidents
“We made 100 articles!” — 30 answer the same question.
Article count became the goal.Bad source → bad content in 12 languages.
Internationalized bug.Translation file exists, but it is stale.
“Exists” and “current” are different properties.Japanese page suddenly links to an English related article.
Language switching and topic navigation were mixed together.Too many hubs.
An information desk next to another information desk next to another one.Every anchor says “click here.”
Every road sign says “that way.”Two AI workers overwrite the same article.
Classic no-CAS accident.Target 50, one success, status says complete.
Please return to arithmetic class.Commit exists, therefore published.
No. It is still in the warehouse.Monitoring finds an error, so someone disables monitoring.
Smoke alarm rings → unplug smoke alarm. Outstanding strategy.
Minimum implementation checklist
Design
- ☐ reader outcome defined
- ☐ 100-point ideal state written
- ☐ hard prohibitions defined
- ☐ stable article IDs
- ☐ locale as separate dimension
- ☐ content fingerprints stored
Content
- ☐ source-language QA
- ☐ privacy removal
- ☐ facts / numbers / URLs protected
- ☐ concrete examples
- ☐ generic AI-template prose reduced
Multilingual
- ☐ separate language URLs
- ☐ hreflang managed
- ☐ source fingerprint recorded
- ☐ stale locales update independently
- ☐ QA per locale
- ☐ no cross-locale content fallback
Links and hubs
- ☐ hub structural links separate from body links
- ☐ descriptive anchors
- ☐ orphan audit
- ☐ broken / self / duplicate / cross-locale audit
- ☐ existing article promotion checked before new hub
- ☐ duplicate-hub audit
Automation
- ☐ state, hash, and tokens gate downstream work
- ☐ claim / CAS for concurrent writes
- ☐ checkpoints
- ☐ exactly-once formal success
- ☐ one failure does not stop all work
Publication
- ☐ validation passed
- ☐ canonical / hreflang / sitemap checked
- ☐ publication policy checked
- ☐ production URL fetched
- ☐ production HTML verified
Maintenance
- ☐ periodic ideal-state scoring
- ☐ hard gates
- ☐ recurring incidents fixed at root cause
- ☐ monitoring remains active after reaching 100
Final lesson: the most important part of an AI site is not the AI
The strongest AI content site is not the site with the fanciest generation model.
It is the site that can remain correct when AI:
- makes a mistake
- becomes stale
- runs concurrently
- encounters an external failure
- has to resume after interruption
Humans define:
- the purpose
- the ideal state
- the boundaries
- the final responsibility
AI handles:
- generation
- comparison
- inspection
- repair
- evidence collection
And completion is proven with external evidence such as:
- hashes
- tests
- Git history
- real URLs
- real rendered HTML
- reader behavior
At that point, the “blog” has become a tiny publisher, library, road authority, and QC factory running inside a repository.
Start small.
Give one article a stable ID.
Add QA.
Add one locale.
Add safe links.
Add state tracking.
Then automate one layer at a time.
You do not need to build a space station on day one.
But please do not buy 100 photocopiers and announce that the space station is complete.
