作者彙整: 星星

如果没有“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
原载: 点石互动搜索引擎优化博客

腾讯QQ屏蔽大部分CN域名

腾讯QQ目前已经在聊天对话中屏蔽了大部分CN域名的地址,只有少数一些CN域名得以幸免,具体的表现形式是:当QQ对话的一方输入的聊天信息包含以.cn为结尾的网站地址的时候,腾讯QQ会将整条信息忽略不予显示,对方QQ的屏幕将不显示任何信息。  据我的分析,腾讯QQ的这个行为可能是为了对付愈演愈烈的中文SPAM网站的不得已的措施,由于.cn域名一度以极其低廉的价格(1元价)疯狂倾销,导致不少黑帽SEO站长注册大量cn域名用于制造链接工厂,同时制造大量垃圾信息和垃圾网站。搜索引擎通常通过降权或去除的方式屏蔽这些垃圾网站,但是由于低廉的cn域名导致这样的行为成本极低,被搜索引擎封掉大批域名也不会造成什么损失,因此他们就使用注册的cn域名疯狂进行SPAM。垃圾站点通常使用作弊手法来误导搜索引擎或者网络用户使其错误地进入垃圾网站,很常见的形式是通过木马病毒或者其他方式在QQ聊天记录上增加尾巴信息,误导和欺骗用户进入某些垃圾网站,当这类信息越来越多的时候,最终导致腾讯QQ痛下杀手,直接屏蔽大部分包含.CN的域名。

  经过我的测试,www.vnet.cn(老流氓互联星空)、www.google.cn(谷歌)、www.net.cn(万网)等较为知名的CN网站以及单字母的cn域名(不带www的)都还可以显示,大部分com.cn的域名也可以显示,但是.cn的域名就大部分不能显示,有趣的是,腾讯连自家域名也不放过,www.qq.cn这个域名也是不能显示的。

  微软的MSN也做过类似的事情,国外搞垃圾网站通常也是注册廉价域名,MSN也将廉价注册的INFO域名(0.99美元价格)彻底屏蔽。

  更新:19日晚,腾讯QQ解除了对.cn域名的屏蔽。

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

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

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

Google网络存储容量可能高达50G

出处:cnbeta

  调研机构iSuppli近日表示,Google即将推出的免费网络存储空间容量可能高达50G.

  11月底有消息称,Google将推出网络存储服务,允许用户将本地计算机中的文件存储在Google的服务器上.该服务为免费提供,但如果付费,用户可获得更大的存储空间.

  对此,iSuppli高级分析师Krishna Chander认为,与希捷等硬盘制造商相比,提供虚拟硬盘服务的利润更加可观.

  对用户而言,该服务是十分实用的;对Google而言,也是极具诱惑力的.

  目前,雅虎和微软等科技也都提供了网络存储服务,但大部分无法满足企业个人的需求.而且,存储空间也只有5G左右.但Chander预计,Google将免费提供高达50G的存储空间.

  通过在存储服务网站上销售广告,Google即可大赚一笔.Chander预计,将有420万用户部署Google的在线存储服务.假设Google每年从每位用户身上获取50美元的广告营收,那么每年的营收就高达2.1亿美元.

  至于Google的成本,Chander表示,每GB的费用约为25美分.Google需要部署210,000TB的存储空间,其成本约为5250万美元.

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 就能登陆谷歌的主页,开始您的搜索之旅。这是我们为中国用户量身打造的谷歌捷径。想想看,这应该是世界上最短的域名之一了,也是谷歌自己最短的域名吧。

Gmail即将升级 部分第三方辅助工具将无法使用

Google公司的一名发言人对国外媒体表示,目前,Google公司的工程师正在对Gmail的JavaScript代码进行更新,更新之后的软件将会提供”更快和更灵活的服务”.
Gmail服务的工程师丹·普皮斯介绍说,Google公司将很快在美国英文版中进行Gmail的升级,几周之后,Google将会对其他语言的版本进行升级.
普皮斯在一篇博客文章中表示,在经过升级之后,Gmail可以提供许多在2004年发布是不敢想象的功能.他说:”在过去三年半时间里,我们已经推出了一些很酷的功能.在这期间,我们在开发大型网络应用软件方面学到了很多东西,知道了如何突破网络浏览器的限制.”
閱讀全文

