(1) Updated Dashboard (2) New Left Hand Navigation (3) Home Compact View

Here is a picture of the revised dashboard:

The new navigation was changed to be more representative of the content and tools within the portal. Google explained:

• Configuration: Things you configure and generally don’t change very often.
• Health: Where you look to make sure things are OK.
• Traffic: Where you go to understand how your site is doing in Google search, who’s linking to you; where you can explore the data about your site.
• Optimization: Where you can find ideas to enhance your site, which enables us to better understand and represent your site in Search and other services.

Related Stories:

• Google Webmaster Tools Expands Query Data to 90 Days
• Do You Have Duplicate Content Issues Across Domain? Google Will Now Alert You
• Google Webmaster Tools Crawl Errors: How To Get Detailed Data From the API
• Google Webmaster Tools Adds Useful Download Options
• Google Webmaster Tools Finally Adds User Administration
• Google Webmaster Tools Revamps Crawl Errors, But Is It For The Better?
• Google +1 Reporting Now In Google Webmaster Tools

“These reports provide another layer of social insight showing which of your content attracts links, and enables you to keep track of conversations across other sites that link to your content. Most website and blog owners had no easy mechanism to do this in the past, but we see it as another important feature for holistic social media reports. When you know what your most linked content is, it is then also much easier to replicate the success and ensure that you are building relationships with those users who actively link to you the most.”

Where To Find The Backlink URLs Report

The Backlink information is not easy to find. First visit the pages tab on the Social reports (this link should take you directly to this report). Then click on a specific URL. Here is what you will see now:

As indicated in the screenshot above, click on the Activity Stream tab above the graphs. Then you will arrive at another page that gathers all Social Data Hub conversations related to this specific page, as seen below:

If you click the Events tab shown above you will find the Backlinks information. This information appears among all other social events like +1s, Delicious bookmarks, and others. For each backlink URL you will be able to View Activity, i.e. visit the page with link, or to View Page, i.e. view the page linked.

As you will see in the reports, while this information is very useful, it is still lacking a centralized place where users can see all the linked pages aggregated. The way this information is being organized is very focused on Social Media professionals, it treats links as another event related to the post. And the reports do not allow any filtering or segmentation. If we look at the Webmaster Tools (screenshot below), the information is more focused on SEOs, showing in a glance where the links are coming from and to which pages.

Postscript 1: According to a comment by Ilya Grigorik on a Google+ post, there is a way to find the centralized information in the reports, here is his explanation on how to do it.

I should also point out that there is indeed a way for users to see all of the linked pages aggregated, though it requires some GA ninja tricks at the moment. We’re working on making it more intuitive for users. Here it is:

1. Just as you outlined in the post, navigate to “Pages”, select a URL, click on “Activity Stream” – this shows you the activitystream for just that URL
2. Ninja trick #1: At the top of the page where it shows the breadcrumb with the current page, click on “ALL” – this report will show you all activity across all the pages in chronological order.
3. Ninja trick #2: Scroll down to any trackback activity and click on the (green) trackback icon: this filters the activitystream to just trackbacks.. And voila, you see a list of most recent trackbacks across all of your pages.

Social Signals And Backlinks In The Same Bucket

This addition is interesting in that Google decided to add this information to the Social reports instead of adding it to the SEO reports. This decision makes sense from a Google Analytics perspective as this information, like all other Social information, is a factor that happens outside the website and, as such, it could be analyzed in the same way we analyze Google+ activity.

However, this information is more often used by SEOs in order to optimize pages and understand which pages are getting the most links. As discussed above, it appears that these reports are more focused on Social Media professionals rather than SEO professionals.

It is also interesting to look at this in the light of Danny Sullivan’s post discussing Social signals for Google and Bing, this decision shows how backlinks and social signals are seen as part of the same bucket.

What’s In the Top Search Queries Report

First, a refresher on what this data is all about. The top search queries report (available in Google webmaster tools for sites you’ve verified ownership of by selecting Your site on the web > Search queries) lists the top queries that brought traffic to your site from Google organic search (from all countries and properties).

