Last night and today I put in some links to news bookmarking and social networking sites on the article pages. Users of Digg.com, Del.icio.us, Furl.net, Reddit.com and Slashdot.org will recognize the familiar logos. For the rest of us, here is what they do.

If you are not a registered user of these sites, you will be asked to create an account. It’s 100% free and is required simply to ensure that robots don’t spam the system and render it useless. Once you have created an account, you can click on the link from any of our articles to add them (or “bookmark” them) on that site. You can then go back later and check your bookmarks to easily find content you were at before.

However, on the more social networking side, the more people that click those links the better it is for our traffic. Each click equates to a vote for this content, and the more votes some content gets the more people get exposure to it. On the one hand we are always interested in more website traffic, but the real reason for doing this is also to make it easier for people to search the web. With content being updated so frequently on the web, social networking sites like these make it easier for people to see what is popular, and what other people are recommending.

So if you can’t bring yourself to register at one of these sites and participate by clicking the links on our articles because it will help the internet to more organized and help others to find content… then do it for me!!! I can always use more web traffic, so at least scrape up the effort to do it for me. After all, I put the links there, you might as well click ‘em.

We have a great thread in our community forums right now that is a discussion about CSS, and whether or not to use it, how hard is it, can it replace tables, and so forth. I completely understand the difficulting that people have when they have reached the point of not being able to deny CSS anymore. I mean, you go nuts trying to learn HTML, and to figure out how to translate a cool photoshop layout into a website, and then someone tells you that you need to learn something else.

Here is the reason for that. The simple HTML that most of us learn when starting out is a quick means to an end. Most beginner designers don’t even know what search engine optimization is, much less how to design for it. And why should they? However, it is important to anyone out there that is learning web development to understand that when you are learning HTML you are basically learning a vocabulary and a way of thinking. Once you have the “vocabulary” you then possess the tools to begin learning the real art of web development. After all, any high school kid can make a website from a photoshop document (nothing personal against high school kids, some of the most talented developer’s I have met were in high school). In fact, most towns have two or three web design outfits in them that do that kind of design.

However, to stay competitive and to provide great sites, you will need to learn how CSS and XHTML interact. You will have to focus on separating the content from the layout, and believe me when I say that a whole new world of possibilities will be at your fingertips. Take the old issue of whether or not to design for 800 x 600 px monitors or for larger monitors. Who cares? With CSS you can take the same XHTML document (the content) and have it display one way if a larger monitor is detected or another way if a smaller monitor is detected. Using a little JavaScript to change the CSS stylesheet is all that is needed. Or your users can decided that they want to make the text larger on your site, since they can’t see it well. A simple button that changes the stylesheet will acccomplish that as well.

These are simple examples of course. I think that someday when I have more time (we have some really important and exciting, but BIG projects going on at the moment) we will try and get some good beginner tutorials up about CSS. It does require a bit of a head change with regards to viewing layout. In the meantime, thanks to everyone participating in our community forums!

I wanted to put a quick post up here about XHTML. It’s been almost six years since the W3C declared that XHTML was replacing HTML 4 as the standard markup for web documents, yet I still consistently see code on websites that does not utilize XHTML. While I know this seems like a small thing, I feel as though it deserves some attention. I’m not going to go into all the advantages of XHTML, but I think that there are a few things to mention. Because XHTML is based on XML, a well structured XHTML document can easily be reformated for display on mobile devices, PDAs, cell phones and more. Not only that, but a well structured XHTML document should rely on CSS for formating, which ensures that your code is lean and clean for search engines. There are countless other reasons to be using XHTML, and for ensuring that it remains valid on your stie. However, I just wanted to bring it up since I have been seeing so many sites lately that are using HTML 4 rather than XHTML. If you aren’t sure about your site, ask your web developer to explain what document type your site uses, and why.

Well, it’s spring time (supposedly). I can’t express how happy I am going to be when it is warm here in Steamboat Springs, Colorado. To be honest, I can’t wait until there is just no more snow and a hint of green. We’ve had an incredible winter of snow, which has been great, but I am ready for it to be gone and for the kayaking and tubing to begin.

Back on track, I had to get that out… I wanted to touch on the importance of good clean HTML and XHTML coding. Michelle Lambert touched on this in her last blog entry, since she has been seeing some good improvements in search engine rankings by doing a little house cleaning on her site.

