Checklist for Making Friendly Web Pages
When I wrote the code for donaldmerand.com, 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?
crickets...
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
- 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 regulartext/htmlMIME-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
- Don’t bother with a <!DOCTYPE> of anything XHTML unless you’re actually going to modify your headers to send a MIME type of
- If you’re going with HTML5, you might want to check for browser compatibility eg. with modernizr.
- 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.
- 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 https://yoursite.com/rss/). - 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.htmlshould be replaced withhttps://yoursite.com/index.html.
- Though it’s technically optional, you should include a
- Your RSS feed should be validated by a RSS Validator
- 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.
- You should include a
- You should be licensing your content. See creative commons for more details and a license-link generator.
- 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.
- You should have clean URL syntax. Try to avoid URLS like
https://mysite.com?somequery=value&some_other_query=some_othervalue. Instead, go forhttp://mysite.com/somequery/value. Search engines love it, humans love it, everybody is happy.- This site gives a good overwiew of the RESTful URL situation, and provides good guidelines on URL management.
- ..and unless you’re using a framework like rails, you’ll probably want to brush up on this .htaccess primer, because you’ll need to know it to make your own custom URLs by hand. You can also learn other neat tricks, like banning specific user agents or preventing hot-linking.
- You should probably have a page search. You can redirect to a google
search_term site:yoursite.comquery 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.