以前做企业网站项目时，我对 SEO 的处理方式比较靠后。

网站先设计、开发、测试、上线。

等正式运行以后，再去检查标题、页面结构、收录和搜索表现。

后来做的项目多了，发现这种流程有一个很明显的问题：

很多搜索可见性问题，其实是在开发阶段就已经被写进网站里的。

等网站正式上线以后再处理，往往意味着重新改程序、重新整理页面，甚至重新调整已经上线的 URL。

所以最近在做武汉企业网站相关项目时，我开始尝试另一种思路：

把技术 SEO 从 “上线后的运营工作”，前移到 “开发和发布流程”。

这篇主要记录一下我现在是怎么做的，以及为什么这么调整。

一、以前的问题：SEO 总是在项目末尾才出现

传统企业网站项目经常是这样的流程：

需求确认；

页面设计；

前端开发；

后台开发；

内容录入；

测试；

上线；

然后才想到 SEO。

开发人员关注的是：

页面能不能打开；

功能能不能使用；

表单能不能提交；

移动端有没有错位；

接口有没有异常。

这些当然都重要。

但搜索系统还会关注另外一些东西：

页面地址是否稳定；

页面标题是否能够正常输出；

重要正文是否在初始页面中存在；

页面之间有没有合理关系；

旧地址如何处理；

重复页面如何控制；

状态码是否正确；

站点地图是否更新。

如果这些事情等上线以后才看，修改成本通常已经变高了。

二、我现在会在需求阶段先确定 “哪些页面需要长期存在”

一个网站在开发之前，往往会先确定栏目。

例如：

首页；

公司介绍；

业务栏目；

案例；

资讯；

联系我们。

以前只要确定页面数量，就可以开始设计。

现在我会多问一个问题：

哪些页面准备长期作为搜索入口存在？

比如企业有多个业务方向。

有些业务值得单独建立页面。

有些只是一个功能点，没有必要单独拆页。

如果开发阶段没有想清楚，后面很容易变成：

一个业务拆出很多相似页面；

不同栏目重复介绍同一个内容；

上线以后又不断新增相似 URL。

所以我现在更习惯先定义页面角色：

首页负责什么；

栏目页负责什么；

业务详情页负责什么；

文章页负责什么；

案例页负责什么。

这件事看起来像 SEO，其实更像信息架构设计。

三、URL 最好在开发阶段就确定，不要上线以后反复改

URL 是我现在比较早确认的一项。

因为 URL 一旦上线并被外部引用，后面再修改就会产生迁移问题。

例如开发时随手做成：

/page?id=28

上线以后觉得不好看，又改成：

/service/website

运行一段时间之后栏目又调整，再变成：

/solutions/website

技术上每次都能改。

但从长期维护角度看，每改一次都要考虑旧地址怎么办。

所以我现在会在开发阶段先确定几个原则：

URL 尽量稳定；

目录不要无意义地过深；

同一个页面保持主要访问地址；

测试地址和正式地址分开；

正式上线以后不要因为 “看起来更漂亮” 随意修改地址。

对开发者来说，这其实也是降低后续维护成本。

四、页面标题不应该完全交给运营人员后期补

以前做 CMS 时，有一种很常见的做法：

后台给一个 “SEO 标题” 输入框。

运营人员自己填。

看起来很灵活，但实际使用以后经常出现：

忘记填写；

全部复制栏目名称；

标题为空；

标题和页面正文完全不是一个主题。

后来我更倾向于在程序层提供一个默认规则。

例如：

业务名称 + 页面类型；

文章标题 + 栏目名称；

产品名称 + 基础业务信息。

运营人员需要的时候可以调整，但即使不填写，系统也应该能够生成一个基本合理的标题。

这种设计比 “所有 SEO 信息全部靠人工维护” 稳定很多。

五、前端开发时就检查正文是不是初始可见

现在企业站越来越多使用现代前端框架。

对开发来说，异步加载数据很方便。

但我会特别检查：

页面最重要的标题和正文到底什么时候出现。

如果打开原始 HTML 时几乎没有正文，所有内容都依赖浏览器执行脚本以后再生成，就需要考虑是否真的有必要。

不是所有页面都必须做服务端渲染。

但对于长期公开的企业业务页面，我更倾向于保证主要内容能够稳定输出。

例如：

H1；

业务名称；

主要介绍；

导航；

基础链接。

这些信息不应该完全依赖复杂交互才能出现。

六、测试环境不能只是检查 “有没有 Bug”

以前测试阶段主要是找程序 Bug。

现在会额外增加一轮 “搜索可见性测试”。

检查的内容其实并不复杂。

页面状态

正常页面是不是返回正常状态。

不存在的页面有没有正确处理。

页面标题

有没有空标题。

有没有大量完全一样的标题。

