這樣去設計 URL,可以提高網站的訪問量

ADVERTISEMENT

今天,很多網站的 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 原則,我們設計出來的 API 的 URL 都會有這樣的缺陷。如下是 RESTful API 設計的一個簡單的例項:

可是對於一個部落格來說,每個部落格的連結都是唯一的。因此,我們仍然可以使用``where slug="how-to-design-a-high-quality-url"。最後,我們設計出來的文章地址,可能就是 blog/123,又或者是 blog/58c286d7ac502e0062d7c84e。

因為,我們是依據這個 ID 到資料庫去操作(CRUD)相應的值。ID 本身是自增的,並且是唯一的,所以這種設計因此就比較簡單了。因此,我們到資料去查詢的時候,我們隻需要

ADVERTISEMENT

where id="123"

即可。

與 URL 相比,ID 本身是不如記的。如我的專欄《我的職業是前端工程師》 的豆瓣上的連結是: ,而在知乎上則是 。試問一下,如果要記下來的話,哪個更輕鬆?

以我的部落格為例,正常的 URL 是這樣的,,對應的標題是:Jenkins 2.0 裡使用 Jenkinsfile 設計更好的 Pipeline,這種設計本身可以將關鍵詞融入 URL ,就更容易換得一個好的排名:

這裡的 use-jenkinsfile-blue-ocean-visualization-pipeline 就是優化的部分。而為了設計方便,大部分的部落格都會將 URL 設計成 /blog/123。結果便是,當使用者搜尋 jenkinsfile 和 pipline 時,就出現了一些劣勢。

對應的,使用漢字搜尋為主的中文網站來說,使用 wo-de-zhiye-shi-qianduan-gongchenshi 可能是一種更不錯的選擇。我們隻需要使用一些分詞庫,就可以生成對應的中文拚音 URL。

當我們有大量的商品的時候,手動定義可能會讓人有些厭煩。於是我們應該定義一些規則,然後生成相對應的 URL。

詳情頁 :簡單的 URL 生成規則

考慮到手動生成的難度,以及一些 RESTful 設計的風格問題,我們可以考慮結合他們的形式,諸如:

動作

URL

行為

ADVERTISEMENT

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 值比較高,因此也沒有一個好的定論:

ADVERTISEMENT

如果希望詳情頁的 Rank 比較高,那麼應該減少分類

如果需要分類的 Rank 比較高,那麼這樣設計就是合理的

在上面的例子中,因為部落格都是唯一的,所以要配置一個唯一的參數都是比較簡單的。當我們需要搜尋結果時,情況就變得有些複雜——我們需要搜尋和過濾。

對於一個使用 RESTful API 表示的搜尋結果頁,我們會這樣去配置它的 URL:

然後,再我們的 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+),匹配結果如下:

但是,不管怎樣這些參數帶來的影響,都是相當微弱的。正在要做好的是網站本身,以及相關的站點結構設計、網站內容。

你說呢?

» Phodal

ADVERTISEMENT