ozine's book library

主题

第 9 章 从域名到内链 建立可以持续生长的网站 ​

本章的目标是把“做一个网站”变成一套能持续发布、被发现、被理解和被维护的系统。涉及搜索机制的说明以 Google 为主，架构建议还需要通过真实使用来验证。读完后，你应能选择适合自己的建站方式，为页面安排稳定地址，画出用户走得通的栏目结构，并建立不会随着文章增加而失控的内部链接。这里讨论产品和内容层面的架构决策；抓取、渲染、状态码和规范化的协议细节见技术章节。

9.1 先定义网站服务的任务 ​

一个站点不是网址的集合，而是任务的集合。开发者最容易先选框架，再搭首页，再寻找可以填进去的文章。更可靠的顺序是先确定谁会来、来解决什么、完成后去哪里，以及你能持续提供什么。设想一个名为“舟行”的 Go 日志分析工具，目标用户是维护中小型服务的开发者。它可能需要销售产品、解释日志排错方法、提供安装文档，还需要让已有客户找到故障解决方案。这四件事互相支持，但不能用同一种页面模板处理。

先写一段站点任务说明：“帮助维护 Go 服务的开发者缩短日志定位路径，提供可试用的分析工具和可复现的方法。”再把它拆成访问者动作：了解是否适用、比较部署方式、完成第一次接入、解决特定错误、确认价格。这些动作决定第一批页面。首页负责介绍站点和分流，功能页解释能力，场景页解释问题如何解决，文档页支持使用，价格页帮助交易决策。博客只是一种发布容器，不是所有内容的默认归宿。

这一步能减少两类浪费。第一类是开发了很多功能却没有入口，第二类是为搜索词写了很多文章但没有业务关联。为每个拟建页面记录“主要用户任务、页面负责人、完成标准、下一步入口”。完成标准要可观察，例如“读者能判断是否支持自己的日志格式”，而不是“看起来专业”。这些是本书的设计建议，并非搜索引擎公布的打分表。

先画页面类型 再画页面数量 ​

页面类型决定模板、字段和维护成本。一个工具站可从首页、产品介绍、价格、工具交互、教程、文档、关于七类开始。个人站也许只需要首页、文章、项目、关于四类。电商通常增加分类、商品、品牌和服务政策。类型越多，不代表覆盖越广；每多一种类型，就需要独立处理导航、标题、移动端布局、错误状态和数据质量。

用五个候选内容测试类型划分：如果“Go 日志脱敏”是一篇原理教程，“日志脱敏工具”是可操作工具，“舟行脱敏功能”是产品说明，它们可以独立存在，因为用户任务不同。若三页都只有同样的介绍和同一个注册按钮，划分就只是形式。此时应合并或重新设计，而不是靠不同 URL 证明它们独立。

9.2 域名 是品牌和运维资产 ​

域名选择首先考虑识别、稳定、可拥有和可维护。理想名字能被准确听写，不容易与他人混淆，不把业务锁死在暂时的功能上。Go 工具若未来可能支持其他语言，直接把某个库名写进域名可能限制品牌表达。简短名称不一定胜过清楚名称；生僻缩写也不一定更国际化。可以让几位目标用户听一遍后写出来，观察真实误写，而不是自己猜。

购买前检查商标冲突、历史用途、旧页面搜索痕迹和与已有品牌的混淆风险。发现旧域名曾被滥用，只能说明需要进一步调查，不能仅凭域龄推断它有优势。Google 的垃圾内容政策专门讨论以操纵排名为主要目的、利用过期域名发布低价值内容的行为；购买旧域名本身不是通往搜索优势的保证。[C07] 对个人项目而言，清晰的新品牌和稳定运营往往比追逐所谓“高权重老域名”更可控。

域名还涉及实际经营责任。注册人和账户应由组织或本人控制，续费与恢复方式要可靠，至少两位适当负责人知道交接流程，但不要共享明文密码。记录注册商、到期时间、DNS 管理方和网站托管方。很多“SEO 突然归零”的事故，根源是到期、证书失效或解析被误改，而不是文章质量。这里不提供具体法律结论；名称和商标问题应按经营地区核实。

根域名 子域名 与子目录 ​

example.com 是示例域名；docs.example.com 是子域名；example.com/docs/ 是同一主机下的路径目录。选择它们主要是组织和技术决策。独立产品、隔离部署和不同团队权限可能适合子域名；同一产品的教程与文档若能共享导航、设计和维护，子目录通常更容易统一管理。不要把其中一种包装成普遍排名捷径。

