標籤彙整: Google

Google Urchin现在公开测试

据Google Analytics官方博客报道,Google宣布Urchin软件的beta版本已经开放下载了,和Google Analytics不同的是,Urchin可以安装在你自己的服务器上,Google Analytics是Google公司在收购了Urchin公司后推出的一款网络分析软件。

urchinsw.png

为什么使用Urchin软件?

Urchin软件用于管理和分析那些处于防火墙保护的、内容敏感而不适合使用Google Analytics的网络分析工具,Urchin能处理和分析服务器的日志文件内容,并能使用浏览器来查看统计资料,Urchin软件内建数据库、支持多平台系统(Windows/FreeBSD/Linux)、自动分析多站点服务器流量资料,由于使用的是本地数据库,并且不需要访问Internet,因此数据分析内容可以保存在本地,不会被Google等第三方知道。

•更准确地缘识别访客
•两岸分割选择类似Google Analytics功能
•电子商务和活动跟踪包括: (不再需要额外模块)
•大幅度提高嵌入式调度,以更轻松地管理加工和再加工,就业机会
•改进的用户界面
•更强大的日志处理引擎

你可以下载一个90天版的测试版在这里。一旦Urchin软件从Google出来的测试版,你可以购买它为2995美元通过Urchin软件授权顾问

Google回应微软购雅虎案 怒斥其欲垄断互联网

据国外媒体报道,针对微软上周五向雅虎发出收购要约一事,Google企业开发部门高级副总裁兼首席法务官戴维·德拉蒙德(David Drummond)周日在一份正式声明中作出了回应。德拉蒙德称,如果微软成功收购雅虎,将给美国及全球互联网产业的正常发展带来“麻烦”,因为微软是想借此垄断互联网产业。他还呼吁,美国及国际监管机构应就此展开全面调查。

 

德拉蒙德在一份书面声明中表示:“微软对雅虎的恶意收购将导致诸多麻烦问题。这并不仅仅是一起金融交易,也不仅仅是某家公司收购另一家公司,而是关系到互联网两大基本原则:开放性和创新性能否得以继续维持的重大事件。”他还表示,微软之所以向雅虎提出收购请求,目的是想利用其在个人电脑操作系统领域的垄断优势向互联网延伸,从而以非法手段获得互联网领域的垄断地位。

德拉蒙德说:“微软已经在某些产业领域内占据了垄断地位,如今它又希望把这种垄断优势向新市场扩展。”他接着指出,微软已经因为涉嫌垄断而导致了多起法律纠纷,美国和国际监管机构应该对微软-雅虎交易进行全面调查,以阻止微软将其垄断优势向互联网产业延伸。

微软上周五表示,已向雅虎董事会发出收购要约,希望以446亿美元收购后者;微软出价相当于每股31美元,比雅虎股价上周四收盘价溢价62%。美国国会众议院下属司法委员会此前表示,将于本周晚些时候举行听证会,以审查微软-雅虎交易是否涉嫌市场垄断。

分析人士称,如果雅虎接受微软收购请求,将使微软获得与Google进行新一轮竞争的实力。近年来,Google在美国搜索和网络市场占据了优势地位,虽然微软与雅虎都一直采取积极措施应对Google的挑战,但从互联网业务整体实力看,微软和雅虎两家加起来也远不如Google.

微软发表官方声明 回应Google指其垄断互联网

针对Google企业开发部门高级副总裁兼首席法务官戴维·德拉蒙德(David Drummond)周日发表声明,回应微软上周五向雅虎发出收购要约一事,微软首席法律顾问布拉德·史密斯(Brad Smith)随即发表一份正式声明,作出了回应。史密斯在其声明中称:“ 微软与雅虎的结合,将会通过建立两家企业在互联网搜索和广告市场竞争的格局,创造出一个更具有竞争力的市场。如果微软与雅虎不合并,那么互联网的竞争只能是大打折扣。
时至今日,Google已成为了一家在互联网搜索引擎和广告产业上占据绝对优势的企业。Google已占据了全球付费搜索市场75%的份额,而且其份额仍在不断扩大。根据已公布的报告显示,Google在美国的搜索份额超过65%,在欧洲的份额超过85%。微软和雅虎一共只占据了美国市场30%的份额,欧洲市场10%左右的份额。微软承诺将开放、创新并保护互联网上的用户隐私。我们相信,微软和雅虎的结合将有利于这些目标的实现。”

在史密斯的声明中,并没有提到Google此前所提到的即时通讯软件和电子邮件的问题。这也反映出,或许监管者更为关注的将是广告营收和在搜索与广告市场的竞争问题,而不是电子邮件或即时通讯软件问题。

德拉蒙德在此前的声明中曾表示,如果微软成功收购雅虎,将给美国及全球互联网产业的正常发展带来“麻烦”,因为微软是想借此垄断互联网产业。他还呼吁,美国及国际监管机构应就此展开全面调查。德拉蒙德此前还表示:“微软对雅虎的恶意收购将导致诸多麻烦问题。这并不仅仅是一起金融交易,也不仅仅是某家公司收购另一家公司,而是关系到互联网两大基本原则:开放性和创新性能否得以继续维持的重大事件。微软之所以向雅虎提出收购请求,目的是想利用其在个人电脑操作系统领域的垄断优势向互联网延伸,从而以非法手段获得互联网领域的垄断地位。微软已经在某些产业领域内占据了垄断地位,如今它又希望把这种垄断优势向新市场扩展。”

微软在2月1日宣布,已经向雅虎董事会提交收购要约,计划以每股31美元收购后者全部已发行普通股,交易总价值约为446亿美元。微软计划以一半现金、一半股票的方式完成这一交易,雅虎股东可以选择获得现金,还是固定数量的微软普通股。微软的收购报价较雅虎1月31日的收盘价19.18美元溢价62%。

李开复谈春运交通图:谷歌更理解中国用户需求

2月4日早间消息,就谷歌近期推出春运交通图、新年短信整合搜索等应用,谷歌全球副总裁兼大中华区总裁李开复向新浪科技表示,这些都是为满足中国用户需要 在春节前特别推出的服务,可见谷歌更了解中国用户的需求.曾被竞争对手暗讽为“不够懂中文”的谷歌,似乎正希望通过以产品说话,以事实说法的方式来表明自 己不甘示弱.在此之前,从微软跳槽过来两年多的李开复与他一手搭建的中国区团队,承受了巨大的压力.

