He noticed that some of the buttons he added to the toolbar, such as those that link to the Sistrix toolbox, no longer worked after upgrading to version 18 of FF. But this problem is not limited to buttons he added to the toolbar, some of the default buttons like the Twitter and Facebook buttons also do not work. They simply do nothing.

He raised the issue with the SEOQuake team but they said they couldn’t reproduce the issue. This made me think that it could be a problem with non-English systems / browsers. So I fired up a fresh VM with Xubuntu I had recently installed and added the SEUQuake add-on to Firefox – which was still at version 16 at that time. Sure enough everything worked as expected – until I upgraded Firefox to version 18. So I am facing the same issue as Oliver on an English install of Ubuntu and Firefox 18.

When clicking on one of the faulty buttons, I get a message in the Javascript console saying:

Did anyone else notice this issue? Or even better, has a solution?

Update (14/Jan/2013):

Today I received a reply to my bug report from a Technical Specialist at SEOQuake:

Thank you for using Seoquake.
Unfortunately, at the present moment we have temporary problems with Seoquake version for Mozilla Firefox 18.0.
I apologize. It’s been brought up to our developers and they’re in the process of fixing it. Meantime, I’d like to advice you to use either earlier version of FF or Google Chrome.

Thank you for your patience and understanding.

So I guess chances are good that a fix will be available soon.

from Problems with SEOQuake Toolbar

Blindfolded Typing Competition – Photo by Foxtongue

What happened?

• In an effort to ‘make search more secure‘, Google has enabled the https protocol for its search engine if a user is logged in to Google.
• To make browsing more secure with Google Chrome they introduced a hard-coded list of sites which should always be opened using the https protocol into the browser. Among them plus.google.com which resulted in a loss of referrer data from Google Plus. This was later fixed by using plus.url.google.com as an intermediate URL.
• Mozilla switched the standard search provider of its flagship browser Firefox to Google’s encrypted search with the launch of version 14.
• Google wants to make the web faster, this is particularly true for mobile devices which are prone to use higher-latency connections.
• Apple switched its mobile Safari browser to use encrypted Google search by default starting with iOS6.

So everything gets faster and more secure, isn’t that great?

Sure, that all sounds great. Unless you’re an online marketer trying to extract some meaning from your analytics data. So many browsers switching to encrypted Google search as a default results in a substantial loss of keyword information. You still know that your visitor came from Google but not what he was searching for – unless you’re buying AdWords ads and this visitor clicked on one of them.

And now it gets even worse: a substantial amount of your “Direct Traffic” are actually iOS6 users coming from a Google SERP.

WTF?

This is the result of two of the above mentioned improvements being combined:

1. Apple deciding to default Safari to Gogles SSL search and
2. Google wanting to speed up the web and therefore optimizing their “mobile” pages for speed.

Why does Google’s speed improvement program affect the referrers? Consider how a link in an encrypted SERP in a desktop browser looks like:

http://www.google.com/url?sa=t&rct=j&q=&esrc...

And now compare this with a result link from a Google search when the client is an iPhone:

href="/url?sa=t&source=web&cd=1...

On desktop browsers the result on an encrypted SERP links to a non-encrypted Google URL (with an empty q parameter, the ‘q’ usually denoted the queried keyword) which will then forward the user to the destination page while serving as the referrer URL.

The iPhone result link is a relative link which has multiple effects:

1. The HTML code of the SERP is smaller resulting in a potentially quicker transmission of the data
2. The intermediate page (/url…) is linked using a relative URL and therefore lies on an encrypted URL which results in no referrer being transferred in requests to non-encrypted URLs. These visitors appear as “Direct Traffic” in your analytics data.

The funny thing about Google’s handling of mobile clients is that they do transmit the keyword if the target URL is also using https.

Is it only iOS6?

