SEO 网站优化及网站推广

Alexa 排名优化有没有捷径-提高Alexa排名的八个方法

2010-08-30T18:34:31Z

最近又看到我在三年前写的那篇《提高Alexa排名的九个方法》在知名SEO论坛出现，后面还有跟贴说，看到这篇文章很多地方都有，还说不知道是谁写的。呵呵，就是我写的，虽然是1997年的文章，有些观点和方法还是适用的。

先看看本站目前的Alexa排名。
Traffic Rank 92,138
在中国的traffic Rank是11,788
这样的排名已经稳定了有两年多了。

那么对于一个新站，或者Alexa排名一直不好的网站是否有什麽捷径可以快速提高Alexa排名的呢？
一个坏消息，一个好消息。
坏消息就是，我的答案可能会让大家失望，那就是没有捷径。
好消息就是，有安全而较为快速的小路可走。

]]> 下面我们就来总结一下之前我曾经用过的针对Alexa排名而做的优化措施。

1）安装Alexa工具条。并且设置自己的网站作为默认首页，这样每次你打开浏览器的时候，Alexa统计就开始工作了。

2）把Alexa排名统计的widget放在网站上，当它被显示/点击的时候，也相当于Alexa统计到一次PV，即使那个用户没有安装Alexa工具条。

3）如果可以的话，在你的公司或者办公室里的电脑里都安装上Alexa工具条。

4）在站长论坛里发贴子的时候留下你的链接，一般站长的电脑安装Alexa工具条的较多，当他们访问你的网站的时候，当然会有帮助。

5）给你的Blog添加一个Alexa分类，把有关Alexa的文章都放在里面，这样站长有更大的机会来到你的Blog，你的排名当然就容易上升。

6）找到你的Blog上最受欢迎的文章，把Alexa的链接添加上。

7）提供一些站长工具，这样站长就会经常来造访，并且提高你的Alexa排名，比如David Yin提供的SEO 在线工具r就是一个很好的例子。

8）多去那些Alexa排名高的网站看看，如果有有意思的文章，那么就留言，或者在自己的blog写一些相关的文章，并且引用（trackback）原文。因为高Alexa排名的网站其用户安装Alexa工具条的比例较高，从那里吸引过来的访客，会较多机会增加你的Alexa排名。

上面就是更新版的提高Alexa排名的八个方法。

]]>

Yahoo的搜索服务并入微软的Bing搜索

2010-08-25T16:49:36Z

今天，我在Yahoo上搜索内容，和微软的Bing搜索上，搜索的内容已经几乎一致了，那些微的差别，是不同的搜索服务器造成的。

雅虎高级副总裁Shashi Seth说：从现在开始，雅虎在美国和加拿大市场上面向台式机和移动设备的网络、图像和视频搜索体验均由微软平台提供支持，其它市场也会跟进。

今天，他又澄清，Yahoo还是一个搜索引擎，只是把原生的自然搜索部分外包给了Bing，其它的部分仍然是自己管理，比如自己的内容，第三方的内容，以及社会化媒体的内容等等会补充道搜索结果中。

这样的情况，对于Google是有一定的冲击，毕竟搜索的老二老三联手了，竞争会更大，要打破垄断，现在已经有Google一家独大的情况出现了，再好的公司，再好的服务，只要处在垄断的位置，一定会变化。

]]>

优化WordPress的利器，W3 Total Cache

2010-08-19T17:25:35Z

介绍了这么多提高网站性能，改善用户体验的通用方法，那么是否有一个简单易用的工具可以使用在WordPress上呢？答案是有的，而且是一个非常强壮的工具，你使用了它，其它的性能优化工具都可以不用了。这就是W3 Total Cache。

这里详述一下W3 Total Cache有哪些益处，对网站的哪些方面做了优化。

获益的8个方面。
1）当配置完全后，可以获得十倍以上的总体性能改善，比如在Yslow评分中得A。
2）在Google站长工具后台可以看到平均载入时间的大幅变化。
3）提高转换率。
4）打开第二个页面的速度大为提高，因为浏览器缓存开始工作了。
5）页面渲染的速度得到优化，网页几乎是即刻展开的。
6）页面载入时间减少，增加了用户浏览时间，或者是用户浏览更多的页面。
7）提高web服务器的性能，特别是在流量高峰的时候会有很明显的改善。
8）超过80%的带宽节省，主要是通过对html，CSS, JS文件的minify，压缩来实现。

]]> W3 Total Cache实现WordPress优化的手段有下面这些：
1）Page Cache
这个有点儿类似其它的WordPress Cache插件。
但其可以在操作码层面（Opcode）进行优化缓存，比如我所使用的Xcache。

