Category Archives: Google Webmaster Central Blog

Official news on crawling and indexing sites for the Google index

Sunsetting support for data-vocabulary

Structured data schemas such as schema.org and data-vocabulary.org are used to define shared meaningful structures for markup-based applications on the Web. With the increasing usage and popularity of schema.org we decided to focus our development on a single SD scheme. As of April 6, 2020, data-vocabulary.org markup will no longer be eligible for Google rich result features.

As a preparation for the change and starting today, Search Console will issue warnings for pages using the data-vocabulary.org schema so that you can prepare for the sunset in time. This will allow you to easily identify pages using that markup and replace the data-vocabulary.org markup with schema.org.

A bit more about structured data

Google uses structured data standardized formats and shared schemas to provide information about a page and the things described by the page. This information is used for two main purposes
  1. Understand the content of the page 
  2. Enable special search result features and enhancements

What are structured data formats?

Structured data formats like JSON-LD, RDFa and Microdata define a small number of fixed structures that can be used to encode descriptive data. They typically build upon lower-level standards like JSON and HTML. To learn more about the supported and recommended formats, please check out our developers guide.

What are structured data schemas?

Alongside the structured data formats, structured data schemas work like a kind of dictionary, defining terms for types of thing (e.g. "Person", "Event", "Organization"), and for properties and relationships (e.g. "name", "worksFor"). By maintaining this separation between format and schema, it is possible for users of different formats to take advantage of the same, widely shared, schemas.

Data-vocabulary schema

Google's "Data Vocabulary" project was an important milestone in the development of structured data on the Web, because it led to our collaboration with other search engines to create schema.org. However it is now very outdated and it is generally preferable to use more widely shared vocabulary from Schema.org. Therefore data-vocabulary.org markup will stop being eligible for Google search result features and enhancements.

Please note that this is the only consequence of this change. Pages using data-vocabulary schema will remain valid for all other purposes.

In order to be eligible for Google rich result features we recommend converting your data-vocabulary.org structured data to schema.org.

For example, here is how you would change the data vocabulary to schema.org

Data-vocabulary.org


Schema.org


You can test any code snippet live on Rich Results Test by pasting it into the search box. Try it out! And if you have any questions or comments, check out the Google Webmasters community.

Posted by Dan Brickley, Standards Developer Advocate, and Moshe Samet, Search Console Product Manager

Get Ready for New SameSite=None; Secure Cookie Settings

This is a cross-post from the Chromium developer blog and is specific to how changes to Chrome may affect how your website works for your users in the future.

In May, Chrome announced a secure-by-default model for cookies, enabled by a new cookie classification system (spec). This initiative is part of our ongoing effort to improve privacy and security across the web.
Chrome plans to implement the new model with Chrome 80 in February 2020. Mozilla and Microsoft have also indicated intent to implement the new model in Firefox and Edge, on their own timelines. While the Chrome changes are still a few months away, It’s important that developers who manage cookies assess their readiness today. This blog post outlines high level concepts; please see SameSite Cookies Explained on web.dev for developer guidance.

Understanding Cross-Site and Same-Site Cookie Context


Websites typically integrate external services for advertising, content recommendations, third party widgets, social embeds and other features. As you browse the web, these external services may store cookies in your browser and subsequently access those cookies to deliver personalized experiences or measure audience engagement. Every cookie has a domain associated with it. If the domain associated with a cookie matches an external service and not the website in the user’s address bar, this is considered a cross-site (or “third party”) context.

Less obvious cross-site use cases include situations where an entity that owns multiple websites uses a cookie across those properties. Although the same entity owns the cookie and the websites, this still counts as cross-site or “third party” context when the cookie’s domain does not match the site(s) from which the cookie is accessed.
When an external resource on a web page accesses a cookie that does not match the site domain, this is cross-site or “third-party” context.

In contrast, cookie access in a same-site (or “first party”) context occurs when a cookie’s domain matches the website domain in the user’s address bar. Same-site cookies are commonly used to keep people logged into individual websites, remember their preferences and support site analytics.


When a resource on a web page accesses a cookie that matches the site the user is visiting, this is same-site or “first party” context.

A New Model for Cookie Security and Transparency


Today, if a cookie is only intended to be accessed in a first party context, the developer has the option to apply one of two settings (SameSite=Lax or SameSite=Strict) to prevent external access. However, very few developers follow this recommended practice, leaving a large number of same-site cookies needlessly exposed to threats such as Cross-Site Request Forgery attacks.

