中文网站搜索引擎优化技术研究

　　近段时间以来，随着网站访问量的上升——SEO探索相对还“好”些，上升曲线比较平缓，而Vista天地则有些“让我欢喜让我忧”了。——服务器越来越不堪重负，昨天竟然频繁出现连我自己也无法访问的情况，当然，这与服务器带宽也有关系，不过，相对而言，IT技术点评则由于使用静态网页，情况要好得多。因此，必须考虑对WordPress实施优化了。

　　在WordPress的Cache类插件中，最著名的恐怕非WP-cache 莫属了，其通过缓存机制，将相应网页中的内容保存在静态文件中，这样，当其他用户再次访问时即可直接提取缓存文件，免除了WordPress重新编译PHP代码、频繁读取数据库带来的效率低下问题，从某种意义上说，相当于静态化网页一样。

　　不过，WP-cache基于Linux/Appache开发，在Windows/IIS平台下并不能按其默认的方法安装，因为其中有些针对Linux/Appache的环境设定。通过Google找到了这篇介绍在Windows中安装WP-cache的文章，依其步骤，果然能够使用WP-cache了。

　　不过，试了几个页面后发现，启用WP-cache让网页彻底乱了套，很多网页显示的内容完全一样，比如说“http://seo.highdiy.com/index.php/seo/user-behavior-in-serp/”与“http://seo.highdiy.com/index.php/category/seo-general/”竟然成了同一个页面，诡异！

　　再次搜索，找到了这篇文章，Using WP-Cache on Windows /IIS，其中对出现这类问题的原因作了解释，与我们permalinks中含有“index.php”有关，由于在Windows / IIS, $_SERVER[’REQUEST_URI’]不能返回正确值而导致。该文并给出了相应的解决办法。

　　如果您的WordPress也架设于Windows/IIS平台，并且使用与本站类似的permalinks设置，可参考这两篇文章。

　　不知您在访问SEO探索或Vista天地时是否能够感觉到些许的速度提升？或者，是否发现不正常之处？

　　在上篇文章中我们探讨过自定义404页面返回不当状态码如“200”等给网站最终SEO效果带来的不利影响，因此，确保自定义的404错误页面能够返回“404”状态码是极为重要的，也是网站优化与SEO的基本要求。

　　这一点如何保证呢？如何才能为网站设置能够正常工作的404错误页面？下面针对不同情况详细介绍。

定制404错误页面的基本原则

　　首先应明确的是，404错误应工作在服务器级而不是网页级。对定制使用动态页面如PHP脚本类型的404页时，必须确保在PHP执行前服务器已经顺利地送出“404”状态码，不然，一旦执行到了ISAPI级别，返回的状态码便只能是“200”或其他如“302”之类的重定向状态码了。

　　其次，无效链接有可能指向网站内的任何位置，因此，在定制网站的404错误页面时，对其中的链接应使用绝对路径而不是相对路径。这点相信很容易理解，考虑一下“http://www.highdiy.com/a/a.html”与“http://www.highdiy.com/a.html”这样两个位于不同目录深度的无效链接，当404错误页中链接使用相对路径时便会彻底乱套。

Apache下设置404错误页面

　　为Apache Server设置 404错误页面的方法很简单，只需在.htaccess 文件中加入如下内容即可：

ErrorDocument 404 /notfound.php

　　当然，把”/notfound.php” 改为自定义404错误页面的地址和名称。

　　尤其需要注意的是，不要采取如下的方式：

ErrorDocument 404 http://www.highdiy.com/notfound.php

　　这样设置则是错误的：其将返回“200”状态码而不是“404”。

　　另外，需要注意的是，如果您的.htaccess存在类似这样的内容：

ErrorDocument 404 /index.php

　　切记要将其删除：这种将404错误转向到网站主页的作法存在极大的风险，严重时会导致主页在搜索引擎中消失。

IIS/ASP.net下设置404错误页面

　　IIS/ASP.net一直是404页面不能正确返回“404”状态码的重灾区，尤其对动态网页而言，很多网站在使用IIS管理器设置404自定义错误页面后发现其返回码却是“302” + “200”。

　　在IIS/ASP.net下设置404动态页面

　　首先，修改应用程序根目录的设置，打开 “web.config” 文件编辑，在其中加入如下内容：

