1. 您的位置:首页 > seo技术 >内容

站群自动:如何使开发人员实施SEO建议

SEO中最难的问题不是算法更新。 它无法访问企业工具。 您甚至没有经验来确定将精力集中在哪里。

不,SEO中最难的问题是使开发人员实际执行建议。

我们每个人都进入了一个项目,希望找到一个内部拥护者,可以与开发人员共进午餐并购买啤酒,以期将我们的建议转化为行动,但有时该拥护者不会露面。 在某些情况下,完成工作可能需要社会工程学。 在其他情况下,它只是需要工程学位。

让我们谈谈如何更好地准备让开发人员根据您的建议采取行动并取得一些成果。

Anderson-Alderson开发人员规模

首先,让我们认识玩家。

我喜欢认为Web开发人员有两个相反的极端,我使用两个我最喜欢的角色来个性化它们。 一个人是托马斯·安德森(Thomas Anderson),您可能还记得他在成为《新》之前的《黑客帝国》中的人物。

这是他的老板在电影中对他的描述:“你有问题,安德森先生。 您认为自己很特别。 您认为这些规则不适用于您。”

安德森开发商是谁生活在他们自己的条件,只有当他们觉得它做的事情的员工类型。 他们是特立独行的人,他们会在代码风格指南的优点上与您争论,为什么他们将元标记完全遗弃在自定义的CMS中,为什么他们将永远不实施AMP-同时,没有一行代码可以验证违反他们所珍视的规格。

他们还是开发人员,他们会注视您的建议或谈论他们如何知道您要呈现的所有“ SEO优化”,他们只是没有时间去做。 当然,安德森先生。

在频谱的另一端,您有Elliot Alderson。

对于那些不看电影的人机器人,”奥尔德森(Alderson)是这样一种人,他们会在凌晨2:00休息时修理他们的东西,甚至到当天晚上跳上公务机来研究网络的最新崩溃。

Alderson型开发人员渴望立即实施您的建议。 那不是因为他们一定在乎排名,而是因为他们在乎擅长做事。

这种开发人员类型很专心,如果您不知道自己在说什么,就会不停地召唤您。 因此,不要在不了解异步JavaScript工作原理的情况下提出有关异步JavaScript的建议。

Aldersons还将帮助您集思广益地执行一个好主意,以及如何帮助您优先解决开发队列中的黑洞建议。 他们可能知道Google的文档,但认识到它不一定总是最新的,并尊重您的经验,因此在实施不确定的内容之前,他们会先询问您的想法。

与Alderson规模的开发人员合作时,我最大的经验就是参与了一个电视节目的客户项目。 我们飞往洛杉矶与团队见面,并带领他们完成我们的SEO网站审核。

在我们解释其中的一些建议时,开发人员坐在房间里,没有做笔记。 相反,这位先生正在提交代码,因为我们正在解释需要解决的问题。 在会议结束时,我们所有的高价值建议都已得到执行。

不幸的是,我不记得那个人的名字了-但他是一个传奇。

战略交付与执行交付

在我的整个职业生涯中,我的办公桌上堆满了许多代理商的可交付成果,而我总是对某些公司提出建议的方式感到震惊。

许多可交付成果要么只是Google工具的屏幕截图,要么是几乎没有上下文的处方。 我总是想像一个首席执行官让某人打印出我们的作品以便在他们乘坐豪华轿车前往机场时阅读。 我希望那个人能感觉到他们理解我们的建议,为什么重要,以及我们如何做得很好。

另外,我经常发现战略文档中没有补充文档可以帮助客户及其开发团队切实执行这些建议。 它的出现非常多,因为“这是一个问题,您应该解决它。 祝好运。”

例如,当我们进行SEO网站审核时,每组问题都会以其重要意义的上下文进行显示,问题说明和一系列建议(包括屏幕截图和代码段)。 然后,将每组优先级划分为一系列的好处,易用性和易于实施的条件。

iPullRank可交付示例

所有问题均以数字编码,以便可以在电子表格中表示。 在该电子表格中,每个编码的问题都有一个选项卡,突出显示发生该问题的特定URL以及代表该问题的任何相应数据。

