General advice

Headlines and dates

Present clear headlines: Google News looks at a variety of signals to determine the headline of an article, including within your HTML title tag and for the most prominent text on the page. Review our headline tips.

Provide accurate times and dates: Google News tries to determine the time and date to display for an article in a variety of ways. You can help ensure we get it right by using the following methods:

Show one clear date and time: As per our date guidelines, show a clear, visible date and time between the headline and the article text. Prevent other dates from appearing on the page whenever possible, such as for related stories.

Use structured data: Use the datePublished and dateModified schema and use the correct time zone designator for AMP or non-AMP pages.

Avoid artificially freshening stories: If an article has been substantially changed, it can make sense to give it a fresh date and time. However, don't artificially freshen a story without adding significant information or some other compelling reason for the freshening. Also, do not create a very slightly updated story from one previously published, then delete the old story and redirect to the new one. That's against our article URLs guidelines.

Duplicate content

Google News seeks to reward independent, original journalistic content by giving credit to the originating publisher, as both users and publishers would prefer. This means we try not to allow duplicate content—which includes scraped, rewritten, or republished material—to perform better than the original content. In line with this, these are guidelines publishers should follow:

Block scraped content: Scrapingcommonly refers to taking material from another site, often on an automated basis. Sites that scrape content must block scraped content from Google News.

Block rewritten content: Rewriting refers to taking material from another site, then rewriting that material so that it is not identical. Sites that rewrite content in a way that provides no substantial or clear added value must block that rewritten content from Google News. This includes, but is not limited to, rewrites that make only very slight changes or those that make many word replacements but still keep the original article's overall meaning.

Block or consider canonical for republished content: Republishingrefers to when a publisher has permission from another publisher or author to republish an original work, such as material from wire services or in partnership with other publications.Publishers that allow others to republish content can help ensure that their original versions perform better in Google News by asking those republishing to block or make use of canonical.Google News also encourages those that republish material to consider proactively blocking such content or making use of the canonical, so that we can better identify the original content and credit it appropriately.

Avoid duplicate content: If you operate a network of news sites that share content, the advice above about republishing is applicable to your network. Select what you consider to be the original article and consider blocking duplicates or making use of the canonical to point to the original.

Transparency

Be transparent: Visitors to your site want to trust and understand who publishes it and information about those who have written articles. That's why our content guidelines stress that content should have posts with clear bylines, information about authors, and contact information for the publication.

Don't be deceptive: Our content policies do not allow sites or accounts that impersonate any person or organization, or that misrepresent or conceal their ownership or primary purpose. We do not allow sites or accounts that engage in coordinated activity to mislead users. This includes, but isn't limited to, sites or accounts that misrepresent or conceal their country of origin or that direct content at users in another country under false premises.

Use structured for rich presentation: Both those using AMP and non-AMP pages can make use of structured data to optimize your content for rich results or carousel-like presentations.

Protect your users and their data: Consider securing every page of your website with HTTPS to protect the integrity and confidentiality of the data users exchange on your site. You can find more useful tips in our best practices on how to implement HTTPS.

Here's to a great 2019!

We hope these tips help publishers succeed in Google News over the coming year. For those who have more questions about Google News, we are unable to do one-to-one support. However, we do monitor our Google News Publisher Forum—which has been newly-revamped—and try to provide guidance on questions that might help a number of publishers all at once. The forum is also a great resource where publishers share tips and advice with each other. Posted by Danny Sullivan, Public Liaison for Search

For every train there's a passenger, but it turns out comments are not our train.

Over the years we read thousands of comments we've received on our blog posts on the Google Webmaster Central blog. Sometimes they were extremely thoughtful, other times they made us laugh out loud, but most of the time they were off-topic or even outright spammy; if you think about it, the latter is rather ironic, considering this is the Google Webmaster Blog.

Effective today, we're closing the commenting feature on the Google Webmaster Central blog. Instead of reading the comments here on the blog, we're going to focus on interacting with the community on our other channels. For all of our subsequent posts, if you have comments, feedback, or funny stories, you can find us in our help forums or on Twitter.

2018 has been a very important year for our webmaster support community. What has happened? There’s been a program rebranding, a global summit, and loads of community hangouts.

In October, the former Top Contributors became Gold Product Experts, and the Rising Stars, Silver Product Experts. This rebranding happened throughout all of the product forums and these are some of the new badges and names:

Silver Product Expert: Newer members who are developing their product knowledge

Gold Product Expert: Trusted members who are knowledgeable and active contributors

