Continuing on from our introduction last week of securing your WordPress site, we’ll address some wp-config.php changes, backups and updating your WordPress instance.
5. One of the most effective changes you can make is to change your WordPress database prefix names. This will change the database table names and will make it much harder for malicious users to guess your table names. This does take a little bit of work but can be done easily with a little planning. Some instructions on how to do it can be found here.
6. WordPress uses 8 (as of v3.0) secret keys to add an additional layer of security to your site. These keys can be changed at any time, although currently logged in users will be logged out. To update these, visit WordPress’s Key Generator and copy these keys into your wp-config.php file.
7. Aside from your hosting provider generating nightly and weekly backups, you are encouraged to collect your own off-server backups of atleast the database and preferably the file system as well. The simplest way to do this is to use PHPMyAdmin to export all of your WordPress tables and then use a simple FTP client grab a copy of your whole WordPress installation. Since your host will provide nightly and weekly backups, we would suggest grabbing a copy of your site once a month and storing as many revisions as you can mange (12, 24, etc). WordPress.com provides some information on how to do this, or have your hosting provider add this to your general site maintenance routine.
8. Lastly, update your WordPress instance. Nothing is more vulnerable than an old, outdated site, displaying version information! With WordPress v3.0 and above, upgrading is a snap. If you have a complex site (member management, ecommerce, etc), you may want to build a mirrored site that you can upgrade to the latest release and test in your environment. Once your happy with the release and it has been tested thoroughly, you can proceed with upgrading your live site. In either case, you will want to grab a dedicated backup of your WordPress site files and database prior to doing any upgrade (see #7 above). It is far easier to do a quick database/filesystem restore yourself than have your hosting provider queue up a restore from last night.