摘要：前言在網站頁面后端渲染的時代，開發者只需要按照規范制作搜索引擎友好的頁面便可以快速讓搜索引擎收錄自己網站的各個頁面。

在網站頁面后端渲染的時代，開發者只需要按照規范制作搜索引擎友好的頁面便可以快速讓搜索引擎收錄自己網站的各個頁面。

隨著前后端技術的更新，越來越多的前端框架進入開發者們的視野，網站的前后分離架構越來越得到開發者們的喜愛與認可。 后端只提供數據接口、業務邏輯與持久化服務，而視圖、控制與渲染則交給前端。 因此，越來越多的網站從后端渲染變成了前端渲染，而由此帶來的直接問題就是各大搜索引擎爬蟲對于前端渲染的頁面（ 動態內容 ）還無法比較完善的爬取，這就導致了網站的內容無法被搜索引擎收錄，直接影響網站流量與曝光度。

博主的網站從去年五月開始也開始采用了前后分離的構架，使用了 AngularJS 框架搭建了 NewRaPo ， 之后又使用 Vue.js 框架進行了整體重構 RaPo3。 無一例外，他們都是基于前端渲染的，然后在此后的一年多時間里，搜索引擎收錄的頁面都是這樣的：

（ 其他搜索引擎也一樣，最早的截圖已經找不到了，先拿這個應付一下 ）

快照是這樣的：

而博主實際的網站是這樣的：

和這樣的：

感覺完全被搜索引擎拋棄了好嘛！這東西誰能搜到啊！搜到了誰會點啊！

為了能讓搜索引擎正常的收錄博主的網站，于是博主踏上了動態 SEO 優化的踩坑之路：

首先，博主 Google 到了在動態頁面中加入 會告訴爬蟲這是個動態內容的頁面，然后爬蟲會在當前鏈接后面加上 ?_escaped_fragment_=tag 來獲取相應頁面的靜態版，于是果斷盤算在路由里改一下，然后重寫一套后端渲染的頁面返回給所有帶 ?_escaped_fragment_=tag 的鏈接。

正當我高興這個問題這么容易解決的時候突然發現網上資料都表示這個方法只有 Google 的爬蟲認可，其他搜索引擎全部沒用！ wtf，白高興一場。

PhantomJS 是一個基于 WebKit 的服務器端 JavaScript API。它全面支持web而不需瀏覽器支持，其快速，原生支持各種Web標準： DOM 處理, CSS 選擇器, JSON, Canvas, 和 SVG。 PhantomJS 可以用于 頁面自動化 ， 網絡監測 ， 網頁截屏 ，以及 無界面測試 等

簡單來說就是 PhantomJS 能在服務端解析HTML、js。

具體怎么使用，簡而言之就是判斷爬蟲來爬取頁面的時候把每個動態頁面先讓 PhantomJS 跑一遍，然后把得到的靜態結果返回給爬蟲，具體過程可以參考：用PhantomJS來給AJAX站點做SEO優化

當然博主看過之后沒用采用自己搭 PhantomJS 服務做動態內容優化，主要因為：

爬蟲每訪問一個頁面就要讓 PhantomJS 渲染一次，相當于爬蟲訪問一次實際服務器要響應兩次，第一次響應爬蟲，第二次響應 PhantomJS 自己，這種方式不僅浪費資源，而且并不優雅；

PhantomJS 對于新的前端技術兼容性會存在問題，可能會出現渲染失敗的情況；

渲染頁面無緩存，每訪問一次就重新渲染一次，會造成網站響應速度變慢。

Prerender.io 是一個基于 PhantomJS 開發的專為動態頁面 SEO 提供靜態頁面渲染的在線服務，基本上解決了自己搭建 PhantomJS 服務所遇到的問題，網站配置 Prerender.io 后 Prerender 將會直接取代網站后端對爬蟲請求進行響應，將提前渲染好的動態頁面直接返回給爬蟲。

具體配置：

注冊 Prerender.io 賬號，免費用戶可以渲染 250 個頁面，對于博客網站來說足夠了；

安裝中間件并設置 token，博主直接采用了 nginx 配置方案，（ Prerender.io 也提供了其他解決方案：https://prerender.io/document... ）博主后端服務器是 uWSGI, 根據 Prerender.io 提供的 nginx.conf 中做如下修改：

server {
    listen 80;
    server_name www.rapospectre.com;
 
    location @prerender {
        proxy_set_header X-Prerender-Token YOUR_TOKEN;
        include        uwsgi_params;
        
        set $prerender 0;
        if ($http_user_agent ~* "baiduspider|twitterbot|facebookexternalhit|rogerbot|linkedinbot|embedly|quora link preview|showyoubot|outbrain|pinterest|slackbot|vkShare|W3C_Validator") {
            set $prerender 1;
        }
        if ($args ~ "_escaped_fragment_") {
            set $prerender 1;
        }
        if ($http_user_agent ~ "Prerender") {
            set $prerender 0;
        }
        if ($uri ~* ".(js|css|xml|less|png|jpg|jpeg|gif|pdf|doc|txt|ico|rss|zip|mp3|rar|exe|wmv|doc|avi|ppt|mpg|mpeg|tif|wav|mov|psd|ai|xls|mp4|m4a|swf|dat|dmg|iso|flv|m4v|torrent|ttf|woff|svg|eot)") {
            set $prerender 0;
        }
        
        #resolve using Google"s DNS server to force DNS resolution and prevent caching of IPs
        resolver 8.8.8.8;
 
        if ($prerender = 1) {
            
            #setting prerender as a variable forces DNS resolution since nginx caches IPs and doesnt play well with load balancing
            set $prerender "service.prerender.io";
            rewrite .* /$scheme://$host$request_uri? break;
            proxy_pass http://$prerender;
        }
        if ($prerender = 0) {
            uwsgi_pass     127.0.0.1:xxxx;
        }
    }
}

