心晴 25个应对谷歌的site:运算符杀手组合
人们常常抱怨site:本身是不准确的（我会在文章的结尾进行解释），但神奇的地方在于将site:与其他查询运算符的结合。所以，我选出两打杀手组合帮助您深入到任何网站。
1. site:example.com
好吧，这一个其实不是一个组合，但让我们从基础知识开始。与根域或子域配对， [site:] 运算符能够提供该域的索引页的数目的预估数。这个”估计”的部分是重要的但稍后我们才会说到。一般来说，我坚持到根域 （省略”www”等）。
这篇文章中的每个组合都有一个可点击的例子 (见下文)。我将把亚马逊网站放在我的示例中，因为它足够大，可以让所有这些组合发挥作用：
你会得到两项信息： (1) 索引结果页面的实际列表，和 (2) 那些页面的数量 (在下面的紫色圆圈中）：
我们都会同意 273,000,000 的结果比我们大多数人预想做整理的庞大。即使我们想要点击那么多次，Google也会在100 页之后阻止我们。那么，我们如何得到更加详细复杂的数据和深入到 Google 索引中呢？
2. site:example.com/folder
深入研究这种混乱局面的最简单方法是提供一个子文件夹 （像“/blog”）—— 只需将它追加到根域的末尾。不要让这个组合的简单性愚弄你——如果你知道网站的基本架构，您可以使用它快速深入到索引中并找到爬网的问题。
3. site:sub.example.com
您还可以向下钻到特定子域，只需使用查询中的完整子域。我通常首先用 #1 来清理所有子域，但 #3 对于追踪发展或暂存可能意外被爬过的子域的情况非常有用。
4. site:example.com inurl:www
“inurl:运算符搜索已被索引的 URL 中的特定文本。您可以将”site:”与”inurl:配对查找完整 URL中的完整子域。你为什么会使用这个而不是 #3呢？一方面，”inurl:”会寻找URL中的任何位置，包括文件夹和页/文件名称的文本。对于跟踪子域这可能不可取。然而，”inurl:”比把子域直接投入主查询灵活得多。您将在例子 #5 和 #6看到为什么。
5. site:example.com -inurl:www
添加运算符 [-] 到大多数运算符中将告诉谷歌搜索除那个特定文本以外的其他任何文本。在这种情况下，通过分离出”inurl:www”，您可以使他变为”-inurl:www”并查找出任何不在”www”子域已被索引的URL。如果”www”是您的规范子域，这对于查找到可能已经被谷歌爬过的非规范URL非常有用。
6. site:example.com -inurl:www -inurl:dev -inurl:shop
我无法列出每一种谷歌所有可能的运算符组合，但是请记住你可以成串使用大多数运算符。您可能怀疑有一些零散的子域，但您不能确定它们是什么。但是，你知道”www.”、”dev.”和”shop.”。您可以成串使用多个”-inurl:”运算符来从查询中删除所有这些已知的子域，只留下那些“流浪者”。
site:amazon.com -inurl:www -inurl:local -inurl:aws
7. site:example.com inurl:https
你不能把一个协议直接放入”site:”(如”https:”，”ftp:”等等）。幸运的是，您可以将”https”放到”inurl:”运算符中，使您可以看到任何谷歌已经编入索引的安全页面。与所有”inurl：”查询一样，这将找到URL中任意的”https”，但除了在协议中，在其他地方看到他的机会比较罕见。
8. site:example.com inurl:param
URL 参数就像是Panda’s dream。如果你在担心搜索排序、筛选器或分页，并且您的站点使用 URL 参数来创建这些页面，那么您可以使用”inurl:”加上参数名称来追踪他们。再次请记住，谷歌将在URL中的任何位置查找该名称，这可能会偶尔令你感到头痛。
专业提示： 尝试上面的示例，您会注意到”inurl:ref”返回任何含有”ref”的URL，而不只是传统的URL参数。当搜索一个同样是常见词的参数时，一定要小心。
9. site:example.com -inurl:param
您可能想要知道多少个搜索页面正在未经分类被索引或谷歌正在跟踪的多少产品页面没有进行大小或颜色挑选——只要添加 [-] 到您的”inurl:”语句以排除该参数。请记住，您可以组合”inurl:”与”-inurl:”，特别是包含某些参数且排除其他的。对于复杂的电子商务网站，单单是这两个组合就可以有几十个用途。
10. site:example.com text goes here
当然，你可以总是将”site:”与旧文本查询运算符组合。这将搜索给定站点内的整个页的内容。同标准查询一样，它本质上是一个逻辑 [AND]，但它又是不太严格的 [AND]——谷歌将尝试匹配所有术语，但那些术语可能会被页面分隔或者你可能得到只包含一些术语的结果。您将看到下面的示例匹配短语”free Kindle books” （免费 Kindle 书）但也匹配像”free books on Kindle”（Kindle 上的免费书籍）这样的短语。
site:amazon.com free kindle books
11. site:example.com “text goes here”
如果您想要搜索完全匹配的短语，请将它放在引号中。这种简单的组合对于追踪您的网站上重复和接近重复复制的内容非常有用。例如，如果你担心你的一个产品说明在几十个页面上重复使用，拉出几个独特的术语，把它们放在引号中。
site:amazon.com “free kindle books”
12. site:example.com/folder “text goes here”
这只是一个提醒您可以把文本（带或不带引号）和几乎任何之前提到过的组合相结合。例如，缩小你的查询到你的博客或商店页面，确定搜索重复项的真正目标。
site:amazon.com/books “harry potter”
13. site:example.com this OR that
如果你特别想要逻辑 [OR]，谷歌确实在查询中支持使用”or”。在这种情况下，你会得到这个域名上被索引的包含”this”或”that”（或两者，正如任何逻辑词 [OR] 一样）的页面。如果您忘记了到底您使用了哪些词或者正要搜索一系列相近关键词时，这将非常有用。
site:amazon.com edward OR jacob
编辑:对TracyMu评论的提示——这是大写字母事关重大的一种情况。“OR”要么使用全大写或”|”符号。如果您使用小写”or”，谷歌会把它作为短语的一部分进行理解。
14. site:example.com “top * ways”
星号 [＊] 可以作为在 Google 查询中用于替换未知文本的通配符。假设您想要查找所有”Top X”文本在你的博客中。您可以使用”site:”定位你的博客文件夹，然后使用”Top＊”只查询那一部分。
专业提示： 通配符 [＊] 运算符将匹配一个或多个单词。所以，”Top ＊ questions “可以匹配”Top 40 Books”（”顶级 40本书”）或者”Top Career Management Books”（”顶级职业生涯管理书籍”）。请尝试上面的示例查询更多示例。
15. site:example.com “top 7..10 ways”
如果你心里有一个特定的数字范围，您可以使用”X…Y”以获得任何范围在从X 到Y内的内容。虽然上面的例子可能有点傻，您可以使用横跨页面范围内的任何数据类型，从产品ID到价格。
site:amazon.com “top 5..10 novels”
16. site:example.com ~word
波浪 [~] 运算符告诉谷歌要在询问中查找与该单词相关的单词。让我们假设您想要在你的博客文章中找到所有与咨询具有类似概念的词。只需添加”~consulting”（”~ 咨询”）到查询，你就会得到更广泛的 Google 认为是相关的术语集。
17. site:example.com ~word -word
通过使用 [-] 排除特定的单词，你可以让 Google 找到任何与其具有相关概念却不仅仅限制于这个词的网页。当您尝试评估您的关键字目标或创建基于关键词研究的新内容时，这很有用。
site:amazon.com ~management -management
18. site:example.com intitle:”text goes here”
运算符”intitle:”只匹配<TITLE></TITLE> 标记中出现的文本。在任何SEO审核抽样调查中我首先做的事情之一就是要使用带有主页标题（或其中的一个独特短语）的这一战术。它对于快速查找主要重复内容这一问题具有难以置信的价值。
site:amazon.com intitle:”harry potter”
19. site:example.com intitle:”text * here”
您几乎可以将任何(12)-(17)中提到的变形与”intitle:”结合——我不会列出所有，但是不要怕富有创造性。这里是一个搜索中使用#14中的通配符的示例，但把它具体到页标题。
site:amazon.com intitle:”the * games”
专业提示： 请记住在”intitle:”后使用引号括住短语，否则谷歌会将视这个查询为一个加直文本的单独字标题。例如，”intitle:text goes here” 将在标题中查找”text” 之外查找页面中任何出现”goes” 与”here”的位置。
20. intitle:”text goes here”
这个不是真正的”site:”组合，但它的如此有用使我不得不收录它。你是否怀疑其他站点可能会将您的内容复制？只要将任何独特的短语放在”intitle:”后的引号中，您就可以找到整个 网站上的副本。这是我发现的最快且最便宜的方法来找到已经偷走您的内容的人。它也是确保您的文章标题是具有唯一性的好方法。
intitle:”fifty shades of grey”
21. “text goes here” -site:example.com
如果你想要更复杂点儿，您可以使用”-site:”且排除任何涉及到的域的副本（包括你自己的）。这可以用直文本或”intitle:”（像 #20中提到的那样）。包括您自己的站点在了解你的网站排名是如何累积方面是有价值的，但减去出您的站点将只允许您查看副本。
“amazon kindle” -site:amazon.com
22. site:example.com intext:”text goes here”
运算符”intext:”查找文档正文中的关键词，但不搜索 <TITLE>标记。文本会显示在标题中，但谷歌不会在那里寻找它。奇怪的是，”intext:”将匹配URL 中的关键词 （似乎像是我的一个失误，但规则不是我制定的)。
site:amazon.com intext:”best book ever”
23. site:example.com ”text goes here” -intitle:”text goes here”
您可能认为 #22 和 #23 一样，但他们还是有细微的差别。如果您使用”intext:”，Google 将会忽略<TITLE>标记，但它不会删除标题中带有”text goes here”（”此处显示文本”）的任何东西。如果您特别想要删除结果中提到的任何标题，那就使用”-intitle:”。
site:amazon.com intext:”best book ever” -intitle:”best book ever”
24. site:example.com filetype:pdf
使用”inurl:”的弊端之一是它将匹配URL 中的任何字符串。因此，例如，搜索”inurl:pdf”，可能返回页叫做”/guide-to-creating-a-great-pdf”。通过使用”filetype:”，您可以指定Google 只搜索文件扩展名。谷歌可以检测某些文件类型（如 PDF），甚至扩展名没有”.pdf”，但其他的（如”html”） 似乎需要已索引文档中的文件扩展名。
25. site:.edu “text goes here”
最后，你可以忽略根域而只关注顶级域 (TLD)。这对于链接建设和竞争性研究比页面 SEO更有用处，但它绝对值得一提。Himanshu，我们的社区成员之一，在他自己的博客上关于使用advanced query operators for link-building(链接建设中的高级查询运算符)有一篇很棒的文章。
为什么没有Allintitle: 和 Allinurl:？
经验丰富的搜索引擎优化者可能会奇怪为什么我遗漏了运算符”allintitle:”和”allinurl:”——简短的回答就是在过去的几年中我发现他们越来越不可靠。在我看来，在引号中使用带有”intitle:”或”inurl:”的关键词是具有同样效果的。
付诸实践
我想给您一个比较省时的案例来显示这些组合并不只是小把戏。我曾与一个相当大的站点合作，我们认为它曾经被谷歌熊猫抓到。它是一个电子商务站点，允许成员甩出自己的店铺（想想 Etsy，但是在一个不同的行业）。我仅仅通过使用”site:” 组合发现一些很有趣的东西。（所有的URL都是虚构的以便保护客户）
(1) site:example.com = 11M
首先，我发现这个网站拥有数量非常大 (1100 万) 的索引页，尤其是相对于网站的整体权重来说。所以，我快速看了看网站的体系结构，并找到了许多的子文件夹。其中之一是”/stores”的子文件夹，其中包含所有会员创建的店铺：
(2) site:example.com/stores = 8.4M
在谷歌索引中有超过 800 万页正是来自那些客户店铺，并且其中许多是空的。我显然没有走错方向。最后，只需通过浏览这些商店中的个别几个，我注意到每个会员创建的店铺都有内部自身的搜索筛选器，所有这些都在URL 中使用”?filter”参数。所以，我进一步缩小了它的范围。
(3) site:example.com/stores inurl:filter = 6.7M
超过 60%的此站点索引页来自搜索筛选器对用户生成的内容。显然，我的工作才刚刚开始，但我仅仅在使用几个简单的查询运算符组合之后，在不到30分钟的时间内在一个非常大的站点上发现了一个关键问题。没花 8 小时来爬行也没有数以百万行的 Excel 数据——我只是不得不运用逻辑并提出正确的问题。
运算符site:有多精确？
一些搜索引擎工作者常常抱怨从”site:”上获得的数据在不同时期和数据库中区别很大。让我们开门见山：他们完全正确。您不应该将任何你获得的数字视为绝对真理。我最近有一个实验可以用来验证它。24 小时内，每隔10分钟我自动查询如下：
- site:seomoz.org
- site:seomoz.org/blog
- site:seomoz.org/blog intitle:spam
即使使用固定的 IP 地址 （假定是单个数据中心），结果的差别也很大，特别是对于广泛的查询来说。24 小时内（144次测量）“site:”组合测试的变化范围如下所示：
- 67,700 – 114,000
- 8,590 – 8620
- 40 – 40
跨两组IP（唯一C-blocks），范围幅度更大（见”/blog”数据）：
- 67,700 – 114,000
- 4,580 – 8620
- 40 – 40
这能意味着”site:”没用吗？不能！只意味着你必须小心翼翼。有时，你甚至不需要精确计数——你只是对找到与讨论中的模式匹配的URL例子感兴趣。即使您需要计数，关键也是要向下深度挖掘。实验中的最窄范围在24 小时内和两个数据中是是完全一致的。越向下深入，效果越好。
您也可以使用相对数字。在我上面的示例中，1100万的总索引页计数是否准确并没有多大关系。重要的是我能够基于一个普通站点结构找出一大部分已被索引的页面。大概那些测量值中的每个测量误差都是差不多的——我只是对每一步的相对百分比感兴趣。当有疑问时，采用多个测量。
请记住，此问题不仅仅存在于”site:”运算符中——谷歌上所有的搜索结果计数都是估计数，尤其是对于较大的数字。Matt Cutts在最近的视频中讨论过这件事，以及有时如何使用第 2 页的计数来减少误差。