Summary Data

For the selected data range, the report shows the total number of queries that brought traffic to the site, the total impressions and clicks the site received, and the number of impressions and clicks for the reported top queries.

Query-Specific Data

For each query, the report notes:

• Number of impressions - how many searchers saw the site in search results for that query
• Number of clicks - how many searchers clicked on the search result for that query
• Click through rate - The percentage of the time searchers who saw the site in search results for that query clicked on it
• Average position - the average position the highest ranked URL for that site appeared in search results for the query across all searchers
• In addition, you can find out the change for each of these data points from the previous period. However, the change percentages aren’t available for time periods longer than 30 days. The change details used to be visible by default, but they’re now off by default. You’ll need to click the With Change button to see them in the report (although they’ll be included automatically with the CSV download). If you have the change percentage displayed, you’ll need to turn that off in order to expand the date range beyond 30 days.

You can click into any query to get more specific data, including the pages that ranked for the query, and the impressions, clicks, and click-through rate at each position the site ranked.

Country and Property-Specific Data

Use the filters to drill into what queries brought traffic from Google properties (web, video, images, mobile web, and smartphones) and from specific countries.

How the Numbers Are Aggregated

As I explained in a previous post, the numbers can be tricky and it’s important to understand what data you’re really looking at. These reports now list the top 2,000 queries that brought traffic to the site for the selected time period. That means that if a query wasn’t one of the top 2,000 for any days in the selected range, data won’t be reported for it. In the example below, the time period is 30 days, but only 6 of those days have data reported for the query (as illustrated by the dots in the graph).

Generating Data

When generating or downloading the data, keep in mind the following:

• The default ending data in the user interface display is today’s date, but reporting is typically 2-3 days behind so check the last date reported in the graph by hovering over the last dot. The default starting date of the range is 30 days before the end date. And because this end date is generally three days ahead of what’s actually reported, the actual date range generally shown by default is 27 days. Make sure you adjust the dates before analyzing data or comparing it to other time periods.
• Because the default shown date range is 27 days, the download available from the Python script is also 27 days.

Google placed reversed the order of these features when they wrote about it, trying to mitigate the importance of removing some of these features. Site Performance going away is going to be frustrating for a lot of Google Webmaster Tools users. Subscriber stats is not as important and robots.txt is really not a big deal for most webmasters.

Site Performance:

Site performance is a Webmaster Tools Labs feature that provides information about the average load time of your site’s pages. This feature is also being removed due to low usage. Now you might have heard our announcement from a couple of years ago that the latency of a site’s pages is a factor in our search ranking algorithms. This is still true, and you can analyze your site’s performance using the Site Speed feature in Google Analytics or using Google’s PageSpeed online. There are also many other site performance analysis tools available like WebPageTest and the YSlow browser plugin.

Subscriber Stats:

Subscriber stats reports the number of subscribers to a site’s RSS or Atom feeds. This functionality is currently provided in Feedburner, another Google product which offers its own subscriber stats as well as other cool features specifically geared for feeds of all types. If you are looking for a replacement to Subscriber stats in Webmaster Tools, check out Feedburner.

Robots.txt Tool:

The Create robots.txt tool provides a way to generate robots.txt files for the purpose of blocking specific parts of a site from being crawled by Googlebot. This feature has very low usage, so we’ve decided to remove it from Webmaster Tools. While many websites don’t even need a robots.txt file, if you feel that you do need one, it’s easy to make one yourself in a text editor or use one of the many other tools available on the web for generating robots.txt files.

Image credit to ShutterStock.

Specifically, Google sent these messages to sites doing “weird redirects.” I’ve personally seen a spike in the number of sites redirecting from their web site to a non-authorized site recently. The webmaster is typically unaware of this redirect because the redirects only occur when someone clicks from Google’s search results to the web site. Typically the site owner doesn’t go to Google to find his web site; the site owner goes directly to the site.

To help webmasters and site owners become aware of this hack, Google has sent out messages to about 20,000 sites effected by this to give them the heads up.