No, it’s not. Vanilla Android versions 4.1 and above (AJ Kohn confirmed it’s actually 4.0+), potentially also 4.0, also use encrypted Google Search by default when using the Android search box. The same is true for mobile Firefox on Android. But Google Chrome for Android uses a standard http URL to access Google Search although I am logged in to Google on that browser.

I don’t know how branded Android versions handle these things. I guess it’s not so relevant yet as few providers or hardware manufacturers have rolled out new versions of Android. So right now it affects mostly the Nexus devices and even these do not hide referrer data if Chrome is used to search on Google.

from The missing iOS6 referrer data

Reasons to master basic command line tools are manyfold

• They are available for most platforms. No need to learn a different set when switching from one operating system to another.
• Each of them is quite specialized but they can be easily combined to perform relatively complex tasks.
• Easy to integrate into scheduled tasks

Common characteristics

You’ll read the term Unix various times in this article. It is used as a common term which includes Linux and Mac OS X. The tools mentioned in this article are all published by the Free Software Foundation as part of their GNU project. As they form an important part of any Linux distribution, these systems are often called GNU/Linux systems.

All of the listed commands provide basic help by calling them with the parameter –help. On Unix systems you can usually get more detailed help by typing man <command>. The headings below also link to the corresponding manual page.

Instead of operating on files, most of these command line tools can also operate on standard input which means they can be used as filters and therefore be easily combined.

The Commands

1. ls – list directory contents

The Unix equivalent to the DOS command dir. It can list directory content in various formats and sort orders. Using the -1 switch it can also create a simple list containing just the file or directory names each on a separate line.

2. less – opposite of more

An improved version of more. Helps to browse through long files which would otherwise scroll out of reach. Allows to scroll up or down through a file as well as to search for text using the ‘/’ command.

3. cut – remove sections from each line of files

The title is misleading, cut allows you to select only certain parts of input lines for output. E.g. if your input lines look like this:

lastname,firstname,address,zip,city

you can print out a list of the contained ZIP codes using cut -d’,’ -f4.

4. sort – sort lines of text files

Does what it says. Assuming you run it on the list of ZIP files mentioned above, you’d get a list of ZIP codes in alphabetical order.

5. uniq - report or omit repeated lines

Filter the input so that consecutive identical lines are omitted. Again, if you take a sorted list of ZIP codes and run it through uniq, you’ll get a list of unique ZIP codes.

6. head - output the first part of files

Print only the first 5 lines of the input stream: head -n 5.

Print all but the first 5 lines of the input stream: head -n -5.

7. tail – output the last part of files

8. find - search for files in a directory hierarchy

find is a very mighty command due to its many options. It can search for files in a directory tree filtering by file names, types, modification times, ownership, permissions and more. See the man page for find for more detailed information.

NOTE: Windows users take care not to confuse the GNU version of find with the version that is installed with Windows. The GNU version is much more flexible.

9. gzip - compress or expand files

by simply running gzip with a file name as the only parameter it compresses a file and replaces it with its gzipped version.

Can also be used to compress or uncompress standard input and thereby acting as a filter.

10. tar – Tape archiver

Tar is not only useful for backups to tape but a very versatile archiving utility.

11. grep - print lines matching a pattern

Filters the input (stdin or a file) for lines matching a given pattern and prints only those. May also be used to do the opposite or simply list files which have matching content.

12. wc – print the number of newlines, words, and bytes in files

What should I say? That’s what it does.

from 12 Useful Unix/Linux command line tools – also for Windows or Macs

Martin Missfeldt has created a fantastic infographic depicting Google’s ranking factors as he currently sees them.

Click on the graphic to get to Martin’s original blog post where you can download a bigger version of the infographic for printing and pinning it on your wall.

I especially like how he shows the assumed relationships between the ranking factors and their hierarchical nature. As much as I like Martin’s work, I still have some comments on it

