SEO News

From a SEO’s perspective, which of Google’s changes in 2013 have you least appreciated?

Julia Logan, Irish Wonder: 

Where Google is going with the Knowledge base. It is simply becoming a scraper, and on top of that it cynically advises the website owners to produce more great content.

Yeah right, so Google has something to scrape.

Dr Pete Meyers, Marketing Scientist at Moz: 

Again, [not provided]. Easily.

Andrew Girdwood, Media Innovations Director at LBi: 

I dislike the 100% not provided and the communication around it. Google’s claims of ‘for privacy’ are too easily dismissed until you begin to speculate what other information Google might want to include in search results.

For a company that once claimed to want to help with the world’s information it seems a pleasant move would be to pass keyword data through their improved privacy.

It could investigate a redirect link with a keyword loaded query string on it, for example. Google has established, with its PPC policy, that keyword data is not a privacy breach.

Will Critchlow, Founder and CMO at Distilled: 

For immediate impact, (not provided) is my least favourite change. Keywords aren’t everything by any means, but they are useful and the public explanations given are just so disingenuous.

If it really meant the explanation given about privacy, they not only wouldn’t be giving up paid keyword data, but also could have found a sensible middle ground of what to share instead of removing it all.

Directionally, I’m also very much not crazy about the UX changes to image search which seek actively to prevent searchers from visiting the sites that contain the images.

I see this as breaking the implied agreement whereby sites allow Google to crawl their sites in exchange for getting traffic when that crawl discovers a good result.

Richard Baxter, CEO at SEOGadget: 

Well, I think Panda’s increasing aggressiveness has largely been ignored since Penguin came along. I’ll choose that update, but I actually appreciate it.

It’s an interesting update to work with – when you get really deep into technical work, particularly into the log files of affected sites you can really see why there’s a problem. The trick is to compare before and after.

What you find with log files is that they tend to confirm what most SEOs just say because they think it’s best practice. Very ‘thin’ pages with little unique content tend to encourage weird crawl behaviours.

For example, much less of the page (total size vs content downloaded) is downloaded by Googlebot than say, a content rich, really developed page. So, as much as I don’t appreciate my job being harder, I certainly appreciate it being more interesting!

What do you expect/hope to see in 2014?

Julia Logan:

I dream of a strong competitor rising so we all have some choice, as searchers, site owners and SEOs. This probably won’t happen very soon, maybe not in 2014, but can I dream?

Dr Pete Meyers:

I suspect a strong shift to a more card-based search result, akin to Google Now, Google+, and mobile search.

Google wants to mix and match information seamlessly, regardless of how you consume it. I believe we’ll see a Knowledge Graph expansion based on Google’s index – in other words, it’s going to extract ‘knowledge’ directly from websites more and more (and not just a small set of big databases).

I hope it’ll open some data back up and become more transparent, but I don’t expect it.

Kevin Gibbons, UK MD at Blueglass:

Bigger and better marketing campaigns. Less focus on tactics, and more integrated strategy across multi-channels.  

We’ve certainly seen a shift ourselves towards a more consumer-led and customer centric strategy, looking to improve the overall user experience across multiple channels and devices.

Focusing much more on the bigger picture and being rewarded by Google as a result – as opposed to more tactical bursts of campaigns.

Andrew Girdwood:

Hope and expect are very different. I hope to see keyword data made better in Webmaster Console along with easier data extraction from the console. I doubt we’ll get that. 

I expect to see more chat around Google+ and for Google to fuel that. I predict more SEO teams will spend more time talking about ‘signals’ rather than just ‘links’.

I fear we’ll see trouble when it comes to the difference between editorial and advertorial. The difference does not seem to be widely understood by very many bloggers and digital publishers.

Whether it’s in-house teams or SEO agencies doing the outreach doesn’t seem to matter but too many brands seem too happy either play to those misunderstandings or actively encourage them.

Will Critchlow:

I expect to see some innovative YouTube ad formats that could set it on the way to becoming a real brand-building platform for the web and see it claim a significant chunk of brand advertising spend.

[Coupled with this, I think we will see a subtle shift away from UGC and towards professional content on YouTube – it could become the equivalent of free-to-air TV versus Netflix’s cable equivalent].

I think Dr. Pete is spot on in his predictions of what we will see on the UI front.

I expect to see some live experimenting with more social ranking factors, particularly in the fresh results.

Teddie Cowell, Director of SEO, Mediacom:  

I expect to see a lot happening around interaction, with search results appearing in more places where we haven’t previously seen them – think of the Android 4.4 Kit Kat contacts list as a current example of this.

