干货内容:SEO采集海量文章，用倒排索引找出"类似的标题"

　　干货内容:SEO采集海量文章，用倒排索引找出"类似的标题"

　　截止目前为止，站群的模式依然是有效的，运用站群的方式截取海量搜索流量偷偷变现再正常不过。一个人管理一批网站，内容的更新离不开采集。

　　本文使用倒排索引的逻辑解决SEO采集场景中"标题类似"的问题，顺便带入一个小算法，过段时间会结合这个小算法分享一个"重要热点自动推送到微信"的案例。

　　倒排索引是搜索引擎检索的基石，理解倒排索引有助于了解搜索引擎的排序逻辑，很多做SEO的朋友甚至不知道基本的排序规则，不能把这些规则结合到日常优化，做SEO全凭感觉。

　　我在文章中偶尔出现的一些技术细节、小思路，表面上看起来离赚钱很远，但实际上正是这些小东西支撑起一个人的判断力，机会来的时候才能做正确的选择。

　　每个SEOer都指导过或者自己干过采集这个事，因为网站内容的数量和质量对于流量的提升至关重要。在早几年PC时代，自媒体这个概念还没有盛行，一个网站的内容生产如果全靠公司编辑组的几个同学们，很可能撑不到自己被辞退的那天。那时候版权和原创的概念还很模糊，一个网站20%的内容是原创，80%的内容是采集，我觉得已经是业界良心了，网站内容互相采集是业内常态，绝大部分个人站长的网站内容从第一篇开始采起。

　　2016年我在看完市面上的大部分采集工具后(那时候普遍是优采云，好像现在也是)，我用自己为数不多的产品思维嫌弃了一下，索性用Python开发了一个采集工具：

　　时隔四年有些感慨，人越缺少什么就越爱炫耀什么，自己技术烂，特别是英语死烂，所以设计界面的时候特意要把相关字段和标题用英文表示，现在看起来眼睛很辣。

　　但是这个工具的功能直到现在我依然不觉得过时，我曾在曹政老师的公众号下评论过，自己是个喜欢动脑不喜欢动手的人，重复的事情让我反复操作10次8次我就得考虑能不能自动化，要不然会开始烦躁。

　　为什么那会嫌弃市面上的采集工具，因为我按照他们的流程走了一遍，我发现过程中很不灵活，不够全面。我希望这个工具打从它做好之后，我就不需要再考虑任何问题，只需要按部就班即可，所有可能发生的情况我都尽可能的设计到里面。这个工具可以对接主流的三大开源内容管理系统：dedecms、phpcms、ecms，接口是自己写的，整体模型是这样：

　　以己方网站为一级目录，目录里收录多个目标采集网站作为二级目录，每个采集网站里又收录多个栏目，每个栏目下存储各自采集规则和历史记录，常态下一天入库几万是没有问题的。

　　程序支持：随时切换己方运营的不同网站，自动调出事先设定的目标网站和规则。

　　每个目标网站的采集规则，支持增删改查、保存、导入导出。单一目标可设定多套规则方案，根据页面自动识别最优抓取规则。html格式化（保留原文段落的同时去除别人的所有HTML标签）

　　特定字符替换、特定规则的字符替换(正则)，图片提取及链接补全。按网站、栏目轮番采集，定时定量，自动判重，自动入库，等待审核。

　　说到判重，就到了我们今天的主题："类似标题"的判重问题。当你把程序打开时，它开始工作，从你为它配置的各个网站抓取内容，这相当于全网采集，目标网站自身和目标网站之间都有可能碰到文章重复的情况。

　　在一个网站里一样的文章除了技术或人为出现问题，一般都是一样的链接，所以只要让程序判断链接是否一模一样即可，这很简单。

　　和 一模一样不入库，但是在不同的网站里，由于大家都是采来采去，很可能采集一模一样的文章，将多篇标题一样正文也一样的文章一起发布在网站上，从优化的角度来说是不可取的，特别是采集情况下，长期自动化采集，没有人工干预，久而久之会积累大量重复性内容，那网站离死不远了。

　　因此除了初步的链接判断之外，还要加入标题的判断，不管是一个网站内部还是网站与网站直接，但凡想入库都要做判断。

