能在AI总览、无头重建和下一次算法更新中存活的技术性搜索引擎优化。

技术性搜索引擎优化是决定搜索引擎和AI助手能否抓取、渲染和信任你的页面的那一层工作——在内容或反向链接产生任何效果之前。它涵盖HTTP行为、HTML语义、结构化数据、hreflang、规范化、核心网页指标和JavaScript渲染。处理不当，你的其他投资就全都白费了。

2026年这个定义已经扩展。两个变化推动了它。首先，AI总览和ChatGPT驱动的搜索现在位于大多数用户和底层页面之间，这意味着可引用性和排名一样重要。其次，标准网站不再是WordPress安装——而是某种无头前端，从Sanity、Strapi、Payload、Storyblok、Contentful或无头WordPress后端拉取内容。这些堆栈中的每一个都引入了旧的手册没有涵盖的自己的技术性搜索引擎优化失败模式。

我对2026年客户的工作定义：技术性搜索引擎优化是Lighthouse运行、Search Console爬虫报告、AI总览引用检查和结构化数据验证器注意到的一切——跨越每个语言地区、每个模板、每个渲染路径。如果这四个信号中的任何一个在代表性URL上失败，我们就从那里开始。

在 headless 或 Jamstack 站点上，你的前端框架负责渲染，而你的 CMS 负责内容——SEO 可能会在两者之间的鸿沟中丧失。经典的 WordPress + Yoast 模式假设了一个服务器、一个渲染器、一套规则引擎。将内容从 WordPress 拉入 Next.js 或 Astro 后，你无法自动继承其中的任何功能。

Headless WordPress 配合 Next.js 或 Astro

我们在 2026 年看到的最常见配置：WP REST 或 WPGraphQL 暴露文章和页面，Next.js App Router 或 Astro 在构建时或通过 ISR 拉取它们。优势是真实存在的——页面可以不带任何插件臃肿而发布，Core Web Vitals 很容易保持绿色，编辑器还能保持熟悉的后台管理界面。陷阱也同样真实存在。Yoast 规范链接和元描述需要通过 API 边界传输；在 WordPress 中定义的重定向需要被放入 vercel.json 或 Netlify _redirects；站点地图通常需要在前端构建时重新生成，而不是在 WordPress 那一侧；搜索控制台验证需要在公开源上进行，而不是在 wp-admin 域名上。

纯现代技术栈

一个 Next.js + Sanity 构建、一个 Astro + Storyblok 构建、一个 Nuxt + Strapi 构建、一个 Next.js + Payload 构建——这些都完全跳过了 WordPress。技术 SEO 工作转向了确保你的 CMS schema 建模了前端需要的 SEO 字段（规范链接覆盖、重定向映射、hreflang 分组、schema 扩展 JSON），以及确保内容变更时按需重新验证会被触发。ISR 缓存中毒是沉默的杀手——页面在发布后因为 revalidatePath 从未被连接而被以过期状态提供数小时。

什么真正最先出问题

根据我们运行的大约 200 次 headless 审计，单一最常见的生产环境破坏问题是规范链接冲突——前端发出一个规范链接，而 CMS 元数据或站点地图发出另一个。Google 会选择其中之一，几乎总是不是你想要的那个，结果错误的 URL 被索引。我们通过构建时 linter 来捕捉这个问题，它将从模板发出的规范链接与存储在 CMS 中的规范链接进行对比，对页面样本进行比较，并在不匹配时中止构建。

WordPress 给了你最强的插件火力和最多的自我伤害方式。经典 WordPress 站点上的技术 SEO 剧本主要是关于减法——移除重复的规范链接、消除 Yoast 和 RankMath 及第三个你都不记得安装过的插件之间的 schema 冲突、驯服那些耗费 2 MB CSS 的页面构建器，以及清理已经积累八年的重定向链。

