taupe Building, using, and running it.

Article

Rewriting twenty years of blog posts with an AI team

Rewriting twenty years of blog posts with an AI team

I am rewriting blog posts I wrote years ago, with an AI team. Not polishing prose — pulling old articles back into being usable media assets.

The loop is: read Search Console, look at what is still popular, re-read the live page, then work through title, description, opening, headings, image alt text, internal links, and affiliate placement. Save, verify the rendered HTML, record it in docs, and observe at 7, 14, and 28 days.

The rule that matters most: on a post that already gets traffic, not breaking it comes before improving it.

Originally published in Japanese on June 4, 2026. This English version was written in September 2026.

Old posts are still someone’s current page

Posts from years ago still take search traffic. Some surface in Google Discover. Some still get product-link clicks. Some are the entry point to another article.

To me it is an old post. To the reader it is the page they are on right now — with stale information in it, a weak opening, missing image alt text, no internal links, and affiliate products that no longer match what the searcher wants.

Adding new posts matters. Re-growing the ones already being read matters about as much.

Hundreds of posts, one person

There is a practical problem. Twenty-plus years of blogging, and moss.fish and isLog each hold hundreds of posts.

Doing one properly means reading the title, reading the body, considering search intent, checking what has gone out of date, thinking about internal links, fixing alt text, revisiting affiliates, editing in WordPress, verifying the published page, and recording it. That is real time — multiplied by several hundred, on top of writing new posts, reviewing daily numbers, posting to X, and improving the sites.

It does not fit. So it runs as an AI team: not handing the work over, but splitting it into roles and working like an editorial desk, in order, from the posts that most deserve attention.

This is not AI-generated content

The point is the opposite of mass production. These are articles I already wrote — fish I caught, meals I ate, places I walked, gear I used, things I tried on the web and with AI — being re-read alongside the agents and reshaped to reach a current reader.

Not written from nothing by an AI. Re-grown, from an experience that was mine. That distinction carries most of the weight here.

The Codex app as the editorial workspace

I do not hand the whole job to one thread. Selecting candidates, reading the live article, organizing search intent, deciding what changes, editing in WordPress, verifying the rendered HTML, and recording the result are split across threads and roles.

One thread organizes rewrite candidates: what search demand exists now, which posts remain popular, where affiliate clicks appear, and whether there are early signs of AI-referred traffic.

Then the target article gets read — the live URL, the current title, description, H1, H2s, images, internal links, and commercial routes — and the change plan is settled before anything is edited. What to change, what to leave, what to hold. On a high-traffic post especially, deciding that first is what keeps the rewrite calm.

Search Console first, then the article itself

Candidates are not chosen on instinct. Search Console queries come first: which terms are appearing recently, which topics are gaining impressions, which posts are converting impressions into clicks. Then the popular-posts list for each site — old articles still being read, still holding search traffic, still generating affiliate clicks, or starting to show traffic from AI services.

But numbers do not decide it alone. The article gets read: is it usable as it stands today, is stale information getting in the way, does it answer the reader’s question early, and which parts should stay as a record of the experience? Numbers and body text, both, before starting.

The more traffic, the smaller the edit

The danger in rewriting is over-editing. A post with search traffic, with clicks, read for years, is being read for a reason — the title, the specificity of the experience, the photos, or simply that it hits what the reader wanted despite being dated. Break that and you have removed the thing that was working, with good intentions.

So on high-traffic posts: keep the URL, keep the core of the body, keep whatever matches search intent, supplement only the information that has gone stale, tidy the opening and description, add internal links, and rewrite alt text into natural sentences. Do not break it, then improve it.

Title, description, and opening for a current reader

These are usually the first things to change. Old titles often lean diaristic — which is part of what that era of blogging was — but a reader arriving from search cannot always tell what the piece is.

For a fishing post: what was caught, how it was eaten, what gear was used, whether it is for beginners or a hands-on review. Make that visible in the title and the opening and the reader can get in.

Descriptions get shortened, lead with what the article establishes, and drop dated phrasing. Openings touch the reader’s question first. The body’s experience stays; only the entrance is adjusted.

Stale facts and alt text

Old posts drift on facts: shop information, opening hours, prices, transport, service specifications, product lineups, app screens, external service terms. Where it matters, it gets re-verified against an official site or a reliable source.

Internal figures and admin-console detail never go into the published body. The body is corrected only as far as a reader needs in order not to be misled today.

Alt text gets revisited too — old posts often have stale or empty alt attributes. Now they are natural sentences describing what the photo shows. Not only for search: it is part of the article being properly readable.

Internal links turn points into a surface

Fixing posts one at a time leaves them as isolated points. Connecting the related ones makes a surface.

Catch it, clean it, slice it, age it, cook it, then out to the gear. A travel hub article into the individual sights, and each sight back to the overview. Add those links and old posts stop being scattered records and become something readable as a set.

Writing new posts is not the whole of running a media property. Connecting the existing ones is part of it.

Affiliates only where they match intent

Commercial routes get reviewed too, without adding product links indiscriminately. If a reader is looking for gear, a product link genuinely helps — a long-term tent review can reasonably point at the tent and the accessories actually used; a tackle post can point at the gear used and near alternatives.