To safeguard more websites and their users, the new secure-by-default model assumes all cookies should be protected from external access unless otherwise specified. Developers must use a new cookie setting, SameSite=None, to designate cookies for cross-site access. When the SameSite=None attribute is present, an additional Secure attribute must be used so cross-site cookies can only be accessed over HTTPS connections. This won’t mitigate all risks associated with cross-site access but it will provide protection against network attacks.

Beyond the immediate security benefits, the explicit declaration of cross-site cookies enables greater transparency and user choice. For example, browsers could offer users fine-grained controls to manage cookies that are only accessed by a single site separately from cookies accessed across multiple sites.

Chrome Enforcement Starting in February 2020


With Chrome 80 in February, Chrome will treat cookies that have no declared SameSite value as SameSite=Lax cookies. Only cookies with the SameSite=None; Secure setting will be available for external access, provided they are being accessed from secure connections. The Chrome Platform Status trackers for SameSite=None and Secure will continue to be updated with the latest launch information.

Mozilla has affirmed their support of the new cookie classification model with their intent to implement the SameSite=None; Secure requirements for cross-site cookies in Firefox. Microsoft recently announced plans to begin implementing the model starting as an experiment in Microsoft Edge 80.

How to Prepare; Known Complexities


If you manage cross-site cookies, you will need to apply the SameSite=None; Secure setting to those cookies. Implementation should be straightforward for most developers, but we strongly encourage you to begin testing now to identify complexities and special cases, such as the following:

  • Not all languages and libraries support the None value yet, requiring developers to set the cookie header directly. This Github repository provides instructions for implementing SameSite=None; Secure in a variety of languages, libraries and frameworks.
  • Some browsers, including some versions of Chrome, Safari and UC Browser, might handle the  None value in unintended ways, requiring developers to code exceptions for those clients. This includes Android WebViews powered by older versions of Chrome. Here’s a list of known incompatible clients.
  • App developers are advised to declare the appropriate SameSite cookie settings for Android WebViews based on versions of Chrome that are compatible with the  None value, both for cookies accessed via HTTP(S) headers and via Android WebView's CookieManager API, although the new model will not be enforced on Android WebView until later.
  • Enterprise IT administrators may need to implement special policies to temporarily revert Chrome Browser to legacy behavior if some services such as single sign-on or internal applications are not ready for the February launch.
  • If you have cookies that you access in both a first and third-party context, you might consider using separate cookies to get the security benefits of SameSite=Lax in the first-party context.
SameSite Cookies Explained offers specific guidance for the situations above, and channels for raising issues and questions.

To test the effect of the new Chrome behavior on your site or cookies you manage, you can go to chrome://flags in Chrome 76+ and enable the “SameSite by default cookies” and “Cookies without SameSite must be secure” experiments. In addition, these experiments will be automatically enabled for a subset of Chrome 79 Beta users. Some Beta users with the experiments enabled could experience incompatibility issues with services that do not yet support the new model; users can opt out of the Beta experiments by going to chrome://flags and disabling them.

If you manage cookies that are only accessed in a same-site context (same-site cookies) there is no required action on your part; Chrome will automatically prevent those cookies from being accessed by external entities, even if the SameSite attribute is missing or no value is set. However we strongly recommend you apply an appropriate SameSite value (Lax or Strict) and not rely on default browser behavior since not all browsers protect same-site cookies by default.

Finally, if you’re concerned about the readiness of vendors and others who provide services to your website, you can check for Developer Tools console warnings in Chrome 77+ when a page contains cross-site cookies that are missing the required settings:

A cookie associated with a cross-site resource at (cookie domain) was set without the `SameSite` attribute. A future release of Chrome will only deliver cookies with cross-site requests if they are set with `SameSite=None` and `Secure`. You can review cookies in developer tools under Application Storage Cookies and see more details at https://www.chromestatus.com/feature/5088147346030592 and https://www.chromestatus.com/feature/5633521622188032.
Some providers (including some Google services) will implement the necessary changes in the months leading up to Chrome 80 in February; you may wish to reach out to your partners to confirm their readiness.
Posted by Barb Palser, Chrome and Web Platform Partnerships

The Search Console Training video series is rolling out

A new video series about Google Search Console is rolling out on Youtube now! The series focuses on how to use Search Console to optimize your website for Google Search. In the videos we explain each of the reports available to you, giving examples on where to find data, how to analyze it, and how to fix issues that might affect your search appearance. We’ll have over a dozen episodes focusing on most of the features available on Search Console.

