單頁應用的搜索引擎優化
單頁應用（Single Page Application）越來越受web開發者歡迎，單頁應用的體驗可以模擬原生應用，一次開發，多端兼容。單頁應用並不是一個全新發明的技術，而是隨著互聯網的發展，滿足用戶體驗的一種綜合技術。
SEO
一直以來，搜索引擎優化（SEO）是開發者容易忽略的部分。SEO是針對搜索（Google、百度、雅虎搜索等）在技術細節上的優化，例如語義、搜索關鍵詞與內容相關性、收錄量、搜索排名等。SEO也是同行、市場競爭常用的的營銷手段。Google、百度的搜索結果是重要的用戶入口，騰訊雲有30%左右的流量來自搜索引擎。因此SEO在品牌、營銷、用戶量的緯度是非常重要的基礎能力。
單頁應用並不是一個全新發明的技術，而是隨著互聯網的發展，越來越受web開發者歡迎，單頁應用的體驗可以模擬原生應用，一次開發，多端兼容，效果酷炫，節省成本。然而，由於單頁應用基本全部使用JS，受制於SEO效果，目前國內使用單頁應頁技術的網站還是少之又少。
在已知使用單頁應用的站點中，攜程旅行的SEO效果一直不錯，那麼今天，我們請攜程旅行SEO技術負責人安琦老師為我們分享了單頁應用SEO解決四大方案，其中第四套是目前攜程旅行採用的技術方案，監控數據表明效果符合預期：
一、單頁應用？此SPA不是彼SPA…
我們所說的「單頁應用」都為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】
還好，開發大大們總是不少奇巧淫技，這是個很」經典」的用法，配合這個擦邊球標籤，既能實現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頁面永遠保持最新版等等省時省力的需求功能。
【優點】
1、具有桌面應用的即時性、網站的可移植性和可訪問性。
2、用戶體驗好、快，內容的改變不需要重新載入整個頁面，web應用更具響應性和更令人著迷。
3、基於上面一點，SPA相對對伺服器壓力小。
4、良好的前後端分離。SPA和RESTful架構一起使用，後端不再負責模板渲染、輸出頁面工作，web前端和各種移動終端地位對等，後端API通用化。分離前後端關注點，前端負責界面顯示，後端負責數據存儲和計算，各司其職，不會把前後端的邏輯混雜在一起；
5、減輕伺服器壓力，伺服器只用出數據就可以，不用管展示邏輯和頁面合成，吞吐能力會提高几倍；
6、同一套後端程序代碼，不用修改就可以用於Web界面、手機、平板等多種客戶端；
7、對前端人員javascript技能要求更高，促使團隊技能提升。
【缺點】
1、分功能模塊的鑒權不好實現；
2、書籤，需要程序來提供支持；
3、SEO問題，現在可以通過Prerender等技術解決一部分；
4、初次載入耗時相對增多。
5、導航不可用，如果一定要導航需要自行實現前進、後退，前進、後退、地址欄等，需要程序進行管理；
6、對開發人員技能水平、開發成本高。
總之，如果你和我一樣，有文章前面部分的抱怨，SPA架構勢在必行，兩套頁面改版不能同步，單獨多做一套可抓取頁面沒有太多資源投入，與此同時還是想以比較保守的方式給蜘蛛展現網站的內容，那麼這個思路可以考慮，然後為自己量身定做。
關於單頁應用的網站優化，在實踐中我所經歷過的這些吧。優化不是按部就班，作為從業人員要審時度勢地採取不同方案，以結果為導向，上不了線，再好的優化也是個方案。
那麼單頁應用與傳統直出頁面在SEO方面有哪些不同之處呢？
單頁應用的優點
對搜索引擎不友好
單頁應用實際是把視圖（View）渲染從Server交給瀏覽器，Server只提供JSON格式數據，視圖和內容都是通過本地JavaScript來組織和渲染。而搜索搜索引擎抓取的內容，需要有完整的HTML和內容，單頁應用架構的站點，並不能很好的支持搜索。
如果站點在用戶體驗和搜索友好權衡時，如果我們做到更好的體驗，也做到友好的搜索支持，既是一箭雙鵰。
URL中的哈希（#號）
單頁應用只有一個頁面，視圖的變化通常是通過路由（route）來驅動，首先，我們先來談一談單頁應用的URL中的#號，很多採用單元結構網站的URL都出現了這個符號。
#號在瀏覽器的URL中是一個錨點，在當前頁改變#號的參數，頁面會跳轉到錨點所在的位置，通過JavaScript我們可以獲取到#號後的參數：
location.hash // 獲取URL hash
location.hash = "#list" //改變URL hash
改變#號後的參數，頁面並不會重載，於是大多數的單頁架構網站，都在URL中採用#號來作為當前視圖的URL地址，例如：
example.com/#index //首頁視圖
example.com/#list //列表頁視圖
example.com/#list/1 //id為1的列表信息的視圖
Backbone.js就是通過改變#號參數來組織視圖，這裡有一個demo(http://119.28.4.22）可以很直觀的體驗URL的變化。
看過這個demo，你或許會發現很熟悉的符號#!，Twitter曾在URL使用這個標識。這個標識是Google提出（AJAX 抓取：網站站長和開發人員指南1）：
因為複雜的單頁架構頁面，對Google來說抓取比較困難，於是給開發者制定一個規範：
網站提交sitemap給Google；
Google發現URL里有#!符號，例如example.com/#!/detail/1，於是Google開始抓取example.com/?_escaped_fragment_=/detail/1；
_escaped_fragment_這個參數是Google指定的命名，如果開發者希望把網站內容提交給Google，就必須通過這個參數生成靜態頁面。
根據上面的demo，我簡單示例一下Google要抓取的頁面的樣子:
http://119.28.4.22/?escapedfragment_=/detail/1
如此以來，就需要Server通過生成靜態的內容以便Google抓取。
以下將簡單介紹，單頁架構，爬蟲訪問根目錄時如果配置Server端的路由。
判斷爬蟲
當Google訪問119.28.4.22/#!/detail/1 時，會自動轉化成http://119.28.4.22/?_escaped_fragment_=/detail/1，以Nginx為例：
if ($args ~ _escaped_fragment_) {
rewrite ^ /api;
}
/api為後台服務的介面，已nodejs為例，代理設置如下：
upstream nodejs {
server 127.0.0.1:3000;
}
location /api {
proxy_set_header X-Request-URI $request_uri;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $host;
proxy_set_header Port $server_port;
proxy_pass http://nodejs; proxy_redirect off;
}
如此，我們便將Google的訪問重寫到/api這個介面，然後在Server的/api處理請求把靜態內容輸出即可。
sitemap
Gogole的這個規範，必須有sitemap支持，因為有可能單頁架構的站點，索引頁面也是JavaScript渲染的。提交sitemap時，不用關注_escaped_fragment_這個參數名，只提交帶哈希符號的URL即可，例如：
http://119.28.4.22/#!/detail/1
weekly
0.5
【微信運營】微信公眾號開發、朋友圈廣告、微信運營活動、微信小程序、微商城搭建；
【PC網站】網站建設、網站結構、網站功能、關鍵字策劃、UI設計、網站SEO、升級改版；
【手機軟體】APP應用設計與開發、網站製作、專項策劃與推廣、網站優化；
【軟體研發】行業性系統應用、硬體應用、WEB網站應用模塊、行業軟體；
【廣告設計】標誌設計、vi設計、海報設計、宣傳手冊設計；
【整合營銷】品牌形象文案策劃、產品銷售概念策劃、產品銷售文案策劃；
【SEO優化】SEO排名優化、論壇營銷、口碑營銷、公關活動等線上傳播；
【託管維護】信息更新、網站安全、市場與受眾分析、品牌與產品分析、整合營銷推廣；
【定製培訓】專業施教團隊、完整課程體系、實際項目操作、一站式委培。
TAG:全球大搜羅 |