2）Minify
这可以对Html和CSS，JS和feed，大概减少10%文件大小。
同时还可以在Opcode缓存。

3）数据库缓存
在数据库缓存可以提速100倍，也可以用Opcode缓存。

4）对象缓存
除了可以使用Opcode，也支持其它的缓存方式，比如disk。

5）CDN
这是重头戏。它可以使用镜像方式的CDN，比如之前我介绍过的MaxCDN。也可以用Push方式的CDN，比如现在我使用的Amazon CloudFront之类的。

6）浏览器缓存
这个部分就是通过gzip压缩，以及添加http头来通知浏览器缓存时间的长短。

在W3 Total Cache的设置中，还有更多更为详细的细节设置，就不一一说了，有兴趣的可以安装试用，记得在使用前和使用后，都用测试工具来评估一下，性能的改善情况。相信一定会有惊喜。

]]>

使用Amazon CloudFront作本站的CDN

2010-08-06T22:01:29Z

现在开始，使用Amazon CloudFront代替之前所用的MaxCDN来做CDN。

这并不是说MaxCDN有什麽不好的，只是，这里有很多祖国的读者，为了改善从大陆访问的速度，而做的改变。

DavidYin曾经介绍过哪些是最适合放到CloudFront上的内容，Amazon服务的申请和CloudFront的计费方式，以及我所用过的4款相关工具。

Ryan Kearney有一个对四个CDN服务商的比较，包括CloudFront，Rackspace，GoGrid CDN，Simple CDN，得空可以看看。

]]> 而最终让我选择CloudFront的一个最大考虑，就是它拥有，Hong Kong and Singapore Edge Locations和Japan Edge Locations。这两个地方都可以服务到大陆用户，比从美国服务器上获取文件，快多了。

]]>

让Amazon CloudFront也支持GZ压缩

2010-08-04T18:51:20Z

Amazon的S3和CloudFront并不会检测客户端是否支持gzip压缩，也就不会根据需要实时压缩内容来提供给客户端。
也是David Yin所说的，默认Amazon CloudFront的服务器是没有gz压缩的。

使用gz压缩，可以减少所下载文件大小，并且减少下载时间，加快页面载入速度。还有一个就是可以减少带宽。

以本站为例，我压缩了三个文件。
压缩前一共是38.9KB，gzip压缩后一共是10.8KB。
其实在做gzip压缩前，已经做过一次minify了，没有做minify之前，一共有62KB.
这三个文件是本站访问最多的三个，就是一个js文件，两个css文件。

最终的压缩量是从62KB到10.8KB。

好了下面介绍一下如何实现这个压缩。

]]> 首先把原生的css文件，用Yahoo Compressor工具对该文件进行minify。
接着，使用开源免费的压缩工具7-zip，对其进行压缩，选择gzip压缩方式。生成的文件，可能是叫做style.css.gz，然后手工改名成为，style.gz.css。

我所使用的CloudFront工具，主要就是CloudBerry Explorer for S3。
上传到相应的文件夹，关键是设置：
Set HTTP Headers
Content-Encoding:gzip
这一步设置好，然后，从浏览器访问时，客户端就知道该文件下载后要用gzip解压缩后才能使用。

当然这里也是有一个问题，或者说缺陷存在，如果一个浏览器是不支持gz压缩的，那么这些个压缩过的文件，将没有用处，如果是css文件，页面布局就会缺失，如果是js，网站功能可能就有部分不能实现。
但是现在，2010年，不支持gz的浏览器已经很难找到，所有目前的浏览器都是支持的，包括搜索引擎的蜘蛛，只要是支持http1.1标准的，就没有问题。

另外，测试评分方面。
使用Pagespeed测试了一下，修改前是88分，修改这三个文件之后，就是90分。
而是用Yslow测试的结果是从84分到87分。都有所提高。

]]>

VPS服务的稳定性及客户服务

2010-07-27T22:05:41Z

