One of the most important steps in the pre-launch phase is an in-depth QA process, including usability and cross-browser testing.  But let’s assume that step has already been completed and your site is bug free and looks snazzy in all the major browsers.  Heck, let’s even say you’ve got a kick-ass mobile version and that everything degrades gracefully with javascript disabled, or on a horrible, outdated browser (I don’t think I need to name names here).

Aside from making sure everything works and looks good, here is a list of items to check on and implement (if you haven’t already).  Many of these may seem rather trivial compared to larger issues like site functionality, but the little details are important and you want to put your best face forward when presenting a new website to the world.  The lack of a favicon may not drive people away from your site, but those small details will be noticed and appreciated by users as well as peers in the industry.  Other items on the list can be much more crucial to the usability and success of the site.

Add Google Analytics and create goals and/or events

There’s nothing like having a great response to your newly launched site – only to realize you’ve forgotten to add analytics tracking code.  But beyond just adding the code so you can track your site’s traffic, it’s also helpful to set up events and goals within Google Analytics. Having goals will help you measure how successful your site is, beyond just the number of page views. For more information on goals, see this presentation, Goals in Google Analytics.

You may also want to set up some events so you can track specific actions that may not be measurable by page view counts and user paths.  On one site we launched recently we wanted to measure how many people were logging in using Facebook Connect, as opposed to logging in using the traditional method.  Creating Events let us track those actions and compare them. For more information on setting up events, see Google’s Event Tracking Guide.

Proof-read and check for straggler placeholder content (“lorem ipsum”, FPO images)

Typos and grammatically incorrect sentences are easy for a developer to miss when they are concentrating on making sure the site looks and functions properly in the week(s) before launch.  Hopefully misspellings and forgotten “Lorem Ipsum” text will be caught in QA, but they could be overlooked if the focus is on testing functionality.  Take another look through the site yourself, but more importantly, ask a friend to proof-read or ask your mom to see if there’s anything she doesn’t understand.  Getting new eyeballs on the site is always better than just looking at it yourself for the 5,278th time.

Check for hard-coded links containing your development URL

Sure, your links and assets may work NOW, but will they after you’ve pushed the site live and the development site is taken offline?  Even if you keep your dev site up and running, if you are still linking to JS and CSS files from your development site you’ll probably end up wondering why those edits you are making to the live versions aren’t having any effect.

The easiest way to avoid having development URLs on your live site is to not hard-code those links at all. If you are using WordPress there are several ways to have URLs generated dynamically:

• Use the constant TEMPLATEPATE for PHP includes
• Use get_permalink() to retrieve the permalink for a specific page
• For assets, use bloginfo(‘template_directory’) to get the URL for your theme folder. Then append the rest of the path to the CSS or javascript file

Check your SEO and robots.txt

Any optimization for search engines should be completed before the site is launched. Sometimes SEO might not feel “essential” for a site launch but you really want it to get the most momentum coming out of the gate so it’s best to have everything set up before launch.  Check your robots.txt file as well to make sure it is formatted properly. Mistakes in the robots.txt file could mean that certain directories are not indexed by search engines. For some common mistakes to avoid, see the article The importance of Robots.txt and scroll down to the section “Things to Avoid.”

Add an XML Sitemap

Generate an XML Sitemap of your finished site using a sitemap generator, or a WordPress plugin.  If you generate it yourself, place the XML file in the root directory of the site.  The sitemap will help search engines crawl your site and index your pages.

Test your site in YSlow and fix any obvious optimization issues

Hopefully you will have used YSlow or Google Pagespeed during the development process to spot problems early. But even if you have checked during active development, last minute changes or additions may have made a big impact so always check again.  Reduce your HTTP requests by combining CSS and javascript files and using sprites.  Minify and/or Gzip scripts to reduce their sizes.  Move assets to a Content Delivery Network if one is available (this is especially important if you have videos or large downloadable files).

Turn on caching

To ensure your site is “Digg-proof” (can handle a large spike in traffic, usually caused by being linked to from a site like Digg) site caching is essential. If you are using WordPress, here are a couple of great caching plugins: WP Super-Cache and W3 Total Cache.  Super Cache will save static HTML copies of your pages so that they will not need to be dynamically generated with PHP every time someone visits.  No need to worry about your dynamic content disappearing though – if you add a new blog post or if someone posts a comment, the static page in the cache will be recreated.  W3 Total Cache doesn’t go so far as to create a static version of your site, but it does do many other things that will increase the load speed of your site and lighten the load on the server.  Whichever method you use, enabling caching before launch will prevent unexpected downtime should a “Digg”-type event occur (and typically you will never predict when that might happen).

Make some security checks

Are any of your folder or file permissions set to 777?  Do you have an easy-to-guess password on the admin account for your CMS? Do any forms on the site submit data to a database without first being checked and filtered (to prevent SQL Injection Attacks)?

Add a favicon

The cherry on top of your website sundae. But beyond just looking all pretty up in the address bar of the browser, the favicon will also be displayed in certain situations if your site is bookmarked. Having a little icon to go with your site  helps it to be identified amongst the user’s other bookmarks.

and finally…

Give yourself some credit!

If appropriate and you’ve discussed it with your client, add a ‘website by…’ attribution and link into the footer of the site (or on a “credits” or “links” page).

See anything I missed or have something on your pre-launch list that I didn’t mention?  Leave it in the comments!

