回到主页

技术SEO文艺复兴:SEO在网络力学中被遗忘角色的原因和方法

Web技术及其采用正在以疯狂的速度发展。内容是每种类型的团队和代理商都在玩的游戏,所以我们都在争夺一块馅饼。与此同时,技术搜索引擎优化比以往任何时候都更加复杂和重要,而且很多搜索引擎优化讨论已经回避了其不断增长的技术组件,转而支持内容营销。

因此,搜索引擎优化正在经历复兴,其中技术组件回到最前沿,我们需要做好准备。与此同时,一些思想领袖已经声明现代SEO不是技术性的。这些陈述歪曲了新技术背后萌芽的机遇和问题。它们还有助于SEO作为营销领域不断增长的技术知识差距,并使许多SEO难以解决我们的新问题。

由此产生的知识差距在过去几年中一直在增长,这使我第一次“参观”演示文稿。自1月份以来,我一直以某种形式提供我的技术SEO文艺复兴时期的演讲,因为我认为围绕事情发生变化的事实进行对话非常重要,如果他们没有账户,许多组织和网站可能会落后于曲线对于这些转变。发生了很多事情,证明自从我开始发表演讲以来我一直走在正确的轨道上,所以我认为值得讨论继续讨论。我们可以?

SEO的精简历史(据我所知)

有趣的是,近年来技术搜索引擎优化已经成为一种垂死的品种。有一段时间它是先决条件。

就个人而言,我于1995年开始在网上工作,担任微软的高中实习生。与其他在网络上工作的人一样,我的头衔是“网站管理员”。这是在网络专业分裂成无数学科之前。没有前端与后端。没有DevOps或UX用户。你只是一个网站管理员。

当时,在雅虎,AltaVista,Lycos,Excite和WebCrawler进入全盛时期之前,我们通过点击滚动条,使用Gopher,Usenet,IRC,杂志和电子邮件发现了网络。大约在同一时间,IE和Netscape参与了浏览器大战,你有多种客户端脚本语言可供选择。框架风靡一时。

然后搜索引擎出现了。说实话,在这个时候,我并没有真正考虑过搜索引擎是如何运作的。我只知道Lycos给了我一些我认为最值得信赖的结果。那时,我不知道有这个黑社会的人操纵这些门户进行竞标。

输入SEO。

搜索引擎优化是由这些网站管理员的横截面产生的,这些网站管理员是计算机科学家的子集,他们理解信息检索的其他深奥领域以及那些“在互联网上快速致富”的人们。这些互联网木偶操作者本质上是魔术师,他们在网络的几乎黑暗的角落里交换技巧和窍门。他们基本上是通过关键词填充,内容旋转和隐藏真实内容从搜索引擎中榨取美元的书呆子。

然后谷歌出现在派对上。

谷歌早期的更新开始了猫捉老鼠的游戏,这将缩短一些永久的假期。为了将过去15年的搜索引擎历史缩小为一个简短的段落,Google将游戏从内容污染和链接操作改为通过从佛罗里达州开始的一系列更新以及最近的Panda和Penguin。在熊猫和企鹅的后续改进之后,SEO行业的面貌发生了巨大变化。许多最傲慢的“我可以排名任何东西”的SEO都变成了白帽子,创办了软件公司,或减少了损失并做了别的事情。这并不是说黑客和垃圾邮件链接仍然不起作用,因为他们当然经常这样做。相反,谷歌的复杂性最终使许多不再忍受过山车的人望而却步。

同时,人们开始从不同的学科进入SEO。好吧,人们总是从不同的专业历史进入搜索引擎优化,但它开始吸引更多的实际“营销”人。这很有意义,因为SEO作为一个行业已经大量转向内容营销焦点。毕竟,我们必须以某种方式得到这些链接,对吧?

当然,这导致很多营销人员向市场营销人员营销营销人员,他们做出了“现代SEO几乎没有技术专长”的陈述。

或者我最喜欢的一个,可能会引起更多的愤怒:“SEO就是化妆。”

虽然我自然不同意这些陈述,但我理解为什么这些人会在他们的思想领导中贡献这些想法。无论我过去曾与两位先生以某种身份合作并了解他们对内容的倾向,他们所提出的核心观点是许多现代内容管理系统确实占据了我们历史悠久的许多SEO最佳实践。Google非常擅长了解您在内容中谈论的内容。最终,您的组织需要专注于为您的用户群制作有意义的内容,以便您可以提供有竞争力的营销。

如果你还记得我最后一次试图在SEO空间中进行范式转换的情况,你会认为我从根本上同意这个想法是正确的。但是,不要忽视技术环境发生变化这一事实。技术SEO是入场的价格。或者,引用Adam Audette,“ SEO应该是看不见的 ”,而不是化妆。

网络技术的变化正在引发技术复兴

在SEO中,我们经常批评开发人员总是希望部署新的闪亮东西。展望未来,重要的是我们要了解新的闪亮事物,以便我们能够更有效地优化它们。

