Given how deep I’ve gone into Claude Code, I started exploring different approaches for managing web-facing content. As part of figuring out the AuthorMagic website creator, I discovered Hugo. I experimented using it for AdventuresInClaude and liked it, so - I decided to see if I could use Claude Code to do a full migration of Feld Thoughts to Hugo.

A day later, Feld Thoughts has a new home. While the theme is simple to start, I have full control over it and will iterate on it (in Claude Code) to get it in a form that I like.

The target stack is straightforward. Hugo generates a static site from markdown files. Vercel hosts it. I’ve been spending a lot of time with Markdown files lately and I enjoy working with them much more than anything that requires formatting. No more database, no PHP, and no WordPress updates. Just markdown files in a git repo.

The first step in the process was getting the content out. WordPress has a built-in REST API at yoursite.com/wp-json/wp/v2. Claude wrote a TypeScript script that fetches all posts via paginated API calls, fetches all categories and tags, and converts HTML to Markdown using the Turndown library. It strips WordPress block comments, handles caption shortcodes, and decodes all the HTML entities WordPress loves to scatter through titles and descriptions - smart quotes, em dashes, ellipses.

The script uses a state file for resumable checkpoints. If it crashes or gets rate-limited, it picks up where it left off. This turned out to be essential.

A key decision was the content structure. I used Hugo “page bundles” to preserve the WordPress URL structure:

content/archives/2012/10/random-act-of-kindness-jedi-max/index.md

This maps directly to feld.com/archives/2012/10/random-act-of-kindness-jedi-max/ - the same URL WordPress used. Every old link still works. No redirects needed.

Hugo’s configuration makes this explicit:

[permalinks.page]
  archives = "/archives/:year/:month/:slug/"

If you have custom post types - I had books, films, running logs, and events - those need separate exports since they live at different API endpoints. Each gets its own content directory.

The media download was tricky. WordPress CDN URLs come in a bunch of variants - i0.wp.com/feld.com, www.feld.com, direct feld.com paths, all with various query parameters. The media script scans every exported markdown file for these URLs, normalizes them, and downloads the actual images.

The clever part is the reference counting. Images used by only one post get co-located in that post’s page bundle directory. Images shared by two or more posts go to static/images/ with year-month prefixes to avoid filename collisions. After downloading, it rewrites all the markdown URLs from WordPress CDN paths to local relative paths.

A separate cleanup pass fixes HTML entities that survived in the frontmatter. WordPress stores stuff like & and ’ in titles and descriptions. These need to be decoded to actual characters, then the YAML strings need to be re-escaped properly. This is the kind of thing that sounds trivial but breaks in surprising ways when you have 5,530 posts.

Claude wrote a verification script that fetches the WordPress sitemaps and compares every URL against the Hugo content directory. It reports the match rate and lists any missing posts. We iterated until it hit 100% accuracy.

For the theme, I used PaperMod as a starting point and forked it. The fork lets me customize branding, layouts, and features without worrying about upstream updates. I added client-side search via Pagefind, which is essential for a site this size. Pagefind builds a static search index at build time. I added data-pagefind-body to the single post template so it only indexes post content - not navigation, footers, or other chrome. This dropped the index from 10,000+ pages to about 5,500 and cut the search index build time from 32 seconds to 8 seconds.

Deployment is simple. Push the Hugo repo to GitHub, connect it to Vercel, and point the domain’s DNS to Vercel. Every git push to main triggers a rebuild and deploy. My 5,530 posts build in about 47 seconds. The whole deploy - clone, build, CDN upload - is under 3 minutes.

The DNS cutover required documenting every existing record first - MX records for email routing, SPF, DKIM, and DMARC for email authentication, CAA records for SSL. I recreated all of them in Vercel DNS after the transfer.

I also switched from Mailchimp to Kit for email subscribers. Kit has RSS-to-email automation that watches the Hugo RSS feed and sends new posts to subscribers automatically. No API integration needed.

