Google’s Pierre Far confirmed that this is indeed a brand new feature built to help webmasters debug their sitemap files prior to submitting them. One of the most common complaints about Google Sitemap files is that Webmaster would create them but not be able to know right away if they were valid. Now, Webmasters can create the sitemaps and test them in Google Webmaster Tools prior to submitting them to Google.

To test the sitemap files, simply login to Google Webmaster Tools, click on Site Configuration and then on Sitemaps. At the top right, there is an “Add/Test Sitemap” button.

After you enter the URL, click submit and Google will begin testing the sitemap file immediately.

When the test is complete, you can click a button to go see the test results.

I am told Google also added a few more features to Webmaster Tools, some we covered already, such as changing the average position calculation and new download options.

Google has now added a blog post on all these new items.

Related Stories:

• Google Changes Definition Of Average Search Ranking Position
• Google Webmaster Tools Adds Useful Download Options
• Google Analytics Webmaster Tools SEO Reports Now Available
• Google Analytics To Add Search Query Data From Webmaster Tools
• Keyword “Not Provided” By Google Spikes, Now 7-14% In Cases
• Google Webmaster Tools Search Queries Report Now Less Accurate
• Google Webmaster Tools Adds Useful Download Options

I saw reports over the past week or so of webmasters commenting about their rankings. Most were complaining that they lost rankings, but some said sites that were originally hit by Panda regained their traffic levels pre-Panda. This would explain the data refresh, where Google ran the algorithm and updated the sites that should or should not have been touched by Panda.

Google Panda 3.2

Google said this happened about a week or so, so I would place this Google Panda 3.2 update as happening on January 18, 2012.

Why 3.2 and not 2.x? Well, I spoke with a Googler back in late November, they expressed that one of the 2.x updates we labeled as a “minor” update, should have likely been named as a major update and thus labelled a 3.0 update. I personally believe that was an October Panda update, that we did not cover here, but I do not have confirmation on that. In fact, Google does not number their updates, so it is hard to nail down.

The 3.1 update was likely the the minor update from November and now this being a basic “data refresh,” we’d label this as a minor update as well, and call this the 3.2 update.

There was a long gap between this update and the update from November because Google promised us no Panda updates during holidays.

Previous Panda Updates

Here’s the Panda update schedule so far, as we’ve tracked and had confirmed by Google:

• Panda Update 1.0: Feb. 24, 2011
• Panda Update 2.0: April 11, 2011 (about 7 week gap)
• Panda Update 2.1: May 10, 2011 (about 4 week gap)
• Panda Update 2.2: June 16, 2011 (about 5 week gap)
• Panda Update 2.3: July 23, 2011 (about 5 week gap)
• Panda Update 2.4: August 12, 2011 (about 3 week gap)
• Panda Update 2.5: September 28, 2011 (about 7 week gap)
• Panda Update 3.0 : ~October 19, 2011 (about 3 week gap)
• Panda Update 3.1 : November 18, 2011 (about 3 week gap)
• Panda Update 3.2 : ~January 18, 2012 (about 2 month gap)

We are waiting to hear back from Google on exact dates and will update our story with those dates if and when we hear back. But Google has indeed confirmed a Panda data refresh as a week or so ago.

Related Articles

• Taking a Closer Look at the Google’s Panda 2.5 “Flux”
• They’re Back! Google Issues Weather Report For Panda Update
• Google Panda 2.5: Losers Include Today Show, The Next Web; Winners Include YouTube, Fox News
• Confirmed: Google Panda 2.5 Update Arrived This Week
• Google Panda Update 2.4: Panda Goes International, In Most Languages
• Official: Google Panda 2.3 Update Is Live
• Can You Dig Out Of Your Google Panda Hole By Offloading To Subdomains?
• Why Google Panda Is More A Ranking Factor Than Algorithm Update

The new definition will take the average of the top ranking of your site for all searchers, as opposed to all URLs listed and average that. In the past, they would take all the positions of your rankings and average them together, now they are taking only the top positions.

Here is how Google explains it:

Let’s say Nick searched for [bacon] and URLs from your site appeared in positions 3, 6, and 12. Jane also searched for [bacon] and URLs from your site appeared in positions 5 and 9. Previously, we would have averaged all these positions together and shown an Average Position of 7. Going forward, we’ll only average the highest position your site appeared in for each search (3 for Nick’s search and 5 for Jane’s search), for an Average Position of 4.

Historically, this won’t impact the reports but going forward, Google will use this new calculation for determining your average position.

Google said, “we anticipate that this new method of calculation will more accurately match your expectations about how a link’s position in Google Search results should be reported.”

Here is where the average position shows up in Google Webmaster Tools:

Here is where the average position shows up in Google Analytics:

Related Stories:

• Google Analytics Webmaster Tools SEO Reports Now Available
• Google Analytics To Add Search Query Data From Webmaster Tools
• Keyword “Not Provided” By Google Spikes, Now 7-14% In Cases
• Google Webmaster Tools Search Queries Report Now Less Accurate
• Google Webmaster Tools Adds Useful Download Options