之前在写挑选VPS的几个考虑时，没有把稳定性包括在其中，但其实我一直认为这一点是毋庸置疑，放在最为前面的。

在这个月，本站所寄放的swVPS，就出现了三次宕机，连控制面板都上不去，最严重的一次是周日晚上开始到周一早晨，offline超过10小时。
根据其在线保证时间的条款，在周一下午，我提出了退款要求，晚上，获得相当于一个月使用的退款。这个客户服务还是可以的，平时我提交维护帖，一般都在3个小时左右得到回复。
当然我还是会继续使用，目前使用到现在一年半以来，只有这个月的情况最为糟糕。
平时的月份，大概只有一两次宕机一两个小时的情况。

swvps的在线时间保证条款是这样的：
99.6% - 100% Uptime: No Credit
99.0% - 99.5% Uptime: 25% of your monthly bill
98.0% - 98.9% Uptime: 50% of your monthly bill
Less than 98% Uptime: 100% of your monthly bill

一个月中，只要宕机超过15个小时，就是低于98%的在线时间保证了，就可以获得全额当月退款。当然做网站的站长，没有人希望出现宕机。

这个退款不会自动产生，使用者需要自己检测，并且提出，否则是不会有退款的。

]]> 目前我还在继续寻找可能更好的VPS服务商，有一个已经进入我的考虑范畴，就是BURSTNET，如果有哪位使用过的一段时间的，请不吝赐教。

刚刚看到SWVPS的LVPS-2款VPS，其内存已经升级到1024M了，突发内存是2G，不知道是何时的事情。

]]>

微软搜索站长工具更新

2010-07-21T16:55:57Z

微软的搜索，从MSN Search到Windows Live Search，然后再改名到Live Search，最后才成为现在的Bing。
刚刚Microsoft发布了它新的站长工具。根据官方Blog的说法，有不少的新特性。

包括：
蜘蛛抓取内容的情况；
网站内容的收录；
来自搜索的流量。

其中，同Google一样，有提交网址，显示蜘蛛抓取的错误，站长可以block不想显示的网址，以及提供最多6个月的各类报告。

微软搜索站长工具入口

Bing Webmaster Tools

]]>

微博的使用和同步

2010-07-12T19:07:18Z

微博的平台太多，如何在多个微博系统中同步更新是一个困难的问题。特别是现在有很多的微博没有易用的接口可用，这里我就简单的介绍一下我的同步方法。

我的基本基地还是在blog，就是说大段文字仍然以blog为主，这里始终是一个能够较为完整表达自己想法的地方，内容和反馈都是可控的。

微博是一个快速分享的地方，任何片段都可以在那边及时的发布，而不用考虑过多。

所以这里我都是以blog为主体，Twitter为辅。

Blog日常发布文章，然后采用插件就是之前我介绍的PostTwiOAuth，每次发布新文章，该插件可以发布一条Twitter消息，并带有bit.ly的文章短链接。如果不是使用MovableType的话，也可以使用twitterfeed，把feed同步到twitterfeed。

Blog 发布》Feedburner 》 Twitterfeed 》 Twitter 》
从Twitter出发，我是分别同步到Friendfeed，facebook。

这些国外的工具可以方便的互相同步，因为都基于开放的原则。对于国内的微博，则需要采用另类的措施，这里我使用的是月光的程序。

]]> 月光他写了一个程序，非常好用，我安装后给它一个名字tongbu4，该程序是安装在Google App Engine（GAE）上，有Google帐号的朋友，可以申请一个GAE服务，然后下载月光的程序，在程序中设置自己的帐号，然后上传到GAE上。

从原理上来说，Tongbu4程序就是每隔固定的时间（我设置5分钟），读取所设定的Twitter帐号的更新，然后分别同步到所设定的微博上，比如David Yin就是同步到网易微博，搜狐微博，做啥，还有就是新浪，但现在新浪屏蔽了GAE的IP，同步不成功，虽然在开始安装的时候，的确是同步了数个tweete，但之后就再也没有成功过。
同时从tongbu4我又同步到ping.fm，由ping.fm再转发到Bebo和Plurk。

其实通过ping.fm可以同步到更多的服务，看你的需要在定。

在设置自己的同步路线，路径的时候，记得不要循环同步，交叉同步要小心，否则就会陷入死循环，自己把自己累死。