If you’re thinking about doing this, three things matter most. First, URL preservation is non-negotiable. Get the permalink structure right from the start so every old link works without redirects. Second, the media download is where things get messy - WordPress CDN URLs come in many variants, and you need reference counting to handle shared images correctly. Third, write a verification script and run it obsessively until you hit 100%.

I’ve open-sourced the migration scripts at github.com/bradfeld/wp-to-hugo. They’re genericized - you configure your site URL and custom post types in a single JSON file and the scripts handle the rest.

The toolkit has five scripts, meant to be run in order:

1. wp-export - Fetches all posts and pages via the WP REST API, converts HTML to Markdown, and writes Hugo page bundles with proper frontmatter (categories, tags, descriptions).
2. export-custom-types - Exports custom post types (books, films, whatever your site has) to separate content directories.
3. wp-media-download - Scans all exported markdown for WordPress media URLs, downloads the images, and rewrites the URLs to local paths. Handles the reference counting (single-use images go in the page bundle, shared images go to static/images/).
4. fix-entities - Cleans up HTML entities that WordPress stores in titles and descriptions (&, ’, smart quotes, etc.).
5. wp-verify - Fetches your WordPress sitemap and compares every URL against the Hugo content directory. Run this until you hit 100%.

To use the scripts you’ll need Node.js (version 20+) and a WordPress site with the REST API enabled (most have it on by default - check by visiting yoursite.com/wp-json/wp/v2/posts). You’ll also need Hugo installed to build the site, a GitHub repo to store it, and a hosting platform like Vercel or Netlify to serve it. The scripts handle the content migration - setting up Hugo, choosing a theme, and configuring deployment is on you, but Hugo’s quick start guide covers most of it.

The scripts are resumable - if one crashes or gets rate-limited, re-run it and it picks up where it left off.

The repo’s documentation has a detailed walkthrough of how each phase works, including the media URL normalization strategy and the reference counting logic.

Claude Code did all the heavy lifting. I described what I wanted and it wrote the scripts, configured Hugo, set up the theme, and handled deployment.

As I play around with Vibe coding, I’ve decided to take a new topic each week. For context, look at my Dinostroids: My Journey into Vibe Coding. Or just go play Dinostroids.

This week, I’ve been learning how to modify WordPress themes. My website has a complex theme that is impossible to change without getting under the hood. The Foundry website is also excessively complex for what it is, but they both turn out to be great to learn on.

I understand PHP well enough to read it. After working through WordPress Studio, GitHub, and Cursor, I’ve set up my development pipeline.

While the code is a little gnarly, it’s not too bad, and it’s pretty easy to figure out what’s going on. But the wall I’m running into now is that I’m a lightweight at graphic design.

While Adobe Photoshop is an obvious choice, and Canva is another obvious choice, I’m looking for “what’s best for a graphic design novice.” Thoughts?

Yup. I’m done with Facebook. However, it’s tough to delete your account. Read the message above. I exited out of this screen, suspended my account instead, but then went back 15 minutes later and actually deleted it. Well – I started the deletion process. I don’t know what day I’m on, but I think I’m close to 14 days. So, I’m still “deleting” apparently.

The only inconvenience I’ve noticed so far are all the sites where I used Facebook as the sign-on authenticator (rather than setting up a separate email/password combo.) I think I’m through most of that – at least the sites I use on a regular basis. For the first few days, I accidentally ended up on the Facebook login screen which was pleasantly filled out with my login beckoning me to log back in. I resisted the siren song of restarting my Facebook account before the 14 days was up.

I have never been much of a Facebook user. About once a year, I try to get into it, but I always stall out and use it as a broadcast-only network for my blog and links that I find interesting. I went through a phase of tightening up my security, pruning my friends, using it more frequently from my phone, deleting it from my phone, checking daily in the morning (as part of my morning routine – which has evolved a lot since I wrote this post in 2007), and then giving up again and never looking at it.

Recently, I decided to rethink Facebook, Twitter, and LinkedIn. Facebook was the easiest. While it had already become a walled garden, I suddenly noticed that the walls we were going up very high, being justified by Facebook’s new effort to get all their privacy and data issues “under control.” For example, you can no longer automatically post your Tweets to your Facebook profile.