Here is Matt Cutts’ tweet:

Is your site doing weird redirects? We just sent a “your site might be hacked” msg to 20K sites, e.g. goo.gl/S6Ptk

— Matt Cutts (@mattcutts) April 16, 2012

For more on hacked sites and malware, see this Google document.

Related Stories:

• Matt Cutts On Appealing Google Malware Warnings
• Google Warns Of Malware Redirecting To Its Search Results
• Google Adds Site Hacked Notifications To Search Results
• Google Search Results Now May Display Malware Warnings
• Google Warns Of Malware Redirecting To Its Search Results

“We don’t use Akismet to flag spam,” a Google spokesperson told us, after talking with Google’s spam team.

One oddity in the speculation was this:

She stated that Google had left a client of hers the dreaded unnatural linking notice in GWT, with example urls of pages it found unnatural links on. This part is nothing new really, but until now we had no idea how Google was deciding this…

Google’s warning notices, such as those that have increased recently, don’t list actual URLs. We’ve reconfirmed this with Google. Instead, they’re a general message like this:

We’ve detected that some of your site’s pages may be using techniques that are outside Google’s Webmaster Guidelines….

So it’s unclear how this person received a warning from Google about particular URLs, much less URLs that were never published on the web because they were trapped within a spam filter.

Postscript By Danny Sullivan: The story above was updated to clarify that to our knowledge, Google doesn’t report specific URLs within its unnatural linking notices messages, which as explained makes the speculation even more speculative. But if anyone wants to pass along the actual warning received with those URLs, we’re happy to take another look.

Related Articles

• Google Eliminates Another Link Network, BuildMyRank.com – Just One Of Several?
• Google Sending Warnings About “Artificial” Or “Unnatural” Links

Warnings Issued

Many people have reported getting messages from Google regarding link violations. If you scan the Google Webmaster Help forums, for instance, you will see many examples of these being posted.

Here is how one reads:

Dear site owner or webmaster of ….

We’ve detected that some of your site’s pages may be using techniques that are outside Google’s Webmaster Guidelines.

Specifically, look for possibly artificial or unnatural links pointing to your site that could be intended to manipulate PageRank. Examples of unnatural linking could include buying links to pass PageRank or participating in link schemes.

We encourage you to make changes to your site so that it meets our quality guidelines. Once you’ve made these changes, please submit your site for reconsideration in Google’s search results.

If you find unnatural links to your site that you are unable to control or remove, please provide the details in your reconsideration request.

If you have any questions about how to resolve this issue, please see our Webmaster Help Forum for support.

Sincerely,

Google Search Quality Team

Links No Longer “Silently Distrusted”

Last month, Google appeared to take action against several blog/link networks. Are the messages going out because of that? Google told us no. Rather, it is that Google’s choosing to report penalties about bad linking issues more now than in the past.

A Google spokesperson emailed this statement:

The majority of the increase in messages to webmasters is not due to messages about links. Rather, Google recently started sending messages to sites even for egregious or “blackhat” violations of our quality guidelines. The vast majority of the increase in messages is thus due to expanding the types of messages we send, not because of more warnings about links.

It is true that actions on link networks have been more visible lately, but there’s an important disclaimer to that. Google has been able to trace and take action on many types of link networks; we recently decided to make that action more visible. In the past, some links might have been silently distrusted or might not have carried as much weight. More recently, we’ve been surfacing the fact that those links aren’t helping to improve ranking or indexing.

Earlier this year, Google said that it significantly increased the number of messages they have sent through Webmaster Tools in 2012.

Related Stories:

• Google Eliminates Another Link Network, BuildMyRank.com – Just One Of Several?
• Official: Selling Paid Links Can Hurt Your PageRank Or Rankings On Google
• Google’s Action Against Paid Links Continues: Overstock & Forbes Latest Casualties; Conductor Exits Brokering Business
• Another Company Outed for Paid Links: Sequoia-Backed Milanoo
• Google’s Jaw-Dropping Sponsored Post Campaign For Chrome
• New York Times Continues Paid Link Outing Stories, Looks At Online Flowers Industry
• Google Chrome’s Paid Link Penalty Now Lifted
• Google Sent Over 700,000 Messages Via Webmaster Tools In Past Two Months
• Dilbert Cartoon: Caught For Paid Links On Google