SEO总是对JavaScript有一种健康的恐惧,而且有充分的理由。尽管搜索引擎已经采用了与我们在浏览器中看到它的方式相同的抓取网络技术至少10年,但它始终是关于该内容是否实际被抓取,更重要的是被索引的一个废话。

当我们最初在2011年检查无头浏览的想法时,集体反应是计算费用大规模禁止它。但似乎即使的话,谷歌认为足够的网络使用JavaScript,这是一个值得投资呈现的。

随着时间的推移,越来越多的人会研究这个想法; 最终,这位来自黑客新闻的前Google员工的评论表明,这一直是谷歌认为需要征服的事情:

这实际上是我从2006年到2010年在谷歌的主要角色。 
我的第一个测试案例之一是华尔街日报的中文页面档案的特定日期范围,其中所有实际文本都在JavaScript字符串文字中,并且在我改变之前,谷歌认为所有这些页面都有相同的内容......只是导航样板。由于华尔街日报没有为其英文网页做这件事,我最好的猜测是他们不是试图隐藏搜索引擎中的内容,而是试图解决一些错误呈现(或丑陋)中文的旧浏览器错误文本,但不知何故通过JavaScript渲染文本避免了错误。 
真正有趣的部分是(1)试图确保渲染是确定性的(因此相同的页面看起来总是与Google相同以用于重复消除目的)(2)检测我们何时显着偏离真实浏览器行为(因此我们没有生成爬虫的太多无意义的URL或太多的虚假重定向),以及(3)在某个时候使模拟的浏览器看起来有点像IE和Firefox(以及后来的Chrome),所以我们没有得到大量的页面说“回来使用IE”呃“请下载Firefox”。 
我最终修改了SpiderMonkey的字节码调度,以帮助检测模拟浏览器何时进入杂草并且可能产生废话。 
我在IE,FireFox和Chrome中发现不同的JavaScript事件的顺序时遇到了很多麻烦。事实证明,如果点击刷新按钮,某些页面实际上会在新加载的页面和页面之间以不同的顺序触发事件。(这是当我在按下浏览器的重新加载按钮时按住shift来学习,就像它是一个新的页面提取一样。) 
在某些时候,一些SEO发现random()总是返回0.5。我不确定是否有人发现JavaScript总是在2006年夏天看到日期,但我认为这已经改变了。我希望他们现在使用所有加载的javascript和页面文本的密钥加密哈希来设置随机种子和日期,因此它是确定性的但很难进行游戏。(您可以通过在当前时间添加页面内容的HMAC(一个月内的模数秒),将该时间向下舍入到一个月的边界,确定一个月的日期和不同页面的日期在不同时间跳转,然后减去你之前添加的值。这可以防止过多的索引流失一次切换所有日期,并为每个页面提供唯一的日期。)

现在,考虑一下来自BuiltWith的Web上的这些JavaScript使用情况统计信息:

JavaScript显然是留下来的。大多数网络都使用它来以某种形式呈现内容。这意味着如果Google无法理解使用JavaScript呈现的页面上的内容,那么搜索质量可能会随着时间的推移而直线下降。

此外,谷歌自己的JavaScript MVW框架AngularJS近来已被广泛采用。几个月前,当我参加谷歌的I / O大会时,由于他们为网络带来的速度和灵活性,Progressive Web Apps和Firebase的最新进展受到了加剧。您只能期望开发人员能够做出更强有力的推动。

遗憾的是,尽管BuiltVisible对该主题做出了巨大贡献,但在SEO领域尚未对Progressive Web Apps,单页面应用程序和JavaScript框架进行过充分的讨论。相反,有关于301s和302s的争论。也许最新的采用率和不同垂直领域的PWA,SPA和JS框架的激增将会改变这种情况。在iPullRank,我们与许多转向Angular的公司合作过; 有关这个特定主题的讨论很多。

此外,Facebook对JavaScript MVW框架的贡献React正在采用与开发过程中灵活性非常相似的速度和优势。

但是,关于SEO,Angular和React之间的关键区别在于,从一开始,React就内置了renderToString函数,允许内容从服务器端正确呈现。这使得React页面的索引化问题变得微不足道。

AngularJS 1.x中,而另一方面,已经在生产经历的搜索引擎优化的最佳实践,其中您预渲染使用模拟浏览器驱动的快照设备如页面Prerender.io,Brombone等,这是有点讽刺意味,因为它是谷歌自己的产品。稍后会详细介绍。

查看源已死

由于采用了这些JavaScript框架,使用View Source检查网站代码是一种过时的做法。您在View Source中看到的不是计算文档对象模型(DOM)。相反,您在浏览器处理之前会看到代码。对于您可能需要以不同方式查看页面代码的原因缺乏了解是另一个实例,其中更详细地了解Web工作方式的技术组件是否更有效。

