中文网站站长博客 [ZH-CN]: 七月 2015

中文网站站长博客。

Google中文网站站长博客为广大站长提供关于Google网页抓取、收录、搜索引擎优化以及其他相关的站长资讯。

#NoHacked：如何避免成为黑客的攻击对象

2015年7月30日星期四

#NoHacked: How to avoid being the target of hackers 作者：Eric Kuan, 站长关系专家；Yuan Niu, 网站分析师

如果您在网上发布任何内容，那么您需要确保的重要事项之一便是安全性。遭到黑客攻击可能会给您的网络声誉造成负面影响，并导致关键的隐私数据丢失。仅在过去一年内，Google 就发现被黑网站的数量上升了 180%。我们一直在努力解决这一被黑趋势，与此同时，您也可以采取一些措施来保护自己的网络内容。

我们将继续开展 #nohacked 宣传活动。我们将重点介绍如何保护您的网站免受黑客攻击，并让您更深入地了解其中某些宣传活动会如何有效地帮助您确保网站安全。您可以在 Twitter 和Google+ 上关注 #nohacked 宣传活动。我们还将举办关于“安全”的 Google 环聊直播，届时您可以直接向我们的安全专家提问。

今天，我们将向您介绍一些关于如何确保网站安全无虞的基本提示，以此开始我们的宣传活动。

增强您帐户的安全性

要保护您的网站，设置一个很难被猜中或破解的密码必不可少。例如，您的密码既可以同时包含字母、数字和符号，也可以是一个口令。密码长度很重要。密码越长，就越难被猜中。网络上有很多资源可帮助您检测密码的安全系数。测试一个与您的密码相似的密码（切勿在其他网站上输入您的实际密码）可让您了解您密码的安全系数有多高。

此外，避免针对多种服务重复使用相同的密码很重要。攻击者经常会使用从泄露的密码列表或被黑的服务中获取的已知用户名和密码组合，来尝试入侵尽可能多个帐户。

您也应为提供双重身份验证服务的帐户启用此项服务。这样做可以显著提升您帐户的安全性，并保护您的帐户免受各种攻击。我们将在两周后详细介绍双重身份验证。

及时更新您网站上的软件

黑客入侵您网站时最常用的方式之一便是利用您网站上的不安全软件。请务必定期检查您网站上是否存在过时的软件，尤其要检查是否有会修补安全漏洞的更新。如果您使用网络服务器（如 Apache 和 nginx）或商业网络服务器软件，请确保及时修补您的网络服务器软件。如果您在自己的网站上使用了内容管理系统(CMS) 或任何插件，请确保及时更新这些工具。此外，如果您使用了网络服务器软件和 CMS，请将其注册加入安全通知邮寄名单。您也不妨考虑完全移除您网站上所有对您无用的插件或软件，因为它们不仅可能会带来风险，还可能会减慢您网站的运行速度。

调查您的托管服务提供商会如何处理安全问题

当您选择托管服务提供商时，一定要考虑该提供商在安全性和清理被黑网站方面的政策。如果您使用托管服务提供商，请询问对方是否会为清理具体网站的问题按需提供支持。您还可以查看在线评价，看看他们是否有与帮助被侵网站的所有者清理被黑内容相关的记录。

如果您掌控着自己的服务器或使用了虚拟专用服务器 (VPS) 服务，请确保您已为处理任何可能出现的安全问题做好准备。服务器管理非常复杂，而服务器管理员的核心任务之一就是要确保您的网络服务器和内容管理软件及时得到修补和更新。如果您没有很好的理由必须亲自管理自己的服务器，则可能会发现聘请托管服务提供商来提供托管服务会让您非常省心省力。

使用 Google 工具及时获知您网站上的潜在被黑内容

借助工具积极主动地监测您的网站很重要。越早发现攻击活动，您就能越早着手修正您的网站。

我们建议您注册 Search Console（如果您尚未注册的话）。Google 会通过 Search Console 将您网站上存在的问题（包括我们检测到被黑内容这一情况）告知您。您也可在自己的网站上设置 Google 快讯，以便 Google 在发现任何关于您网站的可疑搜索结果时向您发送通知。例如，如果您拥有一个名为 www.example.com 的宠物用品网站，则可设置一个 [site:example.com 廉价软件] 提醒，以便 Google 在发现您网站上突然开始显示关于廉价软件的被黑内容时提醒您。您可以为自己的网站设置多个不同的垃圾内容字词提醒。如果您不确定该使用什么样的垃圾内容字词，则可使用 Google 来搜索常见垃圾内容字词。

我们希望这些提示可帮助确保您网站的安全性。请一定使用 #nohacked 标签关注我们的社交宣传活动，并分享您关于如何确保自己的网络内容安全无虞的提示或技巧。

如果您有任何其他问题，请在网站站长帮助论坛中发帖提问。在那里，众多的网站站长同行会为您答疑解惑。您也可以参加我们将在8月26日举办的关于“安全”的环聊直播。

Google

有关自动填充 API 的一项重要更新

2015年7月27日星期一