例如,对于太长的元描述列表,我们将包括这些URL,其元描述及其长度。

更大的问题在于可交付成果,其交付给客户的审查和批准更多,而不是开发人员的交付。 我们有一个称为“内容推荐”的可交付成果,其中,我们获取客户的内容并将其放入Word中的模型中,并跟踪更改以更新正文,元数据和内部链接结构。

这对营销人员来说非常有用,它可以检查我们对他们的广告所做的事情,并确保我们继续保持声音和语调。 如果客户有一个市场协调员来执行手动实施,那也很好。

从开发的角度来看,这是可怕的,因为这要求他们做一个非常繁琐的工作,逐页**和粘贴新项目,并且没有开发人员愿意这样做。

这意味着要实现该Word文档中的建议,需要一名在Anderson-Alderson规模的Alderson方面具有很高才能的开发人员。

另一方面,如果我们与客户一起审查“内容推荐”文档的面向客户的版本,然后将所做的更改放入电子表格中,则开发人员可以编写遍历每个页面的脚本,并进行我们建议的更改。 以后再说。

这将使实现更接近于Anderson-Alderson规模的Anderson端。

让开发人员做事与规模有关

一般来说,对于SEO建议,规模始终是要牢记的。 但是,有时候,您无法缩放您要完成的工作。

例如,如果您已经迁移了网站并以没有确定模式的方式更改了网站分类,则无法为其重定向编写基于规则的.htaccess条目。

开发人员在其端部具有一系列用于实施更改和/或使事情按比例缩放的工具。 通过此框架提出建议,以使开发人员切实执行这些建议是我们的工作。 否则,开发团队将总会找到一种退缩的方法。

在Anderson-Alderson规模上常见的SEO实施任务

某些特定于SEO的任务比其他任务需要更多的开发工作,并且在Anderson-Alderson规模上进行不同的评分,而在该规模上的位置表明您需要与哪种类型的开发人员合作才能实施这些建议。 下面说明了这些常见任务通常在该范围内的情况。

  • 更新元数据。 这个过程通常很繁琐。 除非将副本准备在易于提取并放置到页面中的位置,否则它将需要在CMS中逐页更新,或者从我们准备的文档中提取并将其放置到数据库中。
  • 更新主体副本或嵌入式结构化数据。 与更新元数据类似,这也很繁琐,并且需要逐页更新。 如果我们要讨论的是更新集成在内容中而不是使用JSON-LD放置在<head>中的schema.org代码,这对于开发人员来说是一场噩梦。
  • 更新内部链接结构。 这可能可以通过编程方式完成,但前提是必须有效地确定这些关系。 在大多数情况下,SEO会逐页提出建议,而开发人员则无法有效地扩大工作量。
  • 优化代码以提高性能。 开发人员往往痴迷于速度,以至于他们将“性能”一词简称为“性能”,因此可以说得更快。 但是,他们对Google的PageSpeed Insights提出的关键渲染路径建议不满意。 在我提出的SEO建议中,我最轻松地采纳了这些建议,因为这是开发人员经常防御的领域。 专家提示:使用DevTools时间轴和网络性能详细信息来优化页面速度。 他们倾向于对这些反应更好。
  • 按照网站分类法生成XML网站地图。 有许多工具支持XML站点地图的开发,但是开发人员倾向于让那些工具破烂。 这导致生成XML网站地图,例如“ sitemap14.xml”,而不是那些反映网站分类法后有意义的细分的网站,因此对于SEO进行索引管理很有用。
  • 生成HTML快照。 某些Angular 1.x等JavaScript单页应用程序框架在历史上一直难以索引。 但是开发人员听说Google正在使用无头浏览器进行爬网,并且他们知道Angular是Google开发的框架,因此有时不必强迫他们解决其缺点。
  • 实施重定向。 重定向通常可以在服务器配置级别上完成,并通过一系列模式匹配的规则来编写,因此可以轻松扩展。 根据我的经验,很少有开发人员不会遵循这些要求。
  • 解决不正确的重定向。 相反,在将重定向从302切换到301的过程中,我看到了开发团队的反对。 实际上,我曾经被告知交换机可能会破坏站点。