　　标题如果完全一样，处理方式则跟链接一样，直接丢弃即可，可麻烦的问题在于：标题类似。

　　假设目前网站里有这样10篇文章，它们的标题分别是(拿微博热搜举个例子)：

　　四字弟弟把沙发借蔡国庆坐坐呗特朗普团队称出现死人票美队回应与拜登撞脸阿云嘎可以把钢琴借给蔡国庆躺李栋旭给孔刘送咖啡车应援拜登称特朗普拒绝承认选举结果令人尴尬专家建议女性退休年龄延至55岁你最后网购的那个东西拥有了2万倍生育对女性职业生涯的影响日本首相菅义伟欲率先会见拜登

　　这个时候程序采集抓取了一篇文章，它的标题是：

　　拜登称特朗普拒绝承认选举结果使人尴尬

　　它和现有数据库里的一条标题是一个意思，阐述的是一件事情，标题几乎一模一样，文章正文则完全一样，只是编辑把标题中的"令人"换成了"使人"。

　　如果我们让程序自动去判断两条标题是否一样，那对于不是0就是1的计算机它给的结果就是：否。但我们显然不能让这样的文章再入库，因此要有合适的办法来处理，让程序能识别出来，同时我们网站数据库里可能有几百几千万甚至更多的标题，这个办法有效的前提还得考虑效率，不能做一次判断要几秒。

　　在那段时间我也是不得其所，网上的工具没有发现能处理这个问题的，都是完全一样就丢弃，一字之差也认为是不一样的文章。

　　过了一段时间在搜索引擎书籍里了解到了"倒排索引"的思路，真是惊为天人，当下就想到可以用来解决这个问题。

　　我们思考一下：百度或谷歌为什么可以在几毫秒之内搜索到我们需要的内容？

　　这里面其实有很多技术方案在支撑，但一切的方案都建立在"倒排索引"的前提之下，是"倒排索引"使得"搜索"这一行为极大提升检索效率的同时并附有一定的相关性。

　　倒排索引：

　　假设这是我们的数据库，文档就是一个网页或者一篇文章，我们这里用标题表示，当用户搜索：特朗普

　　因为没有一模一样的（一模一样的瞬间可以找到），数据库就一条条的检索，把收录特朗普的文档对应的ID拿出来，可得：2、6，这样我们就找到了用户需要的相关内容。

　　可如果这里面有100亿条数据，这样的方式不知道要查到猴年马月，这个时候我们多建一份这样的表：

　　如图，我们给单词新建另一份表，表里每个词是唯一的，每个词有哪些文档收录它，把ID都列出来。

　　当用户搜索：特朗普与拜登，搜索引擎分词：特朗普、拜登根据第二张表，特朗普这个关键词显示涉及到它的有：2、6，拜登这个关键词则是：3、6还记得初中学过的交集吧：2、6和3、6取交集，共同的是6，因此本次检索找出来的相关内容就是：文档6，这个文档即收录特朗普也收录拜登，满足了基本的相关性。

　　文章可能有千千万万，但是世界上的词汇量始终是有限的，而且只要是一模一样的，数据库可以马上搜索出来。

　　不管第一张表里有多少亿数据，通过第二张表我们可以瞬间找到收录目标关键词的所有文档ID，取交集后再用文档ID去第一张表里直接取，不需要一条条的查。这第二张表就是：倒排索引，又称反向索引。

　　

　　至于所谓的正排索引，我感觉也没有这个概念，它只是有了倒排后相对的而已。

　　在当时了解到这个思维后，我是真感慨，在最开始的时候人家到底是怎么想出来的，太佩服了。

　　这个应用是针对文档(文章)，在我看完之后，我在想：是否可以把文章换成标题，利用这个思路来判断标题是否极度类似？如果你已经有了初步的思路，那说明倒排索引的思想已经理解了。

　　说一下技术细节：

　　会碰到这个问题并且在考虑解决方案的人，肯定是会技术的人，因此简单给一下核心代码，用Python实现，其实就是dict的设计，这个过程还会涉及到搜索结果的初步得分计算，SEO的朋友如果不会的话也一起了解看看。

　　刚才是为了方便理解倒排索引，所以用一个简单的例子讲解它是怎么为我们的搜索工作，实际上在搜索引擎检索数据时，并非简单的把所有文档ID拿出来取交集，这会存在有很大问题。