• I think that Trust and Authority are heavily influenced by incoming links which is not visible in the graphic.
• While I am sure that the CTR in the SERPs is taken into account for ranking a page, I am unsure about the “Time on site” and “Bounce rate” factors. Without using Analytics data, Google can only measure the bounce rate by counting users who come back to the SERP shortly after having clicked a result. So bounce rate basically is the same as a short time on site. An indication of this is that on some Google properties, e.g. google.de, you can mark pages as “not helpful” when you drop back to the SERP too soon.
• Freshness is quite a small bubble on Martin’s graphic. But Freshness especially is a factor which – in my opinion – has a huge influence on all ranking factors. The ranking of a newly published page will be heavily determined by onpage factors and trust and authority of the site. Then the social factors will kick in and in the long run backlinks will be needed to rank well. Maybe Martin will come up with an animated version that shows growing and shrinking bubbles

Anyway, the illustration will be printed and pinned onto the wall.

What do you think of this overview? Would you like to see something added? Or have the weightings changed?

SEO Image Ranking Factors

from SEO Ranking Factors 2012 – Infographic

To run it follow these steps:

1. Unzip the archive into a directory of your choice
2. Modify config/wmt.properties to match your needs
3. Run either run.sh (you’ll need to make it executable) or run.bat

Using the -m or –lastmonth command line option the tool will only export the data for the last calendar month.

The files will be downloaded to the directory you defined in the properties file. By default it will download all types of search query data. If you want to reduce the amount of files being downloaded, change the list of download types in DownloadFiles.java and recompile.

I tested it on Ubuntu 11.10 and Windows 7.

Download

from Java tool to download search query data

UPDATE: I created a Java version of the Search Query downloader. Any feedback would be great.

The two examples included provide a simple script to download search query data for the last month into a CSV file and another to create a Google Docs spreadsheet containing that data.

The required steps to run the scripts are documented in the Project Wiki, assuming you’ve got Python running already. The ‘selected_downloads’ variable may be extended to include the TOP_PAGES alongside the TOP_QUERIES in the download:

selected_downloads = ['TOP_QUERIES', 'TOP_PAGES']

Downloading data for all your sites

To download the search query data for all sites I have in my Google Webmaster Tools account I changed the example script as follows:

# Instantiate the downloader object
downloader = Downloader()
# Authenticate with your Webmaster Tools sign-in info
downloader.LogIn(email, password)

# Get the list of sites available
sites = downloader.GetSitesList()

# Initiate the download
for site in sites:
  print site.title.text
  try:
    downloader.DoDownload(site.title.text, selected_downloads)
  except ValueError:
    print "No JSON data"

The function GetSitesList() needs to be added to downloader.py:

  def GetSitesList(self):
    stream = self._client.request('GET', self.SITES_PATH)
    sites = wmt.SitesFeedFromString(stream.read())

    return sites.entry

with SITES_PATH being defined as

  SITES_PATH = '/webmasters/tools/feeds/sites/'

Additionally gdata.webmastertools needs to be imported, so add this line to the list of imports at the beginning of the script:

import gdata.webmastertools as wmt

from Downloading data from Google Webmaster Tools

If you like Links

Curious as I am, I had to read that article by Adam Singer. In essence, the author complains about Facebook because they are trying him to force an app just to see an article on the Guardian.

Is the Social Network misguiding its users?

This is not correct. Sure, Facebook is clever, but they are not the ones to blame for this link hijacking. At first, Singer seems to get it right:

However, due to how The Guardian has configured their site’s Facebook integration, anyone clicking the link is not taken to the expected URL. Instead a user is taken to this page to authorize use of The Guardian application

But then he repeatedly accuses Facebook of diverting his link:

To access this story elsewhere was ridiculously easier than in Facebook (I originally found it via Twitter). It was just one click, of course. That’s how the web works. But within Facebook’s system and the need to add an application (and share detailed information / yield rights to a third party) this is just obnoxious.

All this does is leaves a bad taste in my mouth and basically motivates me to take my sharing elsewhere. Because who wants to share content in a platform that adds complexity and brings your network to something you did not intend to share?

His last question should rather be: “Because who wants to share content which is on a web site …”

