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

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

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

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

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

　　怎么解决：

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

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

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

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

　　3.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页面意味着你找不到真正的错误页面，也找不到网站上那些不利于用户体验的地方。从链接建设的角度来看，哪种方法不是最佳选择。可能是你过来的链接链接到了错误的网址，但是很难跟随这些链接，然后重定向到正确的页面。

　　怎么解决：

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

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

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

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

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

　　5.302 重定向而不是 301 重定向

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

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

　　怎么解决：

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

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

　　6.坏/旧站点地图

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

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

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

　　怎么解决：

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

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

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

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

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

　　怎么解决：

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

　　8.robots.txt中有隐藏字符

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

　　怎么解决：

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

　　9.Google 抓取 base64URL

　　这个问题非常有趣。最近有客户发现管理员工具中的404错误越来越多。我们查看了一下，发现几乎所有的错误都是这种格式的URL：/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 相同的标头，因此您根本不会注意到这个问题。

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