我们在 2026 年推荐的默认技术栈：单个 SEO 插件（RankMath 或 Yoast，绝不两个都用）、一个配有适当边缘缓存的托管主机（Cloudways、Kinsta、WP Engine）、用于性能重要的新项目的 Bricks Builder，或带有 Kadence 或 Blocksy 的原生 Gutenberg、一个导出为可移植格式的重定向管理器、以及 Perfmatters 或 FlyingPress 用于资源清理。审计工作就是找出你的站点中哪些决策被做得不同，然后逐一解开其后果。

在无头架构方面，工作从减法转向建设。没有 Yoast，所以 meta 限制必须自己构建。没有插件 schema，所以 JSON-LD 必须模板化。没有内置 sitemap，所以必须生成和流式传输。我们为无头项目添加的 SEO 代码量通常是 WordPress 站点免费提供内容的三到五倍——但这些代码是自有的、版本受控的、可测试的，不会因为下一次插件更新而破坏。

GEO 和 AEO 是两种不同的 AI 功能蚕食搜索流量方式的名称。AEO（Answer Engine Optimisation，答案引擎优化）是较早的术语——它涵盖 Google 功能，如精选摘要、People Also Ask 和 Knowledge Panel，这些功能从你的页面提取一段内容并将其显示为答案。GEO（Generative Engine Optimisation，生成式引擎优化）是较新的术语——针对 AI Overviews、ChatGPT 搜索、Perplexity 和 Bing Copilot 进行优化，助手生成一段段落并将你的页面作为来源引用。

这在结构上意味着什么

两个界面都需要同一样东西：可引用的段落。在所有这些界面中获胜的结构规则是相同的。使用问题作为你的 H2，而不是主题标签。在标题后的前一两个句子中放置答案。将答案控制在 250 字以内。确保答案在服务器端渲染，而不是在页面加载后水合的 JavaScript 组件内部。AI 爬虫和 Google 提取器大多不运行 JavaScript——如果你的答案需要 JS 才能显示，你就是隐形的。

GEO 与 AEO 的差异

三件事对 GEO 尤其重要。实体权威——Google 和 LLM 建立一个图表，显示谁被允许谈论什么，未链接的品牌提及为其提供数据。带有 about 和 mentions 数组的 Schema——它们使你的页面可以作为实体图的一部分被解析，而不是一堵文字墙。以及 llms.txt——一个新兴的标准文件，位于 /llms.txt，为 AI 工具提供你的站点的精选地图，就像 robots.txt 和 sitemap.xml 帮助搜索爬虫一样。我们在构建的每个站点上部署 llms.txt，每当有主要页面上线时就更新它。

你需要的 schema 类型比大多数插件发出的要少，但你发送的类型必须有效且一致。一个简短的列表涵盖了九成的项目。

• Organization——在你的布局中有一个单一的站点级别图表，包含 logo、sameAs（仅限真实社交账户）、address 和 contactPoint。永远不要在每个页面重复这个。
• WebSite — 在布局中出现一次，如果您有站内搜索，则需包含 potentialAction 用于站点链接搜索。
• BreadcrumbList — 在每个非首页上出现，使用locale正确的URL（法语页面必须指向 /fr/ 祖先，而不是 /en/）。
• Article 或 BlogPosting — 在长篇内容上，使用 about 和 mentions 数组来强化实体图。
• Service — 在商业页面上，包含 serviceType、provider、areaServed、audience，以及当您能发布价格范围时的 offers.priceSpecification。
• Product — 在电子商务上，包含 offers.priceCurrency、availability，以及仅当您有真实评价时的 aggregateRating。
• FAQPage — 当页面上至少有两个真实问题时。为了赢得schema标记而伪造常见问题是我们清理的最常见手动操作触发器。
• LocalBusiness 或其子类型之一 — 在物理位置页面上，包含地理坐标和 openingHoursSpecification。

