静态网站的 SEO：8 个需要警惕的问题

Vibe coding 让搭建静态网站变得前所未有的简单。使用 Astro、Jekyll、Gatsby、Hugo 或其他静态框架，就能快速搭起一个网站，完全无需接触传统的 CMS。

但搭建更容易，并不必然意味着优化更容易。

WordPress 以及其他 CMS 会通过插件和内置功能默默处理许多 SEO 基础工作，从规范标签（canonical）和站点地图，到重定向、元数据、结构化数据（schema）和 404 处理。

而在静态网站上，这些工作大部分都变成你自己的责任。

为弄清实践中哪些环节容易出错，业内专家 Suganthan Mohanadasan、Pedro Dias 和 Ryan Law 分享了他们搭建和处理静态网站的经验。

正如 Suganthan 所说，

这并不意味着静态网站对 SEO 不利，只是意味着你需要清楚：CMS 过去替你做了哪些事，以及现在哪些事需要你自行搭建、配置和监控。

静态网站常见的 SEO 问题

静态网站可以很快、技术上也更干净，但也为一些细小的SEO 错误留下更多可乘之机，因为没有 CMS 或插件在后台替你处理这些事。

对vibe coding 出来的网站而言，这一点更为重要：AI 能把页面搭出来，但不一定知道你想让它在整个网站遵循哪些 SEO 规范。

以下是一些最常见的、需要警惕的问题：

网站审计是发现这些问题最简单的方法之一。

Ahrefs 的 Site Audit 会抓取网站，并呈现出 170 多个可能被忽视的技术 SEO 问题，在没有 CMS 或 SEO 插件替你检查时尤其有用。

1. 尾部斜杠与规范标签的冲突

静态网站可能不小心让同一个页面通过两个 URL 访问，例如 /page 和 /page/。

这通常是因为静态框架和托管平台对尾部斜杠有不同的默认设置。

框架可能生成一种版本，而主机却提供或重定向到另一种版本。

问题在于，规范标签、内链和重定向之后可能就哪个 URL 是首选版本产生分歧。往好里说，这会产生不必要的重定向；往坏里说，搜索引擎可能看到重复的 URL，排名信号也会在它们之间被拆分。

如何在静态网站上修复尾部斜杠问题

选定一种 URL 格式（带或不带尾部斜杠），并在整个网站一致使用。

同时配置框架和托管环境，让它们遵循同一约定，再检查规范标签和内链是否指向实际能解析的那一版。

也可用 Ahrefs 的 Site Audit 抓取网站，找出规范冲突、重定向链，以及指向非规范 URL 的内链。

2. Robots.txt、站点地图与 noindex 的冲突

在静态网站上，XML 站点地图通常由代码生成。问题在于，站点地图生成器可能并不知道你把哪些页面标记成了 noindex。

这意味着草稿、感谢页、确认页，或其他你不想出现在搜索中的页面，仍可能被收录进站点地图。

出现这种情况是因为没有 CMS 插件替你让一切保持同步。一个页面可能已被排除在主导航之外，或被标记为 noindex，但除非你明确编写了排除它的逻辑，否则它仍会出现在站点地图或 RSS 源中。

随着网站增长，这种设置也可能变得脆弱。基本的扁平化站点地图相当容易管理，但一旦需要按页面类型拆分站点地图、排除某些板块，或对不同模板应用不同规则，事情就会变得更复杂。

静态网站在 robots.txt 上也可能遇到类似问题。

视框架和部署方式而定，robots.txt 可能不会自动生成，因此值得检查该文件是否存在，以及它是否包含你真正想要的抓取规则。只需记住：robots.txt 控制的是抓取，而不是索引，因此它不应被当作 noindex 的替代品。

如何在静态网站上修复站点地图问题

为想要排除在搜索之外的页面建立一条统一规则。例如把它们标记为 noindex: true，再让站点地图和 RSS 源忽略任何带有该标记的页面。同时检查 robots.txt 文件是否存在、是否把搜索引擎指向正确的站点地图，以及是否无意中屏蔽了你想被抓取的板块。

每当新增一种页面类型，或改变页面的生成方式时，都要重新检查这套逻辑。

