分面导航的详细操作方案
生活随笔
收集整理的這篇文章主要介紹了
分面导航的详细操作方案
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
最近群里討論的比較火熱的就是分面導航如何處理,在這里我說說我自己的一些想法吧。丑話說在前面,民工不常寫文章,文筆是差點,大家能看懂多少就看多少吧。
首先,什么是分面導航相信各位都清楚吧,例如中關村的報價庫索引頁就是采用的分面導航。
像太平洋的報價庫
http://product.pconline.com.cn/mobile/samsung/p3269/
?
說一下制作分面導航需要注意的地方。
一、分面導航因為可以通過不同條件的組合,從而產生非常多URL,如果不加以限制,一方面會大量的消耗蜘蛛的抓取,另一方面由于多條件的組合頁面需要多條件組合查詢數據庫,隨著組合的條件越來越多,對數據庫服務器的消耗的就越厲害,在遇到像360或soso這種流氓爬蟲的時候很容易把你服務器給爬死。
二、因為產品的數量其實是有限的,但是各種條件的組合方式卻是非常多的,這就導致了大量的空白頁面。大量空白頁面會導致網站的評級降低,甚至K站也是經常見的。
假如我要做一個分面導航,我會怎么做?
我的思路是robots.txt + 組合條件控制
一,首先是robots.txt
因為各種不同的條件組合是可以在一定程度上命中關鍵詞,但是隨著條件的增多,命中關鍵詞(命中用戶搜索需求)的幾率會大大降低,頁面質量也會越來越難控制,所以控制只要蜘蛛抓取一定層級的頁面能大大降低風險。那么既然要用到robots.txt,我們制定的URL就必須是有一定的規律的。
首先來看看下面2種URL,哪種會更好呢?
太平洋 : http://product.pconline.com.cn/mobile/samsung/p3269/c4927/
某基友網站的鏈接 : http://www.xxxxx.cn/cartype/28-6 ... order-ASC-grid.html
哪種更好呢?
此處省略一萬個換行
答案是2種都不好,哈哈哈!
太平洋的URL方式少了分面導航URL的標示符,不方便寫robots.txt,容易錯封。
第二個鏈接有標示符,但是太長了,組合了多少個條件沒有體現。
理想的方式:
www.xxxx.com/list_s423_s524_s842.html
robots.txt
添加4條記錄
disallow: /list*.html
allow: /list_*.html
allow:/list_*_*.html
allow:/list_*_*_*.html
就可以達到只讓蜘蛛爬3級組合的頁面了。
這時候程序員可能會說,這樣的URL沒辦法實現啊,參數不知道怎么傳。
這里我也說說這種URL結構傳參數的原理吧。
www.xxxx.com/list_s423_s524_s842.html
首先這個是個偽靜態的URL,原始動態的URL可能是這樣的。
www.xxxx.com/list.php?tag=s423_s524_s842
這樣list其實拿到的是 tag參數對應的值是s423_s524_s842
這時候可以將tag參數的值按 "_"切分成數組,變成下面的數組
array("s423","s524","s842")
再對數組的每個元素進一步解析,每個元素取前2個字符作為參數,其余的作為值。
就變成
s3=23
s5=24
s8=42
s3,s4,s5分別對應著產品的不同屬性,23,24,42分別對應著產品的不同屬性值。
這樣這個URL的解析就完成了。
二,組合條件控制
大家可以去看看太平洋報價庫的分面導航,沒有結果的條件是不可點的。中關村采用的是沒有結果的URL采用nofollow標簽nf掉。但是民工覺得NF還不夠徹底,直接不要讓搜索引擎知道有個鏈接是最好的。
那么怎么實現這一個效果呢,這里就要判斷哪些條件組合是沒有結果的。民工想了一個辦法,在產品數不是很多的情況下可以實現,像淘寶那樣級別的就另當別論了。
首先,當我們選擇第一個條件的時候,我們需要把所有符合條件的商品全部查詢出來,SQL語句想當簡單,select * from XXX where XXX = XXX
假如,這個類產品有三個屬性 aa bb cc ,那么就遍歷結果集,把所有商品的aa bb cc屬性都放到3個數組里
假如只有4個商品,數據可能是下面這樣的
aa=[1,1,2,4]
bb=[2,2,4,2]
cc=[g,w,g,r]
對3個數組去重可以得到
aa=[1,2,4]
bb=[2,4]
cc=[g,w,r]
因為假如增加條件,等同于對現有的結果做進一步的篩選。所以,只有用戶選擇了上面的幾個屬性值之一才可能會有結果,這樣我們就可以判斷出哪些選項是可以繼續篩選的,哪些選項是沒有結果的。
但是有人會說,這樣要遍歷所有符合前面條件的商品啊。首先,這一個過程只做了一次的數據庫查詢,只是計算量會比較大,只要配合緩存我覺得問題不會很大。像代理緩存:如nginx,還有數據庫緩存如mencached,一個能減輕web服務器壓力,一個能減輕數據庫查詢壓力,這樣能保證頁面訪問速度。
好了,上面是我對分面導航怎么實現的一些想法,還沒有真正上過,不知道效果會怎么樣。
扯了一大堆,發現外鏈還沒發完,趕緊先發外鏈去了……
注:本文章只供ITSEO內部交流,禁止轉載!
首先,什么是分面導航相信各位都清楚吧,例如中關村的報價庫索引頁就是采用的分面導航。
像太平洋的報價庫
http://product.pconline.com.cn/mobile/samsung/p3269/
?
說一下制作分面導航需要注意的地方。
一、分面導航因為可以通過不同條件的組合,從而產生非常多URL,如果不加以限制,一方面會大量的消耗蜘蛛的抓取,另一方面由于多條件的組合頁面需要多條件組合查詢數據庫,隨著組合的條件越來越多,對數據庫服務器的消耗的就越厲害,在遇到像360或soso這種流氓爬蟲的時候很容易把你服務器給爬死。
二、因為產品的數量其實是有限的,但是各種條件的組合方式卻是非常多的,這就導致了大量的空白頁面。大量空白頁面會導致網站的評級降低,甚至K站也是經常見的。
假如我要做一個分面導航,我會怎么做?
我的思路是robots.txt + 組合條件控制
一,首先是robots.txt
因為各種不同的條件組合是可以在一定程度上命中關鍵詞,但是隨著條件的增多,命中關鍵詞(命中用戶搜索需求)的幾率會大大降低,頁面質量也會越來越難控制,所以控制只要蜘蛛抓取一定層級的頁面能大大降低風險。那么既然要用到robots.txt,我們制定的URL就必須是有一定的規律的。
首先來看看下面2種URL,哪種會更好呢?
太平洋 : http://product.pconline.com.cn/mobile/samsung/p3269/c4927/
某基友網站的鏈接 : http://www.xxxxx.cn/cartype/28-6 ... order-ASC-grid.html
哪種更好呢?
此處省略一萬個換行
答案是2種都不好,哈哈哈!
太平洋的URL方式少了分面導航URL的標示符,不方便寫robots.txt,容易錯封。
第二個鏈接有標示符,但是太長了,組合了多少個條件沒有體現。
理想的方式:
www.xxxx.com/list_s423_s524_s842.html
robots.txt
添加4條記錄
disallow: /list*.html
allow: /list_*.html
allow:/list_*_*.html
allow:/list_*_*_*.html
就可以達到只讓蜘蛛爬3級組合的頁面了。
這時候程序員可能會說,這樣的URL沒辦法實現啊,參數不知道怎么傳。
這里我也說說這種URL結構傳參數的原理吧。
www.xxxx.com/list_s423_s524_s842.html
首先這個是個偽靜態的URL,原始動態的URL可能是這樣的。
www.xxxx.com/list.php?tag=s423_s524_s842
這樣list其實拿到的是 tag參數對應的值是s423_s524_s842
這時候可以將tag參數的值按 "_"切分成數組,變成下面的數組
array("s423","s524","s842")
再對數組的每個元素進一步解析,每個元素取前2個字符作為參數,其余的作為值。
就變成
s3=23
s5=24
s8=42
s3,s4,s5分別對應著產品的不同屬性,23,24,42分別對應著產品的不同屬性值。
這樣這個URL的解析就完成了。
二,組合條件控制
大家可以去看看太平洋報價庫的分面導航,沒有結果的條件是不可點的。中關村采用的是沒有結果的URL采用nofollow標簽nf掉。但是民工覺得NF還不夠徹底,直接不要讓搜索引擎知道有個鏈接是最好的。
那么怎么實現這一個效果呢,這里就要判斷哪些條件組合是沒有結果的。民工想了一個辦法,在產品數不是很多的情況下可以實現,像淘寶那樣級別的就另當別論了。
首先,當我們選擇第一個條件的時候,我們需要把所有符合條件的商品全部查詢出來,SQL語句想當簡單,select * from XXX where XXX = XXX
假如,這個類產品有三個屬性 aa bb cc ,那么就遍歷結果集,把所有商品的aa bb cc屬性都放到3個數組里
假如只有4個商品,數據可能是下面這樣的
aa=[1,1,2,4]
bb=[2,2,4,2]
cc=[g,w,g,r]
對3個數組去重可以得到
aa=[1,2,4]
bb=[2,4]
cc=[g,w,r]
因為假如增加條件,等同于對現有的結果做進一步的篩選。所以,只有用戶選擇了上面的幾個屬性值之一才可能會有結果,這樣我們就可以判斷出哪些選項是可以繼續篩選的,哪些選項是沒有結果的。
但是有人會說,這樣要遍歷所有符合前面條件的商品啊。首先,這一個過程只做了一次的數據庫查詢,只是計算量會比較大,只要配合緩存我覺得問題不會很大。像代理緩存:如nginx,還有數據庫緩存如mencached,一個能減輕web服務器壓力,一個能減輕數據庫查詢壓力,這樣能保證頁面訪問速度。
好了,上面是我對分面導航怎么實現的一些想法,還沒有真正上過,不知道效果會怎么樣。
扯了一大堆,發現外鏈還沒發完,趕緊先發外鏈去了……
注:本文章只供ITSEO內部交流,禁止轉載!
總結
以上是生活随笔為你收集整理的分面导航的详细操作方案的全部內容,希望文章能夠幫你解決所遇到的問題。