A product unrelated to the article’s flow just reads as an ad. So: do not hide the commercial route, but remove it where it does not match the article’s intent, and keep only what helps the reader decide.

Five worked examples

moss.fish: the shiriyake cuttlefish cluster

On moss.fish, the posts about shiriyake cuttlefish were rewritten as a cluster rather than individually: the fishing trip, the sashimi, the cooking, the modified squid jig, and the soy-marinade preparation. Catch it, clean it, slice it, age it, cook it, then out to gear and preserves. The work itself was dull — tidy titles and descriptions, state in the opening what the article establishes, add internal links between trip, cooking, and gear posts, rewrite alt text, check the featured image size — but done together, the points become a surface.

isLog: the Narita Terminal 3 food court

On isLog, a food-court article about Narita Airport Terminal 3 got rewritten. That kind of post is highly practical: which restaurants are there now, what you can eat before security, what is available after it, and what the reader needs to decide before leaving for the airport. Stale shop information makes it unusable, so current information was verified and the routes reorganized — shorter description, opening and conclusion reshaped for a decision, natural-sentence alt text, internal links to related Narita articles, and a check of the rendered HTML.

isLog: Nokogiriyama, reorganized as parent and children

Also on isLog, the posts about Nokogiriyama — a low mountain in Chiba with a well-known clifftop lookout — were organized into a parent and children: the overview article catches the whole, and the child articles cover individual sights. It makes the relationships between posts legible to a reader arriving from search and to one arriving via an AI service.

On taupe, old how-tos against current behavior

This site’s top posts get the same treatment, and they are unusually exposed to specification changes: running two LINE accounts on a PC, desktop LINE notifications, hiding certain ad categories, the AdSense ad review center, reverse geocoding, Evernote device limits.

Old screenshots, old steps, old service terms, assumptions that no longer hold — all of it costs the article its credibility. So each is brought in line with what can be confirmed as of 2026: is the old screenshot presented as a period record, or is the explanation updated to current behavior, do internal links get added, does the affiliate route stay or go. One article at a time.

The camping-gear post: preservation over improvement

A clear case on moss.fish is the Coleman Tourdome LX post — a camping-gear article with real traffic, real readership, and a real commercial route. Exactly the kind you do not rebuild.

The URL stays. The existing pitching review stays largely intact. The title shifts toward a long-term review. The description gets shorter. The opening gains what a reader needs up front: comfortable for solo or two people, cramped for three, and worth confirming the current model. A 2026 note comparing LX and LDX was added, the featured image and alt text tidied, internal links to related camping posts added, and affiliates matching the article’s intent kept.

On a high-traffic post, not breaking it comes before improving it — and that judgment was made with the agents rather than around them.

Verify the rendered page, not the editor

Saving in WordPress used to be the end. Now the published HTML gets checked: is the title reflected, has the description changed, is the H1 what was intended, are the OG and Twitter images being emitted, are the internal links correct, is the alt text present?

Things that look right in the editor can break on the live page — caching, theme output, a stale OG image. So the last step is opening the published URL. Only then is the rewrite complete.

Record it, then observe at 7, 14, and 28 days

A rewrite does not report back immediately. Search does not move at once, Discover is unreadable, product-link clicks wobble day to day, and AI referrals can appear out of nowhere.

So each one is recorded in docs: which article, what changed, what deliberately did not, which metrics to watch, and when to look again.

Day 7 is anomaly detection — is measurement intact, is the layout broken, has a click route disappeared? Day 14 is early direction — how did the query mix move, is there internal navigation, are related posts being read together? Day 28 is a first assessment across search, navigation, commercial routes, and AI visibility, feeding the choice of what to fix next.

Editing is not the job. Editing plus observation is the job.

Closer to an editorial desk than a writing tool

Running this, an AI team feels less like a text generator and more like a desk: an editor choosing candidates, a researcher reading the live article, an analyst on search intent, an editor on titles and openings, an operator in WordPress, an implementer on alt text and internal links, QA on the rendered HTML, a documentarian, and an analyst at 7, 14, and 28 days.

None of it runs perfectly on its own, and the final calls are mine: do not change this one much, keep that product link, add this internal link, that title goes too far, leave this alone for now. What the team buys me is the number of articles that can be looked at at all.

Still in progress

This is nowhere near finished. Out of several hundred posts, only a fraction has been touched. Nothing here is a demonstrated result — no before-and-after traffic figures are being claimed.

What has changed is how I look at them. Not old posts, but assets: still read from search, seasonal, carrying a commercial route, starting to be found by AI, able to carry a reader onward to another article.

Write new ones, look at old ones, fix, connect, verify the live page, record it, look at the numbers again. That loop runs with an AI team in the Codex app — an unfinished system, with the sense that the posts are gradually turning back into media assets.

References

Next

These notes come from running this setup daily.

About the author

Hidekazu Ishikawa

Hidekazu Ishikawa builds and runs web products with AI agents from Japan. Available for consulting on AI workflow design and web development.

Next

Keep reading.