Donald L. Merand

Checklist for Making Friendly Web Pages


When I wrote the code for, I decided to try my best to adhere to good programming practices and standards for as many elements of the site as possible - the generated HTML, the CSS, the RSS feed, and everything else I could think of. Some people might say that all code projects that everybody does at all times should adhere to best practices and be syntactically valid. People who say that have never worked in a production environment of any sort. That, or they work in very well-supported, well-managed, and well-funded programming environments and have few deadlines.

Here’s what I found about web standards: good programming practice is a somewhat moving target, having just as much to do with æsthetic preference as any hard-and-fast rules. Syntactical validity is basically concrete in programming languages, but on the web it’s different. For example, a big point of the HTML5 standard is to slyly, quietly deal with the poor syntax that’s all over the web. If we all wanted pure and perfect web standards, then we’d have all jumped on the XHTML 2.0 bandwagon. How many of us actually did?


Having said all of that, there are some things you can do as a web programmer that most everybody agrees are Good Things, and you should probably be doing in Most of your Projects. There are also some things that I say you should do, because I’m biased just like everybody else, and you’re here to listen to me, right?

To spare myself (and maybe you) from having to remember all of those things when making my next site, I made a list. So here you go…

Checklist for Making Friendly Web Pages

  1. HTML4 should be validated by the W3C HTML Validator
    • Don’t bother with a <!DOCTYPE> of anything XHTML unless you’re actually going to modify your headers to send a MIME type of application/xhtml+xml. As it turns out, if you send a regular text/html MIME-type, your page isn’t being parsed as XML at all
    • HTML5 should be validated with a HTML5 validator
    • Bonus points for passing HTML lint
  2. If you’re going with HTML5, you might want to check for browser compatibility eg. with modernizr.
    • Also check this link for single-item compatibility if you don’t need more that a couple of HTML5 functions.
    • Also this link is a great resource for what’s new in HTML5.
  3. CSS should be validated by the W3C CSS Validator
    • Bonus points for passing CSS lint
    • Bonus points for minifying your CSS.
    • Bonus points for using sass for your own CSS sanity.
    • Double-extra bonus points for including style elements for different media types. For example, you might want to include a “print” stylesheet that hides your sidebar/navigation elements, so that when articles are printed, only the content comes out.
  4. If you have any sort of dynamic content (blog posts, etc.), you should have an RSS/atom feed.
    • Your RSS feed should be validated by a RSS Validator
      • Though it’s technically optional, you should include a <link rel="alternate" type="application/rss+xml" href="/rss/" /> tag in your <head> section, to indicate to feed readers such as Google Reader that visit your main URL where the rss feed is (in this case a RSS 2.0 feed at
      • Your feed needs to be in the proper XML format, obviously.
      • You have to encode your feed elements. For example, you can’t say <a href>, you have to say <a href>. There’s something called CDATA that makes this relatively straightforward if your web development language of choice doesn’t have escape functions, and you don’t feel like writing your own.
      • Your RSS links can’t be relative - /index.html should be replaced with
  5. The site should have a favicon. Use the favicon generator to get one from a regular image.
    • You should include a <link rel="shortcut icon" href="/favicon.ico" /> in your <head> section to make sure this gets used. Some browsers (like Chrome) don’t seem to need it, but it’s better to be safe if you want people to see your nifty icon.
  6. You should be licensing your content. See creative commons for more details and a license-link generator.
  7. You should be compressing your content. See this article.
    • If you’re using PHP, I’d recommend doing both the PHP compression and the Apache compression. Apache compression doesn’t seem to catch PHP files that serve HTML content. I’m guessing this is the same for other web scripting languages, but I’ll admit my expertise in this area is limited.
  8. You should have clean URL syntax. Try to avoid URLS like Instead, go for Search engines love it, humans love it, everybody is happy.
  9. You should probably have a page search. You can redirect to a google search_term query at the very least.
    • Bonus points if your search returns with highlighting. This might not be applicable, depending on how your search page returns results.