“For those who worry that 1000 error details plus a total aggregate count will not be enough, we’re considering adding programmatic access (an API) to allow you to download every last error you have, so please give us feedback if you need more.”

And led me to believe that the current API would only provide access to the same data available from the downloads from the UI. But in any case, up to 100,000 URLs for each error and the details of most of what has gone missing is in fact available through the API now, so rejoice!

The data is a little tricky to get to and the specifics of what’s available varies based on how you retrieve it.  Two different types of files are available that provide detail about crawl errors:

• A download of eight CSV files, one of which is a list of all crawl errors
• A crawl errors feed, which enables you to programatically fetch 25 errors at a time

(Thanks to Ryan Jones and Ryan Smith for help in tracking these details down.)

What this means is that different slices of data are available in four ways:

• User interface display
• User interface-based CSV download
• API-based download
• API-based feed

CSV Download

Eight CSV files are available through the API (you can download them all for a single site or for all sites in your account at once as well as just a specific CSV and a specific date range), but this support is not built into most of the available client libraries. You’ll need to build it in yourself or use the PHP client library (which seems to be the only one that has support built in). The CSV files are:

• Top Pages
• Top Queries
• Crawl Errors
• Content Errors
• Content Keywords
• Internal Links
• External Links
• Social Activity

For the topic at hand, let’s dive into the crawl errors CSV. It contains the following data:

• Up to 100,000 URLs for each type of error (rather than the 1,000 maximum available through the download link in the UI)
• The full list of URLs blocked by robots.txt (which is no longer available at all in the UI)
• Specifics of “not followed” errors (the UI reports only the status code returned by the URL, while the CSV includes what the actual problem was, such as “too many redirects”)
• Specifics site-wide server errors (the UI no longer lists the specific URLs that returned the error or the specific error)
• Specifics about “soft 404s” (the UI doesn’t include the detail of the type of soft 404)

This file does not include details on crawl error sources (but that is available through the crawl errors feed, described below).

Crawl Errors Feed

It appears that the crawl errors feed request code is built into the Java and Objective C client libraries, but you’ll have to write your own code to request this if you’re using a different library. You can fetch 25 errors at a time and programmatically loop through them all. The information returned is in the following format:

<atom:entry>
  <atom:id>id</atom:id>
  <wt:crawl-type>web-crawl</wt:crawl-type>
  <wt:issue-type>http-error</wt:issue-type>
  <wt:url>http://example.com/dir/</wt:url>
  <wt:detail>4xx Error</wt:detail>
  <wt:linked-from>http://example.com</wt:linked-from>
  <wt:date-detected>2008-11-17T01:06:10.000
  </wt:date-detected>
</atom:entry>

How the Data Differs

Let’s take a look at some real examples at how what you get in this file differs from the UI and UI-based download.

Number of Errors Shown

The UI shows the total count over time, but only lists up to 1,000 URLs for each error. The API-based CSV contains up to 100,000 URLs for each type of error. However, it gives you only the current snapshot of errors and doesn’t provide a total count of each error (if more than 100,000 exist for any given one). This is the same information you can get from the API-based crawl errors feed. The UI-based CSV also only shows you the current snapshot of errors and lists only up to 1,000 URLs (the same as the UI).

For searchengineland.com’s “not found” errors:

• The UI shows that Google encountered 4,981 URLs (down from around 8,000 in December) and displays 1,000 of them, along with the corresponding response code (and the list of sources via a popup):
• The UI-based CSV lists 1,238 of them, along with the corresponding response code:
• The API-based CSV lists 2,867 of them, along with the corresponding response code and the number of incoming links (but not the sources):
• The API-based feed presumably would provide all 4,981 URLs (in 25 URL increments), the response code, and the list of sources.