李开复


  春运交通图受好评

  1月30日上午,谷歌中国宣布紧急推出春运交通图,该交通图由谷歌中国地图“抗击风雪,回家过年”临时小组制作,意在帮助身在异地的人们及时了解国内交通情况.

  由于迎合了众多人群的“回家”需求,谷歌春运交通图推出后迅速得到众多网友关注,并在多家网络媒体中引起热议.谷歌工程师也表示,目前已收到来自全国各地很多网友的邮件,把自己了解到的天气交通情报告诉谷歌.

  值得注意的是,这款产品是谷歌中国几位工程师在一天前小组讨论中的灵感闪现.当天上午,李双峰和陆韵晟两位工程师萌发制作该地图的想法,当天下午,由谷歌工程师组成的临时小组紧急推出该春运交通地图页面.

  这是一款并不浩大的杰作,但却迎合了近期众多人群的热点需求.有业内人士表示,这种非常具有本地化特色的产品却不是出自本土公司百度之手,耐人寻味.

  而谷歌用了2年时间搭建起来的本地团队,似乎正在吸取了谷歌公司的精髓后,用最本土化的办法去攻克国际互联网公司的本土化难题.

  李开复亲自推销新品

  春运交通图上线后的第三天,谷歌中国宣布推新年短信搜索服务.用户在google.cn的中输入“新年短信”等关键词,就可在搜索结果的最上方随机显示一条祝福短信,用户可通过“发送到手机”功能将它免费地发送到自己的手机上,然后再转发给亲友.

  接连的动作表明,谷歌已找到本土化感觉,并渐入佳境.为了给谷歌的新品笼络人气,李开复亲自出面“推销”.2月1日傍晚,在新年短信搜索服务上线后不久,一条主题是李开复拜年的短信迅速传遍业内互联网记者与编辑.

  李开复正在以他的行动来证明,谷歌在中国不退反进的决心.也是在近期,李开复曾在与新浪科技谈及中国雅虎战略转型时,称谷歌在中国市场有长期耐心,不可能放弃中国业务.

  “谷歌新年短信整合搜索的网页应用及手机应用,生活搜索乃至我们紧急推出的春运交通图是为了满足中国用户的需要在春节前特别推出的服务,在体现了谷歌了解用户需求的同时,又反射出谷歌在整合搜索上取得进一步发展.”李开复说.

  有内部消息称,为了迎合中国过年的气氛,谷歌在春节期间的搜索结果将会出现小变化,这是过去从来没有尝试过的.

  李开复谈到2008年计划时表示,谷歌会继续发挥技术优势,深化本土化服务与提高用户体验.这一切似乎都在验证着,“本土化”的春节尚未到来,搜索市场的竞争也才刚刚开始.
文/新浪科技

Google AdSense产品名称已中文化

尽管Google AdSense进入中国市场已有很长一段时间,但你会发现,它一直没有中文名。这样一来,如果你要向一个中国新用户推荐Google AdSense,你就会发现不方便的地方。比如,针对网页内容的AdSense产品,它只有英文名AdSense For Content,针对网页搜索的AdSense产品的名称则为AdSense For Search。这些超长的英文名称对于AdSense在中国的推广是极不利的。为此,谷歌近期将这些长长的英文名汉化了,现在你已经可以在AdSense后台里看到它们的中文名。对照如下:

旧—>新

AdSense For Content—>AdSense内容广告
AdSense For Search—>AdSense搜索广告
AdSense For Mobile Content—>AdSense 移动广告

  令人遗憾的是,谷歌仍不打算将”AdSense”这个品牌汉化,不知是不是受了”谷歌”取名不顺影响。如果你仔细想想,就会发现AdSense的中文名其实也真不好取=..=

Google.ad诞生

  Google以广告(ad)为生,这一点将可以在后天发布的Google 2007第四季财报里再次得到验证。但标题里的Google.ad却是Google最新发布的一个官方域名,与广告无关。 .ad指的是Andorra,尽管Andorra看起来长得有点像Google的开放手机平台”Android”,但事实上它是欧洲的安道尔公国的名称。根据外交部的资料,安道尔公国不仅地小人稀,更有趣的是它的国家元首竟然是法国总统雅克·希拉克和西班牙乌赫尔地方主教霍安·恩里克·比韦斯,称为两大公。

  Google.ad是Google所推出的第160个官方本地域名。从数量上看,这意味着Google的国际化已达到了其竞争对手无法相比的水平。

Google AdSense的PIN码发送标准已降为10美元

来自G速客

 最近Google AdSense的变化太多了,不知何时是尽头。如果你还在为谷歌自动将你的广告字体变得大且难看而感到郁闷,现在至少有个小小的好消息了。Google AdSense为了验证你的帐户的有效性,它会给合标准的用户邮寄个人识别号码(PIN)或进行电话验证。其中的PIN码验证原标准是用户的帐户余额首次达到50美元。而现在,这个标准已降至10美元。换言之,在你开始投放AdSense广告并且获取10美元收入时,Google就开始给你寄PIN码了,而不必等到50美元。

  当前AdSense的官方说明文档的英文版已进行更新,而简体中文版的说明仍然是50美元。但已经有部分中文用户在收入达10美元时,收到了Google邮寄的PIN码。这证明了这次PIN码改动是对所有AdSense用户有效的。

  如果你想知道你的AdSense帐户是否需要PIN码认证,你可进入AdSense后台里的”我的帐户”->”付款历史”里查看。

迎击风雪 回家过年——谷歌紧急推出春运交通图帮助出行

回家过年,似乎是我们每个人过年时不可动摇的情结,与往年不同,今年回家的路显得格外长、格外难,春运的焦点不再是买票难,而是行路难,由于我国中部和南方罕见的连续暴雪灾害,造成高速公路拥堵、封路,火车飞机停运或延误,并导致数以万计的春运旅客滞留在了回家的路上。今天,我们谷歌地图工程团队紧急推出“春运交通图”,以标注式电子地图的形式提供了全国春运沿线各主要城市的天气和交通整合信息。这是周二上午谷歌的工程师李双峰和陆韵晟讨论时萌发的想法,随后大家就自动组成一个临时小组,下午紧急推出了这个页面,我们衷心希望能帮助那些正在路上或者准备回家的朋友们及时了解路况信息,提前制定合理的出行计划,抗击风雪回家过年。

在谷歌“春运交通图”上,我们以图标的形式在原有的电子地图上增添了与天气信息相关的信息。点击春运沿线重要城市上方的天气图标,地图上就会弹出这个城市详细的天气情况。



在重要的交通枢纽上方,大家还可以看到一些火车、汽车或飞机状的小图标,打开它们则能了解该地交通的最新情况,如停止售票、关闭机场和汽车停运的时间和原因,停运的车次,车站或机场滞留的旅客人数以及在何处退票等。


“春运交通图”上还标出了主要的铁路、高速公路和国道,如果铁路或公路被”加红加粗”、那就说明它可能处于封路或受阻状态。点击后即可了解滞留人数、目前情况、持续时间。


除了这些图标信息外,谷歌“春运交通图”左侧列出了和春运相关的、涉及天气及交通的标题,例如”上海停售长途火车票”或”南京机场关闭”,不必费力放大、缩小和拉动电子地图来寻找关注的城市和地区,只需点击这些标题,电子地图就会自动平移到相应的城市或地区,弹出详细的信息。


如果您了解最新的天气、交通情报,欢迎发送到[email protected],经过核实无误后,我们会把它更新到“春运交通图”上。希望通过我们的技术能为大家提供一点帮助,祝愿所有的朋友都能安全顺利地回家,预祝大家春节快乐。

春运交通图:ditu.google.cn/chunyun

AdSense 广告换新装

在2007年,我们根据中国发布商的需求发布了“允许的网站”和“广告在新窗口中打开”等功能,为了让 AdSense 广告更好地服务本地发布商,我们的努力从来都没有停止过。现在,根据中国发布商的反馈,我们又对 AdSense 文字广告的外观进行了调整 – 增大了广告字体,如下图所示。我们的系统会根据广告单元的格式和返回广告的数量来决定广告字体的大小。

我们十分希望新的广告外观能够给您的网站用户带来更好的体验,并能提高您的网站收益。也希望广大发布商能给我们的广告提出更多反馈意见,帮助我们改进。

使用热门选择:元标记(Meta tags)和网页搜索

发表者:John Mueller, 网站管理员趋势分析员,苏黎世
原文:Answering more popular picks: meta tags and web search
发表于:2007年12月4日,星期二,上午11时53分
如果你能写好和维持准确的元标记(例如,描述性标题和为搜索机器人提供的信息),谷歌就可以更准确地爬行、索引并在搜索结果中显示你的网站。元标记为各种各样的客户端(例如浏览器和搜索引擎)提供信息。请记住,每一个客户端可能只解析对该客户端有用的元标记,而忽略了其他元标记(虽然它们有其他用处)。