也可用 Ahrefs 的 Site Audit 把站点地图中的 URL 与可索引性信号对比，揪出那些本不该出现在里面的页面。

例如，这份报告能帮你追踪那些可索引、却不在站点地图里（而本应存在）的页面，以及那些本不该出现在站点地图里、却偏偏出现在里面的 noindex 页面。

3. 图片优化的缺口

有些静态网站框架自带用于更高效地调整尺寸、压缩和提供图片的工具，但这并不普遍。例如，Jekyll 默认会原样复制图片文件，不会自动调整尺寸、压缩或转换格式。要在 Jekyll 里获得这些图片优化效果，就需要一个插件、一个图片 CDN，或在发布前单独走一道图片处理流程。

即便某个框架确实自带图片工具，它们通常也只在你通过该框架的图片流水线添加图片时才生效。

例如，Next.js 通过 next/image 提供了一个 <Image> 组件，能自动处理响应式尺寸、优化、懒加载以及提供现代图片格式等事项。若改用普通的 HTML <img> 标签，就得自己处理这些优化。

若直接把一张原始图片丢进网站，它可能完全绕过那套流程。

你最终可能发布一个远大于所需的图片文件，这会拖慢页面加载（尤其在移动端）；也可能发布一张没有替代文本（alt text）的图片，让使用屏幕阅读器的人更难访问，也让搜索引擎更难了解这张图片展示的内容。由于网站仍能成功构建，这两个问题在发布前都不一定会被察觉。

这正是它容易被忽略的原因，尤其在 vibe coding 出来的网站上：页面在预览里可能看起来完全没问题，同时却加载着不必要的大图，或标记不完整的图片。

如何优化静态网站上的图片

应持续使用框架的图片组件或优化流水线，而不是把原始文件直接丢进页面。发布前，检查是否有过大的图片，以及缺失或空白的替代文本。

也可用 Ahrefs 的 Site Audit 抓取网站，检查过大的图片文件、缺失的替代文本，以及其他与图片相关的 SEO 问题。

还有一个专门的 Images 报告，可用它更深入地排查具体的图片问题：

4. 模板驱动的元数据与结构化数据错误

在静态网站上，标题、元描述、规范标签和结构化数据往往基于共享模板生成。这让它们管理起来很高效，但也意味着一个糟糕的默认设置可能一下子影响数百个页面。

例如，自动把品牌名加到每个标题上，可能让一整组页面标题超出预期长度。

结构化数据也是如此。若模板使用了错误的类型、漏掉必需的属性，或错误地组织关系，该错误会在所有用到该模板的地方被复制传播。

如果你曾在 WordPress 上用过 Yoast，这个思路与其 SEO 标题及元描述模板类似。

你可以一次性定义一个模式，例如给每个页面标题添加网站名称，再把它应用到整个内容类型上。区别在于，Yoast 提供了一个专门管理这些规则的 SEO 界面。

而在静态网站上，你可能要把同样的逻辑直接写进模板。

例如，Next.js 允许在一个共享布局里一次性定义标题模板，并把它应用到多个页面。这很方便，但也意味着一个糟糕的默认设置会以同样快的速度扩散。

Vibe coding 会让这个问题更容易被忽略：AI 生成的模板可能产出看起来合理的元数据或基础结构化数据，却不一定匹配实际需要的页面类型或结构。

如何修复静态网站上的模板错误

在搭建模板之前，先为每种页面类型定义好元数据和结构化数据的要求。然后每次改动时，测试多个使用该模板的页面，而非只测一个例子。

具体到结构化数据，把生成的标记拿去跑 Google 的 Rich Results Test（富媒体搜索结果测试）：

或者试试 Schema.org 的验证器。

Ahrefs 的 Site Audit 也能帮助发现整个网站上标题、元描述、规范标签和结构化数据方面的问题。

5. 不正确的 HTTP 状态码

一个页面在用户看来像是 404，却仍向搜索引擎返回 200 OK 状态码。

例如，开发者 Josh Deltener 记录了这一问题在一个部署到 Vercel 的 Nuxt 静态网站上发生的情况。

