The Quieter Web — Aditya Raj Singh

I’ve been putting this off.

Not the migration — that’s done. I mean writing about it. Because every “I moved my site from X to Y” post on the internet follows the same arc: WordPress was slow, I found a new framework, here are my Lighthouse scores.

I’ll try not to do that to you.

Also, full disclosure upfront: I’m not a web developer. I’m a marketer who works in SEO and content. I know enough to be dangerous with a terminal, but I wouldn’t call myself someone who builds websites. I manage them. There’s a difference.

That distinction matters for how this story goes.

WordPress and I had a decent run. It did what it was supposed to do — kept my site alive, let me post when I felt like it, handled the plumbing. I had zero complaints that felt urgent enough to act on.

That’s actually the problem with WordPress for a site like mine. It doesn’t break dramatically. It just quietly accumulates weight.

There was the plugin that handled SEO. The one that handled image optimization. The one that handled caching. The one that was supposed to make the caching plugin work better. At some point I had six plugins doing what I vaguely understood, and one of them was definitely fighting with another one — I just didn’t know which.

The site worked. It was just… carrying a lot.

The moment that tipped me was loading my own homepage on mobile and watching the spinner go. Not for long. A second, maybe two. But enough to notice. Enough to feel like the site was thinking about showing up rather than just showing up.

I spend my days thinking about Core Web Vitals and TTFB and crawlability. My personal website — the one with my name on it — was sitting on a shared WordPress host, loading fonts the slow way, building pages from a database on every single request.

That felt like a plumber with a leaky tap.

I’d been circling Astro for a while. The pitch is simple: ship almost zero JavaScript by default, generate everything at build time, let the HTML do the work.

Which is just… how the web was supposed to work.

The catch was that I’d never built anything from scratch. I could edit templates. I could navigate a codebase with enough context. But scaffolding a project with content collections, routing, schema markup, and a component system from nothing? That was firmly outside my lane.

So I used Claude Code.

Here’s what that actually looked like — because I want to be specific, not vague about it.

I didn’t just ask it to “build my website.” I described what I had, what I wanted, and what I cared about. The tech stack. The content model. The fact that SEO and GEO visibility mattered to me. What pages existed. How the blog worked. What the photos section needed to do.

And then I worked through it, one piece at a time.

It scaffolded the project. Set up content collections for blog posts and photo albums. Wrote the layout components. Added JSON-LD schema on every page — Person on the homepage, Article on blog posts, BreadcrumbList everywhere — the kind of structured data I’d actually recommend to anyone at work. Built the <Image /> pipeline with AVIF and WebP output. Wired up the sitemap integration. Added an llms.txt file because, again, I work in GEO and it felt slightly embarrassing not to have one.

I reviewed everything. Asked questions when I didn’t understand a decision. Pushed back on a few things. Changed my mind about the design twice.

It was collaborative in the way that good work usually is — I had the context and the judgment, it had the implementation speed. Neither of us could have done it the same way alone.

What surprised me wasn’t the speed. I expected that. What surprised me was how much lighter the whole thing felt to understand.

With WordPress, I never really knew what was happening inside my own site. There were layers I’d never looked at. Plugins I’d installed and forgotten. Database tables I’d never opened. With Astro, I can read the entire codebase. Every file does something I chose. Nothing is hiding.

The site is just files now. Clean files with known contents.

Editing a post means opening a .mdx file, writing, and pushing. No admin panel. No block editor. No login page sitting somewhere waiting to be forgotten. No plugin I installed in 2023 phoning home.

There’s a version of this post where I show you the before/after Lighthouse numbers. They’re good. But that’s not really the point.

The point is that I built something I actually understand now — without being a developer. The combination of a framework that’s honest about what it does and an AI that could translate my requirements into working code meant that the “I’m not technical enough for this” excuse quietly stopped being true.

I spent a lot of energy last year building systems at work that are clean, documented, and easy for someone else to pick up. It felt inconsistent to come home to a personal site that was none of those things.

Now it isn’t.

I don’t think this means everyone should abandon WordPress. If you’re running a content team, or you need a CMS your non-technical colleagues can actually use, or you just want to get something live fast — it earns its place.

But if your site is just you — your writing, your photos, a CV, a contact link — you probably don’t need a database. You probably don’t need six plugins in a fragile truce with each other.

And you probably don’t need to be a developer to build something better.

You just need to be clear about what you want.