Official Google Webmaster Central Blog: webmaster tools

Rolling out the red carpet for app owners in Search Console

Friday, May 22, 2015

Wouldn’t it be nifty if you could track where your indexed app content shows up in search results, for which queries, which app pages are most popular, and which ones have errors? Yeah, we thought so too! So we’ve equipped our freshly renamed Search Console with new reports to show you how Google understands and treats your app content in search results.
Our goal is to make Search Console a comprehensive source of information for everyone who cares about search, regardless of the format of their content. So, if you own or develop an app, Search Console is your new go-to place for search stats.

Add your app to Search Console

Simply open Search Console and enter your app name: android-app://com.example. Of course, we’ll only show data to authorized app owners, so you need to use your Google Play account to let Search Console know you have access to the app. If you don’t have access to your app in Google Play, ask an owner to verify the app in Search Console and add you next.

Connect your site to your app

Associating your site with your app is necessary for App Indexing to work. Plus, it helps with understanding and ranking the app content better.

Track your app content’s performance in search

The new Search Analytics report provides detailed information on top queries, top app pages, and traffic by country. It also has a comprehensive set of filters, allowing you to narrow down to a specific query type or region, or sort by clicks, impressions, CTR, and positions.

Use the Search Analytics report to compare which app content you consider most important with the content that actually shows up in search and gets the most clicks. If they match, you’re on the right track! Your users are finding and liking what you want them to see. If there’s little overlap, you may need to restructure your navigation, or make the most important content easier to find. Also worth checking in this case: have you provided deep links to all the app content you want your users to find?

Make sure Google understands your app content

If we encounter errors while indexing your app content, we won’t be able to show deep links for those app pages in search results. The Crawl Errors report will show you the type and number of errors we’ve detected.

See your app content the way Google sees it

We’ve created an alpha version of the Fetch as Google tool for apps to help you check if an app URI works and see how Google renders it. It can also be useful for comparing the app content with the webpage content to debug errors such as content mismatch. In many cases, the mismatch errors are caused by blocked resources within the app or by pop-ups asking users to sign in or register. Now you can see and resolve these issues.

To get started on optimizing and troubleshooting your own app, add it to Search Console now. If you want to know more about App Indexing, read about it on our Developer Site. And, as always, you’re welcome to drop by the help forum with more questions.

Posted by:
Hillel Maoz, Engineering Lead, Search Console Team (favorite app: Flipboard) and
Mariya Moeva, Webmaster Trends Analyst (favorite app: Spotify)

Announcing Google Search Console - the new Webmaster Tools

Wednesday, May 20, 2015

For nearly ten years, Google Webmaster Tools has provided users with constantly evolving tools and metrics to help make fantastic websites that our systems love showing in Google Search. In the past year, we sought to learn more about you, the loyal users of Google Webmaster Tools: we wanted to understand your role and goals in order to make our product more useful to you.

It turns out that the traditional idea of the “webmaster” reflects only some of you. We have all kinds of Webmaster Tools fans: hobbyists, small business owners, SEO experts, marketers, programmers, designers, app developers, and, of course, webmasters as well. What you all share is a desire to make your work available online, and to make it findable through Google Search. So, to make sure that our product includes everyone who cares about Search, we've decided to rebrand Google Webmaster Tools as Google Search Console.

We're looking forward to an exciting future with Google Search Console, and hope to see users of all types—including webmasters—drop by and use our service to diagnose and improve the visibility of their content in search. We'll be rolling out the updated branding across the product over the coming weeks, so stay tuned.

Just come over to g.co/SearchConsole and get started!

Posted by Michael Fink, product manager Google Search Console

More precise data in the new Search Analytics report

Wednesday, May 06, 2015

If you manage a website, you need a deep understanding of how users find your site and how your content appears on Google's search results. Until now, this data was shown in the Search Queries report, probably the most used feature in Webmaster Tools. Over the years, we’ve been listening to your feedback and features requests. How many of you wished they could compare traffic on desktop and mobile? How many of you needed to compare metrics in different countries? or in two different time frames?