下面是谷歌如何解析以下 HTML 页的元标记:
<!DOCTYPE …><head>
<title>传统瑞士奶酪火锅食谱
<title>
谷歌使用此标记,网站管理员应非常注意它的准确性
<meta name=”description”
content=”奶酪火锅是 …”>
谷歌使用此标记,我们的搜索结果会显示它
<meta name=”revisit-after”
content=”14 days”>
谷歌不使用此标记,其他主要搜索引擎也不使用
<META name=”verify-v1″
content=”e8JG…Nw=” />
可选,谷歌网络管理员工具用到此标记
<meta name=”GoogleBot” content=”noOdp”>
<meta …>
<meta …>
</head>
可选

<meta name=”description” content=”对本页的描述”>此标记提供了对当前页面一个简短描述。在很多情况下该描述会作为页面摘要(snippet)显示在谷歌的搜索结果中。详情请参阅我们的博客文章“使用更好的元描述来改善页面摘要”以及帮助中心的文章“如何更改网站的标题和描述”。虽然描述元标记是可选的,并且不会影响到您的排名,一个好的描述可以产生一个更好的页面摘要,这反过来又可以帮助提高我们的搜索结果质量和你的网页的访问者数量。

<title>页面标题</title>从技术上讲,标题标记并不是一个元标记,它经常与”description”标记一起使用。此标记的内容(即标题)一般显示在搜索结果中(当然,当用户使用浏览器来浏览网页或察看书签时也能看到页面标题)。我们的博客文章”针对访问者,还是针对搜索引擎?“尤其是”充分利用网页标题”中有关于标题标记的更多信息。

<meta name=”robots” content=”…, …”>
<meta name=”googlebot” content=”…, …”>
这些元标记控制搜索引擎如何抓取和索引页。 “robots”元标记指定的规则适用于所有搜索引擎,”googlebot”元标记指定的规则只适用于谷歌。谷歌可以理解以下值(当指定多个值时,用逗号将它们分开) :

* noindex: 防止网页被索引(见”使用元标记拦截或删除网页“)
* nofollow: 不要通过当前页的链接来寻找并抓取新的网页(也见”使用元标记拦截或删除网页“)
* nosnippet: 在搜索结果中显示当前页时,不要显示页面摘要(见”防止显示或删除页面摘要“)
* noodp: 在为本页产生标题或页面摘要时,不要使用开放式目录项目(又名dmoz.org)中的文本(见”如何更改网站的标题和描述?“)
* noarchive: 在显示本网页于搜索结果中时,不要显示一个”网页快照”链接(见”防止显示或删除缓存的网页“)
* unavailable_after:[日期]:在指定的日期和时间后从搜索结果中删除这个网页(见”机器人排除协议:现在更灵活“)

当你完全省略此标记或当你指定content= “all”时,默认规则是”index, follow”。”使用 robots 元标记”中有关于”robots”元标记的更多信息。作为一个说明,你现在也可以在你的页面首部通过”X-Robots-标签”HTTP 头指令来指定这一信息。这特别有用,尤其是当你想微调抓取和索引诸如 PDF、图片或其他类型的非 HTML 文件时。

<meta name=”google” value=”notranslate”>当我们认识到一个页面的内容并不是用用户可能想读的语言所写时,我们往往在搜索结果中提供一个链接以自动翻译你的网页。一般来说,这让你有机会提供独特和令人折服的内容给一个更广大的用户群。不过,在特定情况下,你可能不想你的网页被翻译。用这个元标记,你可以表明你不想让谷歌提供一个翻译此页的链接。这个元标记一般不影响该页为任何特定语言的排名。更多的信息请参阅”谷歌翻译常见问题解答“。

<meta name=”verify-v1″ content=”…”>这是一个谷歌网站管理员工具的特定元标记,它是被用在你网站的高层页面,以在网站管理员中核实一个网站的所有者(另一种核实方法是上传一个HTML文件)。你为这个标记所设置的 “content=”的值是由你的网站管理员工具帐户提供的。请注意,这一元标记的 content 值(包括大小写)必须和你的帐户提供给你的值完全一样,这和你是否从 XHTML 改变标记为 HTML 无关,也和你标签的格式是否与你的网页相符无关。详情请见” 如何通过向网站主页中添加元标记来验证网站?”

<meta http-equiv=”Content-Type” content=”…; charset=…”>这个元标记定义该页的内容类型和字符集。使用这个元标记时,content 属性的值必须放在引号中;否则字符属性可能被错误理解。如果你决定 使用这个元标记,不用说,你应该确保你的内容实际上用的是指定的字符集。”谷歌的网络作者统计“里有一些关于这个元标记的使用的有趣数据。

<meta http-equiv=”refresh” content=”…;url=…”>这个元标记在一定的时间后将用户指引到一个新的 URL,有时它被用来作为一种简单的重定向形式。不是所有浏览器都支持这种重定向。它也可能混淆用户。对显示在搜索引擎结果中的某一页面,如果你需要改变它的 URL,我们建议您使用服务器端的 301 重定向。此外,W3C 的”网页内容易读性技巧和故障指南 2.0“把它列在应该被废弃的标记中。

(X)HTML 和大小写
谷歌既能阅读 HTML 式的元标记,也能阅读 XHTML 式的元标记(无论网页用的是哪种编码)。此外,元标记的大小写一般并不重要–我们把<TITLE> and <title>看作是同样的。但是,”verify-v1″元标记是一个例外,它是区分大小写的。

revisit-after 网站地图的 lastmod 和 changefreq 标记
偶尔,网络管理员不必要地包含了”revisit-after”标记以加快一个搜索引擎的爬行速度,不幸的是,这个元标记大多数情况下是被忽略的。如果你想 让搜索引擎知道你更改页面的信息,你可以提交一个 XML 格式的网站地图。在该文件中,你可以说明你网站的最后修改日期(lastmod)和 URL 页面的改变频率(changefreq)。

如果您想要更多的例子,或有对如上所述的元标记有任何疑问,请到我们的谷歌网站管理员讨论组参与讨论。

Gmail出问题了:用IE7无法看到登录界面

  今天,许多Vista系统的用户用最新的IE7登录Gmail邮件帐户时遇到了一个棘手的问题。他们在IE7中登录Gmail页面时,竟然不是往日熟悉的登录窗口,取而代之的是一个空白页面,而且无论你怎么刷新都无济于事。  不过很及时,一位网名叫“rustybrick”的网友称,Gmail指导中心首先公开了这一问题,并给了用户一些必要的临时解决办法。Gmail指导中心说,目前Gmail正在升级系统,工程师已确认了这一问题正全力以赴以修复这一问题。在修复之前,用户可以采用以下几种方式解决这一问题:

  1. 使用IE7登录新版本的Gmail:http://mail.google.com/mail?hist=0

  2. 设置IE7关闭时自动清空缓存。

  3. 使用IE7登录经典版本的Gmail:http://mail.google.com/mail/?ui=1

  4. 使用其他浏览器如Firefox登录Gmail帐户。

  不过,这一升级带来的问题仅影响使用IE7的用户,其他用户仍然能正常登录邮件系统。

备份Google帐户

原文(英文):Creating a Backup for Your Google Account
中文翻译:为您的Google帐户创建一个备份

