单页应用并不是单页一个全新发明的技术 ，而是应用引擎优化随着互联网的发展 ，越来越受Web开发者欢迎 ，搜索单页应用的单页体验可以模拟原生应用，一次开发 ，应用引擎优化多端兼容，搜索效果酷炫，单页节省成本 。应用引擎优化然而 ，搜索由于单页应用基本全部使用JS ，单页受制于SEO效果 ，应用引擎优化目前国内使用单页应页技术的搜索网站还是少之又少 。在已知使用单页应用的单页站点中 ，携程旅行的应用引擎优化SEO效果一直不错 ，那么今天 ，搜索安琦老师为我们分享了单页应用SEO解决四大方案 ，其中第四套是携程旅行曾经采用的技术方案 ，监控数据表明效果符合预期 ：
我们所说的"单页应用"都为Single Page Application的直译，基本市面上"单页面应用" 、"One Page Application" 、"SPA"及某些语境下的"webapp " 都是指这一类移动站点 。
那么典型的SPA是什么样子？我们用手机看看这条URL，http://cc-ng-z.azurewebsites.net/，可以衍生想象一下乘以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】
还好 ，开发大大们总是不少奇巧淫技 ，这是个很"经典"的用法 ，配合<noscript>这个擦边球标签 ，既能实现URL的自定义 ，又能实现还算有效果的内容抓取 。蜘蛛 、浏览器 ，两方应对 ，给蜘蛛不带井号能抓取的URL ，给浏览器访问非井号URL时中间做转换，这样的话每张页面都有了可抓取的URL ，且依然使用着高逼格的SPA架构 。内链可以做了 ，Sitemap可以做了 ，适配也轻松了 。
但实际上 ，蜘蛛在这种页面上还是盲的 ，所有内容要仰仗于noscript这个标签里塞的数据 ，以及搜索引擎对这个标签的支持程度 。
做到这一步，单就需求而言 ，搜索引擎的抓取从HTML规范讲完成了 ，但这种方式没有任何搜索承认过支持 ，包括最核心的那个对于noscript标签的支持 。
【方案四：用更高效的方式完成两套页面】
再回到那个简单的架构图，SPA这种架构 ，渲染是在客户端（浏览器）完成的 ，大致流程如下 ：
蜘蛛无法执行JS ，相应的页面内容无从抓取 ，弊端还是那个弊端。但我们知道 ，传统的服务端生成页面 ，response里已经是服务器渲染组装好的HTML代码 ，浏览器只负责正确地展现 ，蜘蛛负责正确的解析，所以 ，我们需要给蜘蛛渲染完成的HTML ，那么你的框架需要兼容如下流程的功能 。
我们看到 ，当访问为SEO所需页面的时候 ，数据传输到了SEO 服务器完成渲染和组装然后吐给浏览器和蜘蛛 ，那么蜘蛛拿到的即是完全可见且融合了SPA的页面——landing页都是蜘蛛可见的 ，接下去用户的点击都是SPA的页面 。
需要注意的是 ，如果你是用URL来区分SPA架构与否 ，那么内链及入口要全部使用SEO URL,只为用户暴露SPA的链接 ，JS在这里阴差阳错地成为了优势 ，那些SPA的链接将比较难被抓取的 。
其实可以不使用URL来区分 ，延伸想想。这样一个流程 ，也无多少高精尖元素，其实只是"依照条件"增加了一个服务端自动渲染的步骤 ，在架构方案上再细细夯实 ，可以实现一套代码两处运行 、SEO页面可单独自定义功能 、 、同一张landing人和蜘蛛没有跳转 ，没有区别对待 、全栈工程师的大量使用 、SEO页面永远保持最新版等等省时省力的需求功能 。
总之 ，如果你和我一样，有文章前面部分的抱怨 ，SPA架构势在必行 ，两套页面改版不能同步 ，单独多做一套可抓取页面没有太多资源投入 ，与此同时还是想以比较保守的方式给蜘蛛展现网站的内容，那么这个思路可以考虑 ，然后为自己量身定做 。
关于单页应用的网站优化，在实践中我所经历过的这些吧 。优化不是按部就班 ，作为从业人员要审时度势地采取不同方案 ，以结果为导向 ，上不了线，再好的优化也是个方案 。