　　这块是比较专业的知识，我自己也不算深入理解，仅仅只是依靠这些思维来解决业务问题而已，有兴趣的朋友可以看这本书：《这就是搜索引擎-核心技术详解》PS：感谢SEO业内大神ZERO的各种分享，我早期在他的文章里得到很多帮助和提升！

　　在建立了倒排索引之后，当用户搜索时，一般会有以下几个检索逻辑：

　　一次一文档一次一单词结合一次一文档的跳跃指针一次一文档的本质就是取交集的逻辑，我们这里使用相对简单的一次一单词的方式。

　　搜索：特朗普与拜登特朗普，对应收录它的所有文档ID是：1、2、3

　　拜登，对应文档ID是：3，4，5

　　取出特朗普，1，2，3各得一分

　　再取出拜登，1，2，4，5各得一分，3累积得两分

　　因此文档3是最具相关性的，这就是一次一单词的逻辑，最终我们就得到了每个相关文档的相似性得分，从大到小罗列就是一次搜索的初步排序了。我们其实是把文档出现次数叠加计算得分，在实际的检索中，得分并非简单这样计算，每个文档要结合很多因素单独计算得分，然后再叠加，但是仅用来处理我们的问题是足够了。

　　核心代码：

　　# 存储历史入库的所有标题，相当于表1<br />seen_title ={<br /> '1':['拜登称特朗普拒绝承认选举结果令人尴尬'],<br /><p>        '2':['特朗普团队称出现死人票']

　　}

　　<br />

　　# 把标题对应分词单独建表,方便提取(与表1同步更新)title_word ={<br /> '1':['拜登','特朗普','拒绝','承认','选举','结果','令人','尴尬'],<br />

　　        '2':['特朗普','团队','出现','死人票']

　　}

　　<br />

　　# 表2，单词对应的所有包含它的标题ID(与表1同步更新)word_id ={<br /> '特朗普':set(['1','2','3']),<br />

　　        '拜登':set(['3','4','5'])

　　}

　　<br />

　　# 求余弦值

　　defcount_cos(new_word,old_word):        return cos<br /><br />

　　# 计算相关性得分

　　defget_doc_id(title):<br /> # defaultdict创建的整数型字典，存储文档得分<br /> id_count = defaultdict(int)<br /> # 存储本次新增标题的所有分词<br /> new_word =[word.encode('utf-8')for word,flag in pg.cut(title)]<br />

　　        # 循环提取每个单词对应的所有文档ID并计算得分 for word in new_word:<br /> # 数据库里没有记录的单词忽略计算<br /> if word notin word_id:continue<br />

　　 for ids in word_id[word]:id_count[ids]+=1

　　<br /> # 最终得到所有文档的最终得分，降序<br /> id_count = sorted(id_count.items(),key=lambda x:x[1],reverse=True)<br /> # 取得分最高的与本次标题计算余弦值，大于目标值就算类似重复，反之其他的相似度更低，不必计算<br /> return count_cos(new_word,title_word[id_count[0][0]])>=0.8<br /><br />get_doc_id(title)</p>

　　在16年那时候我没有写过向量分类，最后的对比是借鉴"Shingle"算法提取文本块的方式，相对来说，向量更合适点，整体查询速度基本维持在几毫秒内。

　　这是基本的处理模型，实际上我们可以看到这样的计算方式随着数据的增加，计算速度会线性增长（还好不是指数增长），同时内存的开销也很可怕，所以要采取一些方式来维持稳定。

　　比如分段存储、文本转md5等，百万级千万级的数据没有什么压力，实在不行该增加机器就增加。

　　虽然我是学数据库的，不过那时根本没在上课，毕业后只知道了几个数据库的名称叫什么，显然用数据库的处理方式会更好，不过仅仅只是处理一些小问题，不需要花费太多精力，有更好的方式也欢迎指教。

　　运用这样一个思路去处理SEO-采集过程中-标题判重，这样的一个问题，显得有些大材小用，杀鸡用牛刀，特别是看起来离钱很远。

　　很多人并不愿意做，但是把一个事情做到极致往往是拉开对手距离的关键。

　　接下来我们来谈谈开头提到的小算法：

