搜索引擎优化步骤(谷歌没有发现重复的URL是怎么解决的？(图))

　　搜索引擎优化步骤(谷歌没有发现重复的URL是怎么解决的？(图))

　　这个问题在.NET的网站上经常遇到，当然其他平台也会有。

　　例如，我们通常会遇到这种 URL：

　　当然，现在搜索引擎会帮你解决这个问题，但最好的办法还是自己先解决。

　　怎么解决：

　　找到这些页面可能有点棘手，因为不同的平台有不同的 URL 结构，所以解决方案有点像猜谜游戏。你可以使用工具模拟蜘蛛爬你的网站，导出excel表格中的爬取记录，过滤Meta标签，搜索网站首页标题，轻松找到重复首页。

　　我更喜欢301重定向，将其他重复页面指向我们确定的首页，也可以通过添加rel=canonical标签来解决这个问题。

　　另一种选择是使用工具，例如 ScreamingFrog，来模拟蜘蛛爬行并找到指向重复页面的链接。然后，您可以编辑这些重复页面以指向正确的 URL，这样您就无需通过 301 并担心失去链接权重。

　　提示：您可以检查每个 URL 的 Google 缓存，看看是否有问题。如果 Google 没有发现重复的 URL 相同，您可以看到此写入 URL 的不同 PR 和缓存日期。

　　3.URL末尾的查询参数

　　这种问题在数据库驱动的电子商务中很常见网站。并不是说其他​​类型的 网站 也没有，但电子商务一般 网站 有大量的产品属性和过滤选项，如颜色、大小等。在这种情况下，用户的 URL点击都是 SEO 友好的，但通常会看到很多链接最终像我下面的示例一样：

　　在此示例中，使用某种颜色作为过滤产品类别的基础。这种过滤方法对用户来说很好，但对搜索引擎来说不是很好，尤其是当客户不按颜色搜索特定产品时。在这种情况下，对于某些 关键词，该 URL 不是一个好的目标网页。

　　当许多参数组合在一起时，可能会导致蜘蛛资源耗尽。更糟糕的是，有时尽管参数的位置不同，但仍返回相同的内容，例如：

　　虽然路径不同，但两个 URL 返回的内容相同，搜索引擎会将这些页面视为重复内容。

　　请记住，Google 会根据您的 网站 PR 分配蜘蛛资源。请确保充分利用这些蜘蛛资源。

　　怎么解决：

　　在继续之前，让我们解决另一个常见的相关问题：URL 可能对搜索引擎不友好，因为它们不是数据库驱动的。在这种特殊情况下，我不担心上面的问题，我更担心蜘蛛资源的浪费和一些不需要的页面被索引。

　　首先要弄清楚蜘蛛要抓取和索引哪些页面。根据您的关键字研究，您需要交叉引用数据库中核心 关键词 的属性。

　　在电子商务网站 中，每个产品都有其关联的属性，这些属性也是数据库的一部分。以下是一些常见的例子：

　　尺寸（即大） 尺寸（大）

　　颜色（即黑色） 颜色（黑色）

　　价格（即£49.99)价格（£49.99）

　　品牌(ieNorthFace)品牌(NorthFace)

　　您的工作是找出哪些属性是 关键词 的一部分，用户可以在其中找到该产品。还要确定用户需要使用的属性组合。这样做之后，你可能会发现搜索率高的关键词是NorthFace+waterproofjackets（防水夹克）。此时，您需要制作一个NorthFace+waterproofjackets 的登陆页面，该页面可以被抓取并被索引。还要确保数据库属性中有一个搜索引擎友好的 URL，不是“waterproof-jackets/?brand=5”，而是“waterproof-jackets/north-face/”。同样在导航结构中的网站中添加这些URL，可以传递PR值，用户很容易找到。

　　另一方面，您可能会发现 Northface+Black 的组合对于 关键词 的搜索量较低。您也不希望对具有 Northface+Black 属性的页面进行爬网和索引。

　　如果您已经知道哪些属性要编入索引，哪些不编入索引，则下一步取决于 URL 是否已编入索引。

　　如果 URL 尚未编入索引，最简单的方法是将 URL 结构添加到 robots.txt 文件中。要做到这一点，可能需要多次尝试使用 RegEx，确保 RegEx 正确以防万一。另外请务必使用 Google 的管理工具 Fetch，请务必注意，将已编入索引的 URL 添加到 Robots.txt 文件不会将它们从索引库中删除。

　　如果 URL 已经被索引，我们需要使用 rel=canonical 标签来解析它。如果不幸的是 网站 正在开发中，则无法进行更改，并且无法解决上述情况的核心问题。这时候，rel=canonical 标签可以帮你暂时解决问题。

　　将 rel=canonical 标签添加到您不想被索引的 URL，然后指向您不想被索引的相关 URL。

　　4.软 404 错误

　　这种情况通常是出乎意料的，用户感知不到差异，但搜索引擎蜘蛛知道差异。

　　软 404 页面意味着你找不到真正的错误页面，并且在 网站 上找不到那些对用户体验不利的地方。从链接构建的角度来看，这两种方法都不是最佳选择。也许您有链接到错误 URL 的传入链接，但是很难跟踪这些链接并重定向到正确的页面。

　　怎么解决：

　　幸运的是，对于 网站 开发人员来说，返回 404 状态比返回 200 简单得多。

　　设计一个很酷的 404 页面对您和您的用户来说都是一种享受。

