跳到主要内容

5 篇博文 含有标签「Docusaurus」

查看所有标签

旧博客迁到 Docusaurus 的内容工程:slug 兼容、归档索引和补档修复怎么做

· 阅读需 5 分钟
一介布衣
全栈开发者 / 技术写作者

最开始我也以为,把旧博客迁到 Docusaurus 主要是文件格式问题:把文章导进 blog/,补齐 frontmatter,再让站点 build 起来就差不多了。真开始做才发现,Markdown 导入只是最浅的一层。更难的是后面那几件不太显眼、却直接影响站点可信度的事:旧链接能不能继续访问,归档会不会乱,补写过的文章会不会被迁移脚本覆盖,历史内容和新内容能不能进同一套索引。

把发布脚本变成质量闸门:Docusaurus 站点在 build 前该挡住什么

· 阅读需 5 分钟
一介布衣
全栈开发者 / 技术写作者

以前我对博客发布脚本的要求很低,能把 build -> 上传 -> reload 跑通就算不错。等 blogV2 的文章越来越多、迁移批次越来越频繁以后,这条认知很快就被现实打掉了。因为对内容站来说,最贵的成本不是手工上传慢十秒,而是坏内容已经被发到线上以后,才发现链接错了、description 烂了、文章根本还是半成品。

技术博客 SEO 不靠堆词:description、structured data 和归档入口要一起设计

· 阅读需 5 分钟
一介布衣
全栈开发者 / 技术写作者

我现在做技术站点的 SEO,已经很少从“关键词密度”开始想了。对这种长期积累型博客来说,真正决定搜索质量的,经常是另外几件更基础的事:description 写得像不像人话,结构化数据有没有最小字段,归档和最近文章入口稳不稳定,文章之间有没有形成明确的主题路径。

blogV2 为什么更该重视可持续发布:草稿预览、历史迁移和质量闸门要一起做

· 阅读需 5 分钟
一介布衣
全栈开发者 / 技术写作者

我现在看 blogV2 这类站点,已经不太会先问“这一版什么时候正式上线”,而是更在意它能不能稳定地持续发布。因为对内容系统来说,最容易拖垮人的从来不是第一次把站点搭起来,而是后面一篇篇补写、迁移、修订和回归时,发现所有流程都还靠记忆撑着。

2026 年技术博客为什么还值得认真做:它已经不是 Markdown 仓库,而是内容系统

· 阅读需 6 分钟
一介布衣
全栈开发者 / 技术写作者

如果技术博客今天还只是一个随手放 Markdown 的目录,它当然很容易被放弃。真正让我还愿意认真维护它的原因,不是“写博客”突然又流行了,而是站点早就不只是写作工具了。一篇文章只要要进首页、归档、标签页、RSS、结构化数据和发布流水线,它就已经不再是孤立文本,而是一个被系统消费的内容对象。