As we finished migrating to the new Search Console in 2019, we knew a detailed training video series would help users learn about the product and its many use cases. Below are the videos we have already released and there are many more to come! Check the Search Console Training playlist for a new video every two weeks and subscribe to the Webmasters YouTube channel to get notified about new video uploads.


I hope that by the end of the series you’ll agree with us that Search Console data is insightful, fun and exciting! Let us know what you think via commenting on videos or tagging us on Twitter.



Posted by Daniel Waisberg, Search Advocate

An update on 2019

With 2020 hanging above our heads much the same way that bricks don't, people start reflecting on what they achieved this year, what went wrong, and how they could improve. We're no different, but instead of choosing what went well or wrong ourselves, we picked the announcements on our @GoogleWMC Twitter account that users interacted with the most, and decided to reflect on those. 

We had launches that you appreciated a lot. For example, we announced at Google I/O that Googlebot is becoming evergreen, meaning that it's always going to use an up-to-date version of Chromium for rendering. We hope that this will make it easier for developers to create stunning, modern, and snappy JavaScript experiences, by tapping onto the power of over 1000 new features and interfaces that are now supported.

Speaking of robots, together with the original author of the Robots Exclusion Protocol, other search engines, and input from webmasters, we submitted an Internet Draft to the IETF in order to start standardizing the 25-year-old protocol. 



Like Twitter users, we also thought it's an exciting project which lays down the rules of crawling for good, although it doesn't change anything for most.

But we haven't stopped there with touching ancient protocols: we also rethought how we need to treat "nofollow" links to keep up with the evolution of the web. It was an announcement that seemed to be welcomed by most Twitter users, and for a good reason: having a "hint" model for rel="nofollow" may help us reward those who create high quality content more, by serving even better results to our users.

One of the most tweeted  – and also most humbling – moments this year was when we lost a part of our index, which caused Search Console to misbehave, and also had rendering failures roughly the same time. Since Google Search works like a well oiled machine most of the time, we didn't have processes to quickly communicate issues to those who should know about them: webmasters. Lacking a proper process and channel to communicate these issues was a mistake and we are still working hard to rectify it, however one thing is clear: we need to do more on the critical communication side of things. 

We do like to communicate, in general: we shoot videos, we go to conferences, big and small, where we reach thousands of webmasters and SEOs, and in 2019 we extended our reach with the Webmaster Conference, which landed in 35 locations around the world in 12 languages. Not to mention the weather reports on our YouTube channel.

We hope you had a fantastic year and the new year will bring you even more success. If you need help with the latter, you can follow our blogs, @googlewmc on Twitter, or you could join us at a Webmaster Conference near you!

Posted by John Mueller, Cheese Connoisseur, and Gary the house elf 


Launching a new Publisher Center

Today we are announcing the launch of Publisher Center to help publishers more easily manage how their content appears across Google products. Publisher Center merges two existing tools, Google News Producer and Google News Publisher Center, improving their user experience and functionality.
Publisher Center’s new features include a simpler way to manage your publication’s identity, like updating light and dark theme logos. It also provides an easier way for those that own multiple publications to organize and switch between them, particularly with improved permission settings that make it easier to collaborate with colleagues. Additionally, publishers can now point to the URLs for their website’s sections instead of RSS to configure sections in Google News. Content for News will now come directly from the web, just as it does for Search.
Publisher Center launches today in the existing four languages of the previous tools (English, Spanish, French, and German) and will expand to more languages soon. Learn more here.
Posted by Eric Silva, Product Manager

Package Tracking Early Access Program

People frequently come to Google Search looking to find information on the status of their packages. To make it easier to find, we have created a new package tracking feature that enables shipping companies to show people the status of their packages right on Search. Here’s an example of how this information may appear:
package tracking search result



Through the package tracking Early Adopters Program, which is available in all countries, shipping companies can sign-up to participate in this feature and give feedback on how to improve it. To take part in the program, a carrier will need to provide a RESTful JSON or XML API that returns the package tracking information. We can work with you to reuse an existing API or setup a new one.

Interested in providing package tracking information to your customers? Please review the full eligibility requirements and fill out the interest form.

If you have any questions, let us know through the forum or on Twitter.
Posted by Allen Harvey, Product Manager

Introducing the new Search Console messages

Search Console sends millions of messages every month. They’re our main way to let you know when your website has a new issue and to make you aware of updates and opportunities to improve your presence on Google.

To make working with messages more efficient in Search Console, we have been working to make messages an integral part of the product. As of today, messages will be available through a panel accessed easily by clicking the bell icon at the top of any page in Search Console. The main difference from the old interface is that now you’ll have access to your messages throughout the product, no need to leave your reports.