Update on the Autocomplete API Peter Chiu, Autocomplete team Google 搜索提供了一项自动填充服务，该服务会在用户输入查询字词时尝试预测他们要查询的内容。多年来，很多开发者都通过一款未公开发布的非官方 API 在自己的服务中集成了自动填充结果。由于该 API 对此没有任何限制，因此，发现这款自动填充 API 的开发者能够集成自动填充服务，并使该服务独立于 Google 搜索。

开发者群体经常会通过未公开发布的 API 对 Google 服务进行逆向工程，并且有很多次都取得了不错的成果。Google Maps API 就是一个例子。我们看到，富有创新精神的工程师通过将地图数据与其他数据来源加以整合，取得了意想不到的效果，因此在数月之后，我们将该 API 变成了一款正式发布且受支持的 API。我们目前支持 80 多款 API，开发者可以利用它们将 Google 服务和数据集成到自己的应用中。

不过，有时候使用不受支持且未公开发布的 API 也存在风险，比如使用的 API 不再可用。我们开发自动填充功能的初衷是为了完善 Google 搜索服务，从未想过将其用于与预测用户的搜索查询无关的用途。随着时间的推移，我们认识到，虽然我们能够想象出自动填充数据 Feed 的一些其他可能有价值的用途，但总体来说，我们优化自动填充内容的目的是为了帮助用户更快速地获得搜索结果，而在网络搜索之外的环境中，这些内容并不能给用户带来实质性的好处。

为了使作为 Google 搜索一部分的自动填充功能保持完整性，自 2015年8月10日起，我们将限制用户在未经授权的情况下使用未公开发布的自动填充 API。我们希望确保用户按我们的设计初衷使用自动填充功能，也就是将它与 Google 搜索结合使用。我们相信这有助于使这两项服务都能实现最好的用户体验。

对于仍希望在自己的网站上使用自动填充服务的发布商和开发者，我们提供了一个替代方案。通过 Google 自定义搜索引擎 (CSE)，网站可以继续将自动填充功能与 Google 搜索功能结合使用。此项变更不会影响已经在使用 Google CSE 的合作伙伴。对于其他合作伙伴，如果希望在 2015年8月10日后继续使用自动填充功能，请参阅我们的 CSE 注册页面。

Google

Google+：关于应用下载插页式广告的案例研究

2015年7月27日星期一

Google+: A case study on App Download Interstitials 许多移动网站使用推销应用的插页式广告来吸引用户下载其原生移动应用。某些应用的原生版本可以提供更丰富的用户体验，并有助于充分利用设备上目前难以通过浏览器使用的功能。因此，许多应用所有者都认为，他们应该吸引用户安装其在线资源或服务的原生版本。目前还不清楚应该以多大力度来推销此类应用，而全页插页式广告会妨碍用户查看他们想要查看的内容。

此前，我们决定详细了解一下我们自己在 Google+ 移动网站上使用插页式广告的情况。内部用户体验研究结果表明，插页式广告会导致用户体验变得非常糟糕。詹妮弗·戈夫 (Jennifer Gove) 在去年的 IO 大会上发表了精彩演讲，其中特别提到了这种糟糕的用户体验。虽然我们直觉上认为应该停止使用插页式广告，但我们希望根据数据来做出决策，于是我们开始研究插页式广告会对用户造成什么影响。我们的分析结果表明：

＊对于包含插页式广告的网页，有 9% 的访问者点按了“下载应用”按钮（请注意，在这些用户中，有些之前已安装相应应用或可能并未在应用商店中完成下载流程）。

＊有 69% 的访问者放弃访问我们的网页。这些用户既没有前往应用商店，也没有继续浏览我们的移动网站。

尽管对于任何广告系列来说，9% 听起来都是一个非常高的 CTR，但我们更关注的是，因为糟糕的体验而放弃使用我们产品的用户数量。得到这些数据后，我们于 2014 年 7 月决定开展一项实验，看看停止使用插页式广告会对实际的产品使用情况造成怎样的影响。根据《移动版 SEO 指南》中的避免常见错误部分提供的建议，我们添加了一个智能应用横幅广告，以干扰性较低的方式继续推销原生应用。实验结果出人意料：

＊我们移动网站的单日有效用户数量增加了 17%。

＊G+ iOS 原生应用安装数量几乎没有受到影响（减少了 2%）（我们没有报告 Android 设备上的安装数量，因为这些设备大部分都预装了 Google+）。

根据这些结果，我们决定永久淘汰插页式广告。我们认为，使用我们产品的用户数量大幅增加就足以表明这项改动是合理的，我们在此分享这些数据的目的是希望您重新考虑一下是否确实需要使用推销应用的插页式广告。让我们一起消除影响对用户体验的不利因素，使移动网站变得更加实用且更加好用！

Google

Google 如何处理新的顶级域名

2015年7月22日星期三

Google's handling of new top level domains 作者： John Mueller,网站趋势分析师

随着众多新的通用顶级域名 (gTLD) 不断涌现，我们想介绍一下 Google 的搜索服务如何处理这些域名。据我们所知，用户对我们如何处理新的顶级域名 (TLD)（如 .guru、.how 或任何 .BRAND gTLD）存在很多疑问和误解，例如：

