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

技术SEO是决定搜索引擎和AI助手能否爬取、渲染和信任你的页面的那一层工作，这发生在内容和反向链接产生任何影响之前。它涵盖HTTP行为、HTML语义、结构化数据、hreflang、规范化、Core Web Vitals和JavaScript渲染。做错了，你其余的投资就是废物。

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

我对2026年客户的工作定义：技术SEO是Lighthouse运行、Search Console爬取报告、AI概览引用检查和架构验证器注意事项涵盖的所有内容，跨越每个语言、每个模板、每个渲染路径。如果这四个信号中的任何一个在某个代表性URL上失败，工作就从那里开始。

在无头或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架构为前端需要的SEO字段建模（规范覆盖、重定向映射、hreflang组、架构扩展JSON），并确保按需重新验证在内容更改时触发。ISR缓存中毒是隐形杀手，页面在发布后数小时内被提供过期内容，因为revalidatePath从未被连接。

什么真正最先出问题

在我们运行的约200次无头审计中，单一最常见的生产破坏问题是规范冲突，前端发出一个规范URL而CMS元数据或网站地图发出另一个。Google选择一个，几乎总是不是你想要的那个，错误的URL最终在索引中。我们用一个构建时linter捕获这个，该linter对一个页面样本比较从模板发出的规范与存储在CMS中的规范，并在不匹配时构建失败。

WordPress给了你最多的插件火力和最多的方式去伤害自己。经典WordPress网站上的技术SEO剧本大多是关于减法，移除重复规范、消除Yoast和RankMath之间的架构冲突以及某个没人记得安装的第三方插件、驯服发布2 MB CSS的页面构建器，以及清除已经增长了八年的重定向链。

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

在无头一侧，工作从减法转向构造。没有Yoast，所以元上限必须被构建。没有插件架构，所以JSON-LD必须被模板化。没有内置网站地图，所以它必须被生成和流化。我们为无头项目添加的SEO代码量通常是WordPress网站已免费提供的三到五倍，但那些代码是被拥有的、版本控制的、可测试的，并且不会在下次插件更新时破坏。

GEO 和 AEO 是两种不同方式来称呼 AI 特性抢占搜索流量的现象。AEO（Answer Engine Optimisation，答案引擎优化）是较早的术语，涵盖 Google 的精选摘要、人们还在搜索和知识面板等功能，这些功能从你的页面提取段落并将其作为答案展示。GEO（Generative Engine Optimisation，生成引擎优化）是较新的术语，针对 AI 概览、ChatGPT 搜索、Perplexity 和 Bing Copilot 进行优化，这些助手生成一个段落并引用你的页面作为来源。

这在结构上意味着什么

这两个展示位都想要同一样东西：能被引用的段落。在所有这些位置上获胜的结构规则是相同的。使用问题作为你的 H2，而不是主题标签。在标题后的前一句或两句中放入答案。保持答案在 250 字以下。确保答案是在服务器端呈现的，而不是在页面加载后进行水合的 JavaScript 组件内。AI 爬虫和 Google 提取器基本上不运行 JavaScript，如果你的答案需要 JS 才能出现，你就是不可见的。

GEO 与 AEO 的差异

有三件事对 GEO 特别重要。实体权威性，Google 和 LLM 建立一个图表来确定谁被允许谈论什么，未链接的品牌提及会提供信息。带有 about 和 mentions 数组的架构，它们使你的页面能被解析为实体图的一部分，而不是一堵文字墙。以及 llms.txt，一个新兴标准文件位于 /llms.txt，它为 AI 工具提供你网站的精选地图，就像 robots.txt 和 sitemap.xml 帮助搜索爬虫一样。我们在构建的每个网站上部署 llms.txt，并在每次重大页面发布时更新它。

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

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

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

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

能够规模化的模式

