Rebuilding my blog from the Wayback Machine

How I recovered nearly twenty years of old posts with Claude, and why the new site is just Markdown files in a repo.

I stopped writing at jon.sykes.me around 2009. My home page at the time said "For fun I used to blog", which was fair. I kept the domain, but the blog and its posts didn't survive.

Last night I sat down to put a big grey "sykes.me" on a page. By this morning I had 62 posts going back to 2007, a blog to put them in, and a comment section. I did it with Claude, which still feels a little ridiculous.

Finding the old posts

The jon.sykes.me blog as captured by the Wayback Machine on December 25, 2008, with the archive's capture timeline across the top and post summaries in two columns

I pointed Claude at a single Wayback Machine snapshot of jon.sykes.me from December 2008, and asked it to pull across anything that wasn't broken links or low value. Rather than just crawl that page, it asked the archive for its full list of captures, which turned up far more than the snapshot linked to.

The archive knew about 163 posts from 2006 to 2009. About 100 still had recoverable text. Roughly 60 are simply gone.

The best find came from inside one of the posts. A link pointed to jpsykes.com, where the blog had lived before, and that's where the best early material was. CSRF write-ups, CSS performance tests, IE6 memory leaks, Dojo porting notes, How to explain JSON to your mum. That one I asked for by name, it was a good one.

From there it kept pulling threads. Nomeist turned up, my monome and Arduino blog from 2008 to 2012, which added nine posts. LinkedIn added 14 more, although nearly everything there before 2026 was work news.

Nothing went up automatically. Claude sorted everything by value and gave me a shortlist, I drew the line, and it drafted the posts for me to read first. The text stayed in my original words, typos included, with new titles, summaries and tags to fit the format. Each one ends with a line saying where it first appeared.

It wasn't all clean:

  • The Wayback Machine rate limited us, then flagged the requests as bot traffic. We stopped there rather than work around it, so 11 posts I'd like to check are still in there.
  • 17 old images came back, some in better quality from my old Flickr account. Five are lost, and those posts say so.
  • Old links are old. Some now point to archived copies, and plenty of the rest are probably dead.

Why static

The brief I gave was short: no database, all static content, generated at build and deployed when I push.

I've just spent a night digging my own writing out of an internet archive, so the reason is not hard to find. My old blogs lived on servers, in databases, on software that needed looking after, and when I stopped looking after them they disappeared. If someone hadn't crawled them years ago, those posts wouldn't exist.

A Markdown file in a git repo doesn't need looking after. There is no server to patch, no database to back up and nothing to log in to. The whole site can sit untouched for ten years and still build, and the posts are readable without any of it.

How it's built

Every post is one Markdown file in posts/. The name sets the date and the URL, and the front matter holds the rest:

---
title: Title of the post
subtitle: One sentence saying what the post is about.
date: 2026-11-05
tags:
  - first-tag
---

One Node script, build.mjs, turns those files into the whole site: home, index, tag pages, the Atom feed, the sitemap, robots.txt, llms.txt and the structured data for each post. It has two dependencies, one for front matter and one for Markdown. There's no framework, and the JavaScript on a page is a Light / Dark toggle and the comments loader.

The build is also the editor. A missing subtitle, a wrong date or a stray heading level fails the build, and Vercel keeps the last good version live. Publishing is adding a file and pushing to main.

The look comes from a small design system: tokens for colour, type and spacing, and one stylesheet of about 8KB. One white sheet on a grey canvas, ink with no accent colour, one line weight, and an index that reads like the index of a book.

Why GitHub comments

I wanted comments, but I didn't want to manage them, deal with logins or fight spam. Substack was my first thought, but it has no public API or comment embed, so I looked for someone else to carry that work.

I'm trialling giscus, which stores each post's comments as a GitHub Discussion in a small public repo. GitHub handles the accounts, and the sign-in does most of the work on spam. I own no database, and the comments stay in a place I can export or walk away from.

The catch is that you need a GitHub account to comment, which is a real filter. A lot of what I write here is for engineers, so it's a fair trade for now. If it's too quiet, I'll try something else.

It arrived looking like GitHub, in a site that's trying very hard not to look like anything. So the build now generates its theme from the same design tokens as the site, and the comment form sits flat on the sheet.

If you've read this far, there's a box just below. Let me know if it works.