用產品的思維去做SEO
分享
評論
贊0
最近和朋友聊天，我們都感到SEO行業(yè)有個很致命的問題，就是沒有一個固定的規(guī)范和標準。不像python，PHP等程序語言，有個很完善的官方手冊，實在不行就直接做個小程序跑下，馬上就有準確的答案。而SEO，毛標準都沒有，所以就經常出現(xiàn)這樣的情況：兩個人為關鍵詞密度爭得面紅耳赤，一個說3~7%好，一個說4~9%好，兩個人差點打起來，但結果還是誰也說服不了誰（而且通常都是扯淡問題）。
WHY
在規(guī)模較大的公司里，這樣的SEO是很危險的。因為在大公司里，任何一點資源都需要去爭取，都有一定的成本，比如要說服領導，得到產品和研發(fā)的配合，BI和搜索的支持。好不容易各種流程走完了，大家翹首以待等待流量提升，結果運氣好的會有點效果，大多數(shù)是毛都沒有，甚至倒退都很有可能。就比如往廚房送了一只雞，大伙等著做成雞湯或大盤雞，結果出來一盤雞屁股，或者直接出來一盤炒青菜。問廚師是怎么回事，廚師也撓了撓腦袋，也不知道哪里出了問題。
這樣不可控的SEO是危險的，在大公司會逐漸失去地位。（這也是為什么都說SEO的ROI高，但大多數(shù)老板還是偏愛SEM的原因，很多SEO都做不到可控，無法保證投入一定有產出）因此，一定要讓SEO可控。投入一分錢，就要見到一分錢的效果，不能聽天由命，看天吃飯。
WHAT
那怎樣才能讓SEO做到可控呢，不那么坑爹呢？
首先，要以科學的思路為指導。什么叫科學的思路，有3個方面：1、一切結論都有據(jù)可循，有數(shù)據(jù)支持，或出自搜索引擎基礎理論或官方文檔（這里的基礎理論可不是什么關鍵詞密度等）；2、一切方案都要考慮清楚預期效果及風險（不要求完全精確，但至少對效果的預判方向一致）；3、監(jiān)控最終效果，與之前結論和方案進行實際對照（失敗不要緊，要緊的是不管成功或失?。?。
HOW
其次，SEO項目可以參考衛(wèi)哲3+1的產品思考法。衛(wèi)哲的3+1產品思考法是我之前看到的一個很完整，符合邏輯的產品思路，后來發(fā)現(xiàn)SEO也同樣適用（產品經理是從用戶角度改善網(wǎng)站，而SEO是從搜索引擎角度改善網(wǎng)站，兩者有很多相同點的。）。下面是3+1思考法的SEO：
第一問：需求從哪里來，目標客戶是誰
需求從哪里來，目標客戶是誰，我認為這是最重要的一個問題。SEO通常這樣，沒有數(shù)據(jù)和理論支持，完全是出于自己感性的考慮，就對網(wǎng)站進行調整，比如看這個URL不爽，就重新做一套。這類需求通常沒有明確的目標，或者目標不清晰，只是為了做而做。這些需求是需要直接砍掉的。
還有一類需求，看起來很有邏輯但最底層的理論卻有問題。比如認為自己排名不高，原因是關鍵詞密度過低，于是就提出需求增加關鍵詞密度。但問題是排名低是否確實是由于關鍵詞密度低引起，增加關鍵詞密度是否真的會提高排名？從nlp角度來說，不僅要考慮關鍵詞詞頻TF，還要考慮逆文檔頻率IDF，并沒有那么簡單；其次，從搜索引擎博弈角度出發(fā)，關鍵詞密度如此容易操作，而且一直被SEO拿來控制排名的因素，恐怕早就被搜索引擎打入冷宮了。
其次，SEO需求應該是來自搜索引擎或用戶，即針對搜索引擎或用戶的某些問題進行優(yōu)化。比如生成并提交sitemap，提高搜索引擎爬蟲的抓取效率，或將主要內容放在首屏，提高用戶體驗。如果某個需求，對搜索引擎沒有益處，對用戶也沒有益處，只從SEO角度考慮，那通常是沒有作用的，再比如之前提到的關鍵詞密度。
第二問：如果不做會有什么后果？這個需求緊迫嗎？
上一問是考察需求是否必要，這一問是考察需求的重要和迫切程度。這個需求是緊急處理，還是排在隊列中慢慢來，都需要通過這一問來確定。
第三問：他們的痛是什么？場景是什么（優(yōu)化之前/之后）
這一問是考察需求能否解決之前問題。原來的問題是什么，那需求實施后能否解決問題。
+1：解決之后在網(wǎng)站數(shù)據(jù)上會有什么表現(xiàn)
這一問是考察需求的效果。不管最終結果成功與否，都要考察其結果，符合預期效果那太好了，如果跟預期差距較大，或沒有任何效果，則需要自我分析，找出其中癥結，就是“死也要死個明白”，作為以后的教訓。
EXAMPLE
之前做過一個性能優(yōu)化的需求，雖說效果不明顯，而且嚴格意義上跟SEO沒直接關系，不過仍然可以用產品思維去思考下。大致情況是這樣的：
背景
有同事剛聽了什么搜索大會，某磚家在會上提到了網(wǎng)站速度對SEO的影響，回來后就用某工具跑了下，果然比競爭對手網(wǎng)站速度要慢，于是交給我去分析。我主要是用PageSpeed，Yslow和WebPagetest對網(wǎng)頁幾個重點頁面進行測試（這幾個工具在谷歌網(wǎng)站站長指南中有推薦），并出了個初步方案，列了12項優(yōu)化items。不過由于這些items涉及網(wǎng)站架構，并且我本身專業(yè)度不夠，就只算是給研發(fā)同事的優(yōu)化建議。
第一問：需求從哪里來，目標客戶是誰
需求表面上是同事讓我分析，但總歸是網(wǎng)站自身存在的問題。
對于速度優(yōu)化的受益方，一般是搜索引擎和用戶。因為隨著網(wǎng)站速度的提升，搜索引擎爬蟲的抓取效率會提高，用戶方面就不必說了，必然會提高用戶體驗。不過跟前端和開發(fā)同事討論后，考慮到實現(xiàn)難度，第一期就先對靜態(tài)文件緩存，CSS與JS的合并進行優(yōu)化，所以就跟搜索引擎爬蟲沒有關系了（搜索引擎爬蟲只是向搜索引擎發(fā)送請求，并保存返回的結果。對于返回網(wǎng)頁代碼中的靜態(tài)文件，包括JS和CSS，并加載和保存。這一點可以參考谷歌管理員工具中的谷歌抓取方式來試驗。）。
第二問：如果不做會有什么后果？這個需求緊迫嗎？
速度優(yōu)化如果不做就會影響網(wǎng)頁打開速度，這個需求算比較重要，但不算緊迫。這個需求算是優(yōu)化類，而不算是糾錯類。（我將SEO需求按照目的簡單分為兩類：糾錯類和優(yōu)化類。糾錯類是網(wǎng)站本身的SEO基礎優(yōu)化，比如多個欄目未單獨設置title，而優(yōu)化類則是加分項，比如這個速度優(yōu)化。）
第三問：他們的痛是什么？場景是什么（優(yōu)化之前/之后）
由于是優(yōu)化類需求，所以也不算很痛。就是優(yōu)化前，用戶每次打開網(wǎng)頁都要重新下載靜態(tài)文件，并且JS和CSS都要一個個下載，JS還是單線下載。而優(yōu)化之后，老用戶打開網(wǎng)頁時部分靜態(tài)文件就直接從緩存中取，而不用重新下載，再加上合并后JS和CSS文件數(shù)量的減少，都大大降低了HTTP請求的數(shù)量，這樣用戶打開網(wǎng)頁時，速度就快了100+毫秒。
另外，前端還在列表頁進行了懶加載，這樣就不用等到32個圖片全部加載后網(wǎng)頁才顯示，而是先顯示首屏，隨著鼠標下滾才加載并顯示下面圖片。
+1：解決之后在網(wǎng)站數(shù)據(jù)上會有什么表現(xiàn)
以下是某個頁面優(yōu)化后的數(shù)據(jù)：
某欄目主要做了圖片懶加載以及背景圖合并，css合并等。
JS文件增加3個（業(yè)務需要），體積減少30KB；CSS文件減少3個，減少幅度為50%；CSS背景圖減少11個，減少幅度 61.1%；首屏圖片減少27張，減少幅度56.25%，首屏圖片體積減少200KB左右。
猜你喜歡
評論(0人參與，0條評論)
發(fā)布評論
最新評論