Above is a screenshot of a search result from BusinessPeru where Google have added the rating. I did have an idea that the general CTR in the SERPs would be higher as the stars make your result stand out – but I had no idea that we would see a change of 20% in traffic increase.

The screenshot below shows our Analytics comparing the month before and the month after implementing the stars. (Showing incoming organic traffic) As you can see it shows almost 20% increased traffic from organic search, improving on every single day except the Easter Holidays as marked – as our traffic always drops on holidays and weekends.

So what are you waiting for?

Implementing stars (and other markup tags to add rich snippets) is actually very easy. If you are using WordPress I suggest you have a look at GD star rating which I use on my blogs (including this one). Make sure you test your sites with Google’s Rich Snippets Testing Tool (part of Webmaster Tools).

There is many other markup tags you can add, and recently they started using and showing Product Rich Snippets in the global search results – so if you have a webshop or are listing products, make sure to add markup to your HTML.

If you have any questions or want a guide of how to implement it, feel free to post a comment here. I hope this helps more webmasters implementing these features – and as you can see of our results, it is well worth the time adding a rating system and using markup tags.

You can also see an example of the rating system on one of our listing pages: Mediterraneo Chicken Miraflores

The theme is build up with Bootstrap 2.0.1 and is currently support English and Danish. It is mainly made for my own use on this blog (and my Danish blog) to get some experience in designing themes for WordPress and using Bootstrap.

How to Install
1) Download the latest .zip file from Github.
2) Upload to your WordPress in the wp-content/themes folder
3) Activate theme and enjoy!

Credits
Big thanks goes out to @mdo and @fat for creating Bootstrap and making it available as open source.

TODO
I’d like to add several futures in upcoming versions:
- Edit the theme to fully comply with the WordPress.org Theme Review guidelines and upload it to WordPress.org
- Figure out a way to get the top menu to support Dropdown for sub-pages
- Update the comments styles to look better
- Update comment form to use Glyphicons

If you have any suggestions, feel free to leave them in this post or send me an email. And don’t forget to feel free to contribute to Github!

First of all, let me explain that Nixter is a Chilean startup that recently raised $100.000 from Chilean Angel Investors. I read about them on AndesBeat, and it does state that they went to San Francisco to work as part of some kind of incubator – cool for them, indeed.

Now let’s go straight to the point. As I was curious, I of course signed up to receive an email when they launched their app. And today the email below popped into my mailbox. But there are two huge mistakes in that email.

1) They sent the email with everyone as cc, giving up people’s email addresses. That is sharing with 3rd party. How can people working in tech not know the difference of cc and bcc?

2) There is no clear call to action! (CTA) Where am I supposed to go to download Nixter? Where can I read more about it? The only thing is a link to their website in the signature, and a non-clickable Twitter-account.

Did you forget your roots?
Now before I get to the point of what they should have done with the email, another even more tragic thing occurred to me. As I clicked on the link in their signature to go to their website, I got the message you see below.

“Nixter is not available in your country… yet…”

But I am sitting in Chile – isn’t that where your startup is from? Wasn’t the angel investors Chilean? Or is it just yet another Silicon Vallay wannabe-startup type, that only wants to make product for the SV/SF Bay-area? Come on, at least make it available in your own country!

And what can we learn from this?
1) Never send out emails to your customers putting them all in the cc or to field! This is a mistake that simply should not happend, especially not when we are talking about tech people! This is breaking every single standard for privacy and trust in the company.

2) Make a clear CTA in every email you send out! Even if you send the email out in plain text, make a bit fat link in the middle of the email with a clear “Click here to download our app”. Don’t leave your customers in the blind.

3) If you don’t have your product ready yet, don’t bother people. There is nothing less interesting than a “Sorry not available in your country” if you just sent me an email saying it is! That is called wasting people’s time, and patience is not a virtue people have online. Soon the email will be deleted and the user has forgotten everything about you or your product.

To the Nixter team, if any of you are reading: Please don’t take this as anything negative, just please learn from it. I am looking forward to testing your product one day, but please don’t make rookie mistakes like this – it will make you look bad for your customers and if you keep on making them, it will hurt your sales and reputation in the future.

About a year ago I started moving more of my hosting to “the cloud”, basically choosing to use a VPS solution instead of renting servers in a datacentre. It was right after a breakdown, and the danish hosting center that I had used since 2007 (former Plusnet, later bought by Jay.net) had a terrible customer service and the server I was renting was starting to break down. The point where I took the decision to switch, was when it took me over 3 days to get them to change the HDD in the server – in the end they “upgraded” me to a newer server and fixed the old HDD and connected it with a USB cable. But 3-4 days of downtime is just not acceptable, when you are running both email and production websites for your clients.