问：新的 gTLD 对搜索结果有何影响？Google 会对搜索算法做出有利于这些 TLD 的更改吗？它们对搜索结果的实际影响如何？

答：总体而言，我们的系统对新 gTLD 的处理方式与对其他 gTLD（例如 .com 和 .org）的处理方式相同。TLD 中的关键字不会对搜索结果产生任何正面或负面影响。

问：Google 如何处理 IDN TLD（例如みんな）？Googlebot 能够抓取这些域名并将其编入索引（以便能够在搜索中使用）吗？

答：能。我们可以像使用其他 TLD 一样使用这些 TLD（通过执行 [site:みんな] 等查询，您可以轻松地确认这一点）。Google 会将主机名的 Punycode 版本视为等同于未编码的版本，因此您不需要单独对其进行重定向或规范化处理。对于网址的其余部分，请务必对网址中的路径和查询字符串使用 UTF-8（当使用非 ASCII 字符时）。

问：.BRAND TLD 的权重会高于（或低于）.com 的权重吗？

答：不会。我们会一视同仁地处理这些 TLD 和其他 gTLD。这些域名需要具有相同的地理位置定位设置和配置，并且在我们抓取网址、将网址编入索引或对网址排名时，这些域名不会具有更高的权重或更大的影响。

问：Google 如何处理新的地区 TLD 或城市 TLD（例如 .london 或 .bayern）？

答：即使这些域名看起来像是地区专属域名，我们仍会将其作为 gTLD 来处理。这和我们处理区域性 TLD（例如 .eu 和 .asia）的方式一致。有时可能会有一些例外情况，具体视这些域名在实际中的使用情况而定。如需多区域和多语言网站以及在 Search Console 中设置相关地理位置定位方面的更多信息，请访问我们的帮助中心。

问：Google 如何处理实际的 ccTLD（国家/地区代码顶级域名）？当用户在相应国家/地区进行搜索时，Google 会将这些 ccTLD（例如 .uk、.ae 等）视为当地域名吗？

答：默认情况下，大多数 ccTLD（存在例外情况）都会导致 Google 使用它们对网站进行地理位置定位；ccTLD 告诉我们对应的网站可能与相应国家/地区具有更高的相关性。再提醒您一次，如需多区域和多语言网站方面的更多信息，请访问我们的帮助中心。

问：为了实现搜索引擎优化 (SEO)，我想将我的域名从 .com 迁移到新的 TLD，Google 会提供相关支持吗？如何在迁移网站的同时确保搜索排名或搜索记录不会受到任何影响？

答：我们的帮助中心内提供了大量关于网站迁移的文档。我们会一视同仁地对待此类迁移和任何其他网站迁移。也就是说，域名更改可能需要一段时间才能体现在搜索结果中（此外，用户也希望电子邮件地址的有效期更长久），因此通常情况下，您最好是选择能够满足长期需求的域名。

我们希望上述内容能够帮助您更详细地了解我们如何处理新的顶级域名。如果您有任何其他疑问，可以随时在此处或在我们的帮助论坛中发帖咨询。

Google

博客归档

2020
- 十一月
- 九月
- 八月
- 七月
- 六月
- 五月
- 四月
- 三月
- 二月
- 一月

2019
- 十一月
- 十月
- 九月

2018
- 七月
- 五月
- 二月
- 一月

2017
- 十二月
- 十一月
- 六月
- 四月
- 三月

2016
- 十二月
- 十一月
- 十月
- 九月
- 八月
- 五月
- 三月
- 一月

2015
- 十二月
- 十一月
- 十月
- 九月
- 八月
- 七月
- 五月
- 四月
- 三月
- 二月
- 一月

2014
- 十一月
- 九月
- 八月
- 七月
- 六月
- 五月
- 四月
- 三月
- 二月
- 一月

2013
- 十二月
- 十一月
- 九月
- 八月
- 七月
- 六月
- 五月
- 四月
- 三月
- 二月
- 一月

2012
- 十二月
- 十一月
- 十月
- 九月
- 八月
- 七月
- 六月
- 五月
- 四月
- 三月
- 二月
- 一月

2011
- 十二月
- 十一月
- 十月
- 九月
- 八月
- 七月
- 六月
- 五月
- 四月
- 三月
- 二月
- 一月

2010
- 十二月
- 十一月
- 十月
- 九月
- 八月
- 七月
- 六月
- 五月
- 四月
- 三月
- 二月
- 一月

2009
- 十二月
- 十一月
- 十月
- 九月
- 八月
- 七月
- 六月
- 五月
- 四月
- 三月
- 二月
- 一月

2008
- 十二月
- 十一月
- 十月
- 九月
- 八月
- 七月
- 六月
- 五月
- 四月
- 三月
- 二月
- 一月

2007
- 十二月
- 十一月
- 十月
- 九月
- 八月
- 七月

Feed

Give us feedback in our Product Forums.

Google
Privacy
Terms