＜configuration＞
＜system.web＞
＜customErrors mode=”On” defaultRedirect=”error.asp”＞
＜error statusCode=”404″ redirect=”notfound.asp” /＞
＜/customErrors＞
＜/system.web＞
＜/configuration＞

　　注：上文例中“error.asp”为系统默认的404页面，“notfound.asp”为自定义的404页面，使用时请修改相应文件名。

　　然后，在自定义的404页面“notfound.asp”中加入：

＜%
Response.Status = “404 Not Found”
%＞

　　这样，便可以保证IIS能够正确地返回“404”状态码。

　　注：为显示方便，上文代码中使用的是全角的“＜”与“＞”，应用时应将其改为半角字符。

　　在IIS/ASP.net下设置404静态页面

　　设置静态404错误页面的方法则比较简单，在IIS管理器中右键单击要管理的网站，打开“属性”中的“自定义错误信息”页，为“404”设定相应的错误信息页即可。不过，此处在“消息类型”中一定要选择“文件”或“默认值”，而不要选择“URL”，不然，将导致返回“200”状态码。

　　当然，在设置完成后，最好用Server Header检查工具检查一下设定是否正确。

　　有时候，就算在网站优化方面投入了很多精力，比如为网站建立了不少相关的链接，也进行了相应的页面优化等，但网站的SEO效果却总是不够理想，甚至连网页被搜索引擎及时索引这样的基本要求都不能满足。这并非信口开河，毕竟，除网站自身的优化外，还有很多别的因素影响网站在搜索引擎中的表现，比如说DNS设置不当。

　　最近在帮几位朋友分析他们网站SEO效果为什么不佳时，惊奇地发现，这几个网站或多或少地都存在DNS设置相关的问题，不知道是巧合还是这种情况的确很普通。——虽然总有些让人感觉不可思议。

缘于DNS设置的域名解析问题

　　DNS(即Domain Name System或域名服务)是Internet的核心服务之一，通过一个在域名和IP地址间建立相互映射的分布式数据库，DNS能够使人更方便的访问互联网，而不用去记住那些枯燥、难记的IP数字串。对应地，执行域名服务的服务器即为DNS服务器，它对域名的查询请求作出应答。

　　换言之，DNS的作用是把域名转换成为可以识别的与网站主机相对应的ip地址(在此暂不涉及从IP地址到域名的反向解析)，那么，当我们的网站可以通过域名如“www.highdiy.com”访问时，是不是就意味着DNS解析没有问题呢？

　　也不尽然。

　　这次遇到的一位朋友的网站就很典型，本来，作为使用服务器托管且服务器上仅有四个流量不大网站的情况，访问速度应该很快，但不幸的是，他的网站访问起来慢得要命，当然，他也发现，搜索引擎的Spider如Googlebot就成了几天难得见上一面的稀客。具体什么原因造成的则始终没有找到，他甚至重装了服务器，当然，问题依旧。

　　通过查询他的网站whois信息得知，该域名的DNS解析由域名注册商的DNS服务器提供，但让人很难理解的是，该域名商提供的DNS服务器竟然还有其他用途：还是一个存放了上百个网站的虚拟主机，导致访问这台DNS很慢，有时候甚至连接失败，不过，这还不是最可气的，更让人难以理解的是，注册商竟然将他域名的TTL值设为60。

　　在此简单介绍一下域名的TTL，一般说来，我们上网时使用的是ISP的DNS服务器，这样，当发出某个网址请求如“www.highdiy.com”时，ISP的DNS服务器会首先在自己的缓存数据库中寻找，如果找到相应的记录，便反馈回客户端，如果没有，则按照根解析服务器 - 域名原始解析服务器的顺序，查到该域名的对应信息，反馈客户端并将相应的信息贮存到自己的缓存数据库中，以备再有同样网址的请求时DNS服务器可以直接回应。但是，这些缓存数据是有一定生命周期的，过了一定时限后便会被清除。而TTL，即是决定相应的域名解析信息存活时间的数值，其单位为秒。

　　回到我们上面的例子中来，一方面该DNS服务器因承担过多的工作而繁忙异常难以访问，另一方面，又设定了缓存只有60秒也即一分钟的生命周期，迫使必须频繁地访问这台不堪重负的服务器，真是尴尬的两难！:oops: ——老实说，该域名商的技术人员要么工作极不认真，设定时输入错误数值，要么就是脑袋长虫子了。——从另一个角度，这不但造成了用户访问的困难，对搜索引擎的Spider同样如此，很难想象搜索引擎会喜欢一个动辄不能访问的网站。

