域名预订/竞价,好“米”不错过
单页应用并不是一个全新发明的技术,而是随着互联网的发展,越来越受web开发者欢迎,单页应用的体验可以模拟原生应用,一次开发,多端兼容,效果酷炫,节省成本。然而,由于单页应用基本全部使用JS,受制于SEO效果,目前国内使用单页应页技术的网站还是少之又少。在已知使用单页应用的站点中,携程旅行的SEO效果一直不错,那么今天,我们请携程旅行SEO技术负责人安琦老师为我们分享了单页应用SEO解决四大方案,其中第四套是目前携程旅行采用的技术方案,监控数据表明效果符合预期:
一、单页应用?此SPA不是彼SPA…
我们所说的“单页应用”都为Single Page Application的直译,基本市面上“单页面应用”、“One Page Application”、“SPA”及某些语境下的“webapp ” 都是指这一类移动站点。
那么典型的SPA是什么样子?我们用手机看看这条URL,,可以衍生想象一下乘以N倍的:切换页面无需加载的效果,HTML和JS无法比拟的动画,以及对原生APP的追求……
*案例采用了angularJS这个鼎鼎大名的框架
关于HTML5及单页应用的处境,推荐以下两篇文章,第二篇实际上是百度UMX写的,但是现在原文删掉了,可以对自己的移动站点在技术架构上有个抉择和处理:
HTML5移动应用开发的生态环境简介
论Web App、Hybrid App以及Native App的设计差异
二,高科技永远连累我们干苦力的
为什么这么写,因为SPA对SEO损伤很大,非常大。
优点当然毋庸置疑:效果酷炫,我在视觉和产品面前无从反驳;性能高速度快,全JS嘛当然快,我在运维和产品面前无言以对;运算分散,异步加载,又省硬件又省流量,我在开发和产品面前彻底投降;JS前后端,一个人干一个站的活儿——关于这一点,我在老板、HR和产品面前哭的像一个孩子。总之,在各路人马的一番碾压后,我手里的网站改版了,一个SPA诞生了。
问题接踵而来:我发现所有页面都变成了全JS生成;所有URL中参数前面都被#分割;第三方统计系统无法再正常工作;PC和移动的适配正则全部失效了;所有人都高兴了,只有你,做SEO的、做网站优化的,欲哭无泪。
实际上我观察下来,只要使用了SPA架构的站点或多或少收到伤害,当看到有些大站点没做处理,只有可能搜索对于他们是个微不足道的渠道,比如锤子手机官网甚至不可思议地在PC站点上使用了类似架构,我相信他们的索引是有点问题的。这让我想到知乎上一个问题,说AMAZON的URL那么乱(当时)是因为他们不注重SEO吗?答案是不是,是他们更注重tracking。同理,SPA带来的优点胜过SEO,我被PK掉了。
三,求人不如求己
在SPA项目面前,我发现我被放在了所有人的对立面,无法抗拒这种时髦架构的上线,当然不得不说效果确实比WAP即视感的站点高端和好用太多,不要螳臂当车逆历史车轮而动。既然反抗也很痛,那么享受吧!我知道,我还和搜索引擎在一起;老板要的是解决方案,当然回滚这种方案会让我先滚。
让我们看看一个典型的SPA网站架构,和传统的服务端生成内容不同,在传统的网站,当你发起请求的时候,页面的组装是在服务器上完成的,反馈给浏览器的是已经完成组装的HTML内容;而之于SPA,服务端负责了数据和素材的存储,页面的逻辑执行和组装是在浏览器上通过Javascript完成和呈现的,这也就意味着,SPA不需要请求→接受、请求→接受、请求→接受、请求→接受这样玩了。完全凭借本地数据,即可完成基本的页面请求和访问。
基于此,当某人需要像APP那样切换页面但不刷新,并要在此基础上做文章时,#(井号)这个奇葩的符号粉墨登场,完成了“又要本地传输数据又不需要刷新页面”这个奇葩需求的历史任务,给单页应用的可抓取性重重一击。整个SPA的网站,URL不可抓取,页面内容不可抓取,糟透了。
解决思路倒也简单,围绕全JS和URL可用解决问题。
【方案一:尽人皆知的Google抓取AJAX方案】
如何让搜索引擎抓取AJAX内容?
A proposal for making AJAX crawlable
Google给了官方指导,并在Twitter上做了个最大的case,但后来T家放弃了,我想更多是T战略上的放弃。腾讯的ISUX博客上也曾经推广过这种方式,居然是在2014年,如下文:单页应用的SEO浅谈
总的来说,这种方案可以兼容Google,如果资源实在有限,有着能抓多少是多少的心态,可以试试。主要不幸的是,5年前Google已和我们再见了
【方案二:再做一个服务端生成内容的镜像网站】
说实话,量级不大的网站并且极度依赖搜索引擎这个渠道的情况下,这不失为一种方案,第一,蜘蛛绝对可抓取;第二,URL规则的完全可控(要知道现在流行的路由方式,在配置URL规则上相对于URLrewrite是有天生缺陷的);第三,SPA模式URL衍生的所有问题不再是问题。
但是面临的问题也令我望而却步:我要说服team再维护一个一模一样的网站,不是做完了事,是维护,这意味着修Bug要有资源修,改版要有资源改(能说服自己搜索进来然后点两下看到的网站不一样吗?)、所有相关功能的测试、发布、常规测试,都要耦合在一起,当站点大到一定程度,流程前所未有地臃肿,推进无休止的争吵,所有烦恼包围着我,让我想静静。我预计自己会累垮,即使搞定了所有的资源,网站优化人员自身也将面临着非常繁重的工作,两个网站怎么融合,适配跳转怎么设定,是否需要主动判断蜘蛛展现不同的内容,内链入口怎么放,都是耦合,且是硬耦合,网站大了页面多了,越做耦合越多,以后一碰就是坑。
【方案三:HTML5 history 中的PushState】
还好,开发大大们总是不少奇巧淫技,这是个很”经典”的用法,配合
申请创业报道,分享创业好点子。点击此处,共同探讨创业新机遇!