　　我们刚才也说了是为了便于理解倒排索引，实际上整个倒排索引很复杂，为了支撑它正常工作还要设计很多技术方案，比如存储方式、更新逻辑、检索方案等等，同时在数据库里并非单纯的存放我们刚才提到的内容，特别是表1：

　　我们这里是简单存储文档收录了哪些词，实际在一篇文章里，总有一些词是无关紧要，有它没它都可以，反过来有些词是最能代表这篇文章在写什么，是文章的主题。

　　当用户搜索：特朗普跟拜登一起喝茶

　　有一个文档里只收录"一起"这个单词，可要知道，这样一个词在不同领域的各种文章都会出现，一点都不稀奇，这个词也不重要，去除了它也不影响文章表达的主题。

　　所以我们不能简单的认为这篇文档也跟搜索词有一定的相关性，有鉴于此，我们就必须要计算出一篇文章里哪些词是重要的，哪些词是不重要的，为它们单独计算一个权重值，比如像这样：

　　每一个单词都有它在这篇文章里的权重值，在刚才提到的计算文档相关性得分时就可以加入这些权重值计算，这样的得分更有意义，相关性更高，而这个权重值的计算就是：TF-IDF算法。

　　我们用小明的日记来解释一下：

　　小明在10天里写了10篇日记，我们想知道今天的日记，小明干了什么事，正常人阅读完之后，看到反复出现的爬山的乐趣、爬山的风景、爬山的感受，我们就知道小明今天去爬山了。

　　可是过往的10天里小明没有爬山，所以其他日记都没有出现过爬山这个词。

　　反过来："今天天气晴朗，万里晴空飘着朵朵白云"几乎是全国小学生对于自己文采的初次尝试，这样一个全国统一的凑字数行为作为应付老师的手段屡试不爽。

　　可见，这些词在很多日记里都会出现，它们对于理解某篇文章并不起作用。

　　在一个分类里的某篇文章中，高度反复出现的一些词，在该分类的其他文章里很少出现，这些词是最能说明文章主题的，反过来在任何文章里总是出现的词汇不助于理解文章，这些词也不具备重要性和相关性。

　　这就是TF-IDF的朴质思想。

　　TF-IDF用来评估一个词对一篇文章的重要程度（权重），一个词的重要程度与它在文章中出现的次数成正比，与它在其他文章中出现的次数成反比。

　　使用TF-IDF计算出来的数值就是我们刚才提到的一个词在一篇文章里的权重，结合它计算出来的文章与搜索词的相关性得分非常有效，TF-IDF的公式和具体理解可以百度百科一下。

　　

　　TF-IDF的应用比较小众，基本是应用在搜索引擎中，我利用它做了一个事情。

　　在互联网发达的今天，我们每天发生的各种各样的事情，都通过媒体平台推送给我们，这其中有国家大事、有娱乐八卦、有行业资讯，如何判断今天发生的哪个事情比较突出？核心的关键主题是什么？

　　今年年初疫情呆在家里，我还干了一个事情，写了一个热点推送的工具，自动将昨天各大平台出现的热点推送给我。

　　推送给我的内容是经过权重计算的，哪些热点在多个平台出现，哪些热点在过去一段时间是没有的，最终形成一个简单的报告在每天早上9点准时推送到我微信。

　　这里面我初步看到一个应用：

　　我们都知道能够火爆全网的热点总是最先出现在泛媒体，经过一系列的发酵传播后才达到全网讨论。

　　比如抖音或者微博往往会先出现一些热点爆料，等到这个事情开始传播开来之后，知乎相关的讨论问题也出现了，再然后公众号头条等自媒体开始跟风写内容。

　　我在想：对于常年蹲守热点时刻做好准备蹭的自媒体同学，如果能提早发现一些泛媒体平台普通在讨论的热点，而这些热点在知乎公众号等地方还没出现的时候，是否可以擦擦键盘开始准备蹭？

　　我并非职业自媒体，常年蹭热点的自媒体同学有他们专业的方式，我经常见到的一个现象是：当抖音微博刚出现一个热点的时候，知乎还没有，等后面知乎出现相关问题的时候，基本是热榜，首答一句调侃的内容都能分分钟拿到几万赞。