评估时列出真实成本：登录和统计是否需要跨域，发布是否要协调，内部导航是否一致，内容团队是否有修改权限，迁移是否会改变已有地址。对一个人维护的舟行站，把营销页、教程和文档放在一个清楚的站点体系中通常更简单。如果文档托管服务必须使用子域名，也不用为“权重会不会分散”而仓促迁移；先保证用户能识别它属于同一产品，并能在产品和文档之间往返。

网站名称与页面标题也不是同一件事。网站名称描述整体来源，页面标题描述某个结果。Google 对网站名称有单独机制和建议，选择的是简短、独特、与站点一致的名称，且不承诺一定采用你的偏好。[C23] 不要让首页叫“舟行”，文档叫“日志专家”，页脚又叫“极速监控平台”，除非它们确实是清楚说明的不同品牌。

9.3 按维护能力选择 CMS 与框架 ​

内容管理系统（Content Management System，CMS）解决的是组织、编辑和发布内容的问题。它可以与页面渲染绑定，也可以只提供内容接口。选择时不要只比较“能否设置 SEO 标题”，因为几乎所有成熟方案都能做到。更重要的是团队是否能稳定地产出正确页面，以及出错时能不能恢复。

传统 CMS 的好处是编辑流程完整，非开发者通常能直接操作；风险是插件、主题、权限和更新需要持续管理。静态站点生成器把内容预先生成页面，适合文档和个人站；好处是版本变更清楚、部署可回退，代价是编辑体验和动态功能可能需要额外建设。无头 CMS 将内容与前端分开，有利于多端复用，但预览、链接、缓存和发布同步必须有人设计。自建应用自由度高，也意味着错误页、重定向、元数据和编辑权限都由你负责。

对于会 Go 的个人开发者，最合适的选型并不必然是“全栈都用 Go”。若主要任务是每周维护几篇教程，使用成熟内容系统、只把核心工具写成 Go 服务，可能节约大量注意力。反过来，如果已有稳定的 Go 模板和发布流程，也不必为安装某个 SEO 插件重写全站。搜索引擎最终看到页面和链接，不会因你选了某个流行编辑器就自动奖励网站。

用验收脚本代替销售页面 ​

准备一个小型选型试验：创建一篇文章、一页产品说明、一张带说明的图片和一个已删除页面，再执行以下动作。修改页面标题但保持地址；更改地址并保留旧入口；预览未发布内容；恢复上一版本；输出站点地图；检查手机端；为非管理员提供编辑权限；导出全部内容与媒体引用。记录哪一步需要插件、付费套餐或开发支持。

这个试验的价值在于暴露系统边界。例如某系统允许改标题，但每次改标题都自动改地址；某系统能导出正文，却丢失图片说明和重定向。它们不一定不能使用，却应进入总成本。WordPress 的固定链接设置支持常见与自定义结构，说明 URL 规则是可以配置的站点能力；选型时仍要测试当前安装与主题的实际行为。[C21]

编辑数据模型也应及早确定。教程可包含标题、摘要、正文、作者、审阅者、适用版本、首次发布时间、实质更新日期、相关内容和状态。产品页应保存事实字段，避免价格、功能限制散落在正文里。多个位置使用同一项事实时，尽可能引用同一数据来源。这样一次更新能覆盖页面与相关展示，减少“价格页已改、文章仍旧”的冲突。

9.4 设计 URL 是在设计长期接口 ​

统一资源定位符（Uniform Resource Locator，URL）既是网页地址，也是被收藏、引用、分享和记录的接口。漂亮只是次要目标，稳定和明确更重要。读者应能从地址大致猜到内容类型，但不需要把完整标题塞进去。Google 建议使用可理解、组织清楚的 URL，并避免造成大量重复地址的复杂结构；连字符可用来分隔单词。[C01]

舟行可以采用 /features/log-redaction/、/guides/go-log-redaction/、/docs/install/。这些路径表达不同任务。文章标题以后从“Go 日志脱敏入门”改成“Go 日志脱敏的字段规则与排错方法”，地址仍能成立。若在路径里写入“最全”“最新”“2026”，以后更新可能产生维护负担。真正按时间组织的新闻可以保留日期，版本化接口文档也可能需要版本号；关键是语义是否长期有效。

中文路径与英文路径都可以使用。选择时看团队工作方式、分享渠道和历史习惯。中文路径在某些环境里会显示为百分号编码，复制时较长；英文路径需要术语统一，不能每位编辑随意翻译。建立简短命名约定：小写、单词分隔、日期使用条件、禁用随机营销词、别名处理和地址修改审批。对于已经正常工作的路径，不要只为了变短而大规模修改。