另外，因为twitter api的使用有限制，这个同步工具会耗用，如果你同时使用twhirl之类的客户端，那么很快就会看到超过limit，等待之类的。所以把时间间隔设置的长一些，不要设置成1分钟一次。

最后，致谢puppy blog，月光的程序安装方法，我是从他这里学的。

]]>

PostTwiOAuth 0.40 released

2010-07-10T00:10:41Z

自动通知Twitter的MovableType插件再次升级。

下载最新的插件包。

在设置的地方增加了两项新设置，Enabel Twitter Client和Use Twitter @Anywhere，虽然不明白是干什麽用的，不管它，插件作者说你选上就是。

这次升级若是从0.30升级上来的，应该可以覆盖升级的，因为我就是这样做的。

]]> 这些日子在使用微博，各个微博上都尽量开设帐号，然后以Twitter为核心，向各个服务同步。
具体的请看下回分解。

]]>

订阅数超过一万

2010-06-29T22:55:48Z

不知不觉中，本站的更新频率成了月记，太多琐碎的事情是一个非常合理的借口。

今天才看到，本站的订阅数已经超过了一万，从6月23日开始超过一万的。

还是去年六月的时候，我写了SEO的订阅数超过8000，以记之。

今天当然也要记录一下，2010-06-29 订阅数10085。

这里广告一下：订阅SEO网站优化及网站推广，获得最新SEO消息。

还是鼓励大家订阅，而不是到本站来看，保持全文输出，方便订阅者阅读，不以PV为目标，只为分享技术和观察。
除非你要留言，请来本站相关文章下，提供你的意见。

]]>

MovableType用Twitter的OAuth接口通知新文章的发布

2010-06-21T21:06:49Z

自Twitter全面采用OAuth验证接口后，过去很多使用Basic Auth的程序插件都不能用了。

现在在MovableType下，当新文章写完发布时，自动在Twitter帐号下发一条微博告诉大家有新文章发布的消息的插件，DavidYin只发现一个日本人所写的插件好用，就是PostTwiOAuth，现在已经升级到0.21版，并且同时支持MT4和MT5。

PostTwiOAuth几个有特色的地方：
1）支持bit.ly段网址，把你的文章url直接转换成短网址
2）自定义Tweete标题
3）Tweete再发布，就是re-post

具体的安装方法，就不写了，日文好的同学可以直接看日文，不好的同学可以用Google 翻译来翻译那个页面来用。
或者看我简单写的英文说明，写的很烂，因为是仓促中写的。

这里特别写一个要注意的地方，就是权限问题。
CHANGE THREE CGI FILES UNDER posttwioauth FOLDER TO 755
就是说安装后，在posttwioauth文件夹下的CGI文件，都要给予可执行的权限，否则会出错。

]]> Update：

上午写的文章，在中文blog出现一些问题，反馈给作者后，很快晚上就看到了更新版本，v0.30。
如果你还没有安装的话，可以去这里，下载最新的0.30版，照着那边的说明做就可以了。如果你已经安装了0.21版的话，那么就需要删除原来的文件，然后全新上传新版的plugin文件。登录后台时，会提示更新该plugin。

这次的更新就没有中文blog所有的问题了。

]]>

在线评测一下你的网站负荷能力

2010-06-14T04:17:13Z

通常一个网站可以同时承受的用户流量压力是有一定的限制，随着用户上线人数的增加，网站相应的时间就会逐步的慢下来。
当用户数量达到一个限度时，用户再打开该网站的网页，就会出现timeout。

那么如何衡量你的网站的情况呢？
我推荐一个免费在线评估工具，Load Impact

使用其免费测试功能，对本站进行了一下测试，结果如下图

该测试，从10个用户端，到50个用户，进行了5次测试。
从测试结果来看可以看到，user load time几乎是一条直线，也就是说，网站太强大了，这些个用户数根本测不出负载的变化，需要更多的用户数才能看出变化。

]]> 你也可以对你自己的网站做一下简单的测试，用load impact工具评测一下。
你的评测结果曲线可能同我的可能不同，如何解读，你可以看看这里的说明。

还有两个很常用的网站负载评估工具，或者说压力测试工具。
1）AB 工具
几乎用Linux服务器的站长，可能都用过这个Linux自带的工具。
2）Webbench
上面的链接是张宴介绍的，我也用过，很容易，也方便。