然后重啟服務器，通過 Google Search Console 或其他站長工具提交頁面進行爬取檢測，可以看到，Prerender.io 成功截取了爬蟲請求并進行了渲染：

嗯，終于解決了嘛，正當博主感嘆不容易的時候，Google Search Console 的抓取結果卻讓人發現然并卵：

抓取的內容依然是滿滿的 ${ article.views }} 渲染模版，當時我認為應該是網站緩存的問題，所以沒有多想，然而一周后再次測試，情況依舊，回頭再看 Prerender 渲染的網頁：

原來壓根沒起作用！之后又檢查了配置和文檔，嘗試聯系了 Prerender.io 的技術支持甚至向 Prerender 的 Github 提了相關 issue，都沒有解決問題。 最后，不得已博主還是放棄了 Prerender。

Prerender 的方案啟發了我，通過判斷來訪請求的 User-Agent 來讓不同的后端服務器進行響應，雖然網上關于 SEO 優化的討論中明確提到過判斷 UA 返回不同頁面將會得到搜索引擎的懲罰，但我猜測這只是返回不同內容才會懲罰，如果返回的是相同的內容搜索引擎就不會進行懲罰，區別在于一個是直接通過前端渲染的頁面，而另一個則是后端渲染的頁面，兩個頁面渲染出的內容基本相同，那么搜索引擎就不會發現。

自己動手，豐衣足食，有了想法立即驗證，首先把網站代碼中前端渲染的部分改為后端渲染，然后 push 到一個新的分支，博主網站修改十分簡單，大概只修改了 50 行不到的代碼就完成了需求： RaPo3-Shadow

接著將后端渲染代碼部署到服務器，然后假設用 uWSGI 將它跑在 11011 端口，
此時前端渲染的代碼由 uWSGI 假設跑在 11000 端口；

最后修改 nginx 配置文件 nginx.conf：

server {
    listen 80;
    server_name www.rapospectre.com;
 
    location @prerender {
        include        uwsgi_params;
        
        set $prerender 0;
        if ($http_user_agent ~* "baiduspider|twitterbot|facebookexternalhit|rogerbot|linkedinbot|embedly|quora link preview|showyoubot|outbrain|pinterest|slackbot|vkShare|W3C_Validator") {
            set $prerender 1;
        }
        #resolve using Google"s DNS server to force DNS resolution and prevent caching of IPs
        resolver 8.8.8.8;
 
        if ($prerender = 1) {
            uwsgi_pass     127.0.0.1:11011;
        }
        if ($prerender = 0) {
            uwsgi_pass     127.0.0.1:11000;
        }
    }
}

就是通過 UA 判斷爬蟲，如果是則轉發給 11011 端口，不是就轉發給 11000 端口，當然兩個端口返回的頁面基本是相同的，所以也就不用擔心會被搜索引擎懲罰了。

通過以上配置后，動態頁面的 SEO 問題終于得到了解決，反應最快的是 Google，第二天就爬取并更新到了搜索引擎：

接著 360 搜索：

然后其他沒有提交過網址的搜索引擎也分分收錄了網站：

（ bing 沒有收錄正常的頁面應該是由于 nginx.conf 里沒有加入 bing 爬蟲 UA 的緣故 ）

當然，不知道什么原因百度過了兩個多月還是沒有收錄，在站長工具中提交網頁甚至申訴都沒有收錄新的網頁。沒錯，開頭那個用來應付一下的圖片就是百度的結果，剛截的。

我該說幸好沒更新，否則找不到以前的例子了嘛，哈哈哈哈。

通過博主自己搭建后端渲染服務已經解決了動態頁面 SEO 優化問題，但博主還有一個可行辦法的猜想，不知是否可行，寫在這里如果看了以上辦法都不好用的朋友可以試試。

canonical 標簽是 Google 、雅虎、微軟等搜索引擎一起推出的一個標簽，它的主要作用是用來解決由于網址形式不同內容相同而造成的內容重復問題。 這個標簽的制定時間已經很久了，所以現在主流的搜索引擎都支持這個標簽，它原本的作用是將 url 不同但內容相同的網址權重全部集中到其中一個網址上，這樣可以避免大量重復內容網頁被搜索引擎收錄，舉個例子：

http://www.rapospectre.com/archives/1
http://www.rapospectre.com/archives/1?comments=true
http://www.rapospectre.com/archives/1?postcomment=true

這三個網址的內容其實完全一樣，為了避免重復收錄和分權，在原始網頁加上 這樣其他重復網頁將被看作都是 http://www.rapospectre.com/archives/1

那么假設對于動態網頁 http://www.rapospectre.com/dynamic/1，我們編寫他的靜態網頁：http://www.rapospectre.com/static/1, 然后在 http://www.rapospectre.com/dynamic/1 的頁面內加入：