该页面肉眼可见地显示了“404 — 页面未找到”的信息，但 Chrome 开发者工具显示这个请求返回的是 200 状态。Google 会把它当作软 404（soft 404），因为页面声称自己不存在，而服务器却报告响应成功。

当 404 处理没有在框架或托管层面正确配置时，就可能出现这种情况。在 Deltener 的 Nuxt 配置中，问题源自一个生成的 200.html SPA 回退页被用来响应未知路由。

棘手之处在于，光看页面并不一定能在网站上发现同样的问题。要留意那种设计上写着“页面未找到”、而底层 HTTP 响应却说一切正常的情况。

如何修复静态网站上的 HTTP 状态处理

创建一个规范的 404 页面，再测试几个你确知不存在的 URL，检查实际的 HTTP 响应码。它们应返回 404，而不只是显示一个看起来像 404 的页面。

Ahrefs 的 Site Audit 也能发现返回意外状态码的 URL，包括软 404 和失效的内链，从而捕获那些仅靠手动浏览网站不易察觉的情况。

6. 内链不一致

静态网站最终可能出现内链不一致的情况，尤其当不同模板或 AI 生成的组件构建 URL 的方式稍有不同时。

例如，有些链接可能指向 /about，而另一些指向 /about/；也可能把诸如 ../about/ 这样的相对 URL 和诸如 https://example.com/about/ 这样的绝对 URL 混在一起。

这些格式本身都没有错，但当它们与为网站选定的 URL 约定不一致时，问题就出现了。

即使经验丰富的团队也可能遇到这些问题。当我们把博客迁移到一个新的网站框架时，一条配置错误的内链规则导致我们把所有内链都设成了 nofollow，实际上等于告诉 Google 忽略它们。这并不理想：

这些问题会产生不必要的重定向，让爬虫经过多个 URL 版本，并使内链信号更难集中到每个页面的规范版本上。这在 vibe coding 出来的网站上尤其容易被引入，因为 AI 生成的组件可能使用不同的 URL 格式，除非你明确告诉系统该遵循哪种约定。

如何修复静态网站上的内链不一致

选定一种 URL 格式，并在模板、导航、面包屑和正文内链接中一致使用。

• www 与非 www：例如 www.example.com 或 example.com
• 尾部斜杠与无尾部斜杠：例如 /about/ 或 /about
• 绝对 URL 与相对 URL：例如 https://example.com/about/ 或 /about/
• HTTP 与 HTTPS：所有内链都应指向 HTTPS 版本
• 大写与小写：通常用小写，例如 /about-us/ 而不是 /About-Us/
• 文件扩展名与简洁 URL：例如 /about/ 而不是 /about.html
• 连字符与下划线：例如 /seo-guide/ 而不是 /seo_guide/
• 参数处理：决定何时应该链接到、规范化或避免诸如 ?sort=price 这类带查询字符串的 URL
• 默认页/索引页：避免混用 /about/、/about/index.html 和 /about 这类 URL

在可能的情况下，把这个格式一次性定义在一个共享的链接组件或辅助函数里，而不是在全站手动敲 URL。

再抓取网站，检查是否有指向重定向或非规范 URL 版本的内链。Ahrefs 的 Site Audit 能标记出链接到重定向的页面：

而 Site Structure 报告则能帮你检视 URL 是如何按文件夹和链接深度组织的。

7. 技术性能问题

静态网站素有速度快的名声，但仅凭静态生成并不能保证良好的性能。

一个网站仍然可能：

• 加载过多 JavaScript
• 在每一个页面上加载并不需要的 CSS
• 使用沉重的第三方脚本
• 字体或图片加载不当
• 低效地打包代码

即使 HTML 本身是提前生成的，这些问题也会拖慢渲染和交互。

Vibe coding 出来的网站尤其值得检查。

AI 会不断添加脚本、库、动画和组件，却不一定考虑它们累积起来的性能成本。一个页面在预览里可能看起来很精致，但每迭代一次就变得更重。

如何修复静态网站上的技术性能问题

检查构建背后的技术决策，包括：