在每个可翻译行上存储 content_group_id（或等效项）。页面的每个区域变体都共享一个 ID。hreflang 发射器、站点地图发射器和规范发射器都从该 ID 派生其集群。永远不要仅从 URL 模式匹配计算 hreflang，它在边界情况下会崩溃（一个没有印地语翻译的西班牙页面会在你的代码假设"如果页面 X 存在于区域 A，它就存在于区域 B"时破坏集群）。

什么在实践中杀死了 hreflang

我们反复看到三个模式。区域正则表达式排序，将"zh"放在你的区域检测正则表达式中"zh-Hant"之前，这会捕获错误的区域并写入损坏的 hreflang。忘记 x-default，每个集群都需要一个 x-default 回退，通常指向英文版本。集群 ID 漂移，翻译获得新 ID 而不是继承源 ID，无声地将单个集群分割成两个不相关的集群，其中都没有完整的互惠集。

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

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

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

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

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

我用 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 倍视网膜、在头部添加预加载标签并设置 fetchpriority="high" 来解决。一个 1 MB 的主图像变成 30 KB 的 WebP 是大多数项目中影响最大的单一变化。CLS 来自没有显式尺寸的图像和广告、每个图像上的显式宽度和高度属性、固定高度的广告位以及任何客户端小部件的预留空间。INP 来自交互上的重 JavaScript，通常是第三方标签管理器或过于积极的分析库。修复是防抖、惰性加载或替换为更轻的等效项。

大多数项目遗漏的地方

两个模式。首先，Carousel 组件或 JavaScript 驱动的布局内的 LCP 图像，图像仅在 JS 运行后呈现，你的 LCP 是轮播的加载骨架，而不是照片。其次，不使用 font-display: swap 和不使用预加载加载的网络字体，文本在字体下载时不可见 200-400 毫秒，你的 LCP 被推过 2.5 秒的阈值，即使图像是快速的。两者都通过 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 和明确尺寸检查。

链接器作为 npm run build 的最后一步运行。任何违规都会导致构建失败，这会导致部署失败。没有它，每个回归、增长过限的元描述、某人忘记设置的 SEO 字段、一个属性被重命名时中断的 schema 发射器，无声地发布。有了它，回归在离开开发者的笔记本电脑之前就被捕获了。

通过将每个相关页面写成一堆引用就绪的段落来获得引用。引用就绪的段落是一个问题形式的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。Claude 的 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 机器人保护模式和机器人管理，关闭阻止 AI 代理的规则，或按 IP 和 user-agent 将其列入白名单。Vercel WAF 和 Edge Middleware，确保它们不会在通用正则表达式上匹配 AI user-agent。WordPress 安全插件如 Wordfence，它们通常默认包含阻止 GPTBot 和 PerplexityBot 的规则；明确列入白名单。通过对三个代表性 URL 使用 curl 测试每个 user-agent 并确认返回 200 响应来验证。

我们构建与英国政府数字服务标准和GOV.UK设计系统对齐的技术SEO基础。GDS服务标准是公开领域中最严格记录的数字服务质量原则集合：渐进增强、WCAG 2.2 AA无障碍访问、性能、语义HTML以及JavaScript失效时的优雅降级。在Seahawk的每次技术SEO项目中，我们都遵循这一标准。

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

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

三到十周，三个阶段，固定价格。第一阶段是审计，完整爬取、GSC 和 Ahrefs 审查、JSON-LD 验证、hreflang 集群检查、Core Web Vitals 字段数据提取、AI 引用基线。第二阶段是修复，我们提供修复方案，由你的团队或我们负责执行。第三阶段是 linter 和监控层，防止回归。

审计阶段交付物

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

修复阶段

固定范围的工作。每个工单都有明确的前置状态和后置状态。我们按优先级顺序交付，如果预算用完了，你可以在任何里程碑停止合作。我们交付的第一批总是那些未通过构建代码检查的项目，它们的价值路径最短，因为这些问题会不断反复出现，而一旦代码检查工具就位，每项修复都能保持下去。

监控阶段

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