这里提醒一下，做压力测试，只能对自己的网站，或者得到网站站长同意，才能进行测试。

]]>

网站提速和节省带宽一举两得

2010-06-04T23:34:34Z

网站上的网页通常都有单独的CSS，js文件，当用户打开一个页面时，会根据要求来载入这些文件。
那么当站长使用了一些技术手段后，就可以利用缓存和压缩来提高页面的载入速度。

下面用一个CSS文件为例，说明可能节省的带宽。
1）原来的css文件，3,779bytes
2）minified之后的CSS文件，2,870bytes
3）再使用gzip压缩，1,043bytes

没有使用min和gzip时，用户每次访问，都要下载3.69K的数据
使用之后，用户每次访问，只需下载1.01K的数据，节省72.6%的下载量。

接着我们在设置缓存，也就是设置http header，如下。
Cache-Control max-age=5184000, public。

这样的设置，是60天缓存。当用户访问过一次后，后续访问，都不再下载该文件，直到60天后，再重新下载。

通常这样的缓存设置，可以节省大量的带宽。用户访问时，只是从服务器获得一个http header，比较本地信息后，就不再下载数据了，当然也就节省了下载的时间，页面载入也更快了。

]]> 此文也间接回答了，之前一位读者提出的问题。

价格可以,不过流量为什么这么少呢?1.5G也太少了,如果一天四五百IP,一个月也要1G多流量

我所提供的北美主机空间所提供的流量，目前，最低配置Value Plan 主机计划，空间300MB，每月流量1.5GB。
当不够使用时，可以升级到更高流量和空间的主机计划。
换一句话说，使用虚拟空间主机的，都是小站，个人站点，其实流量大多不是那么的大，当你的网站大到虚拟空间不付使用时，也就是到时候升级到VPS的时候了，甚至可以直接租用服务器了。

]]>

对于国内那些域名管理的对策

2010-05-27T17:46:00Z

最近一个月，收到几封来自域名管理商，新网互联的email，主要的内容就是要求提交注册人的个人资料，以核对域名注册信息。

对此非常反感，当然也不会去配合。因此在5月20日收到一封email后，以及5月26日又收到相同内容的email。
据email中的说法是30天内要提交证明。

对此我的对策就是不去管它，目前我只拥有3个中国域名，是放在新网互联，从2007年开始持有，算不得好名字，也还过得去，续费一直到2011年，如果管理部门停止了我的中国域名，那么就放弃它们，这没有什麽大不了的，没有什麽可惜的。

在我看来，用国际顶级域名才是最好的。
可以自由拥有，并可以自由转入，转出的域名才是真的可以用来做网站的。

]]> 好了，牢骚发好了。

得空再去看看Google Analytics Opt-Out工具，给用户免除隐私风险的工具，在你的浏览器上安装该插件，那么不管你访问什麽网站，那个网站上的Google Analytics追踪代码都不会记录你使用该网站的信息。但是请注意，这只是防止Google收集你的信息，而不是网站，网站可以使用其它的统计代码，其它的统计工具，甚至直接检查网站日志，总还是可以追踪到。

但是，从这个地方可以看到，Google的大气，或者从另一角度看是西方各国隐私专员对Google所施加的压力而推动这个工具的诞生，因为Google自己不做，还有其它人会做，与其让别人来做，不如自己做。呵呵，想多了就不好玩了。

]]>

Google Analytics新代码

2010-05-25T20:31:33Z

Google Analytics的代码更新了，这次它们采用了异步追踪的方式，通常来讲这样用户浏览时更快，更不会感觉到因为代码下载而造成的延迟。

Google官方Blog发布的文章，希望站长们都能改用，它称之为升级，到新的代码，在它们的代码提取说明中提到，把新代码放到页面的紧跟着之后，但是在Analytics在线帮助的地方却告诉大家放在之前。
当然都是在页面代码的头部，但两个地方说明不一致，却是一个明显的错误。让用户感到混淆。

就这一问题，我在那边留下了问题。貌似官方的答复是下面这个。

Jeff Gillis said...

Apologies for the confusion. We recommend the bottom of the head area, before the closing head tag.

就是说放在之前。

]]> 所以使用Google Analytics的站长们都可以升级追踪代码并放到HEAD的最后。

]]>