I checked a site that the UI indicated had more than 100,000 of a particular error (257,065) and found that the corresponding API-based CSV file listed 100,005 of those. The UI-based CSV listed 1,999.

Error Sources

The UI shows error sources, but only at the individual URL level. Click a URL, then click the Linked From tab to see the list. You can’t download this list from the UI in aggregate or for an individual URL.

The API-based CSV indicates the number of sources linking to each URL (which can be useful as you can tackle issues with URLs that have a lot of links first), but doesn’t list what those sources are.

The API-based feed provides details on the source for each URL. Below is an example from searchengineland.com:

<atom:entry>
<atom:id>https://www.google.com/webmasters/tools/feeds/

http%3A%2F%2Fsearchengineland.com%2F/crawlissues/27</atom:id>
<atom:updated>2012-03-19T17:18:18.907Z</atom:updated>
<atom:category scheme='http://schemas.google.com/g/2005#kind'
 term='http://schemas.google.com/webmasters/tools/
2007#crawl_issue_entry'/>
<atom:title type='text'>Crawl Issue</atom:title>
<atom:link rel='self' type='application/atom+xml'
href='https://www.google.com/webmasters/tools/feeds/
http%3A%2F%2Fsearchengineland.com%2F/crawlissues/27'/>
<wt:crawl-type xmlns:wt='http://schemas.google.com/
webmasters/tools/2007'>web-crawl</wt:crawl-type>
<wt:issue-type xmlns:wt='http://schemas.google.com/webmasters/
tools/2007'>not-found</wt:issue-type>
<wt:url xmlns:wt='http://schemas.google.com/webmasters/
tools/2007'>http://searchengineland.com/10-optimization-
secrets-to-drive-more-mobile-traffic-from-facebook-114316/
www.linkedin.com/in/brianklais</wt:url>
<wt:date-detected xmlns:wt='http://schemas.google.com/
webmasters/tools/2007'>2012-03-17T05:58:35.000</wt:date-detected>
<wt:detail xmlns:wt='http://schemas.google.com/webmasters/tools/2007'>
404 (Not found)</wt:detail>
<wt:linked-from xmlns:wt= 'http://schemas.google.com/webmasters/ tools/2007'>htp://searchengineland.com/10-optimization-secrets-to- drive-more-mobile- traffic-from-facebook-114316/comment-page-1 </wt:linked-from>
</atom:entry>

Date of Latest Crawl

As far as I can tell, this detail is available only in the UI (once you click on a URL):

In Sitemaps

This level of detail also seems to be only available in the UI (once you click on an individual URL and then the In Sitemaps tab). This information is also available in aggregate from the Sitemaps section of the UI (but not as a download — either from the UI or from the API).

Not Followed Errors

The UI shows the URL’s response code (such as 301), which as I noted in my earlier article, is somewhat misleading and not that useful for investigating the error. The report can be misread to mean that 301 response codes are errors. What this report actually provides is a list of URLs that returned either a 301 or 302 response code that Googlebot couldn’t follow due to a problem with the redirect.

The UI-based CSV provides similar data (although not the additional details available in the UI when you click the URL).

The API-based CSV lists “redirect error” for these specific URLs.

That particular error isn’t any more helpful than the response code, but in some cases, this file lists the most specific issue (this detail is one of the pieces of data that used to display in the UI). Possible values include:

For instance, here’s a (slightly obscured) example of a URL with a “redirect URL too long” error:

http://www.example.org/A%20Category%20Page%0A/Www.Sample.Net