FeedBurner开始集成AdSense

据FeedBurner官方博客报道,FeedBurner在11月31日的万圣节宣布,FeedBurner的广告已经整合了Google AdSense,大家可以在FeedBurner中展示自己的AdSense了。

这项新的集成将会在你的网站和博客中显示和内容相关的AdSense广告,不过需要注意到是,针对Feeds的AdSense选项此时并没有打开,如果你选择激活Adsense服务,那么你可以在你的Blog页面上显示300×250或468×60的文字或图片广告,当你已经安装了必要的代码后,该广告将出现在文章页面的第一项这中。

用户不一定必须是FeedBurner Ad Network成员也可以使用这项功能,使用的时候请务必遵守Google Adsense的计划政策,确保你的网站符合显示AdSense广告的条件。如果你已经是FeedBurner Ad Network成员,并且也配置了在你的网站上显示广告,那么AdSense广告将会在没有FeedBurner Ad Network广告的时候显示。

使用FeedBurner的AdSense的方法是,选择你的Feed,进入Monetize页签,然后输入你的AdSense帐号或者新建一个AdSense账号,然后在网页上加入FeedBurner的代码,就可以展示AdSense广告了。

中国的用户就不用配置了,因为FeedBurner的feeds子域名无法访问,因此这些广告代码加到你的网站上去也什么都无法显示,获得不了任何收入的,不过大家可以期待一下针对Feeds的广告,因为目前在线阅读器访问FeedBurner还是没有问题的。

发布商经验谈 – 三次优化让我的广告点击率从0.5%提高到3.0%

作者 冯英健 – AdSense 发布商

如果你已经是 Google AdSense 内容发布商,如果希望自己的网站获得更高的收入,非常有必要深入了解 Google 的优化建议。在 Google AdSense 的在线支持页面也提供了相当多的内容可以参考,这里根据我自己对个人网站 Google 广告进行优化的体会,给大家介绍一些个人建议,但愿对其他网站站长有所帮助。

我的个人网站从2004年10月底 Google AdSense 支持中文网站开始就申请成为 Google 内容发布商,不过在早期广告的点击率很低,通常只有0.5%左右,在1年多的时间内,经过三次简单的优化,目前的广告点记录平均达到3.0%,AdSense 点击广告的佣金收入也从最初每个月的30多美元增加到目前的2000美元以上(其中包括后来才提供的 Google 产品推介收入)。取得这样的效果当然也是因为网站的访问量在不断增长,不过网站广告的优化还是发挥了决定性的作用。

为什么我的网站广告点击率只有0.5%?

在我的网站开始投放 Google AdSense 内容关联广告的最初几个月内,我注意到广告的平均点击率大约0.5%,有些渠道甚至低至0.1%,起初对此并未多想,以为这种文字广告点击率不高是正常的现象。一个偶然的机会,看到一个介绍 Google AdSense 的成功案例中,广告的点击率是1.5%,这才第一次对自己网站的网站广告模式产生了“优化”的念头。

第一批投放的广告,实际上没有任何优化的意识,也没有对用户获取信息的行为进行分析,只是根据原来网页模板的布局,将合适的广告代码添加进去而已。第一次所做的优化也很简单,只是根据自定义的广告渠道统计数据,将点击率过低的广告去掉,如网页顶部468×60的广告单元、网页模版右侧160×600的摩天大楼广告单元等,同时将728×90的横幅广告放置到网页的主导航条下面。

经过这些改变之后,在很短的时间内,我的平均广告点击率也达到了1.2%,我当时曾经对这一效果相当满意。不过实际上这仍然不是最好的广告投放模式。

