#NoHacked: Using two-factor authentication to protect your site
There was once a time when having a relatively strong password or answering a security question was a reasonable way to protect your online accounts. However, according to a study from Stop Badware, stolen credentials is a common way for hackers to compromise websites. Additionally, even reputable sites can fall victim to hacking, potentially exposing your personal data like passwords to attackers.
Fortunately, two-factor authentication can help you keep your accounts safer. Two-factor authentication relies on an additional source of verification, in conjunction with your password, to access your account. You might have used two-factor authentication before if you have ever been prompted for a code from your phone when logging into a social media site or from a chip card reader when logging into a bank account. Two-factor authentication makes it more difficult for someone to log into your account even if they have stolen your password.
As a website owner, you should enable two-factor authentication on your accounts where possible. A compromised account can cause you to lose important personal data and valuable reputation for your site. Two-factor authentication can give you the ease of mind that your accounts and data are safer.
Google currently offers 2-Step Verification for all of its accounts, including accounts from Google Apps domains. You can use your phone, a hardware token like a Security Key, or the Google Authenticator app to verify your account. These options give you flexibility when traveling or when you don’t have access to the mobile network.
If your hosting provider, Content Management System (CMS), or any type of platform you use for managing your site doesn’t offer two-factor authentication, ask their customer support for an option to use two-factor authentication in the future.They can build two-factor authentication into their own platforms using Google’s open source code. If your platform or hoster doesn’t provide strong protection against unauthorized access consider hosting your content elsewhere. You can see a list of websites that support two-factor authentication, including what types of authentication options they offer, at https://twofactorauth.org/.
If you have any additional questions, you can post in the Webmaster Help Forums where a community of webmasters can help answer your questions. You can also join our Hangout on Air about Security on August 26.
Posted by: Eric Kuan, Webmaster Relations Specialist & Yuan Niu, Webspam Analyst
Introducing the Search Analytics API
With the great feedback from the Search Analytics feature in Google Search Console, we’ve decided to make this data accessible for developers via API. We hope that the Search Analytics API will help you to bake search performance data into your apps and tools.
If you’ve used any of Google’s other APIs, or maybe one of the existing Search Console APIs, then getting started will be easy! The how-to page has examples in Python that you can use as recipes for your own programs. For example, you can use the API to:
- Verify the presence of data (what’s the most recent date you can request?)
- Top 10 queries by click count
- Top 10 pages
- Top 10 queries in India
- Top 10 mobile queries in India
What will you cook up with the new API? We’re curious to see how new tools and apps that use this API will satisfy the hunger for even more information about your site’s performance in Google Search! If you’ve integrated this API into a tool, we’d love to hear about it in the comments. If you’ve run into any questions about the API, feel free to drop by our webmaster help forum.
Posted by John Mueller, Webmaster Trends Analyst, Google Switzerland
#NoHacked: How to recognise and protect yourself against social engineering
If you’ve spent some time on the web, you have more than likely encountered some form of social engineering. Social engineering attempts to extract confidential information from you by manipulating or tricking you in some way.
Phishing
You might be familiar with phishing, one of the most common forms of social engineering. Phishing sites and emails mimic legitimate sites and trick you into entering confidential information like your username and password into these sites. A recent study from Google found that some phishing sites can trick victims 45% of the time! Once a phishing site has your information, the information will either be sold or be used to manipulate your accounts. the owners will either sell it or use it to manipulate your accounts.
Other Forms of Social Engineering
As a site owner, phishing isn’t the only form of social engineering that you need to watch out for. One other form of social engineering comes from the software and tools used on your site. If you download or use any Content Management System (CMS), plug-ins, or add-ons, make sure that they come from reputable sources like directly from the developer’s site. Software from non-reputable sites can contain malicious exploits that allow hackers to gain access to your site.
For example, Webmaster Wanda was recently hired by Brandon’s Pet Palace to help create a site. After sketching some designs, Wanda starts compiling the software she needs to build the site. However, she finds out that Photo Frame Beautifier, one of her favorite plug-ins, has been taken off the official CMS plug-in site and that the developer has decided to stop supporting the plug-in. She does a quick search and finds a site that offers an archive of old plug-ins. She downloads the plug-in and uses it to finish the site. Two months later, a notification in Search Console notifies Wanda that her client’s site has been hacked. She quickly scrambles to fix the hacked content and finds the source of the compromise. It turns out the Photo Frame Beautifier plug-in was modified by a third party to allow malicious parties to access the site. She removed the plug-in, fixed the hacked content, secured her site from future attacks, and filed a reconsideration request in Search Console. As you can see, an inadvertent oversight by Wanda led to her client’s site being compromised.
Protecting Yourself from Social Engineering Attacks
Social engineering is effective because it’s not obvious that there’s something wrong with what you’re doing. However, there are a few basic things you can do protect yourself from social engineering.
- Stay vigilant: Whenever you enter confidential information online or install website software, have a healthy dose of skepticism. Check URLs to make sure you’re not typing confidential information into malicious sites. When installing website software make sure the software is coming from known, reputable sources like the developer’s site.
- Use two-factor authentication: Two-factor authentication like Google’s 2-Step Verification adds another layer of security that helps protect your account even if your password has been stolen. You should use two-factor authentication on all accounts where possible. We’ll be talking more in-depth next week about the benefits of two-factor authentication.
Additional resources about social engineering:
- Learn more about how to protect yourself from phishing attacks
- Report a Phishing Page
- Avoid and report Google scams
- Identify “phishing” and “spoofing” emails
If you have any additional questions, you can post in the Webmaster Help Forums where a community of webmasters can help answer your questions. You can also join our Hangout on Air about Security on August 26.
Posted by: Eric Kuan, Webmaster Relations Specialist & Yuan Niu, Webspam Analyst
#NoHacked: How to avoid being the target of hackers
Today, we’ll be continuing our #NoHacked campaign. We’ll be focusing on how to protect your site from hacking and give you better insight into how some of these hacking campaigns work. You can follow along with #NoHacked on Twitter and Google+. We’ll also be wrapping up with a Google Hangout focused on security where you can ask our security experts questions.
We’re kicking off the campaign with some basic tips on how to keep your site safe on the web.
1. Strengthen your account security
Creating a password that’s difficult to guess or crack is essential to protecting your site. For example, your password might contain a mixture of letters, numbers, symbols, or be a passphrase. Password length is important. The longer your password, the harder it will be to guess. There are many resources on the web that can test how strong your password is. Testing a similar password to yours (never enter your actual password on other sites) can give you an idea of how strong your password is.
Also, it’s important to avoid reusing passwords across services. Attackers often try known username and password combinations obtained from leaked password lists or hacked services to compromise as many accounts as possible.
You should also turn on 2-Factor Authentication for accounts that offer this service. This can greatly increase your account’s security and protect you from a variety of account attacks. We’ll be talking more about the benefits of 2-Factor Authentication in two weeks.
2. Keep your site’s software updated
One of the most common ways for a hacker to compromise your site is through insecure software on your site. Be sure to periodically check your site for any outdated software, especially updates that patch security holes. If you use a web server like Apache, nginx or commercial web server software, make sure you keep your web server software patched. If you use a Content Management System (CMS) or any plug-ins or add-ons on your site, make sure to keep these tools updated with new releases. Also, sign up to the security announcement lists for your web server software and your CMS if you use one. Consider completely removing any add-ons or software that you don’t need on your website — aside from creating possible risks, they also might slow down the performance of your site.
3. Research how your hosting provider handles security issues
Your hosting provider’s policy for security and cleaning up hacked sites is in an important factor to consider when choosing a hosting provider. If you use a hosting provider, contact them to see if they offer on-demand support to clean up site-specific problems. You can also check online reviews to see if they have a track record of helping users with compromised sites clean up their hacked content.
If you control your own server or use Virtual Private Server (VPS) services, make sure that you’re prepared to handle any security issues that might arise. Server administration is very complex, and one of the core tasks of a server administrator is making sure your web server and content management software is patched and up to date. If you don’t have a compelling reason to do your own server administration, you might find it well worth your while to see if your hosting provider offers a managed services option.
4. Use Google tools to stay informed of potential hacked content on your site
It’s important to have tools that can help you proactively monitor your site.The sooner you can find out about a compromise, the sooner you can work on fixing your site.
We recommend you sign up for Search Console if you haven’t already. Search Console is Google’s way of communicating with you about issues on your site including if we have detected hacked content. You can also set up Google Alerts on your site to notify you if there are any suspicious results for your site. For example, if you run a site selling pet accessories called www.example.com, you can set up an alert for [site:example.com cheap software] to alert you if any hacked content about cheap software suddenly starts appearing on your site. You can set up multiple alerts for your site for different spammy terms. If you’re unsure what spammy terms to use, you can use Google to search for common spammy terms.
We hope these tips will keep your site safe on the web. Be sure to follow our social campaigns and share any tips or tricks you might have about staying safe on the web with the #NoHacked hashtag.
If you have any additional questions, you can post in the Webmaster Help Forums where a community of webmasters can help answer your questions. You can also join our Hangout on Air about Security on August 26.
Posted by: Eric Kuan, Webmaster Relations Specialist and Yuan Niu, Webspam Analyst
Update on the Autocomplete API
There have been multiple times in which the developer community’s reverse-engineering of a Google service via an unpublished API has led to great things. The Google Maps API, for example, became a formal supported API months after seeing what creative engineers could do combining map data with other data sources. We currently support more than 80 APIs that developers can use to integrate Google services and data into their applications.
However, there are some times when using an unsupported, unpublished API also carries the risk that the API will stop being be available. This is one of those situations.
We built autocomplete as a complement to Search, and never intended that it would exist disconnected from the purpose of anticipating user search queries. Over time we’ve realized that while we can conceive of uses for an autocomplete data feed outside of search results that may be valuable, overall the content of our automatic completions are optimized and intended to be used in conjunction with web search results, and outside of the context of a web search don’t provide a meaningful user benefit.
In the interest of maintaining the integrity of autocomplete as part of Search, we will be restricting unauthorized access to the unpublished autocomplete API as of August 10th, 2015. We want to ensure that users experience autocomplete as it was designed to be used — as a service closely tied to Search. We believe this provides the best user experience for both services.
For publishers and developers who still want to use the autocomplete service for their site, we have an alternative. Google Custom Search Engine allows sites to maintain autocomplete functionality in connection with Search functionality. Any partner already using Google CSE will be unaffected by this change. For others, if you want autocomplete functionality after August 10th, 2015, please see our CSE sign-up page.
Posted by Peter Chiu on behalf of the Autocomplete team
Google+: A case study on App Download Interstitials
On Google+ mobile web, we decided to take a closer look at our own use of interstitials. Internal user experience studies identified them as poor experiences, and Jennifer Gove gave a great talk at IO last year which highlights this user frustration.
Despite our intuition that we should remove the interstitial, we prefer to let data guide our decisions, so we set out to learn how the interstitial affected our users. Our analysis found that:
- 9% of the visits to our interstitial page resulted in the ‘Get App’ button being pressed. (Note that some percentage of these users already have the app installed or may never follow through with the app store download.)
- 69% of the visits abandoned our page. These users neither went to the app store nor continued to our mobile website.
- 1-day active users on our mobile website increased by 17%.
- G+ iOS native app installs were mostly unaffected (-2%). (We’re not reporting install numbers from Android devices since most come with Google+ installed.)
Posted by David Morell, Software Engineer, Google+
Google’s handling of new top level domains
Q: How will new gTLDs affect search? Is Google changing the search algorithm to favor these TLDs? How important are they really in search?
A: Overall, our systems treat new gTLDs like other gTLDs (like .com & .org). Keywords in a TLD do not give any advantage or disadvantage in search.
Q: What about IDN TLDs such as .みんな? Can Googlebot crawl and index them, so that they can be used in search?
A: Yes. These TLDs can be used the same as other TLDs (it’s easy to check with a query like [site:みんな]). Google treats the Punycode version of a hostname as being equivalent to the unencoded version, so you don’t need to redirect or canonicalize them separately. For the rest of the URL, remember to use UTF-8 for the path & query-string in the URL, when using non-ASCII characters.
Q: Will a .BRAND TLD be given any more or less weight than a .com?
A: No. Those TLDs will be treated the same as a other gTLDs. They will require the same geotargeting settings and configuration, and they won’t have more weight or influence in the way we crawl, index, or rank URLs.
Q: How are the new region or city TLDs (like .london or .bayern) handled?
A: Even if they look region-specific, we will treat them as gTLDs. This is consistent with our handling of regional TLDs like .eu and .asia. There may be exceptions at some point down the line, as we see how they’re used in practice. See our help center for more information on multi-regional and multilingual sites, and set geotargeting in Search Console where relevant.
Q: What about real ccTLDs (country code top-level domains) : will Google favor ccTLDs (like .uk, .ae, etc.) as a local domain for people searching in those countries?
A: By default, most ccTLDs (with exceptions) result in Google using these to geotarget the website; it tells us that the website is probably more relevant in the appropriate country. Again, see our help center for more information on multi-regional and multilingual sites.
Q: Will Google support my SEO efforts to move my domain from .com to a new TLD? How do I move my website without losing any search ranking or history?
A: We have extensive site move documentation in our Help Center. We treat these moves the same as any other site move. That said, domain changes can take time to be processed for search (and outside of search, users expect email addresses to remain valid over a longer period of time), so it’s generally best to choose a domain that will fit your long-term needs.
We hope this gives you more information on how the new top level domains are handled. If you have any more questions, feel free to drop them here, or ask in our help forums.
Posted by John Mueller, Webmaster Trends Analyst
App deep linking with goo.gl
Starting now, goo.gl short links function as a single link you can use to all your content — whether that content is in your Android app, iOS app, or website. Once you’ve taken the necessary steps to set up App Indexing for Android and iOS, goo.gl URLs will send users straight to the right page in your app if they have it installed, and everyone else to your website. This will provide additional opportunities for your app users to re-engage with your app.
This feature works for both new short URLs and retroactively, so any existing goo.gl short links to your content will now also direct users to your app.
Share links that ‘do the right thing’
You can also make full use of this feature by integrating the URL Shortener API into your app’s share flow, so users can share links that automatically redirect to your native app cross-platform. This will also allow others to embed links in their websites and apps which deep link directly to your app.
Take Google Maps as an example. With the new cross-platform goo.gl links, the Maps share button generates one link that provides the best possible sharing experience for everyone. When opened, the link auto-detects the user’s platform and if they have Maps installed. If the user has the app installed, the short link opens the content directly in the Android or iOS Maps app. If the user doesn’t have the app installed or is on desktop, the short link opens the page on the Maps website.
Try it out for yourself! Don’t forget to use a phone with the Google Maps app installed: http://goo.gl/maps/xlWFj.
How to set it up
To set up app deep linking on goo.gl:
- Complete the necessary steps to participate in App Indexing for Android and iOS at g.co/AppIndexing. Note that goo.gl deep links are open to all iOS developers, unlike deep links from Search currently. After this step, existing goo.gl short links will start deep linking to your app.
- Optionally integrate the URL Shortener API with your app’s share flow, your email campaigns, etc. to programmatically generate links that will deep link directly back to your app.
We hope you enjoy this new functionality and happy cross-platform sharing!
Posted by Fabian Schlup, Software Engineer
Surfacing content from iOS apps in Google Search
We’ve been helping users discover relevant content from Android apps in Google search results for a while now. Starting today, we’re bringing App Indexing to iOS apps as well. This means users on both Android and iOS will be able to open mobile app content straight from Google Search.
Indexed links from an initial group of apps we’ve been working with will begin appearing on iOS in search results both in the Google App and Chrome for signed-in users globally in the coming weeks:
How to get your iOS app indexed
While App Indexing for iOS is launching with a small group of test partners initially, we’re working to make this technology available to more app developers as soon as possible. In the meantime, here are the steps to get a head start on App Indexing for iOS:
- Add deep linking support to your iOS app.
- Make sure it’s possible to return to Search results with one click.
- Provide deep link annotations on your site.
- Let us know you’re interested. Keep in mind that expressing interest does not automatically guarantee getting app deep links in iOS search results.
If you happen to be attending Google I/O this week, stop by our talk titled “Get your app in the Google index” to learn more about App Indexing. You’ll also find detailed documentation on App Indexing for iOS at g.co/AppIndexing. If you’ve got more questions, drop by our Webmaster help forum.
Posted by Eli Wald, Product Manager
Helping users fill out online forms
A lot of websites rely on forms for important goals completion, such as completing a transaction on a shopping site or registering on a news site. For many users, online forms mean repeatedly typing common information like their names, emails, phone numbers or addresses, on different sites across the web. In addition to being tedious, this task is also error-prone, which can lead many users to abandon the flow entirely. In a world where users browse the internet using their mobile devices more than their laptops or desktops, having forms that are easy and quick to fill out is crucial! Three years ago, we announced the support for a new “autocomplete” attribute in Chrome, to make form-filling faster, easier and smarter. Now, Chrome fully supports the “autocomplete” attribute for form fields according to the current WHATWG HTML Standard. This allows webmasters and web developers to label input element fields with common data types, such as ‘name’ or ‘street-address’, without changing the user interface or the backend. Numerous webmasters have increased the rate of form completions on their sites by marking up their forms for auto-completion.
For example, marking up an email address field on a form to allow auto-completion would look like this (with a full sample form available):
<input type="text" name="customerEmail" autocomplete="email"/>
Making websites friendly and easy to browse for users on mobile devices is very important. We hope to see many forms marked up with the “autocomplete” attribute in the future. For more information, you can check out our specifications about Label and name inputs in Web Fundamentals. And as usual, if you have any questions, please post in our Webmasters Help Forums.
Posted by Mathieu Perreault, Chrome Software Engineer, and Zineb Ait Bahajji, Webmaster Trends Analyst
An update on doorway pages
We have a long-standing view that doorway pages that created solely for search engines can harm the quality of the user’s search experience.
- Is the purpose to optimize for search engines and funnel visitors into the actual usable or relevant portion of your site, or are they an integral part of your site’s user experience?
- Are the pages intended to rank on generic terms yet the content presented on the page is very specific?
- Do the pages duplicate useful aggregations of items (locations, products, etc.) that already exist on the site for the purpose of capturing more search traffic?
- Are these pages made solely for drawing affiliate traffic and sending users along without creating unique value in content or functionality?
- Do these pages exist as an “island?” Are they difficult or impossible to navigate to from other parts of your site? Are links to such pages from other pages within the site or network of sites created just for search engines?
Posted by Brian White, Google Webspam Team
Deprecation of the old Webmaster Tools API
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…
Unblocking resources with Webmaster Tools
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 no…
Easier website development with Web Components and JSON-LD
JSON-LD is a JSON-based data format that can be used to implement structured data describing content on your site to Google and other search engines. For example, if you have a list of events, cafes, people or more, you can include this data in your pages in a structured way using the schema.org vocabulary embedded in webpages as a JSON-LD snippet. The structured data helps Google understand your pages better and highlight your content in search features, such events in the Knowledge Graph and rich snippets.
Web Components are a nascent set of technologies to define custom, reusable user interface widgets and their behavior. Any web developer can build a Web Component. You start by defining a template for a distinct part of the user interface, which you import into the pages on which you want to use the Web Component. A Custom Element is used to define the behavior of the Web Component. Because you’re bundling the display and logic for part of the user interface into the Web Component, you can share and reuse the bundle on other pages and with other developers, thus simplifying web development.
JSON-LD and Web Components work really well together. The Custom Element functions as the presentation layer and the JSON-LD functions as the data layer that the custom element and search engines consume. This means you can build custom elements for any schema.org type, such as schema.org/Event and schema.org/LocalBusiness.
Your architecture would then look like this. Your structured data is stored in your database, for example, the store locations in your chain. This data is embedded into your webpage as a JSON-LD snippet, which means it’s available to be consumed by the Custom Element to display to a human visitor and for Googlebot to retrieve for Google indexing.
To learn more and get started with your own custom elements, please see:
- Our latest article on HTML5 Rocks and the accompanying code examples.
- The JSON-LD website, and the W3C spec
- Web Components wiki and the Web Components community on webcomponents.org
- schema.org
- Google’s structured data documentation
Posted by Ewa Gasperowicz, Developer Programs Engineer, Mano Marks, Developer Advocate, Pierre Far, Webmaster Trends Analyst
Safe Browsing and Google Analytics: Keeping More Users Safe, Together
The following was originally posted on the Google Online Security Blog.
If you run a web site, you may already be familiar with Google Webmaster Tools and how it lets you know if Safe Browsing finds something problematic on your site. For example, we’ll notify you if your site is delivering malware, which is usually a sign that it’s been hacked. We’re extending our Safe Browsing protections to automatically display notifications to all Google Analytics users via familiar Google Analytics Notifications.
Google Safe Browsing has been protecting people across the Internet for over eight years and we’re always looking for ways to extend that protection even further. Notifications like these help webmasters like you act quickly to respond to any issues. Fast response helps keep your site—and your visitors—safe.
Posted by: Stephan Somogyi, Product Manager, Security and Privacy
Finding more mobile-friendly search results
Webmaster level: all
When it comes to search on mobile devices, users should get the most relevant and timely results, no matter if the information lives on mobile-friendly web pages or apps. As more people use mobile devices to access the internet, our algorithms have to adapt to these usage patterns. In the past, we’ve made updates to ensure a site is configured properly and viewable on modern devices. We’ve made it easier for users to find mobile-friendly web pages and we’ve introduced App Indexing to surface useful content from apps. Today, we’re announcing two important changes to help users discover more mobile-friendly content:
1. More mobile-friendly websites in search results
Starting April 21, we will be expanding our use of mobile-friendliness as a ranking signal. This change will affect mobile searches in all languages worldwide and will have a significant impact in our search results. Consequently, users will find it easier to get relevant, high quality search results that are optimized for their devices.
To get help with making a mobile-friendly site, check out our guide to mobile-friendly sites. If you’re a webmaster, you can get ready for this change by using the following tools to see how Googlebot views your pages:
- If you want to test a few pages, you can use the Mobile-Friendly Test.
- If you have a site, you can use your Webmaster Tools account to get a full list of mobile usability issues across your site using the Mobile Usability Report.
2. More relevant app content in search results
Starting today, we will begin to use information from indexed apps as a factor in ranking for signed-in users who have the app installed. As a result, we may now surface content from indexed apps more prominently in search. To find out how to implement App Indexing, which allows us to surface this information in search results, have a look at our step-by-step guide on the developer site.
If you have questions about either mobile-friendly websites or app indexing, we’re always happy to chat in our Webmaster Help Forum.
Posted by Takaki Makino, Chaesang Jung, and Doantam Phan
Case Studies: Fixing Hacked Sites
Webmaster Level: All Every day, thousands of websites get hacked. Hacked sites can harm users by serving malicious software, collecting personal information, or redirecting them to sites they didn’t intend to visit. Webmasters want to fix hacked sites …
Crawling and indexing of locale-adaptive pages
Webmaster level: advanced
Locale-adaptive pages change their content to reflect the user’s language or perceived geographic location. Since, by default, Googlebot requests pages without setting an Accept-Language HTTP request header and uses IP addresses that appear to be located in the USA, not all content variants of locale-adaptive pages may be indexed completely.
Today we’re introducing new locale-aware crawl configurations for Googlebot for pages that we detect may adapt the content they serve based on the request’s language and perceived location. These are:
- Geo-distributed crawling where Googlebot would start to use IP addresses that appear to be coming from outside the USA, in addition to the current IP addresses that appear to be from the USA that Googlebot currently uses.
- Language-dependent crawling where Googlebot would start to crawl with an Accept-Language HTTP header in the request.
As these new crawling configurations are enabled automatically for pages we detect to be locale-adaptive, you may notice changes in how we crawl and show your site in Google search results without you altering your CMS or server settings.
Note that these new configurations do not alter our recommendation to use separate URLs with rel=alternate hreflang annotations for each locale. We continue to support and recommend using separate URLs as they are still the best way for users to interact and share your content, and also to maximize indexing and better ranking of all variants of your content.
As always, if you have any questions or feedback, please tell us in the internationalization Webmaster Help Forum.
Posted by Qin Yin, Software Engineer Search Infrastructure, and Pierre Far, Webmaster Trends Analyst
Upcoming Events In The Knowledge Graph
Last year, we launched a new way for musical artists to list their upcoming events on Google: schema.org markup on their official websites. Now we’re expanding this program in four ways:
1. Official Ticket Links
For artists: if you mark up ticketing links along with the events on your official website, we’ll show an expanded answer card for your events in Google search, including the on-sale date, availability, and a direct link to your preferred ticketing site.
As before, you may write the event markup directly into your site’s HTML, or simply install an event widget that builds in the markup for you automatically—like Bandsintown, BandPage, GigPress, ReverbNation or Songkick.
2. Delegated Event Listings
What if you can’t add markup or an event widget to your official website—for example, if your website doesn’t list your events at all? Now you can use delegation markup to tell us to source your events from a page of your choice on another website. Just add the following markup to your home page, making sure to customize the three red values:
<script type="application/ld+json">
{"@context" : "http://schema.org",
"@type" : "MusicGroup",
"name" : "Your Band or Performer Name",
"url" : "http://your-official-website.com",
"event" : "http://other-event-site.com/your-event-listing-page/"
}
</script>
The marked-up events found on the other event site’s page will then be eligible for Google events features. Examples of sites you can point to in the “event” field include bandpage.com, bandsintown.com, songkick.com, and ticketmaster.com.
3. Comedian Events
Hey funny people! We want your performances to show up on Google, too. Just add ComedyEvent markup to your official website. Or, if another site like laughstub.com has your complete event listings, use delegation markup on your home page to point us their way.
4. Venue Events
Last but definitely not least: we’re starting to show venue event listings in Google Search. Concert venues, theaters, libraries, fairgrounds, and so on: make your upcoming events eligible for display across Google by adding Event markup to your official website.
As with artist events, you have a choice of writing the event markup directly into your site’s HTML, or using a widget or plugin that builds in the markup for you. Also, if all your events are ticketed by a primary ticketer whose website provides markup, you don’t have to do anything! Google will read the ticketer’s markup and apply it toward your venue’s event listings.
For example, venues ticketed by Ticketmaster, including its international sites and TicketWeb, will automatically be covered. The same goes for venues that list events with Ticketfly, AXS, LaughStub, Wantickets, Holdmyticket, ShowClix, Stranger Tickets, Ticket Alternative, Digitick, See Tickets, Tix, Fnac Spectacles, Ticketland.ru, iTickets, MIDWESTIX, Ticketleap, or Instantseats. All of these have already implemented ticketer events markup.
Please see our Developer Site for full documentation of these features, including a video tutorial on how to write and test event markup. Then add the markup, help new fans discover your events, and play to a packed house!
Posted by Justin Boyan, Product Manager, Google Search
New Structured Data Testing Tool, documentation, and more
Structured data markup helps your content get discovered in search results and across Google properties. We’re excited to share several updates to help you author and publish markup on your website:
- A new Structured Data Testing Tool to better reflect Google’s interpretation of your content
- Improved documentation and policy guidelines for Google features powered by structured data on the web
- Expanded support for the JSON-LD markup syntax
Structured Data Testing Tool
It provides the following features:
- Validation for all Google features powered by structured data
- Support for markup in the JSON-LD syntax, including in dynamic HTML pages
- Clean display of the structured data items on your page
- Syntax highlighting of markup problems right in your HTML source code
New documentation and simpler policy
We’ve clarified our documentation for the vocabulary supported in structured data based on webmasters’ feedback. The new documentation explains the markup you need to add to enable different search features for your content, along with code examples in the supported syntaxes. We’ll be retiring the old documentation soon.
We’ve also simplified and clarified our policies on using structured data. If you believe that another site is abusing Google’s rich snippets quality guidelines, please let us know using the rich snippets spam report form.
Expanded support for JSON-LD
We’ve extended our support for schema.org vocabulary in JSON-LD syntax to new use cases: company logos and contacts, social profile links, events in the Knowledge Graph, the sitelinks search box, and event rich snippets. We’re working on expanding support to additional markup-powered features in the future.
As always, we welcome your feedback and questions; please post in our Webmaster Help forums.
Posted by Pierre Far, Webmaster Trends Analyst, Tatsiana Sakhar, Search Quality Analyst, Zach Clifford, Software Engineer