Tips for Running Lots of WordPress Installs Efficiently


Since I use WordPress for almost every client project I work on anymore, as well as hosting a number of friend’s website, I tend to accrue a large number of WordPress sites running on my database. While installing WordPress so many times and managing these sites, I’ve developed a sort of check list for being sure that I’m being as smart (and efficient) as I can.

First, a word on working with clients and WordPress

Before I jump into my list, here’s one piece of advice for working with clients and using WordPress for their sites. This tip only comes after a year or so of experience not doing it this way – so listen up.

When I first began developing WordPress sites for clients I realized that I needed a way to showcase the sites for the client before they signed off and took the work (and paid me, also a critical part of it all). So I set up a number of memorable subdomains for testing WordPress themes in order to show them to clients. For the sake of an example, say I used these (which I didn’t):


Each was a URL that I would remember, but also had a cutesy novelty about it, which is important when you’re sitting behind a computer by yourself making websites. In any case, before long this system broke down. It was getting to be too much of a pain to break down the previous client’s project in order to put together the next client’s project. While managing a small number of these installs (usually equal to the number of projects I had going at any one time) was nice, the work in between each project wasn’t. So I needed a new solution.

The better way to achieve this is to have a separate installation of WordPress for each client. That’s right. So, in your case, add a subdomain of “client” to your main domain (or whatever you want to call it) and plan on hosting all of them from there. Then, within this new subdirectory, add a number of new subdirectories, a to z. This will server to separate each of your client’s names. Put them in the corresponding letter’s folder, then put each project for that client within that folder. When the time comes to launch a test site for them built on WordPress (or really anything, for that matter) you literally launch a brand new WordPress install for the occasion. The upside to this technique is you never have to undo what you did for a previous client, and previous client work is always saved in its final development stage.

Also, before you freak out and think that this means maintaining a bunch of different databases for WordPress, remember that you can install WordPress multiple times into the same table using the prefix in the wp-config.php file (change it from wp_ to clientname_projectname_ for each one). While I wouldn’t suggest running WordPress multiple times in a database for public WordPress sites with much activity, for one-off client showcase sites, it’s totally perfect.

Hopefully it goes without saying that you probably want to password protect your clients directory. Just sayin’.

Quick tips for efficiency

  • Get in the habit of clearing out the default content that WordPress adds in. This stuff is just annoying, and really isn’t much fun to get rid of every time you install WordPress. It just needs to be done. Kill the Hello World post along with its comment, the About page, and all of the links in the Blogroll. That’s stuff that you don’t need to be bugged with later.
  • Put together your own base of content that you can import into each WordPress install to test the thoroughness of your code. WPCandy put together a decent importable xml file some time ago, but it’s really best to put it together yourself so you know what to expect.
  • Use a random password generator for each install you set up (on the install screen, when it asks for your password) instead of the same password that you have memorized. This will add to the security of each of your client installations, and not leave your client projects all threatened if someone ever grabs your password.
  • Keep a list of your favorite WordPress Plugins, and just install them right away. Even if you don’t activate them all right away, just throw them in there. I keep a steady list of Plugins for each site I run (probably worth publishing sometime…) and it can be handy to have them waiting inside of WordPress for when you do decide to activate them.
  • Visit your permalink settings page and cater it to your needs. Lately I’ve been leaning toward /year/category/post-title for blogs like this one, but /year/month/day/post-title for my personal blog. Blogs like this one don’t rely heavily on the day of the post, while my personal blog tends to. (Sidenote: it’s annoying that WordPress still defaults its permalink setting to list the post/page ID. It’s about time this was changed to name, don’t you think?)
  • Size your preferred post box size on the writing settings page. Assuming you’re actually going to be writing for the blog a bit, why not change the default amount to a bigger one right away? Anything under 30 or 40 lines seems a bit crunched to me, but everyone has their preference.
  • This isn’t really an efficiency tip, but worth mentioning: download WordPress anew each time you install it. This guarantees you are getting the most up to date version of WordPress, and also ensures that the download count on more closely resembles the actual number of installations out there.

