直接回答:本站用 Hexo 8 + Stellar 主题搭建,GEO 相关的关键改动只有三处——用英文固定链接保证 URL 可引用、用生成脚本自动产出 llms.txt 与结构化数据、用清晰的分类和专栏构建主题聚类。主题本身不需要改源码。
为什么是 Hexo + Stellar
选型理由其实很简单:
| 需求 | Hexo + Stellar 的处理方式 |
|---|---|
| 输出必须是纯静态 HTML | Hexo 生成的 public/ 就是静态文件 |
| 要能写作、要好看 | Stellar 提供完整的排版、代码块、图片灯箱、搜索 |
| 希望长期可维护 | 全部是 Markdown + YAML,没有数据库 |
| 部署到自己的服务器 | 生成后直接同步目录即可 |
我不需要 CMS,也不需要在线编辑。写作流程应该只有一件事:新建一个 Markdown 文件,写完推送。
目录结构
1 | blog/ |
把内容、配置、脚本分开放,是长期维护的前提。 主题升级时只需要替换 node_modules 里的包,自己的内容一点不受影响。
三处对 GEO 真正有影响的设置
一、固定链接改成英文路径
1 | # _config.yml |
文章文件名用英文,标题仍写中文:
1 | source/_posts/what-is-geo.md → https://devnotes.cuiyuehui.cn/posts/what-is-geo/ |
这样做的好处:
- URL 里没有中文编码,复制、分享、被引用时不会出错。
- 去掉
index.html和.html后缀,链接更短。 - 路径稳定,已发布的 URL 不再改动,避免丢失已有的引用积累。
二、用脚本自动生成 llms.txt
手工维护 llms.txt 一定会忘记更新。本站的做法是在 scripts/geo.js 里注册一个生成器:
1 | hexo.extend.generator.register("geo_llms_txt", function (locals) { |
每次构建都会重新生成,同时输出完整正文版的 llms-full.txt。效果可以直接查看 llms.txt。
三、结构化数据自动注入
主题已经输出了 BlogPosting。我在 scripts/geo.js 里补了两类:
- BreadcrumbList:让机器知道这篇文章属于哪个分类。
- FAQPage:文章的问答对直接写在前面的 front matter 里。
1 | faq: |
站点结构:为 GEO 设计的信息架构
内容组织方式对 GEO 的影响经常被忽略。本站的结构是:
1 | / 首页(文章列表) |
三个设计考量:
- 专栏承担主题聚类。 同类文章聚在一个专栏下,比散落在时间线里更容易被识别为完整主题。
- 作者页负责说清楚"这是谁写的"。 读者看完一篇有用的文章,通常会想确认作者靠不靠谱,作者页要能正面回答这件事。
- 留言板是唯一的交流入口。 不加复杂的表单,减少放弃率。
内容写作规范(本站自用)
写每篇文章时遵守这几条,已经固化成模板:
| 规则 | 原因 |
|---|---|
| 开头 3 行给完整结论 | 这是最容易被摘取的片段 |
每个 h2 都是判断句 |
让每个片段自带语义锚点 |
| 一节只讲一件事 | 避免切分时主题混杂 |
| 写清适用边界 | 提升可信度与可核查性 |
| 文末附 FAQ | 直接产出可被引用的问答对 |
| 引用外部来源 | 让结论有路标 |
常见问题(FAQ)
为什么用静态博客而不是 WordPress?
静态博客的输出就是纯 HTML,不依赖后端渲染和数据库,抓取时不会出现空壳页面,正好满足 GEO 的第一层要求。同时部署简单、成本低、几乎没有被打穿的风险,对个人技术博客足够。
Stellar 主题需要改很多代码吗?
基本不需要。它提供了完整的配置项,布局、颜色、侧栏组件都可以用 YAML 配置完成。本站只额外写了一个构建脚本用来生成 llms.txt 和注入结构化数据,没有修改主题源码,这样主题升级时不会有冲突。
文章链接该用什么形式?
用英文文件名的固定链接,例如 /posts/what-is-geo/。中文标题不变但路径保持 ASCII,既避免编码问题,也让链接更短、更容易被引用。已发布文章的路径不要改动。
下一篇
站点生成好之后,就该放到服务器上了:《把 Hexo 博客部署到阿里云 ECS:Nginx + HTTPS 完整流程》。