　　当然，类似这样的情况可能有些极端，不过，因DNS设置不当影响网站优化效果则似乎并不在少数。比如说，大多数网站建设者往往比较关注含“www”的域名如“www.highdiy.com”，而对无“www”的“highdiy.com”则一般容易疏忽，要么没做解析，要么解析了却未做相应的301 Redirect导致重复内容等。前两天另一位朋友网站的问题便在于他的无“www”域名虽然也做了解析，但在DNS设置中Cname定义循环嵌套，导致出错。此外，也有不少人认为网站的whois信息不正确时同样会影响搜索引擎尤其是Google的索引和收录，甚至有人认为域名的反向解析存在错误时也会影响网站的SEO效果(对这种说法个人倒表示怀疑)，但无论如何，DNS设置是网站建设最基础的工作，谨慎一点确保其正确无误总是没错的。

　　要检查网站域名DNS是否正确，其实很简单，Windows 内置的nslookup命令即可提供很多有价值的信息，而网站的whois信息查询工具Internet上则比比皆是。——仅针对顶级域名。CNNIC提供的“.cn”域名的whois查询则相对简陋得多，不知朋友们是否清楚好一些的CN域名whois查询工具？

慎用域名注册商或虚拟主机商的URL转发功能

　　许多域名注册商或虚拟主机商都提供一种免费的URL转发功能，让拥有一个主网站并同时拥有多个域名的用户实现多个域名指向同一个网站或网站子目录，但具体是通过什么机制实现的则大都讳忌莫深，往往只说“通过服务器的特殊技术设置”。同时，大多数服务商提供的URL转发还包括两种，不隐藏路径的URL转发与隐藏路径的URL转发，其中，不隐藏路径的URL转发指在跳转后浏览器地址栏显示真正的目标地址，而隐藏路径的URL转发则在跳转后虽然显示跳转目标页面的内容，但浏览器地址栏则仍显示输入的地址。

　　那么，这类URL转发会不会影响网站的SEO效果呢？老实说，因本人没用过类似的服务，这次因一个优化效果不理想的网站使用该服务才临时抱佛脚，找几家著名企业提供的类似服务简单分析一下，可能有以偏盖全之处，仅供参考。

　　对隐藏路径的URL转发，虽然不能下百分之百的结论，但笔者所见的几家企业均是通过框架实现，即将待跳转的目标页面嵌入到框架中，以这种方式来保证地址栏不显示目标网页地址。相信朋友们都清楚框架式网页对搜索引擎来说是相当不友好的，很多时候搜索引擎只能看到无内容的空白框架，而且，这类网页的标题只能是所定义的主框架页面的标题，而不会是目标网页真正与内容相关的Title。

　　对不隐藏路径的URL转发，按说使用301重定向在技术上并不难实现，不过，笔者所看的几家中只有一家用的是301 Redirect，其他的要么是使用框架，要么使用JavaScript或Meta Refresh，使用框架的弊端上文已做过介绍，使用JavaScript或Meta Refresh则不仅容易被搜索引擎视作“doorway pages”，而且还存在重复内容的问题，这些均是SEO的大忌。

　　因此，对这类URL转发，如果您不能确信其使用301重定向的话，最好慎用。——当然，纯属个人看法。

　　您可以使用这个重定向检查工具来确认URL转发是否使用301 Redirect

题外话

　　本人并非SEO或网站优化方面的从业人员，当然更不是专家，对SEO与网站优化仅是个人兴趣，欢迎朋友们在相应的帖子中针对特定话题留言与回复，大家展开讨论共同提高。

　　对于希望通过E-mail交流的朋友，当然本人深感荣幸，不过，最好将讨论的主题限定在SEO探索发布文章的内容范围内，而不是泛泛的“我的网站为什么在Google排名不佳”或“帮忙看看我的网站有什么问题”之类，老实说，这些问题都太大，不是几句话能说得清，恐怕也并非象我这样水平的人能够解决的，况本人精力所限。因此，以后这类邮件恕不回复，声明在先，敬请谅解！