第二次优化:广告点击率提升到1.8%

在浏览一些国外网站时,发现其中的 AdSense 广告通常看起来没有边框,好像与正文“融合”在一起,而且广告文字、网址等字体颜色也可以自行定义。于是认真查看了 Google AdSense 设置中的最新功能,原来可以通过“调色板”来进一步优化广告的展示效果。我迫不及待地把所有广告都设置为无边框,并且使背景颜色与网页看起来更加协调。经过这次优化,广告点击率提升到1.8%,广告收入也达到每月400美元以上。

由于看到了 Google AdSense 佣金的增长,进一步提高了通过个人网站赚取广告佣金的兴趣,在这期间的网站运营中,我持续增加了大量原创内容,网站访问量也比一年前增加了一倍以上,这些原创内容也为日后获得更多的收入奠定了基础。

第三次优化:广告点击率达到3.0%

对于1.8%的点击率和每月400美元的收入,我认为这已经是相当不错的效果了,因为在当时,传统的BANNER广告点击率通常在0.5%以下,而对于当时日访问量仅有30000多PV的个人网站,如果通过其他广告联盟获得的月收入通常不到1000元人民币。

不过此后不久,Google 给我提供了更加详尽的 AdSense 优化建议,根据这些建议,我在网页正文内容的左上方放置了300×250的中等矩形广告,并且利用调色版采用了“融合”的方式,使得广告更受关注。另外,在网页顶部等改为图片格式的 Google 产品推介广告。通过这次调整,平均广告点击率达到3.0%,Google 产品推介广告点击率也达到1.0%以上,这样的综合效果使得网站的收入达到较好的水平(相对于同等规模的网站而言)。

通过自己将近3年的 AdSense 广告投放经验,可以简单归纳为两点:第一,要选择合适的广告格式和广告展示位置;第二,也是最重要的一点,提高 AdSense 广告佣金收入的根本是网站运营问题,是要用心运营自己的网站,以高质量的内容赢得用户。

百度将在美国欧洲推搜索服务 迎击Google雅虎

据外国媒体10月18日报道,中国最受欢迎的互联网搜索网站百度司宣布,它打算在美国和欧洲推出网络服务,以在国外市场迎击比它强大的竞争对手谷歌和雅虎公司。百度董事长兼CEO李彦宏今年在韩国首都首尔接受一个采访时说:”我们有全球化的志愿,最终我们会扩展到所有国家,这其中包括美国和欧洲市场。” 李彦宏在首尔正在出席一个经济论坛,他说:”我们需要为每个市场提供略微不同的产品。这就是我们一步步地从中国到日本再到其它国家的原因。“但是他表示向全球扩展业务时,并没有透露进程时间表。

百度凭借其在中国位于谷歌之上的领导地位,提高利润并且将股价推进到其2005年8月份上市时价位的11倍。李彦宏称百度打算今年底在日本推出它的日语搜索服务,这也是该公司第一次走出国门以获得国外市场。百度第二季度净利润与一年前同期比翻番至1.419亿元(1890万美元)。谷歌7月份公布的财报显示,其第二季度实现利润9.25亿美元。

  据市场研究公司Analysys International称,第二季度百度在中国搜索市场的市场份额为58%,而它的竞争对手谷歌只有23%。雅虎位列第三,其第二季度中国搜索市场份额为11.6%。百度定在10月25日纳斯达克闭市后公布其第三季度财报。

细说 AdSense 政策 – 什么是“版权材料”

作者 AdSense 政策专员 – AdSense 政策小组

在前面的“细说 AdSense 政策”系列中,我们陆续介绍了一些常见的政策问题。今天,我们再向大家介绍一下另一个非常常见的政策问题 – 版权材料问题。

顾名思义,“版权材料”就是指在未经版权所有者授权的情况下使用的材料,包括电影,电视剧,电视节目,音乐和歌曲(mp3,铃声,flash),漫画,书籍,软件等。