同一资源可能因排序、跟踪和筛选产生多个地址。业务设计阶段先区分“改变主要内容”“改变显示顺序”“记录访问来源”三种情况，再交给技术方案处理。不要让会话编号进入每个公开链接，也不要把客户邮箱、访问令牌或其他秘密放进可分享路径。参数并不是天然错误，问题在于它代表什么，以及是否导致无限组合或数据泄露。

页面身份与分类身份分开 ​

商品常被放进多个分类；教程也可能同时属于 Go 与安全。若 URL 必须包含当前分类，改分类就可能改地址。可以把页面稳定身份放在独立路径下，用导航和面包屑表达归属。比如商品使用 /products/camp-kettle-1/，在“炊具”和“轻量露营”栏目中都能找到它。URL 是否应包含分类没有唯一答案，但每增加一层与经营变化绑定的路径，就增加未来迁移成本。

不要把数据库主键是否出现当成 SEO 成败标准。一个稳定编号加简短名称，可能比容易冲突的纯标题更适合大目录。真正应该避免的是同一商品每次导入都获得新地址、标题相同的页面无法区分，以及系统允许任意拼写访问相同内容。规范化、跳转和错误状态的具体设置由技术章节承接。

9.5 信息架构让页面形成可理解的关系 ​

信息架构（Information Architecture，IA）是内容如何分组、命名和连接的安排。它应符合读者找东西的方式，而不只是公司内部的部门划分。开发者可能按“安装”“配置”“排错”查文档，采购者可能按“价格”“安全”“部署方式”评估产品。若导航只有“赋能”“探索”“生态”这些抽象词，访客需要先学习你的语言，才能开始解决自己的问题。

分类适合表达长期、有限的主题分组；标签适合补充跨主题属性。以教程为例，“日志处理”可以是分类，“脱敏”“性能”“排错”可以是标签，但没有必要为每篇文章建立一个仅包含它自己的标签页。分类页有独立用途时，应提供范围说明、选择线索和内容入口。如果它只重复文章标题，且用户没有理由从这里开始，可以降低它在导航中的地位，而不是自动把每个归档页都当作重要落地页。

所谓主题集群，是让一个较宽的主题入口与多个具体问题页互相支持。它不是固定的“一篇大文加十篇小文”配方。舟行的“日志脱敏”入口可以解释适用对象，链接字段识别、规则配置、误删排查和测试样例。每个子页解决清楚的问题，并在需要背景时返回入口。这样读者能够根据当前知识选择下一步，而不必重复阅读同一段概念。

层级深度与可用性 ​

路径里的斜杠数量不等于点击深度。一个地址很长的页面可以由首页直接链接；一个短地址也可能藏在几十次分页之后。Google 说明它会通过页面之间的链接理解站点结构，分类与商品之间的可达关系很重要，不能指望搜索框代替公开导航。[C08] 因此检查架构时，应该沿链接实际走一遍，而不是只看地址长短。

“所有页面三次点击到达”可作为某些小站的设计目标，却不是统一排名门槛。大型目录需要层次，过度扁平可能产生难以使用的巨型菜单。更合适的目标是重要任务路径短、分类含义清楚、深层页面有合理入口。导航中的每个链接都消耗注意力，放得越多，越需要分组和排序。

9.6 内链不是数量游戏 ​

内部链接（Internal Link）连接同一站点体系中的页面。它让访客继续完成任务，也帮助搜索系统发现页面并理解关系。导航链接表达全站结构，面包屑说明当前位置，正文链接解释当前概念的相关问题，关联内容模块提供下一步。它们服务的目的不同，不应全部用同一套自动关键词匹配代替。

Google 建议链接使用可抓取的形式，并让锚文本简洁、描述明确、与目标内容相关。[C02] 对编辑而言，可以把“点击这里”改为“查看日志脱敏规则示例”，因为读者在点击前就知道目的地。也不要把一长串变体词塞进同一个锚文本，或在同一段里给每个术语加链接。对不熟悉主题的访客，过密链接会打断阅读。

发布新文章时，完成两项不同工作：从新页面指向必要背景，从已有相关页面补上新入口。只做前者，新文仍可能缺少来源页面支持。可以在内容清单里记录三至五个候选来源，再逐页判断是否适合；这里的数量是编辑工作的起点，不是算法要求。若找不到任何自然来源，也许新主题偏离站点任务，或者确实需要新栏目。