I often get criticized among my web friends for “focusing too much on HTML code, and for thinking that coding is more important than it is”. And as a web developer who is utterly fascinated with code, I agree with them. However, all things being equal, I maintain that cleaning the code of your website is the most important aspect to search engine optimization. There, I said it. And here is my brief explanation of why I think that:

All things being equal, the site with the better coding will rank better. Of course, all things are not equal. Your competitors could be paying more for pay-per-click ads, or have better incoming links to their site, which would give them an edge in the rankings. However, you can always pay more for advertising, or solicit better links to your site. Your code, on the other hand, is something that is generally handled only by a web developer or even your shopping cart software. And here is where the edge comes in; Most web developers do NOT know how to create search engine friendly websites. Sad, but true.

I would encourage more people to participate in our forums, especially the “Search Engine Optimization” section where you can get advice about cleaning your code. I try really hard to help everyone out, and where I can I like to provide sample files for people to learn from. I really appreciate Michelle’s kind words, and I’m glad that her site is improving in the rankings. Ideally we can get everyone’s site to improve as well.

I’m sure this one has been beat to death somewhere, but I wanted to touch on it here since it came up with us recently. First of all, a PHP session ID is a unique ID given out by the PHP processor. These can be appended to a URL so that you have:

www.mywebsite.com/?PHPSESSID=183249712347012374871234872314

This is bad. That unique identifier seems to cause search engines to think that it is a different URL than www.mywebsite.com, which means that there will be duplicates created, and you will be hurt in the rankings. Not all search engines have this problem. Google appears to be very astute at figuring that out.

So as our new site begins to register with the engines, I noticed that Google was great, but MSN has been draining our site (over 400 MB per visit), and is listing session ID’s in the URLs of the pages it has found. That had to be fixed, and anyone facing that situation, here is the solution…

The hosting company helped to configure the PHP settings. If you do not have access to this, you can usually put a file called php.ini inside your root folder, and it should work for you. Essentially you want to tell PHP to use cookies for session ids. This means that if a user has cookies enabled, it will store that session id in a cookie. There are also other settings to look at such as;

sesssion.use_only_cookies
session.use_trans_id

So that takes care of that, since most users will have cookies enabled they will no longer see the session ID in the URL. Of course, this is purely cosmetic. That does nothing for the search spiders that don’t accept cookies. In this case, PHP decides to put the session ID at the end of the URLs. So we haven’t gotten anywhere.

The answer to this is to go into your PHP code, and whereever there is a call to start a session (session_start() or session_register()), you need to put a check in there that looks at the user-agent of the requesting browser. If it is a robot or spider (which you have to create a list of these), then you should make sure that a session is not started. It’s a lot of work, especially if you have a large site or application. However, it is the only way to ensure that spiders won’t get sessions IDs in the URLs. While there are tons of spiders, I would recommend the following, as they seems to provide most of the search results on the web:

Google: Googlebot
MSN: msnbot
Inktomi: slurp
Overture: fast
Alexa: ia_archiver
AltaVista: scooter

These are the strings that you should look for in the user-agent to determine if these are the spiders visiting the site.

So in the end we are left with three possible visitor types. The first is a normal user-agent (IE or Firefox) that allows cookies, which will not see session IDs since they will be stored in the cookie. The second is a normal user-agent (IE, Firefox, etc.) that does not allow cookies. These folks will see session id’s attached to urls, but that is the sacrifice they make for not allowing cookies. The third option, which is most important from an SEO standpoint, is that the visitor is a spider (user-agent matches one from the list you have defined) in which case a session willl not be started, to ensure consistent URLs and to make sure that no duplicates are indexed.

I hope that this helps. Please post any questions about this, or if you want some help with handling PHP session ID’s, visit our Community Forum.

OK, the RSS feeds are up. There is one for the articles, and another for the podcasts. I thought I would fire out this little tidbit that relates to RSS feeds, but is probably a little advanced to ever make it into the magazine.

So an RSS feed is really just an XML file. The process goes that when you subscribe to an RSS feed using an RSS reader (such as Safari or Vienna), it basically bookmarks the URL where it can find the XML file. It will then check that XML file periodically, compare it to the previous version, and notify you of new articles or content. iTunes Podcasting directory works much the same way, only it will also download the mp3 podcast file when it sees that there is a new one available.

OK, so that being said, the RSS feed does not need to be an actual XML file. In our case, the RSS feeds are PHP scripts that then output in the correct XML format. This is something that most tutorials and such about rss seem to leave out. They always seem to imply that you have to manually go in there and update your feed. Not gonna happen with the magazine, so I opted to have the feeds dynamically generated to ensure that fresh content is pulled from the database.