如果您网站上使用的这些材料有明确的版权所有人(公司或个人),而您在没有该版权所有人的正式授权(具有法律效力的授权书)的情况下使用这些材料,您的网站内容就属于版权材料,就违反了我们的计划政策。

需要强调的是,您网站上的版权声明(例如“本站所有内容均搜集与网络,如果侵犯了您的版权请立即通知我们,我们会立即删除”)是没有任何法律效力的。如果您没有版权所有人的授权,仍然是版权材料,仍然违反了我们的计划政策。

下面我们就举几个版权材料的具体例子:
1. 电影或电视在线观看或下载网站,如果没有出版公司的正式授权,这些内容就属于版权材料。
2. 音乐在线视听或下载网站,或使用歌曲做手机铃声下载的网站,如果没有出版公司的正式授权,就属于版权材料。
3. 漫画网站,如果使用的漫画有明确的版权所有人,并且没有版权所有人的正式授权,就属于版权材料。
4. 在线书籍或小说网站,如果该书籍或小说已经正式发表并有明确的版权所有人,如果没有版权所有人的授权,就属于版权材料。
5. 软件下载网站,如果软件有明确的版权所有人和发行公司,在未经版权所有人授权情况下提供的下载以及任何其他形式 – 如破解版、绿色版、汉化版等都属于版权材料。

另外,有些发布商来信说他的网站服务器上并没有这些材料,并不提供这些材料的直接下载,而只是提供下载链接,问算不算版权材料。我们的回答是:这样的网站内容仍然是版权材料,不符合我们的计划政策。我们不允许发布商直接或间接利用非法版权材料赚取 AdSense广告收益。

请注意,AdSense 所有的广告都不可以展示在版权材料的网站上,包括 AdSense for Content,AdSense for Search,移动广告和推介。同时,发布商也不可以在版权材料的网页上做导向放有广告或推介页面的链接、图片或flash,这同样是违反我们政策的。

如果我们发现含有大量版权材料的网站在投放 AdSense 广告,我们会停止广告的展示,并向发布商发出警告。对于严重违反政策的发布商,我们会停用账户,该发布商将再也不能参加 AdSense。

说这么多,就是希望让发布商对什么是版权材料有一个清楚的了解,帮助大家保证自己的网站符合我们的政策。我们希望广大发布商都能遵守我们的政策,同时,如果发现了违反政策的行为能及时通知我们,与我们一起维护 AdSense 网络的质量。非常感谢大家!

Google PR更新

早上起来一看Google Toolbar 上面的绿块,很多站的PR都已经刷新,这是很多SEOer期待已久的事情。

随便看了一些站,观察了一些5月份后增加的栏目和文章,PR由原来的0升到2-3不等,不过有点意外的是有几个8月份注册的域名PR也都上升到3了,也有部分由3降低至2,当然,本次更新来的比较突然,
仿佛就在一夜之间,关于还会不会有什么新的变化或者调整,我们继续关注中,赶快Check一下你的站点吧!

作者: 枫林&SEO博客

gmail已经支持IMAP

Gmail开始支持IMAP协议,相比起POP协议,其最大的优势在于可以减少许多重复的下载以及保持各个客户端间的同步,比如在基于IMAP协议的客户端上删除某封邮件后,Web Gmail中该邮件也会被删除

目前支持POP3的免费信箱很多,但是几乎找不到支持IMAP的免费信箱,这主要是因为IMAP的特性导致的,因为IMAP会占用比POP3更多的服务 器和带宽资源,务必导致服务器和带宽将要投入更多资源,因此目前IMAP几乎都是收费的服务,而Google得Gmail提供免费的IMAP之后,估计会 对目前收费IMAP邮件服务造成严重打击。

每个 Web 站点都必需的十余个文件

原文链接: http://www.ibm.com/developerworks/cn/web/wa-webfiles/index.html

David Mertz, Ph.D ([email protected]), Old Schooler, Gnosis Software, Inc.

2007 年 9 月 24 日

