此刻许多人都在做搜刮引擎优化，大的偏向每个人都懂：内容，题目，要害字，外链等等。可是要想比别人做得更好，就需要看细节的器材了。本文列出了一些常见搜刮引擎优化问题，以及详细的解决方案，但愿对相关的职员有所帮忙。1. URL的巨细写这个问题常见于使用.NET技能的网站，事实上是由于网站办事器在设置上就是要相应大写的URL，它不会重定向或者重写小写的版本。随着搜刮引擎在辨认尺度版本和忽略重复版本的技能上有了很大的前进，我们也经常不关注这个问题。可是，搜刮引擎并不完善，以是我们必需要本身下手。若何解决：在IIS 7办事器上有一个URL重写模块，可以帮忙解决这个问题。在这个工具的界面上，你可以执行小写的URL，之后这条规则就会加到网站的设置文件中，从而解决问题。2. 首页有多个版本这个问题也是常常会在.NET的网站上遇到，固然其他的平台也会有。举个例子，我们每每会遇到这种URL：www.example.com/default.aspxwww.example.com/index.htmlwww.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=5www.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. 坏的/旧的SitemapXML网站舆图对于搜刮引擎蜘蛛爬取网站的全部链接长短常有效的，虽然有时辰它不长短常须要。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一样的标头，因此，你底子不会注重到这个问题。改掉这个问题几天后，页面又从头被索引了。常见的搜刮引擎优化问题,以及解决方法-长沙收集推广公司
京ICP备2023016396号-1PoweredByESCLINK.
我要评论