%0A/Topic%20Topic1%0A/A%20Category%20Page%20Topic%20Topic1 %0A/Topic%20Topic3%0A/Excercise%0A/Smoothies%0A/Topic2ix%0A/ Topic%20Trainer%0A/Topic3%20Programs%20%0A/Topic%20Assessments %20%0A/Individual%20Or%20Group%20Topic3%20Topic1%20%0A/Topic4 %20Guidance%20%0A/Category2%20Loss%20Supervision%20%0A/Category2 %20Loss%0A/Support%20And%20Motivation%20%0A/Topic9%20Specific %20Category4%20%0A/Cardiovascular%20Category4%20%0A/Topic9%20 Specific%20Category4%20%20%20%0A/Home%20Gym%20Selection%0A/ Home%20Gym%20Use%0A/Topic12%0A/Topic10%20Topic15%20Topic12%0A/ Workout%20Routines%0A/Category2%20Topic1%0A/Topic3%0A/Topic9%0A/ Topic11%20Topic12%0A/Lean%0A/Lean%20Category3%0A/Nutrition%0A/ Gift%20Topic13s%0A/Topic3%20And%20Wellness%0A/Category5%0A/Topic3 %20Programs%20For%20All%20Ages%20%0A/Topic%20Assessments%20%0A/ Individual%20Or%20Group%20Topic1%20%0A/Topic4%20Guidance%20%0A/ Category2%20Loss%20Supervision%20%0A/Support%20And%20Motivation %20%20%0A/Cardio%20%0A/Topic9%20Specific%20Category4%0A/Category2 %20Topic1%0A/Category2%20Topic14%20Routines%0A/Premier%20Topic%20 Trainer%0A/Category2%20Loss%20Help%0A/Safe%20Category2%20Loss%0A/ Wellness%0A/Nutrition%0A/Category3%20Topic3%0A/Exercise%20Health%0A/ Category2%20Loss%20Product%0A/Category6ing%0A/Topic3%20Equipment%0A/ Category2%20Loss%20Supplement%0A/Loose%20Category2%0A/Health%0A/ Healthy%20Category6%0A/Fat%20Loss%0A/Category6%20Plan%0A/Online%20 Topic3%20Program%0A/Topic3%20Center%0A/Gym%20Exercise%0A/Fast%20 Category2%20Loss%0A/Lose%20Category2%20Fast%0A/6%20Topic15%20 Topic12%0A/Home%20Gym%20Equipment%0A/Gym%0A/Topic3%20Course%0A/ Topic3%20Exercise%0A/Gym%20Equipment%0A/Topic3%20Topic1%20Program%0A/ Gym%0A/Exercise%20Program%0A/Category2%20Loss%20Category6%0A/Topic%20 Topic3%0A/Exercise%0A/Sport%20And%20Topic3%0A/Topic3%20Class%0A/Topic %20Topic3%20Trainer%0A/Topic10%20Topic15%20Exercise%0A/Health%20And%20 Topic3%0A/Topic3%20Australia%0A/Category2%20Loss%20Program%0A/Topic3%20 Trainer%0A/Topic%20Topic1%20Topic16%0A/Topic3%0A/Kick%20Topic17%0A/ 6%20Topic15%0A/Category2%20Topic1%0A/Topic%20Trainers%0A/Category2%20 Loss%0A/Topic%20Trainer%0A/Home%20Gym%0A/Topic%20Topic1%0A/Category6 %0A/Quick%20Category2%20Loss%20%0A/Category2%20Loss%20Plan%0A/ Category7%20Category2%20Loss%0A/Easy%20Category2%20Loss%0A/Category2 %20Loss%20Tip%0A/Healthy%20Category2%20Loss%0A/Rapid%20Category2%20 Loss%0A/Topic8%20135%0A/Category2%201

An “invalid” redirect brought me to this page (which was a 302 to a 404):

Empty redirects are those with no location information.

The API-based feed also provides these specifics as part of the feed.

Soft 404s

Gone missing from both the UI and UI-based CSV are the specifics of soft 404s.

The API-based CSV still lists these details (as does the crawl errors feed), such as:

• 404-like content (the page returns a 200 response code, but seems to contain contain from an error page)
• Redirect to an error page

Site-Wide (Server) Errors

