站点日志：上线49天，我找到了百度收录太少的秘密

2025年7月39日，今天是站点上线第49天。收录上仍然没有太大的变动，pc 收录数又掉了一个，现在是 5 条。总觉的收录少不光是新站的问题。

早上，翻到了百度站长，看了看官方关于优质原创内容的相关文章。才发现，原来官方对内容要求上的要求，其实是有明确建议的。不要只看网上哪些 seo 文章，因为对于没有太多 SEO 经验的你，可能无法分辨哪个帖子才是干货，哪些是水货。所以，最好的方法，看官方要求。

继续寻找网站收录少的原因

早上看了下，百度官方的针对内容的规范。各方面来说，内容质量和原创上，都算不上太差的（哈哈，自评，有槽要吐忍的着点吧）。起码不应该归类到差的一方面。难道是有什么问题我没发现。总结来总结去，最后又回到了之前耿耿于怀的一个问题上。

我的站点是通过 markdown 来书写内容的。为了减少存储空间，后台并没有存储渲染后的 html 内容。前台页面也是通过 markdown 的源码通过 js 来渲染最终的页面的。

这也许就是问题的关键，现在虽说搜索引擎已经多少支持了一些 js 方面的脚本，但是复杂的脚本或者框架，估计还是无法支持，或者说没必要支持。总不可能搜索引擎抓取的巨量页面，都是一个一个渲染出来，然后在去评估内容质量吧。所以，即使搜索引擎能够做到，也不会去做这样费时耗力的事。那问题就来了，是不是我的页面内容压根不会被搜索引擎抓到，或者说抓到的是 markdown 的源码。导致页面被判定为混乱低质的内容。那岂不是白忙活了。

即使这个可能性再小，我觉得也应该完全消除隐患才靠谱。所以，动手吧！改为后台渲染。直接不给搜索引擎拒绝你的一点借口！

目前想到了两个方案，具体如下：

方案一：后台内容编辑功能升级

将内容表，增加一个最终的 html 内容字段。将后台渲染的两部分内容全都保存起来。源码主要是用来做 markdown 编辑器的源码用，html 内容，就是用来最终显示到页面上的。不在用前端 js 渲染了。

优点

技术实现简单，只需后台同时存储 html 渲染数据即可

缺点

• 需要多增加一个字段，存储冗余数据
• 渲染的最终内容中，一些数据需要预处理。比如图片数据，其地址来源于，配置的静态云存储服务，和附件的地址。也就是说网站迁移后如果更换了不同的云存储，那么内容中的地址就需要手动更新一遍，而不是只修改配置就行生效。这个很难容忍。

方案二：前端页面加载前，渲染 vue 内容

不在数据库存储渲染数据，还是保持 markdown 源码的存储。在文章详情页进行渲染时候，由服务端渲染 markdown 内容到 html 内容。

方案二的优缺点

优点

不增加冗余存储，后台功能无变动。最终渲染内容，在渲染到前端页面前，所有预处理的内容都会被处理完。可以保证配置修改后，依赖配置的内容无需手动更新数据。

缺点

技术成本增加，需要解决如何在 PHP中渲染 markdown 源码的问题。服务端 js 内容的渲染也需要花费一定的时间。随着访问量变大，频繁的服务端渲染，对性能肯定有影响。后续可能还需要对此机制进一步优化。

这个方案到此，又有两种实现方式

通过 php 代码的 markdown 库解析 markdown 源码

**缺点：**不能保证php 库渲染 markdown 的时间，另外渲染出的html肯定需要调整，适配到跟前端 css 代码风格一致。

**优点：**只是引入新的扩展库，现有机制通过 composer 引入很简单。只需调整 composer 依赖文件。

通过 v8js 库，直接解析 vue js 代码代替 node js 进行服务单渲染

**缺点：**服务端需要保持 vue 后端代码，Node.js，npm，才能保证 vue js 的运行。同时PHP需要安装 V8 引擎库，V8js 支持扩展。需要修改镜像构建脚本，已适应新的服务构建方式。加大了项目的维护难度，需要保持前端环境、PHP 环境共同运行。修改的东西也很多。

**优点：**渲染出的代码，跟前端的html一模一样。不用跳转渲染的具体业务逻辑。

最终实施方案

所有方案，从明面上来看，方案二的第一个选择，是花费最小，最易于实施的。后边所有测试先按照此方案进行。

先调研了下方案二中涉及 php markdown 转换的库，目前效率最高的是 Parsedown。官网测试显示，最快是 Markdown PHP 10 倍左右。所以先测试下，如果markdown 内容花费在 50ms 以内。那完全可以直接动态渲染。短期内容也不需要更改渲染机制。

然后找了站点几篇比较大的文章源代码，测试了下，解析速度居然分别是 3.97 ms（Markdown PHP），1.94 ms （Parsedown）。

试了几次其他文章，总体就是 Parsedown 显示比 Markdown PHP 要快，最慢的时候，也比它快一倍左右。而且所有测文章测试解析，没有超过 10ms 的，其实严格说，是没超过 5ms 的。

结果出于意料的不错。接下来就是接入测试，看看将转换格式与目标格式定义为一致的格式后，效率最终到多少。