The old URL which was at google.com/webmasters/tools/submit-url/ now returns a page not found (404) error. The issue with that is, Google should really use a 301 redirect because it ranks in the top position for [google webmaster tools] and [google submit URL]:

The truth is, the add URL page is actually at google.com/webmasters/tools/submit-url, that is without the backslash at the end of the URL. It must be a bug on Google’s side, either they should redirect google.com/webmasters/tools/submit-url/ to google.com/webmasters/tools/submit-url or make both work.

In any event, now the new place to submit content is at google.com/submityourcontent. The page isn’t new, but it has recently been redesigned. The page launched back in September 2008 with a single page to find out how to submit content to Google’s various portals. It now looks like this:

Prior, it looked like this:

It is now broken down into four categories to submit content:

(1) For Website Owners

(2) For Business Owners

(3) For Publishing and Media

(4) For Public Agency

When you go to each of those landing pages, some of the content submission URLs differ, while some overlap between the four. One example is that all four have the submit URL to Google web search option.

Related Stories:

• Google’s “Submit Your Content” Page Changes Into Content Central, One Stop Shopping For Publisher Advice

Search Queries: Download Chart Data

Search query chart data downloads provide access to information not easily available before. When you view search query data, the chart in the user interface shows impression and click data per day, but in the past, this detail has only been available if you hover over a dot in the chart.

Now, you can access this data by clicking the Download Chart Data  button below the Top Queries and Top URLs reports. (You can use filtering options to drill into specific data or date ranges).

The data downloads to a CSV file as shown below:

When you click on a specific query in the Top Queries report page, you see a similar chart, but its data is not available for download. In the example below, clicking on [track santa claus] query in the Top Queries report brings up the query details for that single query, and you can download the page and position information, but not the chart data. (Note that a display bug seems to be preventing the buttons on this page from displaying in Internet Explorer.)

You can filter the Top Queries report and download the impression and click data from there (although you may not be able to filter to a single query). In the example below, a filtered report for [track santa claus] resulted in 16 queries.

The chart data in this case can be particularly useful due to how Google reports trended data. Watch for a separate post detailing how this works, but in short, Google reports on the top 1,000 queries per day. For reports that span multiple days, such as the example above, impression and click data is only included if the query was in the top 1,000 for each day. This can result in misleading totals, since the impressions and clicks aren’t totals for the entire data range, but only totals from the days in that range that the query was in the top 1,000. Confusing? Totally understandable.

Let’s look at the example above. I’ve filtered the Top Queries report to only show queries that include [track santa claus] for a 31 day period and the report shows:

• 16 queries
• 170,000 impressions
• 3,000 clicks

Does this mean the site got traffic for only 16 queries that contain the words [track santa claus]? No, it means that only 16 queries made it into the top 1,000 at least one day during the date range. Based on that foundation, you might assume that those 16 queries resulted in 170,000 impressions for the site and brought in 3,000 clicks for the 31 day period. But that assumption would be wrong. (This is where things can really start to get confusing.)

The Search Queries report only reports data (at all) for those days that a query is in the top 1,000. And the totals are the sum of the counts on those days only — not the entire date range. This level of detail has always been available (sort of) by way of the dots on the charts. Looking more closely at our [track santa claus] example, notice that several days in the chart don’t have dots.

The days without dots are the days that the query (or set of queries) didn’t make the top 1,000 and therefore have no data reported. Until now, the only way to make some sense of the data was to count the dots to better understand the summary data. Now, when you download the chart data, you can much more easily understand what the visualization represents:

With the CSV, it’s much more apparent that although the specified date range is 12/18/11 – 1/17/12, the totals are for 11 days, not 31. These queries were in the top 1,000 on 12/27, but not on the 28th or 29th. Does this mean that on the 28th, the impressions and clicks were lower than on the 27th? Maybe. Or it could mean that impressions and clicks stayed the same but another query spiked in volume and bumped it from the top 1,000.

User Interface Improvements

One nice change is the ability to view more data on a page. Most pages, including the dashboard page listing all sites in the account, now include an option for the number of rows to show.

You can now view up to 500 rows at once, which makes overall account management and data viewing much easier.

I had initially thought that more link data might be available as well, but after talking with Google, I realize that the user interface improvements have simply made the link reports more easily visible.

In particular, the detailed chart data available for download provides a significant improvement as it brings a much more accurate understanding of what the data actually is. Watch for my more detailed post on the search query data shortly.

Where We Came From

Some might believe that search engines hate SEOs, hate publishers and have done little over the years to help them. They are mistaken, either choosing to deliberately ignore the gains or, more likely, are simply unaware of how far things have come.

When I first started writing about SEO issues nearly 16 years ago, in 1996, we had little publisher support beyond add URL forms. Today, we have entire toolsets like Google Webmaster Central and Bing Webmaster Tools, along with standalone features and options, which allow and provide:

• Ability to submit & validate XML sitemaps
• Ability to view crawling & indexing errors
• Ability to create “rich” listings & manage sitelinks
• Ability to migrate a domain
• Ability to indicate a canonical URL or preferred domain
• Ability to set crawl rates
• Ability to manage URL parameters
• Ability to view detailed linkage information to your site
• Ability to view keywords used to reach your site
• Notifications of malware or spam issues with your site

There’s even more beyond what I’ve listed above. The support publishers enjoy today was simply unimaginable to many veteran SEOs who were working in the space a decade ago.

The advancement has been welcomed. It has helped publishers better manage their placement in those important venues of the web, the search engines. It has helped search engines with errors and problems that would hurt their usability and relevancy.

That’s why 2011 was so alarming to me. After years of moving forward, the search engines took a big step back.

The Loss Of Link Data

One of the most important ways that search engines determine the relevancy of a web page is through link analysis. This means examining who links to a page and what the text of the link — the anchor text — says about the page.

However, for years Google has deliberately suppressed the ability for outsiders to see what links tell it about any particular page. Want to know why THAT result shows up for Santorum? Why Google was returning THAT result for “define English person” searches? Sorry.

Google won’t help you understand how links have caused these things. It refuses to show all the links to a particular page, or the words used within those links to describe a page, unless you are the page’s owner.

Why? Google’s rationale has been that providing this information would make it harder for it to fight spam. Potentially, bad actors might figure out some killer linking strategy by using Google’s own link reporting against it.

It’s a poor argument. Despite withholding link data, it’s painfully easy to demonstrate how sites can gain good rankings in Google for competitive terms such as “SEO” itself by simply dropping links into forums, onto client pages or into blog templates.

Given this, it’s hard to understand what Google thinks it’s really protecting by concealing the data. But until 2011, there was an easy alternative. Publishers and others could turn to Google-rival Yahoo to discover how people might be linking to a page.

Goodbye Yahoo Site Explorer

Yahoo launched its “Yahoo Site Explorer” back in September 2005, both as part as a publicity push to win people away from Google and to provide information to publishers. The tool allowed anyone to see what link data Yahoo had about any page in its listings.

Today, Yahoo still supposedly wants to win people away from Google. But because Yahoo’s web search results are now powered by Bing, Yahoo has little reason to provide tools to support publishers. That’s effectively Bing’s problem now.

Yahoo closed Yahoo Site Explorer at the end of last November, saying as it still does on the site now:

Yahoo! Search has merged Site Explorer into Bing Webmaster Tools. Webmasters should now be using the Bing Webmaster Tools to ensure that their websites continue to get high quality organic search traffic from Bing and Yahoo!.

That’s not true. Yahoo Site Explorer was not merged into Bing Webmaster Tools. It was simply closed. Bing Webmaster Tools doesn’t provide the ability to check on the backlinks to any page in the way that Yahoo Site Explorer allowed.

The closure supposedly came after Yahoo “listened to your feedback” about what publishers wanted, as it posted earlier this year. I don’t know what feedback Yahoo was hearing, but what I’ve heard has been people desperately pleading with Yahoo or Bing to maintain the same exact features that Yahoo Site Explorer provided — and pleading for well over a year.

Yahoo-Bing Deal Has Reduced Competition & Features

When the US Department Of Justice granted its approval for Yahoo to partner with Microsoft, that was supposed to ensure that the search space stayed competitive. From what the Department Of Justice said in 2010:

After a thorough review of the evidence, the division has determined that the proposed transaction is not likely to substantially lessen competition in the United States, and therefore is not likely to harm the users of Internet search, paid search advertisers, Internet publishers, or distributors of search and paid search advertising technology.

I’d say dropping Yahoo Site Explorer did harm to both users of internet search and internet publishers. Yahoo Site Explorer was a distinctive tool that only Yahoo offered, allowing both parties named by the DOJ to better understand the inner workings of the search engines they depend on. It also reduced competitive pressure for Google to offer its own tool.

Indeed, things have gotten worse since Yahoo Site Explorer closed. At the end of last December, Bing officially confirmed that it no longer supports the link command in its help forum.

Next To Go, The Link Command?

The link command allows you to enter any page’s web address prefaced by “link:” in order to find links that point at that page. It’s a long-standing command that has worked for many major search engines as far back to late 1995, when AltaVista launched.

Google still supports this command to show some (but not all) of the links it knows about that point at pages. I’d link to Google’s documentation of this, but the company quietly dropped that some time around May 2008. Here’s what it used to say:

Here’s how the command still works at Google. Below, I used it to see what links Google says point to the home page of the official Rick Santorum campaign web site:

The first arrow shows you how the command is being used. The second arrow shows you how Google is reporting there are 111 links pointing to the page. Imagine that. Rick Santorum, currently a major Republican candidate for US president, and Google says only 111 other pages link to his web site’s home page.