I fired OWASP‘s ZAP Proxy to analyze the HTTP traffic going on between my browser and the internet when I click on a link to a Guardian article on Facebook. And sure enough I saw what I was expecting. The usual forwarding technique as recently analyzed on Google+ is used to forward the user to the Guardian web site.

What happens then is that the Guardian web site checks if the user comes from Facebook using the referer header field and if this is the case the browser is told to redirect to the Guardian’s Facebook app which of course first needs to ask for permission.

Who’s to blame?

Quite clearly this is the Guardian who tries to force its readers into using their Facebook app if they determine a user’s click source is Facebook. Given that their app uses Facebook’s “frictionless sharing” capability which automatically updates a user’s contacts with what she reads this has quite a viral potential. The numbers which are disclosed in a comment to the article by Martin Belam who has worked on the Guardian Facebook app are quite impressive:

Since launch the app has been installed over 4 million times, added about 1m page impressions a day to our traffic, and over 56% of those installations are by people aged 24 and under. They are a demographic that news organisations have found very difficult to reach.

The Guardian seems to have decided that the price they pay, namely annoying readers by hitting them in the face with the question to use their app, is ok to pay for the increasing number of readers and app users.

To be fair, the Guardian only asks once (per browser). If the user indicates she does not want to use the app by clicking ‘Cancel’ the app sets a Cookie called ‘GU_FB’ with a value of ‘false’ and a lifespan of one year.

from Facebook falsely accused of hijacking Links

© Doug Wheller

Google recently announced a new way to tag content on multilingual / multi-regional web sites using the hreflang attribute in a rel=”alternate” link tag. A classic example for this would be Spanish language content for the US, Mexico and Spain. Assuming each of these geographical regions would have a separate site we might have similar content on www.brand.com/es/, www.brand.mx and www.brand.es.

Ideally, a Spanish speaking searcher in Spain would see search results only from www.brand.es while someone in Mexico should see results from www.brand.mx. In reality the SERPs will contain a mix of results from both if not all three sites. One way to show only one of these results in the results is the use of the canonical tag, so in our example we could define the version on www.brand.es to be the one and only version so this will be the only one of our Spanish-language sites showing up in the SERPs while simultaneously collecting all the link juice.

The drawback to that approach is that Spanish speaking searchers will be directed to the site intended for Spain, no matter where they are. To get us out of this dilemma Google has introduced the hreflang attribute in relation to the rel=”alternate” attribute for the link tag. The example page at hand could be tagged as follows:

<link rel="alternate" hreflang="es" href="http://www.brand.es/" />
<link rel="alternate" hreflang="es-US" href="http://www.brand.com/es/" />
<link rel="alternate" hreflang="es-MX" href="http://www.brand.mx/" />

This way searchers will see www.brand.es in the search results but will be redirected to the site that best matches their browser settings. As in this example all alternate regional versions are written in the same language and therefore are probably pretty identical in content, the canonical tag should be used additionally:

<link rel="canonical" href="http://www.brand.es/" />

Use for Truly Global Brands

But what if you want to roll out your site globally to many markets? You might end up with sites for 80 countries in 100 regional variations. It surely is not a good idea to list 100 alternate URLs in the HTML or HTTP header (Yes, the alternate URLs can also be defined in the HTTP header for non-HTML content).

In such a case I’d build clusters of similar sites, such as Spanish language sites, French language sites, Russian language sites, etc. and have them link to each other within their language realm. Sites like Swiss or Belgian ones will have a different set of alternate links depending on which language area you are in plus the relevant other languages. The ideal tag set for the URL www.brand.ch/de/beispiel might be:

<link hreflang="fr-CH" href="http://www.brand.ch/fr/exemple" rel="alternate"/>
<link hreflang="it-CH" href="http://www.brand.ch/it/esempio" rel="alternate"/>
<link hreflang="de-CH" href="http://www.brand.ch/de/beispiel" rel="alternate"/>
<link hreflang="de-AT" href="http://www.brand.at/beispiel" rel="alternate"/>
<link hreflang="de" href="http://www.brand.de/beispiel" rel="alternate"/>