所有Google服务使用一个单一账户有一个很大的优越性,但是,如果因为某些原因,你不能进入该帐户或Google暂时停用它,你就会失去很多重要数据。幸运的是,你可以从你的帐户成立一个Google账户,这应该会给你获得的一些资料。 (你也应该备份重要的数据以其他方式:下载Gmail邮件使用的电子邮件,在邮件客户端,出口将您的文件,从Google的文档,备份您的博客博客等)

*如果你使用Gmail时,你可以创建一个Gmail帐户,他们的唯一目的是为了获取信息,从你的主要账户。设立邮件fetcher在备份帐户,并添加主要账户作为一个习俗,从地址。这样,你就可以阅读所有的邮件,从你的账户,甚至发送电子邮件。

*增加了备份帐户作为一个Google Talk的朋友,从Gmail的聊天室或其它Google Talk界面。作为一种副作用,你将有机会向您的共享项目从Google阅读器。

*对于Blogger ,这增加了备份帐户,在博客作者条: “设置>权限> “添加作者。该帐户应具有系统管理权限,使您可以创建,编辑和删除职务。

*在Google Analytics功能,去访问管理器,并添加帐户管理员。您将有机会访问所有报告和档案备份帐户。

* Google日历,让您分享的主要日程与其他人,甚至给他们有权编辑活动。点击”管理日历” ,在窗口底部的份额主要行事历和新增备份帐户。您应选择” ,使转变和管理共享” ,从下拉式。

*如果你是一组Google groups的所有者,去会员邀请中,选择”添加成员直接” ,并增加了备份帐户。然后改变会员类型的新帐户,以”所有者” 。这也是一个好主意,选择”无电子邮件” ,在认购型。

*增加了备份帐户作为合作者,为一些最重要的Google的文件和笔记本。

*其他Google服务只允许你出口你的数据: Google的阅读器(设置> “输入/输出) ,网上论坛(分享各自统计表与备份帐户) , Gmail的联系人, Google新闻的个性化(滚动至底部的网页并点击”分享你的个性化的新闻与一位朋友” ) 。

备份帐户不会有全部数据从你的主帐户,但你仍然能够阅读您的邮件,发送邮件,邮政博客岗位,检查你的日历,增加新的活动,获取重要文件等。

Adsense推介不带中国玩了

1. 几个小时前Google Adsense Blog刚刚放出消息,“Google Adsense下线推介”将在中国地区停止,在一月底开始只保存在北美、拉丁美洲和日本的站长,其它地区的站长在2008年2月开始将不能再做AdSense下线推介。
官方说辞:
If you’re in North America, Latin America, or Japan, the pricing structure for AdSense referrals is changing.
If you’re outside of North America, Latin America, and Japan, AdSense referrals will be retired.

2. 请站长提前做好准备,不要再在Adsense推介上花精力了。
官方说辞:
Soon, you’ll no longer see the option to create a referral button for AdSense in your account, although existing buttons will display as normal.

删除了评论链接中的nofollow

注意:本文已经过期,为了防止spam 目前已经停用了dofollow。

本站删除了评论链接中的nofollow,对于旧的评论已经没有了nofollow!

当新评论发布时可能还会有该属性,但这个属性将在评论发布一段时候后移除(5天)。

nofollowgoogle 几年前提出的一个新属性,目的是减少垃圾留言。此标签相当于告诉搜索引擎,“该链接所指向的网页非我所能控制,对其内容不予置评”,或者简单地说,该链接不是对目标网站或网页的“投票”。这样,搜索引擎在计算目标的网站的Link Popularity时,将会把这个链接排除在外。

目前主流的 Blog 程序,如 WordPressMovableType,均默认为其留言与 trackback 中的链接自动添加 nofollow 属性。

本站为什么去除nofollow

  1. nofollow 属性是为了减少垃圾留言而诞生,但是许多人认为 nofollow 并没有真正解决 Blog 的垃圾留言问题。因为现在的垃圾留言都是机器人生成的,它们不会因为你加了 nofollow 而忽视你

2. 为了评论者,引用者,为了自己。nofollow=不相信。对于留言中的 nofollow 来说,读者帮助你建设了 Blog,你却对搜索引擎说,“我不相信这个读者的评论”,这对评论者不公。对于 Trackback 中的 nofollow 来说,别人在自己的文章中链接了你,给你的链接是没有 nofollow 的,你却回敬人家一个 nofollow,这对引用者不公。而且去掉了 nofollow,会让读者更踊跃的来你的博客中评论、留言,增加了博客的人气。

小心:中国黑客利用贝·布托死讯传毒

 巴基斯坦前总理贝·布托夫人被刺杀不到12个小时,黑客即开始利用这一热点事件进行病毒传播。瑞星公司例行的网络监测发现,用Google引擎搜索”Benazir Bhutto”,排行第三的某英文网站已经证实被植入两个病毒,分别名”Hack.Explolt.Script.JS.Realplayer.b”和”Trojan.DL.Script.JS.Agent.lmj”,用户浏览该网站后就会中毒,中毒电脑会从网上自动下载其它病毒,并且Google自身的安全检测系统没有显示病毒警示信息。

  据瑞星反病毒专家介绍,该网站利用了前不久公布的Realplayer媒体播放器的漏洞,很多用户还没来得及打好相应的补丁。由于布托夫人遇刺已经成为全球关注的焦点,很多用户将通过Google等搜索引擎搜索观看相关资讯,预计将有大量的用户因此染毒。据了解,带毒网站在雅虎等引擎的排名也非常高。

  据专家分析,由病毒的编写手法、来源网站、木马植入方式、病毒的危害对象等来看,此带毒网站可能与中国黑客有关。但是,由于在搜索引擎上搜索布托夫人英文名字的主要是国外人士,并且该网站在百度等国内搜索引擎的排名并不高,因此对中国用户的危害相应较弱。专家还没有更多的证据,无法知道此网站是被黑客攻击而植入病毒,还是纯粹由黑客设立的钓鱼网站。

  利用政治事件、娱乐热点传播病毒,已经成为国内黑客惯常使用的手法,对于此类病毒的防御措施,瑞星反病毒专家介绍说,用户应该安装并及时升级自己的杀毒软件,上网的时候开启即时监控功能,并尽量利用瑞星2008版集成的主动防御功能加固自己的电脑系统。

如果没有“NoFollow”

自从2005年Google率先引入对链接的“nofollow”属性(“rel=’nofollow’”)的支持以来,对其各种各样质疑的声音便未间断过,其中,以SEO(搜索引擎优化)界为甚,毕竟,“nofollow”属性剥去了链接的价值,对建构于链接的SEO影响最大。

近来,关于移除blog如WordPress默认在留言链接使用“nofollow”属性设置的讨论成为了热点,许多人认为,为了体现对留言者劳动的尊重并回馈留言者,应当将留言链接中的“nofollow”属性移除,从而,刺激留言者在blog中参与讨论的积极性,客观地看,这种说法不无道理。甚至,还有更进一步者,有人认为通过这样,可以让用户真正地参与到blog建设中来,实现blog向Web 2.0的转化  ——老实说,究竟什么是Web 2.0,本人一直搞不太清楚,但与其相信通过刺激用户留言便能构成“用户贡献内容”的Web 2.0模式,我宁可相信博客学堂所认为的移除“nofollow”属性只会让博客变成老式论坛的结论,当然,这是题外话了。