And, Facebook recently killed automatic WordPress publishing to Profiles. So, my one (and only) current use case for Facebook, which is to broadcast from my blog, disappeared. Sure, I could create a public page, go through all the authentication stuff, and theoretically post to my new public followers, but who cares. If they are really interested in what I write, they can subscribe to my blog or follow me on Twitter (at least for now, until I figure out how I’m going to engage with Twitter long-term.)

Lanier’s Ten Arguments for Deleting Your Social Media Accounts Right Now tipped me over into thinking harder about this. Now that I have decided how to deal with Facebook, at least for now, it’s time to move on down the road to Twitter and LinkedIn. I’m about a month into a different way of engaging with LinkedIn and we’ll see if it sticks. When I reach a conclusion, I’ll definitely write about it.

On my run today, I thought more about what I was looking to do and decided that my approach wasn’t right.

I’ll put this in the MVP / fail fast category. While many of the responses were from people who are clearly talented and would be able to tackle the stuff I’m said I was looking for help on, I realize that my premise around what I need may be flawed when I think harder about what I really want.

So, for now, I’m going to rescind my previous post titled Looking for a Writer and a WordPress Goddess and keep pondering things.

I’ve been very reticent to add people to our team. However, at this point it’s clear that I can get a lot of leverage from two very specific people.

Writer: I’m looking for a full time non-fiction writer. This is not a research function, but rather a writing / editing / coordination function. The amount of writing I do is significant, but there is 5x more to do than I can handle. I’m turning down a lot of stuff that I’d like to write and putting off stuff into an infinite backlog which doesn’t feel good. So, having someone writing first drafts, editing stuff I slap together, writing some primary content, and helping get it posted in the right places would be a big help.

WordPress Goddess: I contribute to four – soon to be five – blogs that my best assessment of is a hot mess of different configurations. Every time I fiddle around with something on one of them I break something else. Ideally I’d be able to normalize everything into one configuration, but I accept that this will always be changing. The person I’m looking for here has a mix of design skills and WordPress programming / config skills. In addition, there’s a bunch of other stuff in the infinite backlog of goodness to work on.

Each of these people would work directly for me. Optimally they’d live in or move to Boulder, but that’s not a requirement. They must be interested in entrepreneurship and be able to deal with lots of ambiguity. They must be comfortable with a lack of daily structure and reporting. They must be able to work remotely at times.

I’m willing to make a two year commitment to them, so they need to be willing to make a two year commitment to me.

If you are interested, just email me at brad@feld.com. If you know someone who might be a fit, please forward this post to them.

I’ve been using the Medium WordPress plugin to republish my posts automatically. It’s generally not much effort, although there are a few bugs. The most annoying is that when I publish something on WordPress, update it, and then publish it again, it doesn’t update on Medium.

Yesterday my WordPress database automatically updated and published a pile of posts from 2006 and 2007 to Medium. It also filled up my drafts on Medium, which eventually caused Medium to rate limit me (it seems like that happened around 100 posts). I didn’t want the old posts up on Medium so I went through and deleted them. That was a pain in the ass as Medium doesn’t have a bulk delete feature and I had to do it one by one. That prompted me to ask the question as to whether this has been a useful experiment.

While Medium says I have 51,000 followers, it looks like I get about 1,000 views per post and between 10 and 50 likes. So – that’s a little incremental exposure, but a very low percentage of the people who follow me, which is interesting.

I’ve had a lot of trouble engaging in comments and feedback on Medium. Some of it is the UI, some of it is time, and some is modality. I do almost all my responses to comments on WordPress via email, which Disqus handles extremely well. Medium, on the other hand, doesn’t have a reply by email feature.

Any thoughts, especially from the Medium side? Feedback welcome.

Every time a marketing team works with a web design firm, there is the usual painful and broken handoff between the outside agency and the technical operations of the client which culminate on launch day. So many things have to go right for your launch to be flawless: server configuration, load testing, and deployment. For our portfolio companies, this requires diverting senior DevOps engineers to ensure things go right, which of course comes at the expense of delivering and operating their product and even then there are no guarantees.

