我们的网站是否需要静态化页面
现在很多新手,对一个网站进行优化诊断,第一个步骤就是不管三七二十一,先判断网站是否静态化,如果没有就建议客户进行页面静态化。将页面静态化后,无非是希望搜索引擎喜欢,能被收录的机会多些。这并不是因为动态页面就做不了SEO,而是相对静态页面而言,动态页面的SEO会增加些难度,目前多数搜索引擎都能收录动态页面,使用动态页面的站点数也远远大于静态页面的站点数。但是如果把具体因素综合考虑起来,页面静态化有时候反而是得不偿失。
在百度出的搜索引擎优化指南里,百度明确表示:动态的URL对搜索引擎没有影响;但是建议尽量减少动态url中包含的变量参数,这样即有助于减少url长度,也可以减少让搜索引擎掉入黑洞的风险。通过多次实践表明,对于搜索引擎而言,它们对静态页面和动态页面并没有特殊的好恶,只是有时候动态页面的url参数机制不利于搜索引擎收录,而静态页面的url更容易收录而已。此外,静态页面在一定程度上降低系统负载,也提高了页面访问速度和系统性能及稳定性。减少因为程序问题而引发的页面故障。
然而对于大中型网站,静态化带来的问题和后续成本也是不容忽视的:
1、由于生成的文件数量较多,需要生成的文件往往多达几百万个,存储需要考虑文件、文件夹的数量问题和磁盘空间容量的问题———需要大量的服务器设备;
2、页面维护的复杂性和大工作量,及带来的页面维护及时性问题——需要一整套站点更新制度和专业的站点维护人员;
3、站点静态化,增加了更新维护难度和网站管理人员工作强度,增加了硬件设备需求和损耗速度,增加了站点潜在的访问冲突和故障概率。对于一个大型网站而言,这都是必须考虑的问题。
许多大型网站虽然网址的后缀为.htm,但其实还是动态页面,只是用了伪html链接、URL Rewrite等方式“欺骗”搜索引擎,真正完全静态的没有发现几个。但就在页面更新维护问题上,即使是伪静态,也一样带来了不少维护的复杂性和工作量。
伪静态是相对真实静态来讲的,有的朋友为了实时的显示一些信息.或者还想运用动态脚本解决一些问题.不能用静态的方式来展示网站内容.如果用动态页面的话就损失了对搜索引擎的友好面.怎么样在两者之间找个中间方法呢,这就产生了伪静态技术.
伪静态优点:易收录(静态网站的优点)+便于更新(动态网站的优点)
缺点:系统资源消耗很大。流量稍大一些使用伪静态就容易出现CPU使用超负荷,由于伪静态是用正则判断而不是真实地址,分辨到底显示哪个页面的责任也由直接指定转由CPU来判断了,所以CPU占用率的上升,是伪静态最大的弊病.伪静态在遇到错误的页面的情况下不会执行IIS,也就不会调用404页面。需要从WEB CONFIG内调用 或者直接从程序中写入错误处理方式。
所以,网站优化并非一定需要静态化。静态化对于网站优化来说,应当只是一个辅助方法,告诉搜索引擎我的站点很好收录,使搜索引擎尽可能尽可能方便的“浏览”站点内的内容。而只要能够方便浏览和收录,不论是静态页面还是动态页面,搜索引擎都会一视同仁的去收录。
对于小网站而言,站点静态化或许是解决网站收录量的一个简便的办法,而对于大网站来说,则要认真考虑了,是不是真的有必要去做静态化,还是做一下“相对静态化”就够了。
那我们到底应该选择伪静态还是真静态呢?
伪静态最大的缺点就是打开速度慢, 耗资源,实际上在不同条件下,都有不同的优势。
真正的静态网页,因为都是已经生成好的实实在在的html文件,不包含需要服务器端解释执行的脚本语言(如Asp、Php之类的),因此相对伪静态来说最大的优势就是节省服务器计算资源(CPU等)且不受服务器脚本解释器状态影响,尤其是流量大的网站(如日IP上千上万的站点),不管解释器是否超慢甚至当掉(就是超负荷停止运行了)静态页面还是能快速打开,最大的缺点是消耗服务器存储资源(容量),因为每个产品或文章都需要生成html文件,如果你只是一个普通企业站,空间100M左右,产品不多百来个且每个产品图片不超过3张,页面静态化还是比较好的选择
伪静态之所以消耗资源是因为每次访问还是需要依靠脚本解释器解释编译php或asp文件里面的程序,包括读写数据库等操作。一旦访问量大,配置一般的服务器(CPU差、内存小的那种)的资源明显被消耗得差不多的时候解释器就会变慢甚至当掉,这种时候别人访问你的这些伪静态页面自然也会变慢甚至打不开。
不管怎么样,在访问量小(日IP1000以下)的情况下,选择伪静态跟真静态效果差不多,差异感觉不出来,如果访问量大,尤其是使用虚拟主机的站点,最好还是选择以生成html页面为主的网站管理系统。
具体要选择静态化页面,还是要选择伪静态。就要根据你自己的实际情况了。老生常谈,与其花心思做SEO,不如努力做出网站的特色,太多重复的内容会将你的网站淹没在垃圾网页的海洋里,只有具有原创特色,推出的独家信息资料的网页才会真正得到 搜索引擎的关照。
还没有任何评论,你来说两句吧