对“nofollow”的质疑,比较有代表性的便是Loren Baker在13 Reasons Why nofollow Tags Suck中所归纳的链接“nofollow”属性的十三条罪状,其主要观点包括:

  • “nofollow”属性并没有起到当初预期中有效地抑制blog spam的效果;
  • 如果blog人工审核留言的话,那么,便完全没有必须必要在留言链接中使用“nofollow”属性;
  • 留言是对blog内容的有益补充与完善,因此,有得便理应有所付出,应当给予事实上在帮助自己建设blog的留言者真正的链接以回报;

是不是很有道理?

毋庸置疑,“nofollow”属性在对付blog spam方面显得力不从心,远不是一个理想的解决方案,但是,至少在现阶段,是不是存在比“nofollow”更有效、更好的办法?移除blog留言链接中的“nofollow”属性或者干脆取消“nofollow”属性,真的能带来blog与留言者的双赢?

恐怕情况并不那么简单。让我们来简单地分析一下如果blog留言链接中没有“nofollow”属性,情况将会怎样:

Blog需投入更多的时间与精力检查链接

在blog留言链接中使用“nofollow”属性,对blog建设者或管理者而言最大的好处在于,即使审核留言,也只需审核留言本身是不是与文章真正相关,是不是针对内容进行讨论,而不必对留言中的链接投入过多的关注:即便其中存在不当的链接、无关的链接甚至404死链接,在“nofollow”的保护下,不必担心会给自己的blog带来伤害。

但如果没有了“nofollow”,blog管理者则必须在链接管理方面投入更多的精力,如果希望自己的blog不受伤害,则至少应避免出现如下的链接:

  • 不当网站如色情、赌博网站的链接;
  • 被搜索引擎判定为链接工厂的链接;
  • 404错误链接,这可能是最令人头痛的,即使在留言发布时该链接没有问题,但如何保证该链接在日后仍能有效?莫非需要定期每周或至少每月检查网站的死链接数量?毕竟,网站出现大量的404链接是SEO的大忌;

而如果blog希望能在SEO方面有所作为的话,要考虑的因素会更多,比如说以Google为代表的主流搜索引擎大都在算法中结合网站内容、出入站链接来定位网站所处的行业、领域乃至网站在所处行业中的位置,那么,当blog中存在大量的无关链接——这应该是不可避免的——时如何让搜索引擎正确了解自己并建立信任是一个至关重要的大问题。

搜索引擎调整算法,降权blog链接的价值

对搜索引擎而言,要保证搜索质量,返回最相关的搜索结果,其必须首先能够保证最大限度地排除spam对其算法的影响。从这个角度看,Google引入“nofollow”并不是要对抗或消除日益猖獗的blog spam大潮,而是希望在其排名算法中引入一道将blog spam拒之门外的防线,换言之,对Google而言,只要blog spam不能影响其搜索结果便达到推出“nofollow”的目的,至于是不是消灭了blog spam,倒还在其次,甚至用点“无赖”的话说,那与Google无关。如果这样看,“nofollow”属性似乎并不是那么“失败”!

那么,如果没有了“nofollow”呢?搜索引擎为了避免、减小或降低blog spam对搜索结果的影响,似乎只能对blog留言中的链接降权处理,甚至对整个blog内的链接降权——危言耸听么?很难说——直接的结果便是所预期的“回报留言者”的设想落空。对blog而言,存在大量的无关或不当链接还有一个是否会受到搜索引擎惩罚的问题。

必然结果便是非但不能达到blog与留言者的双赢,而是双输!

作者: highdiy
原载: 点石互动搜索引擎优化博客

AdSense支持在新窗口中打开广告

Google AdSense 首先面向中国发布商发布了一项非常重要的功能 – 在新窗口中打开广告。这是继”允许的网站”之后,AdSense 根据中国发布商的需求以及中国用户的用户体验,对 AdSense 广告联盟产品作出的又一项重大改进。  用户在发布商的网站上点击广告后,广告网页将在一个新的浏览器窗口中呈现。这样,用户不必使用浏览器”后退”按钮才能返回到发布商的网站继续浏览,也能够避免用户意外离开网站造成该网站的用户流失;同时,这一功能也为用户浏览网站以及广告网页带来了方便。

  Google AdSense 广告联盟一贯重视中国市场以及中国发布商的需求,希望通过对产品的不断改进,为用户带来更好的体验,为广告主带来更好的投入回报,也为发布商带来更大的收益。实现用户、广告主以及发布商与 Google的四方共赢!

nofollow标签的使用

bestroi建议说一下nofollow,所以把以前写的一篇转过来。
nofollow是一年多前(好象)由Google领头新创的一个标签属性,目的是尽量减少垃圾链接对搜索引擎的影响。

Matt Cutts说过,这个标签的意义是告诉搜索引擎这个链接不是经过作者自己编辑的,所以这个链接不是一个信任票。搜索引擎看到这个标签就可能减少或完全取消链接的投票权重。
这个标签通常是用在博客的评论或论坛帖子中,因为这些地方是最多垃圾链接出现的地方。现在主流的博客和论坛软件都自动在评论和帖子的链接中加上了这个标签。
另外一个作用是,如果你在网站上卖广告,可以使用这个标签。因为买卖网页广告的初衷应该是流量,而不是PR值或试图影响搜索引擎排名。加上这个标签完全不会影响流量,但是有可能减少对搜索引擎排名的影响。
那么加了这个标签会把链接投票权重和PR传递值降为零吗?这一点是存有一些疑问的。如果我记的不错的话,Google,Yahoo,MSN表示支持这个标签。但是他们真的把这些链接的投票权重降为零吗?并没有肯定。
可以肯定的是,nofollow+博客评论或论坛帖子,这样的链接的投票权重可以忽略。
其他搜索引擎不一定支持这个标签,比如百度。就我观察的情况看,百度很可能不考虑这个标签,因为垃圾链接在百度还是很起作用的。
除了博客或论坛,在使用nofollow时要小心。想象一下,如果一个网站的导出链接都使用了nofollow标签,这显得自然吗?你向读者介绍一些网站,却告诉搜索引擎你不推荐这些网站?不可疑吗?受伤害的是其他人的网站,还是使用这个标签的网站呢?
以前也说过,害怕链接到其他网站是很多站长的一个误区,实际上链接到其他相关网站在很多时候会帮助你本身网站的排名。
但在博客评论和论坛帖子里面的链接就不一样了,这些链接是用户和读者自己加的,而不是网站拥有人或作者加的。在很多情况下,作者也不会去看这些链接去了什么网站。所以对这些网站的质量当然是不知道,并且不应该背书的。
读者如果有感而发,欢迎留评论,也欢迎留下签名链接。但是如果是想留个链接而留评论,那就不必了,不会有什么作用。
作者: Zac 原载: 点石互动搜索引擎优化博客

各大网站域名服务器测评

1、 Sina.com.cn

http://www.dnsstuff.com/tools/dnsreport.ch?domain=sina.com.cn

Parent

INFO NS records at parent serversYour NS records at the parent servers are: ns2.sina.com.cn. [61.172.201.254 ] [TTL=21600] [CN]
ns3.sina.com.cn . [202.108.44.55] [TTL=21600] [CN]
ns1.sina.com.cn. [202.106.184.166] [TTL=21600] [CN]
[These were obtained from cns.cernet.net]

NS INFO Nameservers versions Your nameservers have the following versions: 61.172.201.254: No version info available (refused).
202.108.44.55: No version info available (refused).
202.106.184.166: No version info available (refused).

SOA

WARN SOA Serial NumberWARNING: Your SOA serial number is: 5. That is OK, but the recommended format (per RFC1912 2.2) is YYYYMMDDnn, where ‘nn’ is the revision. For example, if you are making the 3rd change on 02 May 2006, you would use 2006050203. This number must be incremented every time you make a DNS change.

