SEM Wired

We all know WordPress is one of the most versatile and easy to use CMSs, with plenty of features which made him one of the best blogging platform available on the market. However it still lacks and adequate support for multilingual blogs, for instance when we’d need ot post the same article in more than one language at the same time.

If the CMS itself does not provide enough support for this feature, we can sort thing out pretty easily with a few plugins:

• Google Ajax Translation, this Google API makes available translation to users on your blog frontpage. It is not to be considered a proper WordPress plugin but it works just as good.

• WPML Multilingual CMS, with this plugin we would be able to get a fully working multilingual blogs in just a few minutes. No need of any change inside the source code or tables, it works straight out of the box.

   

• qTranslate, with this plugin we would be able to manage content in different languages from the WordPress editor, through automatic translation and permalink management.

Robots.txt has got its own system of codification for content, which does not allow any text codification different than US-ASCII.

According to the URI specifications, only the US-ASCII character set has to be used in order to define URL’S. This very point can create quite a lot of trouble for webmasters trying to set up their own robots.txt with a different set of characters.

ASCII’s 128 characters only covers the English alphabet, numbers, and punctuation marks, making impossible to control search engine behaviour when some “weird” characters are used into folder codification, like ñ in Spanish and ç in French, which are left out of ASCII.

Most characters in non-Latin-based alphabets, such as pi (π) in Greek, ya (я) in Cyrillic, and entire alphabets from many other world languages, can’t be accurately written in the limited, English-oriented ASCII.

robots.txt file codification is the following:

• ANSI (Windows-1252)
• Unicode
• UTF-8

The file however supports following codifications for its content:

• ANSI (Windows-1252): 8 bit
• ASCII: 7 bit
• ISO-8859-1: 8 bit
• UTF-8: 8 bit

Let’s take the case of a russian website, using Cyrillic codification for its folders and directories. In this case, characters like π or я should be correctly encoded into US-ASCII.

Percent-encoding comes into play, making possible to encode a non-ASCII string into a set of characters which can be perfectly read by search engines.

Let’s consider a russian website with a admin folder we do not want search engine to crawl:

http://www.domain.com/папка/

In order to avoid search engines crawling the admin folder, the folder’s name should be encoded as following:

Disallow: /%D0%BF%D0%B0%D0%BF%D0%BA%D0%B0/

…while the following line won’t work, since directory specifications into robots.txt must be always encoded in US-ASCII:

Disallow: /папка/

You might also want to read this article from the Bing Community, which explains the issue.

A news realase of WordPress has just been made available and is supposed to fix several security flaws, as explained here on the WP blog.

WordPress got so popular that any security update can actually be crucial, considering the amount of websites using it. Recently a well-known vulnerability allowed a worm to spread around affecting several blogs, according to this article. Still, there’s something more we can do to make our WordPress installation safer.

The WordPress Exploit Scanner extension can scan for well-known vulnerabilities and exploits which might affect your WordPress installation. In order to be used you just need to download, the extension, upload it on you server, active it by the extensions dashboard and a link will pop-up on your general dashboard.

Once you run the extension (it might need a few minutes to complete the task) the report you get is extensive. The plugin analyse in depth every single file, looking for malicious code embedded into standard file. It’s pretty useful, even if a standard report can require some programming knowledge to be fully understood. It’s a very neat tool, I guess it should be included in every WordPress standard setup.

Page loading time is a crucial factor when it comes to estimate page’s usability as well as search engine’s rankings and Google’s Adwords quality score.

according to this statement, Google is going to update its assessment policy . Page load time it is soon due to become an important factor requiring specific assessment and optimization from webmasters and SEOs.

In order to calculate page loading time, you might try Pingdom. Pingdom is an online utility which calculates pages text, images and scripts, giving you also some interesting suggestions about improvement.

However, besides any Google statement about quality score or rankings, it’s always good to think about you user’s experience on your website: nobody likes websites taking too long to load.

Considering both usability and rankings, this should be some general guidelines to be followed one assessing and optimizing page’s loading time:

Text and page structure should load and be completely visible within the first 3 seconds
Any other element of the page must be visible within the first 8 seconds

These are only thumb rules of course. Always cehck your page weight and loading times. Working on this side of on-page optimization can lead to interesting discoveries sometimes.

A new search engine has just been launched and it’s time to update our analytics software.

Google hasn’t released any major update to automatically recognize traffic coming from Bing into Google Analytics but I guess it is not gonna take too long.

In the meantime we can easily tweak Google Analytics just playing around with our tracking code.

In order to add Bing as a search engine we need to use the addOrganic function: _addOrganic[domain, search query]

AddOrganic Function: how it works

The addOrganic function has two parameters:  domain and search query. It basically tells the Analytic engine to consider some referrals as proper search engines, hence appearing on keyword statistics.
This two parameters are embedded in every search query we forward to a search engine:

Google:

http://www.google.com/search?q=[searchquery]

Yahoo:
http://us.search.yahoo.com/search?p=[search query]

So let’s take a look to a standard Bing query:
http://www.bing.com/search?q=[search query]

As you can see, the right AddOrganic sintaxy would be the following:

pageTracker._addOrganic("bing.com", "q");

We just need to add this line right before the trackpageview() call into our Analytics code.

I think there’s an obvious update on the way but if you are already getting some decent organic traffic from Bing just add this line and see what happens.