In November, we invited all of our Gold Product Experts from every Google help forum (such as Blogger or Google My Business) to a global summit. This meetup happened in the Google campus in Sunnyvale, California. Out of the almost 550 attendees from all over the world, around 70 were Webmaster Gold Product Experts. Coming from 25 different countries, this was the second biggest community that attended the event. Later that month, another very successful meetup took place in Moscow, gathering 23 Russian speaking Product Experts (of which 10 were Webmasters).

Many of the attendees acknowledged that this “was a really valuable time”, that the “sessions were very insightful and interesting” and that “the entire event was fantastic!”.

This knowledgeable group of super users provides invaluable help in 16 languages to more than 2 million users a year, about everything related to Search, Structured Data or Search Console in the forums.

And what is the profile of our community? Many of our Product Experts (Silver and Gold) are site owners who started out on the Webmaster forums (some more than a decade ago) by asking questions about their own sites. After their issues were fixed, most of them stayed to give back to the community, as they realized that their expertise could be of use to others. We want to thank all of our experts for their dedication and constant knowledge sharing to help users who are having trouble with their websites.

Throughout the year, we’ve held 75 live office hours hangouts on the Webmaster YouTube channel, in English, Japanese, German, Hindi, French, and we’ve also kick started the calls in Spanish. On those hangouts, anyone can raise their questions to the Google team directly and interact with one another.

If you’re interested in joining the community, meeting everyone and helping other users on the Webmaster forums, you can learn more on the Product Experts program website. We are always excited to meet users from diverse backgrounds and skill-sets!

Looking forward to what 2019 will bring to our community... And looking forward to meeting you!

It's been two years since we started working on "mobile-first indexing" - crawling the web with smartphone Googlebot, similar to how most users access it. We've seen websites across the world embrace the mobile web, making fantastic websites that work on all kinds of devices. There's still a lot to do, but today, we're happy to announce that we now use mobile-first indexing for over half of the pages shown in search results globally.

Checking for mobile-first indexing