根据页面的编码方式,您可能会在实际内容的位置看到变量,或者在页面完全加载后您可能看不到已完成的DOM树。这是一个根本原因,一旦SEO听到页面上有JavaScript,建议确保所有内容在没有JavaScript的情况下可见。

为了进一步说明这一点,请考虑Seamless.com的此View Source视图。如果您在此页面上查找元描述或rel-canonical,您将在实际副本的位置找到变量:

如果您在其他浏览器中查看Chrome DevTools或Inspect Element的Elements部分中的代码,您将找到完全执行的DOM。您将看到变量现在已填入副本。rel-canonical的URL在页面上,元描述也是如此:

由于搜索引擎以这种方式爬行,如果您默认只使用View Source来检查网站代码,您可能会错过完整的故事。

HTTP / 2即将推出

谷歌最重要的一点是页面速度。了解网络如何影响页面速度绝对是一个必须成为有效的SEO。

在HTTP / 2发布之前,超文本传输​​协议规范在很长一段时间内都没有更新。事实上,自1999年以来我们一直在使用HTTP / 1.1 。HTTP / 2与HTTP / 1.1有很大的不同,我鼓励您阅读它,因为它将对网络的速度做出巨大贡献。

很快,最大的区别之一是HTTP / 2将使用每个源一个TCP(传输控制协议)连接并“多路复用”流。如果你曾经看过Google PageSpeed Insights突出显示的问题,你会发现总是出现的一个主要问题是限制HTTP请求的数量/这就是多路复用有助于消除的问题。HTTP / 2打开与每个服务器的一个连接,同时在其上推送资产,通常根据初始资源确定所需资源。由于浏览器需要使用传输层安全性(TLS)来利用HTTP / 2,因此Google很可能会在不久的将来进行某种推动,以使网站采用它。毕竟,速度和安全性在过去五年中始终贯穿始终。

最近,越来越多的托管服务提供商一直在强调他们正在提供HTTP / 2,这可能就是为什么今年它的使用量大幅增加的原因。HTTP / 2的优点在于大多数浏览器已经支持它,除非您的站点不安全,否则您不必为此启用它。

绝对保持你的雷达上的HTTP / 2,因为它可能是谷歌一直在推动的高潮。

搜索引擎优化工具落后于搜索引擎

当我批评这一点时,SEO工具总是落后于搜索引擎的能力。但是,这是可以预料到的,因为SEO工具是由较小的团队构建的,最重要的事情必须优先考虑。缺乏技术理解可能会导致您相信您使用的工具信息不准确时。

当您查看Google自己的一些文档时,您会发现我最喜欢的一些工具与Google的规格不符。例如,Google允许您在HTTP标头中指定hreflang,rel-canonical和x-robots。SEO工具检查这些指令的能力缺乏一致性。

您可能已经对网站进行了审核,发现很难确定网页偏离索引的原因。这很可能是因为开发人员正在关注Google的文档并在HTTP标头中指定一个指令,但是您的搜索引擎优化工具没有表现出来。实际上,通常最好在HTTP标头级别设置这些,而不是通过用它们填充每个页面的<head>来为下载时间添加字节。

尽管计算费用很高,谷歌仍然无法抓狂,因为他们认识到很多网络都是通过JavaScript改变的。最近,Screaming Frog转向使用JS渲染整个页面:

据我所知,其他爬行工具都没有这样做。我确实认识到,由于云服务器的使用是基于时间的,并且在浏览器中渲染页面所花费的时间比仅下载主HTML文件所需的所有搜索引擎优化工具的成本要高得多。多少时间?

实际上,还有更多的时间。我刚写了一个简单的脚本,只使用cURL和HorsemanJS加载HTML。cURL平均下载5.25毫秒来下载雅虎主页的HTML。另一方面,HorsemanJS平均花费25,839.25毫秒或大约26秒来渲染页面。这是每小时爬网686,000个网址和138个网址之间的区别。

理想情况下,搜索引擎优化工具将提取网站上使用的技术或在几个页面上执行某种DIFF操作,然后提供无头爬行的选项,如果它被认为是值得的。

最后,谷歌在移动设备上的规格也说你可以使用客户端重定向。我不知道跟踪这个的工具。现在,我不是说利用JavaScript重定向移动是您应该这样做的方式。相反,谷歌允许它,所以我们应该能够轻松地检查它。

幸运的是,在SEO工具赶上之前,Chrome DevTools确实处理了很多这些事情。例如,HTTP请求和响应标头部分将显示x-robots,hreflang和rel-canonical HTTP标头。

您还可以使用DevTools的GeoLocation Emulator来查看Web,就像您在不同的位置一样。对于那些对nearEquals查询参数有美好回忆的人,这是另一种了解精确位置排名的方法。