I hope to see some controls mechanisms in place for Knowledge Graph. There have been a few to many factual inaccuracies; and some highly embarrassing ones, so currently it feels like Google is playing with fire in regards to what the Knowledge Graph says.

With particularly regard to brands, which by their nature as recognised entities are more likely to trigger the Knowledge Graph, it’s very dangerous territory, because coincidentally they are also some of Googles most valued advertisers.

Richard Baxter:

Spammy SEO to be gone. Google keep saying it’s getting better at tackling the bad stuff but there are still plenty of examples around – it’s a case of ‘do what you said you’d do’ – and not giving very poor quality SEO agencies any more fuel by way of case studies on their bad, temporary tactics.

It would make it much easier to get the message across that the good guys do a good job and that SEO is a credible, technical and content marketing discipline that is very much here to stay.

Jimmy McCann, Head of SEO at Search Laboratory:

Improved accuracy in the Webmaster Tools link examples that are given under manual action. These have been automated and incorrect in the past – which is a pain.

It would be better if the examples were more explicit and told you exactly what was required to sort out the penalty.

Adam Skalak, Head of SEO at iCrossing: 

The most significant shift for SEO is that we are no longer limited by keyword phrases. Google’s 2014 expansion of its semantic-search offering, the Knowledge Graph, offers both opportunities and challenges for brands.

Established brands will benefit from greater exposure in more prominent parts of the results pages. But with Google providing answers directly at the top of the page, brands may struggle to increase their organic traffic as this could remove the need for people to click through to their site at all if they don’t need too much detail.  

Posted by randfish

Homepages were once the ultra-authoritative one-stop shops of online brands. As people and search engines have become better at understanding what users are looking for, though, the purpose of homepages has become more targeted. In today’s Whiteboard Friday, Rand details several of the changes we’ve seen, and offers his advice for what to include on a truly effective homepage on the web today.

For reference, here’s a still of this week’s whiteboard!

Video transcription

Video transcription by Speechpad.com

Sign up for The Moz Top 10, a semimonthly mailer updating you on the top ten hottest pieces of SEO news, tips, and rad links uncovered by the Moz team. Think of it as your exclusive digest of stuff you don’t have time to hunt down but want to read!

Posted by deedpolloffice

This post was originally in YouMoz, and was promoted to the main blog because it provides great value and interest to our community. The author’s views are entirely his or her own and may not reflect the views of Moz, Inc.

It’s been two years now since Google announced that they’d be gradually withholding the search terms from referer headers, as secure (SSL) search was rolled out. This has meant that the keyword report in Analytics shows (not provided) for most visitors.

In our own Analytics reports, (not provided) keywords now make up 82% of all organic visitors.

For paid traffic (coming through AdWords) the keywords are still “provided,” which is very helpful, but also very expensive.

And of course there’s also the Search Queries report in Webmaster Tools. This is also useful, but it’s still a disappointing loss of information compared to what we used to have (even if I personally think Google was probably right to go ahead with it).

The ved parameter to the rescue

Back in May, Tim Resnik wrote about patterns he’d spotted in Google’s ved parameter. It turns out that ved codes contain rather useful information about the link that was clicked on in the search engine results page. And as Tim pointed out, this goes some way in replacing what was lost (or rather, killed off) by Google taking away the keyword data.

Three months later, Benjamin Schulz worked out that ved codes are actually encoded in Protocol Buffers (or “Protobuf”). So, as they’re not actually encrypted, it’s not too hard to unencode them (plus we don’t have to feel too guilty about it!).

Google has even released open-source compilers (in several different languages), which you can use to decode ved codes yourself. However these compilers are probably a bit over-the-top for what online marketers need (and probably a bit hard to put into practice).

We’ve written up a guide to decoding and interpreting ved codes—as well as filling in some of the unanswered questions (such as what parameter 1 means). And we’ve also written a JavaScript function for decoding veds, which—as I want to explain—is essential if you want to incorporate this information into your own Analytics reports.

This article is an actionable guide to getting information out of these ved codes, and incorporating it into Analytics.

What is a ved code anyway?

I don’t want to repeat too much what has already been written about in other posts, but it’s a good idea to summarise what veds are, what’s inside them, and how you can access them.

When you click on any of the links in Google’s search results, the URL (address) of the link contains a “ved” parameter.

This “ved” code contains information about the link that you clicked on, and when a user comes to your website through Google’s search results, the ved code is (usually) passed to you in the referer HTTP header.

What’s inside a ved code?

