A blog about location aware services, cloud architecture, mobile applications development on the iPhone, G1, Palm Pre, whatever, plus traveling, microblogging, and other random musings from developers building some secretly cool stuff

So you may wonder when you see all of those TinyUrl version of links to your site on Twitter if those links actually positively affect your sites page ranking.  If so read on…

The quick answer is mostly no… and the long answer is of course more technically complicated.  First lets delve into TinyUrl.  In case you dont know what TinyUrl is basically it can take any URL and turn it into a shortened “tinyurl” - perfect for microblogging sites like Twitter where you only have 140 ish characters to get what you have to say across and you dont want long urls waisting those preshish 140 characters.

Now the TinyUrls service at the technical end generally does things right.  For example a link to socialguides gets converted to http://tinyurl.com/clpr7g.  And what is happening behind the scene is that when you click on that link it takes your browser instantaneously (so you never know) to the TinyUrl server and they lookup what that URL actually responds to and the forward you off to the real URL before you ever knew your browser went anywhere.

What’s important (from an SEO perspective) about the redirect from TinyUrl is that they do it via a 301 header redirect which tells your browser (in a standard compliant way) that the actually URL has “permanently moved” to the real address.  This is incredibly key as Google passes the pagerank for the original tinyurl not over to tinyurl.com but to socialguides.com, or well whatever the final site is supposed to be. That’s a good thing.

Unfortunately its not all rosey in the land of TinyUrl and Twitter services.  First, because of the nature of tinyurl shortening the link you no longer have anchor tags.  For example if you make a link like this: Techzulu a cool technology blog covering southern california , Google will assoicate the link reference to the Techzulu site with potentially important keywords like “technology blog” and “southern california”.  Now if we look at the TinyUrl version: http://tinyurl.com/ack7de we see that there are no anchor tags and thus less SEO loven.

Now if that wasnt bad enough, when it comes to Twitter the thing I said about the 3o1 redirect that TinyUrl does that allows you to get the “link juice” actually doesn’t even count.  The reason is Twitter takes all URLs found in posts and appends a “nofollow” to each link.  This means that Google will not follow the link at all and thus gives you no credit for said link. This, much like wikipedias implementation, is primarily to avoid spam from blackhat seo folks and the like.

On onehand this really isnt a TinyUrl problem at all so why do I bring it up?  Only because if your link is fully written out on Twitter (in long form) at least you get a little bit of that silly marketers thing called “brand awareness” for your site even if you dont get Google credit for it.  If TinyUrl is used, not only do you not get Google credit for it, you also dont get any brand loven either.

Unfortunately while I understand the Google spam issue, and the reason for nofollow on Twitter it is unfortunate that Google has asked Twitter to implement it that way.  If people are talking about a website then surely that is precisely what Googles pagerank SHOULD be counting to determine popularity/authority/etc.  But that rant is probably for a different post.

So all that said, should TinyUrl still be used?  Probably, because you likely still need to shorten URLs on microblogs and you get what you get.  As for us, we’ll be partnering with a with a very cool company that is still in stealth mode (and arent we all ) in the future that could help resolve some of these shortcomings. Stay tuned.

Sources: beussery web1marketing andybeard

I’ve got to admit, wordpress is pretty epic as blog systems go.  They have a hosted service which is free, or you can pay for an upgrade to get premium features.  While I’ve always admired the wordpress guys from a far, I’ve always used blogger.  The reason has been pretty simple: I’ve always wanted/needed to use my own custom blog domain.  To have a hosted blog as blog.company.com or whatever.com (instead of with the wordpress domain) required the premium upgrade.  Now not that the insanely trivial 10 dollars a year or whatever it is for the wordpress upgrade isnt worth it, but just the fact that blogger offers that feature for free always just made me use blogger.

But this go around we are trying to be SEO focused from the get go.  And on that point blog.company.com doesnt hold as much juice for the overall domain strategy as company.com/blog does. To avoid mickey mousing stuff (like using a silly masking type strategy - which BTW losing some of the SEO advantage you were going for in the first place) the best thing is just to start hosting the blog on your own webserver.  I’ve usually avoided that for various reasons (such as why waist your own webservers resources when you don’t have to), but it was starting to look like time to break down and install the opensource version of wordpress.

As code goes, wordpress base is actually quite nice, and since we are (among other things) a LAMP house, integration is a snap. What’s particularly nice about the integration with your own system is that you can start utilizing blog feeds on other parts of your site with much less overhead.  For example, a good SEO strategy would be to put some of the most recent blog posts on the footer or sidebar of your “nonblog” pages, as it adds a we-bit of dynamic content (useful for both the nartural user flow of your site as well as SEO gains).

Now one way to do this if your site was hosted directly with wordpress or blogger would be to just get something like a feedburner widget which can be a plug in play type solution for your main site with minimal effort.  Of course you don’t want to do that because feed widgets like that bring in the posts via javascript and thus dont get seen at all to our google crawler friends.  So no SEO value there.  This leaves us with the sort of “standard” route that a lot of folks like myself have used (if they are LAMP based that is), is to rely on the MagpieRSS library.  Now the Magpie solution is cool in that you dont have to write your own xml parser but it tends to lack some flexibilty.  Even more importantly is that to use it effectively so you dont crush your server (by having every user request to your servers also have to fetch data from another server ) you need to implement a caching algorithm.  Now of course, writing code to cache in PHP is pretty simple but then you lose some of that dynamic SEO loven that we are looking for.

So that leaves us with a local wordpress install.  Integration becomes a snap, since they are just local lookups there is the lowest performance overhead and maximum SEO value.  Now already brought up the downside, which is that I dont get the offload advantage of “freely” using someone else hosting.  But heh, no matter, noone reads this blog anyways…

Since we  will be migrating domains in the coming future, today we setup a little virtual host loven in Apache.  While most folks know the importance of setting up proper canonical structures with 301 redirects and the like for SEO purposes, I figure I’ll post just in case someone doesn’t.

First a basic virtual host setup:

Now that gets us going for adding another domain on the same apache server.  You can add as many of these virtualhosts blocks as you need domains supported.

Okay so next is to get a little SEO in play.  One of the most talked about things on the seo side is getting the canonical structure of your website setup properly so the www and non www dont end up being seen as two different sites to google and the like.  The downside is obvious if www.socialguides.com and socialguides.com are treated separately then your pagerank could be split between.

While it doesn’t matter which version you pick, you do need to pick one and roll with it.  Now a mistake that gets made occasionally is people just aliasing one to the other.  Something like using Apache’s ServerAlias directive to take all requests that dont match your preferred “www.socialguides.com” and show it anyways.  The problem though is while a user then doesn’t get a dreaded 404 error, you’ve only really just masked things and our search engine friends like GoogleBot will still think they are separate.  Instead you want to send with it a 301 permanent redirect in the header so the crawlers know to unify the link juice.

With that we need to add another virtual host entry with a redirectmatch rule.

The reason we add a completely new entry all together is that it fixes some annoying bugs with infinate redirect loops as well as gives you the ability to catch the “bad requests” in separate logs if so desired.  If your not using a virtualhost directive then all you really need is the redirectmatch.

Anyways as you can see we can now catch non-www traffic (as well as typos) in a SEO friendly type of way.