淺析網(wǎng)站tags標(biāo)簽優(yōu)化的重要性

記得有一個(gè)博主說過，他的博客標(biāo)簽已經(jīng)有了200多個(gè)，仔細(xì)想想一個(gè)博客盡然出現(xiàn)這么多Tags，是有濫用網(wǎng)站Tags標(biāo)簽的嫌疑，我覺得保證每個(gè)Tags標(biāo)簽下面至少有3篇以上的文章，這樣才能引起搜索引擎的重視。

第六，該不該修改Tags標(biāo)簽？

Tags標(biāo)簽的優(yōu)化是一個(gè)漫長(zhǎng)的過程，包括我在內(nèi)的大多數(shù)站長(zhǎng)都很喜歡修改Tags標(biāo)簽，每修改一次，都要等著搜索引擎從新收錄，從新賦予權(quán)重。建議站長(zhǎng)們不要輕易修改Tags標(biāo)簽。

第七，Tag頁(yè)面使用時(shí)要注意什么？

雖然tag頁(yè)面相關(guān)度高，但用不好也容易有負(fù)面作用。比如前面提到的自動(dòng)生成大量頁(yè)面，這必須是在內(nèi)容數(shù)量足夠、而且生成頁(yè)面相關(guān)性夠高的情況下。一個(gè)只有幾千個(gè)產(chǎn)品的網(wǎng)站，如果生成幾千個(gè)tag頁(yè)面，組合來組合去也都是那些產(chǎn)品，恐怕會(huì)造成大量低質(zhì)、重復(fù)的頁(yè)面。一個(gè)“黑連衣裙”tag頁(yè)面如果夾雜很多白色衣服，用戶體驗(yàn)恐怕也是個(gè)問題。

即使有足夠內(nèi)容保證，相關(guān)度也夠高（比如標(biāo)簽是編輯人工打的），也要避免一個(gè)很多網(wǎng)站在犯的錯(cuò)誤：tag頁(yè)面不應(yīng)該與現(xiàn)有分類頁(yè)面重復(fù)。比如一個(gè)新聞網(wǎng)站，把所有和財(cái)經(jīng)有個(gè)的新聞打上“財(cái)經(jīng)”這個(gè)標(biāo)簽是毫無意義的，“財(cái)經(jīng)”這個(gè)tag頁(yè)面與“財(cái)經(jīng)”欄目?jī)?nèi)容必然高度相似，對(duì)搜索引擎來說是重復(fù)內(nèi)容，對(duì)網(wǎng)站來說，到底優(yōu)化哪個(gè)頁(yè)面將失去焦點(diǎn)。

Tag關(guān)鍵詞應(yīng)該是分類名稱沒有的、又有一定關(guān)注度的詞，比如“中美貿(mào)易戰(zhàn)”，而不是“財(cái)經(jīng)”。很多時(shí)候，這種不會(huì)出現(xiàn)在分類導(dǎo)航系統(tǒng)中的詞，是有不小的查詢量的，除了前面提到的突發(fā)新聞，還有保持穩(wěn)定的人名、公司名，都不大會(huì)出現(xiàn)在分類名稱中，但名人、大公司名字，搜索量是很大的。

Tag與分類名稱重復(fù)，也可以理解為標(biāo)簽打得太寬泛，要避免。另一方面，標(biāo)簽也不能打得太細(xì)，比如我見過把文章標(biāo)題打成標(biāo)簽的，結(jié)果是一個(gè)tag頁(yè)面上就一篇文章，這頁(yè)面質(zhì)量也太低了。最好一個(gè)Tag頁(yè)面上至少有5篇10篇相關(guān)文章，才生成這個(gè)Tag頁(yè)面。

三種高效的Tags標(biāo)簽系統(tǒng)數(shù)據(jù)庫(kù)設(shè)計(jì)方案

需求背景

目前主流的博客系統(tǒng)、CMS都會(huì)有一個(gè)TAG標(biāo)簽系統(tǒng)，不僅可以讓內(nèi)容鏈接的結(jié)構(gòu)化增強(qiáng)，而且可以讓文章根據(jù)Tag來區(qū)分。相比傳統(tǒng)老式的Keyword模式，這種Tag模式可以單獨(dú)的設(shè)計(jì)一個(gè)Map的映射表來增加系統(tǒng)的負(fù)載和查詢的效率。

數(shù)據(jù)庫(kù)設(shè)計(jì)方案（1）

此方案分為2個(gè)表：

1.Tag表

2.文章表

Tag表表結(jié)構(gòu)：代碼如下:

tagid # tag標(biāo)簽的IDtagname #tag內(nèi)容num #當(dāng)前Tag的引用個(gè)數(shù)

文章表結(jié)構(gòu)：代碼如下:

ID #文章ID

title #文章標(biāo)題tags #tags列表，多個(gè)以,分割tagid #tags的ID 多個(gè)以,分割...

此種方式Tag標(biāo)簽主要內(nèi)容保存在 文章表 中，對(duì)于Tag表的壓力較小，只是添加的時(shí)候更新一下Tag的引用數(shù)量，但是查詢的時(shí)候效率不足，不是好辦法

數(shù)據(jù)庫(kù)設(shè)計(jì)方案（2）

第二種方案使用2個(gè)Tag表，其中一個(gè)保存Tag信息，另一個(gè)保存映射信息：

Tag表：代碼如下:

tagid # tag標(biāo)簽的IDtagname #tag內(nèi)容num #當(dāng)前Tag的引用個(gè)數(shù)

Tagmap表代碼如下:

tagidaid

文章表代碼如下:

ID #文章IDtitle #文章標(biāo)題tags #tags列表，多個(gè)以,分割...

這種形式，每次發(fā)布內(nèi)容和修改內(nèi)容的時(shí)候 都去更新一下Tag表和 Tagmap表。

查詢的時(shí)候需要從Tagmap表中查找響應(yīng)的文章ID，然后使用文章ID去查詢具體的文章信息，因?yàn)槊看尾樵兌际鞘褂盟饕孕瘦^高。

數(shù)據(jù)庫(kù)設(shè)計(jì)方案（3）

前兩種方案都是使用純粹的Mysql來設(shè)計(jì)的，第三種方案將使用Nosql的魅力來設(shè)計(jì)。

基本結(jié)構(gòu)同方案2，只是在Tag表和Tagmap表中使用mongo/redis這樣的nosql數(shù)據(jù)庫(kù)服務(wù)器，這樣可以發(fā)揮nosql數(shù)據(jù)庫(kù)強(qiáng)大的線性查詢能力。

1） 第一種方式的表結(jié)構(gòu)設(shè)計(jì)與方案2完全相同，只是數(shù)據(jù)庫(kù)服務(wù)器換了。

2）其他的方案，當(dāng)然是發(fā)揮Nosql的線性能力來設(shè)計(jì)存儲(chǔ)的Key了，尤其是使用redis的時(shí)候，使用的Key的結(jié)構(gòu)可以好的提高查詢效率

寫了這么多，希望能幫助到還在迷茫之中的你。