We’ve heard you! Today, we’re very happy to announce Search Analytics, the new report in Google Webmaster Tools that will allow you to make the most out of your traffic analysis.
The new Search Analytics report enables you to break down your site's search data and filter it in many different ways in order to analyze it more precisely. For instance, you can now compare your mobile traffic before and after the April 21st Mobile update, to see how it affected your traffic.

Or, if you have an international website, you can now find the countries where people search most for your brand: choose “impressions” as your metric, filter by your brand name, and group results by country to show a sorted list of impressions by country.

These use cases are just two examples out of many more. Search Analytics allows you to really dig deeper into your traffic analysis and helps you make the best decisions for your website’s performance.

There are some differences between Search Analytics and Search Queries. Data in the Search Analytics report is much more accurate than data in the older Search Queries report, and it is calculated differently. To learn more read out Search Analytics Help Center article’s section about data. Because we understand that some of you will still need to use the old report, we’ve decided to leave it available in Google Webmaster Tools for three additional months. To learn more about the new report, please read our Search Analytics Help Center article.

We hope you find the new Search Analytics report useful for your traffic analysis. Please share your feedback in the comments below or on our Google Webmasters Google+ page. As usual, if you have any question or need help with the report, feel free to post in our Webmasters Help Forum.

Last but not least, we sincerely thank all the Trusted Testers and webmaster forums’ Top Contributors who spent time testing the alpha version of Search Analytics, and who helped us create such a good report: we wouldn’t have made it that great without your constant feedback and suggestions. Thank you for being so amazing!

Posted by Zineb, on behalf of the awesome Google Webmaster Tools engineers and UX designers.

Deprecation of the old Webmaster Tools API

Thursday, March 12, 2015

Last fall we announced the new Webmaster Tools API, which helps you to automate a number of important aspects using code. With the pending shutdown of ClientLogin, we're going to turn down the old Webmaster Tools API on April 20, 2015. If you're still using the old API, getting started with the new one is fairly easy. The new API covers everything from the old version except for messages and keywords. We have examples in Python, Java, as well as OACurl (for command-line fans & quick testing). Additionally, there's the Site Verification API to add sites programmatically to your account. The Python search query data download will continue to be available for the moment, and replaced by an API in the upcoming quarters. As always, should you have any questions, feel free to comment here, or post in our Webmaster Help Forum. Posted by John Mueller, fan of command lines & APIs, Google Zuerich

Unblocking resources with Webmaster Tools

Wednesday, March 11, 2015

Webmasters often use linked images, CSS, and JavaScript files in web pages to make them pretty and functional. If these resources are blocked from crawling, then Googlebot can't use them when it renders those pages for search. Google Webmaster Tools now includes a Blocked Resources Report to help you find and resolve these kinds of issues.

This report starts with the names of the hosts from which your site is using blocked resources such as JavaScript, CSS, and images. Clicking on the rows gives you the list of blocked resources and then the pages that embed them, guiding you through the steps to diagnose and resolve how we're able to crawl and index the page's content. An update to Fetch and Render shows how these blocked resources matter. When you request a URL be fetched and rendered, it now shows screenshots rendered both as Googlebot and as a typical user. This makes it easier to recognize the issues that significantly influence why your pages are seen differently by Googlebot.Webmaster Tools attempts to show you only the hosts that you might have influence over, so at the moment, we won't show hosts that are used by many different sites (such as popular analytics services). Because it can be time-consuming (usually not for technical reasons!) to update all robots.txt files, we recommend starting with the resources that make the most important visual difference when blocked. Our Help Center article has more information on the steps involved.We hope this new feature makes it easier for you to spot and then unblock resources used by your website! Should you have any questions, feel free to drop by our webmaster help forums.Posted by John Mueller, Webmaster Trends Analyst, Google Switzerland

The four steps to appiness

Tuesday, December 09, 2014

Webmaster Level: intermediate to advanced

App deep links are the new kid on the block in organic search, and they’re picking up speed faster than you can say “schema.org ViewAction”! For signed-in users, 15% of Google searches on Android now return deep links to apps through App Indexing. And over just the past quarter, we've seen the number of clicks on app deep links jump by 10x.

