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

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

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

　　比如我们经常会遇到这样的网址：

　　当然，现在搜索引擎也会帮你解决这个问题，不过最好的办法还是第一时间自己解决。

　　如何解决：

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

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

　　另一种解决方案是使用 ScreamingFrog 等工具来模拟蜘蛛爬行并查找指向重复页面的链接。然后您可以编辑这些重复的页面以指向正确的 URL，因此您无需担心通过 301 重定向来减少链接权重。

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

　　3.URL 结束查询参数

　　这种问题在数据库驱动的电子商务中很常见网站。不是其他类型的网站不可用，而是一般电商网站上有很多产品属性和过滤选项，比如颜色，尺寸等。在这种情况下，用户点击在搜索引擎优化方面更友好，但你经常可以看到有很多链接像我下面的例子一样结尾：

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

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

　　虽然路径不同，但这两个网址返回的内容是一样的，搜索引擎会认为这些页面是重复的内容。

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

　　如何解决：

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

　　首先要解决的是哪些页面被蜘蛛抓取和索引。这取决于您的关键字研究。需要交叉引用数据库中核心关键词的属性。

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

　　尺寸（即大）尺寸（大）

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

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

　　品牌（即NorthFace）品牌（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标签添加到您不想被索引的网址，然后指向您不想被索引的相关网址。

　　4.soft 404 错误

　　通常不会出现这种情况。用户感觉不到任何区别，但搜索引擎蜘蛛知道区别。

　　软404页面意味着你找不到真正的错误页面，你也找不到网站上那些对用户体验不利的地方。从链接建设的角度来看，哪种方法不是最佳选择。也许您有指向错误网址的链接，但很难遵循这些链接然后重定向到正确的页面。

　　如何解决：

　　幸运的是，对于网站 开发者来说，返回 404 状态比返回 200 容易得多。

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

　　使用 Google Admin Tool 中的一些功能帮助您查找软 404 页面，它会告诉您已检测到的软 404 页面。

　　您也可以自己手动检查，并使用断开的链接进行测试，以查看您获得的退货状态。

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

　　5.302 重定向而不是 301 重定向

　　网站Developers 很容易把这个重定向弄错，因为从用户的角度来看，两者没有区别，但搜索引擎确实是分开处理的。

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

　　如何解决：

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

　　为了解决这个问题，你可以要求网站developers改变规则，使用301重定向代替302s。

　　6.坏的/旧站点地图

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

　　然而，一些 XML 站点地图是一次性的，很快就会过时，导致一些损坏的链接保留在其中，但新链接不是。

　　理想状态是定期更新 XMLsitemap，删除不良链接并添加新链接。对于大网站，经常添加新页面很重要。 Bing 还表示，他们对站点地图的“脏”也有一个临界值。如果超过这个临界值，他们就不会那么信任这个网站。

　　如何解决：

　　首先，查看您当前的站点地图以找出不良链接。您可以使用 MikeKing 这个工具。

　　其次，告诉网站developers网站的更新，以便他们可以定期更新。根据您的资源确定周期：每天一次、每周一次或每月一次。这些更新需要一些时间，但从长远来看，它将为您节省大量时间。

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

　　7. 给 robots.txt 文件错误的指令

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

　　如何解决：

　　小心使用 robots 命令。如果有单独的命令，请确认接下来还有哪些其他命令，即使这些命令已经被提及。充分利用 Google Admin Tool 的测试功能，它会告诉您它对您的 robots.txt 文件的反应。

　　8.robots.txt 有隐藏字符

　　我最近为一位客户做了一次技术审查，发现 Google Admin Tool 给了我一个警告：“语法不理解”。我检查了文件并测试了它，一切正常。最后，我的同事诊断出问题：在文件中发现了一个隐藏字符。

　　如何解决：

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

　　9.Google 抓取 base64URL

　　这个问题很有意思。最近有客户发现管理员工具中的404错误越来越多。我们看了一下，发现几乎所有的错误都是这种格式的网址：/AWYgeW91IGhhdmUgZGVjb2RlZA0KdGhpcyB5b3Ugc2hvdWxkIGRlZmluaXRlbHkNCmdldCBhIGxpZmU/。

　　管理员工具会告诉你这些404的来源，所以我们去页面看看这个URL是怎么生成的。经过大量挖掘，我们发现这些信任证书（authenticationtokens）都是由RubyonRails生成的，用于防止跨站请求。网页的代码中有一些，谷歌蜘蛛也在尝试抓取这些信息！

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

　　如何解决：

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

　　10.服务器配置不当

　　我遇到了一个问题。某个网站的主登录页面没有排名。此页面以前曾排名，但在某些时候下降了。所有页面看起来都不错，没有作弊的嫌疑。

　　经过大量的排查和挖掘，最终发现是服务器配置错误造成的，一个小错误，服务器有一个HTTP头。

　　通常，客户端（浏览器）会发送一个接受头，表明它可以理解的文件类型，这几乎不会修改服务器的操作。服务器会发送内容格式头来识别文件是HTML、PDF还是JPEG。

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

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

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

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

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