How To Check the Quality of Your Web Site Code
Web developers can be a cocky bunch. Sometimes it's hard to tell if you're dealing with people who actually know what they're talking about, or if they've just memorized a bunch of acronyms and buzzwords. While the developers are throwing around terms like "Web 2 point 0," "AJAX" and "social marketing," you just sit there nodding with a smile on your face, secretly fantasizing about snapping their scrawny necks.
But they've got you in a vulnerable position. Most people certainly can't build a high quality Web site themselves. While they're alone at home debating whether Opera is superior to Firefox in a forum, you've actually got a life. However, even though you'd love to smack them back to the basement they call home, you pretty much have to bite your tongue and hope they're as good as they say they are.
Well, here are some insider tools and tips that can help level the playing field. None of these are foolproof and this list is by no means comprehensive, but the items I have listed below can provide a more objective way of checking the quality of your own Web site code or checking up on the portfolio of someone you intend to hire.
Web Site HTML Validator: http://validator.w3.org
This tool can tell you about the quality control practices of a Web developer. One at a time, type a couple of the key Web pages on your site into the validator and it will display the number of HTML errors on that page. Now, before you panic, it's important to keep this number in perspective. Due to the nature of HTML, an error at the beginning of the page will often appear as dozens of errors, just like when you make a mathematical error at the beginning of a problem it affects later calculations. So, often you can fix multiple errors with a single change.
It's also important to know what these errors are. They don't necessarily mean that the Web site is broken. In fact, you generally will find some errors even on successful Web sites (CNN has 37 errors on their home page, for example). What it DOES tell you, especially for smaller Web sites, is that the developer didn't validate his or her work and write code to meet the industry standards.
Because this happens so often, most browsers try to "guess" what the Web developer meant, effectively fixing these errors. However, just because some browsers are able to fix these errors doesn't mean that it's OK to make them.
Google Site Search: www.google.com
It's important that your pages be built in a way that maximizes your search engine click-throughs. One simple test is to check how well your site is being indexed and how the pages show up in Google. To do this, search Google using two special keywords: "site" and "inurl." Using these keywords you can show every page that Google has indexed. For example, the full search to test our own site at Villing.com would be "site:villing.com inurl:villing.com". Simply replace villing.com with the Web site you are testing.
You are looking for three things:
- Does each page have a unique title that effectively describes what's on that page?
- Is the description under the link relevant and informative?
- Are all your pages showing up appropriately or are some missing?
The worst thing you can see when you do a search like that is dozens of links that all look identical. How is a visitor supposed to know what is on that page? This is another quick way to test if Web developers are paying attention to the details, or if they are just throwing sites together as quickly and cheaply as possible.
Check for Outdated Coding Methods:
The link above is not a new page; it is a JavaScript-based tool that you can add to your bookmarks in order to check out what's "under the hood" on any Web site. All you need to do is right-click on the link and add it to your favorites. Internet Explorer (IE) might give you a warning, but just ignore that (IE's just timid after years of being pummeled by viruses).
Now, just browse to any site that you want to test and click that favorite. Clicking this tool will remove the stylesheets from the page, letting you see a much more simplified, one-column version of the page, something that looks like a Word document.
Or at least that's what SHOULD happen.
Sites built using outdated coding practices won't change as much as modern sites. Basically, there shouldn't be anything left on the page except for page CONTENT and the images that reinforce the content. None of the following should still appear:
- Multiple columns: all the text and graphics should be in one column
- Custom fonts or text colors: all the text should be black Times (links should be blue or purple)
- Background colors: the page background should be white
- Template graphics: little rounded corner images shouldn't be scattered around the page
- Sliced images: images shouldn't be broken up into multiple pieces
- Keyword spam: if there are "hidden" keywords or obvious Google-baiting text on their site, run away as fast as you can
I want to reiterate that you should use each of these tools with a little bit of common sense. You'll probably want to run all three tests to get a feel for a trend. If you have access to multiple sites from the same developer, it's a good idea to test a few of them. Also, remember that many Web sites are not maintained by the original developer and may include user-generated content such as comments. While quality developers should anticipate this and plan accordingly, sometimes these errors are out of their control. And finally, these insights don't replace the need for good professional chemistry and quality service, so these tools shouldn't be the only thing one considers when evaluating specific Web sites.
In next month's Tech Tip, I'll explain what to look for when you are hiring a Web developer, either an in-house Web manager, outside agency or independent contractor. I encourage you to subscribe to our RSS feed. If you're interested in these topics, it's a good way to be sure you're alerted to the latest installment.
To get our latest articles when they are posted, please subscribe by e-mail or RSS.