三件事会在生产环境中破坏schema。发明schema.org未定义的属性。为 sameAs 发明虚假值（假LinkedIn URL、被遗弃的Twitter账号）。以及从多个插件发送冲突的Organization图。我们在构建linter中运行schema验证器，并在这三种模式中的任何一种出现时使构建失败。

Hreflang在大规模时失败是因为约束是双向的，且数据集是稀疏的。页面的每个locale变体必须自我引用，必须引用所有其他变体，并且必须被所有其他变体反向引用。在一个locale中的一个页面上漏掉一个方向，Google就会悄悄降低该集群的等级。

能够规模化的模式

在每一行可翻译的内容上存储一个 content_group_id（或等价的标识符）。一个页面的每个语言版本都共享一个 ID。hreflang 生成器、sitemap 生成器和规范链接生成器都从该 ID 派生出它们的集群。切勿仅从 URL 模式匹配来计算 hreflang — 它在边界情况下会失效（一个存在西班牙语版本但没有印地语翻译的页面，如果你的代码假设"如果 pageX 存在于语言 A，那么它也存在于语言 B"，就会破坏集群）。

什么在实践中杀死了 hreflang

我们反复看到的三个模式。语言代码正则表达式顺序错误 — 在语言检测正则表达式中把"zh"放在"zh-Hant"之前，这会捕获错误的语言代码并生成破损的 hreflang。忘记 x-default — 每个集群都需要一个 x-default 后备选项，通常指向英文版本。集群 ID 漂移 — 一个翻译获得了新的 ID，而不是继承源 ID，无声地把一个集群分裂成两个不相关的集群，两个都没有完整的互相引用。

我们总是在构建时添加一个 hreflang linter，它抓取一批页面样本，遍历它们引用的 hreflang 集群，如果任何集群不完整或不对称就让构建失败。

程序化 SEO 是从结构化数据源加上模板生成数千个页面 — 目录、对比页面、位置页面、术语表页面。做得好的话，它可以以单个作者的内容无法匹配的规模击中长尾。做得不好的话，它会触发人工审查，并在一夜之间删除你大部分已索引的页面。

什么把干净的程序化构建与薄弱内容分开

三件事。每个页面真实数据 — 每个 URL 都有至少一个对它来说唯一的事实、数字或细节；薄弱的程序化页面共享 95% 的内容。一个有意义的模板 — 该模板围绕唯一的数据添加上下文、对比、推荐或聚合，而不仅仅是搜索引擎优化的包装。以及质量控制 — 数据不足的页面被排除在 sitemap 之外、被阻止索引或保持在草稿状态直到数据层填充完整。

我们从大规模运行这个系统中学到的东西

我用 Next.js 加 Supabase 构建了 HostList.io，这是一个程序化 SEO 平台，大约有 28,000 个网络托管公司页面。在两年的 Google 更新中活下来的页面，都是每个 URL 至少有三个独特数据点，再加上一个进行对比、评分或推荐的模板。我们被取消索引的页面，都是那些独特数据只有名称和价格的页面。从索引中删除薄页面的成本很小，但保留它们的成本在 2024 年 3 月的有帮助内容更新到来时产生了全站排名惩罚。

我们把这套运营手册带到客户的程序化构建中——Next.js 或 Astro 前端，Supabase 或 Postgres 数据，一条在发布前按唯一性为页面评分的摄入管道，一个以分块流式传输的网站地图因为超过 50,000 个 URL 无法放入单个 sitemap.xml，还有一个将每个叶节点拉入主题集群的内部链接图。

在 CrUX 字段数据的第 75 百分位数处通过 Core Web Vitals，而不是在受控的 Lighthouse 实验室运行中。来自 CrUX 的字段数据是 Google 使用的；Lighthouse 是一个调试工具。两者在真实网站上的差异通常达到 30% 或更多。

预算实际流向何处