Chrome DevTools还允许您插入Android设备并通过浏览器控制它。从SEO的角度来看,有许多用例,但是Simo Ahava写了一篇很棒的教学文章,介绍如何使用它来调试移动分析设置。如果你有Mac,你可以在Safari的iOS设备上做同样的事情。

2016年真正的排名是什么?

排名是一件有趣的事情,如实,已经有一段时间了。当我在网站管理员工具/搜索控制台中推出时,我本人对平均排名的想法有所抵制,但平均排名实际上比我们在标准排名工具中看到的更有意义。让我解释。

SEO工具根据现实世界中实际不存在的情况来提取排名。除非您明确指定位置,否则刮掉谷歌的机器应该是干净的,否则不可知。实际上,这些工具可以了解排名对于第一次搜索的用户而言没有Google的上下文或历史记录。排名软件模拟了第一次登录网络的用户,他们认为要做的第一件事是搜索“4英尺钓鱼竿”。然后他们不断寻找一系列其他相关和/或无关的查询实际点击结果。理所当然的。某些软件可能会做其他事情来尝试和模拟该用户,但无论哪种方式,他们收集的数据都不一定反映真实用户看到的内容。最后,

底线是我们忽略了真实的用户环境,特别是在移动领域。

允许您跟踪移动排名的排名工具通常允许您定义一个上下文,或者他们只需指定“移动电话”作为选项。辛迪克鲁姆的研究表明该SERP功能和排名将根据用户代理,手机品牌和型号,浏览器,甚至是内容的组合是不同自己的手机。

排名工具也忽略了用户的选择现实。我们正处在一个包含SERP的元素很多的时代,#1根本就不是#1。在某些情况下,#1是页面上的第8选择,远远低于首选。

由于AdWords有第四个广告位,有机产品被推到了最低点,用户无法确定有机产品和付费产品之间的差异,在有机产品中排名第一并不意味着它曾经用过的产品。因此,当我们查看告诉我们排名第一的排名报告时,我们经常会欺骗自己,以了解将会带来什么样的结果。当我们向客户报告时,我们不会关注可操作性或用户环境。相反,我们完全专注于虚荣。

当然,排名不是业务目标; 它们是衡量潜力或机会的标准。无论我们多少谈论他们不应该成为主要的关键绩效指标,排名仍然是SEO所指出的东西,以显示他们正在努力。因此,我们应该考虑将有机排名视为与其周围的SERP特征相关。

换句话说,我希望看到排名包括标准的有机1-10排名以及关于付费,本地包和特色片段的绝对位置。其他任何事情都忽略了用户绝对可用的选择的影响。

最近,我们已经看到一些升级到这种效果,Moz对它们如何呈现排名功能进行了重大改变,我知道其他一些工具也突出了有机功能。谁将是第一个突出集成搜索上下文的人?毕竟,许多用户不知道其中的差异。

什么是2016年的隐形衣?

伪装被正式定义为显示与用户不同的搜索引擎。当Google允许自适应和响应式网站以及无头和基于文本的网站时,这意味着什么?当Googlebot尊重304响应代码时,这意味着什么?

在自适应和响应模型下,通常会出现针对不同上下文显示更多或更少内容的情况。这对于响应很少见,因为它意味着根据定义重新定位和调整内容大小,但是一些实现可能会减少内容组件以使查看上下文工作。

如果网站通过更改显示的内容来响应屏幕分辨率,并且显示的内容超出了Googlebot呈现的分辨率,那么他们如何将其与隐藏真实内容区分开来?

类似地,304响应代码是向客户端指示内容自上次访问以来未被修改的方式; 因此,没有理由再次下载它。

Googlebot坚持使用此响应代码,以防止带宽占用。那么什么阻止网站管理员获取索引的一个版本,更改它,然后返回304?

我不知道在这一点上对这些问题有明确的答案。然而,根据我在野外看到的情况,这些已被证明是仍然致力于测试和学习的技术SEO的机会。

爬行

内容作为SEO必须检查的基本组件的可访问性没有改变。什么改变是需要进入它的分析工作的类型。已经确定Google的爬行功能已经大大改善,像Eric Wu这样的人通过JSCrawlability.com等实验在表现这些功能的细节方面做得非常出色。

同样,我想尝试一下实验,看看Googlebot加载页面后的行为方式。使用LuckyOrange,我尝试在访问该页面时捕获Googlebot的视频:

我在尚未编入索引的页面上安装了LuckyOrange脚本,并将其设置为仅在用户代理包含“googlebot”时才触发。一旦设置完毕,我就会从Search Console调用Fetch and Render。我希望看到鼠标滚动或尝试填写表格。相反,光标从未移动过,Googlebot仅在页面上停留了几秒钟。后来,我看到Googlebot再次点击该URL,然后不久该页面出现在索引中。在LuckyOrange中没有第二次访问的记录。

虽然我想在更大的网站上进行更广泛的测试以验证这一发现,但我从这个轶事经验中得出的假设是,Googlebot会来到该网站并确定是否需要使用无头网页来抓取网页/网站履带。基于此,他们将使用适合该作业的爬虫回到该站点。