In general, we move sites to mobile-first indexing when our tests assure us that they're ready. When we move sites over, we notify the site owner through a message in Search Console. It's possible to confirm this by checking the server logs, where a majority of the requests should be from Googlebot Smartphone. Even easier, the URL inspection tool allows a site owner to check how a URL from the site (it's usually enough to check the homepage) was last crawled and indexed.

If your site uses responsive design techniques, you should be all set! For sites that aren't using responsive web design, we've seen two kinds of issues come up more frequently in our evaluations:

Missing structured data on mobile pages

Structured data is very helpful to better understand the content on your pages, and allows us to highlight your pages in fancy ways in the search results. If you use structured data on the desktop versions of your pages, you should have the same structured data on the mobile versions of the pages. This is important because with mobile-first indexing, we'll only use the mobile version of your page for indexing, and will otherwise miss the structured data.

Missing alt-text for images on mobile pages

The value of alt-attributes on images ("alt-text") is a great way to describe images to users with screen-readers (which are used on mobile too!), and to search engine crawlers. Without alt-text for images, it's a lot harder for Google Images to understand the context of images that you use on your pages.

Check "img" tags in the source code of the mobile version for representative pages of your website. As above, the source of the mobile version can be seen by either using the browser to simulate a mobile device, or by using the Mobile-Friendly test to check the Googlebot rendered version. Search the source code for "img" tags, and double-check that your page is providing appropriate alt-attributes for any that you want to have findable in Google Images.

For example, that might look like this:

With alt-text (good!):<img src="cute-puppies.png" alt="A photo of cute puppies on a blanket">

Without alt-text:<img src="sad-puppies.png">

It's fantastic to see so many great websites that work well on mobile! We're looking forward to being able to index more and more of the web using mobile-first indexing, helping more users to search the web in the same way that they access it: with a smartphone. We’ll continue to monitor and evaluate this change carefully. If you have any questions, please drop by our Webmaster forums or our public events.

A few days ago, Fatih Ozkosemen and I led an episode of the AdSense On Air series. This program consists of monthly videos which cover many topics of interest to online publishers (we recommend you sign up if you use Google AdSense). The November 2018 version was dedicated to HTTPS migrations.

You can find the whole session, about one hour long, in this video:

The video covers the following topics:

What HTTPS encryption is, and why it is important to protect your visitors and yourself,

How HTTPS enables a more modern web,

What are the usual complaints about HTTPS, and are they still true today?

“But HTTPS certificates cost so much money!”

“But switching to HTTPS will destroy my SEO!”

“But “mixed content” is such a headache!”

“But my ad revenue will get destroyed!”

“But HTTPS is sooooo sloooow!"

Some practical advice to run the migration. Those are an aggregation of:

We hope that this sort of content is useful. Don’t hesitate to let us know if you like it and if we should do more! You can reach out to us directly on Twitter (Vincent & Fatih). Let us know which topics are of interest to you by commenting here or on the YouTube page. If you have questions when you plan your own HTTPS migration, don’t hesitate to ask in our Webmaster Help Forums.

Over the past few years, it's become easier than ever to stream live videos online, from celebrity updates to special events. But it's not always easy for people to determine which videos are live and know when to tune in. Today, we're introducing new tools to help more people discover your livestreams in Search and Assistant. With livestream structured data and the Indexing API, you can let Google know when your video is live, so it will be eligible to appear with a red "live" badge:

Add livestream structured data to your page

If your website streams live videos, use the livestream developer documentation to flag your video as a live broadcast and mark the start and end times. In addition, VideoObject structured data is required to tell Google that there's a video on your page.

Update Google quickly with the Indexing API

The Indexing API now supports pages with livestream structured data. We encourage you to call the Indexing API to request that your site is crawled in time for the livestream. We recommend calling the Indexing API when your livestream begins and ends, and if the structured data changes. For more information, visit our developer documentation. If you have any questions, ask us in the Webmaster Help Forum. We look forward to seeing your live videos on Google! Posted by Danielle Marshak, Product Manager

People come to Google seeking information about all kinds of questions.Frequently, the information they're looking for is on sites where users ask and answer each other's questions. Popular social news sites, expert forums, and help and support message boards are all examples of this pattern.

A screenshot of an example search result for a page titled “Why do touchscreens sometimes register a touch when ...” with a preview of the top answers from the page.

In order to help users better identify which search results may give the best information about their question, we have developed a new rich result type for question and answer sites. Search results for eligible Q&A pages display a preview of the top answers. This new presentation helps site owners reach the right users for their content and helps users get the relevant information about their questions faster.

A screenshot of an example search result for a page titled “Why do touchscreens sometimes register a touch when ...” with a preview of the top answers from the page.

At Google, we know that speed matters and we provide a variety of tools to help everyone understand the performance of a page or site. Historically, these tools have used different analysis engines. Unfortunately, this caused some confusion because the recommendations from each tool were different. Today, we're happy to announce that Pagespeed Insights (PSI) now uses Lighthouse as its analysis engine. This allows developers to get the same performance audits and recommendations everywhere: on the web, from the command line, and in Chrome DevTools. PSI also incorporates field data provided by the Chrome User Experience Report (CrUX). Version 5 of the PageSpeed Insights API will now provide CrUX data and all of the Lighthouse audits. Previous versions of the PSI API will be deprecated in six months.

Pagespeed Insights is now powered by Lighthouse

PageSpeed Insights provides the following information:

Lab Data. PSI fetches and analyzes the page using Lighthouse, which simulates how a mobile device loads a page. It computes a set of performance metrics for the page (such as First Contentful Paint and Time to Interactive) and summarizes these metrics with a performance score from 0-100. Scores are categorized into three levels; 90 and up is considered to be a good score.

Field Data. PSI also displays real-world performance metrics (First Contentful Paint and First Input Delay) for the page and its origin. (As a result, we've also deprecated the origin: query in PSI). Note that not all sites may have field data available for display. The data set relies on a version of the Chrome User Experience Report that is updated daily and is aggregated over the previous 28 days. Keep in mind that the metrics here may be different from the ones in the Lab Data section as they capture a wide spectrum of real-world network conditions and devices used by Chrome users.

Opportunities. PSI provides suggestions on how to improve the page's performance metrics. Each suggestion in this section estimates how much faster the page will load if the improvement is implemented.

Diagnostics. This section provides additional information about how a page adheres to best practices for web development.

The PSI v5 API now returns this new analysis together with CrUX data, and all Lighthouse category data (Performance, Progressive Web App, Accessibility, Best Practices, and SEO) for a given URL. We have more information about the changes in our FAQ. If you have any questions, please use Stack Overflow and tag your question with the pagespeed-insights tag.

Every month, millions of Chrome users encounter pages with insufficient mobile subscription information. Surprising charges that come from unclear communication are a poor user experience. That’s why starting from Chrome 71 (December 2018), Chrome will show a warning before these pages, so that users can make informed decisions when signing up to mobile based subscription services. Users will be offered the choice to proceed to the page or go back if they were unaware that they were entering a billing page.

Unclear mobile subscriptions

Picture this: Andrea is browsing the web on a mobile connection to access a gaming page and they’re presented with a page that asks them for their mobile phone details.

They fill in the blanks with their mobile number and press Continue, and get access to the content.

The next month, the phone bill arrives and they see a charge they were not expecting. Was the subscription to the online gaming service really that expensive? Did they really agree to pay that specific price for the service? How much did they agree to be charged to access the content?

Clearer billing information for Chrome users

We want to make sure Chrome users understand when they are going through a billing flow and trust that they’ll be able to make informed decisions while browsing the web.

To adequately inform users, it’s important to provide a sufficient level of details within the billing page as outlined by our new mobile billing charges best practices. Pages that answer positively to the following questions generally provide sufficient information for users:

Is the billing information visible and obvious to users? For example, adding no subscription information on the subscription page or hiding the information is a bad start because users should have access to the information when agreeing to subscribe.

Can customers easily see the costs they’re going to incur before accepting the terms? For example, displaying the billing information in grey characters over a grey background, therefore making it less readable, is not considered a good user practice.

Is the fee structure easily understandable? For example, the formula presented to explain how the cost of the service will be determined should be as simple and straightforward as possible.

If Chrome detects pages that don’t provide sufficient billing information to users, the following warning will be displayed to the user on Chrome mobile, Chrome desktop and Android’s WebView:

The warning will be shown to users entering unclear billing pages.

When we identify such pages, we will notify the webmaster through Search Console where there will be an option to let us know about the changes they’ve made to clarify the billing process. For websites that aren’t verified on Search Console, we will do our best to get in touch with the webmasters affected and will be available to answer questions in our public support forum available in 15 languages. Once an appeal has been sent via Search Console, we will review the changes and remove the warning accordingly.

If your billing service takes users through a clearly visible and understandable billing process as described in our best practices, you don't need to make any changes. Also, the new warning in Chrome doesn’t impact your website’s ranking in Google Search.

Today, we’re excited to introduce reCAPTCHA v3, our newest API that helps you detect abusive traffic on your website without user interaction. Instead of showing a CAPTCHA challenge, reCAPTCHA v3 returns a score so you can choose the most appropriate action for your website.

A Frictionless User Experience

Over the last decade, reCAPTCHA has continuously evolved its technology. In reCAPTCHA v1, every user was asked to pass a challenge by reading distorted text and typing into a box. To improve both user experience and security, we introduced reCAPTCHA v2 and began to use many other signals to determine whether a request came from a human or bot. This enabled reCAPTCHA challenges to move from a dominant to a secondary role in detecting abuse, letting about half of users pass with a single click. Now with reCAPTCHA v3, we are fundamentally changing how sites can test for human vs. bot activities by returning a score to tell you how suspicious an interaction is and eliminating the need to interrupt users with challenges at all. reCAPTCHA v3 runs adaptive risk analysis in the background to alert you of suspicious traffic while letting your human users enjoy a frictionless experience on your site.

More Accurate Bot Detection with "Actions"

In reCAPTCHA v3, we are introducing a new concept called “Action”—a tag that you can use to define the key steps of your user journey and enable reCAPTCHA to run its risk analysis in context. Since reCAPTCHA v3 doesn't interrupt users, we recommend adding reCAPTCHA v3 to multiple pages. In this way, the reCAPTCHA adaptive risk analysis engine can identify the pattern of attackers more accurately by looking at the activities across different pages on your website. In the reCAPTCHA admin console, you can get a full overview of reCAPTCHA score distribution and a breakdown for the stats of the top 10 actions on your site, to help you identify which exact pages are being targeted by bots and how suspicious the traffic was on those pages.

Fighting Bots Your Way

Another big benefit that you’ll get from reCAPTCHA v3 is the flexibility to prevent spam and abuse in the way that best fits your website. Previously, the reCAPTCHA system mostly decided when and what CAPTCHAs to serve to users, leaving you with limited influence over your website’s user experience. Now, reCAPTCHA v3 will provide you with a score that tells you how suspicious an interaction is. There are three potential ways you can use the score. First, you can set a threshold that determines when a user is let through or when further verification needs to be done, for example, using two-factor authentication and phone verification. Second, you can combine the score with your own signals that reCAPTCHA can’t access—such as user profiles or transaction histories. Third, you can use the reCAPTCHA score as one of the signals to train your machine learning model to fight abuse. By providing you with these new ways to customize the actions that occur for different types of traffic, this new version lets you protect your site against bots and improve your user experience based on your website’s specific needs. In short, reCAPTCHA v3 helps to protect your sites without user friction and gives you more power to decide what to do in risky situations. As always, we are working every day to stay ahead of attackers and keep the Internet easy and safe to use (except for bots). Ready to get started with reCAPTCHA v3? Visit our developer site for more details. Posted by Wei Liu, Google Product Manager