A ved code contains up to five separate parameters, which each tell you something about the link that was clicked on:

Link index (parameter 1)

All the links on the SERP have a numerical index, which gets passed in the ved code.

It only gives you a very rough idea of where the link was in the page (without knowing more about what was on the page), so it’s the least useful of the five parameters inside the ved.

However, it is rather useful when it’s for a ved code coming from an adword, simply because there’s no other information about the position.

Although the link index only gives a rough idea of the position of the adword, there are two concrete things you can take from it:

• If it’s about 45—65 or less (shopping results could go up to 85), then it means the adword was in the main column above the organic results
• If it’s about 170 or over, then it means the adword was in the right-hand column or at the bottom of the page

Link type (parameter 2)

This parameter is a number which corresponds to the type of link that was clicked on.

The most common value is 22, which corresponds to a normal (universal) search result.
Other common values (and their meanings) are:

See the complete list, for other (less common) values.

We’ve actually found well over a hundred distinct values, so this is a small fraction of them! Most of them, though, are very unlikely to appear in referer URLs (bear in mind that these are Google’s parameters; they weren’t really meant for us).

You’ll no doubt have noticed that there are lots of gaps in the values. I don’t really know if this is because a lot have been retired, or if Google has left space for future link types (probably a bit of both, but more of the latter). For example, our reports show the link type 703, but we haven’t worked out what it means yet. It seems like it’s some sort of universal search result just for mobile devices. If you see 703 or other codes in your reports, and you have an idea what they mean—write a comment below, or submit a pull request.

Start result position (parameter 7)

This parameter is the cumulative result position of the first result on the page. On page 2 it will be 10, on page 3 it will be 20, and so on.

It’s better to think of this as the page number of results (after subtracting 1, and multiplying by 10)—because it’s quite a long time ago now that there were always 10 results on every page. Anyhow, you’ll need to interpret it in conjunction with parameter 6.

Result position (parameter 6)

This is very similar to the cd parameter, but there are a few important differences:

• cd is counted from 1 (and upwards), whereas the ved result position is counted from 0.
• On page 2 of the results, cd keeps on counting (i.e. 11, 12, 13…), but the ved result position is reset to 0.
• Sometimes the cd parameter is not passed (e.g. for image thumbnails). In these cases, though, the ved result position does seem to get passed.

The ved result position is the more reliable of the two. If, for example, the cd parameter is 11—you wouldn’t know if this is the 11^th result on page 1, or the first result on page 2. With the ved result position, you can distinguish the two.

Sub-result position (parameter 5)

This parameter is like the result position (parameter 6), except it tells you the position in a list of sub-results, such as breadcrumbs, or one-page sitelinks.

How to decode ved codes and pull the information into Analytics

To import the ved into Analytics, you’ll need to include some Javascript to decode it (and send it to the Analytics servers).

To do this, you can modify your Analytics JavaScript “snippet” as follows:

1. Include the ved-decode and base64 libraries

You need to include these libraries in your HTML, somewhere before your Analytics snippet.

The ved-decode library is needed to decode the ved and extract the information we want.
The base64 library is needed for Internet Explorer users, because they won’t have a native Base64 decoder available in their browser.

Each of the two libraries is licensed under a permissive open-source licence (MIT / Apache v2.0)—which lets you use it in any kind of project.

<!-- Include both these scripts or copy them into your main JavaScript file -->
<!--[if lt IE 10]>
    <script type="text/javascript"
        src="http://veddecode.opensource.dpo.org.uk/js/base64-1.0.min.js"></script>
<![endif]-->
<script type="text/javascript"
    src="http://veddecode.opensource.dpo.org.uk/js/ved_analytics-1.0.min.js"></script>

2. Send the ved data to Analytics

How you do this depends on whether you’re using the old Analytics (ga.js) code, or the new Universal Analytics (analytics.js) code:

If you’re using Analytics (ga.js)

Add this JavaScript code just before the call to _gaq.push(['_trackPageview'])—

    // The custom variable code needs to go *before* you record the pageview
    // (i.e. the call to _trackPageview)
    (function(w) {
        var customVars = [
            { slot: 1, name: 'Google link index',          v: 'linkIndex'         },
            { slot: 2, name: 'Google link type',           v: 'linkType'          },
            { slot: 3, name: 'Google result position',     v: 'resultPosition'    },
            { slot: 4, name: 'Google sub-result position', v: 'subResultPosition' },
            { slot: 5, name: 'Google page',                v: 'page'              }
            ];
        if (w._gaq && w.VedDecode && w.VedDecode.ved) {
            for (var i = 0, val; i < customVars.length; ++i) {
                val = w.VedDecode[customVars[i].v];
                w._gaq.push([
                    '_setCustomVar',
                    customVars[i].slot,
                    customVars[i].name,
                    val ? val + '' : '(not set)',
                    2 // session scope
                    ]);
            }
        }
    })(window);