显然,我们需要寻找可以与之合作的更好的开发人员,否则我们必须找到一种方法来提出我们的建议以防Anderson。

请允许我向您介绍任务赛跑者

Web开发,主要是在前端,日新月异。 过去五年来引入的最有价值的概念之一是任务赛跑者。

Gulp和Grunt等任务运行程序使开发人员在每次推送新代码时都能自动执行一系列任务。 Webpack的最新功能还具有任务运行功能。 这在很大程度上是为了防止开发人员执行机器本身可以执行的平凡或繁琐的过程,并且许多Web项目正为此目的利用这些。

在不深入研究工具本身的具体细节的情况下,社区围绕Grunt,Gulp和Webpack成长了。 因此,可以使用一系列插件。 当然,可以为每个模块编写自定义模块,但是为开发人员创建的工作越少越好。

回到大规模更新元数据的想法,Grunt有一个名为grunt-meta-excel的插件,它允许您为XLSX文件提供页面标题,元描述和开放图元数据的更改。

只需提供文件,开发列映射并运行任务即可更新站点上的所有相关页面。 当然,我的建议是将更多内容应用于平面文件,而不是CMS中的内容,但当然也有在数据库级别运行的任务运行程序。

开发人员可以有效地修改此插件以编辑数据库,而不是编辑文件,或者您的Excel文件可以很快转换为SQL文件,并作为UPDATE在整个数据库中运行。

最后,大多数现代内容管理系统都具有允许开发人员将繁琐的任务扩展到类似效果的插件或模块。 由您决定进行研究并在准备建议时了解它们。

您可以使用任务运行程序的常见SEO建议

Grunt,Gulp和Webpack都有一系列插件,这些插件提供可配置的功能,使开发人员可以快速执行乏味的SEO任务。 以下是(非详尽的)SEO任务列表以及可以用于它们的一些插件:

代码缩小

  • 丑化(Grunt)
  • Cs**in(格伦特)
  • HTMLmin(粗体)

图像压缩

  • imagemin(Grunt)
  • imagemin(Gulp)
  • imagemin(Webpack)

自动更新XML网站地图

  • Gulp-Sitemap(Gulp)
  • Grunt-Sitemap-Xml(Grunt)
  • Sitemap-Webpack-Plugin(Webpack)

AMP验证

  • gulp-amphtml-validator(Gulp)

AMP创建

  • AMP生成器(Webpack)

更新元标记

  • grunt-meta-excel(Grunt)

生成HTML快照

  • 咕unt爬(咕run声)
  • Prerender-webpack-plugin(Webpack)

页面速度见解

  • grunt-pagespeed(Grunt)

这些插件中的每一个都可以让您准备规范(在某些情况下还可以提供支持文件)。 然后,开发人员只需配置插件即可反映出来并运行任务。 利用这些工具,您实际上已使他们的工作变得相当轻松。

除了Grunt,Gulp和Webpack设置之外,开发人员可以使用Webcheck来自动化针对此StackOverflow线程中突出显示的其他几个SEO问题的一系列其他检查。 这个想法是,开发人员可以编写构建测试,除非所有内容都签出,否则不允许他们部署新站点。 您可以通过搜索npmjs.com找到更多插件。

使开发人员实施SEO建议的其他方法