The reality is that many more pages probably link over. Google’s counting them but not showing the total number to people who care about what exactly is being considered. I’ll demonstrate this more in a moment, but look at the worse situation on Bing:

One link. That’s all Bing reports that it knows about to those in the general public who may care to discover how many links are pointing to the Rick Santorum web site.

It’s Not Just An SEO Thing

People do care, believe me. I actually started writing this article last Monday and got interrupted when I had to cover how Google might have been involved with a link buying scheme to help its Chrome browser rank better in Google’s own search results.

I doubted that was really the main intent of the marketing campaign that Google authorized (Google did err on the side of caution and punished itself), but the lack of decent link reporting tools from Google itself left me unable to fully assess this as an independent third-party.

As soon as that story was over, renewed attention was focused on why Rick Santorum’s campaign web site wasn’t outranking a long-standing anti-Santorum web site that defines “santorum” as a by-product of anal sex.

Major media outlets were all over that story. My analysis was cited by The Economist, CNN, The Telegraph, The New York Times, MSNBC and Marketplace, to name only some.

But again, I — or anyone who really cared — was unable to see the full links that Google knew about pointing at both sites, much less the crucial anchor text that people were using to describe those sites. Only Google really knew what Google knew.

Third Party Options Good But Not The Solution

If you haven’t heard more complaints over the closure of Yahoo Site Explorer, and the pullback on link data in general, that’s because there are third-party alternatives such as Majestic Site Explorer or the tool I often use, SEOmoz’s Open Site Explorer.

These tools highlight just how little the search engines themselves show you. Consider this backlink report from Open Site Explorer for the Rick Santorum campaign’s home page:

The first arrow shows how 3,581 links are seen pointing at the page. Remember Google, reporting only 111? Or Bing, reporting only 1?

The next two arrows show the “external” links pointing at both the Santorum home page and the anti-Santorum home page. These are links from outsiders, pointing at each page. You can see that the anti-Santorum page has four times as many links pointing at it than the Santorum campaign page, a clue as to why it does so much better for a search on “santorum.”

But it’s not just number of links. Using other reports, I can see that thousands of links leading to both sites have the text “santorum” in the links themselves, which is why they both are in the top results for that word.

Because the anti-site has so many more links that say “santorum” and “spreading santorum,” that probably helps it outrank the campaign site on the single word. But because the official site has a healthy number from sources including places like the BBC saying “rick santorum” in the links, that — along with its domain name of ricksantorum.com — might help it rank better for “rick santorum.”

It’s nice that I can use a third party tool to perform this type of analysis, but I shouldn’t have to. It’s simply crazy — and wrong — that both Google and Bing send searchers and publishers away from their own search engines to understand this.

For one, the third party tools don’t actually know exactly what the search engines themselves are counting as links. They’re making their own estimates based on their own crawls of the web, but that doesn’t exactly match what Google and Bing  know (though it can be pretty good).

Not Listing Links Is Like Not Listing Ingredients

For another, the search engines should simply be telling people directly what they count. Links are a core part of the “ingredients” used to create the search engine’s results. If someone wants to know if those search results are healthy eating, then the ingredients should be shared.

Yes, Google and Bing will both report link data about a publisher’s own registered site. But it’s time for both of them to let anyone look up link data about any site.

The Blekko search engine does this, allowing anyone logged in to see the backlinks to a listed page. Heck, Blekko will even give you a badge you can place on your page to show off your links, just as Yahoo used to. But for Google, it’s “normal” for its link command to not show all the links to a page. Seriously, that’s what Google’s help page says.

Google, in particular, has made much of wanting people to report spam found in its search results. If it really wants that type of help, then it needs to ensure SEOs have better tools to diagnose the spam. That means providing link data for any URL, along with anchor text reporting.

Google has also made much about the need for companies to be open, in particular pushing for the idea that social connection should be visible. Google has wanted that, because until Google+ was launched, Google had a tough time seeing the type of social connections that Facebook knew about.

Links are effectively the social connections that Google measures between pages. If social connections should be shared with the world, then Google should be sharing link connections too, rather than coming off as hypocritical.

Finally, it doesn’t matter if only a tiny number of Google or Bing users want to do this type of link analysis. That’s often the pushback when this issue comes up, that so few do these type of requests.

Relatively few people might read the ingredients labels on the food they eat. But for the few that do, or for anyone who suddenly decides they want to know more, that label should be provided. So, too, should Google and Bing provide link data about any site.

Goodbye Keyword Referrer Data

While I’m concerned about the pullback on link data, I’m more concerned about how last October, Google stopped reporting to publishers the keywords people used to find their web sites, for times when those people were logged into Google.

Link data has long been suppressed by Google. Holding back on keyword data is a new encroachment.

Google has said this was done to protect user privacy. I have no doubt many in the company honestly believe this. But it if was really meant to protect privacy, then Google shouldn’t have deliberately left open a giant hole that continues to provide this data to its paid advertisers.

