从 IT 技术面细说 Search Console 的 27 组数字 KPI:终与始

在今天,从早上开到傍晚,连续的五场会议,而今天的会议都是围绕着 Google Search Console,讨论从这张表能够看出甚麽因果,能够开出甚麽样合理的工作清单,能够有甚麽接下来的策略可以发展。

https://ithelp.ithome.com.tw/upload/images/20210930/20000065wH853xBPkq.png

这 30 篇从第一篇到最後一篇,都是当天写的,虽然每次都很想说当发完单天的一篇後,开始写下一篇让第二天不会太类,但最後还是因为当天已经太累而作罢,每天写 1500~3000 字理论上不算困难,若是写的东西都是已知的,即使在每天上了两个班後,还要打起精神写,实在不算轻松。

而今天的检讨中,都用到我昨天写的文章,或是更之前写的文章,因此也大大降低了所须要解释与思考的时间,因为我把这 30 天铁人赛,当作是强迫自己在每天工作之後,还能够抽出 1~2 小时来作自我的全盘思考与反省,找出一种可能性,让这样的工作有没有可能做得更好,但也能够更轻松。

即使我有在这样的经验中,设定一个这样狭窄的题目,刚好可以在这段时间整体都有讲到一定深入的程度,但也尽量写到人能够看懂的地步,对於我不是件简单的事,因为要把这个架构一面写一面组织起来才是最困难的,但也是因为有这样的功夫,让这题目能够更完善。

但如我预期的一样,前 20 天是简单的,唯一困难的是要去思考是先後次序,因为有太多的东西可以写,因为我还有一个原则是:『别人写过的我就不须要再写,而写的东西几乎都是原创的事情与观点』,这种避免做『重覆的工作』本来就是一个工程师种本能,更不要说是习惯 DIY 的工程师。

虽然这样的铁人赛,几乎是每天再多加一个班,但因为写出新的东西是令人兴奋的事,有趣的程度不输日常的工作,只是比较可惜的是在铁人在之前,这八个月来我看了 99 部电影,也就是说每个月可以看 12 部以上,而这整个九月,最後只看一部 Netflix,外加经过戏院顺便看的 Dune,就知道写这些文章是要多少心力与时间。

写到了第 23 天,果然如预期的开始撞墙,虽然真的可以写得很多,但更希望的是在这 30 天内能够整理出一个完整的脉络,所以就设定只写 Google Search Console 的事,甚至只写跟 KPI 数字有关的事,而完全不想提在之外的 SEO 任何事情,因为这部份不太可能在 30 天内写出个大纲。

在第 18 天已经写完所有的项目,而空下一天来说明 Google Search Console 的不足外,最後再写 4 篇如何填表,此时即使收手不再写,也是足够完整的而没有太大的问题,只是还剩下的 7 天该如何解决呢?而这也是种自我挑战的开始,在这样的情境,是否还能够研究出不同的观点,而不是写下本来就知道该写的东西。

因此之後大概思考了几个题目:

  1. Google Search Console 与 Ranking Factor 的关系
  2. Google Search Console 的历史演进观点评论
  3. Google Search Console 的 Bug 及不为人知的 Bug
  4. 因为 Google Search Console 的 Bug 及如何解决
  5. 解读用排名做为依据的问题
  6. 用回归分析来看这些因子的价值
  7. 如何用 API 来弥补这些既有数字的不足
  8. 写程序将下载的 CSV 档分析,找出问题点

最後再写不出来,就只好搬出压箱技,来做 Case Study 与 Live Demo,虽然这部份不是我期望的。

其中的排名是我最不想碰触的问题,虽然在实务上还是会去思考排名的问题,我也写了很多相关的程序,但就是看到这个业界被排名的迷思而困住,因此不想再推波助澜了,所以因此只做大概的解释後,就转写其他了。

这些题目有些真的很重要,甚至有些是还没做完的,要在最後一个星期去完成是有点挑战,就像是用回归来做相关分析能不能有结果在之前也不确定,加上是否能够想出一套方法自动化、即时化的回归分析才有意义,因为早在去年前年就做过一次性的分析,虽然有结论但我并不喜欢做这种一次性的工作,而是希望做出系统自动化帮人找问题的架构。

很幸运的之前对 Google Sheet 的研究派上用场,最後完成期待的方式,也从中证明了 80% 已知的事,但也发现 20% 的意外,因此这变成最大的成长与收获。

所以原本规划的 8 点最後写了 4 点就满了,因为因子分析文章就超过 5000 字分两天写了,後面的题目就给 30 天之後来写了,虽然就之前的经验,有可能再写个 1~2 天就没力了。

这样的 30 篇我相信对大多数的人是很有帮助的,最後对我的工作也很有帮助,就像是一开始所说的今天五个工作,几乎都靠铁人赛重构出新的表单,而能够更好的跟 Google 的演算法『对话』,能够从这边了解我们网站的优缺点,这种 30 天的自我挑战与进化,对读者也帮助,甚至对作者是有更大的帮助,这才是铁人赛真正的意义。

 - - - - - - - 
虽然写铁人赛还有一个原因是:

『你这问题我早就写过了,你去看我在铁人赛写的 30 篇就会有基本概念,你也会在这边找到答案了。』

这样我牺牲这个月比较少看电影就有价值了,而後可以有更多的时间看电影了,Ya~~~


<<:  [Day 25] 如果我们不想 mock Clock 怎麽办呢?谈依赖反转

>>:  Day30 .NET 6 <ErrorBoundary>

第48天-学习 crontab 工作排程

今天进度 鸟哥私房菜 - 第十五章、例行性工作排程(crontab) 我在 Crontab.guru...

JS 题:将变数宣告在全域环境是否为好习惯?

今天分享一个对经典 JS 面试题的探讨。 原本完整的问题: Why is it, in genera...

企划实现(19)

在写app时常常会因为所有app在外观看起来一样,所以往往会要找很久才能找到自己想要执行的app,所...

Day 20 : Jenkins Pipeline与撰写Jenkinsfile

Jenkins Pipeline介绍 如昨天的文章,我们将Code推上远端仓库後Jenkins会自动...

Day 7 python字典

今天我们要介绍的是python的字典,所谓的字典就是指将元素用{}包住并且元素是由一个键(key)配...