8 minute read.

A website checklist. 20 things to check before going live.

Paul Anthony / March 20, 2008

Posted in: Archive

As developers we all know the highs of launching a new site, but how many of us have went through a step by step list checking off all the to-do items. The following is (in no particular order) what I normally go through before setting a site live.

1). Meaningful Page names and folder structures

page-titles.gifMake sure that the page names themselves are relevant to the content they contain. Remember that Hypens in page names are more effective from a search engine perspective than underscores. So-try-to-keep-this-in-mind. But dont be too spammy with keyword after keyword or go overboard with length. You get the picture. Folder names should also be meaningful, and relevant to what they hold. Images for images, css for css. I’ve a sample folder structure in another article.

2) ALT Tags on all images

Make sure your alt tags have meaningful names, that helps again with SEO. There also has been some talk about putting a break out of frames script on your site to catch Google image traffic. Due to the fact that Google images uses frames to show images in context – something like the below would be appropriate:

<script language=”JavaScript”>
if (top.location != location) {
top.location.href = document.location.href;

3) Page Titles always set [ no ‘untitled document’]

page.jpgEasy to forget, and a stickler for poor search engine results. At time of writing, you would be competiting with 26,400,000 results. So good luck with getting any relevant traffic. Plus it looks pretty unprofessional in the web browser. Dreamweaver normally sets this to Untitled Document, or if you leave the title tag off altogether Firefox shows “Mozilla Firefox”, and Internet Explorer just shows the user the path to the file.

4) CSS and XHTML valid

Goes without saying. Considering that we are a bit obsessed with standards compliance, and the like we always like to check our documents for validity, and you should too. XHTML must be checked, as should CSS compliance. Good code is good business, and ensures forward compatibility.

5) Server side includes for Navigation / header / footer

Make sure that you also separate out these badboys, for maintainance reasons. Having to tweak a logo, or copyright date is made ten times easier if you have separated out your code into include files.

6) Footer copyright date and text

copyright.gifWe tend to go all dynamic on sites that support this by writing out the current year automatically. But you can do the same sort of thing with Javascript on static websites quite easily. Its one less thing to worry about maintaining.

Copyright © 2008
<script language=”JavaScript”>
var d=new Date();
if (yr!=2008)
document.write(“- “+yr);

7) Meta Data on all pages

meta.gifYes I know, most people think it useless. But Google uses <meta description> to show a site description in the SERPs, and if this is missing (or looks spammy) then they use on page text. If you want clickthroughs, write (for every page) a unique meta description, and make it appealing to visitors. Don’t be tempted to write meta descriptions for the sole benefits of the search engines, natural language is critical here.

8 ) All javascript externalised

I hate seeing sites with inline javascript (or for that matter CSS) code, its lazy, adds weight to the page, and cant be cached by the browser. Get all your javascript code into an external file, and if you are still using that dreadful Adobe / Macromedia legacy code for image swaps and preloading, shame on you. Bloated unreadable code.

9) Footer links back to your site

alttag.gif If you create websites for other people, you can ask them politely if they would be willing for you to place a link to your website. Make sure you link it with the link text being something relevant to your website. i.e. your chosen keyword phrase which you wish to rank for in the SERPS. An extremely simple way to get additional traffic to your site, and improve your search engine position. Dont bother using your company name as link text, you probably already rank for it, and its a waste of a link.

10) Text size – able to make larger and smaller

This is an accesibility must, if you use % or ems sizing for your text, then you will be able to resize it in all browsers. Fixed pixel will constrain text size. If its not absolutely necessary try not to use pixel sizes for text in your CSS stylesheet. Some designs require this to prevent them from being broken at larger text sizes, but it is definitely better not to force your visitors to read your content at a specific size.

11) Site meets Accessibility Guidelines

access.gifOne of the easiest ways to ensure accessibility is to separating style from presentation using CSS layouts, so the site degrades gracefully. Use text equivalents for every non-text element such as Alt tags. The full list of accessibility guidelines can be found on the w3c website.