LCP 几乎总是首图，几乎总是通过以 80% 质量重新编码为 WebP、调整到实际显示尺寸加 2 倍视网膜、在 head 中添加预加载标签，以及设置 fetchpriority="high" 来解决。一个 1 MB 的首图变成 30 KB 的 WebP 是大多数项目中影响最大的单一变化。CLS 来自没有显式尺寸的图像和广告——每个图像上都有显式的 width 和 height 属性、固定高度的广告插槽，以及为任何客户端小部件预留的空间。INP 来自交互上的重 JavaScript——通常是第三方标签管理器或过度热情的分析库。修复方法是防抖、延迟加载或替换为更轻的等效物。

大多数项目遗漏的地方

两种模式。首先，LCP 图像在 Carousel 组件或 JavaScript 驱动的布局内——图像只在 JS 运行后才呈现，你的 LCP 是轮播的加载骨架，不是照片。其次，网络字体加载时没有 font-display: swap 也没有预加载——文本在字体下载时不可见 200-400 ms，你的 LCP 被推过 2.5 s 阈值，即使图像很快。这两者都是通过 CrUX 字段数据审查捕获的，而不是单个 Lighthouse 运行。

构建时 SEO linter 是在你的构建结束时运行的脚本，从输出目录中抽样一部分渲染的 HTML 文件，如果它发现会在生产中降低 SEO 的模式就使构建失败。这是我们添加到客户代码库中影响最大的单一习惯。

我们的检查项目

• 每个页面都有且仅有一个 H1。
• 每个可索引网址上的 Meta 描述在 120 到 155 个字符之间。
• html lang 属性与区域路径匹配（/fr/ 页面的 lang="fr"）。
• 可翻译路由上的 Hreflang 集群完整且双向。
• 每个页面上的 JSON-LD 都针对 schema.org 定义有效。
• 没有禁止的内容模式 — sameAs 中的虚假社交 URL、硬编码的测试占位符文本、禁止使用的通用文案词汇。
• 模板发出的规范 URL 与 CMS 中存储的规范匹配。
• 样本模板上的图片 WebP 和明确尺寸检查。

linter 作为 npm run build 的最后一步运行。任何违规都会导致构建失败，进而导致部署失败。没有它，每一个回退 — 超出限制的 meta 描述、有人忘记设置的 SEO 字段、属性被重命名时破坏的架构发出器 — 都会悄无声息地部署。有了它，回退就会在离开开发者的笔记本电脑之前被捕获。

通过将每个相关页面写成一堆引用就绪的段落来获得引用。引用就绪的段落是一个问题形式的H2标题，紧跟着一个直接的一到两句话的答案，接着100-200字的支持细节，以及答案块中零JavaScript渲染内容。AI提取器会提取那个开头句子并引用该页面。

超越段落结构有帮助的因素

• 实体权威——维基百科存在、一致的组织架构标记、真实的sameAs账户、整个开放网络中的品牌提及。
• 网站根目录下的llms.txt——为AI工具策划的网站地图，与服务于传统爬虫的robots.txt和sitemap.xml分开。
• 长篇内容中包含about和mentions的架构标记——声明页面所在的实体图。
• AI爬虫robots.txt允许列表——明确允许GPTBot、PerplexityBot、ClaudeBot、OAI-SearchBot、Google-Extended、Applebot-Extended、CCBot和Anthropic-AI。阻止其中任何一个都是自我造成的引用中断。
• 长篇页面答案丰富部分的Speakable架构属性——对语音和AI提取器的提示，说明这是可引用的段落。

跟踪引用是大多数团队跳过的部分。Otterly、Profound和AthenaHQ按域跟踪AI概览和Perplexity引用份额。我们在每个engagement的基础上添加周引用跟踪，并将其与有机流量一起报告。如果你不测量引用，你就无法判断你的GEO工作是否有效。

AI爬虫只有在你的robots.txt明确允许它们的用户代理且你的托管层不在网络边缘阻止它们时，才能读取你的网站。两个检查都需要通过。默认的Cloudflare设置、默认的Vercel WAF规则和默认的WordPress安全插件经常在没有警告的情况下阻止AI机器人。