不管开发 Web 站点所用的是何种内容管理系统或 Web 应用程序框架,都应该涵盖一些基本要素。能提供精致的用户界面和丰富的内容固然很棒,但在那之前,首选应该提供用户能查找到并能明了地表达该站点用途 的基本文件。

引言

有几个标准的文件是每个 Web 站点都必需的,但在很多时候它们却会被站点忽略。大多数这种文件都与约定有关,而非技术上的要求,但如果不能提供这些文件,就会使站点创建误入歧途。除了 URL 可以通过猜想尝试得到,通常用户很难通过猜想找到其他想要的东西。本文将对这些标准文件逐一简述。

给定的资源究竟如何提供决定于所使用的 Web 服务器层和 Web 应用程序层。在诸如 Apache 这类 “传统” 的、接近静态的服务器内,这些资源很可能就是服务器上的文字文件。但在不同的配置中,它们也有可能是数据库中的某些条目、配置文件中的某些行、服务器进程中的某些类等。本文重点放在用户最终所见之上,而非该如何让其发生。

404.html

当用户使用您的 Web 站点,他们不可避免地都会找寻一些不存在的资源。比起其他原因,这类寻找更多地是由于 URL 的拼写错误而致,但链接过时、后端的错误配置、不同点的 URL 残缺等因素也不容小觑。当资源不可用时,一个很好的做法是提供某种回转页面以协助用户导航到其他有用的页面。一个普通的 “没有找到” 虽然可以让用户知道资源不可用,但却无法帮助他们解决 “下一步如何做” 的问题。

警告:在创建定制的 404.html(或 Web 服务器用来发布定制 “没有找到” 消息的任何其他机制)时,太多的 Web 站点都会被错误地配置成发送 “soft 404” 消息。换句话说,它们会发送一个带常规的 “200 OK” 标题的页面,这仅仅说明了文本的某个地方“不可用”,也许还提到(但不经常)此处有 “404 Error”。应该避免这样做。相反,应该让用户(和他们的 Web 浏览器以及其他工具)省些事,使用确切的状态标题。

about.html

那么,究竟为何要创建 Web 站点呢?没错,需要用一个首页来回答这个问题。但更可能的情况是,首页并不提供这类信息,而只是让用户能够登录、突出站点的 “卖点”、显示某些花哨的内容等等。也许还需要让用户能够从首页导航到 “关于” 页面,如果真是这样,请务必让该信息能够从 http://mysite.example.com/about.html 获得。有些人习惯从此页寻找这类信息。

一个好的 about.html 页面应该能够提供有关站点功能、创建此站点的意图以及用户为何要关注此站点的总览,而且还有可能会有几个链接能够帮用户导航回站点的核心功能。此页无需、而且通常也不应该十分华丽。只需让它保持务实且准确,以便用户能够利用站点所能提供的所有功能。

contact.html

那么,如何联系您呢?借助 about.html,用户可以通过在现有主页上的多次单击获得此信息。不要让用户费太多力气才能找到此信息:将其放置于 http://mysite.example.com/contact.html。为相同的页面同样使用 contacts.html。请引入 .htm 扩展名。名称易得易用。当然,也可以将此信息留在这些单击产生的连串导航屏幕的最后;但为寻找资源提供冗余方案的做法也不错。

copyright.html

网站的版权归谁所有?有可能内容属于您,但您又是谁呢?个人?公司?合伙人?政府机构?如果内容属于公共领域或在自由内容许可的范畴内,那么可能需要告知用户这一点。时下,几乎任何内容都有各自的版权归属:如果您的内容遵从不同的原则,那么就请告知用户。但目前费心提供这类信息的网站还不够多,但为何不将它添加到自己的网站呢?因为总会有些用户会关注这方面的信息。

很明显,不同的页面或资源可能有不同的版权信息。请利用这个页面为用户提供有关如何确定那些个别差异的信息。如果有商标方面的问题,请一并提供。

index.html(和 index.htm)