Worse, if Google were really serious about protecting the privacy of search terms, then it would disable the passing of referrers in its Chrome browser. That hasn’t happened.

Unlike the long examination of link data above, I’ll be far more brief about the situation with Google withholding link data. That’s because I’ve already written over 3,000 words looking at the situation in depth last October, and that still holds up. So please see my previous article, Google Puts A Price On Privacy, to understand more.

Google’s Weak Defense

Since my October story, the best defense that Google’s been able to concoct for withholding keyword data from non-advertisers is a convoluted, far-fetched argument that makes its case worse, not better.

Google says that potentially, advertisers might buy ads for so many different keywords that even if referrer data was also blocked for them, the advertisers could still learn what terms were searched for by looking through their AdWords campaign records.

For example, let’s say someone did a search on Google for “Travenor Johannisoon income tax evasion settlement.” I’ve made this up. As I write this, there are no web pages matching a Google search for “Travenor Johannisoon” at all. But…

• If this were a real person, and
• someone did that search, and
• if a page appeared in Google’s results, and
• someone clicked on that page…

then the search terms would be passed along to the web site hosting the page.

Potentially, this could reveal to a publisher looking at their web analytics that there might be a settlement for income tax evasion for involving a “Travenor Johannisoon.” If the publisher starting poking around, perhaps they might uncover this type of information.

Of course, it could be that there is no such settlement at all. Maybe it’s just a rumor. Anyone can search for anything which doesn’t make it into a fact.

More likely, the search terms are so buried in all the web analytics data that the site normally receives that this particular search isn’t noticed at all, much less investigated.

Extra Safe Isn’t Extra Safe

Still, to be extra safe, Google has stopped passing along keyword data when people are signed-in. Stopped, except to its advertisers. Like I said, Google argues that potentially advertisers might still see this information even if they were also blocked.

For instance, say someone runs an ad matching any searches with “income tax evasion” in them. If someone clicked on the ad after doing a search for “Travenor Johannisoon income tax evasion settlement,” those terms would be passed along though the AdWords system to the advertiser, even though the referrer might pass nothing to the advertiser’s web analytics system.

So, why bother blocking?

Yes, this could happen. But if the point is to make things more private, then blocking referrers for both advertisers and non-advertisers would still make things harder. Indeed, Google still has other “holes” where “Travenor Johannisoon” might find his privacy exposed just as happens potentially with AdWords.

For example, if someone did enough searches on the topic of Travenor and tax evasion, that might cause it to appear one of Google Instant’s suggested searches.

So why bother blocking?

Also, while Google blocks search terms from logged-in users in referrer data, those same searches are not blocked from the keyword data it reports to publishers through Google Webmaster Central. That means the Travenor search terms could show up there.

So why bother blocking?

Nothing has changed my view that, despite Google’s good intentions, its policy of blocking referrers only for non-advertisers is incredibly hypocritical. Google purports this is done to protect privacy, but it puts its own needs and advertisers desires above privacy.

Blocking referrers is a completely separate issue from encrypting the search results themselves. That’s good and should be continued. But Google is deliberately breaking how such encryption works to pass along referrer data to its advertisers. Instead, Google should block them for everyone or block them for no one. Don’t play favorites with your advertisers.

What Google & Bing Should Do

Made it this far? Then here’s the recap and action items for moving forward.

Bing should restore its link command, if not create a new Bing Site Explorer. Google should make sure that its link command reports links fully and consider its own version of a Google Site Explorer. With both, the ability for anchor text reports about any site is a must.

If there are concerns about scraping or server load, make these tools you can only use when logged in. But Yahoo managed to provide such a tool. Blekko is providing such statistics. Tiny third-party companies are doing it. The major search engines can handle it.

As for the referrer data, Google needs to immediately expand the amount of data that Google Webmaster Central reports. Currently, up to 10,000 terms (Google says up to 1,000, but we believe that’s wrong) for the past 30 days are shown.

In November, the head of Google’s spam team Matt Cutts — who’s also been involved with the encryption process — said at the Pubcon conference that Google is considering expanding the time period to 60 days or the queries to 2,000 (as said, we think — heck, we can see, they already provide more than this). Slightly more people wanted more time than more keywords shown.

I think Google should do more than 60 days. I think it should be providing continuous reporting and holding that data historically on behalf of sites, if it’s going to block referrers. Google is already destroying historical benchmarks that publishers have maintained. Google’s already allowed data to be lost for those publishers, because they didn’t begin to go in each day and download the latest information.

So far, all Google’s done is provide an Python script to make downloading easier. That’s not enough. Google should provide historical data, covering a big chunk of the terms that a site receives. It’s the right thing to do, and it should have been done already.

What Publishers Can Do

An anti-SOPA-like effort as targeted GoDaddy isn’t going to work with the search engines. That’s because the two biggest things that publishers could “transfer” out of Google and Bing are their ads and their web sites. But there’s no place to transfer these to that wouldn’t hurt the publishers with incredible amounts of lost traffic.