12) Spelling

Bit of a personal issue with me. I hate spelling mistakes, definitely worth going through a site with a fine tooth comb for spelling issues. It will prevent you from looking unprofessional, and could even make the difference (if you are an ecommerce retailer) when making a sale through your site.

13) Alignment

shock.jpgIf you have any experience with building websites, you will know that different websites can render content hideously differently. Unfortunately we aren’t in a place (yet) where we can create valid XHTML content, and expect it to render the same across all browsers. We are closer than we were a couple of years ago..but not quite there yet. If you are using CSS layouts, it is slightly more difficult to provide consistent layout across browsers rather than tables, but the juice is definitely worth the squeeze. Get yourself over to browsershots.org to see how your site renders in different operating systems with different browsers.

15) Images Quality

Images are a key opportunity to wow your visitor, unfortunately sometimes that comes at a cost. Higher quality images = slower download times, and vice versa. Make sure you dont overcompress for the sake of a few kilobytes if a crisper image would look better. With the uptake of broadband now, its not something to worry overly about. Also make sure that your images dimensions are not constrained via HTML. This will warp the image, and if it is bigger than the space it fits into – be a waste of bandwidth. Always resize images with a photo editor – not with HTML.

16) Forms testing and validation

softwaretesting.jpgAlmost if not all websites have forms of some sort to either collect data, or provide feedback, or send email. Always check that these work when you launch, mainly because the setup of your testing and live server is almost always different. Forms should always have both server validation and client side javascript to validate input. Not one or the other.

17) Register your content rating

A little known, but useful tip is that you can register your website at the Internet Content Rating Association. This makes your website easier for filtering software to distiguish as “in a good neighbourhood”. i.e. Not pornography or other objectionable content. Simply fill in a questionaire, and they will give you a file to upload to your website, and some code to add to your meta tags or ask your website developers to do this for you. Voila, your content has now been correctly tagged.

18) Sitemap.

sitemap.jpgEvery website should provide a sitemap for the search engines to crawl. You can see what our sitemap looks like over here. It is quite easy to generate one of these, either dynamically (if you have a database driven website) or manually if it is a static site. In fact we had ours created automatically by xml-sitemaps.com.You can then style up the sitemap using XSLT. Feel free to copy our XSLT file if you so desire. To check if your website has a sitemap, or you are checking if your webdevelopers have created one, the easiest way is to look for the existance of a sitemap.xml file. i.e. www.domain.com/sitemap.xml.

19) Favicon

Everyone loves icons. In fact, there are tons of websites out there dedicated to creating your own favicon for your website. And some that will convert standard images to favicons.

When you have that done add the following to your site:

<link rel=’shortcut icon’ href=’mypage.ico’ />

and it will appear when you add the icon to your browsers favourites. You can also have animated icons in Firefox. Which is a little gimmicky, but hey I thought I’d throw it in there for completeness sake.

20) Privacy policy in place

privacy-policy.jpgYep, the data protection act law states that we have to do it, if you are collecting data of any kind. In addition to having an applicable privacy policy, you should also have your registered company details available from your website.

  • alt tag
  • copyright
  • css valid
  • email
  • folder structures
  • footer
  • images
  • page names
  • privacy policy
  • sitemaps
  • things to check
  • website promotion
  • xhtml

