跳至正文
Ende Sun
EN ES 中文
返回博客

人工智能与自动化

用 AI 做可复现的技术 SEO：可验证的结构化数据与 301 重定向

阅读需 8 分钟

用 AI 做可复现的技术 SEO：可验证的结构化数据与 301 重定向

每次搭建或迁移网站，几乎都会遇到两项技术 SEO 工作：添加结构化数据，让搜索引擎理解页面内容；以及把旧网址重定向到新网址，不丢失旧站已经积累的权重。这两项工作手写都很繁琐，也很容易在不知不觉中出错。它们同样很适合交给 AI 来做——前提是把 AI 的输出当作草稿，并用独立的工具加以验证。

随着时间推移，我把这两项工作分别整理成了笔记里简短、可复用的流程。真正有价值的不是提示词本身（它们都很短），而是整个步骤顺序：生成、用工具验证，再请第二方复核。

第一部分：使用 schema.org 的结构化数据

结构化数据不等于富媒体搜索结果

我在笔记里记下的第一个区别是：结构化数据和富媒体搜索结果相关，但并不是一回事。

  • 结构化数据是一种标记，通常是使用 schema.org 词汇表的 JSON-LD，用来描述页面的内容：一个组织、一家本地商户、一件商品、一篇文章。
  • 富媒体搜索结果是搜索引擎在发现受支持类型的有效结构化数据时，可能展示的增强型搜索结果。

结构化数据有效，并不保证一定会出现富媒体结果。把两者区分开，才能避免验证错了对象。

生成

第一个提示词刻意写得很开放：

告诉我你会在我的网站上添加哪些 schema.org 结构化数据。

我会提供网站的网址或相关 HTML，得到的回答是一组建议的类型，以及每种类型对应的 JSON-LD 脚本。对于典型的小型企业网站，结果大致如下（已替换为中性示例）：

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Example Studio",
  "url": "https://www.example.com/",
  "logo": "https://www.example.com/logo.png",
  "sameAs": [
    "https://www.linkedin.com/company/example-studio",
    "https://www.instagram.com/example.studio"
  ]
}
</script>

这段脚本放在页面的 <head> 中；如果是静态网站，就放进 index.html。

接着是第二个同样简短的提示词，用来补上第一次遗漏的内容：

告诉我还缺哪些结构化数据才能做到完整。

与其一次性要求全部内容，不如专门询问缺口，这样往往能发现第一次回答中漏掉的属性和类型。

验证

脚本绝不会仅仅因为是模型生成的就直接上线。我会用两个不同的工具验证两次，它们回答的是两个不同的问题：

  1. schema.org 验证工具（validator.schema.org）：标记语法是否有效、类型是否正确？
  2. Google 富媒体搜索结果测试（search.google.com/test/rich-results）：这个页面是否有资格获得某种富媒体结果？

如果第一项通过、第二项没有通过，说明标记本身没问题，只是该类型不属于能产生增强结果的类型——这正是前面提到的结构化数据与富媒体结果的区别。我还会逐一核对每个字段是否属实：模型很可能会填上一个看似合理、实际却不存在的电话号码或 logo 路径。

第二部分：不产生循环的 301 重定向

问题所在

迁移网站时，每个已经有流量或外部链接的旧网址，都需要永久重定向到对应的新网址。在 Apache 主机上，这通常意味着在 .htaccess 中编写 RewriteRule 规则。手写几十条规则很容易出错，而常见的错误又很隐蔽：重定向循环、双斜杠，或者多条规则串联成多次跳转。

把提示词当作需求说明

这里的提示词与其说是提问，不如说是一份需求说明。我每次都会写明以下要求：

  • 每个源网址与目标网址一一对应。
  • 使用 301 永久重定向。
  • 不得出现循环，也不得出现双斜杠（//）。
  • 一条全局规则：凡是请求不带结尾斜杠的网址，都重定向到带结尾斜杠的版本；但如果最后一段看起来像文件（包含点号）则除外。
  • 输出为一个完整的代码块，可以直接粘贴到 <IfModule mod_rewrite.c> 中。

需求之后是网址映射，每行一个：

https://oldsite.example.com/en/tickets -> https://newsite.example.com/en/tickets/
https://oldsite.example.com/es/entradas -> https://newsite.example.com/es/entradas/
https://oldsite.example.com/fr/billets -> https://newsite.example.com/fr/billets/

把要求明确写出来，比措辞本身更重要。只说“帮我写一些重定向”，模型给出的结果看起来没问题；而明确给出循环和斜杠方面的约束后，模型写出的规则通常会遵守这些约束。

下面是我期望得到的代码块示例（已匿名化）：

<IfModule mod_rewrite.c>
    RewriteEngine On

    # 一对一的具体映射。可选斜杠（/?）同时匹配两种写法
    RewriteRule ^en/tickets/?$ https://newsite.example.com/en/tickets/ [R=301,L]
    RewriteRule ^es/entradas/?$ https://newsite.example.com/es/entradas/ [R=301,L]
    RewriteRule ^fr/billets/?$ https://newsite.example.com/fr/billets/ [R=301,L]

    # 全局规则：为看起来不像文件的路径添加结尾斜杠
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_URI} !\.[A-Za-z0-9]+$
    RewriteCond %{REQUEST_URI} !/$
    RewriteRule ^(.*)$ /$1/ [R=301,L]
</IfModule>

检查规则顺序

我每次都会人工检查的一点是规则的顺序。Apache 从上到下处理规则，[L] 会在第一次匹配后停止。如果在旧域名上先执行全局的结尾斜杠规则，那么对 /en/tickets 的请求会先在同一域名下被重定向到 /en/tickets/，然后才跳转到新网站——本来一次跳转就够，结果变成了两次。把具体映射放在前面，并让匹配模式同时接受带斜杠和不带斜杠的网址，就能避免这种串联跳转。无论模型选择哪种顺序，我都要确保它是经过考虑的。

验证

和结构化数据一样，任何规则都不会因为模型这么写就直接部署：

  1. .htaccess 测试工具（technicalseo.com/tools/htaccess/）：粘贴规则，用真实的源网址逐一测试，看每个网址最终跳转到哪里。
  2. 请另一个 AI 做审查，并提出一个范围明确的问题：
分析这个 .htaccess，告诉我它是否会导致严重错误。

没有参与编写规则的审查者会从不同角度看问题；而专门询问严重错误，可以让回答集中在循环、语法错误和永远无法匹配的规则上，而不是代码风格。

只有两项检查都通过后，规则才会上传到服务器；部署完成后，我还会立即在浏览器中访问几个旧网址确认效果。

为什么我把它们保存为固定流程

这两个流程都不复杂。关键在于它们被写了下来，而且可以重复执行：每次使用相同的提示词、相同的要求、相同的两步独立验证。AI 让第一版草稿产出得很快；而写成文档的流程和验证工具，才是结果值得信赖的原因。