This doesn’t mean that publishers are powerless, however.

Bing is desperate to be seen as the “good” search engine against “evil” Google. Publishers should, whenever relevant, remind Bing that it’s pretty evil not to have maintained its own version of Yahoo Site Explorer much less to have closed the link command.

Mention it in blog posts. Mention it in tweets. Bring it up at conferences. Don’t let it die. Ask Bing why it can’t do what little Blekko can.

As for Google, pressure over link data is probably best expressed in terms of relevancy. Why is Google deliberately preventing this type of information from being studied? Is it more afraid that doing so will reveal weaknesses in its relevancy, rather than potential spam issues? Change the debate to relevancy, and that gets Google’s attention — plus the attention of non-publishers.

There’s also the issue of openness. Google shouldn’t be allowed to preach being “open” selectively, staying closed when it suits Google, without some really good arguments for remaining closed. On withholding link data, those “closed” arguments no longer stand up.

As for the referrer data, Google should be challenged in three ways.

First, the FTC will be talking to publishers as part of its anti-trust investgation into Google’s business practices. Publishers, if asked, should note that by withholding referrer data except for Google’s advertisers, it’s potentially harming competing retargeting services that publishers might prefer to use. Anti-trust allegations seem to really get Google’s attention, so make that wheel squeak.

Second, question why Google is deliberately leaving a privacy hole open for the searchers it’s supposedly trying to protect. If Google’s really worried about what search terms reveal, the company needs a systematic way to scrub potentially revealing queries from everything: suggested searches, reporting in Google Webmaster Central, AdWords reporting as well as referrer data.

Finally, withhold your own data. Are you opted-in to the data sharing on Google Analytics that launched back in 2008? Consider opting-out, if so:

To opt-out, when you log in, select an account, then select “Edit Analytics Account” next to the name of the account in the Overview window, then you’ll see options as shown above and as explained on this help page.

Opting out means you can’t use the benchmarking feature (fair enough, and no loss if you don’t use it) and Conversion Optimizer. If you still want Conversion Optimizer, don’t opt-out or alternatively, tell Google that you should have a choice to share data solely for use with that product but not other Google products.

There might be other drawbacks to not sharing that I’m missing. But we haven’t been sharing here at Search Engine Land since the beginning of the year. So far, we’re not having any problems.

Google loves data. Withholding your own is another way for publishers to register their displeasure about having data withheld from them. And it’s the type of thing that Google just might notice.

Related Articles

• What Is SEO / Search Engine Optimization?
• Search Engine Land’s Guide To SEO
• The Periodic Table Of SEO Ranking Factors
• What Is Google PageRank? A Guide For Searchers & Webmasters
• How The “Focus On First” Helps Hide Google’s Relevancy Problems
• Yahoo Completes Global Organic Transition To Bing
• Yahoo Site Explorer Closing Down Monday, November 21st
• The Microsoft-Yahoo Search Deal, In Simple Terms
• Google Releases New Link Reporting Tools
• Google Now Reporting Anchor Text Phrases
• Yahoo Adds Link Badge In Site Explorer
• Link Building Tool Review: Link Research Tool Set By CEMPER
• Link Building Tool Review: SEOmoz PRO
• Link Building Tool Review: SEO Book
• Link Building Tool Review: Raven Tools
• Link Building Tool Review: Majestic SEO
• Bing Webmaster Tools Launches New Link Reports; Google Webmaster Tools Changes Theirs
• Blekko’s SEO Tools: What Information Do They Provide?
• Blekko Offers New Linkroll Widget & More Publisher Tools
• Google’s Chrome Page No Longer Ranks For “Browser” After Sponsored Post Penalty
• Should Rick Santorum’s “Google Problem” Be Fixed?
• How Rick Santorum Is Making His “Google Problem” Worse
• For “Define An English Person,” Google Suggests The C-Word
• Google’s Spam Report Page Gets “Biggest Refresh” In Years
• Google: As Open As It Wants To Be
• Google’s Facebook Competitor, The Google+ Social Network, Finally Arrives
• How Google Instant’s Autocomplete Suggestions Work
• Google Webmaster Tools Adds Page-Level Query Data
• Google Webmaster Tools Search Queries Report Now Less Accurate
• Google Analytics Benchmarking Feature, Data Sharing & Audio Ad Charting
• Guest Opinion: Is Google’s Privacy Move Really An Anti-Competitive Practice?
• Dear Congress: It’s Not OK Not To Know How Search Engines Work, Either
• Googleopoly: The Definitive Guide To Antitrust Investigations Against Google
• Keyword “Not Provided” By Google Spikes, Now 7-14% In Cases
• Google Puts A Price On Privacy

A search for [site:co.cc] currently returns 105,000,000 results.

Google originally delisted the co.cc subdomains because Google saw a “very large fraction of sites” on that subdomain to be “spammy or low-quality” and felt it was warranted, in this case, to simply block the whole subdomain from showing up in Google’s results.