WARN SOA MINIMUM TTL valueWARNING: Your SOA MINIMUM TTL is : 600 seconds. This seems low (unless you are just about to update your DNS). You should consider increasing this value to somewhere between 3600 and 10800. RFC2308 suggests a value of 1-3 hours. This value used to determine the default (technically, minimum) TTL (time-to-live) for DNS entries, but now is used for negative caching.

规范等级:中

Sina.com

http://www.dnsstuff.com/tools/dnsreport.ch?domain=sina.com

Parent

INFO NS records at parent serversYour NS records at the parent servers are: ns1.sina.com.cn. [ 202.106.184.166 (NO GLUE)] [CN]
ns2.sina.com.cn. [61.172.201.254 (NO GLUE)] [CN]
ns3.sina.com.cn. [202.108.44.55 (NO GLUE)] [CN]
[These were obtained from l.gtld-servers.net]

WARN Glue at parent nameservers

WARNING. The parent servers (I checked with l.gtld-servers.net.) are not providing glue for all your nameservers. This means that they are supplying the NS records ( host.example.com), but not supplying the A records (192.0.2.53), which can cause slightly slower connections, and may cause incompatibilities with some non-RFC-compliant programs. This is perfectly acceptable behavior per the RFCs. This will usually occur if your DNS servers are not in the same TLD as your domain (for example, a DNS server of ” ns1.example.org” for the domain “example.com“). In this case, you can speed up the connections slightly by having NS records that are in the same TLD as your domain.

NS

WARN Nameservers on separate class C’s

WARNING: We cannot test to see if your nameservers are all on the same Class C (technically, /24) range, because the root servers are not sending glue. We plan to add such a test later, but today you will have to manually check to make sure that they are on separate Class C ranges. Your nameservers should be at geographically dispersed locations. You should not have all of your nameservers at the same location. RFC2182 3.1 goes into more detail about secondary nameserver location.

INFO Nameservers versionsYour nameservers have the following versions: 202.106.184.166: No version info available (refused).
61.172.201.254 : No version info available (refused).
202.108.44.55: No version info available (refused).

WARN Nameservers on separate class C’s

WARNING: We cannot test to see if your nameservers are all on the same Class C (technically, /24) range, because the root servers are not sending glue. We plan to add such a test later, but today you will have to manually check to make sure that they are on separate Class C ranges. Your nameservers should be at geographically dispersed locations. You should not have all of your nameservers at the same location. RFC2182 3.1 goes into more detail about secondary nameserver location.

SOA WARN SOA MNAME Check

WARNING: Your SOA (Start of Authority) record states that your master (primary) name server is: sina.com. . However, that server is not listed at the parent servers as one of your NS records! This is probably legal, but you should be sure that you know what you are doing.

WARN SOA REFRESH value

WARNING: Your SOA REFRESH interval is : 900 seconds. This seems low. You should consider increasing this value to about 3600-7200 seconds. RFC1912 2.2 recommends a value between 1200 to 43200 seconds (20 minutes to 12 hours). A value that is too low will unncessarily increase Internet traffic.

WARN SOA MINIMUM TTL value

WARNING: Your SOA MINIMUM TTL is : 300 seconds. This seems low (unless you are just about to update your DNS). You should consider increasing this value to somewhere between 3600 and 10800. RFC2308 suggests a value of 1-3 hours. This value used to determine the default (technically, minimum) TTL (time-to-live) for DNS entries, but now is used for negative caching.

规范等级:低

2、 sohu.com

http://www.dnsstuff.com/tools/dnsreport.ch?domain=sohu.com

Parent

INFONS records at parent serversYour NS records at the parent servers are:dns.sohu.com. [61.135.131.86] [TTL=172800] [CN]
ns1.sohu.com. [61.135.131.1] [TTL=172800] [CN]
ns3.sohu.com. [220.181.26.168] [TTL=172800] [CN]
[These were obtained from a.gtld-servers.net]

NS

WARN Single Point of Failure

WARNING: Although you have at least 2 NS records, and they appear to point to different physical servers, it appears that they block the ICMP packets used as part of our test, which means that they may share the same firewall. If they share the same firewall, this results in a single point of failure, which could cause all your DNS servers to be unreachable.

INFO Nameservers versionsYour nameservers have the following versions:61.135.131.86: ” ”
61.135.131.1: ” ”
220.181.26.168: ” ”

SOA

FAILSOA MINIMUM TTL value

WARNING: Your SOA MINIMUM TTL is : 60 seconds. This seems very low (unless you are just about to update your DNS). You should consider increasing this value to somewhere between 3600 and 10800. RFC2308 suggests a value of 1-3 hours. This value used to determine the default (technically, minimum) TTL (time-to-live) for DNS entries, but now is used for negative caching.

规范等级:高

3163.com

http://www.dnsstuff.com/tools/dnsreport.ch?domain=163.com

Parent

INFO NS records at parent serversYour NS records at the parent servers are:ns.nease.net. [202.106.185.75] [TTL=172800] [CN]
ns3.nease.net. [220.181.28.3] [TTL=172800] [CN]
[These were obtained from a.gtld-servers.net ]

NS

INFO Nameservers versions Your nameservers have the following versions: 202.106.185.75: “9.2.3”
220.181.28.3: “9.2.3”

SOA

FAILNS agreement on SOA Serial #

ERROR: Your nameservers disagree as to which version of your DNS is the latest (20011937 versus 20011938). This is OK if you have just made a change recently, and your secondary DNS servers haven’t yet received the new information from the master. I will continue the report, assuming that 20011938 is the correct serial #. The serial numbers reported by each DNS server are:
202.106.185.75: 20011938
220.181.28.3: 20011937

WARN SOA Serial Number

WARNING: Your SOA serial number is: 20011938. That is OK, but the recommended format (per RFC1912 2.2) is YYYYMMDDnn, where ‘nn’ is the revision. For example, if you are making the 3rd change on 02 May 2006, you would use 2006050203. This number must be incremented every time you make a DNS change.

规范等级:中

nease.net

http://www.dnsstuff.com/tools/dnsreport.ch?domain=nease.net

Parent

INFO NS records at parent serversYour NS records at the parent servers are: ns.nease.net. [202.106.185.75] [TTL=172800] [CN]
ns3.nease.net. [220.181.28.3] [TTL=172800] [CN]
[These were obtained from j.gtld-servers.net]

NS

INFO Nameservers versions Your nameservers have the following versions: 202.106.185.75: “9.2.3”
220.181.28.3: “9.2.3”

SOA

WARN SOA Serial Number

WARNING: Your SOA serial number is: 991160. That is OK, but the recommended format (per RFC1912 2.2) is YYYYMMDDnn, where ‘nn’ is the revision. For example, if you are making the 3rd change on 02 May 2006, you would use 2006050203. This number must be incremented every time you make a DNS change.

WARN SOA EXPIRE value

WARNING: Your SOA EXPIRE time is : 3600000 seconds. This seems a bit high. You should consider decreasing this value to about 1209600 to 2419200 seconds (2 to 4 weeks). RFC1912 suggests 2-4 weeks. This is how long a secondary/slave nameserver will wait before considering its DNS data stale if it can’t reach the primary nameserver.

规范等级:中

4、 tom.com

http://www.dnsstuff.com/tools/dnsreport.ch?domain=tom.com

Parent

