Dynamic blogs with blogwriter: repair, extend, or retire

Dynamic blogs with blogwriter means a post that keeps watching itself after it ships, instead of just sitting there getting more wrong every month while nobody checks back. Most blogs never get that far. You write the post, it goes live, and that's it: a publish date, and nothing after it. This flips that. A post gets repaired, extended, or retired on its own when the world around it moves.

In short: every post is one of nine content types. Over time it needs one of three things done to it: repaired, extended, or retired. Four signals decide which one. A loop checks those signals, proposes the change, waits for a human to approve it, applies it, publishes it, and then remembers what got approved so the next decision is faster.

Nine kinds of posts, not one

According to me, there are nine types of blocks a blog is built from. Knowing which one a post is matters, because "update the post" means something different for each of them.

1. Listicles, the ranked or grouped list.
2. How-to posts: how to write a blog, how to build something, how to create something.
3. Comparison blocks put two platforms, tools, or people side by side.
4. Explanatory posts pick a topic and work through the how, the why, and the what.
5. Glossary. Closer to a dictionary entry than a post: for each word, where it came from, then deeper into the topic from there.
6. Product-led posts are product guides, walking through what the product actually does.
7. News or roadmap, which is where announcements live too.
8. Case studies.
9. Opinion.

Nine types, and each one goes wrong differently. A how-to post ages by going stale: the steps stop matching the current version of whatever it's teaching. A glossary post ages by going shallow, because the definition was fine but the conversation around the term moved past it. A news post ages by going irrelevant. The announcement happened, there's nothing left to add. That's exactly why one blanket "refresh old content" pass never works as well as it should.

Repair, extend, or retire

For all nine types, there are three things that can happen to a post over time.

Repair fixes what's already there without adding anything new. Wrong numbers, dead links, an outdated screenshot: same post, same scope, just correct again.

Extend takes the topic further. Either it moves the reader from awareness to a deeper conversation, or something genuinely new happened around the topic and the post needs to say so.

Retire is for a topic that's gone very quiet: old, and nobody is searching for it in Search Console anymore. Not every stale post deserves a rewrite. Some of them just need to come down.

Deciding which of the three applies is the harder problem, and it comes down to four signals.

The four triggers

1. Search Console or Ahrefs results. Analytics, whether that's Search Console or Google Analytics, plus the scroll depth on that specific post: how far people actually get before they leave.
2. Competitor monitoring. A competitor starts writing about the same topic.
3. Intent mapping. A sudden spike in Ahrefs or analytics traffic around a topic.
4. Community signal. People start talking about it on Twitter, on Reddit, or a YouTube video pops up on the subject.

Any one of these firing is enough to start the loop. Not all four.

The loop behind dynamic blogs with blogwriter

The mechanism that turns a trigger into a published change runs as a loop, not a one-off script.

1. Fetch and verify. Check every trigger above. Did anything actually fire?
2. Propagate. If something fired, work out which post it points to: which one needs extension, which needs repair.
3. Propose. Decide the outcome, repair, extend, or retire, and what the repair or extension should actually contain.
4. Approve. A human signs off before anything gets touched. This is the step that keeps "minimum human intervention" from becoming "no human intervention."
5. Apply. The approved changes get made.
6. Publish. A review pass, then it goes live.
7. Learn. After publishing, the system looks back at what got approved and what didn't. Which block types tend to get repaired, which get extended, how far an extension usually goes, which topics get retired. That pattern becomes a skill, and the skill keeps improving as more posts go through the loop.

Learn feeds back into fetch and verify. It isn't the same run the same way forever; what it learns changes how confidently it proposes the next repair or extension.

From a tweet to a published post

Here's the part that's easy to miss. The loop doesn't start at the blog. It starts at the trigger.

Say a topic spikes on Reddit, or Twitter, or shows up as a jump in Ahrefs. The agent's first move is to search across the whole content cluster for an existing post, or a synthetic chat, already covering that keyword or topic.

• If a post already exists, it goes into the pipeline at the propagate step: repair or extend, decided the way described above.
• If nothing exists yet, it skips straight to creating a new post from scratch.

Either path lands on the same writer, but the two paths need different things from the codebase. Creating a new post is the easy case, since the codebase already supports it end to end, but repairing or extending an existing one can ask for something the codebase doesn't have yet, and that's where it gets interesting. Say the proposal calls for a live timeline embedded in the post, or a live trading-view style chart. If that embed type isn't supported, the writer passes that requirement to a coding agent instead of guessing at it. The coding agent builds what's missing, pushes it to a branch, and the post builds against that branch. Only then does it go to approval and publish through the CMS. New posts skip that whole detour. Codebase's ready, so it's approval and publish, straight through.

That's the shape of it. Dynamic blogs, blogs that update themselves, with as little human involvement as the approval gates allow. Not none. Just less than reading every old post by hand ever needed.