I have learned a lot more about hosting since then; I am no pro, no do I normally work with hosting, but having more and more production sites online, it makes me extremely annoyed when I get downtime. With this world of cloud-computing, any downtime at all is almost unacceptable. One of the things I did was to make sure all email hosting was no longer on the same servers (I actually use a $10-monthly account at HostGator for all email hosting).

Now with VPS.net I will start by making a short list of the good and the bad, before I try to make a final point. I can however say that I have decided to experience with Amazon in the future, but it will be when time allows me to play with a more challenging project – I already have the ideas to split it up (DB, main source & user data like images apart, using Amazon’s Elastic Load Balancing to reach fail-over).

Things I like about VPS.net

• Excellent free support goes a long way. When people are nice and usually answers within 10 minutes, it is hard to get mad – even when having problems with downtime.
• The price is another great reason to buy a VPS. Starting at $20 USD per month (or $1 per day if you need a quick burst), and going down the more you buy, the nodes are pretty cheap. I currently pay around $100 per month for 2 instances with 3 nodes each, which is plenty to run for most of my projects. If you ever need more, you can give a quick burst for a day or two with extra nodes, which is a nice option to have.
• Scalability is the last thing I will emphasize. As mentioned above, upgrading your VPS with more nodes is easy and the user interface is really nice. Seeing a growth in traffic? Throw an extra node and make sure your VPS can take the pressure.

And now to the downsides of using VPS.net…

As I said in the beginning, this will be a honest review of my experiences using VPS.net, and going through the positive stuff have given them enough credit. Like I mentioned before I am planning to do some more technical experiences by custom building some application for AWS & spreading out the hosting with fail-overs.

So right off to the main points why I would not recommend you to use VPS.net and the couple of incidents I had..

The might be some downtime – yes I know, “how can you expect 100% uptime?”. This is the cloud. The only downtime should be when I fuck up my settings, or do some other stupid thing. I had a couple of times where my VPS was suddenly read-only, and they had to use some time fixing it. Below is a screenshot of the last couple of months where I have been using Pingdom, with “only” 98.62% uptime. anything below 99% is not good (in my eyes) when we are talking about “the cloud”. As the screenshot shows, I had a day with over 11 hours of downtime – just not acceptable with production servers in my mind.

Now you probably wonder if I am going to end this post either blessing VPS.net as “the best VPS hosting provider” and throwing some affiliate link, or if I will come with some negative crap about “that day with 11 hours of downtime”. But well, I promised to be honest so I can do neither.

In the end, they are providing a good service for what you pay. $20 per month per node including free support (where they always have answered within 15 minutes) is not that bad. But – and this is a big mother-but for me – the best host is where you do NOT need to contact the support at all.

I’d love to hear from you, if you have experiences with VPS.net – just throw a comment below. And if you are looking for a VPS provider, take a look at them. It also depends how serious you are, and how hard you look at a bit downtime. Nobody is perfect, and VPS certainly still have some work to do to become a 100% stable cloud-hosting provider, that I would recommend. If I ever get around to do the project using Amazon’s micro-instances to create fail-overs, I will ofcourse follow up with another blogpost about that.

First of all I expect you to know at least the basics of PageRank and how it flows. Go read up on it on SEOMoz or just Google around for it so you get a basic understanding of how it works. This is the basics of why and how we make our link structure.

There is several ways to organize your content, and make a map of the link structure of your application. Some people create “graphical maps” with an easy overview of the pages and the “virtual sitemap”. Personally I create a kind of “technical sitemap”, but that is usually also something I use when building the technical description of a project. This especially helps me when dealing with a lot of dynamic content like in directories. In most cases you want focus on getting PageRank and crawlers directed to your content pages, to make sure they will rank on long-tail keywords as well as get crawled and indexed more often by Google.

At the MozCation in Lima last Friday, I got a few tips that I hadn’t thought about before; Tom Critchlow was talking about SEO for Enterprises, and mentioned one of the things he doesn’t like is pagination. Instead it’s better to use some kind of tags or other content-related to sort your content pages. Based on this I will try to make some updates on BusinessPeru as we have always used pagination on categories with a lot of entries. I will be testing several things to see if they affect the rankings and traffic we receive, as well as the crawl rates from Google.
The same thing goes for my other project, FeedOrganizer, where I am working on a smart way to categorise and sort the content automatically, instead of using basic listing and paginated pages.
I will probably return with a more specific result about my tests and the results thereof, once I actually get to complete all the updates above. Now to get back on track with what the article is actually about…

Internal Linking is both for your users and for the search engines! Like Google time after time is saying, the most important thing is creating good content and making a good experience for your users. But while your users is important, there is no need to make it harder than necessary for the spiders. Make sure that every content page is easy to get to (I usually have the rule of thumbs that it should be max 2-3 clicks away from your home page), and that there is some logic in the structure. If you are trying to rank on specific phrases, make sure they are available directly from the index page of your site; but don’t fill it up with links. Another rule of thumbs is max 100 links on each page, otherwise it might be looked as a spam. Another is to remember the rules of PageRank; filling your pages up with lots of (internal) links, will make the PageRank flow being reduced.