A couple of things. Ouputting the XML format is a piece of cake, and any PHP developer should have no problem. There is the issue of headers. You may try to validate your RSS feed and see an error that the feed and content-type don’t match. Content-Type is a header that is sent by the server describing the content. There are two options for RSS feeds:

1. Content-Type=text/xml - This is the one that you will probably want to use. Since a normal RSS feed is an XML file (a text file), most things expect that this will be the content type.

2. Content-Type=application/rss+xml - this one is a little more specialized. This one denotes that you are trying to send application data. One place to use this is in the head of your HTML documents to allow browsers that are also RSS readers (like Firefox and Safari) to know that there is a feed.

I opted for the previous, since it is more universal and also because the seconde option causes some funny things to happen in Firefox. It would assume that based on the content type I wanted to open an RSS reader application and that was annoying. However, the second one has it’s place. Check out the HEAD section of our website to see how we use that content type to display the RSS feed in enabled browsers.

Another thing that will prevent validation is if the character encoding sent by the server does not match the character encoding declared in the RSS feed XML file. For example, in our feed I declare that we are using Unicode (UTF-8) encoding:

So I must also ensure that the ouput of my PHP script is encoded this way as well. Both of the above declarations are handled by the PHP header function. As you can see below, it sets the output content type to “text/xml” and the character encoding to “UTF-8″:

header(’Content-type: text/xml; charset=UTF-8′);

Hopefully this is helpful to anyone that is interested in creating a dynamic RSS feed, but is having trouble getting it to validate.

One part of the site that has already been completed has been the “cleaning up” of the URL’s in the site. We cover this a lot in the magazine, and it is a pretty common topic among Search Engine Optimization discussions lately. Rumor has it that search engines will not index pages with URL’s that look like:

http://www.exampleaddress.com/catalog/index.php?cat=20394?¢Àܬè_id=1234534

That is actually a bit of an overstatement. The truth is that most search engines will follow these URLS, however there are limitations. For example, one such variable (these are passed after the ? symbol) might be a unique user id or session id. These are generated by the server and are usually long strings of numbers. These are bad. Don’t expect a search engine to effectively index any URL that has a session id or other unique id.

Secondly, a good rule to follow is that if there are less than three relatively short variables being passed, search engines should index it just fine.

HOWEVER, it is important to note that the search engines realize when they see the “?” symbol in the URL that the site is accessing a database. In order to prevent too many hits on a database in short period, the search engines will index these pages more slowly. It’s a nice thing for them to do, especially if you have a huge site with extremely high traffic that would be slowed down for your customers if the search engines index it too quickly. For the rest of us, which is nearly everyone, this is not worth it.

So here is why we wanted our URL’s to be cleaned up:

• 1. Search engine optimization - we wanted our URLs to be nice and clean, containing no traces of dynamic content to slow the indexing down. For the most part we were able to convert the following URL:

  http://www.exampleaddress.com/index.php?cat=34&page=2

  into nice pretty URL’s like this:

  http://www.exampleaddress.com/34/2

  It seem like a minor thing, but it is worth it for the search engines. There are many ways of accomplishing this, including using MOD_REWRITE to rewrite the URLs. The best things that I can say about getting started with this is make sure that you know exactly what all your URL’s are going to be site wide before beginning this.

• 2. We also wanted our readers to be able to copy and paste URLs into emails, or tell people about them without them being complicated. After all, if you look at the URL’s above, it’s much easier to say to someone on the phone, “Go to www.exampleaddress.com/34/2″ than it is to spell out the first example.
• 3. This method allows our tracking software to give us a better idea of what is happening on our site. Rather than passing variables to a single page, we are created completely new (even though they are fake) URL’s. In our case this helps our analytics software, Google Analytics, to better provide us with information. By setting up some special code, we are able to see exactly what content our users are viewing, and not just what pages they are seeing.

Of course, since we are using other external applications, there have been complications. For example, our forum is powered by phpBB, which is an open source forum software. Since it wasn’t written by me, I can’t control it. I am sure that there is a module or add-on out there that will do it, but there are more important things for me to deal with right now.

Also, these blogs are powered by WordPress, which I must say has an excellent control panel option for presenting clean URL’s. Not only that, but our subscription membership software, aMember Pro, which controls the access to our premium content and manages our subscribers and affiliates, has had no problems adjusting to the URL scheme that we have implemented.

I am done preaching about URLs.