單頁應(yīng)用SEO淺談

　　前言

　　單頁應(yīng)用(Single Page Application)越來越受web開發(fā)者歡迎，單頁應(yīng)用的體驗可以模擬原生應(yīng)用，一次開發(fā)，多端兼容。單頁應(yīng)用并不是一個全新發(fā)明的技術(shù)，而是隨著互聯(lián)網(wǎng)的發(fā)展，滿足用戶體驗的一種綜合技術(shù)。

　　SEO

　　一直以來，搜索引擎優(yōu)化(SEO)是開發(fā)者容易忽略的部分。SEO是針對搜索(Google、百度、雅虎搜索等)在技術(shù)細節(jié)上的優(yōu)化，例如語義、搜索關(guān)鍵詞與內(nèi)容相關(guān)性、收錄量、搜索排名等。SEO也是同行、市場競爭常用的的營銷手段。Google、百度的搜索結(jié)果是重要的用戶入口，騰訊云(www.qcloud.com)有30%左右的流量來自搜索引擎。因此SEO在品牌、營銷、用戶量的緯度是非常重要的基礎(chǔ)能力。

　　那么單頁應(yīng)用與傳統(tǒng)直出頁面在SEO方面有哪些不同之處呢?

　　單頁應(yīng)用的優(yōu)點

　　更好的用戶體驗，讓用戶在web感受natvie的速度和流暢;

　　經(jīng)典MVC開發(fā)模式，前后端各負其責(zé)。

　　一套Server API，多端使用(web、移動APP等)

　　重前端，業(yè)務(wù)邏輯全部在本地操作，數(shù)據(jù)都需要通過AJAX同步、提交;

　　對搜索引擎不友好

　　單頁應(yīng)用實際是把視圖(View)渲染從Server交給瀏覽器，Server只提供JSON格式數(shù)據(jù)，視圖和內(nèi)容都是通過本地JavaScript來組織和渲染。而搜索搜索引擎抓取的內(nèi)容，需要有完整的HTML和內(nèi)容，單頁應(yīng)用架構(gòu)的站點，并不能很好的支持搜索。

　　如果站點在用戶體驗和搜索友好權(quán)衡時，如果我們做到更好的體驗，也做到友好的搜索支持，既是一箭雙雕。

　　URL中的哈希(#號)

　　單頁應(yīng)用只有一個頁面，視圖的變化通常是通過路由(route)來驅(qū)動，首先，我們先來談一談單頁應(yīng)用的URL中的#號，很多采用單元結(jié)構(gòu)網(wǎng)站的URL都出現(xiàn)了這個符號。

　　#號在瀏覽器的URL中是一個錨點，在當(dāng)前頁改變#號的參數(shù)，頁面會跳轉(zhuǎn)到錨點所在的位置，通過JavaScript我們可以獲取到#號后的參數(shù)：

1
2

location.hash // 獲取URL hash
location.hash = "#list" //改變URL hash

　　改變#號后的參數(shù)，頁面并不會重載，于是大多數(shù)的單頁架構(gòu)網(wǎng)站，都在URL中采用#號來作為當(dāng)前視圖的URL地址，例如：

1
2
3

example.com/#index  //首頁視圖
example.com/#list   //列表頁視圖
example.com/#list/1   //id為1的列表信息的視圖

　　Backbone.js就是通過改變#號參數(shù)來組織視圖，這里有一個demo可以很直觀的體驗URL的變化。

　　看過這個demo，你或許會發(fā)現(xiàn)很熟悉的符號#!，Twitter曾在URL使用這個標(biāo)識。這個標(biāo)識是Google提出(AJAX 抓?。壕W(wǎng)站站長和開發(fā)人員指南1)：

　　因為復(fù)雜的單頁架構(gòu)頁面，對Google來說抓取比較困難，于是給開發(fā)者制定一個規(guī)范：

　　網(wǎng)站提交sitemap給Google;

　　Google發(fā)現(xiàn)URL里有#!符號，例如example.com/#!/detail/1，于是Google開始抓取example.com/?_escaped_fragment_=/detail/1;

　　_escaped_fragment_這個參數(shù)是Google指定的命名，如果開發(fā)者希望把網(wǎng)站內(nèi)容提交給Google，就必須通過這個參數(shù)生成靜態(tài)頁面。

　　根據(jù)上面的demo，我簡單示例一下Google要抓取的頁面的樣子:

　　http://119.28.4.22/?escapedfragment_=/detail/1

　　如此以來，就需要Server通過生成靜態(tài)的內(nèi)容以便Google抓取。

　　以下將簡單介紹，單頁架構(gòu)，爬蟲訪問根目錄時如果配置Server端的路由。

　　判斷爬蟲

　　當(dāng)Google訪問119.28.4.22/#!/detail/1 時，會自動轉(zhuǎn)化成http://119.28.4.22/?_escaped_fragment_=/detail/1，以Nginx為例：

1
2
3

if ($args ~ _escaped_fragment_) {
   rewrite ^ /api;
}

　　/api為后臺服務(wù)的接口，已nodejs為例，代理設(shè)置如下：

1
2
3
4
5
6
7
8
9
10
11
12
13

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處理請求把靜態(tài)內(nèi)容輸出即可。

　　sitemap

　　Gogole的這個規(guī)范，必須有sitemap支持，因為有可能單頁架構(gòu)的站點，索引頁面也是JavaScript渲染的。提交sitemap時，不用關(guān)注_escaped_fragment_這個參數(shù)名，只提交帶哈希符號的URL即可，例如：

1
2
3
4

<loc>http://119.28.4.22/#!/detail/1</loc>
<changefreq>weekly</changefreq>
<priority>0.5</priority>
</url>

　　結(jié)語

　　技術(shù)潮流的步伐很快，單頁應(yīng)用，URL哈希處理也沒渲染的方式實際上已經(jīng)流行了很久，在國外很多用戶數(shù)據(jù)較好的情況下，開發(fā)者會選擇HTML5 History API的pushstate特性開發(fā)，在URL中拋棄#!。但是IE6、7等低端瀏覽器用戶情況較多的網(wǎng)站，#能夠很好的兼容。關(guān)于采用HTML5 History API來架構(gòu)單頁應(yīng)用的方案，也歡迎討論。

　　參考1: https://support.google.com/webmasters/answer/174992?hl=zh-Hans

　　感謝你的閱讀，本文由 騰訊ISUX 版權(quán)所有，轉(zhuǎn)載時請注明出處，違者必究，謝謝你的合作。

　　注明出處格式：騰訊ISUX (http://isux.tencent.com/seo-for-single-page-applications.html)