Building a website with Claude Code: how Guide2Japan writes, translates and publishes itself
Nick van der Blom5 min read
"Building a website with AI" usually means: a tool generates a template, you fill in the copy. That is not what this article describes.
Guide2Japan.com is a travel site with a mission: send travellers where the crowds are not. The site is largely researched, written, edited, translated and published by AI agents. I approve twice per article. Everything in between is autonomous. This is how it fits together, including the rule that stops the AI from inventing temples.
Two reasons. I wanted to test my thesis that an entire site can be run from one AI workspace, and I wanted to do it on terrain where I have nothing to contribute except the system. Japan is the testing ground; the mechanism is the point.
The mission is not decoration: over-tourism is a real problem in Japan, and the best answer is better information. Every popular destination on the site has a "Consider X instead" section with a quieter alternative.
Everything in the system falls into one of three layers. That separation is why it stays maintainable.
| Layer | What it is | Example |
|---|---|---|
| Workflows | The recipe: which steps in which order | "New article: strategy → brief → approve → write → edit → SEO → approve → translate → publish" |
| Agents | The thinking, each with its own instruction file | Strategist, writer, editor, SEO specialist, translator, affiliate checker |
| Tools | The execution: scripts that do something in the outside world | Publish to the CMS, look up facts, generate photos, post a Slack message |
When something goes wrong, the question is always: is the recipe wrong, is an agent thinking wrong, or is a tool failing? That turns debugging into minutes instead of hours.
The rule that carries everything: facts in a database, prose in the CMS
The biggest risk of AI travel content is not bad style. It is an invented restaurant. That is why the facts do not live in the copy.
- Every named place (temple, ryokan, restaurant, viewpoint) lives in a database with name, location, source and a status of "verified" or not.
- The writer agent may only name places that are in that database, and must mark them with a reference.
- The QA agent rejects any article that names a place it cannot verify. No exceptions, not even when the rest of the text is beautiful.
Just this week the QA agent rejected an article over a single restaurant the writer could not substantiate. That is the system working, not failing.
Two approval moments, nothing else
Every article moves through a fixed series of statuses. A human stands at exactly two places:
- Gate 1, the brief. The strategist agent proposes the topic, the angle and the search intent. I approve or redirect. This is the moment to steer on mission and on what the site still lacks.
- Gate 2, before publishing. After writing, editing, SEO check and QA, I read the article. Good? Then the pipeline translates and publishes on its own.
Everything between those two moments happens without me. That is the design choice: not "as little human as possible", but "the human at the two places where it matters".
The control panel is a conversation
There is a dashboard, but day-to-day management runs through Slack. The bot reports "brief ready for article X", I reply with approval or feedback from my phone, and the pipeline continues. Overnight routines work through the queue without anyone at a keyboard.
Every agent call logs its own tokens and cost, per article. So I know exactly what a published, edited and three-times-translated article costs. I will share the figures as a rounded range in a follow-up article, but the conclusion I can give now: compute is not the biggest cost. Setting up context, limits and the facts database was.
What this means for your own site or store
You do not have to build a travel site to benefit. The patterns transfer:
- Separate facts from copy. For a store: product data (sizes, materials, prices) in the system, copy that refers to it. AI may describe, not invent.
- Choose your two approval moments. For a store: the brief and the page before publishing. Not every step, not none.
- Let the control panel come to you. A Slack or email message with "approve / adjust" is enough.
- Log what it costs. Otherwise you never know whether AI content was cheaper than the copywriter.
How to build this step by step, from one automated task to a site you manage from one workspace, is in the article on running your store with AI.
Frequently asked questions
Is this "vibe coding"? Partly. The site was built with Claude Code by describing what I wanted. But the system around it (facts database, approval moments, cost log) is the opposite of vibes: it is precisely defined what may and may not happen.
Can Google see this as spam? Google judges content on usefulness and reliability, not on who typed it. The facts database and the editor agent exist precisely to prevent thin or incorrect content. I will share results once there is enough data.
How much of your time does it take per week? Two approval moments per article, from my phone. The rest is system maintenance when something breaks, and I log that too.
Can you build something like this for my store? Yes, and it starts smaller than this: one task, then the next. An audit of your current setup is the first step.
Want to know what such a system would look like for your site? Request a free audit.