　　Google 管理工具中有一些功能可以帮助您查找软 404 页面，它会告诉您检测到了哪些软 404 页面。

　　您也可以自己手动检测它，只需使用错误链接进行测试，然后查看您获得的返回状态。

　　我喜欢使用WebSniffer工具来检测，如果你使用的是Chrome浏览器，也可以使用Ayima工具。

　　5.302 重定向而不是 301 重定向

　　网站 开发人员很容易将这种重定向弄错，因为从用户的角度来看，两者之间没有区别，但搜索引擎确实将它们分开处理。

　　301 重定向是永久性的，搜索引擎认为它会将权重传递给新页面。302 重定向是暂时的，搜索引擎认为它不会通过权重，因为搜索引擎认为页面总有一天会回来。

　　怎么解决：

　　要查找具有 302 重定向的 URL，我建议使用 ScreamingFrog 或 IISSEOToolkit，它们可以进行深度爬取。然后检查他们是否应该使用 302 或 301. 重定向

　　要解决此问题，您可以要求 网站 开发人员将规则更改为使用 301 而不是 302 重定向。

　　6.糟糕/旧的站点地图

　　XML网站 地图对于搜索引擎蜘蛛抓取 网站 的所有链接非常有用，尽管有时它不是很有必要。站点地图正确引导搜索引擎。

　　然而，一些 XML 站点地图是一次性的，很快就会过时，导致一些坏链接仍然存在，但新链接没有。

　　理想情况下，XMLsitemap 会定期更新以删除不良链接并添加新链接。对于大型 网站 来说，经常添加新页面很重要。Bing 还表示，他们对站点地图的“脏”也有一个门槛。如果超过这个阈值，他们就不会那么信任这个网站。

　　怎么解决：

　　首先，审核您当前的站点地图是否存在错误链接。你可以使用 MikeKing 这个工具。

　　其次，告诉网站开发人员网站发生了什么，以便他们可以定期更新。根据您的资源确定周期：每天一次、每周一次或每月一次。这些更新需要一些时间来绘制，但从长远来看会为您节省大量时间。

　　这里有一个额外的提示：您可以尝试创建一些只收录最新产品的站点地图，然后更频繁地更新这些特定的站点地图。如果您有足够的开发资源，您还可以创建仅收录未编入索引的 URL 的站点地图。

　　7.robots.txt 文件的指令不正确

　　我最近遇到了一些示例，其中很多页面被抓取和索引，因为它们被锁定在 robots.txt 文件中。抓取这些页面是因为 robots.txt 文件中的说明错误。单独的命令是正确的，但它们一起是错误的。

　　怎么解决：

　　谨慎使用 robots 命令，如果有单独的命令，请确认后面还有哪些其他命令，即使这些命令已经被提及。利用 Google 管理工具的测试功能，它会告诉您它对 robots.txt 文件的反应。

　　8.robots.txt中有隐藏字符

　　我最近为一个客户做了技术审核，发现谷歌管理工具给了我一个警告：“语法不理解”。我检查了文件并对其进行了测试，一切正常。最后我的同事诊断出问题：在文件中发现了一个隐藏字符。

　　怎么解决：

　　解决这个问题很简单。只需重写 robots.txt 文件，再次运行命令，然后再次检查。

　　9.谷歌抓取base64URL

　　这是一个有趣的问题，因为最近一位客户看到管理工具中的 404 错误大幅增加。我们查看并发现几乎所有错误都是这种格式的 URL：/AWYgeW91IGhhdmUgZGVjb2RlZA0KdGhpcyB5b3Ugc2hvdWxkIGRlZmluaXRlbHkNCmdldCBhIGxpZmU/。

　　管理工具会告诉你这些 404 的来源，我们会去页面了解这个 URL 是如何生成的。经过大量挖掘，我们发现这些信任凭证（authenticationtokens）都是由RubyonRails生成的，用于防止跨站请求。网页中有一些代码是 Google 蜘蛛试图抓取的！

　　更大的问题是这些信任凭证（authenticationtokens）是动态生成的并且是唯一的，所以我们找不到它们。

　　怎么解决：

　　幸运的是，对于这种情况，我们可以通过在 robots.txt 文件中添加正则表达式来告诉蜘蛛不要抓取这些 URL。

　　10.服务器配置错误

　　我遇到了 网站 的主要目标网页没有排名的问题。这个页面曾经排名，但在某些时候它下降了。所有页面看起来都不错，没有作弊的嫌疑。

　　经过一番排查和挖掘，原来是服务器配置错误造成的，一个小错误，而这个服务器是一个HTTP头。

　　通常，客户端（浏览器）会发送一个accept header来指示它所理解的文件类型，这几乎不会修改服务器的操作。服务器发送一个 content-form 标头来识别文件是 HTML、PDF 还是 JPEG。

　　此 网站 服务器返回了一个文件类型标头。如果您发送一个以 text/html 开头的接受标头，这就是服务器作为内容类型标头返回的内容。这种行为很奇特，但很难注意到，因为浏览器总是发送以 text/html 开头的接受标头。

　　但是，Googlebot 在抓取时会发送“Accept:*/*”（表示它接受所有内容）。

　　我发现如果我发送 */* 标头，服务器会挂起，因为 */* 不是有效的内容类型，并且服务器会崩溃发送错误的响应。

　　将浏览器的用户代理更改为 Googlebot 不会影响 HTTP 标头，websniffer 等工具不会发送与 Googlebot 相同的标头，因此您根本不会注意到问题。

　　解决此问题几天后，该页面再次被重新索引。