7-31-15 1:42am PST
Google Webmaster Central Blog
#NoHacked: How to avoid being the target of hackers
If you publish anything online, one of your top priorities should be security. Getting hacked can negatively affect your online reputation and result in loss of critical and private data. Over the past year Google has noticed a 180% increase in the number of sites getting hacked. While we are working hard to combat this hacked trend, there are steps you can take to protect your content on the web.
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 securityCreating 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 updatedOne 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 issuesYour 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 siteIt’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.
We’re kicking off the campaign with some basic tips on how to keep your site safe on the web.
1. Strengthen your account securityCreating 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 updatedOne 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 issuesYour 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 siteIt’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.
7-26-15 3:22pm PSt
Goolge
Official news on crawling and indexing sites for the Google index
Update on the Autocomplete API
link to article
http://googlewebmastercentral.blogspot.com/
Google Search provides an autocomplete service that attempts to predict a query before a user finishes typing. For years, a number of developers have integrated the results of autocomplete within their own services using a non-official, non-published API that also had no restrictions on it. Developers who discovered the autocomplete API were then able to incorporate autocomplete services, independent of Google Search.
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.
7-26-15 3:12pm PST
Google Search provides an autocomplete service that attempts to predict a query before a user finishes typing. For years, a number of developers have integrated the results of autocomplete within their own services using a non-official, non-published API that also had no restrictions on it. Developers who discovered the autocomplete API were then able to incorporate autocomplete services, independent of Google Search.
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.
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.
Official news on crawling and indexing sites for the Google index
App deep linking with goo.gl
Posted by Fabian Schlup, Software Engineer
Link to Article
http://googlewebmastercentral.blogspot.com/2015/05/app-deep-linking-with-googl.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+blogspot%2FamDG+%28Official+Google+Webmaster+Central+Blog%29
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.
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.
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.
I have bought over 15 Domains in past two years so of course this Article caught my attention,
let me know what you think if you buy a good amount of Domain names and this affects you.
Brian M Rye-Blog Autor
Article from Google Webmaster Central Blog
link to Article
http://googlewebmastercentral.blogspot.com/2015/07/googles-handling-of-new-top-level.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+blogspot%2FamDG+%28Official+Google+Webmaster+Central+Blog%29
Google's handling of new top level domains
Posted: Tuesday, July 21, 2015
With the coming of many new generic top level domains (gTLDs), we'd like to give some insight into how these are handled in Google's search. We’ve heard and seen questions and misconceptions about the way we treat new top level domains (TLDs), like .guru, .how, or any of the .BRAND gTLDs, for example:
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.
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.
Google+: A case study on App Download Interstitials
Posted on
Google Webmaster Blog,
link to article
http://googlewebmastercentral.blogspot.com/2015/07/google-case-study-on-app-download-interstitials.html
Google+: A case study on App Download Interstitials
By David Morell, Software Engineer, Google+
Posted: Thursday, July 23, 2015
Many mobile sites use promotional app interstitials to encourage users to download their native mobile apps. For some apps, native can provide richer user experiences, and use features of the device that are currently not easy to access on a browser. Because of this, many app owners believe that they should encourage users to install the native version of their online property or service. It’s not clear how aggressively to promote the apps, and a full page interstitial can interrupt the user from reaching their desired content.
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:
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.
While 9% sounds like a great CTR for any campaign, we were much more focused on the number of users who had abandoned our product due to the friction in their experience. With this data in hand, in July 2014, we decided to run an experiment and see how removing the interstitial would affect actual product usage. We added a Smart App Banner to continue promoting the native app in a less intrusive way, as recommended in the Avoid common mistakes section of our Mobile SEO Guide. The results were surprising:
- 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.)
Based on these results, we decided to permanently retire the interstitial. We believe that the increase in users on our product makes this a net positive change, and we are sharing this with the hope that you will reconsider the use of promotional interstitials. Let’s remove friction and make the mobile web more useful and usable!
(Since this study, we launched a better mobile web experience that is currently without an app banner. The banner can still be seen on iOS 6 and below.)
Posted by David Morell, Software Engineer, Google+
7-26-15 3:22pm PSt
Goolge
by Google Webmasters,
7-26-15 3:22pm PSt
Goolge
7-26-15 3:12pm PST
Google
7-25-15 5:20pm PST
I have bought over 15 Domains in past two years so of course this Article caught my attention,
let me know what you think if you buy a good amount of Domain names and this affects you.
Brian M Rye-Blog Autor
Article from Google Webmaster Central Blog
link to Article
http://googlewebmastercentral.blogspot.com/2015/07/googles-handling-of-new-top-level.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+blogspot%2FamDG+%28Official+Google+Webmaster+Central+Blog%29
7-24-15 6:10am PST
Posted on
Google Webmaster Blog,
link to article
http://googlewebmastercentral.blogspot.com/2015/07/google-case-study-on-app-download-interstitials.html
Posted by David Morell, Software Engineer, Google+
8-8-15, 4:18PM PST
7-31-15 1:42am PST
Google Webmaster Central Blog
Google+: A case study on App Download Interstitials
Many mobile sites use promotional app interstitials to encourage users to download their native mobile apps. For some apps, native can provide richer user experiences, and use features of the device that are currently not easy to access on a browser. Because of this, many app owners believe that they should encourage users to install the native version of their online property or service. It’s not clear how aggressively to promote the apps, and a full page interstitial can interrupt the user from reaching their desired content.
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:
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.
While 9% sounds like a great CTR for any campaign, we were much more focused on the number of users who had abandoned our product due to the friction in their experience. With this data in hand, in July 2014, we decided to run an experiment and see how removing the interstitial would affect actual product usage. We added a Smart App Banner to continue promoting the native app in a less intrusive way, as recommended in the Avoid common mistakes section of our Mobile SEO Guide. The results were surprising:
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.)
Based on these results, we decided to permanently retire the interstitial. We believe that the increase in users on our product makes this a net positive change, and we are sharing this with the hope that you will reconsider the use of promotional interstitials. Let’s remove friction and make the mobile web more useful and usable!
(Since this study, we launched a better mobile web experience that is currently without an app banner. The banner can still be seen on iOS 6 and below.)
Posted by David Morell, Software Engineer, Google+
Posted by David Morell, Software Engineer, Google+
7-31-15 1:42am PST
Google Webmaster Central Blog
#NoHacked: How to avoid being the target of hackers
If you publish anything online, one of your top priorities should be security. Getting hacked can negatively affect your online reputation and result in loss of critical and private data. Over the past year Google has noticed a 180% increase in the number of sites getting hacked. While we are working hard to combat this hacked trend, there are steps you can take to protect your content on the web.
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 securityCreating 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 updatedOne 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 issuesYour 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 siteIt’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.
We’re kicking off the campaign with some basic tips on how to keep your site safe on the web.
1. Strengthen your account securityCreating 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 updatedOne 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 issuesYour 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 siteIt’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.
Google Webmaster Central Blog
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 countTop 10 pagesTop 10 queries in IndiaTop 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.
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 countTop 10 pagesTop 10 queries in IndiaTop 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.
7-26-15 3:22pm PSt
Goolge
Official news on crawling and indexing sites for the Google index
Update on the Autocomplete API
link to article
http://googlewebmastercentral.blogspot.com/
Google Search provides an autocomplete service that attempts to predict a query before a user finishes typing. For years, a number of developers have integrated the results of autocomplete within their own services using a non-official, non-published API that also had no restrictions on it. Developers who discovered the autocomplete API were then able to incorporate autocomplete services, independent of Google Search.
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.
Google Search provides an autocomplete service that attempts to predict a query before a user finishes typing. For years, a number of developers have integrated the results of autocomplete within their own services using a non-official, non-published API that also had no restrictions on it. Developers who discovered the autocomplete API were then able to incorporate autocomplete services, independent of Google Search.
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.
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.
Google Webmaster Central Blog
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 countTop 10 pagesTop 10 queries in IndiaTop 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.
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 countTop 10 pagesTop 10 queries in IndiaTop 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.
SEO for startups in under 10 minutes You Tube Video,
by Google Webmasters,
Google Webmaster Central Blog
#NoHacked: How to recognise and protect yourself against social engineering
Today in our #NoHacked campaign, we’ll be talking about social engineering. Follow along with discussions on Twitter and Google+ using the #nohacked hashtag. (Part 1)
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:
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 PageAvoid 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.
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.
7-26-15 3:22pm PSt
Goolge
Official news on crawling and indexing sites for the Google index
Update on the Autocomplete API
link to article
http://googlewebmastercentral.blogspot.com/
Google Search provides an autocomplete service that attempts to predict a query before a user finishes typing. For years, a number of developers have integrated the results of autocomplete within their own services using a non-official, non-published API that also had no restrictions on it. Developers who discovered the autocomplete API were then able to incorporate autocomplete services, independent of Google Search.
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.
Google Search provides an autocomplete service that attempts to predict a query before a user finishes typing. For years, a number of developers have integrated the results of autocomplete within their own services using a non-official, non-published API that also had no restrictions on it. Developers who discovered the autocomplete API were then able to incorporate autocomplete services, independent of Google Search.
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.
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.
7-26-15 3:12pm PST
Official news on crawling and indexing sites for the Google index
App deep linking with goo.gl
Posted by Fabian Schlup, Software Engineer
Link to Article
http://googlewebmastercentral.blogspot.com/2015/05/app-deep-linking-with-googl.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+blogspot%2FamDG+%28Official+Google+Webmaster+Central+Blog%29
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.
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.
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.
I have bought over 15 Domains in past two years so of course this Article caught my attention,
let me know what you think if you buy a good amount of Domain names and this affects you.
Brian M Rye-Blog Autor
Article from Google Webmaster Central Blog
link to Article
http://googlewebmastercentral.blogspot.com/2015/07/googles-handling-of-new-top-level.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+blogspot%2FamDG+%28Official+Google+Webmaster+Central+Blog%29
Google's handling of new top level domains
Posted: Tuesday, July 21, 2015
With the coming of many new generic top level domains (gTLDs), we'd like to give some insight into how these are handled in Google's search. We’ve heard and seen questions and misconceptions about the way we treat new top level domains (TLDs), like .guru, .how, or any of the .BRAND gTLDs, for example:
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.
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.
7-24-15 6:10am PST
Google+: A case study on App Download Interstitials
Posted on
Google Webmaster Blog,
link to article
http://googlewebmastercentral.blogspot.com/2015/07/google-case-study-on-app-download-interstitials.html
Google+: A case study on App Download Interstitials
By David Morell, Software Engineer, Google+
Posted: Thursday, July 23, 2015
Many mobile sites use promotional app interstitials to encourage users to download their native mobile apps. For some apps, native can provide richer user experiences, and use features of the device that are currently not easy to access on a browser. Because of this, many app owners believe that they should encourage users to install the native version of their online property or service. It’s not clear how aggressively to promote the apps, and a full page interstitial can interrupt the user from reaching their desired content.
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:
Posted by David Morell, Software Engineer, Google+
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.
While 9% sounds like a great CTR for any campaign, we were much more focused on the number of users who had abandoned our product due to the friction in their experience. With this data in hand, in July 2014, we decided to run an experiment and see how removing the interstitial would affect actual product usage. We added a Smart App Banner to continue promoting the native app in a less intrusive way, as recommended in the Avoid common mistakes section of our Mobile SEO Guide. The results were surprising:
- 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.)
Based on these results, we decided to permanently retire the interstitial. We believe that the increase in users on our product makes this a net positive change, and we are sharing this with the hope that you will reconsider the use of promotional interstitials. Let’s remove friction and make the mobile web more useful and usable!
(Since this study, we launched a better mobile web experience that is currently without an app banner. The banner can still be seen on iOS 6 and below.)
Posted by David Morell, Software Engineer, Google+