并不是每个 Web 服务器都实际使用 index.html 文件来描述其主页。根据设置的不同,可能会有 URL 重写、依路径名动态生成等手段。但用户并不关心这些细节!只需让 http://mysite.example.com/index.html 指向主页,即便是为了实现这一目的而必须要使用简单 HTML 重定向。

对了,既然如此,那么就索性让老的 .htm 扩展名也生效吧。如果还觉得不够,就对 index.cgi 也如法炮制吧。

index.rss

很多 Web 内容都可通过 RSS 提供。虽然此种做法并不适用于所有 Web 站点,但对大多数站点而言还是比较有效的。让 RSS 内容独立于特定于用户的配置选项、登录或为特定的信息付费的做法极其合理。因为 RSS 也不能面面俱到。

虽然如此,如果有些东西 可以作为 RSS 提供,那么请尽管这么去做。也许,在 index.rss 给出的不过是 “广告” 内容,有时还会一并提供如何利用 RSS 提要的种种优势的老生常谈。有时又或许是有关 RSS 为何与您的 Web 站点不相关的一个说明。

privacy.html

一旦想要收集用户信息(即使只有用户名或流量日志),就要告知用户您打算如何处理这些信息。围绕 Web 站点创建者和/或用户的权力和责任的法律问题十分复杂 — 我不是一名律师,更无法解决 法律方面的问题。不过,若能考虑到用户的个人私隐,用户还是会感觉到的。而且也许您 应该在此时与律师 商谈一下该如何处理用户的数据。

robots.txt

如果不想让 Web 站点上的所有资源都能被自动工具编入索引,就请在 robots.txt 文件内加以说明。但如果确实 想让内容都编入索引,也请如实说明。Robots Exclusion Standard 指令并不强制用户:如果的确 不想让某些东西可见,就请不要将其放到站点,或者要确保其后有足够的许可保护。不过,所有主要的合法 Web 爬虫引擎都会遵从 robots.txt 内的要求。因此请尽量明确地说明您的意图。

security.html

security.html 的使用并不强制。但如果站点存在安全性问题(比如,从用户那收集了任何敏感的信息),为安全性流程建立文档说明(至少给出大致的概括)不失是个很好的做法。请在此页给出联系信息以防用户存在任何疑问或想要给出如何改进的建议。寻找这些信息应该遵从网站导航选项的整体组织。既然如此,不妨在这个 URL 也放上该资源。

站点地图

如何显示整个 Web 站点的地图还未完全标准化。为制作站点地图而提供的某些东西 总是很有用的,但这些东西究竟详细到何种程度取决于站点的动态程度(或动态的方式)。而且,想要为用户显示的内容也依赖于站点的意图。比如,如果用户没有对资源 X 的使用权限,那么让用户知道资源 X 的存在可能根本就不合适。请根据自己的判断和具体情况,设法提供一些东西

对于很多站点,提供站点地图只不过是对诸如搜索引擎这类自动机制的支持和友好。Google 在 robots.txt 约定的基础上发布了一个新的约定。总之,可以创建一个 XML 文件来给出站点所提供的所有资源。这有点像一个 “包含列表”,充当了 robots.txt 的 “排除列表” 的补集。

电子邮件地址

只考虑 Web 上的东西还不够。有时 Web 站点的导航工具并不能尽入人意(或者有的用户可能会对您的优雅设计不理解),因此最好让用户也能通过电子邮件联系到您。

请务必在 Web 站点的 contact.html 或其他地方显著地公布联系信息。但也请确保发到一般性的电子邮件地址的邮件能够送达给合适的人员。这至少包括 [email protected][email protected][email protected]。对于那些 “老辈人”,可能需要让发给 [email protected] 的邮件也能转达到合适之处(但出于安全性原因,可能不是到 “root”)。请加入少许对电子邮件转发进行说明的文字,这些文字应该能清楚表明站点目的。电子邮件地址就像 Web 服务器目录中的符号链接一样易得易用。

参考资料