我鼓励你试一试。你不必使用LuckyOrange - 你可以使用HotJar或其他任何类似的东西 - 但这是我的LuckyOrange的代码:

jQuery(function(){ Window .__ lo_site_id = XXXX; if(navigator.userAgent.toLowerCase()。indexOf('googlebot')>) { var wa = document.createElement('script'); wa.type ='text / javascript'; wa.async = true; wa.src =('https'== document.location.protocol?'<a href="https://ssl"> https:// ssl </a>':'<a href =“http:// cdn“> http:// cdn </a>')+'.luckyorange.com / w.js'; var s = document.getElementByTagName('script')[0]; s.parentNode.insertBefore(WA,S); //用Googlebot标记它 window._loq = window._low || []; window._loq .push([“tag”,“Googlebot”]); } ));

然而,故事的寓意是谷歌所看到的,他们看到它的频率等等仍然是我们作为SEO所要回答的主要问题。虽然它不性感,但日志文件分析是绝对必要的练习,特别是对于大型网站的SEO项目 - 由于网站的复杂性,现在可能比以往任何时候都要多。我鼓励你听听Marshall Simmonds所说的一切,特别是在这个问题上。

为此,谷歌搜索控制台中的抓取统计数据完全没用。这些图表告诉我到底是什么?太棒了,谢谢谷歌,你在二月份的某个时候爬了一堆页面。凉!

有许多日志文件分析工具,从ELK堆栈中的Kibana到Logz.io等其他工具。然而,Screaming Frog团队最近发布了他们的日志文件分析器,在这个领域取得了突飞猛进的发展。

值得注意的是,这个工具是如何轻松处理数百万条记录的,我希望这也是Spider工具的一个标志。无论是谁制作这个工具,它帮助你解锁的见解在实际发生的事情上都是非常有价值的。

去年我们有一位客户坚持认为他们在有机产品上的损失不是企鹅更新的结果。他们认为这可能是由于关闭了可能导致搜索量,或季节性或其他因素的其他传统和数字广告系列。通过拉动日志文件,我可以将所有数据从所有广告系列运行时分层,并显示它们都不是那些; 相反,Googlebot活动在Penguin更新之后立即大幅下降,同时也是有机搜索流量。日志文件明确地显示出来。

它遵循传统上持有的SEO智慧,Googlebot基于具有指向它们的最高质量和/或数量的链接的页面进行爬行。在为我们的最新客户分层社交份额,链接和Googlebot访问次数时,我们发现社交份额和抓取活动之间的关联比链接更多。在下面的数据中,链接最多的网站部分实际上被抓取的次数最少!

这些是您可能只是在猜测而不花时间深入挖掘日志文件的重要见解。

日志文件如何帮助您了解AngularJS

与任何其他网页或应用程序一样,每个请求都会在日志中生成记录。但是根据服务器的设置方式,AngularJS设置可以提供大量的课程,特别是如果您使用其中一种快照技术进行预渲染。

对于我们的一个客户,我们发现通常当快照系统需要刷新其缓存时,它花费的时间太长而且超时。Googlebot将这些理解为5XX错误。

这种行为会导致这些页面脱离索引,随着时间的推移,我们看到页面在排名之间来回跳跃并且完全消失,或者网站上的另一个页面取而代之。

此外,我们发现有很多情况,其中Googlebot被误认为是人类用户。反过来,Googlebot服务于AngularJS实时页面而不是HTML快照。然而,尽管Googlebot没有看到这些页面的HTML快照,但这些页面仍在进入索引并且排名很好。因此,我们最终与客户进行了测试,以删除网站各部分的快照系统,实际上有机搜索流量得到了改善。

这与谷歌在他们的AJAX Crawling计划的弃用声明中所说的一致。他们能够访问使用JavaScript呈现的内容,并将索引在加载时显示的任何内容。

这并不是说HTML快照系统不值得使用。预呈现网页的Googlebot行为是,它们往往更快,更频繁地被抓取。我最好的猜测是,这是由于爬行在执行时计算成本较低。总而言之,我认为使用HTML快照仍然是最佳做法,但绝对不是Google看到这些类型网站的唯一方式。

根据Google的说法,您不应仅为他们提供快照,而应提供用户获得的速度增强功能。

一般而言,网站不应仅为Google预呈现网页 - 我们希望您可以预先呈现网页以提高用户的效果,并遵循渐进式增强指南。如果您预先呈现网页,请确保提供给Googlebot的内容与用户的体验相匹配,包括其外观和交互方式。提供Googlebot与普通用户不同的内容会被视为隐藏真实内容,并且会违反我们的网站管理员指南。

这些是高度技术性的决策,对有机搜索可见性有直接影响。根据我在采访SEO的经验,去年加入我们的iPullRank团队,很少有人理解这些概念,或者能够诊断HTML快照的问题。这些问题现在已司空见惯,并且随着这些技术继续被采用,这些问题将继续增长。

但是,如果我们也要向用户提供快照,那么它就会引出一个问题:为什么我们首先要使用这个框架?当然,技术堆栈决策超出了SEO的范围,但您可能会考虑不需要像MeteorJS这样的设备的框架。

或者,如果您肯定想坚持使用Angular,请考虑支持新Angular Universal的Angular 2。Angular Universal提供“同构”JavaScript,这是另一种说法,它预先在服务器端呈现其内容。

在所有疯狂的框架出现令人困惑的头脑之前,谷歌对新兴技术有一种思路 - 那就是“渐进式增强”。随着许多新的物联网设备即将出现,我们应该建立网站来为最低的内容提供服务功能的共同点,为可以渲染它们的设备保存铃声和口哨声。

如果您从头开始,一个好的方法是仅使用HTML构建网站的结构和导航。然后,一旦您拥有了网站的页面,链接和内容,您就可以使用AJAX为外观和界面增添趣味。Googlebot会很高兴看到HTML,而拥有现代浏览器的用户可以享受您的AJAX奖励。

换句话说,确保每个人都可以访问您的内容。向Fili Weise致敬,提醒我。

刮痧是SEO分析的根本缺陷核心

刮刮是我们的SEO工具所做的一切的基础。cURL是用于制作和处理HTTP请求的库。最流行的编程语言具有对库的绑定,因此,大多数SEO工具利用库或类似的下载网页。

可以认为cURL的工作类似于从FTP下载单个文件; 就网页而言,这并不意味着可以完整地查看页面,因为您没有下载所有必需的文件。

这是大多数搜索引擎优化软件的一个基本缺陷,原因完全相同。查看源文件不再是查看页面代码的有效方式。由于在加载时会发生许多JavaScript和/或CSS转换,并且Google正在使用无头浏览器进行爬网,因此您需要查看代码的Inspect(元素)视图,以了解Google实际可以看到的内容。

这是无头浏览发挥作用的地方。

PhantomJS是一个比较流行的无头浏览库。SEO世界之外的许多工具都是使用这个库编写的,用于浏览器自动化。Netflix甚至还有一个用于抓取和截取名为Sketchy的截图。PhantomJS是从一个名为QtWebkit的渲染引擎构建的,也就是说,它与Safari(以及谷歌将它分成Blink之前的Chrome )所基于的代码分开。虽然PhantomJS缺少最新浏览器的功能,但它具有足够的功能来支持我们进行SEO分析所需的大部分内容。

正如您从GitHub存储库中看到的那样,HTML快照软件(如Prerender.io)也是使用此库编写的。

PhantomJS有一系列包装库,可以很容易地使用各种不同的语言。对于那些有兴趣与NodeJS一起使用的人,请查看HorsemanJS。

Headless Chromium是无头浏览器派对的最新和更有资格的补充。您可能已经猜到,这是Chrome浏览器的无头版本。如果我是一个博彩人,我会说我们在这里看到的是Googlebot的某种低调的分支。

为此,这可能是SEO公司在未来重新考虑他们自己的爬行基础设施时应该考虑的事情,如果仅针对高级用户。

使用浏览器内部抓取来执行您的工具无法做到的事情

尽管许多搜索引擎优化工具无法检查完全呈现的DOM,但这并不意味着您作为个体搜索引擎优化不得不错过。即使没有利用无头浏览器,Chrome也可以变成一台只需要一点点JavaScript的抓取机器。我在“ 如何在网上抓每一页 ”帖子中详细讨论了这个问题。使用一点点jQuery,您可以有效地从页面选择和打印任何内容到JavaScript控制台,然后将其导出到您喜欢的任何结构的文件中。

通过这种方式刮擦,您可以跳过许多使网站认为您是真实用户所需的编码,例如必须在服务器端进行的身份验证和cookie管理。当然,这种刮擦方式适用于一次性而非构建软件。

如何从技术背景中处理内容和链接

搜索引擎优化过去几年所做的大部分工作已经转移到为更多链接创建更多内容。我不知道在讨论如何扩展内容或构建更多链接时添加任何内容在这一点上是有价值的,但我怀疑现有的链接和内容有一些机会对许多人来说不是最重要的。

Google首先关注实体

Google员工最近宣布,他们会在审核查询时首先查看实体。实体是Google在其系统中表示专有名词以区分人物,地点和事物,并告知他们对自然语言的理解。在谈话的这一点上,我要求人们举起手来,如果他们有实体战略。我此时已经谈了十几次,而且只有两个人举手。

比尔斯拉夫斯基是这个话题最重要的思想领袖,所以我会顺从他的智慧并鼓励你阅读:

  1. 谷歌如何进行实体识别
  2. SEO和新的搜索结果
  3. 与网站和相关实体的实体关联

我还鼓励您使用AlchemyAPI或MonkeyLearn等自然语言处理工具。更好的是,使用谷歌自己的自然语言处理API来提取实体。标准关键字研究与实体策略之间的区别在于您的实体策略需要根据现有内容构建。因此,在识别实体时,您需要先进行关键字研究,然后通过实体提取工具运行这些着陆页,以了解它们的排列方式。您还希望通过相同的实体提取API运行竞争对手的登录页面,以确定这些关键字的目标实体。

TF-IDF

类似地,术语频率/逆文档频率或TF * IDF是一种自然语言处理技术,在池塘的这一侧没有得到太多讨论。事实上,主题建模算法过去一直是SEO社区激烈争论的主题。令人担忧的问题是,主题建模工具倾向于将我们推向关键字密度的黑暗时代,而不是考虑创建对用户有效的内容。然而,在许多欧洲国家,他们发誓TF * IDF(或WDF * IDF - 在文档频率/反向文档频率内)作为一种关键技术,即使没有链接也能提高有机可见度。

实际上,无论您使用何种模型,一般的想法是在您的副本中使用相关的关键字,以便更好地为您的主要目标关键字排名,因为它有效。

现在,我不能说我们已经孤立地检查了这个策略,但我可以说我们使用TF * IDF优化的页面在排名方面的跳跃比没有它的那些更大。虽然我们利用OnPage.org的TF * IDF工具,但我们不会使用硬性和快速数字规则来遵循它。相反,我们允许相关的关键字影响构思,然后在它们有意义时使用它们。

至少,这种内容技术优化的顺序需要重新审视。当你参与其中时,你应该考虑Cyrus Shepard提出的其他策略,以便从你的内容营销工作中获得更多的收益。

302s vs 301s - 严重吗?

最近,在SEO回声室中重新审视了301与302重定向。我认为网站管理员趋势分析师在公众眼中要么像关注还是只是无聊,所以他们会发布模糊的推文,看看会发生什么。

对于那些喜欢工作而不是等待Gary Illyes发推文的人,我所得到的只是一些数据要分享。

曾几何时,我们与一家大型媒体机构合作。与这些类型的组织的课程相同,他们的技术团队不能实施我们的大部分建议。然而,他们有数百万个内部和外部链接指向返回302响应代码的URL。

在经过多次会议和更具吸引力的商业案例之后,我们能够说服他们做的一件重要事情就是将这些302改为301。几乎在一夜之间,1-3级地区的排名有所增加。

重申一下,此时唯一的重大变化是302到301的开关。它导致每个月有机搜索访问量增加了几百万。当然,这是在一年前,但是当你从301s切换到302s时,有人能告诉我同样的事情或没有交通流失,我们没有讨论过。

内部链接,技术方法

在PageRank模型下,通过站点的链路权益流是一个非常重要的组件,这是一个公理。不幸的是,与客户的讨论很多只是在外部链接上,而不是如何更好地最大化网站已经拥有的链接资产。

有许多工具将这一概念带到了最前沿。例如,Searchmetrics计算并可视化整个站点的链接权益流。这使您可以了解如何构建内部链接以使其他页面更强大。

这些方法中的任何一种都非常有价值,可以提供更多的内容可见性,并且非常落入技术搜索引擎优化所能提供的内容中。

结构化数据是有机搜索的未来

流行的一线是Google希望成为网络的表现层。我说,帮助他们做到这一点!

关于谷歌如何利用我们的内容并尝试从我们的网站中删除我们自己的网站,已经有很多讨论。随着业界从网站上看到的交通流量成为特色代码片段,很明显,在很多情况下,Google在获取内容方面的价值高于其他方式。

借助移动设备上的Vocal Search设备和即将推出的Google Home,用户只能收到一个答案。也就是说谷歌正在建造的星际迷航计算机不会读取每一个结果 - 只有一个。这些答案由丰富的卡片和特色片段推动,而这些片段又由结构化数据推动。

实际上,Google在更新允许使用JSON-LD的规范时,对结构化数据做了很大的帮助。在此之前,Schema.org需要对代码进行非常繁琐且具体的更改,而投资回报率很低。现在结构化数据为SERP的许多组件提供动力,并且可以非常容易地放置在文档的<HEAD>上。现在是重新实现额外标记的时候了。Builtvisible的结构化数据指南仍然是黄金标准。

网页速度仍然是谷歌的痴迷

谷歌对页面速度有非常积极的期望,特别是对于移动环境。他们希望在一秒钟内加载上面的内容。但是,800毫秒的时间几乎无法控制。

要理解这个概念,首先我们需要稍微退一步来了解浏览器如何构建网页。

  1. 浏览器获取您在地址栏中指定的统一资源定位符(URL),并对域名执行DNS查找。
  2. 打开套接字并协商连接后,它会向服务器询问您请求的页面的HTML。
  3. 浏览器开始将HTML解析为文档对象模型,直到遇到CSS,然后它开始将CSS解析为CSS对象模型。
  4. 如果它在任何时候运行到JavaScript,它将暂停DOM和/或CSSOM构造,直到JavaScript完成执行,除非它是异步的。
  5. 完成所有这些后,浏览器构造渲染树,然后构建页面的布局,最后绘制页面元素。

这个术语对你来说可能听起来很熟悉,因为你在PageSpeed Insights中寻找有关如何进行改进的答案,并且“消除渲染阻止JavaScript”是一个常见问题。该工具主要用于支持关键渲染路径的优化。许多建议涉及静态调整资源,使用异步脚本和指定图像尺寸等问题。

此外,外部资源显着增加了页面加载时间。例如,我总是看到Chartbeat的库只需3秒或更长时间来解析DNS。在考虑如何加快页面加载时,这些都需要进行审核。

从本质上讲,AMP的存在是因为Google认为普通公众在编码方面表现不佳。因此,他们制作了一部分HTML并在其背后投放了一个全球CDN,使您的网页达到1秒。就我个人而言,我对AMP有强烈反感,但正如我们许多人在今年年初预测的那样,谷歌已经将AMP推广到了媒体垂直以及SERP中的所有类型的页面。该路线图表明,有很多更到来,所以这绝对是值得我们深入探讨,并期待利用。

使用预浏览指令来加快速度

为了支持网站速度的提升,大多数浏览器都有预浏览资源提示。这些提示允许您向浏览器指示稍后将在页面中使用文件,因此当浏览器的组件处于空闲状态时,它现在可以下载或连接到这些资源。Chrome会在可能的情况下自动执行这些操作,并且可能会完全忽略您的规范。但是,这些指令的运行方式与rel-canonical标签非常相似 - 您更有可能从中获得价值。

SEO从哪里开始?

成为一个强大的搜索引擎优化需要一系列技能,这是一个人很难做到的。例如,具有强大技术技能的SEO可能会发现很难进行有效的拓展,反之亦然。当然,SEO已经以这种方式在页面和页面之间进行分层。但是,技术技能要求在过去几年中继续大幅增长。

有许多技能总是给技术SEO带来不公平的优势,例如网络和软件开发技能甚至统计建模技能。也许现在是时候正式进一步对传统内容驱动的页面优化进行技术搜索引擎优化,因为所需的技能组合比网络开发人员和网络管理员要多得多,而不是通常认为的SEO(至少在这方面)游戏中的舞台)。作为一个行业,我们应该考虑像一些组织已经拥有的SEO工程师的角色。

至少,SEO工程师需要掌握以下所有内容才能真正利用这些技术机会:

  1. 文档对象模式 l - 理解Web浏览器的构建块是理解前端开发人员如何在构建Web时操纵Web的基础。
  2. 关键渲染路径 - 了解浏览器如何构建页面以及页面呈现的内容将有助于提高Google更加积极的速度。
  3. 结构化数据和标记 - 了解如何指定元数据以影响Google如何理解所呈现的信息。
  4. 页面速度 - 了解影响页面加载时间的其他编码和网络组件是获得页面加速的自然下一步。当然,这比SEO更重要,因为它会影响一般用户体验。
  5. 日志文件分析 - 了解搜索引擎如何遍历网站以及他们认为重要且可访问的内容是一项要求,尤其是随着新的前端技术的出现。
  6. 用于JavaScript框架的SEO - 理解利用其中一个流行框架进行前端开发的含义,以及详细了解可能需要HTML快照设备的方式,原因和时间以及实现它们需要做些什么至关重要。就在前几天,贾斯汀布里格斯在一个地方收集了关于这个主题的大部分知识,并将其分解为其组成部分。我鼓励你看看。
  7. Chrome DevTools - 了解SEO工具包中最强大的工具之一Chrome浏览器本身。Chrome DevTools的功能加上一些第三方插件弥补了SEO工具目前无法分析的许多问题。SEO工程师需要能够快速构建一些东西,以获得我们行业以前未提出的问题的答案。
  8. Acclerated Mobile PagesFacebook即时页面 - 如果 AMP路线图是任何迹象,Facebook Instant Pages是一个类似的规范,我怀疑它们将难以继续存在。
  9. HTTP / 2 - 了解此协议将如何显着改变Web的速度以及从HTTP / 1.1迁移的SEO影响。
让我们再次使SEO变得更好

总是使SEO变得有趣并且其思想领袖如此引人注目的事情之一就是我们如此严格地测试,学习和分享了这些知识。看来,测试和学习的文化在内容泛滥中被淹没了。也许许多类型的人都消失了,因为他们知道和喜爱的策略被谷歌的动物园动物吞噬了。也许我们不断侵蚀的数据使得得出强有力的结论变得越来越困难。

所有文章
×

还剩一步!

确认邮件已发至你的邮箱。 请点击邮件中的确认链接,完成订阅。

好的