INFO NS records at parent serversYour NS records at the parent servers are: brown.hutchcity.com. [202.45.84.67] [TTL=172800] [HK]
edns.wyith.net. [202.181.240.44] [TTL=172800] [HK]
ns1.tom.com. [61.135.159.46] [TTL=172800] [CN]
ns2.tom.com. [61.135.159.47] [TTL=172800] [CN]
[These were obtained from f.gtld-servers.net ]

NS

FAILOpen DNS servers

ERROR: One or more of your nameservers reports that it is an open DNS server. This usually means that anyone in the world can query it for domains it is not authoritative for (it is possible that the DNS server advertises that it does recursive lookups when it does not, but that shouldn’t happen). This can cause an excessive load on your DNS server. Also, it is strongly discouraged to have a DNS server be both authoritative for your domain and be recursive (even if it is not open), due to the potential for cache poisoning (with no recursion, there is no cache, and it is impossible to poison it). Also, the bad guys could use your DNS server as part of an attack, by forging their IP address. Problem record(s) are: Server 202.45.84.67 reports that it will do recursive lookups. [ test] Server 202.181.240.44 reports that it will do recursive lookups. [ test] Server 61.135.159.46 reports that it will do recursive lookups. [ test] Server 61.135.159.47 reports that it will do recursive lookups. [test] See this page for info on closing open DNS servers.

FAIL Lame nameservers

ERROR: You have one or more lame nameservers. These are nameservers that do NOT answer authoritatively for your domain. This is bad; for example, these nameservers may never get updated. The following nameservers are lame:
202.45.84.67

FAIL Missing nameservers 2

ERROR: One or more of the nameservers listed at the parent servers are not listed as NS records at your nameservers. The problem NS records are:
brown.hutchcity.com.
edns.wyith.net.

WARN All nameservers report identical NS records

WARNING: Your nameservers report somewhat different answers for your NS records (varying TTL, for example).

INFO Nameservers versions Your nameservers have the following versions: 202.45.84.67: “8.3.4-REL”
202.181.240.44: “4.9.6-REL”

61.135.159.46: “TOM.COM DNS Server 2.00″
61.135.159.47 : “TOM.COM DNS Server 2.00″

规范等级:低

5qq.com

http://www.dnsstuff.com/tools/dnsreport.ch?domain=qq.com

Parent

INFO NS records at parent serversYour NS records at the parent servers are:dns1.imok.net. [219.133.40.202] [TTL=172800] [CN]
dns2.imok.net. [61.152.100.5] [TTL=172800] [CN]
[These were obtained from e.gtld-servers.net ]

NS

WARN Single Point of Failure

WARNING: Although you have at least 2 NS records, there is a chance that they may both point to the same server (one of our two tests shows them being different, the other is unsure; it appears that there are one or more firewall(s) that intercept and alter DNS packets (some versions of Linux reportedly have a built-in firewall that does this, too)), which would result in a single point of failure. You are required to have at least 2 nameservers per RFC 1035 section 2.2.

INFO Nameservers versions Your nameservers have the following versions: 219.133.40.202: “9.3.2”
61.152.100.5: “9.3.0rc4”

SOA

WARN SOA MNAME Check

WARNING: Your SOA (Start of Authority) record states that your master (primary) name server is: qq.com.. However, that server is not listed at the parent servers as one of your NS records! This is probably legal, but you should be sure that you know what you are doing.

WARN SOA REFRESH value

WARNING: Your SOA REFRESH interval is : 300 seconds. This seems low. You should consider increasing this value to about 3600-7200 seconds. RFC1912 2.2 recommends a value between 1200 to 43200 seconds (20 minutes to 12 hours). A value that is too low will unncessarily increase Internet traffic.

WARN SOA EXPIRE value

WARNING: Your SOA EXPIRE time is : 86400 seconds. This seems a bit low. You should consider increasing this value to about 1209600 to 2419200 seconds (2 to 4 weeks). RFC1912 suggests 2-4 weeks. This is how long a secondary/slave nameserver will wait before considering its DNS data stale if it can’t reach the primary nameserver.

规范等级:低

Imok.net

http://www.dnsstuff.com/tools/dnsreport.ch?domain=imok.net

Parent

INFO NS records at parent serversYour NS records at the parent servers are:dns1.imok.net. [219.133.40.202] [TTL=172800] [CN]
dns2.imok.net. [61.152.100.5] [TTL=172800] [CN]
[These were obtained from j.gtld-servers.net ]

NS

WARN Single Point of Failure

WARNING: Although you have at least 2 NS records, there is a chance that they may both point to the same server (one of our two tests shows them being different, the other is unsure; it appears that there are one or more firewall(s) that intercept and alter DNS packets (some versions of Linux reportedly have a built-in firewall that does this, too)), which would result in a single point of failure. You are required to have at least 2 nameservers per RFC 1035 section 2.2.

INFO Nameservers versions Your nameservers have the following versions: 219.133.40.202: “9.3.2”
61.152.100.5: “9.3.0rc4”

SOA

WARN SOA MNAME Check

WARNING: Your SOA (Start of Authority) record states that your master (primary) name server is: imok.net. . However, that server is not listed at the parent servers as one of your NS records! This is probably legal, but you should be sure that you know what you are doing.

WARN SOA REFRESH value

WARNING: Your SOA REFRESH interval is : 360 seconds. This seems low. You should consider increasing this value to about 3600-7200 seconds. RFC1912 2.2 recommends a value between 1200 to 43200 seconds (20 minutes to 12 hours). A value that is too low will unncessarily increase Internet traffic.

WARN SOA EXPIRE value

WARNING: Your SOA EXPIRE time is : 3600000 seconds. This seems a bit high. You should consider decreasing this value to about 1209600 to 2419200 seconds (2 to 4 weeks). RFC1912 suggests 2-4 weeks. This is how long a secondary/slave nameserver will wait before considering its DNS data stale if it can’t reach the primary nameserver.

规范等级:低

6、 baidu.com

http://www.dnsstuff.com/tools/dnsreport.ch?domain=baidu.com

Parent

INFONS records at parent serversYour NS records at the parent servers are:dns.baidu.com. [202.108.250.228] [TTL=172800] [CN]
ns2.baidu.com. [202.108.249.147] [TTL=172800] [CN]
ns3.baidu.com. [220.181.27.61] [TTL=172800] [CN]
ns4.baidu.com. [220.181.27.62] [TTL=172800] [CN]
[These were obtained from m.gtld-servers.net]

NS

FAIL Missing (stealth) nameservers

FAIL: You have one or more missing (stealth) nameservers. The following nameserver(s) are listed (at your nameservers) as nameservers for your domain, but are not listed at the parent nameservers (therefore, they may or may not get used, depending on whether your DNS servers return them in the authority section for other requests, per RFC2181 5.4.1). You need to make sure that these stealth nameservers are working; if they are not responding, you may have serious problems! The DNS Report will not query these servers, so you need to be very careful that they are working properly. ns1.baidu.com.
This is listed as an ERROR because there are some cases where nasty problems can occur (if the TTLs vary from the NS records at the root servers and the NS records point to your own domain, for example).

WARN TCP Allowed

WARNING: One or more of your DNS servers does not accept TCP connections. Although rarely used, TCP connections are occasionally used instead of UDP connections. When firewalls block the TCP DNS connections, it can cause hard-to-diagnose problems. The problem servers are: 202.108.249.147: Error [No response to TCP packets].

220.181.27.61: Error [No response to TCP packets]. 220.181.27.62: Error [No response to TCP packets].

WARN Single Point of Failure

WARNING: Although you have at least 2 NS records, there is a chance that they may both point to the same server (one of our two tests shows them being different, the other is unsure; it appears that there are one or more firewall(s) that intercept and alter DNS packets (some versions of Linux reportedly have a built-in firewall that does this, too)), which would result in a single point of failure. You are required to have at least 2 nameservers per RFC 1035 section 2.2.