I am not sure if this change was intentional or a bug where after we write about it Google will delist the subdomains again.

Here is what the results looked like previously:

Now that many of the results are back, you can check for yourself to see how spammy or low-quality co.cc sites are or are not.

Related Stories:

• Google Delists All CO.CC Domains From Index
• Wait… Google Banned BeatThatQuote Again!
• Why Google Should Ban Its Own Help Pages — But Also Shouldn’t
• AdWords Cloaks Its Help Pages, Gets Banned By Google
• 90 Days Later, J.C. Penney Regains Its Google Rankings
• Got A Google Penalty? A Workflow For Managing Google Penalties
• Official: Selling Paid Links Can Hurt Your PageRank Or Rankings On Google
• Google Sending Additional Reconsideration Request Responses To Webmasters

Image credit ShutterStock’s welcome back sign.

Author Stats shows you how often your content is showing up on the Google search results page. This will show up under Google Webmaster Tools in the “labs” section in Webmaster Tools. It shows the impressions and clicks of the stories found in Google and shows up when you associate your content with your Google Profile.

Here is a picture:

Google said if you have issues with it, you can email them at authorship-pilot@google.com.

Also, Google has promoted the authorship stories in the Google search results by adding a more by link in the search results.

Related Stories:

• Google Tweaks Its Rel=Author Display, Promotes Google+ In Search Results
• Google Now Supports “Author” Tag
• Google+ Is Slowly Invading Google’s Main Search Results
• Google Analytics Webmaster Tools SEO Reports Now Available
• Google +1 Reporting Now In Google Webmaster Tools

In fact, digging deeper into the announcement produces new worries and potential new solutions for international SEOs.

For instance, whilst it may not have been Google’s intention, they’re presenting this as a “stronger signal than canonicals”, and give scenarios for its use which many did not even know existed as potential danger areas — including me.

Google Announces Multilingual Markup Scheme

The Two Big Elephants Of Global SEO

So, let’s try and walk through this in a logical way so we can all grasp what’s going on. Firstly, there are two big related issues which have plagued international SEO for years, namely:

• Dealing With Duplication
• Correctly Geo-Targeting A Site

In addition, Google has been under pressure for some time from large global corporates concerned that their global website costs were escalated by the needs of the Google algorithm — because of the impacts on translation costs.

So there are also two further translation issues:

• Costs Associated With Creating Specific Country Translations
• Dealing With Multi-Language User Generated Content

Dealing With Duplication

I’ll take each of these in turn to clarify what’s involved starting with “Duplication”. A problem with content that is duplicated arises because Google’s algorithm naturally throws out all copies apart from the “Best” or “Most Original”.

This is fine if you’re working on content for one country only, but if you need to show the same content for countries which all speak the same language then it starts to become challenging.

It’s important to note that, to date, this issue has applied only to copies of content that were in the same language. I’ll explain later why this distinction is important.

The main issue with duplication is actually that marketers need to show the correct country content to that country at the moment that user finds their site via Google.

Showing them the wrong country could provide them with incorrect contact details or pricing which potentially reduce their conversion performance or effectively deliver poor customer service.

Correctly Geo-Targeting A Site

Correctly geo-targeting a site means that when a user searches for an organization within a particular Google local domain, the site shows up and has not been filtered out because Google thinks it relates to a different country.

This is particularly important in the “Page From” and “Pages In {Language}” user filters on the left of the page. If user searches for you via “Pages From Norway” for instance, and you have a Norwegian operation, you definitely do want your site to show up in the rankings.

Costs Associated With Creating Specific Country Translations

Large corporations invest billions of dollars in translations and often not very productively. There are two solutions to this problem which can help with the cost namely using the same “World Language Content” multiple times or adopting machine translation techniques.

For example, it’s very common for global sites to use only translate their content into Spanish once and to deliver that same Spanish to all countries needing that language equally. As there are at least 20 countries speaking Spanish, the could mean 20 copies of the same content on the same site at the same time. Yep, we’re duplicating.

To avoid the duplication, we might use local domains to help (I can confirm that does help) or we might translate a fresh copy for each country — or more commonly, for the major ones which we consider significant.

Dealing With Multi-Language User Generated Content

If you’re site is a forum or Q&A style site that operates internationally, you face the problem that your users are generating content in one language that you might wish to share with users in other languages.

Almost all organizations facing this problem opt to use auto-generated translation techniques; but unfortunately this has begun to fall foul of the Panda algorithm which searches out poor quality content based on machine learning and pattern techniques. Frequently, auto-translated content looks like really bad spam!

The Solution Google Is Offering

With the new markup, Google is putting forward a different way of solving these problems. At a later point, I will look at the broader issues of combining this approach with Webmaster Central geo-targeting and the use of local domains, but for now we’ll stick to the markup option.