Our portfolio company Pantheon is fixing this. Today they are launching Pantheon for Agencies, which enables professional web designers and developers to standardize all DevOps for all of their clients and nail every launch every time. If you know anyone who designs or builds websites for a living they should know about it.

It includes Pantheon’s most developer loved features, their enterprise tools for managing teams and websites en masse, and lessons learned powering 85,000 Drupal and WordPress websites. It is available instantly to digital agencies and for free. Agencies that standardize their work on Pantheon are generating hundreds of thousands of dollars a year in additional profit by efficiency gains due to time saved by the Pantheon development and deployment tools.

Pantheon for Agencies gets everyone on the same page with a common set of management and testing tools for clients and their agencies. It makes handoffs seamless and it ensures everything just works the way you expect it to on launch day.

If I take a step back, it’s so clear to me how much the website market needs to change. Websites are a huge industry that is now bigger than digital advertising business, much of which is serviced by digital agencies (e.g. every web design, development, and digital marketing company on the planet.) Until now agencies have had to bear the responsibility of website DevOps for their customers by necessity. At the end of the day agency clients expect their website to work, even if it’s a server problem at 3AM on a client site that the agency last worked on six months ago.

Pantheon fixes this broken and frustrating dynamic. They enable digital agencies to walk into any customer at any scale and know they can nail the launch no matter how demanding the requirements.

Every digital agency should try Pantheon out – it’s free!

And yes – this site is on Pantheon and my friends at Young & Hungry who did the design and migration from my previous hosting hell are now experts at this.

Talk with any professional marketer about their websites and two things will become clear: 1) websites are absolutely central to how digital marketing gets done and 2) websites are a giant pain in the ass.

In our portfolio of startup companies, following is how websites usually get managed.

When companies are just getting off the ground, the founders often build the websites themselves, increasingly with flat HTML because it is simple and efficient. The websites are usually thought of as simple extensions to the product themselves.

At some point (hopefully) the business starts growing and a professional marketer is brought on board. In order to do their jobs marketing needs a content management system, often WordPress for simple use cases.

This is where things start to break down. Startup engineering teams are now tasked with managing a CMS system. This may be simple at first, but things get complicated very quickly. Hosting offers little beyond just hardware and maybe some server configuration. Professional website developers need much more than that — they have to collaborate in teams, work with version control, deploy changes, and as the company grows scale their site and make sure it is running fast 24×7 — aka website DevOps.

Guess who’s responsibility this becomes? The startup’s ops and engineering team. Every hour invested in this marketing infrastructure comes directly out of the bandwidth available for product improvements. Total break down.

At Foundry Group we went through a similar pattern, but here at Foundry it was Ryan (a co-founder and former engineering leader at Excite) who played the role of VP Eng. He spent too many hours over the past year baby-sitting our WordPress mess. He eventually got sick of me texting him that there was a problem somewhere.

This is why we are so excited to announce that our portfolio company Pantheon now supports WordPress. Over the past two years they have worked entirely in the Drupal ecosystem (their roots) and now run over 55,000 sites. They have built an incredibly powerful multi-tenant platform with the best set of website developer tools in the world and a container based run-time that can scale sites from 0 to >100M page-views entirely in software. All of their technology is now available to WordPress developers.

We like many of their customers were begging for some time for them to support WordPress. That day has finally come. Ryan is retiring the website pager and I’ll have to find some other way to annoy him on a regular basis.

The BigDoor team has built a powerful gamification API, but until recently it required a programmer to implement it.  The team continues to make big strides in making gamification more accessible by streamlining and simplifying the process of adding points, leader-boards, badges and virtual goods to a site or app.  BigDoor is progressing toward what they call the “15 minute install”.  Their new WordPress plugin takes about an hour from download to being live on your site, but this is a big step toward making gamification, badges and leader-boards more accessible for bloggers everywhere.

If you are a WordPress blogger, download the BigDoor WordPress Gamification plugin and give it a spin. Feedback welcome.