自动内链适合稳定术语或结构化目录，但应设置例外。产品名可以链接到产品页，错误码可以链接到排错页；同一句出现多次时不必每次都链接。编辑应能覆写目标，防止同名词含义不同。一个常见错误是把“日志”全部指向首页，结果专题页、教程页和工具页的角色都变模糊。

从链接清单诊断架构 ​

在表格里记录来源地址、目标地址、锚文本、出现位置和目标状态。先找没有站内入口的孤立页面，再找大量指向过期地址的链接，最后分析重要页是否主要靠页脚获得入口。孤立并不等于绝对无法索引，但它提示网站没有为真实访客安排访问路径。对搜索结果里仍有点击、站内却找不到的旧文章，优先决定保留、合并还是归档。

不要仅按链接数量排序修改。一个帮助理解的正文入口，和重复出现在所有页面的页脚入口，业务意义不一样。把链接加入最相关的位置后，测试访客是否更容易找到目标，并观察来源页面和目标页面的表现。排名变化会受其他因素影响，不能把几天后的上涨全部归因于这一条链接。

9.7 舟行工具站的完整架构练习 ​

下面是一套虚构项目的设计过程，页面与数字仅为教学假设，不表示真实流量结果。假设舟行由两个人维护，初期只有日志脱敏和格式校验两项能力，每月能认真维护四篇内容。此时不应该先建立几十个空分类。先上线主页、两项功能页、价格页、快速开始、两份配置文档、三篇问题教程和关于页，形成一个能走通的最小体系。

主页先解释服务对象，再给“试用脱敏工具”和“阅读接入文档”两个不同入口。脱敏功能页描述输入、输出、支持范围和限制，指向交互工具。工具页提供一份无敏感信息的示例数据，让访客不用注册也能理解效果；真实产品是否支持匿名试用，由经营者决定。快速开始页只负责第一次成功运行，不混入完整参数手册。详细参数链接到配置文档，教程解释为什么要这样配置。

在地址规划中，功能页进入 /features/，教程进入 /guides/，文档进入 /docs/，工具进入 /tools/。每个目录的首页是否存在，取决于是否需要一个可浏览入口。若只有两篇教程，指南首页可以很短，但应说明内容范围；没有必要生成空白“性能”“安全”“运维”三个分类。后续出现稳定内容群，再拆分栏目。

这套架构的验收由四条用户路径完成。新访客从主页判断是否适用并到达工具；带着具体问题来的访客从教程理解解决方法并找到产品能力；已有客户从文档完成配置；谨慎采购者从功能页找到价格与安全说明。如果某条路径必须返回搜索引擎寻找你站内的另一页，就检查导航、命名或相关链接。

维护三个月后，团队可能发现日志格式校验几乎没有实际使用需求，而脱敏问题不断增加。这里不能直接根据一个流量指标删除功能。先核对支持成本、真实试用、业务方向和已有用户，再决定是否保留工具、合并介绍或减少入口。架构是一份可调整的产品假设，但每次调整都要保护已有地址和使用路径。

9.8 上线检查与练习 ​

上线前，把主要页面在手机、桌面和未登录状态下走一遍。确认导航名字能被目标读者理解，每类页面有负责人，已有公开地址不会因修改标题而改变，重要页面能沿正常链接找到，图片和附件有明确归属。检查搜索框找不到结果时是否给出可用下一步，删除内容时是否有符合语义的处理，而不是把所有旧页都送回首页。

练习一：一个个人站有十二篇文章，自动生成了三十个标签页，其中多数只有一篇文章。你会怎样调整？参考解答是先找用户会反复使用的主题分组，保留能解释内容范围的入口，合并同义标签，停止自动创建无意义归档。不要因为数量少就统一删除，也不要因为系统能生成就全都突出展示。

练习二：产品同时属于“开发工具”和“隐私保护”，是否必须复制两页？参考解答是不需要。可以保留一个稳定产品页，由两个分类链接到它；只有用户任务、内容或产品确有不同，才考虑独立页面。分类归属和页面身份可以分开表达。

练习三：文档放在子域名，团队担心搜索表现，准备迁移。先列出需要验证的事情。参考解答包括已有流量来源、外部引用、内部导航、部署权限、迁移成本和当前问题证据。仅凭子域名这一事实不足以证明应迁移。若真正问题是文章无法链接到文档，修复链接可能比改地址更直接。

本章的交付物应该是一张页面类型清单、一份地址规则、一张主要任务路径图和一份上线验收记录。把它们交给另一个人，请他不听讲解完成三项关键任务。卡住的位置，比“网站看起来有没有 SEO 感”更能说明下一步该改哪里。

本章参考来源 ​

保留各书来源与许可 · 示例运行条件以正文为准