This might then be combined with a canonical URL set to the last URL listed.

How you set up such a construct in your CMS is another matter.

What do you think? Is that useful? Feasible? Completely insane?

from Best Practice for tagging Global Multilingual Web Sites

Today I read a notice on the Google Chrome releases blog about a new development release of Chrome 17. One of the changes caught my eye:

Support for <meta name=”referrer”>

A “referrer” meta tag? And look! It’s spelled correctly! This is amazing, but what does it do?

I found this information on the WHATWG wiki page about the proposed tag:

Using the referrer metadata attribute, a document can control the behavior if the Referer HTTP header attached to requests that originate from the document.

Which I would understand as a way for the page author to define if referrer information should be sent to the target web site. Possible values for this meta tag are:

• never
• always
• origin
• default

While ‘never’ and ‘always’ are pretty clear, I’d like to explain the other two. ‘default’ is meant to work the same as today which means the browser does transmit the complete URL of the document which is the origin of the request (i.e. the URL of the web page on which the user clicked a link) unless the origin is using Transport Layer Security, more commonly known as ‘SSL encryption’ and the target is not. Here are the rules for ‘default’:

• http -> http : Referrer is transferred
• http -> https : Referrer is transferred
• https -> http : Referrer is set to blank
• https -> https : Referrer is transferred

If the value of the ‘referrer’ meta tag is set to origin, the user agent will send an ASCII serialization of the origin, basically a combination of the protocol, the hostname and the port, e.g. http://www.webkruscht.com, as defined in the Web Origin Concept. 

Setting this ‘referrer’ meta tag to ‘origin’ basically results in only revealing the site a user comes from to the target site, without ‘leaking’ any more information. Google already does a similar thing if you use their encrypted search or click on links from Google Plus. The introduction of this tag puts the decision to transfer the referrer data in the hands of the web master. Which is a good idea I think as the owner of a site should be able to decide if any harm could be done to his users if the referrer is transmitted completely.

Looks like we can expect this meta tag to be processed as defined in the next version of Google Chrome.

from More news on Google Chrome and the HTTP Referrer

An example would be a user who always logs into Facebook using the same two devices from IP addresses located within a small area. If someone tries to log in using his account details from a previously unknown device (one without Facebook long-term cookie ‘datr’) from an unusual place, e.g. from Lagos, Nigeria instead of Wichita, Kansas, then this raises some alarms in Facebook’s systems. In such a case the user will still be able to log in, but only if she’s able to solve some ‘social captchas‘.

Having their ‘datr’ cookie justified this way could also allow Facebook to fulfill section 66 of the EU directive 2009/136/EC, the so-called ‘EU Cookie Law’ which states:

(66) Third parties may wish to store information on the equipment of a user, or gain access to information already stored, for a number of purposes, ranging from the legitimate (such as certain types of cookies) to those involving unwarranted intrusion into the private sphere (such as spyware or viruses). It is therefore of paramount importance that users be provided with clear and comprehensive information when engaging in any activity which could result in such storage or gaining of access. The methods of providing information and offering the right to refuse should be as user-friendly as possible. Exceptions to the obligation to provide information and offer the right to refuse should be limited to those situations where the technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user. Where it is technically possible and effective, in accordance with the relevant provisions of Directive 95/46/EC, the user’s consent to processing may be expressed by using the appropriate settings of a browser or other application. The enforcement of these requirements should be made more effective by way of enhanced powers granted to the relevant national authorities.

(Emphasis mine)

As users explicitly request Facebook’s service and Facebook claims that setting the long-term identifying cookie is required to keep the service secure it could be allowed for Facebook to legally set the cookie without asking the user for permission. Two birds with one stone. Clever, isn’t it?

from How Facebook might comply with the EU Cookie Law