• JavaScript：避免在每个页面上加载或激活不必要的交互代码。
• 代码分割：把大块 bundle 拆成更小的分片，在需要时再加载。
• CSS：避免加载只有少数页面才需要、却全站通用的样式，并考虑为折叠线以上内容使用关键 CSS。
• 渲染策略：根据每个页面实际需要，使用静态生成、服务端渲染或其他渲染方式。
• 图片和字体：压缩资源，使用响应式图片，只预加载关键资源，避免不必要的字重。
• 第三方脚本：移除或延迟那些对首屏加载并非必需的脚本。
• 缓存与 CDN 分发：确保静态资源得到缓存并被高效地提供。

然后去测试完成后的网站，而不是想当然地认为静态构建就一定快。用 PageSpeed Insights 检查 核心网页指标，例如 LCP、INP 和 CLS，并抓取网站以发现多个页面上的性能问题。

也可查看 Ahrefs 的 Site Audit，获取关于 JavaScript 和 CSS 错误的具体报告：

8. 迁移特有的 SEO 陷阱

从 CMS 迁移到静态网站，即便新页面看起来一模一样，也可能引入 SEO 问题。

这是因为一次网站迁移往往移走的不只是 CMS 界面：你还可能失去重定向、站点地图规则、元数据逻辑、结构化数据、内链行为，以及其他此前在后台处理的 SEO 设置。

最大的风险之一是 URL 变更。

若一个旧 URL 消失，却没有恰当的 301 重定向指向它的替代页，那么指向该页面的所有链接和排名信号都可能丢失。

可用 Ahrefs SEO 工具栏轻松检查这一点。下面是我们最近一次国际博客迁移的例子，从一个子文件夹结构移到另一个：

像遗留的规范标签、过时的站点地图条目，或从构建或缓存中提供的陈旧资源这类东西，也很容易被忽略。

迁移到静态网站后如何保住 SEO 表现

把这次迁移当作一次完整的 SEO 迁移，而不仅仅是一次改版。上线前：

• 把每一个旧 URL 映射到它的新目标。
• 在 URL 发生变化的任何地方都添加 301 重定向。
• 对比新旧规范标签、元数据、结构化数据和站点地图规则。
• 检查重要的内链是否仍指向正确的页面。
• 上线后测试线上网站，而不只是预览或预发布构建。
• 抓取新旧两个版本，以便发现缺失的页面、重定向错误和其他意外变化。

静态迁移完全可行，但不要想当然地认为新框架会重建你旧 CMS 在后台默默做的一切。

哪些静态网站框架更利于 SEO？

并不存在某个天生就“最适合 SEO”的静态框架。

Astro、Next.js、Gatsby、Hugo、Jekyll 以及类似的框架都能支撑强大的 SEO，但所需工作量取决于你要构建什么。像规范标签、Open Graph 标签、结构化数据、站点地图规则和 noindex 处理这些东西，仍需你自行配置，而不能想当然。

图片处理是各框架差异更明显的一个方面。

有些框架（如 Astro）自带更强的图片工具，另一些则把更多优化工作留给你。但在元数据、结构化数据、规范标签和站点地图逻辑方面，更大的差异通常取决于你把框架配置得有多好，而非选了哪一个。

因此，与其问“哪个框架最适合 SEO？”，不如问：

• 它能否干净地处理你想要的 URL 结构？
• 规范标签和元数据是如何生成的？
• 你能否控制 noindex 规则和站点地图的排除项？
• 内置了哪些图片优化？
• 添加并验证结构化数据有多容易？
• 重定向、404 和内链需要投入多少人工？

正确的选择取决于你要构建的网站，以及你实际需要多少技术控制权。

正如 Pedro 所说：

这大概是更有用的决策框架。一个只有几个页面、更新不频繁的小网站，可能非常适合静态方案；而一个工作流复杂的大型内容发布机构，可能就不适合。

最后的想法

静态网站可以给你更多控制权、更少依赖，也让你更少依赖插件，但这种控制也意味着更多责任。

传统 CMS 把大量 SEO 管道藏在插件和默认设置背后；而在静态或 vibe coding 出来的网站上，你更可能需要自己接手这套管道，从规范标签、站点地图，到重定向、结构化数据、性能和状态码。

Vibe coding 让搭建过程更快，但并未消除理解什么才是好的技术 SEO 的必要性。