在過去的幾年里风题，搜索引擎的影響力發(fā)生了一些變化——其影響力的趨勢(shì)是逐漸變?nèi)踵叶蟆?yīng)用程序已經(jīng)變成了流量的一個(gè)大入口宙橱，當(dāng)然搜索引擎也還是一個(gè)大的入口捻悯。搜索引擎優(yōu)化看上去并沒有那么重要，企業(yè)靠活動(dòng)鸟赫、運(yùn)營來挖掘新的用戶蒜胖。可當(dāng)所有的人不重視抛蚤，而我們重視的時(shí)候台谢，那么這個(gè)流量入口就是我們的天下。
自打我開始寫博客起（大概是在 2011 年左右）岁经，便開始研究搜索引擎優(yōu)化（Search Engine Optimization）朋沮。這項(xiàng)看似不重要的技術(shù)，卻為我的博客帶來 了大量的流量蒿偎。
工作之后，我才發(fā)現(xiàn)這是一門大生意——為了排在搜索引擎靠前的位置怀读，每個(gè)網(wǎng)站每天都在不斷的送錢給 Google诉位、百度、Bing 等搜索引擎公司菜枷。當(dāng)我們?cè)?Google苍糠、百度上點(diǎn)擊一下，首頁上的某個(gè)推廣鏈接啤誊，可能就會(huì)為它們帶去幾十美刀的收入岳瞭。要是能競(jìng)爭(zhēng)到此，那說明這個(gè)行業(yè)相當(dāng)?shù)馁嶅X蚊锹。同時(shí)瞳筏，處在這個(gè)行業(yè)的人吶也越來越不賺錢了——他們都把錢交給了科技公司了。
搜索引擎優(yōu)化都是前端的活
如我們?cè)谝岳锼f的牡昆，搜索引擎的流量在逐漸地減弱姚炕，但是這幾乎是一種一勞永逸的方式。只需要制定一個(gè)合理的 SEO 策略丢烘，再瞧瞧看競(jìng)爭(zhēng)對(duì)手的規(guī)則柱宦、用戶的習(xí)慣等等。我們就可以坐等：用戶從搜索引擎來到我們的網(wǎng)站播瞳。隨后的日子里掸刊，只需要跟蹤用戶行為的變化，再做出一些適當(dāng)?shù)母淖兗纯伞?/p>
在決定玩搜索引擎優(yōu)化之前赢乓，我們?nèi)匀坏门袛嗍遣皇切枰阉饕鎯?yōu)化忧侧。對(duì)于那些網(wǎng)站流量依賴于搜索引擎的網(wǎng)站來說石窑，搜索引擎優(yōu)化必要的，這樣的網(wǎng)站有以內(nèi)容為主的網(wǎng)站苍柏，如各種博客尼斧、知識(shí)問題類網(wǎng)站，網(wǎng)站的主要功能也是搜索的網(wǎng)站试吁，如各種手機(jī)棺棵、電腦、房產(chǎn)網(wǎng)站等等熄捍。而對(duì)于大到一定體量的網(wǎng)站——用戶已經(jīng)有這個(gè)品牌意識(shí)的時(shí)候烛恤，他們對(duì)沒有多大必要進(jìn)行搜索引擎優(yōu)化，而是更關(guān)注于如何提高用戶體驗(yàn)余耽。
當(dāng)我們決定為網(wǎng)站進(jìn)行搜索引擎優(yōu)先的時(shí)候缚柏，需要執(zhí)行一系列相關(guān)的調(diào)查、設(shè)計(jì)碟贾，并著手開始修改代碼币喧，上線，隨后再分析線上的情況袱耽，不斷的改進(jìn)系統(tǒng)杀餐。系統(tǒng)以一種精益的模式在運(yùn)行著：
而完成這部分的主要工作，都是在前端的頁面模板上朱巨。而在那之前史翘，我們得保證：我們的 Web 應(yīng)用可以支持后臺(tái)渲染。
如果當(dāng)前的單頁面應(yīng)用不支持后臺(tái)渲染冀续，可以參考我之前寫的文章《單頁面應(yīng)用后臺(tái)渲染的三次實(shí)踐》來完善后臺(tái)渲染的機(jī)制琼讽。
作為一個(gè)前端工程師，我們需要做一系列的工作：
- 設(shè)置好 HTML 中的 Title洪唐、URL钻蹬、Keywords、Description
- 頁面中的內(nèi)容是否可以正常顯示凭需。如果內(nèi)容是動(dòng)態(tài)生成的脉让，那么整個(gè)系統(tǒng)對(duì)于搜索引擎的體驗(yàn)將會(huì)特別。盡管 Google 可以動(dòng)態(tài)的渲染頁面功炮，但是仍然會(huì)有一些影響溅潜。
- 頁面的內(nèi)容是否以推薦的 HTML 標(biāo)簽寫的。如只有一個(gè) H1 用于作內(nèi)容的標(biāo)題薪伏，多個(gè) H1 標(biāo)簽可能會(huì)造成和 Title 不一致滚澜，導(dǎo)致顯示在搜索引擎上的結(jié)果有誤。
- 頁面中的內(nèi)鏈?zhǔn)欠穹峙涞煤侠砑藁场ｍ撁嬷惺遣皇菚?huì)有指向重要頁面的鏈接设捐，如首頁借浊∷檗啵或者每個(gè)分類的詳情頁都會(huì)有鏈接夷狰，并鏈接到列表頁。這樣一來畔派，列表頁的排名就會(huì)比較高槐沼。
- 判斷頁面中的外鏈?zhǔn)欠裥枰?nofollow 標(biāo)簽曙蒸。
- 檢查頁面中的
- 如果有獨(dú)立的移動(dòng)站點(diǎn)，要檢測(cè)一下岗钩，是不是需要 rel="canonical" 來表明他們的關(guān)系纽窟。
- 是否需要采用 rel="next" 和 rel="preve" 來指明頁面間的關(guān)系，以讓第一頁擁有較高的排名兼吓。同時(shí)還能為瀏覽器開啟 Prefetch 功能臂港。
- 等等
我們需要做的活有一大堆。不過视搏，考慮到這不是一本詳細(xì)的 SEO 書籍审孽，我們將關(guān)注于基礎(chǔ)的部分：設(shè)置好 HTML 中的 Title、URL浑娜、Keywords佑力、Description。
如何設(shè)計(jì)一個(gè)高質(zhì)量的 URL
今天棚愤，很多網(wǎng)站的 URL 的設(shè)計(jì)都是有問題的搓萧。它們看起來一塌糊涂杂数，仿佛是被人洗掉的臟數(shù)據(jù)一樣宛畦，沒有經(jīng)過設(shè)計(jì)，沒有經(jīng)過思考揍移。他們一點(diǎn)都不適合閱讀次和，也不利于搜索引擎優(yōu)化。
剛開始寫博客的時(shí)候那伐，我從來不會(huì)想著去自定義一個(gè) URL踏施。想好一個(gè)標(biāo)題，沒有敲好內(nèi)容就直接提交了罕邀，可這個(gè)時(shí)候生成的 URL 總是很詭異畅形。當(dāng)我們?nèi)ピO(shè)計(jì)一個(gè)博客的時(shí)候，URL 是一個(gè)頭疼的問題诉探。設(shè)計(jì)之下日熬，每個(gè)人選擇的方案都有所不同：
- 直接使用博客的 ID，如 /blog/123肾胯，即省事又方便
- 自動(dòng)生成 URL
- 將標(biāo)題轉(zhuǎn)換為拼音或者英語單詞竖席，如 blog/ruhe-sheji-yige-gaozhilang-de-url
- 根據(jù)日期和 ID 生成耘纱，諸如 blog/2017/02/123
- 等等
- 自定義 URL，諸如 blog/how-to-design-a-high-quality-url毕荐。如果要考慮到一些推薦的 URL 設(shè)計(jì)原因束析，如介詞，這個(gè) URL 應(yīng)該變成 howto-design-hight-quality-url憎亚。
也因此员寇，我們會(huì)發(fā)現(xiàn)大部分的架構(gòu)設(shè)計(jì)里，都忽略了對(duì) URL 的設(shè)計(jì)——只是為了更加方便的使用 RESTful虽填。
受 RESTful API 影響 的 URL 設(shè)計(jì)
依據(jù) RESTful API 原則丁恭，我們?cè)O(shè)計(jì)出來的 API 的 URL 都會(huì)有這樣的缺陷。如下是 RESTful API 設(shè)計(jì)的一個(gè)簡(jiǎn)單的實(shí)例：
| 動(dòng)作 | URL | 行為 |
|---|---|---|
| GET | /blog | 獲取所有的文章（PS：實(shí)踐的時(shí)候斋日，通常會(huì)采用分頁機(jī)制） |
| GET | /blog/:id | 獲取某一個(gè)具體的文章 |
| PUT | /blog/:id | 更新某一個(gè)具體的文章 |
| POST | /blog | 創(chuàng)建一個(gè)新的文章 |
| DELETE | /blog/:id | 刪除某一個(gè)具體的文章 |
最后牲览，我們?cè)O(shè)計(jì)出來的文章地址，可能就是 blog/123恶守，又或者是 blog/58c286d7ac502e0062d7c84e第献。因?yàn)椋覀兪且罁?jù)這個(gè) ID 到數(shù)據(jù)庫去操作（CRUD）相應(yīng)的值兔港。ID 本身是自增的庸毫，并且是唯一的，所以這種設(shè)計(jì)因此就比較簡(jiǎn)單了衫樊。因此飒赃，我們到數(shù)據(jù)去查詢的時(shí)候，我們只需要where id="123"即可科侈。
可是對(duì)于一個(gè)博客來說载佳，每個(gè)博客的鏈接都是唯一的。因此臀栈，我們?nèi)匀豢梢允褂胉`where slug="how-to-design-a-high-quality-url"蔫慧。
于是，自定義 URL 就是其中的一種形式权薯。
手動(dòng)自定義 URL
與 URL 相比姑躲，ID 本身是不如記的。如我的專欄《我的職業(yè)是前端工程師》 的豆瓣上的鏈接是：https://read.douban.com/column/5945187/ 盟蚣，而在知乎上則是 https://zhuanlan.zhihu.com/beafe黍析。試問一下，如果要記下來的話屎开，哪個(gè)更輕松阐枣？
以我的博客為例，正常的 URL 是這樣的，https://www.phodal.com/blog/use-jenkinsfile-blue-ocean-visualization-pipeline/侮繁，對(duì)應(yīng)的標(biāo)題是：Jenkins 2.0 里使用 Jenkinsfile 設(shè)計(jì)更好的 Pipeline虑粥，這種設(shè)計(jì)本身可以將關(guān)鍵詞融入 URL ，就更容易換得一個(gè)好的排名：
這里的 use-jenkinsfile-blue-ocean-visualization-pipeline 就是優(yōu)化的部分宪哩。而為了設(shè)計(jì)方便娩贷，大部分的博客都會(huì)將 URL 設(shè)計(jì)成 /blog/123。結(jié)果便是锁孟，當(dāng)用戶搜索 jenkinsfile 和 pipline 時(shí)彬祖，就出現(xiàn)了一些劣勢(shì)。
對(duì)應(yīng)的品抽，使用漢字搜索為主的中文網(wǎng)站來說储笑，使用 wo-de-zhiye-shi-qianduan-gongchenshi 可能是一種更不錯(cuò)的選擇。我們只需要使用一些分詞庫圆恤，就可以生成對(duì)應(yīng)的中文拼音 URL突倍。
當(dāng)我們有大量的商品的時(shí)候，手動(dòng)定義可能會(huì)讓人有些厭煩盆昙。于是我們應(yīng)該定義一些規(guī)則羽历，然后生成相對(duì)應(yīng)的 URL。
詳情頁 ：簡(jiǎn)單的 URL 生成規(guī)則
考慮到手動(dòng)生成的難度淡喜，以及一些 RESTful 設(shè)計(jì)的風(fēng)格問題秕磷，我們可以考慮結(jié)合他們的形式，諸如：
| 動(dòng)作 | URL | 行為 |
|---|---|---|
| GET | /blog/:id/:blog-slug | 獲取某一個(gè)具體的文章 |
是的炼团，只需要改進(jìn)一下 URL 生成的規(guī)則就可以了澎嚣。StackOverflow 采用的就是這種設(shè)計(jì)，當(dāng)我們從 Google 訪問一個(gè) URL 的時(shí)候瘟芝，我們?cè)L問的地址便是：questions/:question-id/:question-slug 這種形式易桃，其中的 id 和 slug 都是自動(dòng)生成的，如：
questions/20381976/rest-api-design-getting-a-resource-through-rest-with-different-parameters-but
而當(dāng)我們使用 question/:question-id 的形式訪問時(shí)模狭，諸如 questions/20381976颈抚，就會(huì)被永久重定向到上面的帶 slug 的地址踩衩。
與手動(dòng)相比嚼鹉，使用這種方式，即可以保證 URL 的質(zhì)量驱富，又可以減輕后臺(tái)的負(fù)擔(dān)——我們不根據(jù) URL 來獲取數(shù)據(jù)锚赤，我們?nèi)匀皇褂?ID 來獲取數(shù)據(jù)，仍然可以對(duì)數(shù)據(jù)進(jìn)行緩存褐鸥。
而 RESTful 原則主要解決的問題是：對(duì)于資源的分類线脚。，我們就需要一些更高級(jí)的 URL 設(shè)計(jì)。
自動(dòng)化 URL：分類與多級(jí)目錄
假使我們的網(wǎng)站上擁有大量的商品時(shí)浑侥，那么我們采用 RESTful 來描述資源時(shí)姊舵，這個(gè)時(shí)候路徑可能就會(huì)變成這樣：
/markets/3c/sj/meizu/meizu-mx5
如果不考慮搜索引擎優(yōu)化，這個(gè) URL 本身是沒有什么毛病的寓落，除了：分類有點(diǎn)多括丁。
分類多對(duì)于 SEO 來說，主要問題就是伶选，Page Rank 會(huì)被分配到不同的分類上史飞，而導(dǎo)致當(dāng)前頁面的 Page Rank 比較低。因而仰税，對(duì)于不同的網(wǎng)站來說可能有不同的策略需求构资。有的網(wǎng)站可能需要主目錄的 Rank 比較高，有的網(wǎng)站則需要詳情頁的 Rank 值比較高陨簇，因此也沒有一個(gè)好的定論：
- 如果希望詳情頁的 Rank 比較高吐绵，那么應(yīng)該減少分類
- 如果需要分類的 Rank 比較高，那么這樣設(shè)計(jì)就是合理的
搜索結(jié)果頁：將參數(shù)融入 URL
在上面的例子中河绽，因?yàn)椴┛投际俏ㄒ坏睦乖砸渲靡粋€(gè)唯一的參數(shù)都是比較簡(jiǎn)單的。當(dāng)我們需要搜索結(jié)果時(shí)葵姥，情況就變得有些復(fù)雜——我們需要搜索和過濾荷鼠。
對(duì)于一個(gè)使用 RESTful API 表示的搜索結(jié)果頁，我們會(huì)這樣去配置它的 URL：
http://www.xxx.com/search/?q={keyword}&page={page}&size={size}
然后榔幸，再我們的 Link Header 里指定下一頁的結(jié)果就可以了允乐。這樣的 API 設(shè)計(jì)看上去，非常適合我們的場(chǎng)景削咆。用戶在篩選條件里選好想要的條件牍疏，再填入關(guān)鍵詞就可以了。
現(xiàn)在讓我們來假設(shè)一種用戶場(chǎng)景拨齐，我們想搜索一個(gè) 100~150 元左右的 移動(dòng)電源鳞陨，并且它還是深圳產(chǎn)的。這個(gè)時(shí)候瞻惋，網(wǎng)頁返回的 URL 可能就是：
search/?minPrice=100&maxPrice=150&product=powerbank&location=shenzhen&page=1
這個(gè)時(shí)候索引的結(jié)果厦滤，可就失去了分類的意義了。于是歼狼，我們需要一個(gè)更好的 URL掏导，諸如：
product/powerbank/?minPrice=100&maxPrice=150&location=shenzhen&location=shenzhen
那么，對(duì)于 URL 索引的 Rank 將會(huì)加給 powerbank羽峰，點(diǎn)擊量 + 頁面數(shù)量可以讓它有一個(gè)好的排名：
當(dāng)然諸如淘寶趟咆、京東這樣的網(wǎng)站就不需要這么做了添瓷，他們對(duì)于 SEO 的需求沒有這么強(qiáng)烈——因?yàn)橐诎俣壬吓艂€(gè)好名，可不止 SEO 的事了值纱。
而如果我們?cè)敢獾脑捔鄞€可以將參數(shù)融入到 URL 中，powerbank/range-100-150-city-shenzhen/page-1虐唠。這樣悄晃，不止移動(dòng)電源上有一個(gè)好的排名，100~150 元的移動(dòng)電源也可以有一個(gè)好的排名凿滤。這時(shí)候妈橄，我們需要使用正則來匹配這些規(guī)則，一個(gè)簡(jiǎn)單的示例(\S+)-range-(\d+)-(\d+)-city-(\S+)翁脆，匹配結(jié)果如下：
但是眷蚓，不管怎樣這些參數(shù)帶來的影響，都是相當(dāng)微弱的反番。正在要做好的是網(wǎng)站本身沙热，以及相關(guān)的站點(diǎn)結(jié)構(gòu)設(shè)計(jì)、網(wǎng)站內(nèi)容罢缸。
自動(dòng)生成高質(zhì)量的站點(diǎn)標(biāo)題
什么是站點(diǎn)標(biāo)題篙贸？
就是我們?cè)谒阉鹘Y(jié)果頁看到的那個(gè)標(biāo)題。
如上圖所示的結(jié)果枫疆，是我用 Google 搜索：“程序員如何提高影響力”得到的結(jié)果爵川。對(duì)應(yīng)的第一個(gè)鏈接的，如何提高影響力- Phodal | Phodal - A Growth Engineer 就是我博客的站點(diǎn)標(biāo)題息楔。對(duì)應(yīng)在 HTML 中就是 title 標(biāo)題：
什么才算一個(gè)高質(zhì)量的站點(diǎn)標(biāo)題寝贡？
這是一個(gè)很趣的問題。我想應(yīng)該是在標(biāo)題里值依，帶有我想要的信息吧圃泡。對(duì)于一篇博客來說，我可能想看到的內(nèi)容有：文章的標(biāo)題愿险，站點(diǎn)的簡(jiǎn)單介紹颇蜡，誰的網(wǎng)站等等的內(nèi)容。
如上圖中的我的博客的標(biāo)題辆亏，就是一個(gè)不錯(cuò)的示例风秤。標(biāo)題里帶有：文章的標(biāo)題，作者名褒链、站點(diǎn)名唁情、站點(diǎn)簡(jiǎn)介疑苔，即：文章標(biāo)題 - 作者名 | 站點(diǎn)名 - 站點(diǎn)簡(jiǎn)介甫匹。上圖中的 SegmentFault 的標(biāo)題也相當(dāng)?shù)牟诲e(cuò)，文章標(biāo)題 - 專欄標(biāo)題 - 站點(diǎn)名。而知乎的專欄兵迅，就沒有那么有趣了：程序員如何提高影響力2.0 - 知乎專欄抢韭。
有了上面的例子之后，要完成一個(gè)相似的站點(diǎn)標(biāo)題就更添加容易了：即將產(chǎn)品的相關(guān)信息帶入到標(biāo)題里恍箭。上面的例子中的 Title 看上去都有點(diǎn)生硬刻恭，如果我們?cè)敢獾脑挘覀円部梢詫?duì)其進(jìn)行優(yōu)化扯夭。
該說的我們都說了鳍贾，最后再來說說為什么吧。如下是 Google 搜索結(jié)果中的用戶熱圖：
盡管發(fā)生了一些變化交洗，但是我們會(huì)發(fā)現(xiàn)：用戶仍然集中注意力在左側(cè)區(qū)域骑科，即文章的標(biāo)題部分。也就是說构拳，我們應(yīng)該將標(biāo)題放在最左邊咆爽，而與搜索無關(guān)的網(wǎng)站信息放在最右邊。
所以置森，標(biāo)題的形式應(yīng)該是：文章標(biāo)題 - 各種相關(guān)信息斗埂。由于 Title 標(biāo)簽擁有比較重要的作用，所以在不影響讀者閱讀的時(shí)候凫海，應(yīng)該盡可能地把相關(guān)的信息放進(jìn)去呛凶。
