ASP等動態語言網站做SEO時站內搜索應當注意的問題

WEB動態語言有眾多，ASP，PHP，.NET，JSP等，之所以在題目中著意提到ASP，是由於到現在為止市面兒上大部分數的公司站點仍然認為合適而使用ASP來做的，這個語言由於學習的門檻較低，又有ACCESS的完美合適，所以是大部分數程序開發人員首選的公司站點語言。我們不在這篇文章中商議ASP的安全性或技術層面的物品，我僅在這篇文章中分享最新學習到的一個理念，就是ASP網站的站內搜索功能對SEO的影響。

由於SEO對靜態語言的收錄有一定的優先(雖沒有完全性，但因為一樣的配備布置上，靜態頁面的過訪速度快於動態頁面，所以從用戶體驗認識角度上，百度是優化收錄和名次的)，如今大部分數在網絡企業辦公的程序開發人員都著手接觸SEO網絡營銷的概念，所以有點程序開發人員在站點計劃上會生成靜態，但有個矛盾點，就是站內搜索，尤其是對於一點產品或新聞信息比較多的站點，這個功能是至關關緊的，因為數值的傳道輸送問題，沒有辦法做到完全的全站靜態，要不是偽靜態，要不是用XML做為小規模數值庫施行用篩子選，但從實質上講，仍然動態的。

這種站內搜索頁面萌生的最後結果頁面往往是重復程度頎長，或相仿性頎長，不太了解這個意思的朋友，我舉個例子：

譬如淘寶網裡有1000個電腦商品，而後搜索筆記本，還是搜索14寸筆記本，出來的最後結果相差無幾，這處僅只是兩個網站關鍵詞在搜索，隨著產品數值變大，可以搜索出相仿最後結果的網站關鍵詞也會越來越多，那末這些個網站關鍵詞搜索萌生的最後結果頁面，他們的相仿性就極高，甚至於有重復性，天然，百度是不喜歡這些個頁面的。

上頭講的只是一個不喜歡的概念，真正了解起來，從搜索引擎網站的原理上剖析，我們會明白地曉得，互聯網上每日的更新是很大的，但百度就一個，他派出來的蛛蛛抓取頁面和剖析頁面時，都需求時間，而因為這些個頁面要施行數值庫的用篩子選，消耗的錢的時間是剖析其它頁面的幾倍，等蛛蛛有耐性剖析完後，又發覺這些個站內搜索萌生的頁面有頎長的相仿性，所以容易假想，百度不會由於你的站點萌生了眾多這種頁面而感到你的網站規模比較大，與之相反有負面的影響，由於你耗費了它的時間，況且關鍵是這些個頁面並未給你的站點帶來若乾的浩博內部實質意義。

那末既是這麼，有萬不得已處置這種事情狀況呢?由於畢竟如今絕大部分數網站都有這種站內搜索的功能，天然也存在這種弊病了。

我看了眾多國內比較知名的SEO人士的文章和訪問交談，它們也有說起這種事情狀況，但直到現在還沒有啥子好的方法可以解決。

根本端由如下：

假如用robots來直接指導蛛蛛不去抓取這些個頁面，這一點兒上是行得通的，不過我們要曉得，來這些個頁面之前，蛛蛛是延著我們的站內結構一步步過來的，等抓到這些個頁面時，遭受ROBOTS的影響，就好似我們斷了它的路，這是個借喻，實際事情狀況下，站內的權重需求傳交，形成一個循環，需求斷掉的話，讓權重有來無回，有些大致相似宇宙寂的坍縮星。因為這個無論你用robots仍然用其它一點手眼，可以讓蛛蛛不來抓取，但不可以讓權重做到合理的傳交。

綜上所述，站內搜索到現在為止仍然SEO辦公者盤中的一塊雞肋，至少在到現在為止的搜索引擎網站算法中還不可以獲得完美的解決。

然而SEO的技術在不斷成熟，搜索引擎網站的算法也在一天一天地走向人性化，我們曉得了實質的原理，固然到現在為止萬不得已解決，但不代表沒有辦法解決。

我們一方面期望搜索引擎網站本身能協調這個問題，另一方面，我們也考求SEO的合了解決辦法。

【尊重原創，分享觀點。來自芝麻開門網絡科學技術原創文章，過載請標見於文字章出處 — 】