I Replaced WordPress with Static HTML. My New Publishing Tool? An AI Coding Agent.

I've been running my personal website, subhankarsarkar.com, on traditional WordPress hosting. It served its purpose, but I started questioning something fundamental: why was I paying for PHP, MySQL, and a traditional hosting environment for a website that primarily publishes articles?

I don't run an e-commerce platform. I don't have user accounts, transactional workflows, or complex server-side business logic. Most of my website is content: articles, professional information, and technology experiments. It seemed like unnecessary infrastructure.

But the more interesting question was not where to host the replacement. It was how to rebuild and maintain it without introducing another CMS.

And that's where AI-assisted coding changed my approach.

1. Why not rethink the entire publishing model?

Traditionally, migrating an existing WordPress website to static HTML would have been a reasonably involved engineering exercise. You would need to understand the existing theme, separate presentation from WordPress-specific functionality, decouple PHP templates, extract content, recreate navigation, rebuild article layouts, preserve URLs, and implement a new publishing workflow.

You could use a website cloning tool to reproduce the visible pages, but that wouldn't necessarily give you a clean, maintainable architecture. I deliberately didn't use any website cloning tool.

Instead, I asked myself a different question:

"If AI coding agents are capable of producing sophisticated HTML pages, why can't I use one to rebuild and maintain my own website?"

I already knew the visual experience I wanted. I had the existing website as a reference, the content was mine, and the migration requirements were well understood.

I could use an AI coding agent to inspect the existing website, understand its structure, create a new design system, and progressively rebuild it using standard HTML, CSS, and JavaScript. More importantly, I could make the agent responsible for following that design system every time it created a new page.

I didn't need to recreate WordPress. I needed to preserve the content and experience while replacing the underlying architecture.

2. The IDE replaces the blogging editor

This was probably my most important design decision: I realised I didn't really need a blogging editor.

My future articles would typically start as a text document or Word document. I could give that content to an AI coding agent and ask it to turn it into a properly structured HTML page. A good prompt, a design-system document, and clear agent instructions would be enough to reproduce the same visual style, page structure, and publishing conventions consistently.

I could maintain three essential artifacts in my repository:

• DESIGN-SYSTEM.md: Defines typography, colours, spacing, layouts, article cards, and reusable components.
• AGENTS.md: Defines how coding agents should work with the website, create pages, preserve URLs, update metadata, and validate changes.
• A reusable HTML structure: Provides the foundation for every page and article.

Whenever I want to publish something new, the workflow becomes remarkably lean:

1. Write the content in a text file or document.
2. Open the website project in an AI coding IDE.
3. Ask the agent to create an article following the design system and agent guidelines.
4. Review the generated HTML and preview the page.
5. Commit and push the changes to GitHub.

That's it. No WordPress dashboard. No page editor. No CMS administration.

I don't need a blogging editor. I need an IDE.

In my case, that IDE is Google's Antigravity. I can also use other coding agents such as GitHub Copilot or Codex because the instructions and website source code live in the repository, not inside a particular AI tool. This is a fundamentally different way of thinking about content publishing.

3. Extract everything before rebuilding

Before writing any code, I needed to understand what I was migrating. I started with three sources from WordPress:

WordPress XML export: From the dashboard via Tools → Export → All Content → Download Export File. This provided the published posts, pages, categories, tags, publication dates, and raw content.

Media library: I downloaded the complete wp-content/uploads directory to preserve original images, featured images, and other media assets.

Sitemap hierarchy: I downloaded sitemap_index.xml and all the child sitemaps referenced by it. The sitemap was particularly useful for identifying every existing URL, including older articles, category archives, and other pages.

I also retained a full backup of the original website, including its database and files. The objective was to avoid losing years of content, images, or existing search engine visibility.

4. Let AI do the discovery and migration planning

I opened the migration workspace in Google Antigravity and asked it to act as a website migration engineer. The first task was not to generate HTML. It was to analyse the source material.

I asked the agent to:

• Parse the WordPress XML export.
• Extract all published articles and pages.
• Identify categories, tags, and publication dates.
• Map every article to its original URL.
• Inspect the complete sitemap hierarchy.
• Map images to their corresponding articles.
• Identify missing images and broken references.
• Compare sitemap URLs against the WordPress export.
• Generate CSV inventories and a migration report.

I explicitly instructed it not to modify the source files or start rebuilding the website. This distinction matters. AI-assisted migration shouldn't mean asking an agent to blindly clone a website. It should mean giving it a structured understanding of the existing system and clear constraints for rebuilding it.

5. Build a clean static website

Once the discovery work was complete, I moved to the actual implementation. I deliberately chose a lightweight technology stack:

• HTML5: Semantic, well-structured, W3C valid.
• CSS3: Native CSS custom properties, responsive flexbox and grid, zero CSS preprocessors.
• Vanilla JavaScript: Fast, lightweight, zero runtime framework dependencies.
• Vector Icons: Inline SVG assets.
• Optimized Images: Next-generation AVIF with responsive fallback images.

No PHP. No MySQL. No WordPress. No React or heavy frontend framework bloat.

I wanted a modern editorial-style website, not another conventional corporate portfolio template. The development started with three representative pages:

1. Homepage: Introduction, expertise, featured articles, and navigation.
2. Blog archive: Article cards, categories, and archive timeline.
3. Individual article: Typography, images, metadata, and focused reading experience.

The idea was to establish the design system and reusable page structures first, then migrate the remaining content. This is where the earlier design-system and agent-guideline documents become important. They ensure that every future page follows the same conventions, even when different AI coding agents are involved.

6. GitHub becomes the source of truth

I created a private repository in my personal GitHub account: subhankar-personal-website. GitHub Free supports private repositories, so I didn't need an Enterprise subscription.

The repository contains the website source, assets, design guidelines, agent instructions, sitemap, and RSS feed. Every change is version-controlled.

The AI agent can make changes, but I can inspect the diff, review the generated pages, and decide what gets committed. This gives me a portable website that isn't tied to WordPress, a particular hosting provider, or a particular AI coding tool.

7. Azure Static Web Apps for hosting

With the static website ready, I created an Azure Static Web App and connected it to my GitHub repository. The deployment workflow is straightforward:

GitHub push → GitHub Actions → Azure Static Web Apps → Live website

Every push to the main branch can trigger an automated deployment. Azure serves the generated HTML, CSS, JavaScript, and images globally. There is no continuously running application server or database to maintain.

The Free tier is an attractive starting point for a personal website, subject to its bandwidth, storage, and service quotas (Azure Static Web Apps Documentation).

8. Connecting my existing domain

My domain was registered with GoDaddy, but its DNS was managed by Cloudflare. I didn't need to transfer the domain or change the registrar:

• GoDaddy: Domain registrar.
• Cloudflare: DNS management and edge routing.
• Azure: Static website hosting.

The domain migration involved three steps:

First: Verify ownership. I added subhankarsarkar.com as a custom domain in Azure. Azure generated a TXT verification record, which I added to Cloudflare.

Second: Connect www. I added www.subhankarsarkar.com as another custom domain and configured a CNAME record pointing to my Azure hostname ([unique name].azurestaticapps.net). I also resolved an existing DNS record conflict for www rather than simply creating another record.

Third: Prepare the root domain cutover. The root domain was still pointing to my old GoDaddy hosting through an A record. Azure successfully validated ownership of both domains. The root-domain traffic is switched by replacing the old website A record with a Cloudflare-flattened CNAME pointing to Azure.

An important lesson: never delete all DNS records during a website migration. Only change the records responsible for website traffic. MX, SPF, DKIM, and DMARC records must be preserved to avoid disrupting email. The final step is to establish one canonical domain and redirect the other using a permanent 301 redirect.

9. What have I actually changed?

The biggest change isn't simply the hosting bill. It's the removal of infrastructure and software dependencies that my website didn't need in the first place.

10. A different way to think about building and maintaining websites

What started as a cost-saving exercise became an interesting experiment in AI-assisted software development.

We traditionally built content management systems because maintaining a website required technical intervention. We needed editors, templates, plugins, databases, and administration interfaces.

But AI coding agents are changing that equation.

If an agent can understand a repository, follow a design system, generate HTML, maintain navigation, update metadata, and validate changes, perhaps the traditional editing interface isn't always necessary.

For a personal website, the combination of:

• A well-defined design system (DESIGN-SYSTEM.md).
• Clear repository-level agent instructions (AGENTS.md).
• Static HTML and reusable components.
• GitHub for version control.
• An AI coding IDE for content creation and maintenance.

can be a perfectly practical alternative.

The important shift is that the website becomes a codebase that an AI agent can maintain, rather than an application that requires a CMS to manage.

I don't need to maintain a content management platform just to publish my thoughts. I need a good IDE, a well-structured repository, and an AI agent that understands the rules.

Sometimes the best migration isn't replacing one platform with another. It's questioning whether you need that platform at all.

Less infrastructure. More ownership. AI-assisted publishing.

Disclaimer: The views expressed in this article are my own and do not necessarily reflect those of my employer; they are informed by personal engineering experiments, hands-on architectural migration, and practical experience with AI coding tools.