Back in February 2009, Google first launched the Canonical markup tag supported also by both Bing and Yahoo. The main purpose of the canonical tag was to add code on the page to indicate to the search engine the “Canonical” of the page. In other words, to indicate to the search engine which was the most important copy of the page which should be shown to users.

Later, the canonical tag was given cross-domain capabilities which extended its reach into the multilingual world — but there it suddenly ran into some significant limitations.

If you used the rel=canonical tag to solve duplication issues, you had to choose which one was the “Top” URL which meant you could be showing UK content in Australia or Argentinian pages to the Spanish.

Targeting The Right Part Of Google Involves Understanding Google Geographic Filters

Where The New Tag Comes In

Let’s imagine that in our scenario where you’ve denominated, using rel=canonical, that a certain page is the “master content”.

What you’ve now done is “Deduplicated” it! In other words, you’ve given an indication to Google that a particular piece of content is necessarily duplicated and you’ve indicated which is the original.

What you’ve not done is indicated which version of that now-known-to-be-duplicate content should be shown where.

The rel=”alternate” hreflang=”en” version of the Hreflang tag enables you to say, “This is for Australia, this is for the UK!” We can also assume that without “Hreflang”, the top content — perhaps the UK version — would be linked to by both sets of Google results.

So to recap, rel=canonical deduplicates and rel=alternate hreflang denotes the geo-targeting. Simple.

Not Quite So Simple

Don’t forget, we also have Webmaster Central geo-targeted settings in the background and they’re useful because you can geo-targeting a whole site, folder or sub-domain to a particular country.

With the “rel=tag thingies”, you have to specify the settings on a per URL basis which involves considerably more effort and cost than the use of global settings at Webmaster Central.

However, the rel=”alternate” hreflang has the advantage that it can be deployed alongsider ccTLDs or local domains. This makes eminent sense and prevents people thinking they have to use a dot com to target when in fact ccTLDs achieve better results.

Where Site Content Is “Fully Translated?”

In the rel=”alternate” annoucement and Webmaster help pages, Google gives as an example scenario the denomination of targeting for a German and for an English URL — the question is why? A German translation of an English text is by definition not a duplicate, unless you re-translate it back and re-compare. So why would Google show this example?

The use case Google describes is, “Multiregional websites using fully translated content, or substantially different monolingual content targeting different regions. Example: a product webpage in German, English and French”. So it is clear that Google would like us to use this tag to denote content even if it’s not in the same language.

Other commentators have concluded that Google is telling us that translated content “Can Be Duplicate”. I doubt this because I cannot see what the purpose might be from Google’s point of view.

Studying The Non-Duplicate Use Cases

There are other cases where indicating which language a page’s content is deemed to be in could be useful:

• To indicate dynamic machine translation
• To identify content in English to be translated

Machine translation is known to raise red flags to visiting Panda crawlers because of their preference for correct gramatical and properly flowing natural language — in the same way that real life Panda’s are very fussy about eating natural bamboo shoots and nothing else!

Denominating your content as machine translated and linking it to one original source could be used in Panda as a means of giving additional authority to the content even if doesn’t really flow very naturally at all and would normally be discarded. (Less politely said, “Your content is rubbish dude but we’ll let it pass…”)

Equally, some websites hold content in English and translate the content dynamically — such as multi-country forums for example. That content may be seen by the crawler as another copy of English to be discarded, unless it is denoted as “German” which is the language it would be displayed in once a user had “demanded” the content to load.

Using the alt=”alternate” hreflang could help Google understand this process algorithmically.

Canonical Involves Guesswork — Not Any More

The result? I’m already thinking that this opens up so many options we’d better be increasing that hour’s training we’re currently providing to explain geo-targeting, to a full-day as the potential variations have now expanded exponentially! By the way, if anyone has any updates do let me know via the comments!

The new link element is rel=”alternate” hreflang=”x” where you define the language and location in the hreflang area.

Here are examples of how you may use it respectively:

• http://www.example.com/ – contains the general homepage of a website, in Spanish
• http://es-es.example.com/ – is the version for users in Spain, in Spanish
• http://es-mx.example.com/ – is the version for users in Mexico, in Spanish
• http://en.example.com/ – is the generic English language version

<link rel="alternate" hreflang="es" href="http://www.example.com/" />
<link rel="alternate" hreflang="es-ES" href="http://es-es.example.com/" />
<link rel="alternate" hreflang="es-MX" href="http://es-mx.example.com/" />
<link rel="alternate" hreflang="en" href="http://en.example.com/" />

For more details on how to use this, see this Google help document.

Related Articles:

• How Machine Translation Has A Habit Of Mangling Multilingual SEO
• Effectively Managing Multilingual Content Segmentation
• Do You Have Duplicate Content Issues Across Domain? Google Will Now Alert You
• Google Supports Cross-Domain ‘Canonical Tag’
• Google: rel=”canonical” Now Supported In HTTP Headers
• Google Adds URL Parameter Options to Google Webmaster Tools
• Canonical Tag 2.0: Google To Add Cross Domain Support