　　我们网站服务器的带宽一直是个问题，已经有不少用户抱怨访问速度过慢，虽然我们也在竭力改善，但先天的不足很难得到根本性的改善。我们所能做的也只能是在一定程度降低带宽的占用，象IT技术点评的改版便是出于尽量精减页面文件大小的目的，而考虑是否应该禁掉Yahoo! Slurp或Outfoxbot无非也是缘于带宽的窘迫，不过，还有一个大问题最近一直在困扰着我们，估计许多朋友也会遇到，那便是盗链，尤其是图片文件的盗链。

　　IT技术点评因为网站自身的性质，很多图片是必需的，比如评测硬件性能时的测试数据图表，甚至不能压缩得太厉害，不然，便很难清楚地说明问题。随着IT技术点评访问量的上升，大量的图片文件对服务器带宽的占用日趋严重，而其他网站对图片的盗链则更雪上加霜。如果说其他网站不加说明不注出处地对我们内容的拷贝让我们郁闷的话，这种图片的盗链则更过份：复制内容虽然在某种程度上可以说是剽窃我们的劳动成果，但毕竟对网站本身没有太大的伤害，而图片盗链则让带宽被无任何回报地占用，影响网站的访问速度。我们对此的反应也只是为图片添加水印，加上我们网站的地址，希望这一方面能让盗链者有所忌讳，另一方面即便被盗链，希望能有用户循此找到我们网站。当然，这并不解决盗链的有效手段，但是，在我们目前基于Windows + IIS的服务器平台对这个问题好象没有什么更好的办法(仅是个人之见，可能不对。如蒙高手指点，不胜感激)。

　　这时候便不由自主地地感叹起服务器平台选择的重要性来了，如果在Linux + Apache下，想要防止类似的盗链是相当简单的，而IIS以图形化的管理界面降低入手难度的同时，不免增加了许多管理上的难度。

　　下面简单介绍一下笔者之前在Linux + Apache平台下防止图片被盗链的设定方法，希望能对同样面临图片盗链问题，服务器基于Linux + Apache的朋友有所帮助。

　　注：1、本文虽然谈的是防止图片盗链的问题，但设定也同样适用于其他非Html类型的文件，比如说下载网站的防盗链，只需将下面设定中的文件类似由gif、jpg更改为相应的zip或rar即可。

　　2、本方法笔者在Linux + Apache下测试通过，而对于是否也同样适用于Windows + Apache平台，则没有把握，采用这类平台的朋友可自行测试。

Apache中的.htaccess文件

　　.htaccess文件(或者”分布式配置文件”)是Apache中相当重要的配置文件，其格式为纯文本，它提供了针对目录改变配置的方法，通过在一个特定的文档目录中放置一个包含一个或多个指令的文件，以作用于此目录及其所有子目录。

　　通过.htaccess文件，可以实现简单地很多在IIS中很繁琐甚至无法实现的功能，如密码保护、禁止显示目录列表、阻止/允许特定的IP地址、实现网址的301 重定向等。

　　正如上面所说， .htaccess文件将影响其所在的目录及其子目录，因此，如果我们要保护的内容(此处以防止图片盗链为例，即图片)位于网站内多个目录下，可以考虑将其放在根目录下；而如果图片有单独的子目录如“/images/”，则只需将其放置在该目录下。

　　需要注意的是，如果通过FTP方式将创建好的.htaccess上传到服务器上，传输模式应为ASCII而非Binary。上传到服务器后，应将其属性通过CHMOD修改为644 或“RW-R–R–”，这样，可以保证服务器能够使用同时无法通过浏览器修改，当然，.htaccess的可读属性也存在一定的风险：攻击者可通过它找出您要保护的对象或认证文件位置——解决办法是将认证文件.htpasswd放到网站根目录之外，这样，便无法通过网络找到它了。

使用.htaccess禁止盗链

　　通过.htaccess来防止网站的图片、压缩文件、或视频等非Html文件被盗链的方法相当简单，通过在.htaccess文件中加入几句命令即可保护我们宝贵的带宽。

RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www\.)?highdiy.com/.*$ [NC]
RewriteRule \.(gif|jpg)$ - [F]

　　其中，前两行为命令声明，不必管它，第三行中的“http://highdiy.com”则需改为相应的网站地址，而第四行则为防止盗链的文件类型：gif与jpg，根据需要，可更改或添加其他文件类型，如rar、mov等，不同文件扩展名间使用“|”分割。