I hope this can help some people to get a better idea of the Internal Link Structure and why it is so important to think about before you develop your web applications. Please throw some comments at me, especially if you have some experience with ways to avoid pagination or just other tips for managing lots of dynamic content in terms of SEO.

This is part 4 of 5 in my series of Must-Know SEO for Developers. You can find all the parts here.

• Part 1: Avoiding Duplicate Content With 301 Redirects and Canonical Tags
• Part 2: Using Correct URL Structure
• Part 3: Using Correct Meta-tags And Other HTML tags
• Part 4: Internal Linking In Your Web Application
• Part 5: Using Webmaster Tools And Analytics

The event was (as far as I understood) arranged by Lima Valley, a group I have mixed feelings about. (And as I just realized, have the most terrible SEO ever in spite of using WordPress). Nonetheless the event was allright, with a free buffet and some wine – and even free T-Shirts as you can see on the photos in the bottom of this post.

Most surprisingly I actually thought that the people attending this event knew at least the basic of SEO. But when the first speaker came on and asked “How many knows what Keyword Research is?”, only 2-3 other people in the room put their hands up. This was a bit of an “omg” moment; because this is so basic and fundamentally important for SEO in general.

All in all the event gave me some nice inspirations and thoughts about the state of SEO and Internet in general here in Peru. It hasn’t moved much since I came here, and although it is changing bit by bit, the process is really going slow. I’m hoping to spread my series of SEO for Developers a bit in the community, it is certainly something they need to learn here. All good SEO starts with the developers – if your CMS is directly hurting your rankings, all other optimizing is pointless.
I also think there might be some good opportunities in this field now, and to be one of the first movers. This might be something I will try to focus on in the upcoming months.

To sum up, then I am looking forward to following the development of the SEO as the markets in Latin America starts to mature and get more traction. It will definitely be interesting to follow an upcoming and merging market like this.

What is your experiences with SEO in Peru and the Latin American markets? Where is the biggest differences, between SEO en Europe / USA compared to South America?

Let’s start with the meta description, which is really the most important meta-tag you need to remember. First I want to kill a typical myth about this tag: it does not help your site rank higher. The only purpose for the meta description is to provide at snippet about the current page for Google. Now why is this tag so important? Because it gives you a chance to write 160 characters to get the users attention – this is what differentiates your results from the other results on the page. I have seen several sites having the CTR on search results improve a lot, just by optimizing their meta description.
Another important thing to mention with meta-tags, is that meta keywords is useless; it is out-dated, and no longer used by Google (most likely not by other search engines either). Generating or writing meta-keywords is a waste of time in terms of ranking and SEO, so just skip it. Save the bytes in your HTML for more important tags (like the canonical!).

Now let’s move on to some of the other important HTML tags. First of all you should always remember to use h1, h2, etc. where applicable. If possible also wrap your paragraphs into the p-tag, and in general make sure you follow the W3C guidelines.
A small tip is to take a look at your generated HTML (yes, go to your browser and use the view-source function), and read through your page. Now ask yourself if the page is easy to read? (Is it easy to identify title, content, and other objects?)
If it is easy to read your page as a human, then it is most likely also easy for Google to read and understand. If this is not the case, then you should probably start to work on optimizing your HTML.

To sum up, here is a small check-list when going through your HTML source:

• Always make sure to have unique title-tags (Google only shows 60 characters, but it will read much more than that, so don’t be afraid to have too long title-tags)
• Make sure to create a unique meta-tag description for each page. Never have the same meta-description on all pages.
• Use h1, h2, p, strong, em, and so on to format your text and content. A rule of thumb is that if your HTML is readable for humans, it most likely is readable for Google as well.
• Don’t use meta keywords, it is a waste of time and bytes.

This is part 3 of 5 in my series of Must-Know SEO for Developers. You can find all the parts here.

• Part 1: Avoiding Duplicate Content With 301 Redirects and Canonical Tags
• Part 2: Using Correct URL Structure
• Part 3: Using Correct Meta-tags And Other HTML tags
• Part 4: Internal Linking In Your Web Application
• Part 5: Using Webmaster Tools And Analytics

The main thing to remember with URL’s are to get the keywords in. If you are allowing your users to create dynamic content (fx. CMS pages), make sure to generate the URL string from the title or give the user control of creating a URL.
Another thing Google likes, especially if you have dynamic content and nested categories, is using the URL as a “breadcrumb” structure. A good idea would be to have for example:
/category/subcategory/item
Just remember not to have too long URL’s, and follow the basic rules. Also make sure that nested URL’s like the above are actually related and it is the correct path for the item.
Note: Google is in general really good at understanding breadcrumb structure, but always make it as easy as possible. The above example is both easy to understand for the crawlers and for the human eye.