Oh, and happy new year!  Here’s to many successful site launches in 2010.

When you install WordPress, you will automatically have a user account named “admin.”  Everyone who knows WordPress knows this.  And that includes the bad folks who want to get admin access to your site.  Because they know that your site probably has an administrator-level account with the username “admin,” half the work is done.  Then they just need to figure out your password.  One of the most common attacks on WordPress sites is called “brute force” password guessing. A script will keep trying different password combinations until it finds the correct one.  They usually aren’t successful, but sometimes they hit the jackpot – and you don’t want your site to be the lucky winner.**

To defend against this type of attack, there are three fairly basic things you can do:

1. Have a good password
2. Get rid of the “admin” account
3. Ban anyone with too many failed login attempt

Creating a strong password

WordPress makes it really easy to have a good password.  When you edit your profile and change your password there is a “strength indicator” that will tell you if your password is very weak, weak, medium or strong.  Always shoot for a “strong” rating.  That goes for anyone with any user role, but especially for someone with administrator-level access.

Getting rid of the “admin” account

This is a little more involved, but still really easy.  The most painless way I have found to accomplish this with WordPress is to use WPVN Username Changer to change the username from “admin” to something else.  The plugin doesn’t work with WPMU yet, unfortunately, as it doesn’t seem to transfer Site Admin status to the new username.

Here are the steps I’d recommend to change your username:

1. If you want to change your account’s password to something other than the generated password, I found it’s easiest to change it before you switch usernames. If you do change it, make sure it gets a “strong” rating.
2. Backup your database (unless it is an untouched, fresh installation of WordPress).
3. Download, install and activate WPVN Username Changer.
4. Expand “Users” in the main navigation, and click “Change Username”.
5. Enter your new username, click save. The plugin will ask you to log in again using your new username (This is where changing your password comes in handy – you don’t have to go back to your installation email to copy/paste the generated password).

(yup, it’s that easy.)

There are of course other ways to rid your site of the ‘admin’ user.  Aside from other techniques for changing the username to something else (directly editing the user in the database), you can also create a new account for yourself, and then delete the admin user.  Steps for deleting the admin account are outlined clearly in this post at Internet Techies.

If you go this route, just be extra-cautious that you have given your new account proper permissions before you delete ‘admin’.  In WordPress, it’s as easy as changing the user’s role to ‘administrator’.  In WPMU, in addition to changing the role, you will need to add the new user name to the list of site admins on the Site Options page.  To do that, expand the Site Admin section in the navigation, then click Options. Scroll down to Administration Options. Add the new username(s) to the site admin list, separated by spaces.

Ban anyone with too many failed login attempts

There are a couple plugins I’ve found that can do this for you (though I’m sure there are more): Login Lockdown and  Limit Login Attempts. These plugin allows you to block anyone that has more than a certain number of failed login attempts.  You can specify what that number is in the plugin settings, as well as the duration of the lockout. Login Lockdown displays the IPs of anyone currently locked out on its options page.  Limit Login Attempts goes one step further: it can keep a log of all lockouts, and/or email you whenever it happens.  Also, if anyone has multiple lockouts (you can choose the number), Limit Login Attempts allows you to block them for an even longer period of time.

Final notes: Strong passwords, strong passwords, strong passwords. Did I mention strong passwords?

So you’ve deleted or renamed the ‘admin’ account, so you’re protected against malicious automated scripts.  That’s great!  But let’s say someone holds a grudge against you for that time you beaned them with a dodge ball in P.E.  And they have a new brute force password cracker they are dying to try out.  There are a couple ways they could discover your username. Aside from the fact that they may be able to guess it (if it’s your first name for example), they could also find it if you have posted any blog posts with your administrator account, and use the_author_posts_link() in your template.  That function generates a link to an archive of your posts, in the format of  http://www.site.com/author/nancyq. There’s your username, exposed to the world.  If they guess your password, they are in.

Even if you don’t have author archives, your username may also be displayed in the RSS feed generated by WordPress.  If you have not changed your display name from the default, the RSS feed source code will show your username as the content creator.

It’s probably not likely that you have a nemesis from 5th grade trying to get access to your blog – and both the above scenarios are easy to fix or avoid. However, if someone with malicious intent knows (or can guess or find) your username you can be in trouble if you have a weak password.  Even if a hacker gains access to an author or editor account, even though they couldn’t do a whole lot of harm, they could still post links, naughty pictures, or worse, blinking blue text saying “pwnd”.

If you don’t know how to create a good, strong password, there is a lot of advice out there.

Some resources

A strong password, some tricky username tactics, and locking down your login form are all some very basic things you can do to protect your WordPress admin area.  Of course there are many, many more things you can do to protect against brute force attacks, as well as other types of common WordPress attacks.  Google “wordpress security” and you will get a LOT of info.  Here are some links to get you started:

Hardening WordPress (WordPress codex)

13 Vital Tips and Hacks to Protect Your WordPress Admin Area (WPBeginner)

11 Best Ways to Improve WordPress Security (Pro Blog Design)

WP Security Scan (a plugin that will scan your site/blog for security vulnerabilities)

** Distributed account hacking schemes could be making brute force password guessing a more wide spread and successful. See articles:
Web service automates Wordpress account cracking
The Hail Mary Cloud: Slow but steady brute-force password guessing botnet