We’ve gotten a lot of feedback from developers and seen a lot of implementations gone right and others that were good learning experiences since we opened up App Indexing back in June. We’d like to share with you four key steps to monitor app performance and drive user engagement:

1. Give your app developer access to Webmaster Tools

App indexing is a team effort between you (as a webmaster) and your app development team. We show information in Webmaster Tools that is key for your app developers to do their job well. Here’s what’s available right now:

Errors in indexed pages within apps
Weekly clicks and impressions from app deep link via Google search
Stats on your sitemap (if that’s how you implemented the app deep links)

...and we plan to add a lot more in the coming months!

We’ve noticed that very few developers have access to Webmaster Tools. So if you want your app development team to get all of the information they need to fix app-related issues, it’s essential for them to have access to Webmaster Tools.

Any verified site owner can add a new user. Pick restricted or full permissions, depending on the level of access you’d like to give:

2. Understand how your app is doing in search results

How are users engaging with your app from search results? We’ve introduced two new ways for you to track performance for your app deep links:

We now send a weekly clicks and impressions update to the Message center in your Webmaster Tools account.
You can now track how much traffic app deep links drive to your app using referrer information - specifically, the referrer extra in the ACTION_VIEW intent. We're working to integrate this information with Google Analytics for even easier access. Learn how to track referrer information on our Developer site.

3. Make sure key app resources can be crawled

Blocked resources are one of the top reasons for the “content mismatch” errors you see in Webmaster Tools’ Crawl Errors report. We need access to all the resources necessary to render your app page. This allows us to assess whether your associated web page has the same content as your app page.

To help you find and fix these issues, we now show you the specific resources we can’t access that are critical for rendering your app page. If you see a content mismatch error for your app, look out for the list of blocked resources in “Step 5” of the details dialog:

4. Watch out for Android App errors

To help you identify errors when indexing your app, we’ll send you messages for all app errors we detect, and will also display most of them in the “Android apps” tab of the Crawl errors report.

In addition to the currently available “Content mismatch” and “Intent URI not supported” error alerts, we’re introducing three new error types:

APK not found: we can’t find the package corresponding to the app.
No first-click free: the link to your app does not lead directly to the content, but requires login to access.
Back button violation: after following the link to your app, the back button did not return to search results.

In our experience, the majority of errors are usually caused by a general setting in your app (e.g. a blocked resource, or a region picker that pops up when the user tries to open the app from search). Taking care of that generally resolves it for all involved URIs.

Good luck in the pursuit of appiness! As always, if you have questions, feel free to drop by our Webmaster help forum.

Posted by Mariya Moeva, Webmaster Trends Analyst

Tracking mobile usability in Webmaster Tools

Wednesday, October 29, 2014

Webmaster Level: intermediateMobile is growing at a fantastic pace - in usage, not just in screen size. To keep you informed of issues mobile users might be seeing across your website, we've added the Mobile Usability feature to Webmaster Tools. The new feature shows mobile usability issues we’ve identified across your website, complete with graphs over time so that you see the progress that you've made. A mobile-friendly site is one that you can easily read & use on a smartphone, by only having to scroll up or down. Swiping left/right to search for content, zooming to read text and use UI elements, or not being able to see the content at all make a site harder to use for users on mobile phones. To help, the Mobile Usability reports show the following issues: Flash content, missing viewport (a critical meta-tag for mobile pages), tiny fonts, fixed-width viewports, content not sized to viewport, and clickable links/buttons too close to each other.

We strongly recommend you take a look at these issues in Webmaster Tools, and think about how they might be resolved; sometimes it's just a matter of tweaking your site's template! More information on how to make a great mobile-friendly website can be found in our Web Fundamentals website (with more information to come soon).If you have any questions, feel free to join us in our webmaster help forums (on your phone too)!Posted by John Mueller, Webmaster Trends Analyst, Zurich

An update to the Webmaster Tools API

Thursday, September 11, 2014

Webmaster level: advanced

Over the summer the Webmaster Tools team has been cooking up an update to the Webmaster Tools API. The new API is consistent with other Google APIs, makes it easier to authenticate for apps or web-services, and provides access to some of the main features of Webmaster Tools.