　　蹭热点截流这个逻辑的价值本身不需要验证，重点在于这种方式是否能让我们及时蹭到。

　　目前我还只是猜想，这个工具的其他运用我也还在思考，后续我再把相关方式写出来。

　　插播一个事情：

　　很多朋友经常会加我问一些回答过很多次的问题，包括技术上的、思路上的。

　　时不时有朋友会问能不能加一下评论里谁谁谁的微信，想要跟他对接或者找他买源码。

　　陆陆续续有些朋友利用文章的思路做出一些效果来，但终究是小部分，更多的人由于基础薄弱的原因无从下手，他们缺乏引导。

　　程序员普遍缺乏营销思维，而运营的人又不懂技术，双方之间互相仰望。

　　有鉴于此，前段时间决定开设一个读者交流群，解决上面的问题。

　　目前来说，自媒体方面只是我抽空去运营的事情，很多时候没办法投入太多精力，开设一个微信群就得负责管理，随时回答各种问题，这会占用很多精力，这也是我迟迟犹豫的地方。

　　不过考虑到上面的问题随着时间的积累是会反复出现的，而开设一个微信群可以减轻很多，利大于弊。

　　关于费用问题，如果进群要正式收费的话我当然不用担心精力的投入，恰恰是进群不收费所以我才要考虑要不要开。

　　虽然不收费，但也要有一丁点门槛，我也不希望它是一个闲聊吹水群。

　　先说一下群的价值或意义：

　　最主要的还是我的所有文章里涉及到的任何技术问题、思路问题、落地实操、应用场景等都可以提问，我在群里统一回答。

　　Python、seo、sem、信息流、产品、运营、数据等，涉及专业的我会解答，不是专业方面的我会给出自己的建议。

　　互联网创业、自由职业、副业、个人技能提升等方向上的问题，信息差、项目选择等判断性的问题，我也有一些自己的看法。

　　新的内容或资源我会优先在群里推送。

　　其他方面：

　　读者朋友之间有任何要对接的事情可以自己私下联系，我不参与其中，仅提供一个方便。

　　允许在一定频次内宣传自己或自己的业务、包括文章或社群。

　　还有一点在考虑中的是问答咨询，你有专业的领域正好是别人疑惑的，群里有人在提问，你也愿意提供解答，那我很乐意起到桥梁的作用，但如何保障双方的权益是个麻烦事，流程设计上要再考虑一下，知乎的付费咨询氛围没有起来，很大程度上是其流程上的简单粗暴导致的。

　　关于群的门槛，本质上我不打算收费，但原则上我不欢迎伸手党，这跟看文章不一样，文章发出来就是让人看的，但群是用来交换彼此的地方，我相信大家也不欢迎，因此进群门槛的逻辑是这样：

　　在过往有在我这里主动付出过的：付费阅读了文章、付费咨询过（不论知乎或公众号，不论多少钱）、私下给我发过红包（不论我有没有收、不论多少钱），这些朋友是在没人要求的情况下主动付出的，我很尊重你尊重别人付出的态度，请直接进群。

　　反之，请转账10块钱，算是对我以及其他付出过的人的尊重，没有这些朋友的正向反馈我也不可能持续产出，同时也让这些付出过的朋友知道进来的都是和他一样愿意交换付出的人，这样才能平等交流。

　　这个群毕竟没有正式的商业产品或服务，因此不会正式收费，10块钱仅是聊表态度，我不可能挨个去检查进群的谁有没有付出过，初衷是为了解决上面提到的问题，不能本末倒置的花费更多的精力。

　　相信大部分人还是诚信的人，要真有不诚信的，也请相信我：圈子不大。

　　之所以选择微信群的方式，目前来说我没有精力运营一个社群，再者类似的社群其实有很多优秀的了，如果这个群的价值很明显，对大家的个人提升、业务推荐、资源互换确实有很大帮助，以后再考虑专业性的问答社群，重在解决实际问题。

　　群二维码：

　　人满或过期，请加我备注：进群

　　由于担心打扰，所以一些原本是好友的我也没一一邀请，有需要进群请知会我一下即可。

　　刚好周末到了，放着让需要的人进一下，下周再一起探讨。

　　内容分享:网站采集工具之免费文章批量采集发布插件详解（图文）