任务运行者当然不是万能的。 相反,它们是SEO工具箱中用于与开发人员进行有效交互的另一个工具。 有许多较小的方面可以帮助您使开发团队采取行动。

  • 了解技术栈,并在其中提出您的建议。 考虑一种情况,在这种情况下,您已经为客户端建议了301重定向。 事实证明,它们运行的​​是Nginx而不是Apache。 您知道Nginx不使用.htaccess文件吗? 如果您不这样做,则可能建议在其中放置301重定向,而开发人员可能会忽略您所说的其他内容。 诸如BuiltWith.com之类的工具将使您大致确定所使用的技术。 一个更好的主意是查看Chrome DevTools中的HTTP标头。 无论您做什么,都应该花些时间在订婚开始时对技术堆栈有一个详细的了解。
  • 在建议中提供详细信息。 如果要求开发人员在文档之外的其他地方寻找解决方案,则使他们实施建议的可能性大大降低。 相反,请在交付的内容中顺其自然地解释上下文和实现,而不要链接到其他人的解释。 尽管开发人员往往从不信任他人的应用程序,但与许多SEO工具相比,某些开发人员更倾向于尊重DevTools的发现。 我的猜测是,这是由于细化细节的组合,并且它们是他们每天使用的工具。
  • 提供一种解决方案,但了解其他解决方案。 通常,可以通过多种方法解决SEO问题站群自动,并且通过突出显示所有可用选项来满足填充SEO文档的愿望可能很难。 加倍努力,只提供一种可能的解决方案。 消除决策的必要性将导致开发人员更有可能实施。 但是,如果开发团队将某个解决方案记下来,请准备好另一个解决方案。 例如,如果他们不能将站点从子域移动到子目录,则建议使用反向代理。
  • 业务案例和优先级。 这可能是您获得组织上下支持的最有价值的事情,这给开发团队带来了完成工作的更大压力。 将数字加到实现的价值上,可以使操作的想法更具吸引力。 通过此透镜对建议进行优先级排序也会有所帮助。 诚然,我们都知道没有人能真正预测机会的规模,因此请使用某种可以理解的方法来做到这一点,以使事情发生。
  • 了解他们的开发方法。 无论是敏捷,瀑布式,XP,某种组合,还是世界上只有一个团队才能做到的新事物,都希望了解它。 听着,当我全神贯注地问我一个他们可以用Google搜索的问题时,有人站在我的办公桌前跑到我身边,我无法忍受。 同样,开发人员讨厌SEO出现在他们面前,并告诉他们他们需要破坏他们通常如何适应SEO建议的方式。 因此,如果该团队在冲刺中工作,请在冲刺周期何时结束以及何时将您的要求纳入后续冲刺的最佳时间,从他们的Scrum主管那里了解。 您还应该直接与该人员合作,将建议发展为故事,并放入他们的项目管理解决方案中,以便团队可以遵守其标准工作流程,而无需将您的工作转化为他们的工作方式。
  • 与开发团队建立关系。 看起来很明显,但是与开发团队成为朋友的软技巧将大大有助于他们与您合作。 在大多数情况下,SEO和技术团队之间的关系是非常重要的事务,因此,它们仅在您需要帮助时才会收到您的来信。 相反,如果您花时间对这些人产生真正的兴趣,您会发现他们就是像您和我一样尽力而为的人。
  • 呼吁他们的自身利益。 到了上一点,有机会使您要尝试的工作与他们要尝试的工作保持一致。 例如,我们的一位新客户有一个开发团队希望优化页面速度,但他们更关注内部指标,而不是Google所关注的外部指标。 接受该建议的子集比其他任何建议都容易得多,因为它支持该人由其老板给予的任务授权。 因此,对我来说,与他交谈时专注于此内容比重定向之类的东西更有价值。 尽管这需要对我认为最有价值的任务进行优先级调整,但这确实有助于将重点转移到页面速度上,以确保我强调的项目得到优先处理。 只要结果是收入,您就会输掉一些,而您会赢得一些!

尽力平衡天平

作为开发人员,我可以告诉您,即使您要成为一个开发人员,也总是很难让开发团队使事情成真。 但是,当您说他们的语言并更感兴趣为他们提供正确的面向细节的解决方案时,您将获得比没有的更多的东西。

改进可交付成果,利用任务执行者,开发业务案例,有效地确定优先级,并对与您打交道的人产生真正的兴趣,将使您更加接近完整实施和更好的自然搜索性能。 祝您好运,将您的Andersons转换为Aldersons!


本文中表达的观点是来宾作者的观点,不一定是Search Engine Land。 工作人员作者在此处列出。

本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容,一经查实,本站将立刻删除。如若转载,请注明出处:http://www.botadmin.cn/sylc/9874.html