If you’re using Universal Analytics (analytics.js)

For Universal Analytics you need to set up custom dimensions corresponding to the five parameters:

(These are suggested names, of course—you can call them whatever you like.)

Then add this JavaScript code just before the call to ga('send', 'pageview'):

    // The custom variable code needs to go *before* recording the pageview
    (function(w) {
        if (w.ga && w.VedDecode && w.VedDecode.ved) {
            // Send pageview with custom dimension data
            ga('set', {
                dimension1: getVedValue('linkIndex'),
                dimension2: getVedValue('linkType'),
                dimension3: getVedValue('resultPosition'),
                dimension4: getVedValue('subResultPosition'),
                dimension5: getVedValue('page')
                });
        }
        function getVedValue(key) {
            var ret = w.VedDecode[key];
            return ret ? ret + '' : '(not set)';
        }
    })(window);

Make sure that the index generated for each dimension in your control panel corresponds to the dimension number in the JavaScript code.

For example, if the generated index for the Google link index dimension is 7, then you need to refer to it as dimension7 in the code.

Using the data

After a short while, the ved data should show up in your reports!

How you then use the data is up to you.

Clearly, though, it’s going to be useful for optimizing different routes to your site, and looking at how different routes affect your conversion rates.

Personally, I think it’s very interesting—for AdWords customers—to see how adword position (i.e. link index) affects conversion rates. It’s very frustrating only having daily averages to work with, because you can’t see (in the standard reports) how much your adword position varies during the day.

Please let us know what you do with the data in the comments below.

But what if no referer header gets passed?

This is important, because if there’s no referer header, then there’s no ved parameter.

The referer won’t get passed in some cases:

If your site isn’t secured by HTTPS

If your site uses HTTP, or it uses HTTP for some pages (in particular, any landing pages), then the referer header may not get passed. Sometimes—even if a user is using secure (HTTPS) search—Google redirects them through a (non-secure) intermediate HTTP click-tracking page. When this happens, you’ll get the referer (and the ved parameter).

However, if Google passes them through a secure (HTTPS) click-tracking page, then you won’t get the referer (or the ved parameter) unless your site is also using HTTPS.

In conclusion—if you want to be sure of getting the ved parameter for as many users as possible—use HTTPS for your site. (Of course this isn’t the only reason to use HTTPS!)

If the user is on a mobile device

For mobile devices, Google has started to use hyperlink auditing—which should have been called “click tracking”, and is better known as the “ping” attribute—instead of redirects through a click-tracking page. Hyperlink auditing isn’t as reliable as a redirect, though, which is why:

• Google only use it for mobile devices
• all paid results (e.g. adwords) still go through traditional redirects

According to Google, the main motivation for using the ping attribute (only) on mobile devices, is to improve speed—and I’m inclined to believe them. But it probably also helps that:

• mobile users are probably less likely to turn hyperlink auditing off (or know how, or know what it is)
• mobile devices run modern browsers, which support hyperlink auditing

However—you might ask—if mobile devices don’t go through a redirect, and my site is using HTTPS, shouldn’t I get the referer anyway?

Yes, that’s right, you should get the referer!
But sadly, Google has specifically disabled it.

What Google do, if they use hyperlink auditing, is to set the meta referrer element to origin:

    <meta name="referrer" content="origin">

This instructs the user’s browser to include the document’s origin in the referer header rather than the full URL of the document. So the referer will just state (something like) <a href="https://www.google.co.uk/">https://www.google.co.uk/</a>.

Before you think, “How evil!”—there’s a good reason for this. If they didn’t do this, then the search terms would also appear in the referer, and Google has committed to turning this off for privacy reasons.

So, mobile devices are another kettle of fish, and ved code analysis won’t work most of the time. But for most sites, mobile devices will still be in the minority, and things change quickly anyway. (For example, if there was a new anti-privacy law requiring hyperlink auditing to be off by default, that would certainly be the death of it.)

Sign up for The Moz Top 10, a semimonthly mailer updating you on the top ten hottest pieces of SEO news, tips, and rad links uncovered by the Moz team. Think of it as your exclusive digest of stuff you don’t have time to hunt down but want to read!