Migrating a 20-Year WordPress Blog to Be Agent-Ready
I thought I was moving a website. I ended up reconsidering how knowledge should survive the next generation of the internet.
I wrote my first technical article in 2001. It was about messaging-oriented middleware, long before cloud computing became mainstream, before smartphones reshaped how we consumed the internet, and long before anyone imagined that AI systems would one day read our websites on our behalf.
In 2004, I started publishing on WordPress.
I kept writing through the rise of service-oriented architecture, cloud computing, mobile, IoT, blockchain, machine learning, generative AI, and now agentic AI.
Over more than two decades, the writing accumulated.
So did the places where it lived.
Long-form articles remained on my blog. Newsletters and shorter ideas increasingly moved to LinkedIn. Videos found their home on YouTube. Podcast episodes went to Spotify. More than twenty-five books were distributed through publishers and online storefronts.
Every decision made sense at the time.
Each platform gave me something valuable: reach, convenience, distribution, community, or a better way to communicate a particular format.
But after twenty-five years of publishing, I realized something uncomfortable.
I had built a body of work, but I no longer had one body of knowledge.
My ideas were scattered across platforms, formats, databases, feeds, pages, applications, and systems that I did not fully control.
That realization led me to rebuild my website.
But the most important decision came before I wrote a single line of code.
I asked myself a different question:
If I were building this website for the next twenty years rather than the previous twenty, who exactly am I building it for?
The obvious answer was people.
The less obvious answer was AI agents.
That second answer changed almost everything.
The Next Reader May Never Visit Your Website
For most of the history of the web, publishing followed a familiar pattern.
A person searched for something, opened a webpage, read it, interpreted the information, and decided what to do next.
The interaction looked roughly like this:
Human → Browser → Website
We optimized websites around that journey.
We thought about navigation, visual hierarchy, page speed, readability, responsive design, and search engines.
All of those things still matter.
But a new interaction model is emerging.
Increasingly, people are asking AI systems to find, compare, summarize, explain, recommend, research, and act on information for them.
The interaction increasingly looks like this:
Human → AI Agent → Website
The person may never open the page.
An AI research assistant might retrieve it.
A coding agent might inspect it.
An answer engine might extract a section.
An enterprise agent might combine it with information from ten other sources before producing a recommendation.
The website still matters, but the website may no longer be the destination.
It becomes a source of knowledge inside a larger reasoning process.
That is a profound shift.
It means we are no longer designing only for people who see pages.
We are also designing for machines that consume knowledge.
I Started With One Architectural Test
Once I accepted that agents were becoming part of the audience, I kept returning to one question throughout the rebuild:
If an AI agent fetches any page on this site, does it receive the complete content, correctly structured, on the first request?
If the answer depended on executing JavaScript, calling an undocumented API, navigating through several screens, authenticating into a platform, or reconstructing content after a framework initialized, I treated that as an architectural warning.
This was not because JavaScript is bad or dynamic applications are wrong.
It was because my website had a specific purpose.
Its primary asset was knowledge.
And knowledge should be easy to retrieve.
That principle led to several decisions that may sound technically unremarkable, but together they changed the architecture completely.
Markdown Became the Canonical Source
The most important decision was simple.
Every article, newsletter issue, short post, book entry, and talk would live as a plain Markdown file.
Each file would carry a small amount of structured metadata such as the title, publication date, summary, topic, and content type.
That meant the content itself was no longer trapped inside a database.
There was no proprietary editor representation that had to be interpreted later.
There was no content management system holding the only canonical version.
The file was the content.
That may sound like a small implementation detail.
I believe it is much more than that.
Markdown creates a remarkably durable interface between people and machines.
A person can open it and understand it.
A developer can version it.
A script can transform it.
A search engine can index it.
An AI system can reason over it.
A future platform can import it without needing to understand the application that originally rendered it.
For something as valuable as accumulated knowledge, that simplicity matters.
Git Became More Than Version Control
Once the content lived in Markdown, Git naturally became the system that managed it.
The repository became the content system.
That gave me something traditional publishing platforms often hide: a complete history of how the knowledge changed.
I could see what was added, what was removed, what was corrected, and when a piece evolved.
Version history became provenance.
Diffs became the audit trail.
The repository became portable.
More importantly, the content became independent of the website that happened to display it.
The architecture had changed from:
Content → CMS database → Website
to:
Content → Open files → Repository → Website
That distinction is more important than it first appears.
The website is now a representation of the knowledge.
It is no longer the container that owns the knowledge.
The Website Became a Compilation Target
I use Astro to transform the Markdown files into static HTML.
Again, the important idea is not the framework.
The important idea is separation.
The content exists independently.
The website is produced from it.
That means I can think of the website almost like compiled software.
The repository contains the source.
The build creates one output.
Today, that output is a website.
Tomorrow, the same source could feed an AI knowledge system, a semantic search engine, an EPUB, an API, a research assistant, or an interface that does not yet exist.
This is what made the architecture feel fundamentally different from the site I was leaving behind.
I was no longer designing around the assumption that the webpage was the final form of the knowledge.
I was designing around the assumption that knowledge should survive its interfaces.
Boring Architecture Started to Look Very Intelligent
A surprising amount of the design came down to choices that would never make an exciting conference talk.
The URLs are predictable.
The heading structure is consistent.
Pages contain proper semantic HTML.
The content taxonomy is explicit.
Metadata follows the same structure.
RSS feeds exist.
The site avoids unnecessary client-side rendering.
There is one canonical location for every piece of authored content.
None of this is revolutionary.
That is exactly the point.
Machines benefit enormously from predictability.
Humans do too.
A clean structure reduces ambiguity.
A stable URL creates a durable reference.
A proper heading hierarchy improves accessibility, navigation, search, and machine interpretation at the same time.
The more I worked on the site, the more I came to appreciate a principle that software architecture sometimes forgets:
Boring systems are often easier to understand, easier to migrate, and easier to preserve.
When machines become active participants in the information ecosystem, that becomes an architectural advantage.
Consolidating the Content Changed How I Thought About Publishing
Bringing twenty-five years of material into one place also exposed another problem.
A “blog post” had stopped being a meaningful description.
Some content was long-form technical writing.
Some belonged to Technology Bytes or Green AI Bytes.
Some was short-form commentary originally written for LinkedIn.
Books needed their own representation.
Talks, videos, and podcast episodes had different metadata and different distribution models.
Trying to force all of that into one generic content type would have simplified the code while making the knowledge model worse.
So I did the opposite.
Each stream retained its identity.
Articles remained articles.
Newsletter issues remained newsletter issues.
Posts remained short-form posts.
Books remained books.
Talks, videos, and podcasts retained their original formats.
But underneath those formats, they shared something more important: a common topic structure.
That allowed an idea to be followed across time and media.
A topic might connect an article from years ago, a recent Technology Bytes issue, a podcast discussion, a presentation, and a book.
This revealed something else about agent-ready content.
Humans often navigate by format.
Agents are more likely to navigate by meaning.
An AI system does not care very much whether the useful idea came from a podcast, article, video, book, or newsletter.
It cares whether the information is relevant to the task.
That suggests that the future architecture of knowledge may be organized less around where something was published and more around what it means and how it relates to everything else.
The Hardest Part Was Not Building the New Site
The new architecture was relatively straightforward.
The migration was not.
Moving a WordPress site after twenty years turned into an archaeology project.
Nothing was fundamentally broken.
That was what made the experience so interesting.
The old site worked.
Articles loaded.
Images appeared.
Search worked.
Visitors could read everything.
But underneath that functioning surface were years of accumulated assumptions.
Themes had come and gone.
Each had left formatting decisions behind.
Plugins had introduced shortcodes that once rendered perfectly but no longer had meaning without the original plugin.
Posts contained old caption tags, embed structures, syntax-highlighting conventions, and markup generated by different generations of editors.
Some images pointed to locations that no longer existed.
Different periods of the blog reflected different versions of the publishing stack.
No single decision had caused the problem.
The problem was the accumulation of reasonable decisions over time.
That was the moment when this stopped feeling like a website migration.
It started feeling like a lesson in technical debt.
Technical Debt Is Often the History of Good Decisions
We sometimes talk about technical debt as though somebody made a bad decision.
That is rarely the whole story.
Every plugin I installed solved a problem.
Every theme improved something.
Every integration saved effort.
Every workaround addressed a real need at the time.
Most technical debt does not begin with incompetence.
It begins with usefulness.
The same thing happens inside enterprises.
A script solves an urgent integration problem.
A vendor-specific feature accelerates delivery.
A schema is extended to support a new business requirement.
A temporary workaround is introduced because a project must ship.
A workflow is customized because the standard product cannot handle an edge case.
Each choice may be entirely rational.
But systems remember every decision.
People do not.
Years later, the organization inherits the accumulated coupling while the context that justified each choice has disappeared.
That is why I now think of technical debt differently.
Technical debt is often the residue left behind by yesterday’s perfectly reasonable decisions.
The Bill Arrives When You Need to Change
My WordPress site had worked for years.
Therefore, almost none of this debt was visible.
The cost appeared only when I wanted to move.
That pattern exists everywhere in technology.
A legacy system may run successfully for fifteen years.
Then an acquisition happens.
A cloud migration begins.
A vendor retires a product.
A new regulation requires different controls.
An AI modernization program needs access to old data.
Suddenly, decisions made a decade earlier become expensive.
The debt was always there.
The organization simply had no reason to measure it.
The invoice arrives when change becomes necessary.
That is why technical debt can feel so unfair.
It often becomes visible precisely when the business has the least time to deal with it.
The Real Debt Was Not in the Content
This was perhaps the most important lesson from the migration.
The articles themselves were fine.
The ideas had survived.
The words were readable.
The real problem was everything the content had become attached to.
The themes.
The shortcodes.
The image paths.
The plugins.
The rendering behavior.
The assumptions of old editors.
The platform itself.
The knowledge was valuable.
The coupling was expensive.
Enterprise systems have exactly the same problem.
Business logic is often still valuable.
Data is often still valuable.
Processes are often still valuable.
What makes modernization difficult is that those assets become welded to specific databases, middleware, application frameworks, workflow engines, vendor schemas, or proprietary interfaces.
Organizations often assume they are paying to rebuild the business logic.
In reality, much of the cost is simply the price of separating the logic from everything it became attached to.
Migration cost is frequently the cost of un-welding knowledge from infrastructure.
Open Formats Are Not Just Convenient. They Are a Future Exit Strategy.
That experience changed how I think about formats.
Choosing Markdown was not simply a content-authoring preference.
It became part of my technical-debt strategy.
The same applies to Git, stable URLs, documented metadata, and static HTML.
I know the technology stack will change again.
It would be extraordinary if it did not.
Astro may not be relevant twenty years from now.
Today’s AI protocols may disappear.
Today’s search engines may look primitive.
Browsers themselves may become less central.
None of that worries me very much.
The content should still exist as readable files.
That is the hedge.
The same principle applies inside enterprises.
Open formats, documented schemas, portable data, explicit interfaces, and platform-independent business logic are not merely interoperability decisions.
They are future migration decisions made in advance.
When evaluating architecture, we often ask:
What can this platform allow us to do?
Perhaps we should ask another question with equal seriousness:
How difficult will it be to take our knowledge somewhere else?
What Does Agent-Ready Actually Mean?
There is a risk that “agent-ready” becomes another technology label that encourages unnecessary complexity.
I think the opposite is required.
An agent-ready website does not necessarily need an AI chatbot, a vector database, an orchestration framework, or a sophisticated agent protocol.
Before any of that, the underlying knowledge needs to be accessible.
An agent should be able to discover the content, retrieve it completely, understand its structure, identify its topic, determine when it was created or updated, follow related information, reference a stable address, and consume the material without reconstructing an entire application.
Most of these ideas existed before generative AI.
We used to call them things such as good information architecture, accessibility, semantic markup, open standards, portability, and clean web design.
AI did not make those principles obsolete.
It made them more valuable.
There Is Another Shift Happening Beneath This One
The first generation of the web largely connected people to documents.
The next generation increasingly turned websites into applications.
Now another transition is underway.
Documents and applications are becoming inputs to intelligent systems.
That means a website is becoming more than a destination.
It is becoming a knowledge endpoint.
An article might be discovered by a human through search.
It might also be retrieved by an AI research system.
A product page might be read by a buyer.
It may also be interpreted by the buyer’s shopping agent.
Documentation may be written for a developer.
It may increasingly be consumed by a coding agent before the developer ever sees it.
A company report may be published for investors.
It may first be summarized and compared by an AI assistant.
The machine is increasingly becoming an intermediary between information and the person who needs it.
That has significant implications for how we publish.
The Bigger Lesson Is About Ownership
The migration started because I wanted to consolidate my work.
But that was not ultimately the most important outcome.
The more important change was moving the source of truth back into something I controlled.
LinkedIn remains valuable for distribution.
YouTube remains valuable for video.
Spotify remains valuable for podcasts.
Publishers and storefronts remain valuable for books.
Those platforms do not need to disappear.
They simply no longer need to be the canonical home of the knowledge.
That distinction feels increasingly important in an AI-mediated world.
Distribution can be rented. Knowledge should be owned.
Platforms will evolve.
Algorithms will change.
APIs will disappear.
Business models will shift.
The underlying ideas should survive all of them.
Twenty Years From Now
This was the thought I kept coming back to while rebuilding the site.
Somebody will want to read this material twenty years from now.
Perhaps it will be a person using something that still resembles a browser.
Perhaps it will be an AI agent building a research history of how enterprise AI evolved.
Perhaps it will be software that does not resemble anything we use today.
I cannot design for that interface.
Nobody can.
But I can make sure the knowledge is not trapped inside today’s interface.
That is the architectural responsibility.
We spend a lot of time trying to future-proof technology.
That is probably impossible.
Technologies change too quickly.
Perhaps the better goal is to future-proof the knowledge.
The Takeaway
If you are building or rebuilding a digital presence, whether personal or enterprise, there are now two audiences worth thinking about.
One is the human being who wants to read, watch, listen, learn, or explore.
The other is the intelligent system that may increasingly help that human discover and use the information.
Designing for one does not require sacrificing the other.
Fast pages serve both.
Clear structure serves both.
Semantic content serves both.
Stable references serve both.
Open formats serve both.
Good architecture increasingly serves both.
Keep the canonical knowledge in formats you control.
Separate the information from the platform presenting it.
Use distribution platforms for what they are exceptionally good at: distribution.
Avoid confusing convenience today with portability tomorrow.
And remember that every layer of unnecessary coupling you add is a small promise that somebody, someday, will have to unwind it.
I spent more than twenty years accumulating those promises.
This year, I finally paid many of them off.
If I have designed this correctly, then twenty years from now, when another generation of technology wants to consume the same body of work, the migration should be dramatically simpler.
It may not even feel like a migration.
It might begin with something as ordinary as:
git clone
I also want to end with something more personal.
Thank you to everyone who has read an article, opened a Technology Bytes newsletter, watched a video, listened to the podcast, read one of my books, attended a talk, asked a question, challenged an idea, or sent me a note over these years.
Publishing consistently for more than two decades is only meaningful because somebody is on the other side.
The technologies changed repeatedly.
The platforms changed.
The formats changed.
The subjects certainly changed.
The reason to keep writing did not.
It was always about sharing what I was learning and hearing what others thought about it.
This new site brings those years of work back together.
It gives that work a home I control.
It makes the knowledge easier for people to discover.
And, for the first time, it deliberately prepares that knowledge for another kind of reader as well.
The next twenty years of the web will not be read only by people.
Our knowledge architecture should be ready for that.