You’ll see a notification with the number of new messages on top of the bell icon, as shown below. Click it to see a panel with a list of messages for your site, you can mark one or more messages as read to clear the clutter.

Image: New Search Console Messages

We are also introducing a new way to make messages more actionable by categorizing them into several types, such as Coverage, Enhancement types, Performance, and others. This will make it easier for you to find information about a specific issue.

Image: Categories in Search Console messages

We are also introducing the capability for site owners to access all the messages sent to the site, even those that were previously sent, regardless of when they were verified and when the messages were sent. Now, when users gain access to a new site they can see messages the site have received in the past, which should help the new owners to understand the context for that property.

The message panel shows messages only from May 23, 2019 onward. Messages sent before that date can be viewed only in your personal email or in the legacy message list. Your old messages will be available in the old interface for the time being, you can find them under the “Legacy tools & reports” section in the sidebar.

We hope this new feature improves your workflow and puts all the information you need at your fingertips to make better and faster decisions. If you have any feedback please let us know through the forum or via Twitter.

Posted by Maya Mamo, Haymi Shalom & Yuval Kurtser, Search Console engineering team

Google Search News for November 2019

The ecosystem around and in Google Search has continued to evolve since the first episode of Google Search News. With this video series, we aim to give regular updates on Google Search, in particular for SEOs, publishers, webmasters -- essentially anyone who's creating content with the goal of making it discoverable in search. 

In this episode, we cover:

We hope you find these updates useful! Let us know in the video comments if there's something we can improve on.

Posted by John Mueller, Webmaster Trends Analyst, Google Switzerland

New reporting for Products Results in Search Console

We recently announced that in addition to schema.org markup, product data feeds submitted through Google Merchant Center and Google Manufacturer Center will be used to enrich Google Search shopping journeys. Today, we are announcing a new Search Appearance in the Search Console Performance report, which captures search stats for Product rich results on Google Search.

People come to Google to discover, research, and decide which products and brands to purchase. In order to provide helpful product information to shoppers, Google shows rich product data like product descriptions, price and availability within the search results.

Image: Rich product information on Google Search results

Website owners need to understand the impact of these rich results. The Google Search Console Performance report provides key metrics like clicks and impressions to help webmasters understand and optimize the performance of their website results on Google Search. These metrics can further be segmented by device, geography and queries.

If your website is eligible to appear on Product search results, you’ll find a new Search Appearance type called “Product results”, with which you can segment your traffic to analyze your search performance.

Image: Search Appearance of “Product results”

The new ‘Product results’ search appearance (shown in the screenshot above) will help website owners understand their search performance for product rich results. For example, they’ll be able to answer the following questions:

  • How much traffic comes from experiences with rich data like price, availability?
  • How does shopping traffic change over time, and for what shopping search queries is the website shown?

If you have any questions on this (or other) Search Console reports, let us know through the forum or on Twitter.

Posted by Siddhartha Garg, Product Manager

Get faster with the new Speed report in Search Console

A fast web experience has long been an important user experience factor that we have promoted and advocated for. To help site owners on this quest we showed a preview of the Speed report in Search Console at Google I/O 2019. Since then, we've been iterating on all the great feedback from the beta testers and, starting today, are excited to begin public rollout!

Discovering potential user experience problems can be hard, especially on sites with many pages. To help site owners, the Speed report automatically assigns groups of similar URLs into "Fast", "Moderate", and "Slow" buckets. The data is based on the Chrome User Experience Report, which provides user experience metrics for how real-world Chrome users experience popular destinations on the web.

Image: Speed report overview
The report classifies URLs by speed and the issue that causes any slowdowns. Drill down on a specific issue to see examples of slow URLs to help you prioritize performance improvements for them. To get a better sense of what type of optimization can be performed for a specific URL, the report links to the Page Speed Insight tool, which provides information on specific optimization opportunities.

You should use this report both for monitoring your performance over time and for tracking fixes you made to your website. If you fix an issue, use the report to track whether users experienced a performance improvement when browsing the fixed version of your website.

To help you understand how your site is performing, you can also see what types of URLs are doing better by checking the moderate and fast buckets.

Image: URLs in the fast bucket

This new report is classified as "experimental" as we plan to continue to iterate and improve the metrics and recommendations for site owners. We will monitor feedback submitted directly through the report and in the user forum to ensure that it is useful and helpful, so please let us know how we are doing.

Posted By Sion Schori & Amir Rachum, Software Engineers