With the UI overhaul, Google shows the number of site-based (vs. URL based) errors encountered over time, but not the specific URLs that triggered the errors, and has simplified the error messaging into three types: DNS, server connectivity, and robots.txt fetch. There is no corresponding download. (Google says when they encounter these types of errors, it typically means they’ll receive them for any URL on the site, since the problem is at a lower level.)

There’s some interesting data to be gleaned here that’s not apparent. For instance, if you hover over the dots, you see the total number of Googlebot fetch requests per day. (Unfortunately, you can only see this graph if you Google encounters at least one site error during the reported time period and there’s no way to see this number other than hovering.)  For one site I looked at, the number of URLs crawled averaged around 250,000 per day. Then one day, 2% of requests returned a DNS error (2,866 of 152,528 requests). The following day, Googlebot made only 128 requests (all crawled successfully) and only 71 the day after that. This doesn’t match up exactly what the crawl stats report shows:

Another site went from an average of 100,000 a day to 362 a day after 1% of requests returned a DNS error.

With the API-based CSV file and API-based crawl errors feed, you get:

• The URL that triggered the error
• The specifics of the error

DNS Error

Server Connectivity

Robots.txt Fetch

Pages Blocked with Robots.txt

This report is gone entirely from the UI but it’s still available (up to 100,000 URLs) from the API (both the CSV and the feed).

All in all, I’m happy to learn that most of this information is still available. It’s somewhat cumbersome and confusing that what’s available isn’t consistent across delivery mechanisms and figuring out how to access the API-based data isn’t all that straightforward. But for those power users (like me) who process this data programmatically, that Google is continuing to provide this information is great news.

Update 3/17/12:After talking with Google, I’ve learned that most of what I was disappointed to find had been removed and that I feel is useful detail for power users is in fact still available through the API! I’ve dug into the details and have written up my findings. I’ve also updated this story with additional details from Google:

• Access denied errors include 401, 403, and 407. That some of these were showing up as “other” was a bug that has since been fixed.
• Not followed errors are indeed URLs returned either a 301 or 302 and Googlebot had trouble crawling that redirect due to an issue.

So what’s changed?

Site vs. URL Errors

Crawl errors have been organized into two categories: site errors and URL errors. Site errors are those which are likely site-wide, as opposed to URL-specific.

Site errors are categorized as:

• DNS – These errors include things like DNS lookup timeout, domain name not found, and DNS error. (Although these specifics are no longer listed, as described more below.)
• Server Connectivity – The errors include things like network unreachable, no response, connection refused, and connection reset. (These specifics are also no longer listed.)
• Robots.txt Fetch – These errors are specific to the robots.txt file. If Googlebot receives a server error when trying to access this file, they have no way of knowing if a robots.txt file exists, and if so, what pages it blocks, so they stop the crawl until they no longer get an error when attempting to fetch it.

Google has finally satisfied this request by adding user administration to Google Webmaster Tools.

Now, site owners, who are defined as an owner if they go through the verification process in Google Webmaster Tools, can add access for others without making them go through the verification process. The access granted is either “owner,” “full” or “restricted” access.

• Owner Access – Anyone who has verified the site in Webmaster Tools. This enabled them to add users via the user administration, delete sites, and more super controls.
• Full Access – Granting a user “Full” permission means that they will be able to view all data and take most actions, such as changing site settings or demoting sitelinks.
• Restricted Access – When a user’s permission is set to “Restricted” they will only have access to view most data, and can take some actions such as using Fetch as Googlebot and configuring message forwarding for their account.

You can add users either on the overview page where it says “manage site” and then by clicking on “Add or remove users” or under the “site configuration” section where it says “user administration.”

Those with restricted access will see this label when accessing the tool:

For more details on the access rights based on permission, see this help document.

Related Stories:

• Google Sent Over 700,000 Messages Via Webmaster Tools In Past Two Months
• Google Recommending New Video Schema.org Markup
• Now Test Your Sitemaps Before Submitting Them To Google
• Google Panda 3.2 Update Confirmed
• Google Changes Definition Of Average Search Ranking Position
• Google Revamps Submit Content Page
• Google Webmaster Tools Adds Useful Download Options