The last time Hackerfall tried to access this page, it returned a not found error. A cached version of the page is below, or click here to continue anyway

How to make a personal website, in 9001 easy steps

How to make a personal website, in 9001 easy steps

Making your own personal website might seem daunting, but it's not hard if you break it into smaller steps.

Recording your works

Start recording everything worth recording. Write it down, take video, or whatever. It doesn't matter how you do it or how you organize things; just record things while you still remember them, and store them in a place you won't lose them. (Email attachments are perfectly acceptable.)

Before I had a good system, I stored things in email attachments, Google Docs, hard drives, Gitorious (git repositories), Tumblr, SmugMug, S3, Twitter, Facebook, a CouchDB, and in a 60-page book written in LaTeX. I probably used other places too.

Fun fact: I named my 60-page book The Dump, after Maurice Benayoun's The Dump.

The main thing is to get everything digital so that you can carry the stuff around and search through it easily.

Write about your stuff

You probably want to write a little something about each thing. At the very least, you probably want to give them a title. A paragraph and a date might be good too.

I wrote these descriptions all over the place, but a lot were as captions on SmugMug. This was sort of a good idea, but only because I was uploading lots of pictures to SmugMug. The point is that you don't need to have a fancy website before you can create content for the website.

Also, don't proofread. Well, more accurately, only proofread after you've posted something on the internet and a few hundred people have read it and complimented you on it. Nobody is ever going to see most of your stuff, so don't waste time on making it good.

Organizing your works

Nobody other than you is going to read your website once you have it, at least at first, so don't worry about designing it for other people. In fact, you don't even need a website; just come up with some system that makes it easy for you to find the things you've recorded. I'll divide my approach to this into two categories.

Make a list

If you've been using email attachments to store your works, you could just list the names of the works and search terms that will find them. I actually didn't do this, but the point is that it doesn't have to be fancy.

I had already been doing this to some degree as I was recording things in my 60-page LaTeX book and in my SmugMug galleries.

Most of everything else was already publicly accessible on the web, so I mostly made a list of all of the links to them. I did this as a webpage, but you could do it in an email or blog post or whatever.

Make a consistent file structure

For anything you have been storing as ordinary files, copy the files into a new place with standard naming conventions. I suggest the following structure.


For example,


Don't worry yet about writing the web page about it.

Here's me putting the things into directories before I was using my current website-generator system.

Make a simple website

You wanted a website, so start putting stuff up on the web in whatever way is easy.

I wound up with a list of links before I had nicely structured files, so I just put that up. It went through many incarnations, but here are a few.

If you have nicely structured files and no other list, you could just dump them on a Apache web server with default configuration. There are even many fancy easy-to-use drag-files-somewhere-and-have-them-magically-served things that are practically quite similar.

I got this idea while talking with Marina Kukso, once used this as her web server.

Make a fancy website

By now, you have a lot of nicely organized content on the web. This is still not quite what you want; the following things could be improved.

  1. It should be easy for you to add new material to the website.
  2. It should be easy for other people to see what is on the website.

Remember, nobody is going to read your website, so concern yourself only with the first of these things.

Now that you have a bunch of content, you can play around with a few different ways of arranging them, and you can see what you like. Focus on the following things.

And, notably, since nobody else is going to use your website, don't try to make it easy for other people to add content or manage the system, and only try to make it look pretty if you enjoy the activity of adjusting the website style.

How do you like to add new content?

I like working with ordinary files, so I make new webpages by making new files inside of a terminal. But you might prefer to use a word processor on a website or to take videos with your phone.

How can you make this whole system easy to manage?

Lots of things could go wrong when things get fancy like this. Pay attention to things that seem annoying, and come up with ways around this. Annoying things might include

Try to keep this fancy system simple. When it has to be complicated, let the complicated things be either things you already understand well or things that you'll learn quickly.

My particular website

You probably want a website that isn't exactly like mine, but it might be worth explaining how my website works right now. If you're not the sort of person who knows what text files and Git are, you might want to skip this section.

Copying it

But before I explain any further, I would like to note that you are welcome to base your website on mine; the source code is here.

The process for editing it is designed very specifically for me, so you might not like it. Also, it is not very well documented, but if you're having trouble figuring out how it works, write to me, and I'll document it better.

If you want to use it, start by keeping all of the logic the same and just changing things in the content/! directory and in the content/index.haml file. Get something working, and worry later about making it look pretty.

Notable features

If you don't want to use it, you still might take some inspiration from some of the decisions I made

This section was accurate when I wrote it, but I have since switched to other software. As of October 19, 2014, I used the Ikiwiki service Branchable.) In 2015 I stopped using Branchable and wrote the website in Django. By 2016 I had switched to my own static website generator, written in Python. In 2017 I substantially rewrote the static website generator. All of these switches were very easy, and I maintained the same directory structure through all of the switches.

Static website generator

My website doesn't have anything where people log in or upload files or otherwise send input to the server. Thus, I can serve my website as ordinary files.

Editing these files is annoying, so I use a static website generator that writes these files based on the simpler and less-annoying files with which I configure my website. I happen to use nanoc, but there are tons of them.


It scares me to edit things without tracking their history. I settled a few years ago on using Git for this, so that's what I use for versioning the all of the content on my website. (I'm right now making a distinction between content and logic.)

When I build the site with nanoc, the resulting files go into the output directory, and then I upload them to a static file hosting service (more on that later).

This output directory is a git submodule with just the resulting website. This is cool in case I ever can't get nanoc working in the future; even if I can't rebuild the site, I'll be able to see what old versions looked like.

Git remotes

It also scares me to edit things without having multiple backups on different continents, so I have Git remotes. I used to use Gitorious, and I still have my own server that I push things to, but I wind up using GitHub a lot of the time. It works decently and isn't annoying once you've set things up the first time, but I don't like this because it's proprietary

GitHub Pages

If you already have everything in Git and you've already given in to proprietary GitHub software, you might as well use GitHub Pages to host your website. GitHub Pages serves a website from files committed to a Git repository.

Recall that the compiled website goes into the output directory and that this directory is a git submodule. I push that submodule to GitHub, and it gets served through GitHub Pages.

I must point out that there are some things I don't like about GitHub Pages. First, as I said above, it's proprietary. Second, I can't serve different pages depending on the Accept-Language header.

Directory structure

I went with this directory structure for pages.


This results in two pages, one at!/this-cool-thing, and the other at!/that-cool-thing.

This structure is nice because it gives me a place to put more than one file per page.


Remember, you might be different

I just explained how my site works, but you are probably not a clone of me. Starting with my ideas might not be a bad idea, but try to come up with something that suits you better.


It's not like each of these steps only happens once. I still have at least half a lifetime of stuff that I've written about, photographed, &c. but haven't published on my website. I periodically go through those old things and copy them to the site.


Making your personal website might seem daunting, but it's easy if you break it into tiny pieces. Start by saving everything. Once you have a lot of things, organize them and write about them. Don't worry very much at first about making the website pretty; just get things started. And in designing your website, focus on making it easy for you to add content rather than on making it pleasant for other people to view.

Other resources

I found some other nice directions on a belly dancing website.

Continue reading on