现在很多人都在做搜索引擎优化，大的方向每个人都懂：内容，标题，关键字，外链等等。但是要想比别人做得更好，就需要看细节的东西了。

本文列出了一些常见搜索引擎优化问题，以及具体的解决方案，希望对相关的人员有所帮助。

1. URL的大小写

这个问题常见于使用.NET技术的网站，事实上是因为网站服务器在配置上就是要响应大写的URL，它不会重定向或者重写小写的版本。随着搜索引擎在识别标准版本和忽略重复版本的技术上有了很大的进步，我们也常常不关注这个问题。但是，搜索引擎并不完美，所以我们必须要自己动手。

如何解决：

在IIS 7服务器上有一个URL重写模块，可以帮助解决这个问题。在这个工具的界面上，你可以执行小写的URL，之后这条规则就会加到网站的配置文件中，从而解决问题。

2. 首页有多个版本

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

举个例子，我们通常会碰到这种URL：

www.example.com/default.aspx

www.example.com/index.html

www.example.com/home

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

如何解决：

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

我比较倾向于301转向，将其他重复页面指向到我们确定的那个首页，你也可以通过添加rel=canonical标签来解决这个问题。

另一种方案是使用工具，例如Screaming Frog，来模拟蜘蛛爬行，找出指向重复页面的链接。然后你可以编辑这些重复的页面，指向正确的URL，这样就不需要通过301转向而担心链接权重的降低。

小提示：你可以查看每条URL的谷歌缓存，来看是否有问题。如果谷歌没有发现重复的URL是一样的，你可以看到这写URL不同的PR和缓存日期。

3. URL结尾的查询参数

在有数据库驱动的电子商务网站，这种问题很常见。也并不是说其他类型的网站没有，但是一般电子商务网站上有大量的产品属性和筛选选项，如颜色，大小等。在这种情况下，用户点击的URL在搜索引擎优化方面都比较友好，但是可以常常看到有很多链接的结尾是像我下面的例子这样的：

www.example.com/product-category?colour=12

在这个例子中，某种颜色是作为筛选产品类别的依据。这种筛选方法对于用户来说是很好的，但是对搜索引擎就不好了，尤其是有时候客户并不是用颜色来搜索某个特定的产品。在这种情况下，对某些关键词来说，这个URL就不是一个好的登陆页。

当很多的参数结合起来的时候，可能会导致蜘蛛资源被用尽。更糟糕的是，有时候尽管参数的位置不一样，但是却返回相同的内容，例如：

www.example.com/product-category?colour=12&size=5

www.example.com/product-category?size=5&colour=12

尽管路径不一样，但是这两个URL返回的是相同内容，搜索引擎会认为这些页面是重复内容。

请记住，谷歌是根据你网站的PR值来分配蜘蛛资源的。请确保这些蜘蛛资源有充分的利用。

如何解决：

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

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

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

Size (i.e. Large)  尺寸（大）

Colour (i.e. Black) 颜色（黑色）

Price (i.e. £49.99) 价格 （£49.99）

Brand (i.e. North Face) 品牌（North Face）

你的工作是要找出哪些属性是关键词的一部分，用户可以找到这个产品。还要确定用户需要使用哪些属性的组合。这样做后，你可能会发现一个搜索量很高的关键词是North Face + waterproof jackets（防水夹克）。这时，你需要做一个被爬行和索引的North Face + waterproof jackets登陆页。还要确保数据库属性中有一个对搜索引擎友好的URL，不是"waterproof-jackets/?brand=5" 而是"waterproof-jackets/north-face/."还要将这些URL添加在网站的导航结构中，PR值可以传递，用户也很容易找到。

另一方面，你可能会发现Northface+Black这个组合的关键词搜索量很低。你也就不会想要Northface+Black这两个属性的页面被爬行和索引。

如果你已经清楚哪些属性是要被索引的，哪些不需要，下一步行动要不要开始取决于URL有没有被索引。

如果URL还没有被索引，最简单的方法是把URL结构添加到robots.txt文件中。要完成这个可能需要多尝试一下RegEx，请确保RegEx是正确的来以防万一。此外一定要使用谷歌的管理员工具Fetch， 需要注意的是，把已经被索引的URL添加到Robots.txt文件中不会让 他们从索引库中被删除。

如果URL已经被索引，我们需要用rel=canonical标签来解决。如果不巧网站正在开发中，你不能进行修改的工作，你会像上面遇到的情况一样不能解决核心问题，这时候，rel=canonical标签可以帮助你延迟一点解决问题。

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