　　网站的每日更新，对于站长来说，既费时又费力。没有那么多东西可以写。作为站友，可以考虑使用网站采集工具制作采集站，让网站可以更新规则，方便搜索引擎Keep跟踪您的 网站 更新。网站采集工具批量监控不同的cms网站数据。网站采集工具无论你的网站是Empire, Yiyou, ZBLOG, 织梦, WP, Cyclone, 站群, PB, Apple, 搜外和其他主要的cms工具，可以同时管理和批量发布。

　　网站采集工具在发布任务时会自动在文章的内容中生成内部链接，有助于引导网络蜘蛛抓取，提高页面权限。网站采集工具构建网站地图。构建网站地图可以加快收录网站的速度，但不是100%。一切都是相对的，不是绝对的。这样一来，这个世界上就有好人和坏人。网站采集工具内容与标题一致，做到内容与标题100%相关。已提交网站 只需要监控爬虫日志，看看搜索引擎是否爬取了你提交的页面，如果5天内没有收录，那么还要考虑你的内容质量。网站采集 工具可以设置为自动删除不相关的词。通过网站采集工具实现自动化采集行业相关文章。

　　网站采集工具可以批量采集文章内容。网站采集工具生成行业相关词，关键词从下拉词、相关搜索词和长尾词。网站采集工具自动添加推送代码。推送代码分为：主动推送和自动推送网站采集工具搜索引擎推送。网站采集工具标题前缀和后缀设置，网站采集工具让标题区分更好收录。网站采集工具文章发布成功后，会主动向搜索引擎推送文章，保证新链接能被搜索引擎展示&lt; @收录 及时。

　　

　　网站采集工具自动批量挂机采集，无缝对接各大cms发布者，在采集之后自动发布推送到搜索引擎。网站采集工具可以主动推送：主动推送需要自己编写代码，在文章发布时推送到百度。现在很多程序都有可以安装的插件。如果自己用网站代码没有插件，只能自己写代码，有点难度。如果是php程序，可以调用百度的api接口推送。网站采集随机喜欢-随机阅读-随机作者之类的工具。

　　网站采集工具可以自动推送，采集发布后可以批量百度、神马、360、搜狗推送，让你的网站更多容易被搜索引擎发现并增加蜘蛛爬取频率来推广网站收录。网站采集工具插入随机图片，网站采集工具文章如果没有图片可以随机插入相关图片。自动推送是在用户访问文章时自动推送到百度。网页只要加载了百度的JS代码，就可以推送了。JS代码的使用与百度统计代码相同。这很简单。现在百度统计代码也自动推送了。

　　网站采集多种工具采集来源采集。网站采集工具网站 是响应式的。网站响应速度快是最重要的，不管是搜索引擎还是用户，只要你的网站长时间加载或者打不开。网站采集工具内容关键词插入，合理增加关键词的密度。搜索引擎和用户都会选择下一个站点。搜索引擎每天抓取的页面信息数以千万计。对于用户来说也是如此。耐心是有限的。你不是整个网页中唯一的一个。网站我可以看到这个需求的东西，你可以选择其他网站找到你需要的东西。

　　

　　网站采集工具会自动过滤其他网站促销信息。域名的选择对于网站采集丰富的工具收录也很重要。您可以在此处选择旧域名和新域名。在注册旧域名之前，最好查看网站以前的历史数据中有灰色行业，不要注册。网站采集其他平台的工具图片本地化或存储。对于新域名，一般建议将域名加长。这样的域名有 90% 的可能性已经注册并完成了 网站。在注册新域名之前，不要去百度查询域名变更的相关数据。

　　网站采集工具一次可以创建几十个或几百个采集任务，可以同时执行多个域名任务采集。一个稳定快速的响应空间可以减轻搜索引擎对自己服务器的压力，搜索引擎也会根据服务器情况自动调整网站的爬取频率。

　　网站采集工具可以选择模板。模板要尽量选择内容多的，有图有文，flash，少特效，少弹窗的模板，最好是内容丰富的模板。网站采集工具定期发布定期发布网站内容让搜索引擎养成定期爬取网页的习惯，从而提高网站的收录 . 今天关于 网站采集 工具的解释就到这里了。下期我会分享更多的SEO相关知识。我希望它可以帮助您进行SEO优化。下期再见。