If you've used other Google APIs, getting started with the new Webmaster Tools API will be easy! We have examples for Python, Java, as well as OACurl (for fans of command lines).

This API allows you to:

list, add, or remove sites from your account (you can currently have up to 500 sites in your account)
list, add, or remove sitemaps for your websites
get warning, error, and indexed counts for individual sitemaps
get a time-series of all kinds of crawl errors for your site
list crawl error samples for specific types of errors
mark individual crawl errors as "fixed" (this doesn't change how they're processed, but can help simplify the UI for you)

We'd love to see what you're building with our APIs! Feel free to link to your projects in the comments below. Should you have any questions about the usage of the API, feel free to post in our help forum as well.

Posted by John Mueller, fan of long command lines, Google Zürich

Introducing the Google News Publisher Center

Monday, August 04, 2014

(Cross-posted on the Google News Blog)

Webmaster level: All

UPDATE: Great News -- The Publisher Center is now available in all countries where Google News has an edition.

If you're a news publisher, your website has probably evolved and changed over time -- just like your stories. But in the past, when you made changes to the structure of your site, we might not have discovered your new content. That meant a lost opportunity for your readers, and for you. Unless you regularly checked Webmaster Tools, you might not even have realized that your new content wasn’t showing up in Google News. To prevent this from happening, we are letting you make changes to our record of your news site using the just launched Google News Publisher Center.

With the Publisher Center, your potential readers can be more informed about the articles they’re clicking on and you benefit from better discovery and classification of your news content. After verifying ownership of your site using Google Webmaster Tools, you can use the Publisher Center to directly make the following changes:

Update your news site details, including changing your site name and labeling your publication with any relevant source labels (e.g., “Blog”, “Satire” or “Opinion”)
Update your section URLs when you change your site structure (e.g., when you add a new section such as http://example.com/2014commonwealthgames or http://example.com/elections2014)
Label your sections with a specific topic (e.g., “Technology” or “Politics”)

Whenever you make changes to your site, we’d recommend also checking our record of it in the Publisher Center and updating it if necessary.

Try it out, or learn more about how to get started.

At the moment the tool is only available to publishers in the U.S. but we plan to introduce it in other countries soon and add more features. In the meantime, we’d love to hear from you about what works well and what doesn’t. Ultimately, our goal is to make this a platform where news publishers and Google News can work together to provide readers with the best, most diverse news on the web.

Posted by Eric Weigle, Software Engineer

Testing robots.txt files made easier

Wednesday, July 16, 2014

Webmaster level: intermediate-advancedTo crawl, or not to crawl, that is the robots.txt question.Making and maintaining correct robots.txt files can sometimes be difficult. While most sites have it easy (tip: they often don't even need a robots.txt file!), finding the directives within a large robots.txt file that are or were blocking individual URLs can be quite tricky. To make that easier, we're now announcing an updated robots.txt testing tool in Webmaster Tools.You can find the updated testing tool in Webmaster Tools within the Crawl section:

Here you'll see the current robots.txt file, and can test new URLs to see whether they're disallowed for crawling. To guide your way through complicated directives, it will highlight the specific one that led to the final decision. You can make changes in the file and test those too, you'll just need to upload the new version of the file to your server afterwards to make the changes take effect. Our developers site has more about robots.txt directives and how the files are processed. Additionally, you'll be able to review older versions of your robots.txt file, and see when access issues block us from crawling. For example, if Googlebot sees a 500 server error for the robots.txt file, we'll generally pause further crawling of the website. Since there may be some errors or warnings shown for your existing sites, we recommend double-checking their robots.txt files. You can also combine it with other parts of Webmaster Tools: for example, you might use the updated Fetch as Google tool to render important pages on your website. If any blocked URLs are reported, you can use this robots.txt tester to find the directive that's blocking them, and, of course, then improve that. A common problem we've seen comes from old robots.txt files that block CSS, JavaScript, or mobile content — fixing that is often trivial once you've seen it.We hope this updated tool makes it easier for you to test & maintain the robots.txt file. Should you have any questions, or need help with crafting a good set of directives, feel free to drop by our webmaster's help forum!Posted by Asaph Arnon, Webmaster Tools team

Troubleshooting hreflang annotations in Webmaster Tools

Monday, July 14, 2014

If you are targeting users in more than one country, chances are you already heard about rel-alternate-hreflang. If you haven't, in short, this annotation enables Google and other search engines to serve the correct language or regional version of pages to searchers, which can lead to increased user satisfaction.

Making sure the deployed annotations are usable by search engines can be rather difficult, especially on sites with many pages, and site owners all around the world haven’t been shy telling us about this. Today we're releasing a feature that should make debugging rel-alternate-hreflang annotations much easier.

The Language Targeting section in the International Targeting feature enables you to identify two of the most common issues with hreflang annotations:

Missing return links: annotations must be confirmed from the pages they are pointing to. If page A links to page B, page B must link back to page A, otherwise the annotations may not be interpreted correctly.
For each error of this kind we report where and when we detected them, as well as where the return link is expected to be.

Incorrect hreflang values: The value of the hreflang attribute must either be a language code in ISO 639-1 format such as "es", or a combination of language and country code such as "es-AR", where the country code is in ISO 3166-1 Alpha 2 format.
In case our indexing systems detect language or country codes that are not in these formats, we provide example URLs to help you fix them.

Additionally, we've moved the geographic targeting setting to this part of Webmaster Tools, so that you can find all information relevant to international and multilingual targeting in the same place.

We hope you'll find this new feature useful and that it helps you to identify issues with the rel-hreflang-implementation on your site. If you have comments or questions about the feature, please post in our Webmaster Help Forum.

Posted by Gary Illyes, Webmaster Trends

Android app indexing is now open for everyone!

Wednesday, June 25, 2014

Webmaster level: All

Do you have an Android app in addition to your website? You can now connect the two so that users searching from their smartphones and tablets can easily find and reach your app content.

App deep links in search results help your users find your content more easily and re-engage with your app after they’ve installed it. As a site owner, you can show your users the right content at the right time — by connecting pages of your website to the relevant parts of your app you control when your users are directed to your app and when they go to your website.

Hundreds of apps have already implemented app indexing. This week at Google I/O, we’re announcing a set of new features that will make it even easier to set up deep links in your app, connect your site to your app, and keep track of performance and potential errors.

Getting started is easy

We’ve greatly simplified the process to get your app deep links indexed. If your app supports HTTP deep linking schemes, here’s what you need to do:

As we index your URLs, we’ll discover and index the app / site connections and may begin to surface app deep links in search results.

We can discover and index your app deep links on our own, but we recommend you publish the deep links. This is also the case if your app only supports a custom deep link scheme. You can publish them in one of the following ways:

Add a rel=alternate <link> element to specify the corresponding app URI.
You can insert it in the <head> section of each web page, or in your sitemap. Find out how to implement these methods on our developer site.
Use the App indexing API

There’s one more thing: we’ve added a new feature in Webmaster Tools to help you debug any issues that might arise during app indexing. It will show you what type of errors we’ve detected for the app page-web page pairs, together with example app URIs so you can debug:

We’ll also give you detailed instructions on how to debug each issue, including a QR code for the app deep links, so you can easily open them on your phone or tablet. We’ll send you Webmaster Tools error notifications as well, so you can keep up to date.

Give app indexing a spin, and as always, if you need more help ask questions on the Webmaster help forum.

Posted by Mariya Moeva, Webmaster Trends Analyst

Directing smartphone users to the page they actually wanted

Wednesday, June 04, 2014

Webmaster level: all

Have you ever used Google Search on your smartphone and clicked on a promising-looking result, only to end up on the mobile site’s homepage, with no idea why the page you were hoping to see vanished? This is such a common annoyance that we’ve even seen comics about it. Usually this happens because the website is not properly set up to handle requests from smartphones and sends you to its smartphone homepage—we call this a “faulty redirect”.

We’d like to spare users the frustration of landing on irrelevant pages and help webmasters fix the faulty redirects. Starting today in our English search results in the US, whenever we detect that smartphone users are redirected to a homepage instead of the the page they asked for, we may note it below the result. If you still wish to proceed to the page, you can click “Try anyway”:

And we’re providing advice and resources to help you direct your audience to the pages they want. Here’s a quick rundown:

1. Do a few searches on your own phone (or with a browser set up to act like a smartphone) and see how your site behaves. Simple but effective. :)

2. Check out Webmaster Tools—we’ll send you a message if we detect that any of your site’s pages are redirecting smartphone users to the homepage. We’ll also show you any faulty redirects we detect in the Smartphone Crawl Errors section of Webmaster Tools:

3. Investigate any faulty redirects and fix them. Here’s what you can do:

Use the example URLs we provide in Webmaster Tools as a starting point to debug exactly where the problem is with your server configuration.
Set up your server so that it redirects smartphone users to the equivalent URL on your smartphone site.
If a page on your site doesn’t have a smartphone equivalent, keep users on the desktop page, rather than redirecting them to the smartphone site’s homepage. Doing nothing is better than doing something wrong in this case.
Try using responsive web design, which serves the same content for desktop and smartphone users.

If you’d like to know more about building smartphone-friendly sites, read our full recommendations. And, as always, if you need more help you can ask a question in our webmaster forum.

Posted by Mariya Moeva, Webmaster Trends Analyst

Rendering pages with Fetch as Google

Tuesday, May 27, 2014

Webmaster level: all

The Fetch as Google feature in Webmaster Tools provides webmasters with the results of Googlebot attempting to fetch their pages. The server headers and HTML shown are useful to diagnose technical problems and hacking side-effects, but sometimes make double-checking the response hard: Help! What do all of these codes mean? Is this really the same page as I see it in my browser? Where shall we have lunch? We can't help with that last one, but for the rest, we've recently expanded this tool to also show how Googlebot would be able to render the page.

Viewing the rendered page

In order to render the page, Googlebot will try to find all the external files involved, and fetch them as well. Those files frequently include images, CSS and JavaScript files, as well as other files that might be indirectly embedded through the CSS or JavaScript. These are then used to render a preview image that shows Googlebot's view of the page.

You can find the Fetch as Google feature in the Crawl section of Google Webmaster Tools. After submitting a URL with "Fetch and render," wait for it to be processed (this might take a moment for some pages). Once it's ready, just click on the response row to see the results.

Handling resources blocked by robots.txt

Googlebot follows the robots.txt directives for all files that it fetches. If you are disallowing crawling of some of these files (or if they are embedded from a third-party server that's disallowing Googlebot's crawling of them), we won't be able to show them to you in the rendered view. Similarly, if the server fails to respond or returns errors, then we won't be able to use those either (you can find similar issues in the Crawl Errors section of Webmaster Tools). If we run across either of these issues, we'll show them below the preview image.

We recommend making sure Googlebot can access any embedded resource that meaningfully contributes to your site's visible content, or to its layout. That will make Fetch as Google easier for you to use, and will make it possible for Googlebot to find and index that content as well. Some types of content – such as social media buttons, fonts or website-analytics scripts – tend not to meaningfully contribute to the visible content or layout, and can be left disallowed from crawling. For more information, please see our previous blog post on how Google is working to understand the web better.

We hope this update makes it easier for you to diagnose these kinds of issues, and to discover content that's accidentally blocked from crawling. If you have any comments or questions, let us know here or drop by in the webmaster help forum.

Posted by Shimi Salant, Webmaster Tools team

More Precise Index Status Data for Your Site Variations

Monday, March 31, 2014

Webmaster Level: Intermediate

The Google Webmaster Tools Index Status feature reports how many pages on your site are indexed by Google. In the past, we didn’t show index status data for HTTPS websites independently, but rather we included everything in the HTTP site’s report. In the last months, we’ve heard from you that you’d like to use Webmaster Tools to track your indexed URLs for sections of your website, including the parts that use HTTPS.

We’ve seen that nearly 10% of all URLs already use a secure connection to transfer data via HTTPS, and we hope to see more webmasters move their websites from HTTP to HTTPS in the future. We’re happy to announce a refinement in the way your site’s index status data is displayed in Webmaster Tools: the Index Status feature now tracks your site’s indexed URLs for each protocol (HTTP and HTTPS) as well as for verified subdirectories.

This makes it easy for you to monitor different sections of your site. For example, the following URLs each show their own data in Webmaster Tools Index Status report, provided they are verified separately:

HTTP	HTTPS
http://www.example.com/	https://www.example.com/
http://example.com	https://example.com
http://www.example.com/folder/	https://www.example.com/folder/
http://example.com/folder/	https://example.com/folder/

The refined data will be visible for webmasters whose site's URLs are on HTTPS or who have subdirectories verified, such as https://example.com/folder/. Data for subdirectories will be included in the higher-level verified sites on the same hostname and protocol.

If you have a website on HTTPS or if some of your content is indexed under different subdomains, you will see a change in the corresponding Index Status reports. The screenshots below illustrate the changes that you may see on your HTTP and HTTPS sites’ Index Status graphs for instance:

HTTP site’s Index Status showing drop

HTTPS site’s Index Status showing increase

An “Update” annotation has been added to the Index Status graph for March 9th, showing when we started collecting this data. This change does not affect the way we index your URLs, nor does it have an impact on the overall number of URLs indexed on your domain. It is a change that only affects the reporting of data in Webmaster Tools user interface.

In order to see your data correctly, you will need to verify all existing variants of your site (www., non-www., HTTPS, subdirectories, subdomains) in Google Webmaster Tools. We recommend that your preferred domains and canonical URLs are configured accordingly.

Note that if you wish to submit a Sitemap, you will need to do so for the preferred variant of your website, using the corresponding URLs. Robots.txt files are also read separately for each protocol and hostname.

We hope that you’ll find this update useful, and that it’ll help you monitor, identify and fix indexing problems with your website. You can find additional details in our Index Status Help Center article. As usual, if you have any questions, don’t hesitate to ask in our webmaster Help Forum.

Posted by Zineb Ait Bahajji, WTA, thanks to the Webmaster Tools team.

Changes in crawl error reporting for redirects

Wednesday, January 22, 2014

Webmaster level: intermediate-advanced

In the past, we have seen occasional confusion by webmasters regarding how crawl errors on redirecting pages were shown in Webmaster Tools. It's time to make this a bit clearer and easier to diagnose! While it used to be that we would report the error on the original - redirecting - URL, we'll now show the error on the final URL - the one that actually returns the error code.

Let's look at an example:

URL A redirects to URL B, which in turn returns an error. The type of redirect, and type of error is unimportant here.

In the past, we would have reported the error observed at the end under URL A. Now, we'll instead report it as URL B. This makes it much easier to diagnose the crawl errors as they're shown in Webmaster Tools. Using tools like cURL or your favorite online server header checker, you can now easily confirm that this error is actually taking place on URL B.

This change may also be visible in the total error counts for some websites. For example, if your site is moving to a new domain, you'll only see these errors for the new domain (assuming the old domain redirects correctly), which might result in noticeable changes in the total error counts for those sites.

Note that this change only affects how these crawl errors are shown in Webmaster Tools. Also, remember that having crawl errors for URLs that should be returning errors (e.g. they don't exist) does not negatively affect the rest of the website's indexing or ranking (also as discussed on Google+).

We hope this change makes it a bit easier to track down crawl errors, and to clean up the accidental ones that you weren't aware of! If you have any questions, feel free to post here, or drop by in the Google Webmaster Help Forum.

Posted by John Mueller, Website Error Analyst

Google Publisher Plugin beta: Bringing our publisher products to WordPress

Wednesday, January 15, 2014

Cross-posted from the Inside AdSense blog.

We’ve heard from many publishers using WordPress that they’re looking for an easier way to work with Google products within the platform. Today, we’re excited to share the beta release of our official Google Publisher Plugin, which adds new functionality to publishers’ WordPress websites. If you own your own domain and power it with WordPress, this new plugin will give you access to a few Google services — and all within WordPress.

Please keep in mind that because this is a beta release, we’re still fine-tuning the plugin to make sure it works well on the many WordPress sites out there. We’d love for you to try it now and share your feedback on how it works for your site.

This first version of the Google Publisher Plugin currently supports two Google products:

Visit the WordPress.org plugin directory to download the new plugin and give it a try. For more information about the plugin and how to use it, please visit our Help Center. We look forward to hearing your feedback!

Posted by Michael Smith - Product Manager

More detailed search queries in Webmaster Tools

Tuesday, January 07, 2014

Webmaster level: intermediate

To help jump-start your year and make metrics for your site more actionable, we've updated one of the most popular features in Webmaster Tools: data in the search queries feature will no longer be rounded / bucketed. This change will become visible over the next few days.

The search queries feature gives insights into the searches that have at least one page from your website shown in the search results. It collects these "impressions" together with the times when users visited your site - the "clicks" - and displays these for the last 90 days.

Before and after:

We hope this makes it easier for you to see the finer details of how users are finding your website, and when they're clicking through. Should you have any questions, feel free to visit our help forum.

Posted by John Mueller, frequent searcher & Webmaster Trends Analyst, Google Switzerland

Improved Search Queries stats for separate mobile sites

Tuesday, January 07, 2014

Webmaster ToolsSearch Queries

Queries where your m. pages appeared in search results for mobile browsers

Queries where Google applied Skip Redirect. This means that, while search results displayed the desktop URL, the user was automatically directed to the corresponding m. version of the URL (thus saving the user from latency of a server-side redirect).

Skip Redirect information (impressions, clicks, etc.) calculated with mobile site.Best practices if you have a separate m. site

Follow our advice on Building Smartphone-Optimized Websites

On the desktop page, add a special link rel="alternate" tag pointing to the corresponding mobile URL. This helps Googlebot discover the location of your site's mobile pages.
On the mobile page, add a link rel="canonical" tag pointing to the corresponding desktop URL.
Use the HTTP Vary: User-Agent header if your servers automatically redirect users based on their user agent/device.

Verify ownership of both the desktop (www) and mobile (m.) sites in Webmaster Tools for improved communication and troubleshooting information specific to each site.

Written by Maile Ohye, Developer Programs Tech Lead

Structured Data dashboard: new markup error reports for easier debugging

Thursday, December 12, 2013

Since we launched the Structured Data dashboard last year, it has quickly become one of the most popular features in Webmaster Tools. We’ve been working to expand it and make it even easier to debug issues so that you can see how Google understands the marked-up content on your site.Starting today, you can see items with errors in the Structured Data dashboard. This new feature is a result of a collaboration with webmasters, whom we invited in June to>register as early testers of markup error reporting in Webmaster Tools. We’ve incorporated their feedback to improve the functionality of the Structured Data dashboard.An “item” here represents one top-level structured data element (nested items are not counted) tagged in the HTML code. They are grouped by data type and ordered by number of errors:

We’ve added a separate scale for the errors on the right side of the graph in the dashboard, so you can compare items and errors over time. This can be useful to spot connections between changes you may have made on your site and markup errors that are appearing (or disappearing!).Our data pipelines have also been updated for more comprehensive reporting, so you may initially see fewer data points in the chronological graph.How to debug markup implementation errors

To investigate an issue with a specific content type, click on it and we’ll show you the markup errors we’ve found for that type. You can see all of them at once, or filter by error type using the tabs at the top:

Check to see if the markup meets the implementation guidelines for each content type. In our example case (events markup), some of the items are missing a startDate or name property. We also surface missing properties for nested content types (e.g. a review item inside a product item) — in this case, this is the lowprice property.

Click on URLs in the table to see details about what markup we’ve detected when we crawled the page last and what’s missing. You’ll can also use the “Test live data” button to test your markup in the Structured Data Testing Tool. Often when checking a bunch of URLs, you’re likely to spot a common issue that you can solve with a single change (e.g. by adjusting a setting or template in your content management system).

Fix the issues and test the new implementation in the Structured Data Testing Tool. After the pages are recrawled and reprocessed, the changes will be reflected in the Structured Data dashboard.

We hope this new feature helps you manage the structured data markup on your site better. We will continue to add more error types in the coming months. Meanwhile, we look forward to your comments and questions here or in the dedicated Structured Data section of the Webmaster Help forum.Posted by Mariya Moeva, Webmaster Trends Analyst

Webmaster Central Blog