我们提供的robots.txt白名单

ChatGPT和OpenAI搜索产品的GPTBot、ChatGPT-User和OAI-SearchBot。Perplexity的PerplexityBot和Perplexity-User。Anthropic的ClaudeBot、Claude-Web和anthropic-ai。用于Bard和AI Overviews的Google-Extended。Applebot-Extended。Common Crawl的CCBot，它为许多开源模型提供数据。Cohere-AI。Meta-ExternalAgent。Bytespider — TikTok的爬虫 — 通常被阻止，因为它很激进且大多数项目不希望TikTok转载他们的内容。

你还需要做的事情

Robots.txt是必要但不充分的。还有三个其他检查。Cloudflare的bot fight mode和bot management — 关掉阻止AI代理的那些，或按IP和用户代理将它们加入白名单。Vercel WAF和Edge Middleware — 确保它们不会在通用正则表达式上匹配AI用户代理。WordPress安全插件如Wordfence — 它们通常默认包含阻止GPTBot和PerplexityBot的规则；显式地加入白名单。通过针对三个代表性URL curl每个用户代理并确认200响应来测试。

我们构建与英国政府数字服务标准和GOV.UK设计系统对齐的技术SEO基础。GDS服务标准是公开领域中最严格记录的数字服务质量原则集合：渐进增强、WCAG 2.2 AA无障碍访问、性能、语义HTML以及JavaScript失效时的优雅降级。在Seahawk的每次技术SEO项目中，我们都遵循这一标准。Government Digital Service Standard and the GOV.UK Design System. The GDS Service Standard is the most rigorously documented set of digital-service quality principles in the public domain: progressive enhancement, accessibility to WCAG 2.2 AA, performance, semantic HTML, and graceful degradation when JavaScript fails. We follow it on every Seahawk technical SEO engagement.

为什么这对SEO特别重要：符合GDS标准的网站能持续通过Core Web Vitals，在传统有机搜索中排名良好，并且对AI Overview引用特别适配——因为GDS要求的结构清晰度正是AI表面提取所需的结构清晰度。该标准虽然早于AI搜索时代出现，但完美映射到AI搜索时代。

对于英国企业、公共部门和受监管行业客户，GDS对齐是真实的采购信号。对于其他所有人，它是一个质量标志，将工作与追求更低标准的代理商区分开来。

三到十周，三个阶段，固定价格。第一阶段是审计——完整爬取、GSC和Ahrefs审查、JSON-LD验证、hreflang集群检查、Core Web Vitals现场数据提取、AI引用基线。第二阶段是修复——我们或你的团队交付修复。第三阶段是防止回归的检查工具和监控层。

审计阶段交付物

• 完整Screaming Frog爬取的CSV文件，加上关于重要问题的书面说明，按影响程度排序。
• Search Console导出——覆盖报告、查询、页面级性能——附带对异常情况的注释。
• 对模板样本的Schema验证器检查，以及关于每个损坏或缺失类型的书面说明。
• 可翻译路由上的 Hreflang 集群完整性报告。
• 从 CrUX 提取的 Core Web Vitals 字段数据，包含最近 25 周按指标分类的图表。
• AI 概览和 Perplexity 引用基准——当前份额、与三个指定竞争对手的差距分析。

修复阶段

固定范围的工作。每个工单都有明确的初始状态和最终状态。我们按优先级发布，如果预算用尽，你可以在任何里程碑停止合作。我们发布的第一批总是那些无法通过构建 linter 的项目——它们的价值路径最短，因为没有 linter 它们会不断回归，一旦 linter 就位，每个修复都会保留下来。

监控阶段

每周在预发布和生产环境上进行自动化 linting，每月 Core Web Vitals 报告，每月 AI 引用追踪，以及一个常驻的 Slack 频道，我会对 Google 或你的团队标记的任何事项进行回应。在关闭时我们会交接仪表板，这样无论你是否续约，你都能保持可见性。