　　如果希望不仅仅让盗链者无法盗链，还要显示出某些警告信息，可创建一个内嵌如“Highdiy图片”、“请勿盗链”文字的图片，——当然，图片要足够小，不然无法达到节省带宽的主要目的——上传到网站根目录或这个.htaccess文件影响不到的其他目录下，如“http://www.highdiy.com/warning.gif”，然后，将上面的第四行改为：

RewriteRule \.(gif|jpg)$ http://www.highdiy.com/warning.gif [R,L]

　　这样，盗链者将看不到其想要盗链的图片，而只能看到您的警告或调侃。

　　Tags: htaccess , Apache

　　从严格意义上，favicon的话题无关SEO技术，也与Web服务器技术方面的讨论没有太大干系，不过，在我们的网站建设中，为网站打造一个契合网站主题的个性化标志则是必需的，这直接关系到能否成功地塑造网站的品牌。这从某些角度看仍在网站推广的范畴之内，而欲取得成功，不仅包括良好的页面设计、令人印象深刻的网站Logo，也包括favicon。

什么是favicon？

　　所谓favicon，即Favorites Icon的缩写，顾名思义，便是其可以让浏览器的收藏夹中除显示相应的标题外，还以图标的方式区别不同的网站。当然，这不仅仅是Favicon的全部，根据浏览器的不同，Favicon的显示也有所区别：在大多数主流浏览器如FireFox和Internet Explorer (5.5及以上版本)中，favicon不仅在收藏夹中显示，还会同时出现在地址栏上，这时用户可以拖曳favicon到桌面以建立到网站的快捷方式；除此之外，标签式浏览器甚至还有不少扩展的功能，如FireFox甚至支持动画格式的favicon等。

　　从特定的技术角度看，favicon也并不只是仅仅让网站给人更专业的观感，也可以在一定程度上减轻服务器的流量带宽占用：一般为了提高网站的可用性，我们都会为自己的网站创建一个自定义的404错误文件，在这种情况下，如果网站没有相应的favicon.ico文件，每当有用户收藏网站/网页时，Web服务器都会调用这个自定义的404文件，并在网站的错误日志中记录。这显然是应该予以避免的。

如何制作Favicon.ico

　　制作Favicon.ico的方法相当简单，首先，利用图形工具创建2个反映网站主题的256色的小图片：1个为32×32像素，另一个为16×16像素。需要注意的是，调色板要选用“Windows 默认调色板”，不然，在最终的效果展示中图形可能会发生迥异于您初衷的颜色上变化。

　　需要说明的是，在很多关于Favicon.ico的说明中，常见到要求图片为16色的说法，应该说这类说法大大过时：在早期如Windows 95时期，16色的Favicon.ico可能是个稳妥的选择，保证其在大多数情况下正常使用，但现在，完全不存在那类限制，16色只能使图标的展示效果大大降低。

　　至于在浏览器中使用时16×16像素的图片已经足够，为什么还要准备32×32像素的图片，原因在于，正如上文所言，favicon也显示在地址栏中，用户可以拖曳favicon到桌面以建立到网站的快捷方式，而桌面图标则要以32×32显示的，如果您的Favicon.ico不包括32像素的图片，系统就只能使用默认的浏览器图标来标注网站/网页，如Internet Explorer的蓝色“e”，起不到我们意欲通过Favicon.ico打造网站品牌的作用。

　　图片制作好后，使用如Image2Ico之类的小程序即可将2张图片转换到一个Icon文件中。也可以通过可以在线制作Favicon的网站来制作，不过，需要注意的是，这个网站要求图片源文件格式为Pic。

在网页中使用Favicon.ico

　　浏览器调用Favicon的原则是首先在网页所在的目录下寻找Favicon.ico文件，如果没有，便到网站的根目录下寻找。

　　因此，在网页中使用Favicon最简单的办法便是将制作好的图标文件命名为Favicon.ico，然后将其上传到网站的根目录即可。

　　如果您需要将Favicon.ico放到其他目录下，或者希望让不同的网页显示不同的Favicon，就需要在网页Html文件中做设定了，具体设置也很简单，在Html中的＜head＞部分加入如下的代码：

＜link rel=”icon” href=”/dir/favicon.ico” mce_href=”/dir/favicon.ico” type=”image/x-icon”＞
＜link rel=”shortcut icon” href=”/dir/favicon.ico” mce_href=”/dir/favicon.ico” type=”image/x-icon”＞

　　Tags: Favicon