Another thing to remember when making pretty URL, is that while the robots and browsers in general can read, crawl and understand special signs (fx. ñ in Spanish) it is generally a bad idea to use those in urls. I learned this the hard way, and discover that Google doesn’t encode the url, so if you for example use urlencode()/urldecode() in PHP, you will get different requests from Google and from normal browsers. So remember to always make urls plaintext; no exceptions.

A last thing about URL structure is that you should choose one and stick to that. Make sure that once content has been created, and has an URL (fx. /category/item), they will not change. Make sure that you create the proper 301 redirects if you change the URL structure, and implement the canonical tags as described in the last post.

This is part 2 of 5 in my series of Must-Know SEO for Developers. You can find all the parts here.

• Part 1: Avoiding Duplicate Content With 301 Redirects and Canonical Tags
• Part 2: Using Correct URL Structure
• Part 3: Using Correct Meta-tags And Other HTML tags
• Part 4: Internal Linking In Your Web Application
• Part 5: Using Webmaster Tools And Analytics

• Your “linkjuice” / PageRank-flow is spreading to different pages.
• The Search engines will treat each page as individual and index them as different pages
• In worst case scenario you will get punished and get lower rankings

Duplicate content can be of many variations. Here is a couple of examples:

• www.domain.com and domain.com(could be ANY subdomain like server2.domain.com)
• domain.com/page1 and domain.com/page1/(The trailing slash in the end WILL be seen as different page)
• domain.com/index.php and domain.com/

Luckily for developers, there is many easy ways to fix this. Lately my favourite has been using canonical tags, but you have to be careful with those. 301 redirection is in many cases the best option, and is a MUST if you already have DC problems.
By implementing canonical tag with the full url (fx “http://domain.com/page1”), Google knows that it is the original page, and will stop thinking /page1/ or /page1/?x=y is different pages. But be careful: just a couple of weeks ago, I pushed an update to a site with large amounts of dynamic content. I didn’t notice that I forgot “http://” in my canonical tags, and suddenly I had over 30.000 404 errors in Webmaster Tools, because Google couldn’t find “http://domain.com/domain.com/url”.
Now when shit happens, like in the case above, 301 Redirects is the absolute best way to go. This will pass pagerank on to the original page and redirect both visitors and the crawlers.

So to sum up about Duplicate Content: avoid it. Before it goes wrong. Make sure that all subdomains 301 redirect to your original (or www-version if you use that) – or that you at least have canonical tags implemented. Also make sure to decide if your URL’s should be shown as /content, /content/, /content.html or whatever you prefer. If you do not implement these things your site will most likely get punished. If your competitor is of “evil mind”, and see that you show the same content on all subdomains without canonical tags (common mistake) he can linkbuild to your different URL’s and get your site punished for DC.
(suddenly you might see “looser.domain.com”, “imanass.domain.com” and whatever ranking instead of your original page – that wouldn’t be fun, would it? And worst case scenario, get de-ranking and even de-indexed as punishment for Duplicate Content)

What is your experience with Duplicate Content as a web developer? Do you implement and use 301 Redirects & canonical tags in your projects right from the start? Be sure to leave a comment, and feel free to come with more tips and corrections.

This is part 1 of 5 in my series of Must-Know SEO for Developers. You can find all the parts here.

• Part 1: Avoiding Duplicate Content With 301 Redirects and Canonical Tags
• Part 2: Using Correct URL Structure
• Part 3: Using Correct Meta-tags And Other HTML tags
• Part 4: Internal Linking In Your Web Application
• Part 5: Using Webmaster Tools And Analytics

This is the most basic stuff that can really harm your rankings in search engines like Google. I’ve seen sites drop, get de-index and suddenly triple their visitors from search engines, just based on simple onsite changes. However the worst thing is that many developers out there are basically ruining their clients websites, by not knowing what they do; and implementing potentially harmful codes.
Let’s get on to the list of 5 SEO tips every web application developer must know! Below is links to the different parts of the series.

• Part 1: Avoiding Duplicate Content With 301 Redirects and Canonical Tags
• Part 2: Using Correct URL Structure
• Part 3: Using Correct Meta-tags And Other HTML tags
• Part 4: Internal Linking In Your Web Application
• Part 5: Using Webmaster Tools And Analytics

I am planning to post one part every Monday, with the first part coming next Monday, 5th of September. So stay tuned, and feel free to comment with inspiration, what you think is the most important onsite SEO every web developer should know, and of course if you thing I am wrong, feel free to correct me in the comments.