We hope the year 2020 has started off well for you, and wanted to bring a brief update of some of the changes around Google Search since our last episode. We aim to do this in our YouTube Series called Google Search News.

In the January 2020 episode, we cover:

• Updates in Search Console, a free tool from Google to help you succeed with your website in Google Search. Since the last episode, we celebrated the two-year anniversary of the new Search Console, updated the Discover report, and made the Index Coverage report more comprehensive. Another big change was the new messaging system, which integrates directly with various reports.
• Updated Mobile-First Indexing documentation and some tips, such as making sure your mobile site reflects your full content (we won't use the desktop version at all, once we switch your site over). Also, if you use separate mobile URLs (commonly called m-dot URLs), make sure to use them consistently within your structured data too.
• The deprecation of support for data-vocabulary.org structured data was recently announced. This markup was mostly used for breadcrumb markup, so if you added that early on, you should double-check the breadcrumb report in Search Console.
• We make regular updates in Google Search -- our website on How Search Works has more on the backgrounds, if you're curious. In this episode we covered BERT - a modern way for computers to understand natural language - as well as various updates mentioned on our Search Liaison & Webmaster Central Twitter profiles.
• Chrome has posted on its handling of mixed-content, and we started sending notices to sites using old HTTPS / TLS protocols.
• Googlebot's rendering has continued to move forward with the new user-agent, which is being used more and more for crawling.
• and, last but not least, if you'd like to find out more about Search Console, check out our new Search Console training video series!

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

Posted by John Mueller, Google Search-Relations team, Zurich

We’re happy to announce that we’re launching a new version of the Removals report in Search Console, which enables site owners to temporarily hide a page from appearing in Google Search results. The new report also provides info on pages on your site that have been reported via other Google public tools.

There are different tools available for you to report and remove information from Google, in this post we’ll focus on three areas that will be part of the new Search Console report: temporary removals, outdated content and SafeSearch filtering requests.
Temporary removals A temporary removal request is a way to remove specific content on your site from Google Search results. For example, if you have a URL that you need to take off Google Search quickly, you should use this tool. A successful request lasts about six months, which should be enough for you to find a permanent solution. You have two types of requests available:

• Temporary remove URL will hide the URL from Google Search results for about six months and clear the cached copy of the page.
• Clear cache URL clears the cached page and wipes out the page description snippet in Search results until the page is crawled again.

Outdated content The outdated content section provides information on removal requests made through the public Remove Outdated Content tool, which can be used by anyone (not just site owners) to update search results showing information that is no longer present on a page.

SafeSearch filtering The SafeSearch filtering section in Search Console shows a history of pages on your site that were reported by Google users as adult content using the SafeSearch Suggestion tool. URLs submitted using this tool are reviewed, and if Google feels that this content should be filtered from SafeSearch results, these URLs are tagged as adult content.

We hope you will find the new report clearer and useful. As always, please let us know if you have any comments, questions or feedback either through the Webmasters help community or Twitter.

Posted by Tali Pruss, Search Console Software Engineer

Update on 2020-10-30: We will deprecate support for data-vocabulary.org on January 29, 2021. This means that this markup will stop being eligible for Google search result features and enhancements. Please update your markup following the instructions in this post.

Update on 2020-04-06: We have decided to postpone this change for the immediate future due to the Coronavirus situation. We will re-evaluate this matter in June 2020.

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

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:


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

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