That’s my list right now. There’s still a lot more to be said: how best to actually develop a theme for WordPress (as well as test it) for one, but that’s best saved for another day. What tips do you have for those of us installing a lot of WordPress sites each week?

11 thoughts on “Tips for Running Lots of WordPress Installs Efficiently

  1. I’m starting to run across more developers using WordPressMU to manage multiple installs for this. Which can be done pretty easily. 🙂

    (I should probably whip up a tutorials for it..)

  2. That’s interesting Andrea, do you know of any potential downsides to taking that direction? Would you expect there to be any compatibility issues between the client who will be running a WP install and the WPMU install for testing purposes? Just curious, I’ve never really looked into it.

  3. The biggest downsides include a pile of plugins that just don’t work under MU. And releases are usually behind. For instance, WPMU 2.7 isn’t official yet, although the trunk version isn’t too bad.

    But once it’s all set up, you can add another client site with filling out two fields and clicking a button.

  4. Yeah, that’s kind of what I thought. Still, might be worth my trying it out. Less work is always a good thing.

    And if you’re serious about wanting to write that WPMU piece, let me know if you’d like to guest-star here for a day. Wouldn’t mind at all 🙂

  5. One of the ever increasing issues I found was on keeping plugins updated for the various clients.

    For this I suggest keeping one central excel document in the top level of your design folder.

    (link to image which will help understand the below: )
    This document then contains the client names starting from C1 and in corresponding columns, with the site address below that. You may like to add admin user name and pass.
    Then from A3 down I list WP and the relevant plugins, with the install version besides that.

    Finally I use conditional formatting to tell me at a glance if a plugin for a particular site needs updating based on the version I have installed. I just update the latest version numbers once a month or so. If red you need to update, green is okay – and N/A means the plugin is not installed at that site.

    Not hard to keep track of when you have a few sites, but when you start creating more it’s a handly little guide.

    I also keep a separate ‘plugin’ folder with the most up to date plugins which I add the latest versions to, with old versions hitting an ‘archive’ folder.


  6. Pingback: links for 2009-01-16 — Chroniques du web

  7. Hi, very interesting article.

    I have developed a similar system to keep track of the various WordPress websites I manage. I find it essential to have a process and checklist to make sure everything gets done properly. Without a checklist, mistakes can, and will, happen.

    I have also come up with another little system to save time and ensure I add tags, categories, meta description and meta keywords to each post I write (I quite often forget at least one and have to go back into the post for a further edit!). I changed the post writing page layout in 2.7 to two columns instead of three with the save/publish button at the bottom of the page. Scrolling down acts as a kind of pre publication checklist. I wrote a post about it today (funny enough), but I haven’t added a link here as I am not spamming! I have found this technique to be very efficient when writing a new post.


  8. I have found Subversion (SVN) very handy for keeping loads of WP sites and plugins updated.

    All you need is a text file with the locations of the plugins’ trunk folders (most of them are on and as long as your host supports svn then you paste it into a file in the plugins directory – then you can just install and update each site by typing ‘svn up’ once you’ve ssh’d into its directory.

    It’s a small learning curve to learn the svn commands but once you’ve done it, it’s SO much easier.

    Also when a new WP version comes out, it’s a ten second job to install it on each site.

    I may do a short tut on my site if I get a minute.

    I’m gonna look into the WPMU thing as well, have noticed a lot of job sites need people with those skills.

    Thanks for the post!

  9. I do something like this but I have a bunch of extra domains that I sit on and I use each domain randomly for demoing a site. I never thought of using a subdomain but I’ll start doing that instead. I always make sure to use robots.txt to make sure this content isn’t indexed if engines find it.

    I also create a new DB for each site just to make it easy to export and import into the permanent location. Does the DB allow you to export just a specific set of tables? If so, I would use one DB too…

  10. I have built a wordpress site from scratch as a test because more and more clients are expecting to be able to update their own sites. WordPress seems to be the solution. While this article is helpful, it doesn’t cover how to actually move a test site to the clients server without breaking code. Would love to see a tutorial on this.

Comments are closed.