Without much ado:
1. Has Google Analytics or equivalent software.
Why is this important?
You should be tracking how your pages are doing, which pages are popular and which of your pages are making money. Use Google Analytics or equivalent software. (haveamint.com, Kissmetrics.com or Mixpanel.com)
2. Has been tested with Pagespeed(http://code.google.com/speed/page-speed/) and Yslow(http://developer.yahoo.com/yslow/).
This is important as 70% of user visible speed improvements come via improving the client-side optimizations. Pagespeed and Yslow check your site’s conformance to best practices and can suggest areas of improvement.
3. Has a usability testing done via feedbackarmy.com and usertesting.com.
This is important as customers drop unusable websites to go to competitors. Even testing with 5 users can find 85% of the usability issues. These websites make usability testing simple and affordable.
4. Admins get error emails when site error happens.
No matter how much you have tested, users are going to do unexpected things to your website, which can cause site errors. If you get a email informing about this, you can fix this proactively.
5. Has monitoring setup with Siteuptime.com/Pingdom.com or equivalent.
No matter how good your infrastructure, sites crash. A site-monitoring service can inform you before your customers do.
6. Media and database are backed up.
Servers die, humans make errors. Your website data is too precious and backups are affordable.
Your web host can generally provide you a option to backup entire servers. You should also be backing up your database and media to a separate server from your main host.
7. Backups are tested.
Doing backups is useless if you never test them. Too many people miss this obvious step when they setup their backups.
8. Has a sitemap.xml
Search engines are good at finding all your pages, but with sitemap you can guide and hint them, as well as guide about the relative importance of the pages.
9. Has a robots.txt
You may have a lot of things you do not want the world to know about. (Eg user uploaded media). Use robots.txt to hide them from search engines.
10. Has been tested in multiple browsers.
Your development team may have only tested a subset of browsers. Use a service like browsershots.org and you can ensure your site looks good in all browsers.
11. Users have a way to contact admins
You should have a contact page and make it easy to contact you and email you.
12. Admins get emails on broken links.
Pages are moved around, and links break. These links can be extrnal or internal. If you are notified when a user gets a 404, you can respond. (For example put the redirect at the old url.)
13. Has a whats new section and/or a RSS feed.
Your customers would like to know about you. They should not have to search to get this info. If you use a blog software a RSS feed should be automatic.
You can download this checklist as pdf here.
Did I miss anything? Email us at [email protected]
Have you joined our newsletter yet http://eepurl.com/e1zk2
We cover Webdev, Django, SaaS, Mobile and cloud computing and
help you “Build amazing webapps”.
{ 20 comments… read them below or add one }
> 4. Admins get error emails when site error happens.For Python applications, see KeyError: https://www.keyerror.com/
browsershots.org not browsershots.comThanks for the heads up on that, and all your other tips!
Another useful tool for performance profiling is the Pingdom Tools.http://tools.pingdom.com/It fetches your page directly from their servers and can be useful in troubleshooting issues that may not be apparent from the developer’s browser/location.
AndyJ: Fixed, thanks.
Sentry (http://readthedocs.org/docs/sentry/en/latest/index.html) is another option for Django sites. Admin error emails can be dangerous because you can get banned from services like Gmail if they are too frequent.
UserVoice (uservoice.com) is a great way for users to be able to contact admins for help or with feedback (#11).
Nice list. TXH!
You forgot one super important thing: Security ReviewOne thing I always do before launching is having a security review. Launching and falling flat on your face because of obvious security problems is almost worse than having bug ridden code and a crappy UX. A week or two delay by being proactive and conducting a security review will save you countless hours and sleepless nights of being reactive ‘when’, not ‘if’, your site is compromised.
Brian: I didnot add that as apart from paying someone big bucks, what is the easy way to do this?
It obviously depends on the specific site you’re building of course and what framework if any is utilized. One thing I find often is that there is sometimes an implicit reliance on the UI to restrict what a user can access.I work in Rails and an extremely common thing I find is an authentication before_filter which forces a logged in user before access to any actions in a controller is given. Beyond that there sometimes isn’t any other restrictions other than relying on what the UI allows. For instance, a things_controller might have a before filter to require a logged in user and the UI might force URLs that a logged in user access to look something like /things/4 where 4 is the thing’s db id. The UI forces all the URLs to be correct but a user could easily manually change the url to /things/5 and get access to a thing that’s not that user’s data. This type of thing happens all the time, especially when you’ve got a ton of different controllers and data that can be accessed by different users. The correct behavior should be to explicitly check that the logged in user has permissions to access any of the data. Instead of doing Thing.find(params[:id]) you should be doing something like current_user.things.find(params[:id]) to make sure that the current user is only able to access its own data and no other. Its obvious to spot and extremely simple to fix but it happens over and over and over again.I always try to take the time to review all the code in the app for obvious problems like this. Its pretty easy to spot and it happens enough that it a security review is well justified. Another thing I do is try to clean up any unused code and routes. Even before your site gets launched there will likely be a handful of code that was created in the development process that isn’t being used anymore. By removing unused code or unused routes, you reduce the potential attack vectors on your app.There’s always improvements that can be made regarding security and you could go down a rabbit hole of what-ifs. However, there are some extremely simple and quick things you can do to greatly improve the security of your application before it launches. An hour spent being proactive is worth a week being reactive.
You do not want to do #12 (Admins get emails on broken links), unless you have a way to filter out all the hits from bots looking for common vulns.
Why pay that much for website monitoring – only $10 at NodePing (nodeping.com) to watch up to 1000 sites/services at one minute intervals. Best deal out there.
One checklist item to address re: security is verifying that every single database call within the site’s backend is run through a sanitizer. SQL Injection seems to be the dominant method of breaking into websites, and has been consistently effective for years.
Open Web Application Security Project ( http://OWASP.org ) has some cheatsheets on testing for web security issues. These can easily be added as a checklist and a basic security review is a possibility. Although unless the coverage is complete one can never has the assurance of a secure website but doing a basic security review will ensure some glaring security issues can be taken care of.
It’s easy to forget the basics while you’re in the middle of launching your website. This list is a nice reminder. Thanks.
This is a good list thanks. I was inspired by >> 4. Admins get error emails when site error happens.to examine this a little further. I think there are plenty of triggers which can be used get such email so I wrote a post on it. http://13.7billionyearslater.net/2011/checklist-of-webmaster-error-notificati…
I’d also add FavIcons, I’ll admit, I don’t use them, however if not used, they clog up your Apache error_log and also waste server requests, plus if someone bookmarks your site, at least there’s an icon. Small yes, but I think it’s something to look out for.
Patrick: http://agiliq.com/newsletter/the-website-launch-checklist-part-2