4. 软404错误

这种情况通常不在预料中，用户没有觉得什么不一样，但是搜索引擎蜘蛛知道不同之处。

软404页面意味着你发现不了真正的错误页面，也找不到网站上那些地方对用户体验不好。从链接建设的角度看，哪个方法都不是最佳选择。可能你有过来的链接链到了坏的URL上，但是却很难追踪这些链接，然后重定向到正确的页面。

如何解决：

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

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

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

你也可以自己手动检测，随便用一个坏链接来测试，看看你得到的返回状态是什么。

我很喜欢用Web Sniffer这个工具来检测，如果你是用Chrome浏览器的话，也可以用Ayima这个工具。

5. 302重定向而不是301重定向

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

301重定向是永久性的，搜索引擎认为它会传递权重到新的页面。302重定向是临时的，搜索引擎认为它不会传递权重，因为搜索引擎觉得某天这个页面又会回来。

如何解决：

要找到302重定向的URL，我建议用Screaming Frog或者是IIS SEO Toolkit这两个工具，它们可以进行深度爬行。然后检查看它们是应该用302重定向还是301.

要解决这个问题，你可以要求网站开发人员改变规则，用301重定向而不是302。

6. 坏的/旧的Sitemap

XML网站地图对于搜索引擎蜘蛛爬取网站的所有链接是非常有用的，虽然有时候它不是非常必要。Sitemap可以正确引导搜索引擎。

但是，一些XML sitemaps是一次性的，很快就过时了，导致一些坏链接还在里面，但是新的链接却没有。

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

如何解决：

首先，审核你当前的sitemap,找出坏链接。可以用Mike King这个工具。

其次，告诉网站开发人员网站的动态，以便定期更新。根据你的资源来确定周期：每天一次，每周一次或者是每月一次。这些更新绘画一些时间，但是从长远来说会节省你很多时间的。

这里有个额外的提示：你可以尝试创建一些sitemap,只包含最新的产品，然后以更高的频率来更新这些特定的sitemap。如果你有足够的开发资源，也可以创建一个sitemap，只包含没有索引的URL。

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

最近遇到一些例子，很多页面被爬取和索引是因为他们被锁定在robots.txt文件中。这些页面之所以会被爬取是因为robots.txt文件中的指令是错误的。单独的命令是正确的，但是结合在一起是就是错误的。

如何解决：

谨慎使用robots命令，如果有单独的指令，要确认接下来的其他指令是什么，即使是这些指令已经被提到过。充分利用谷歌管理员工具的测试功能，它会告诉你它对你的robots.txt文件的反应。

8. robots.txt中有隐藏字符

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

如何解决：

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

9. 谷歌爬行 base64 URL

这个问题很有趣，最近一个客户发现在管理员工具中发现404错误在大量增加。我们一看，发现几乎所有的错误都是这个格式的URL：/AWYgeW91IGhhdmUgZGVjb2RlZA0KdGhpcyB5b3Ugc2hvdWxkIGRlZmluaXRlbHkNCmdldCBhIGxpZmU/。

管理员工具会告诉你这些404的来源，我们就去页面找这个URL是怎样生成的。经过大量的挖掘，我们发现这些信任凭证（authentication tokens）都是Ruby on Rails生成的，是为了防止跨站点请求。在网页的代码中有一些，谷歌蜘蛛还试图去爬取这些信息！

更大的问题是，这些信任凭证（authentication tokens）是动态生成的，并且独一无二，因此我们找不到。

如何解决：

针对这个情况，很幸运，我们可以通过添加Regex到robots.txt文件中，告诉蜘蛛不要爬行这些URL。

10. 服务器配置不当

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

经过大量的调查和挖掘，最后发现原来是由于服务器的错误配置，一个小小的错误造成的，这个服务器是HTTP标头的。

通常，客户端（浏览器）会发送接受标头，指出它能理解的文件类型，这几乎不会修改服务器的操作。服务器端会发送内容形式标头，来识别文件是HTML,PDF或者是JPEG之类的。

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

但是，Googlebot在爬行的时候会发送"Accept:*/*"（表示它接受所有的东西）。

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

把浏览器的用户代理改成Googlebot并不会影响HTTP标头，像websniffer这种工具不会发送跟Googlebot一样的标头，因此，你根本不会注意到这个问题。

改掉这个问题几天后，页面又重新被索引了。