SEO 技巧，如何設計一個高質量的 URL 和標題
在過去的幾年裡，搜尋引擎的影響力發生了一些變化——其影響力的趨勢是逐漸變弱。應用程式已經變成了流量的一個大入口，當然搜尋引擎也還是一個大的入口。搜尋引擎優化看上去並沒有那麼重要，企業靠活動、運營來挖掘新的使用者。可當所有的人不重視，而我們重視的時候，那麼這個流量入口就是我們的天下。
自打我開始寫部落格起（大概是在 2011 年左右），便開始研究搜尋引擎優化（Search Engine Optimization）。這項看似不重要的技術，卻為我的部落格帶來 了大量的流量。
工作之後，我才發現這是一門大生意——為了排在搜尋引擎靠前的位置，每個網站每天都在不斷的送錢給 Google、百度、Bing 等搜尋引擎公司。當我們在 Google、百度上點選一下，首頁上的某個推廣連結，可能就會為它們帶去幾十美刀的收入。要是能競爭到此，那說明這個行業相當的賺錢。同時，處在這個行業的人吶也越來越不賺錢了——他們都把錢交給了科技公司了。
搜尋引擎優化都是前端的活
如我們在引言裡所說的，搜尋引擎的流量在逐漸地減弱，但是這幾乎是一種一勞永逸的方式。只需要制定一個合理的 SEO 策略，再瞧瞧看競爭對手的規則、使用者的習慣等等。我們就可以坐等：使用者從搜尋引擎來到我們的網站。隨後的日子裡，只需要跟蹤使用者行為的變化，再做出一些適當的改變即可。
在決定玩搜尋引擎優化之前，我們仍然得判斷是不是需要搜尋引擎優化。對於那些網站流量依賴於搜尋引擎的網站來說，搜尋引擎優化必要的，這樣的網站有以內容為主的網站，如各種部落格、知識問題類網站，網站的主要功能也是搜尋的網站，如各種手機、電腦、房產網站等等。而對於大到一定體量的網站——使用者已經有這個品牌意識的時候，他們對沒有多大必要進行搜尋引擎優化，而是更關注於如何提高使用者體驗。
當我們決定為網站進行搜尋引擎優先的時候，需要執行一系列相關的調查、設計，並著手開始修改程式碼，上線，隨後再分析線上的情況，不斷的改進系統。系統以一種精益的模式在執行著：
而完成這部分的主要工作，都是在前端的頁面模板上。而在那之前，我們得保證：我們的 Web 應用可以支援後臺渲染。
如果當前的單頁面應用不支援後臺渲染，可以參考我之前寫的文章《單頁面應用後臺渲染的三次實踐》來完善後臺渲染的機制。
作為一個前端工程師，我們需要做一系列的工作：
- 設定好 HTML 中的 Title、URL、Keywords、Description
- 頁面中的內容是否可以正常顯示。如果內容是動態生成的，那麼整個系統對於搜尋引擎的體驗將會特別。儘管 Google 可以動態的渲染頁面，但是仍然會有一些影響。
- 頁面的內容是否以推薦的 HTML 標籤寫的。如只有一個 H1 用於作內容的標題，多個 H1 標籤可能會造成和 Title 不一致，導致顯示在搜尋引擎上的結果有誤。
- 頁面中的內鏈是否分配得合理。頁面中是不是會有指向重要頁面的連結，如首頁。或者每個分類的詳情頁都會有連結，並連結到列表頁。這樣一來，列表頁的排名就會比較高。
- 判斷頁面中的外鏈是否需要 nofollow 標籤。
- 檢查頁面中的
- 如果有獨立的移動站點，要檢測一下，是不是需要 rel="canonical" 來表明他們的關係。
- 是否需要採用 rel="next" 和 rel="preve" 來指明頁面間的關係，以讓第一頁擁有較高的排名。同時還能為瀏覽器開啟 Prefetch 功能。
- 等等
我們需要做的活有一大堆。不過，考慮到這不是一本詳細的 SEO 書籍，我們將關注於基礎的部分：設定好 HTML 中的 Title、URL、Keywords、Description。
如何設計一個高質量的 URL
今天，很多網站的 URL 的設計都是有問題的。它們看起來一塌糊塗，彷彿是被人洗掉的髒資料一樣，沒有經過設計，沒有經過思考。他們一點都不適合閱讀，也不利於搜尋引擎優化。
剛開始寫部落格的時候，我從來不會想著去自定義一個 URL。想好一個標題，沒有敲好內容就直接提交了，可這個時候生成的 URL 總是很詭異。當我們去設計一個部落格的時候，URL 是一個頭疼的問題。設計之下，每個人選擇的方案都有所不同：
- 直接使用部落格的 ID，如 /blog/123，即省事又方便
- 自動生成 URL
- 將標題轉換為拼音或者英語單詞，如 blog/ruhe-sheji-yige-gaozhilang-de-url
- 根據日期和 ID 生成，諸如 blog/2017/02/123
- 等等
- 自定義 URL，諸如 blog/how-to-design-a-high-quality-url。如果要考慮到一些推薦的 URL 設計原因，如介詞，這個 URL 應該變成 howto-design-hight-quality-url。
也因此，我們會發現大部分的架構設計裡，都忽略了對 URL 的設計——只是為了更加方便的使用 RESTful。
受 RESTful API 影響 的 URL 設計
依據 RESTful API 原則，我們設計出來的 API 的 URL 都會有這樣的缺陷。如下是 RESTful API 設計的一個簡單的例項：
可是對於一個部落格來說，每個部落格的連結都是唯一的。因此，我們仍然可以使用``where slug="how-to-design-a-high-quality-url"。最後，我們設計出來的文章地址，可能就是 blog/123，又或者是 blog/58c286d7ac502e0062d7c84e。因為，我們是依據這個 ID 到資料庫去操作（CRUD）相應的值。ID 本身是自增的，並且是唯一的，所以這種設計因此就比較簡單了。因此，我們到資料去查詢的時候，我們只需要where id="123"即可。
於是，自定義 URL 就是其中的一種形式。
手動自定義 URL
與 URL 相比，ID 本身是不如記的。如我的專欄《我的職業是前端工程師》 的豆瓣上的連結是：我的職業是前端工程師 ，而在知乎上則是 我的職業是前端工程師 - 知乎專欄。試問一下，如果要記下來的話，哪個更輕鬆？
這裡的 use-jenkinsfile-blue-ocean-visualization-pipeline 就是優化的部分。而為了設計方便，大部分的部落格都會將 URL 設計成 /blog/123。結果便是，當用戶搜尋 jenkinsfile 和 pipline 時，就出現了一些劣勢。
對應的，使用漢字搜尋為主的中文網站來說，使用 wo-de-zhiye-shi-qianduan-gongchenshi 可能是一種更不錯的選擇。我們只需要使用一些分詞庫，就可以生成對應的中文拼音 URL。
當我們有大量的商品的時候，手動定義可能會讓人有些厭煩。於是我們應該定義一些規則，然後生成相對應的 URL。
詳情頁 ：簡單的 URL 生成規則
考慮到手動生成的難度，以及一些 RESTful 設計的風格問題，我們可以考慮結合他們的形式，諸如：
動作URL行為GET/blog/:id/:blog-slug獲取某一個具體的文章是的，只需要改進一下 URL 生成的規則就可以了。StackOverflow 採用的就是這種設計，當我們從 Google 訪問一個 URL 的時候，我們訪問的地址便是：questions/:question-id/:question-slug 這種形式，其中的 id 和 slug 都是自動生成的，如：
questions/20381976/rest-api-design-getting-a-resource-through-rest-with-different-parameters-but
而當我們使用 question/:question-id 的形式訪問時，諸如 questions/20381976，就會被永久重定向到上面的帶 slug 的地址。
與手動相比，使用這種方式，即可以保證 URL 的質量，又可以減輕後臺的負擔——我們不根據 URL 來獲取資料，我們仍然使用 ID 來獲取資料，仍然可以對資料進行快取。
而 RESTful 原則主要解決的問題是：對於資源的分類。，我們就需要一些更高階的 URL 設計。
自動化 URL：分類與多級目錄
假使我們的網站上擁有大量的商品時，那麼我們採用 RESTful 來描述資源時，這個時候路徑可能就會變成這樣：
/markets/3c/sj/meizu/meizu-mx5
如果不考慮搜尋引擎優化，這個 URL 本身是沒有什麼毛病的，除了：分類有點多。
分類多對於 SEO 來說，主要問題就是，Page Rank 會被分配到不同的分類上，而導致當前頁面的 Page Rank 比較低。因而，對於不同的網站來說可能有不同的策略需求。有的網站可能需要主目錄的 Rank 比較高，有的網站則需要詳情頁的 Rank 值比較高，因此也沒有一個好的定論：
- 如果希望詳情頁的 Rank 比較高，那麼應該減少分類
- 如果需要分類的 Rank 比較高，那麼這樣設計就是合理的
搜尋結果頁：將引數融入 URL
在上面的例子中，因為部落格都是唯一的，所以要配置一個唯一的引數都是比較簡單的。當我們需要搜尋結果時，情況就變得有些複雜——我們需要搜尋和過濾。
對於一個使用 RESTful API 表示的搜尋結果頁，我們會這樣去配置它的 URL：
http://www.xxx.com/search/?q={keyword}&page={page}&size={size}
然後，再我們的 Link Header 裡指定下一頁的結果就可以了。這樣的 API 設計看上去，非常適合我們的場景。使用者在篩選條件裡選好想要的條件，再填入關鍵詞就可以了。
現在讓我們來假設一種使用者場景，我們想搜尋一個 100~150 元左右的 移動電源，並且它還是深圳產的。這個時候，網頁返回的 URL 可能就是：
search/?minPrice=100&maxPrice=150&product=powerbank&location=shenzhen&page=1
這個時候索引的結果，可就失去了分類的意義了。於是，我們需要一個更好的 URL，諸如：
product/powerbank/?minPrice=100&maxPrice=150&location=shenzhen&location=shenzhen
那麼，對於 URL 索引的 Rank 將會加給 powerbank，點選量 + 頁面數量可以讓它有一個好的排名：
當然諸如淘寶、京東這樣的網站就不需要這麼做了，他們對於 SEO 的需求沒有這麼強烈——因為要在百度上排個好名，可不止 SEO 的事了。
而如果我們願意的話，還可以將引數融入到 URL 中，powerbank/range-100-150-city-shenzhen/page-1。這樣，不止移動電源上有一個好的排名，100~150 元的移動電源也可以有一個好的排名。這時候，我們需要使用正則來匹配這些規則，一個簡單的示例(\S+)-range-(\d+)-(\d+)-city-(\S+)，匹配結果如下：
但是，不管怎樣這些引數帶來的影響，都是相當微弱的。正在要做好的是網站本身，以及相關的站點結構設計、網站內容。
自動生成高質量的站點標題
什麼是站點標題？
就是我們在搜尋結果頁看到的那個標題。
如上圖所示的結果，是我用 Google 搜尋：“程式設計師如何提高影響力”得到的結果。對應的第一個連結的，如何提高影響力- Phodal | Phodal - A Growth Engineer 就是我部落格的站點標題。對應在 HTML 中就是 title 標題：
什麼才算一個高質量的站點標題？
這是一個很趣的問題。我想應該是在標題裡，帶有我想要的資訊吧。對於一篇部落格來說，我可能想看到的內容有：文章的標題，站點的簡單介紹，誰的網站等等的內容。
如上圖中的我的部落格的標題，就是一個不錯的示例。標題裡帶有：文章的標題，作者名、站點名、站點簡介，即：文章標題 - 作者名 | 站點名 - 站點簡介。上圖中的 SegmentFault 的標題也相當的不錯，文章標題 - 專欄標題 - 站點名。而知乎的專欄，就沒有那麼有趣了：程式設計師如何提高影響力2.0 - 知乎專欄。
有了上面的例子之後，要完成一個相似的站點標題就更新增容易了：即將產品的相關資訊帶入到標題裡。上面的例子中的 Title 看上去都有點生硬，如果我們願意的話，我們也可以對其進行優化。
該說的我們都說了，最後再來說說為什麼吧。如下是 Google 搜尋結果中的使用者熱圖：
儘管發生了一些變化，但是我們會發現：使用者仍然集中注意力在左側區域，即文章的標題部分。也就是說，我們應該將標題放在最左邊，而與搜尋無關的網站資訊放在最右邊。
所以，標題的形式應該是：文章標題 - 各種相關資訊。由於 Title 標籤擁有比較重要的作用，所以在不影響讀者閱讀的時候，應該儘可能地把相關的資訊放進去。
長按圖片識別圖中二維碼(或搜尋微信公眾號FrontEndStory)關注“前端那些事兒”，帶你探索前端的奧祕。