INFO Nameservers versions Your nameservers have the following versions: 202.108.250.228: “diy by bind”
202.108.249.147: “9.2.1 ”
220.181.27.61: “9.2.1”
220.181.27.62: “9.2.1”

FAIL Stealth NS record leakage

Your DNS servers leak stealth information in non-NS requests:
Stealth nameservers are leaked [ns1.baidu.com.]!
This can cause some serious problems (especially if there is a TTL discrepancy). If you must have stealth NS records (NS records listed at the authoritative DNS servers, but not the parent DNS servers), you should make sure that your DNS server does not leak the stealth NS records in response to other queries.

SOA

WARN SOA REFRESH value

WARNING: Your SOA REFRESH interval is : 300 seconds. This seems low. You should consider increasing this value to about 3600-7200 seconds. RFC1912 2.2 recommends a value between 1200 to 43200 seconds (20 minutes to 12 hours). A value that is too low will unncessarily increase Internet traffic.

WARN SOA EXPIRE value

WARNING: Your SOA EXPIRE time is : 2592000 seconds. This seems a bit high. You should consider decreasing this value to about 1209600 to 2419200 seconds (2 to 4 weeks). RFC1912 suggests 2-4 weeks. This is how long a secondary/slave nameserver will wait before considering its DNS data stale if it can’t reach the primary nameserver.

规范等级:中

7、 google.com

http://www.dnsstuff.com/tools/dnsreport.ch?domain=google.com

Parent

INFO NS records at parent servers Your NS records at the parent servers are: ns1.google.com. [216.239.32.10] [TTL=172800] [US]
ns2.google.com. [216.239.34.10 ] [TTL=172800] [US]
ns3.google.com. [ 216.239.36.10] [TTL=172800] [US]
ns4.google.com . [216.239.38.10] [TTL=172800] [US]
[These were obtained from k.gtld-servers.net]

NS

INFO Nameservers versions Your nameservers have the following versions: 216.239.32.10: No version info available (refused).
216.239.34.10: No version info available (refused).
216.239.36.10: No version info available (refused).
216.239.38.10: No version info available (refused).

SOA

FAILSOA MINIMUM TTL value

WARNING: Your SOA MINIMUM TTL is : 60 seconds. This seems very low (unless you are just about to update your DNS). You should consider increasing this value to somewhere between 3600 and 10800. RFC2308 suggests a value of 1-3 hours. This value used to determine the default (technically, minimum) TTL (time-to-live) for DNS entries, but now is used for negative caching.

规范等级:中

http://blog.pcstars.tk/2007/11/blog-post_09.html

10月份西联汇款取款指南

作者 廖溪 – AdSense 支持小组

各位 Google AdSense 发布商您好,如果10月份您选择的付款方式为西联汇款,现在开始您就可以去领取您的西联汇款的收入了!

领取西联汇款步骤如下:

1.登录您的 Google AdSense 账户,点击付款页面,如果显示10月份”付款已签发”的话,点击此链接边上的”付款细节”。

2.在付款细节页面,请您打印或抄录如下信息并随身携带:
* 您的付款监控码(MTCN),此号码为10位数号码。
* 您的详细的付款金额,详细到美分,如 123.45美元。
* 发汇人的详细信息:
发汇人: Google.Inc
发汇人地址:1600 Amphitheatre Parkway,Mountain View, CA 94043 , USA
3.随身携带您的有效身份证件,如身份证,驾照,护照。

4.首先选择离您最近的西联代理机构,您可以访问 http://www.payment-solutions.com/agent.asp ,请提交地址并从 “Product”(产品) 下拉框中选择 “Quick Cash”(快汇)。您随即会看到距您最近的西联代理机构清单。如果您没有找到的话,请致电西联汇款的免费服务热线 8008208668 进行咨询。

5.前往您最近的西联代理机构或分理处领取付款,如果您付款有任何问题的话,请致电西联汇款的免费服务热线 8008208668 寻求帮助,我们已经跟西联汇款中国部门提前联系相关事宜,相信他们可以给您提供帮助。

6.如果您的拼音收款人姓名不是我们介绍过的标准格式(如 Liao xi,Zhang xiaoming), 姓在前,名在后,姓名中间有空格,请 点击此处 申请更改您的拼音收款人姓名,请注意,您无需为使用西联汇款更改您的中文收款人姓名。

7.如果您在10月 25 日到 10 月 30 日之间更改过您的付款方式,您的付款很有可能以您更改后的方式发出,您可能要稍晚才会在账户中看到更新,感谢您的耐心等待。

对于此次付款给大家带来的不便,我们感到十分抱歉。我们会不断改进我们的付款流程,让您更快更方便地拿到付款。非常感谢各位发布商一直以来对我们的信任和支持。

Google Adsense定义下的成人内容

今天,Google Adsense的官方博客详细阐述了关于成人内容的定义规则,详细解释了哪些网站算是成人内容,是不能放Google Adsense广告的,如果包含成人内容的网站投放Adsense广告,那么Google会停止投放广告甚至停用发布商的账户。  根据Google AdSense的计划政策,发布商的网站内容“不得包含色情或成人内容”,因此,色情网站是不能投放Google Adsense广告的,根据Google这次的解释,成人内容实际指的是“少儿不宜内容”,也就是说不适合少儿观看的内容。其中包括:

1.色情内容以及有色情倾向文字描写的内容,如色情图片、视频、以及色情、成人小说等;

2.有成人或色情引导性的图片或视频,如“偷拍”“走光”“激情图片”等;

3.具有猥亵性或不健康倾向的内容,如“美腿丝袜”“高跟丝袜”等内容;

4.成人用品;

5.对于性教育方面的内容,只有完全教育性的内容才能投放广告,任何成人擦边性质的内容,如成人倾向的描写以及成人图片都属于少儿不宜内容;

6.网页上在投放成人广告,就不能同时投放 AdSense 广告。

实际上,中国目前不少门户网站就包含成人内容,比如某某门户网站的女性频道和社会新闻频道,打开后映入你眼帘的大多都是美女等等不健康的内容,Google对于成人内容的定义似乎执行的并不太好,我举个例子,中国的老牌流氓网站:中国电信互联星空会通过各种手段将用户输错地址后带入互联星空的网站,相信内容参见我以前的报道,这个网站就投放过AdSense广告,而我给出当时的截图来看,这样的内容显然已经符合Google Adsense关于“成人内容”的定义,不过中国电信似乎依然堂而皇之的挂着Google Adsense,实在令人不解。

G.cn

上 Google(谷歌)还有捷径?没错,今天,我们很兴奋地告诉大家谷歌最简网址 G.cn 上线。如果你愿意叫它”快捷键”也无妨。

再老资格的网民也有输入网址时键入”wwww”的时候,再忠诚的谷歌粉丝也难免激动中会生造出”gooogle”来,更何况那些对英语、对谷歌不那么熟悉的朋友,非逼着大家把 Google 这六个字母想记清楚打正确还真是不太”贴心”,是两个”o“还是三个”o”?是”g”在前还是”l”在前?

现在你再也不用全神贯注地输入 www.google.cn 这么长而且比较难记的 URL 了。只要在浏览器中输入 G.cn 就能登陆谷歌的主页,开始您的搜索之旅。这是我们为中国用户量身打造的谷歌捷径。想想看,这应该是世界上最短的域名之一了,也是谷歌自己最短的域名吧。