23 responses to “A website checklist. 20 things to check before going live.

  1. Well written. And comprehensive too!

    I like your inclusion of accessibility testing. It’s great to see this is something that is becoming more and more of a factor when testing.

  2. I think ‘4) CSS and XHTML valid’ would be better saying tested in a range of modern browsers. Anyone who has made a CMS that has end users on it will know getting a site to validate is almost impossible.

    Good compatability is good business (which often stems from good code) but code that validates doesn’t give you any benefits and often wastes time and money.

  3. as for point 4, this page is not valid! lol,
    Line 340, Column 12: end tag for “ol” which is not finished

    Most likely, you nested tags and closed them in the wrong order. For example … is not acceptable, as must be closed before . Acceptable nesting is:

    Another possibility is that you used an element which requires a child element that you did not include. Hence the parent element is “not finished”, not complete. For instance, in HTML the element must contain a child element, lists (ul, ol, dl) require list items (li, or dt, dd), and so on.

    good pointers though!!!! keep up the good work

  4. Thanks a lot for this article, some really good points here. I’m not a webdesigner (just a copywriter), but my friends are and they surely could take a look at this and change some habits. :)

  5. In #2, you propose javascript to “break out” of a Google image search. This breaks a couple of important rules.

    First, users have an expectation of a 2 frame interface when doing a Google image search; to automatically transfer the user from the result page they expect to one they do not, you are unexpectedly modifying their experience, causing them to lose good-will with your site.

    Next, many of us using assistive devices/software (or even those with normal mousing skills) can’t click the back-button twice fast enough to return past javascript-redirecting pages. The only option is completely close the browser window and start the browsing session all over again … which is in frank terms, inconsiderate and rude.

    Would you do business with, or return to a store that blocked all exits once you arrived? What is the actual benefit of exiting Google Image Search frames that is worth souring your visitors against your site/products?

  6. @Joe – have you ever tried to integrate this into a site to see the visitors reaction / web stats? I’ve noticed on some sites up to a 60% rate of clickthroughs onto other pages through the site, after breaking out of the Google interface – with images that have been appropriately tagged. Now if that visitor turns into a sale – that’s traffic that shouldnt be ignored – particularly for e-commerce.

    All of that is of course a matter of opinion, and at the discretion of the webmaster / site in question.

    I dont know about the good-will comment – people searching for images with image search are generally expecting a few things..a) possible broken images b) images that aren’t in the public domain for consumptions and c) the possibility of either a break out of frames – or a no hotlinking image.

  7. @admin
    re user reaction: See ieee’s article on “Interface Adaptation Based on User Expectation”, or Jacob Neilson’s Usability reports. Specifically, users’ response to unexpected or surprising interface behavior that are inconsistent with previous/expected results.

    re goodwill: See “reservoir of goodwill” subjects in usability expert Steve Krug’s books.

    re converting page views into conversions (or sales): Users who find what they are looking for will not be prevented (or deterred) from clicking on “add to cart”. If they prefer not to remain in the frame, google provides a direct link to the current page.

    However, forcing a user into a redirect cycle from which they may not be able to escape is a sure-bet way to guarantee the user will never return to the site.

    Why is forcing the user’s experience out of the google image search frame important?

  8. Well. Because not every image on your site is likely to be a “product image”. And therefore it may take a click or two to convert a visitor.

    Regardless of what your opinions are – the tip is there for those who wish to try it out, monitor their analytics and make decisions for themselves.

    I wouldn’t start quoting Jacob until your own site is in tip top “presentation separated from content / unobtrusive javascript” condition.

    People in glass houses and all that.

  9. Oh snap, gotta make it personal. Granted, I should have found time in the last 5 or 6 years to update something/anything on that nearly-abandoned site. Maybe it could be used as a great bad example of outdated techniques!

    But for what its worth, its not being marketed to developers as a checklist for best practices, nor is there a concern for converting either of the two visitors I get per month.

  10. Fair point.
    For what its worth – I never intended it to be a “best practice guideline”…

    [quote]The following is (in no particular order) what I normally go through before setting a site live.[/unquote]

    The developer community is big enough and bad enough to make decisions on their own regarding usability / rule bend / seo / what they bookmark. I’m not here to prostitute opinion.

  11. I would also add making sure that your CSS looks the same in all browsers, especially IE and FF. Things can go radically wrong with the incompatible Box Models.

  12. Good list always handy to have a pre-live check-list. What about custom 404/error pages? especially essential if file names or folder structure have been updated and bookmarked or indexed pages no longer exist.

Leave a Reply

Your email address will not be published. Required fields are marked *