<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Chris Stead &#187; SEO</title>
	<atom:link href="http://www.chrisstead.com/archives/category/seo/feed" rel="self" type="application/rss+xml" />
	<link>http://www.chrisstead.com</link>
	<description>Web, the Universe and everything</description>
	<lastBuildDate>Fri, 23 Mar 2012 18:56:43 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
		<item>
		<title>When SEO Goes Bad</title>
		<link>http://www.chrisstead.com/archives/329</link>
		<comments>http://www.chrisstead.com/archives/329#comments</comments>
		<pubDate>Tue, 06 Jul 2010 21:22:01 +0000</pubDate>
		<dc:creator>Chris</dc:creator>
				<category><![CDATA[Internet Culture]]></category>
		<category><![CDATA[SEO]]></category>
		<category><![CDATA[Site Architecture]]></category>
		<category><![CDATA[User Experience]]></category>
		<category><![CDATA[World Wide Weird]]></category>

		<guid isPermaLink="false">http://www.chrisstead.com/?p=329</guid>
		<description><![CDATA[My last post was about finding a healthy balance between client- and server-side technology. My friend sent me a link to an article about SEO and Google&#8217;s &#8220;reasonable surfer&#8221; patent. Though the information regarding Google&#8217;s methods for identifying and appropriately assessing useful links on a site was interesting, I am quite concerned about what the [...]]]></description>
			<content:encoded><![CDATA[<p>My last post was about finding a healthy balance between client- and server-side technology.  <a href="http://www.designbycandlelight.com/" target="_blank">My friend</a> sent me a link to an article about <a href="http://searchengineland.com/seo-implications-of-googles-reasonable-surfer-patent-44222" target="_blank">SEO and Google&#8217;s &#8220;reasonable surfer&#8221; patent</a>.  Though the information regarding Google&#8217;s methods for identifying and appropriately assessing useful links on a site was interesting, I am quite concerned about what the SEO crowd was encouraging because of this new revelation.</p>
<p>It is important to consider search engines during the site building process, however I feel the SEO guys often get carried away.  In this article it is suggested that you de-emphasize navigation and forget footers along with lots of other questionable advice.</p>
<p>These two suggestions alone are enough for me to consider this article, at best, a crackpot spouting extremist ideas.  SEO experts often seem to forget a very important element on the web: the user.<span id="more-329"></span></p>
<p>Something designers are told and people are wise to heed is, pretty things work better.  Do they ACTUALLY work better in some sort of quantifiable way? Probably not, but that doesn&#8217;t matter to the user.  If a site is attractive and seems easy to use, the user is more likely to invest the time to learn how it works.</p>
<p>User experience people know that navigation is key to moving a user through the site.  Let&#8217;s take, for example, Amazon.  They are a top-rated site for Google searches.  Have they gone and done away with navigation? No. Why? They know users rely on navigation to move through the site.  Moreover, their designers know that pretty navigation works.</p>
<p>While the SEO nuts will scream &#8220;de-emphasize navigation,&#8221; Amazon bucks the &#8220;trend&#8221; and keeps on doing what they know works best for making money: directing users.</p>
<p>Regarding forgetting about footers, if anyone in the SEO world ever thought footers were there for search engines, they are fooling themselves.  Footers are only ever implemented for the user.  Information which a small group of users may want is typically stored in the footer.  This kind of information is stuff like license numbers, contact information and other legal odds and ends.</p>
<p>Other common footer items include convenience links, brief site navigation and polish elements which finish out a site.  Footers, especially those of the fat variety, were never intended to be SEO tools.  They are for the user.</p>
<p>If an SEO guru were to design a site, it would probably be a huge mass of text with a few peppered images, some meta information at the top, a link which says &#8220;home&#8221; and the required legal information at the bottom in a big, unattractive text block.</p>
<p>Though a page like this would garner a couple of extra points from search engines for being easy to parse, it would lose mega points for being completely useless to a user.  The more useless your site is, the fewer users will return. The fewer return visitors you have, the lower your site rank will be.  Ultimately, you will win the battle and lose the war.</p>
<p>Moreover, what is really making the money, the search engine or your product?  Trust me, if you have a product everyone wants, the search engines will bump you up the list even if your SEO stinks.  On the other hand, if your SEO is top-notch, but your site fails to deliver conversions you may as well pack it in now.</p>
<p>Finally, something I never seem to hear SEO people talk about which should be absolutely top of their list is the semantic web.  The semantic web can be horribly complex which seems a little daunting, but it doesn&#8217;t have to be.  Simply remember to use the right tags at the right time and you&#8217;ll be on your way to better SEO without all of the extraneous pain involved in new metadata information embedded in your pages.</p>
<p>Remember to do things like break your pages up into headers, divisions, paragraphs, lists and tables.  If you want to get really fancy, add definition lists.  This will score big points with the search engines and it will also score big with your audience.  The more you can divide your information into digestible chunks and then style with CSS, the happier everyone will be.  Users will be able to quickly skim the page in search of what they are there for and the search engines will be able to parse your pages better, potentially leading to better overall ranking.</p>
<p>In the end it is best to build your pages the right way: semantic tagging, strong user focus and dense metadata components.  There are many SEO techniques which work better for both search engines and users.  Forget about completely re-building your page just to impress the Google spider, because you won&#8217;t.  Think about the user, build a compelling site, mark it up correctly and make the web a better place.</p>
<p>&copy;2012 <a href="http://www.chrisstead.com">Chris Stead</a>. All Rights Reserved.</p>.]]></content:encoded>
			<wfw:commentRss>http://www.chrisstead.com/archives/329/feed</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>Balance is Everything</title>
		<link>http://www.chrisstead.com/archives/321</link>
		<comments>http://www.chrisstead.com/archives/321#comments</comments>
		<pubDate>Tue, 01 Jun 2010 17:55:57 +0000</pubDate>
		<dc:creator>Chris</dc:creator>
				<category><![CDATA[HTML]]></category>
		<category><![CDATA[Javascript]]></category>
		<category><![CDATA[PHP]]></category>
		<category><![CDATA[SEO]]></category>
		<category><![CDATA[Site Architecture]]></category>
		<category><![CDATA[User Experience]]></category>

		<guid isPermaLink="false">http://www.chrisstead.com/?p=321</guid>
		<description><![CDATA[Earlier this year I discussed progressive enhancement, and proposed that a web site should perform the core functions without any frills. Last night I had a discussion with a friend, regarding this very same topic. It came to light that it wasn&#8217;t clear where the boundaries should be drawn. Interaction needs to be a blend [...]]]></description>
			<content:encoded><![CDATA[<p>Earlier this year I discussed <a href="http://www.chrisstead.com/archives/226" target="_blank">progressive enhancement</a>, and proposed that a web site should perform the core functions without any frills.  Last night I had a discussion with a friend, regarding this very same topic.  It came to light that it wasn&#8217;t clear where the boundaries should be drawn.  Interaction needs to be a blend of server- and client-side technologies.</p>
<p>Ultimately, it is rarely clear where boundaries are in a project.  What is too much, what is too little?  Somewhere between too much and too little is just right, much like what Goldilocks wanted in her porridge.  We know that even the most limited of users should be able to access our sites within certain considerations.  A photo gallery is, ultimately, little use to a blind person, but alt tags should still be in place.  Sound clips of the Boston Philharmonic Orchestra would be useless to a deaf person, though a caption or indication as to what each sound clip is would be quite handy.</p>
<p>Coming back to the point, finding a balance point is critical to providing rich, meaningful interaction between your user and your site.  Perhaps the first question which should be answered is &#8220;can this be done without Technology X?&#8221;<span id="more-321"></span></p>
<p>Technology X is always the hot technology everyone is dying to use.  Flash, AJAX, CSS3, these all have fallen under the Technology X heading at one point or another.  By using Technology X as your baseline interaction, you may be causing your users pain when you thought you were enhancing their experience.</p>
<p>A prime example of where Technology X is used when standard interaction would do is the Google login procedure.  Many, if not all, of Google&#8217;s login boxes use AJAX for verification of user creds.  It sounds cute and looks vaguely neat, but what happens when the browser barfs on their Javascript or you suddenly lose your internet connection?  You have no clue what happened.</p>
<p>Your experience just took a nose dive and left you in the dark.</p>
<p>This is especially bad news for something like a login.  Logging into a website should be a simple, straightforward, FAST experience.  I want to type my creds, log in and be on my way to my dashboard.  If something dies unexpectedly, I want a clean, clear indication as to what happened and why.  If someone cut my ethernet cable in the next room, I want to know my computer lost network connectivity and that&#8217;s why I&#8217;m not seeing my dashboard in all its glory.</p>
<p>CSS is another item which can choke on users, leaving them feeling lost and confused.  When things are hidden or altered with CSS in a way that makes them unreadable or unusable to the user, it can get ugly.  The user sees a damaged site and moves along.  Your rep falls to pieces and your user has moved on to greener pastures.  This is especially true for people using Javascript to reveal something hidden with CSS.</p>
<p>The phrase &#8220;if it is to be shown with Javascript, hide it with Javascript,&#8221; carries a lot of weight with me.  If your Javascript is going to die, it would be preferable that you err on the side of caution.  Show everything.  Make sure the page is as usable as possible.</p>
<p>So, the balancing act.  I&#8217;m not saying there is no room for Technology X.  The Technology X of today is the old standby of tomorrow.  People will become familiar with new technology and learn to expect it.  In the meanwhile it is important to consider what your user is aiming to do.</p>
<p>As a friend of mine likes to quote: Proper prior planning prevents piss poor performance.  Know what it is your user is trying to accomplish by using your site.  If they are there to purchase widgets, build a no-frills site which sells widgets.  Use styles only to make the page more readable.  Make sure everything makes sense without styles.  Don&#8217;t use Javascript to do anything.  Let the server do all the grunt work.</p>
<p>If you plan your site carefully and build something which is clear, usable and meaningful, adding Technology X will only make the site better.  If something fails, your user will still be able to interact with the site and get things done.  It may take them an extra click here or there, but it won&#8217;t be the show stopper it would have been if Technology X had been your only approach.</p>
<p>Balance is everything.  Balance your plain site with your desire to incorporate interesting new technology.  Just because it might be neat to see something done with AJAX doesn&#8217;t mean you should.  Flash doesn&#8217;t solve all world ills.  Sometimes a little bit of HTML a dash of simple CSS and some server-side elbow grease will do just fine.  Build your sites for real use.  Make your toys secondary.  Think about your users&#8217; goals and make the web a better place.</p>
<p>&copy;2012 <a href="http://www.chrisstead.com">Chris Stead</a>. All Rights Reserved.</p>.]]></content:encoded>
			<wfw:commentRss>http://www.chrisstead.com/archives/321/feed</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>Almost Pretty: URL Rewriting and Guessability</title>
		<link>http://www.chrisstead.com/archives/247</link>
		<comments>http://www.chrisstead.com/archives/247#comments</comments>
		<pubDate>Mon, 29 Mar 2010 08:00:10 +0000</pubDate>
		<dc:creator>Chris</dc:creator>
				<category><![CDATA[ASP.Net]]></category>
		<category><![CDATA[C#]]></category>
		<category><![CDATA[Coding]]></category>
		<category><![CDATA[JSP]]></category>
		<category><![CDATA[PHP]]></category>
		<category><![CDATA[SEO]]></category>
		<category><![CDATA[Site Architecture]]></category>
		<category><![CDATA[User Experience]]></category>

		<guid isPermaLink="false">http://www.chrisstead.com/?p=247</guid>
		<description><![CDATA[Through all of the usability, navigation, design, various user-related laws and a healthy handful of information and hierarchical tricks and skills, something that continues to elude designers and developers is pretty URLs. Mind you, SEO experts would balk at the idea that companies don&#8217;t think about using pretty URLs in order to drive search engine [...]]]></description>
			<content:encoded><![CDATA[<p>Through all of the usability, navigation, design, various user-related laws and a healthy handful of information and hierarchical tricks and skills, something that continues to elude designers and developers is pretty <acronym title="Uniform Resource Locator">URL</acronym>s.  Mind you, SEO experts would balk at the idea that companies don&#8217;t think about using pretty URLs in order to drive search engine placement.  There is something else to consider in the meanwhile:</p>
<p>The user.</p>
<p>Several articles I found talk about the SEO benefits of pretty URLs and whether it is very important to consider using them with a site as they don&#8217;t encourage a major boost anymore. &#8220;It&#8217;s ten years too late,&#8221; they say.  It&#8217;s never too late, I say.<span id="more-247"></span></p>
<p>Rather than bashing SEO experts that cry &#8220;content, content, content&#8221; let&#8217;s look at content and wrap it up in an easy to guess URL the user can make sense of.  <a href="http://findability.org/" target="_blank">Peter Morville argues for findability</a>, meaning users are more likely to use resources which are easy to navigate. Moreover, users will naturally navigate to whatever <a href="http://en.wikipedia.org/wiki/Satisficing" target="_blank">satisfices</a> their information needs.</p>
<p>I wonder why users are forced to satisfice when pretty URLs make it much easier to satisfy by simple guessing.  Unfortunately, something that stands in the way of this guessability is the combination of SEO professionals considering pretty URLs as a lesser sin combined with technologies which stand in the way of smarter URL writing.</p>
<p>Actually, I don&#8217;t necessarily wonder much, at all, why users are forced to satisfice when attempting to find something on a site through URL guessing.  Much of the available technology on the internet is fairly limited when looking at URL rewriting.</p>
<p>When working with PHP, Python, Perl or anything else that works well with Apache, rewriting is easy.  If you are working with Java or anything that runs under IIS, rewriting gets tricky quickly.  Some of the technology which lives under the skin of the web gets a little ugly when you want to start doing pretty things.  We&#8217;ll talk about overcoming these obstacles soon.</p>
<p>See, here&#8217;s the issue.  We really want to do URL rewriting, not maintenance-heavy URL trickery.  I came across <a href="http://www.sitepoint.com/blogs/2009/07/07/pretty-urls-pretty-easy/" target="_blank">an article about creating pretty URLs</a> which claims it is &#8220;pretty easy.&#8221;  Technically it IS easy but the suggested method is to make a directory for every page and have a single index.php or index.html page in the directory.</p>
<p>Using this method is a one-way ticket to sites you&#8217;ll have to manually manage forever.  If you are a maintenance thinker, this is fine.  If you want to solve the problem correctly, once and for all, you&#8217;ll want to do a little URL rewriting, instead.</p>
<p>In case you are new to the idea of URL rewriting, here&#8217;s a quick overview.  When someone arrives at a site using a URL of the following form:</p>
<p><a href="http://www.chrisstead.com/search/url rewriting" target="_blank">http://www.chrisstead.com/search/url rewriting</a></p>
<p>The server captures the URL which was used and then works a little magic, making it look more like the following:</p>
<p><a href="http://www.chrisstead.com/?s=url+rewriting&#038;submit=Search" target="_blank">http://www.chrisstead.com/?s=url+rewriting&#038;submit=Search</a></p>
<p>Which makes the whole URL much MUCH easier to manage and manipulate by, in this example, a PHP script.  There are a couple of different reasons we would want to do this kind of rewriting.  Let&#8217;s take a look at them.</p>
<p>Note: Yes, those both work. Give them a try! </p>
<p>Rewriting hides the underlying technology.  This might sound like a strange thing to want to do, but there is learning in my lunacy.  People interested in compromising your site will use any knowledge they can get to take advantage of common little flaws and loopholes.  By disguising what technology you are using, it sets up a roadblock, making your site less interesting to attack.  This isn&#8217;t really what I wanted to write about, however.</p>
<p>Rewriting makes gives you the opportunity to make your URLs guessable.  If users start to notice a pattern in the way the URLs are structured, they can take advantage of the common themes.  This means it is easy for the user to guess how to get to something they want directly and just type the URL.  This might seem like kind of an obscure goal, but let&#8217;s look at something a little more reasonable.</p>
<p>Suppose you are a music retailer.  If you write scripts to handle URLs like the following, your users might not be particularly keen on trying to guess how to rewrite things to find something else:</p>
<p>http://www.mymusicsite.com/query.aspx?s=records&#038;key=LKIH8hi7iKJbkjykjBJ&#038;artist=some%20artist</p>
<p>This looks a little intimidating to me and I know what I was trying to say.  Let&#8217;s suppose you, then, rewrote URLs instead so what the user sees is this:</p>
<p>http://www.mymusicsite.com/search/some-artist</p>
<p>This looks a lot less intimidating and, better yet, your user knows precisely what happened without even looking at the results you present.  They typed &#8220;some artist&#8221; in the search box, which took them to a search page.  They then know how to type another artist in and get a result.  It would be even better if you capture the URL and replace the spaces with dashes for them, they can just type the artist name in and get what they want.</p>
<p>When the day is done, the SEO work, usability and findability could and SHOULD work together to create a site that is friendly to search engines as well as your users.  That single little string is the first, last and only direct link your user has with the underlying system that drives your website.</p>
<p>**Disclaimer**</p>
<p>If you are a designer reading my blog, you are welcome to stop here.  If you have concerns about URL rewriting, I encourage you to contact me and I&#8217;ll address them.  Take what you have read and make the web a better place.  If you are comfortable programming in a web-friendly language, please read on!</p>
<p>**On with the code!**</p>
<p>That&#8217;s great and all, but this doesn&#8217;t really get us any closer to how you DO any of this rewriting.  There are, of course, barriers which get in the way of making this all happen.  See, if you are writing in PHP then you are probably serving everything with Apache.  This is great since Apache supports URL rewriting directly.  If you have any skill with regular expressions then you can work a little juju and be rewriting by this afternoon.  Your work will start and stop in the .htaccess file.</p>
<p>Common rules will look like the following:</p>
<p>RewriteRule (.*) /command/directory/index.php?$1 [L]</p>
<p>This was totally made up, so I can&#8217;t promise it will work, but this is the basic idea.  Apache URL rewriting is a cryptic art that I have yet to master.  Fortunately, there are many people, much smarter than I, who can advise and direct your work.</p>
<p>Apache is the nice situation, however.  When we look at two languages used on the web, things get tricky really quickly.  The tools for rewriting get few and the machinations become more cumbersome.  I&#8217;ve encountered problems with each of the following.</p>
<p>ASP/ASP.Net runs on <acronym title="Internet Information Server">IIS</acronym> which does not natively support URL rewriting.  If you are interested in writing your own module or paying for something someone else has written for you, I give you my blessing.  However, this may not be an option for you.  Fortunately, you can still write URLs of the form:</p>
<p>http://www.mysite.com/Default.aspx?/my/ugly/url</p>
<p>Sadly, this probably cause more pain than anything else.  Java, through JSP, has much the same problem.  Unless you are running a Tomcat instance, hiding behind an Apache instance where you can rewrite your URLs nicely, your URLS at best will look like this:</p>
<p>http://www.mysite.com/index.jsp?/my/ugly/url</p>
<p>Once you have written your URLs like this, you can get slick and tricky with the code by simply doing the following:</p>
<p><strong>ASP with C# code behind:</strong></p>
<pre class="brush:c-sharp">
String path = Request.QueryString.toString();
</pre>
<p></p>
<p><strong>JSP:</strong></p>
<pre class="brush:java">
String path = request.getQueryString();
</pre>
<p></p>
<p>Now that we have gotten that little piece of ugly out of the way, let&#8217;s look at a solution for that gorilla in the corner.  ASP and Java are typically only used to solve problems in a business environment.  This means your IT department probably has a router and a load balancer sitting between the world and their servers.  Enterprise routers are typically highly configurable, and can do quite a bit of rewriting work for you.</p>
<p>The most difficult part of getting your IT department to rewrite your URLs for you is convincing them it&#8217;s worth the time and effort.  If you can provide them with precisely what you want the end result to be in your efforts, they can probably create the right rules and get everything situated fairly quickly.  Be ready to buy them beer.</p>
<p>In the end, pretty URLs, under the skin, are pretty ugly.  When it comes to getting your user to the site, moving them through your vast amounts of information and converting the visit into a sale or a return, the pain is worth it.  Just think about how much easier life will be for your users once you have taken the time to craft their journey even outside the carefully designed presentation of your website.  Think about URL rewriting and guide your user gently.  Make the web a better place.</p>
<p>&copy;2012 <a href="http://www.chrisstead.com">Chris Stead</a>. All Rights Reserved.</p>.]]></content:encoded>
			<wfw:commentRss>http://www.chrisstead.com/archives/247/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Degrading Behavior: Graceful Integration</title>
		<link>http://www.chrisstead.com/archives/226</link>
		<comments>http://www.chrisstead.com/archives/226#comments</comments>
		<pubDate>Fri, 26 Feb 2010 17:00:26 +0000</pubDate>
		<dc:creator>Chris</dc:creator>
				<category><![CDATA[Coding]]></category>
		<category><![CDATA[CSS]]></category>
		<category><![CDATA[Javascript]]></category>
		<category><![CDATA[SEO]]></category>
		<category><![CDATA[Site Architecture]]></category>
		<category><![CDATA[User Experience]]></category>

		<guid isPermaLink="false">http://www.chrisstead.com/?p=226</guid>
		<description><![CDATA[There has been a lot of talk about graceful degradation. In the end it can become a lot of lip service. Often people talk a good talk, but when the site hits the web, let&#8217;s just say it isn&#8217;t too pretty. Engineers and designers work together, or divided as the case may be, to create [...]]]></description>
			<content:encoded><![CDATA[<p>There has been a lot of talk about graceful degradation.  In the end it can become a lot of lip service.  Often people talk a good talk, but when the site hits the web, let&#8217;s just say it isn&#8217;t too pretty.</p>
<p>Engineers and designers work together, or divided as the case may be, to create an experience that users with all of their faculties and a modern browser can enjoy.  While this goes down, the rest of the world is left feeling a bit chilly.</p>
<p>What happens is, the design starts with the best of intentions and, then, the interactivity bug takes hold.  What comes out is something that is almost usable when slightly degraded, but totally non-functional when degraded to the minimum.<span id="more-226"></span></p>
<p>In the end, of course, the user needs must be considered.  Having a graphically intensive site doesn&#8217;t hurt if you are a design firm, but might not be the best option for a company dealing with medical customers.</p>
<p>My suggestion, however, is simple.  Instead of degrading your site as the user needs become greater, start with a site that is usable at the lowest common denominator and work up.</p>
<p>Understand who your audience is and prepare to serve those of them who have the greatest needs.  Build a site that is attractive and works if the user can only view it through a program that reads for them.</p>
<p>Once your site has been built and is fully functional, build up.  Integrate functions to serve the users that have some needs, but aren&#8217;t in the highest-need area on the spectrum.</p>
<p>Continue on this path until you have integrated all of the latest and greatest, bleeding-edge functions that your highest-ability users can interact with.</p>
<p>As you build this way, be sure that you are simply enhancing the function that is already on the screen.  As you add enhancements, you should be able to remove them cleanly and still get the same experience you started with.</p>
<p>I call this approach graceful integration.  Each progressive step, you integrate more functionality and interaction, preserving the layer just below as a separate user interaction.</p>
<p>Each progressive enhancement should be separate and easily disabled.  The granularity of your enhancements can be as large as a two-step approach: all or nothing.  You may also enhance your site in a careful way that allows for several levels of degradation depending on the user and their distinct needs.</p>
<p>A natural separation of user interaction happens when HTML is written, CSS is added and Javascript acts upon the subsequent design.  This three-tier separation, you can use the work that will be done regardless to define your user interaction in a clean way.</p>
<p>One of the best quotes I&#8217;ve heard regarding graceful degradation, in paraphrase, is, &#8220;if you show it with Javascript, hide it with Javascript.&#8221;  I offer this with no source as I can&#8217;t recall where I heard it.  If you know/are the author of this, stand up and reap the rewards.</p>
<p>The attitude in this quote represents the core of graceful integration.  As you pile the Javascript on, be sure you manage its behavior with Javascript.  Don&#8217;t use CSS to manage something that is going to be handled with Javascript.  If you must, prepare a style sheet that defines scripted behavior, but set the object classes with Javascript.</p>
<p>There are other benefits you&#8217;ll gain from this approach.  Not only will your users appreciate the time and care you put into their experience, so will the search engines.</p>
<p>As search spiders crawl your site, they won&#8217;t see any CSS that looks to be doing something sneaky like hiding text from the viewer.  Spiders have gotten smarter and they recognize when something fishy is going on.  As you are already doing something good for your users, you get this bonus for free.</p>
<p>For those of you looking for snippets of code, the best thing you could know and rely on is the &#8220;noscript&#8221; tag.  This is a tag which defines the behavior of the page for users without Javascript.  I use this quote a bit to display extra form controls when Javascript has been disabled or is unavailable to the user.  You can use it like the following:</p>
<p>&lt;script type=&#8221;text/javascript&#8221;&gt;<br />
     //your script logic goes here<br />
&lt;/script&gt;<br />
&lt;noscript&gt;<br />
&lt;!&#8211; HTML elements go here like style definitions or form controls. &#8211;><br />
&lt;/noscript&gt;</p>
<p>You can also use noscript by itself scattered throughout the page to display page elements that might, otherwise, be missing for some of your users.</p>
<p>In the end, behavior on your site should be defined by the HTML first, the CSS second and the Javascript third.  Should you choose to go to a finer granularity, don&#8217;t forget to double check your users can still use all of the layers effectively.  Be mindful of your users, integrate function into your site in stages and make the web a better place.</p>
<p>&copy;2012 <a href="http://www.chrisstead.com">Chris Stead</a>. All Rights Reserved.</p>.]]></content:encoded>
			<wfw:commentRss>http://www.chrisstead.com/archives/226/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Mapping the Course: XML Sitemaps</title>
		<link>http://www.chrisstead.com/archives/154</link>
		<comments>http://www.chrisstead.com/archives/154#comments</comments>
		<pubDate>Tue, 02 Feb 2010 17:00:14 +0000</pubDate>
		<dc:creator>Chris</dc:creator>
				<category><![CDATA[Internet Culture]]></category>
		<category><![CDATA[SEO]]></category>
		<category><![CDATA[Site Architecture]]></category>
		<category><![CDATA[World Wide Weird]]></category>

		<guid isPermaLink="false">http://www.chrisstead.com/?p=154</guid>
		<description><![CDATA[I just read a short, relatively old blog post by David Naylor regarding why he believes XML sitemaps are bad. People involved with SEO probably know and recognize the name. I know I did. I have to disagree with his premise, but agree with his argument. I say XML sitemaps are good! The real issue [...]]]></description>
			<content:encoded><![CDATA[<p>I just read a short, relatively old blog post by David Naylor regarding why he believes <a href="http://www.davidnaylor.co.uk/why-an-xml-sitemap-is-bad.html" target="_blank">XML sitemaps are bad</a>. People involved with SEO probably know and recognize the name.  I know I did.  I have to disagree with his premise, but agree with his argument.</p>
<p>I say XML sitemaps are good!</p>
<p>The real issue with XML sitemaps does not lay in the technology but the use.  If a site is well designed, well developed and has a strong information architecture, it should spider well and indexing should occur.  Moreover, if the HTML/XHTML supporting the information on the site is well formed, the site should get decent rankings.  This is where I agree with David.<span id="more-154"></span></p>
<p>I disagree on the grounds that there is nothing XML sitemaps do that other SEO best practices won&#8217;t do.  There is one clear item on this docket.  Update frequency.  There is no better tool I know of for announcing update frequency than an XML sitemap.</p>
<p>Within the standard for sitemap generation, update frequency can be denoted.  By setting the update frequency appropriately, the spider will have an indicator to how often it should visit.  This is really important in assuring that a spider will revisit your site and pick up new pages regularly, especially for new sites.  Established sites may not suffer from the same kind of crawl frequency, but even there, it is good practice to make things as easy for the search spider as possible.</p>
<p>While we are on the topic of unique features, XML sitemaps also offer an opportunity to reinforce your navigation hierarchy.  Page priority can be specified, giving the search engine an early indicator to what will be found in the site.  Search spiders dislike hunting through site links to discern information for which they could, otherwise, have a pre-set baseline.</p>
<p>It should be stated that XML sitemaps, when held isolated, do not cure all ills.  They are merely one more tool in the locker that allows a site to grow and benefit from good search ranking.  When sitemaps are coupled with strong content, good code, description tags, thoughtful information architecture and careful navigation, they can only be a boon to your site.</p>
<p>When used correctly, an XML sitemap will drive search spiders to key pages faster and ensure early indexing of the entire site.  Once this initial indexing is managed, it is up to the people who maintain the site to ensure that the path is clear to access information across the site.</p>
<p>Ultimately, David does not argue against sitemaps but, instead, chooses an easy target like poor navigation and concludes that because there are users that don&#8217;t use a sitemap properly, the technology must be bad.  This is disappointing as it seems to lead potential SEO professionals astray.  XML sitemaps are your friends and when treated with the kindness and care a friend deserves, they will only be a boon to your site.  Build your site well, use sitemaps intelligently and make the web a better place.</p>
<p>&copy;2012 <a href="http://www.chrisstead.com">Chris Stead</a>. All Rights Reserved.</p>.]]></content:encoded>
			<wfw:commentRss>http://www.chrisstead.com/archives/154/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Party in the Front, Business in the Back</title>
		<link>http://www.chrisstead.com/archives/94</link>
		<comments>http://www.chrisstead.com/archives/94#comments</comments>
		<pubDate>Thu, 14 Jan 2010 17:00:55 +0000</pubDate>
		<dc:creator>Chris</dc:creator>
				<category><![CDATA[Coding]]></category>
		<category><![CDATA[SEO]]></category>
		<category><![CDATA[Site Architecture]]></category>
		<category><![CDATA[User Experience]]></category>

		<guid isPermaLink="false">http://www.chrisstead.com/?p=94</guid>
		<description><![CDATA[Nothing like a nod to the reverse mullet to start a post out right. As I started making notes on a post about findability, something occurred to me. Though it should seem obvious, truly separating presentation from business logic is key in ensuring usability and ease of maintenance. Several benefits can be gained with the [...]]]></description>
			<content:encoded><![CDATA[<p>Nothing like a nod to the reverse mullet to start a post out right.  As I started making notes on a post about findability, something occurred to me.  Though it should seem obvious, truly separating presentation from business logic is key in ensuring usability and ease of maintenance.  Several benefits can be gained with the separation of business and presentation logic including wiring for a strong site architecture, solid, clear HTML with minimal outside code interfering and the ability to integrate a smart, smooth user experience without concern of breaking the business logic that drives it.</p>
<p>The benefit that engineers will appreciate is the ease of maintainability.  With business logic abstracted from the presenation, engineers can maintain the infrastructure without worrying about breaking the look and feel of the client experience.  This alleviates stress and sleepless nights they might experience otherwise.<span id="more-94"></span></p>
<p>I just finished building the beta version of a Content Managment System for the company I am with.  I built a multi-layer system including two distinct uses of the Model-View-Controller design pattern.  The first instance was the underlying system that actually maintained the content, page information, taxonomy, hierarchy and page templates.  The second was more abstracted from the classic MVC pattern.</p>
<p>The CMS control interface, in my abstract version, is the model.  The API is the controller and it handles requests for display data, stores input from.  Finally, a very lightweight templating system is the view.  The templating system is actually built to act as a fully functional site on its own, built around a business logic/presentation theme.  The entire site can run on a separate machine from the CMS or API.</p>
<p>The benefit to all of this is releasing the presentation which the user interacts with from the confines of business logic which can slow a site down and muddy the response of an interactive system.  Flexibility is the path to enlightenment.</p>
<p>With the presentation decoupled, it offers a unique opportunity to concern myself only with what the user will interact with.  With some creative CSS and good, solid HTML I can build an experience my users will look forward to.  Also, with a lighter template to render, the site response should be snappier, leaving the user free to concern themselves with what they came for, content.</p>
<p>Because much of the template is pure HTML, the task of search engine optimization becomes trivial.  The HTML validates better and the content hierarchy is easier to develop.  This means search engines will be more likely to get a clear picture of what the site is like and how the content interrelates.</p>
<p>The benefit of keeping the business logic tucked away behind an API is, regardless of how it changes or functions, the user will have a seamless, predictable experience.  This builds trust between the user and your organization, which increases the liklihood they will stay longer and visit again.</p>
<p>Finally, all of this positive user experience would not be possible without a solid design.  Since the business logic does not interact or interfere with the design, the designer is empowered to make bold moves and guide the user through the site in a way that might not have been possible if user interface were tightly coupled with the code that drives it.</p>
<p>In the end, decoupling the business logic from the presentation allows us to move back to a simpler time when the web was primarily HTML, except you&#8217;ve got more than just bronze-age tools to build with.  With increased usability, maintenance and findability, your site will feel more like a smooth, clean experience and less like a clunky tool straight out of the mid-ninties.  Presentation decoupling makes for happy users and everyone wants happy users.  Go make the web a better place.</p>
<p>&copy;2012 <a href="http://www.chrisstead.com">Chris Stead</a>. All Rights Reserved.</p>.]]></content:encoded>
			<wfw:commentRss>http://www.chrisstead.com/archives/94/feed</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>The Selection Correction</title>
		<link>http://www.chrisstead.com/archives/87</link>
		<comments>http://www.chrisstead.com/archives/87#comments</comments>
		<pubDate>Tue, 12 Jan 2010 00:21:38 +0000</pubDate>
		<dc:creator>Chris</dc:creator>
				<category><![CDATA[SEO]]></category>
		<category><![CDATA[Site Architecture]]></category>
		<category><![CDATA[User Experience]]></category>

		<guid isPermaLink="false">http://www.chrisstead.com/?p=87</guid>
		<description><![CDATA[User self selection is a mess. Let&#8217;s get that out in the open first and foremost. As soon as you ask the user questions about themselves directly, your plan has failed. User self selection, at best, is a mess of splash pages and strange buttons. The web has become a smarter place where designers and [...]]]></description>
			<content:encoded><![CDATA[<p>User self selection is a mess.  Let&#8217;s get that out in the open first and foremost.  As soon as you ask the user questions about themselves directly, your plan has failed.  User self selection, at best, is a mess of splash pages and strange buttons.  The web has become a smarter place where designers and developers should be able to glean the information they need about the user without asking the user directly.</p>
<p>The innate problem with asking the user about what they want is, they will invariably give you the wrong answer.  Sometimes it happens because they don&#8217;t know what they want.  Sometimes they don&#8217;t care.  Sometimes they misunderstand what you really want to know and sometimes they flat out lie to see what happens.</p>
<p>The question has hit my desk a few times now, &#8220;how does the user self-select in a nice, fluid manner?&#8221;  The answer: they don&#8217;t.<span id="more-87"></span></p>
<p>It occurred to me, while pondering this question, that it wasn&#8217;t the answer that was a problem.  It was the question.  I don&#8217;t want to know how the user self-selects. I want to know how I am to select the user.  The question is flawed.</p>
<p>The first thing I did, once I awoke from the haze and saw the truth for what it was, I reformulated the question.  How do I select the user before they get to the site?</p>
<p>It sounds like I am preparing for a life of mind reading.  No computer will tell you much, if anything about your user.  Do they like cats or do they like laser blasters?  The computer neither knows, nor cares.  All you get is an IP address, an operating system and browser info.</p>
<p>So, how would one approach the user selection issue?  Is it a design concern or a development concern?  Yes.</p>
<p>The developer can say a lot about the computer the user is using, the place they came from to get to your site and where they landed on your site.  The designer can pick up the stragglers and put them on the path to user experience redemption.</p>
<p>First the developer must work their magic.  Given where the user came from and what page they landed on, the developer can make predictions about what they are going to want to do next.  These predictions are essential to handling the user experience moving forward.</p>
<p>If you have more than one type of user coming to your site, it is helpful to understand what they did to arrive.  If they typed in the address manually, or clicked on a link in their e-mail, the resulting behavior is almost certain.  They are there for a purpose and it would be wise to get out of their way.</p>
<p>If, on the other hand, the user arrived via search, the search terms will probably be in the referrer URL that is passed along with the GET request. If this is too much tech speak, think of it this way: the browser tells you what they searched for and you can use that to guide your user.</p>
<p>Any other in-bound links will tell you the user is interested in the page they clicked through to.  This is especially true if they were not mislead to believe the page is something it&#8217;s not.  Your SEO skills would come in handy for that little task.  If you know the user is interested in a particular product or area, you can use that for opportunities to cross- or up-sell.</p>
<p>Once the user it on your site, the battle is half over, or only half over, depending on your outlook.  Since you know something about your user, you can guide them.  If, on the other hand, the user arrives mistakenly, on the wrong page, they need to find a way to get out of their mess.</p>
<p>This is where design and client-side architecture come into play.  Users typically behave in a click, back, click, back manner.  They click a link then, if it is not what they wanted, they click the back button.  It is your job, O noble chess player, to stave off that back-click at the expense of life and limb.</p>
<p>Make it easy to find the way to the right place on the site.  &#8220;Is this not what you wanted? Why not try this?&#8221;  It&#8217;s a fantastic way to lead the user where you want them to go.  Make their journey one that ends at Mecca.</p>
<p>There are two wonderful side-effects of pre-selecting your user and their journey.  The first is you can streamline the architecture of your site to match precise needs and exclude the train wreck &#8220;features&#8221; that balloon into eventual site clutter.  Secondly, you can spend more time solving the problem of how to handle the edge-case users, leaving the straight-and-narrow users alone to complete their journey as effortlessly as they please.</p>
<p>In the end, the question of how a user self-selects should undergo great scrutiny before it is passed off as a primary goal of the site development process.  Think carefully and consider, not only the visual elements of the site, but the outside influences that make up the ecosystem you are about to interact with.  Consider your user before building the site.  Your users will thank you for it.</p>
<p>&copy;2012 <a href="http://www.chrisstead.com">Chris Stead</a>. All Rights Reserved.</p>.]]></content:encoded>
			<wfw:commentRss>http://www.chrisstead.com/archives/87/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Well, Now, Isn&#8217;t that Flashy?</title>
		<link>http://www.chrisstead.com/archives/57</link>
		<comments>http://www.chrisstead.com/archives/57#comments</comments>
		<pubDate>Thu, 07 Jan 2010 22:40:51 +0000</pubDate>
		<dc:creator>Chris</dc:creator>
				<category><![CDATA[SEO]]></category>
		<category><![CDATA[Site Architecture]]></category>
		<category><![CDATA[User Experience]]></category>
		<category><![CDATA[World Wide Weird]]></category>

		<guid isPermaLink="false">http://www.chrisstead.com/?p=57</guid>
		<description><![CDATA[I make no secret of the fact that i&#8217;m not a huge fan of Flash.  It&#8217;s not really because I feel there is anything inherently wrong with Flash.  I am opposed to the gross overuse and misuse that happens every day.  Sometimes only Flash will do, and in those circumstances it is the answer.  Sometimes [...]]]></description>
			<content:encoded><![CDATA[<p>I make no secret of the fact that i&#8217;m not a huge fan of Flash.  It&#8217;s not really because I feel there is anything inherently wrong with Flash.  I am opposed to the gross overuse and misuse that happens every day.  Sometimes only Flash will do, and in those circumstances it is the answer.  Sometimes Flash is the answer to a question that is totally incorrect.</p>
<p>When someone proposes making a website, I immediately start asking questions of scope, regularity of updates, audience, intent and so-on.  Typically I don&#8217;t ever ask what technology the client is interested in using.  When it comes down to brass tacks, I&#8217;m typically uninterested in the technology the client wants because the user is the important piece of the puzzle, so the tech that fits is the tech that gets used.  I can only imagine what goes through the minds of people before building a website that is run only with Flash.</p>
<p>&#8220;Hey Joe, what do you think of building a site using only Flash?&#8221;</p>
<p>&#8220;Cool idea! How do you think users should interact with it?&#8221;</p>
<p>&#8220;I hadn&#8217;t really thought about it. I just think it would be neat to have an all Flash site.&#8221;</p>
<p>&#8220;Let&#8217;s do it.&#8221;<span id="more-57"></span></p>
<p>This conversation may be out of touch, but this is how I feel any time I find myself looking down the barrel of an all Flash site.  It simply feels like people were putting tech before the user.  Flash is a great tool, but it seems to thwart some of the elements of the web I consider to be key.</p>
<p>Before I go further, let&#8217;s agree to use a naming convention so I don&#8217;t have to keep typing things out over and over. I&#8217;m going to refer to an all Flash site as an AFS.  Please be aware of this.</p>
<h4>Now, That&#8217;s Degrading</h4>
<p>An excellent <acronym title="All Flash Site">AFS</acronym> will have been built to degrade gracefully, allowing for access by disabled users.  The content will be repeated in an <acronym title="HyperText Markup Language">HTML</acronym> format which can easily be read to the blind or accessed through a disability-geared browser.  I have seen sites like this and I applaud their effort to keep accessibility in mind.</p>
<p>Many of the AFS examples I have seen do not degrade so beautifully. Some just show a broken plugin indicator.  Others test for flash on a system, then display a message stating, &#8220;this site requires flash.&#8221;  The worst test for flash, and if it is not installed, they display the main menu, without links and without content, as if to say, &#8220;this is everything you could have if you weren&#8217;t such a luddite.&#8221;</p>
<p>Users really dislike being told they are bad because they aren&#8217;t like you.</p>
<h4>Trafficking Issues</h4>
<p>Unfortunately, even if an AFS is designed to degrade wonderfully, the content for the site is locked away in a Flash file which causes undue strain on the user.  Suppose, for instance, an AFS has a really incredible article about a relevant topic.  Since the site is built into a Flash file, the user cannot pass the article along to other potential readers.  This means the site is losing potential traffic.  Lost traffic is always a good indicator of bad design and development.</p>
<h4>Johnny 5 Requires Input</h4>
<p>Marketing teams should always be against an AFS on principle alone. If a user visits the site and spends a large amount of time in one section, how is anyone to know?  I am unaware of any analytics tool that will track this, as all of the tools I&#8217;ve used rely on a standard HTML site.  This lack of site analytics should elicit horrified reactions from your marketing team instantly.  A complete lack of marketing feedback is always a little frightening.</p>
<h4>What Search Engines?</h4>
<p>Even the best AFS leaves something to be desired in <acronym title="Search Engine Optimization">SEO</acronym>.  Supposing your site degrades perfectly and any Flash-disabled browser hits your site, the content is on the ready in plain text and markup, you are still committing an SEO faux pas called cloaking. In simple terms, cloaking is when you display different content for the search engine than what is provided to the real user.</p>
<p>Understandably, the argument would be made that the content is identical to what is in the Flash file.  It isn&#8217;t.  The look is different and there are pages which can only be accessed if Flash is disabled, while, if Flash is enabled, you have to navigate within just a single page.  What this translates to is, you are lying to the search engine.  You are saying there is content directly accessible on your site which, in reality, is not.</p>
<p>Google doesn&#8217;t look kindly upon this and has banned websites doing legitimate cloaking in the past.  What makes you think you are any different or better?</p>
<p>Now, supposing you don&#8217;t have all of the degrading features we love so well? In plain terms, you don&#8217;t exist to the search engines at all.  Your site comes up on Google or Yahoo and the description is, &#8220;sorry, you must have flash to view this site.&#8221;</p>
<p>When I see that in any search result, I skip it immediately.  Fortunately, since you have chosen the path of Darwinian self-selection, I never come across that message since I don&#8217;t look for that phrase.</p>
<h4>Up-shot</h4>
<p>I am certain I haven&#8217;t covered all of the evils that ride on the coattails of an AFS, but I believe these few are a strong enough case on their own.  In the end, if you opt for an AFS for your company, be prepared for many difficulties, which will, undoubtedly, outweigh the benefits you gain by having a pretty transition from one page to another.</p>
<p>Please, keep the web a beautiful and accessible place.</p>
<p>&copy;2012 <a href="http://www.chrisstead.com">Chris Stead</a>. All Rights Reserved.</p>.]]></content:encoded>
			<wfw:commentRss>http://www.chrisstead.com/archives/57/feed</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>It&#8217;s Called SEO and You Should Try Some</title>
		<link>http://www.chrisstead.com/archives/26</link>
		<comments>http://www.chrisstead.com/archives/26#comments</comments>
		<pubDate>Thu, 19 Nov 2009 00:02:19 +0000</pubDate>
		<dc:creator>Chris</dc:creator>
				<category><![CDATA[SEO]]></category>

		<guid isPermaLink="false">http://www.chrisstead.com/?p=26</guid>
		<description><![CDATA[It&#8217;s been a while since I last posted, but this bears note. Search engine optimization, commonly called SEO, is all about getting search engines to notice you and people to come to your site. The important thing about good SEO is that it will do more than simply get eyes on your site, but it [...]]]></description>
			<content:encoded><![CDATA[<p>It&#8217;s been a while since I last posted, but this bears note. Search engine optimization, commonly called SEO, is all about getting search engines to notice you and people to come to your site. The important thing about good SEO is that it will do more than simply get eyes on your site, but it will get the RIGHT eyes on your site. People typically misunderstand the value of optimizing their site or they think that it will radically alter the layout, message or other core elements they hold dear.</p>
<p>First, what SEO isn&#8217;t. I think it&#8217;s best to get this out of the way early so we can get into helping you do good stuff without a bunch of &#8220;but-but-buts.&#8221; So, SEO isn&#8217;t cramming a bunch of keywords into the bottom of your page. It also isn&#8217;t redesigning your entire site so it looks like garbage but Google can read it like a dream. SEO is not putting your site on every link farm in the world and it is not spamming people on social networking sites. SEO is also not spamming people on message boards. SEO is not about fads and fast grabs. It&#8217;s not about people coming to your site and then bouncing immediately. SEO isn&#8217;t about a bad web experience, plain and simple.<span id="more-26"></span></p>
<p>Now let&#8217;s look at what SEO is. SEO is about strategic placement of key concepts in your web site to encourage traffic that will be interested in your message, product or service. SEO is about making the best of what you have to offer and making your web presence work for you. SEO is about traffic analysis and evolution. SEO is about marketing in a smart way and encouraging your customers to think of you first. SEO is about becoming an industry leader and a recognized authority.</p>
<p>I don&#8217;t believe in mincing words or trying to sneak around and do back-room deals to become another SEO douchebag, so I felt it was only right to lay that all on the line first and foremost. Now that we have a picture of what SEO is and is not, we can benefit from looking at ways to improve your site today and give you tools to improve your site more over time.</p>
<h4>Keywords</h4>
<p>Keywords are important for any search. Regardless of the way that the searching is done, eventually it comes down to what the customer is searching for and keywords are precisely this in a crystalline structure.</p>
<p>The thing to know about keywords is they are meant to be a focus. If you are planning on making a page about anything, it would behoove you to understand the essential idea you are trying to convey. Once you have this in mind, write down three to seven keywords. Use these as a guidepost and they will keep you on target. Moreover, if you are on target and your keywords were selected properly, they will appear naturally in the text. This is good. Don&#8217;t try to overdo it. If a keyword is important it will appear in the main copy a few times. The appearance of keywords in 400-1000 words of copy should live around fewer than 10 times.</p>
<h4>Titles</h4>
<p>Every document should have titles. These titles are going to range from the overarching document title down to sub-sub-subtitles. This hierarchy of titles is important in SEO because it tells both your reader and the search spider what is most and least important. If you have good titles, they will work for you. If you choose poor titles, or worse, your hierarchy is haphazard, then they may well work against you. Take care to pick the right title structure for what you are actually trying to say and you will do well.</p>
<h4>In-bound Links</h4>
<p>Any site that is considered an authoritative source on anything is bound to have in-bound links. If people care about what you do or say, they are going to refer to you for citation. The people who created search algorithms know this and they take advantage of it. The more in-bound links your site has, the more likely it is to be an authority. Authoritative sources show up higher in search rankings than derivative sources. Keep this in mind and strive to be an authority. Pick something that you do which the rest of the world could do to know about. Push that and become a key player. This will boost your site rankings as well as being a generally good business practice.</p>
<p>While we are discussing links, let&#8217;s discuss directories. There are several directories on the web but, as far as I know, there is only one that is still completely human edited and maintained. That site is the <a style="color: #000000;" href="http://dmoz.org/" target="_blank">Open Directory Project</a> (<a style="color: #000000;" href="http://dmoz.org/">http://dmoz.org</a>). Since the Open Directory Project is human maintained, it is given more value by the search engines. It is the equivalent of having a single person, who is a noted authority, personally vouch for your site. This would be like having someone with a doctorate vouch for your research in their field. It&#8217;s mega bonus points and you should use it to your full advantage. It takes a while to get listed so don&#8217;t fret if, after you submit your site, it takes months to see a result.</p>
<h4>Meta Information</h4>
<p>This is where things get a little more technical. Meta information, generally referred to as meta tags, provide spiders with direct information about your site. You can add things like a description and keywords. Both of these things will help people find your site more easily. The meta keywords typically aren&#8217;t given as much weight anymore, since people abused them in the past. Your meta description is the vital one. Google, for one, uses your meta description to tell people about your site in your own words. That&#8217;s a good thing since it gives you personal control over what people see before they hit your site. Below are the tags that should be included in the head of your page:</p>
<p>&lt;meta name=&#8221;description&#8221; content=&#8221;your site description goes here&#8221; /&gt;<br />
&lt;meta name=&#8221;keywords&#8221; content=&#8221;your keywords go here&#8221; /&gt;</p>
<h4>Document Format</h4>
<p>The underlying format of your document will tell spiders a lot about what they are looking at. This is one of those items that can be worked on over time. As long as spiders know you are out there, they will check back on pages from time to time to ensure they know about the latest changes. First, it is best to pull your site out of that table layout you are using. Spiders think tables mean that each piece of data is related to another in a certain way. If your entire format is a table then they will not correctly interpret the content you have on your page and you might lose brownie points.</p>
<p>Commonly, sites are created using page divisions, as God intended. This means that you tell the browser &#8220;this is a piece of this page and it stands on its own.&#8221; Spiders can read this much more easily and the whole site degrades much more gracefully if you do a good job. Graceful degradation makes your users happy, especially if you have users with limitations, using a special browser. Once your document is formatted properly, you can arrange your divisions into an aesthetically pleasing format using Cascading Style Sheets (CSS). CSS is outside of the scope of this discussion, so I am going to let that dog lay.</p>
<h4>Sitemaps</h4>
<p>I&#8217;m not talking about your run-of-the-mill sitemap for your visitors. I am talking about a carefully crafted and standards compliant XML sitemap. There is a standard used for creating a sitemap and, once you have one, it makes indexing your site a breeze. Search spiders commonly grab a sitemap so they can better understand what they should and should not index. Sitemaps also allow you to tell spiders how often certain pages are updated. This allows them to index pages that change all the time more often than pages that may not change for months at a time.</p>
<h4>Robots.txt</h4>
<p>The robots.txt file is a simple text file that tells search spiders what to index and what to ignore on your site. It&#8217;s similar to a sitemap, but the parameters are limited. You can say &#8220;index this&#8221; and &#8220;don&#8217;t index that.&#8221; This is great if you have some pages that are currently in development, should not be seen by the public or other strangeness like that. This also allows you to have a copy-testing site that should be ignored. Duplicate copy on sites is looked down on by search engines, so anything you can do to avoid indexed duplicate copy is a good thing. I typically have a sparse robots.txt file as most of my site is viable content, but government agencies and Rupert Murdoch seem to like robots.txt quite a bit.</p>
<h4>.htaccess</h4>
<p>This is probably a book in its own right, but it is something that people should be aware of. The .htaccess file allows administrators to control site access and redirect people to new pages and away from missing pages. Correct use of the .htaccess file can limit the number of broken pages that spiders will encounter and keep your visitors happy. One of the best features of a good .htaccess file is the ability to redirect users and spiders alike to new pages and send a message back to them, letting them know the redirect is permanent. Spiders like knowing that a page has moved. It makes the whole process of reindexing faster and easier. This kind of redirect is generally called a 301 redirect for the code that is returned by the browser.</p>
<h4>Blogging</h4>
<p>We live in a time where the blogosphere is king. What this means to the rest of the world is, blogs influence online life. Blogs change rapidly and bloggers tend to stay atop issues that are near and dear to them. Blogs are also a boon to your industry. If you have a blog that reflects knowledge and a profound understanding of your industry, you are more likely to be considered an authority. Blogs also give your site an opportunity to generate new content on a regular basis. Search spiders like new content and index sites, which are regularly updated, more frequently. This also provides an opportunity to share information about your industry in a non-business environment and generate in-bound links, you remember what I said about those, right?</p>
<h4>Social Networking</h4>
<p>This is closely tied to blogging, but it can impact your business and website in many ways. From forums to MySpace to Facebook to twitter and others like these, people will talk about what they do and don&#8217;t like. If you are a well liked provider, the word will get around and people will head to your site. These sites help people to find things that others have recommended and they are a great source of in-bound links. Search spiders check these sites often as content changes minute to minute. Also, if someone recommends your site on a social network, it is taken as a personal recommendation and spiders will take note.</p>
<p>There are so many ways to take advantage of social networking that it should probably be at least one, if not several, college courses. I did choose to list this one last, however. If you have not worked on everything else first, social networks can be your worst enemy. People will say negative things about their experience and spiders will touch your site more often only to pick up your poor SEO. Once this happens, it&#8217;s downgrade city, so watch out!</p>
<p>In the end, there are many facets to SEO, but most of them can be worked on and improved by anyone that helps build, update or administer your site. With this information I charge you, go forth and make the web a better place.</p>
<p>&copy;2012 <a href="http://www.chrisstead.com">Chris Stead</a>. All Rights Reserved.</p>.]]></content:encoded>
			<wfw:commentRss>http://www.chrisstead.com/archives/26/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