页面地址

有没有测试地址残留。

有没有一个页面出现多个地址。

内部链接

重要业务页面能不能从正常导航路径到达。

页面正文

关闭部分脚本以后，主要内容是否仍然能够正常理解。

robots 与站点地图

正式上线前的配置有没有准备好。

这一轮检查做完以后，很多问题根本不会进入正式环境。

七、robots.txt 是我现在上线时一定会重新检查的文件

这件事看起来很小，但非常容易出问题。

测试环境为了避免被搜索系统发现，经常会设置抓取限制。

如果上线时直接把测试环境配置一起部署到正式服务器，就可能出现：

网站已经公开；

用户能够正常访问；

但搜索抓取仍然受到限制。

所以我现在会把 robots 相关检查放到正式上线清单里，而不是凭记忆检查。

开发流程中越是 “太简单、不可能忘” 的事情，反而越容易被忘。

八、站点地图不应该上线后再手工做

如果一个网站本身有内容管理系统，我更倾向于让 Sitemap 自动生成。

原因很简单：

人工维护迟早会忘。

新增文章以后忘记加入；

删除页面以后旧 URL 还留着；

栏目修改以后地址没有同步。

这些问题都很常见。

如果系统能够根据实际有效页面自动更新，后面的运营工作会轻松很多。

所以我现在会把 Sitemap 理解成 CMS 功能的一部分，而不是 SEO 人员上线以后单独准备的文件。

九、网站改版功能也应该提前考虑旧页面

这是开发阶段很容易忽略的一点。

企业网站不是上线一次以后永远不变。

几年以后可能改版。

如果程序设计时完全没有考虑 URL 迁移，后面处理旧页面会比较麻烦。

所以现在做网站系统时，我会尽量保留：

页面旧地址记录；

重定向配置能力；

页面状态管理；

历史内容管理。

这样以后栏目变化或者页面合并时，不需要到服务器里手工改一堆规则。

从工程角度看，这属于给未来留下维护空间。

十、我现在会给上线流程加一个 SEO Gate

这个思路有点像代码质量检查。

一个版本准备上线以前，不只是问：

功能测试通过了吗？

还会增加几个问题：

重要页面能正常访问吗？

标题输出正常吗？

页面主要正文存在吗？

正式域名配置正确吗？

测试域名有没有混进页面？

站点地图正常吗？

抓取配置正确吗？

重要页面有没有内部入口？

如果其中有明显异常，就先不发布。

我把它理解成一个很轻量的 “SEO Gate”。

它不是为了让开发人员变成 SEO 人员，而是防止技术问题进入生产环境。

十一、上线后的工作变成验证，而不是救火

流程调整以后，一个比较明显的变化是：

上线后的 SEO 工作轻松了一些。

以前上线以后经常是在找问题：

为什么这个页面抓不到；

为什么出现两个地址；

为什么标题为空；

为什么测试环境被发现；

为什么正式站禁止抓取。

现在更多是验证：

正式环境与测试结果是否一致；

搜索爬虫是否开始正常访问；

新页面是否进入正常发现路径；

有没有上线后才出现的异常。

从 “上线以后救火” 变成 “上线以后观察”，整个项目会舒服很多。

十二、这套方法对小团队反而更有用

大型团队可能有专门的 SEO、开发、测试、运维人员。

独立开发者或者小团队通常没有这么细的分工。

一个人可能同时负责：

需求；

设计；

开发；

部署；

内容；

运营。

这种情况下，把技术 SEO 做成开发流程的一部分反而更实际。

因为不需要额外记住：

“以后什么时候再来做 SEO。”

项目流程本身就会提醒你检查。

我的一个判断

做了一段时间以后，我越来越觉得：

技术 SEO 比较适合被看成网站质量的一部分，而不是上线以后额外加的一层东西。

页面地址稳定，本身是工程质量。

正确的状态码，本身是工程质量。

清楚的页面结构，本身是产品设计质量。

稳定输出主要内容，本身是前端质量。

合理的内部页面关系，本身也是信息架构质量。

这些事情做好以后，本身就会让搜索系统更容易理解网站。

最后的反思

以前我们很容易把 SEO 问题交给运营阶段。

开发完成以后说：

“后面再做 SEO。”

但如果真正的问题来自程序结构，运营人员最后还是得回来找开发。

所以现在我的思路发生了变化：

不是开发完成以后再给网站 “加 SEO”。

而是在开发过程中，尽量不要制造明显影响搜索可见性的技术问题。

对于长期运营的企业网站，我觉得这种方式比上线以后不断修补更可控，也更符合开发者的工作习惯。

本文由梓彤超越（武汉）科技有限公司结合企业网站建设、技术 SEO 与 GEO 搜索可见性相关项目实践整理。ztbey.com