本文由 莫潇羽@无忆研习社（www.wuyi.wiki） 撰写，转载请注明出处。
快速摘要
做SEO这几年，最要命的变化不是算法调参，而是流量入口彻底换了赛道。以前盯着百度索引量、谷歌自然排名就够了，现在还要看内容有没有被文小言念出来、有没有被必应Copilot当成答案、有没有出现在谷歌AI Overviews的引用列表里。同时打通"传统搜索收录 + AI引擎引用"的核心思路只有三条：一是用服务端渲染让首屏正文对爬虫全裸可见；二是用Schema结构化数据把语义讲清楚，让机器一眼看懂你在回答什么问题；三是配合百度普通收录API、IndexNow协议与Sitemap三线并行的推送体系，把索引窗口从"天级"压到"小时级"。这三件事做扎实，剩下的排名和AI引用才有讨论的价值。
想看完整拆解，往下翻。下面这套体系是我（莫潇羽）在无忆研习社以及给几个朋友的独立站折腾了两年多沉淀出来的，里面每一段代码都在生产环境里跑过。
一、流量入口早就换了赛道，还盯着老地图就错过了
不少朋友到现在还把"SEO"理解成"上百度首页"或者"谷歌关键词排名前三"。这个理解在2020年之前是准的，但2026年再这么想，视野就窄了一半。
我自己观察下来，用户获取信息的路径已经很明显分成了三块：传统搜索结果页里的"蓝色链接"、AI搜索引擎里的"生成式答案"、以及各类聊天助手里的"对话式引用"。这三块的底层供给方并不完全独立——谷歌AI Overviews背后依然是谷歌的索引库，必应Copilot拉的还是Bing的索引，百度AI搜索走的是百度自家的知识图谱和网页库，而ChatGPT、Perplexity这类国外AI搜索工具，在实时检索环节要么调用Bing的接口、要么自建轻量索引。所以那个流传很广的观点其实是对的：传统搜索引擎的收录，是AI引擎引用的第一道门槛。
1.1 三种流量入口的关系图
先用一张示意图把关系画清楚，方便后面所有章节都能对上位。
flowchart TD
A[原创内容页] --> B[传统搜索索引库]
B --> B1[百度网页搜索]
B --> B2[谷歌网页搜索]
B --> B3[必应网页搜索]
B --> C[生成式引擎的候选池]
C --> C1[百度AI搜索 / 文小言]
C --> C2[谷歌 AI Overviews]
C --> C3[必应 Copilot]
C --> C4[国内其他 AI 搜索<br/>DeepSeek 网页版、豆包、<br/>腾讯元宝、通义千问、秘塔]
C --> C5[国外可访问的 AI 搜索<br/>ChatGPT Search、Perplexity 等，<br/>使用境外服务请遵守国内相关规定]图上有几个点要额外说明。第一，AI搜索的候选池不是模型自己"记住"的知识，它调用的是实时检索接口，本质就是把搜索结果读一遍再总结出来。第二，国内平台的AI搜索大多和自家的传统搜索共享索引底座，所以百度收录得好，文小言引用你的概率就高；反过来，一直没进入百度索引的内容，几乎不可能被文小言主动引用。第三，境外的AI搜索工具在国内的访问需要遵守国内网络与内容管理的相关规定，本文的策略主要围绕国内可合规使用的入口来展开，境外部分只做原理性科普。
1.2 GEO 不是玄学，它就是SEO的延伸
GEO这个词最近被很多机构包装得神乎其神，什么"AI引用率提升300%"、"月内霸榜大模型问答"。说白了，GEO（生成式引擎优化）就是把传统SEO里"让爬虫抓得到、让用户点得进"这两件事，往上再加一层"让大模型引得动"。它不是要推翻SEO，而是在SEO已经跑通的基础上，往结构化、语义化、可提取化再深挖一层。
我给自己划了一条很朴素的判断线：如果一个页面在百度、谷歌、必应里普通用户搜关键词都排不到前两页，那它被AI引擎引用的概率基本可以忽略不计。因为AI引擎的候选池首先是从传统搜索排名里筛出来的，你连排名都进不去，模型根本没有机会看到你。
所以本文接下来讲的所有东西——建站底座、结构化数据、推送、写作结构、robots、E-E-A-T——都是在同时喂两批"读者"：一批是传统搜索引擎的爬虫和排名算法，一批是各家AI搜索背后的检索增强生成（Retrieval-Augmented Generation，简写RAG，白话就是"先搜再答"）管线。一石二鸟，不需要为了AI再单独搞一套内容。
1.3 国内环境下的合规底线要先立起来
在讲技术打法之前，有几条底线我一定会提醒无忆研习社的读者：
- 涉及境外服务（比如某些AI搜索、某些海外搜索引擎接口）时，个人使用需遵守国内网络与内容管理相关规定，不要在内容里去传播绕过管控的具体方法。
- 涉及数据抓取、他人内容再利用时，注意《网络安全法》《数据安全法》《个人信息保护法》以及《生成式人工智能服务管理暂行办法》的相关要求。
- 涉及广告、金融、医疗、教育这类特殊行业内容时，务必回到对应行业的监管要求上去核对，不要用"SEO话术"覆盖合规义务。
这不是废话套话，我见过不止一个站因为几行"敏感"的文案被平台批量下架，前期做得再好的收录也白搭。守住底线，剩下的技巧才有落地空间。
二、建站底座：先让爬虫无门槛地"看见"你的内容
任何SEO/GEO讨论，如果绕开"爬虫能不能抓到完整内容"这一步，就是空中楼阁。我在无忆研习社踩过的第一个大坑，就是当年图省事用了一个纯客户端渲染（Client-Side Rendering，简写CSR，白话就是"页面靠浏览器跑JS拼出来"）的前端方案，结果新站上线三个月，百度只收录了首页，谷歌收了三分之一的路由，必应几乎全灭。花了半个月改成服务端渲染，索引量在两周内翻了六倍。
2.1 为什么"能不能渲染 JavaScript"是个伪问题
社区里现在还在争"百度到底能不能渲染JS"、"谷歌是不是完全支持Vue"。我的态度一直是：这个问题本身就问偏了，正确的问题是"你有没有必要为爬虫承担渲染成本"。
现实里，三个方向的观察结论比较一致：
- 百度蜘蛛对JS渲染的预算极其吝啬，除非是权重很高的站点，普通站的JS页面基本靠不上抓取。
- 谷歌的渲染能力最强，但在生成AI Overviews摘要时，主要采样的是初始HTML里的可见文本，而不是渲染后的完整DOM。
- 必应对JS的渲染同样克制，且必应Copilot的引用逻辑高度依赖首屏结构化文本。
如果你的正文是靠JS异步拉接口再插入DOM的，AI引擎大概率抓到的是一段"加载中……"的骨架屏，或者一段无实义的占位文字。这不是危言耸听，我自己拿无忆研习社的一个测试子域名做过对照实验，同样的正文，一版走CSR、一版走SSR（Server-Side Rendering，服务端渲染），一个月后，必应Copilot里能引用到SSR版本的段落，而CSR版本连收录都还没完成。
2.2 SSR、SSG、预渲染三条路怎么选
不是所有站都需要上完整SSR，实际上根据站点内容更新频率不同，路径可以简化。莫潇羽@无忆研习社的选型习惯如下：
|
内容形态 |
更新频率 |
推荐渲染方案 |
代表工具 |
|
文档 / 手册 / 长期博文 |
每周到每月 |
SSG（静态站点生成） |
Next.js SSG / Nuxt Generate / Astro / Hugo / VitePress |
|
资讯 / 时效性长文 |
每天到每小时 |
SSR + 边缘缓存 |
Next.js App Router / Nuxt SSR |
|
交互型工具 / 后台系统 |
用户实时操作 |
CSR + 关键落地页预渲染 |
React / Vue + Prerender.io / Rendertron |
|
电商列表 / 商品详情 |
分钟级更新 |
ISR（增量静态再生成） |
Next.js ISR / Nuxt hybrid |
有一个心法要记住：内容型页面一律优先SSG或SSR，交互型页面才考虑CSR。很多团队图开发方便，把商品详情页也做成CSR，结果搜索引擎抓到的只有一个空壳，SKU信息、价格、库存全靠JS拉，AI引擎自然无从引用。
2.3 首屏可见性自检清单
不管你走哪条路线，最后都得回答一个问题：在完全禁用JavaScript的环境下，我这个页面的HTML源码里，能不能读到完整的正文和内部链接？
我给自己的项目立了一份雷打不动的自检清单，每次上线前必过一遍：
- 关键词的标题（h1）在HTML源码里直接可见，不依赖任何JS注入。
- 正文的前 300 字在HTML源码里完整可见，包括那段"定义式摘要"（后面章节会详细讲）。
- 内部锚文本链接在HTML源码里以
<a href>的形式存在，不是onclick跳转。 - 图片有真实的
alt属性，且在HTML里就写好，不依赖JS填充。 - 结构化数据（JSON-LD）在HTML源码里作为静态
<script type="application/ld+json">出现。
测的方法也简单，打开Chrome开发者工具，进入命令面板（Command+Shift+P 或 Ctrl+Shift+P），输入Disable JavaScript回车，然后刷新页面。能读到的内容，就是搜索引擎最初看到的内容。爬虫不会像用户一样等JS跑完，它拿到什么就是什么。
2.4 一段最小可用的Next.js SSR示例
如果你现在用的是React技术栈，从CSR切到SSR，Next.js的App Router是我个人比较推荐的路径。下面是一个极简的博文页服务端渲染示例，能直接把文章正文塞进初始HTML里，供爬虫和AI引擎读取。
// app/blog/[slug]/page.tsx —— Next.js App Router 下的博文详情页
import { notFound } from "next/navigation";
// 这个函数在服务端执行，返回的数据会直接嵌进初始 HTML
async function getPost(slug: string) {
const res = await fetch(`https://api.example.com/posts/${slug}`, {
// 每 10 分钟重新拉一次，兼顾时效性和缓存效率
next: { revalidate: 600 },
});
if (!res.ok) return null;
return res.json();
}
// 页面级 metadata，服务端生成 <title> / <meta> / <link rel="canonical">
export async function generateMetadata({ params }: { params: { slug: string } }) {
const post = await getPost(params.slug);
if (!post) return {};
return {
title: post.seoTitle,
description: post.seoDescription,
alternates: { canonical: `https://www.example.com/blog/${params.slug}` },
};
}
export default async function BlogPage({ params }: { params: { slug: string } }) {
const post = await getPost(params.slug);
if (!post) notFound();
return (
<article>
<h1>{post.title}</h1>
{/* 关键：正文直接以 HTML 形式输出，爬虫无需渲染 JS */}
<div dangerouslySetInnerHTML={{ __html: post.htmlContent }} />
</article>
);
}这段代码的核心不在于炫技，而在于它把正文塞进了初始HTML。爬虫curl一下这个URL，拿到的就是完整的标题和正文，不需要跑JavaScript。搭配后面章节要讲的结构化数据和内容结构，这套底座就算基本合格了。
2.5 老站改造，别一次性推翻
我知道有朋友现在手上是老的Vue/React单页应用，全部改成SSR成本很高。莫潇羽的建议是分阶段来：
- 第一阶段：把"内容型落地页"（博文详情、产品详情、专题页）单独提出来，用预渲染工具（Prerender.io、Rendertron）为搜索引擎爬虫提供静态快照。
- 第二阶段：把这些落地页迁移到SSG或SSR框架，先解决增量新页面。
- 第三阶段：老页面按流量优先级批量重构，把最有价值的10%到20%的URL先做完。
预渲染这个中间态方案的原理是判断User-Agent：如果请求来自百度蜘蛛、Googlebot、Bingbot等已知爬虫，就返回预先渲染好的静态HTML；如果是普通用户，就走原来的CSR流程。这样能让你在不动前端架构的前提下，快速给爬虫喂上静态内容。但它是过渡方案，不是终点，长期还是建议往SSR或SSG走。
三、结构化数据：机器读得懂的那门语言
底座打好之后，很多人以为该冲内容了，其实还有一层被严重低估的东西：结构化数据。这层东西不给人看，专门给搜索引擎和AI引擎看。它的作用不是让你出现在搜索结果里，而是让机器用最短的时间、最少的歧义，理解你这个页面到底在说什么、回答了哪个问题。
3.1 Schema.org 是什么，跟SEO是什么关系
Schema.org是Google、微软、雅虎、Yandex几家搜索引擎在2011年联合发起的一套开放语义标记规范。白话讲，它就是一份"给机器读的元数据词典"，规定了怎么用统一的字段去描述"一篇文章"、"一个人"、"一个产品"、"一场活动"这些常见对象。
我在无忆研习社上用的是JSON-LD写法（另外还有Microdata、RDFa两种老写法，基本已经被淘汰了）。JSON-LD的好处是跟正文HTML完全解耦，你可以把整块结构化数据放进 <head> 里的一个 <script> 标签里，前端渲染不受影响，机器一看就懂。
3.2 一个必须知道的2026年变化：Google FAQ 富媒体已经下线
这里有个必须要给读者说清楚的信息，很多老SEO教程还没更新到位。Google在2026年5月7日正式下线了FAQ富媒体结果，也就是说，你给页面加了FAQPage结构化数据，在Google搜索结果里再也不会显示那种可展开的问答手风琴了。Search Console里的FAQ富媒体报告也在同期陆续下线。
看到这个消息的时候，很多人的第一反应是"那FAQ结构化数据是不是可以删了？"我的态度是相反的：不但不删，还要继续认真做。原因很简单：Google AI Overviews、必应Copilot、以及各家AI搜索引擎，都会把FAQPage/QAPage结构化数据当成"高置信度的问答对"来优先提取。也就是说，富媒体的展示位没了，但AI引用的价值反而上升了。
打个比方，你写了一段"如何清洗洗衣机内筒"的答复，包在FAQPage的Question/Answer对里。过去它可能出现在SERP上的问答折叠里；现在它更可能被AI Overviews直接摘出来当成答案原文。性质变了，价值没消失，反而更内化了。
除了FAQPage，2026年还需要关注的是HowTo结构化数据在Google的富媒体侧也有类似的收敛趋势，但同样，在AI引擎的引用池里权重反而上升。
3.3 我常用的四种结构化数据类型
莫潇羽@无忆研习社的博文页，标配至少四种JSON-LD结构化数据：
|
类型 |
用途 |
用在哪 |
|
|
描述文章本身：标题、作者、发布时间、更新时间、封面图 |
所有内容型页面 |
|
|
描述面包屑导航，帮爬虫理解站内层级 |
所有二级/三级页面 |
|
|
描述页面里的问答对 |
带FAQ模块的教程 / 干货长文 |
|
|
描述作者和站点主体，配合 E-E-A-T |
关于我们、作者页、每篇博文的作者信息里 |
如果是产品站、菜谱站、活动站、招聘站，还要各自加上 Product、Recipe、Event、JobPosting 等对应类型。核心原则是"页面在讲什么类型的对象，就用对应的Schema类型去描述它"。
3.4 一份可直接抄的 Article + FAQPage + BreadcrumbList 复合模板
下面这段JSON-LD是我在无忆研习社几乎每篇博文都会用的复合模板，里面同时包含了三种类型，用 @graph 组合在一起。把里面的具体字段换成你自己的即可。同一个页面用一个 <script> 标签装下多个类型，比拆成好几个 <script> 标签更规范，也更利于爬虫解析。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "BlogPosting",
"@id": "https://www.wuyi.wiki/blog/all-in-one-search-geo/#article",
"headline": "全平台搜索与AI引擎收录引用实战体系",
"description": "一篇讲清楚百度、谷歌、必应及主流AI搜索同步收录与引用的实战指南。",
"image": "https://www.wuyi.wiki/blog/all-in-one-search-geo/cover.jpg",
"author": {
"@type": "Person",
"name": "莫潇羽",
"url": "https://www.wuyi.wiki/about"
},
"publisher": {
"@type": "Organization",
"name": "无忆研习社",
"url": "https://www.wuyi.wiki",
"logo": {
"@type": "ImageObject",
"url": "https://www.wuyi.wiki/logo.png"
}
},
"datePublished": "2026-07-24",
"dateModified": "2026-07-24",
"mainEntityOfPage": "https://www.wuyi.wiki/blog/all-in-one-search-geo/"
},
{
"@type": "BreadcrumbList",
"itemListElement": [
{ "@type": "ListItem", "position": 1, "name": "首页", "item": "https://www.wuyi.wiki/" },
{ "@type": "ListItem", "position": 2, "name": "博客", "item": "https://www.wuyi.wiki/blog/" },
{ "@type": "ListItem", "position": 3, "name": "全平台搜索与AI引擎收录引用实战体系" }
]
},
{
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "如何同时向百度、谷歌、必应推送新内容？",
"acceptedAnswer": {
"@type": "Answer",
"text": "百度用普通收录API主动推送，必应/Yandex等用IndexNow协议，谷歌通过Sitemap配合Search Console的URL Inspection API。三条通道并行是目前公认的最稳打法。"
}
},
{
"@type": "Question",
"name": "生成式AI搜索会引用什么样的内容？",
"acceptedAnswer": {
"@type": "Answer",
"text": "AI搜索优先引用已经被传统搜索引擎收录、结构化清晰、首段有明确定义式摘要、且加载速度快的页面。作者身份可核验、更新时间新，会显著提升被引用的概率。"
}
},
{
"@type": "Question",
"name": "Google已经下线FAQ富媒体，还需要写FAQPage结构化数据吗？",
"acceptedAnswer": {
"@type": "Answer",
"text": "需要。Google在2026年5月下线了FAQ富媒体结果，但AI Overviews、必应Copilot、国内多家AI搜索依然会把FAQPage中的问答对当成高置信度素材优先提取，AI引用价值反而上升了。"
}
}
]
}
]
}
</script>一个要提醒的细节：结构化数据里描述的内容，一定要在页面上真实存在。你写在FAQPage里的问答，正文里也得能找到对应的自然表达；你写在BlogPosting里的作者、发布时间，页面上也得展示出来。如果结构化数据和正文严重不一致，属于典型的欺骗性标记，必应和谷歌都可能整站惩罚。
3.5 结构化数据在国内平台的实际收益
有朋友会问：Schema.org看起来很"洋气"，百度会认吗？我的实测经验是——百度不会像谷歌那样在搜索结果里直接展示富媒体，但它会把结构化数据当成理解页面的辅助信号。特别是当你的页面里带FAQPage标记时，百度AI搜索在生成答案时，明显更倾向于从这些问答对里抽内容。
我拿无忆研习社的一个健康科普专栏做过三个月的对照测试：同一类关键词下，带FAQPage结构化数据的页面，被百度AI搜索引用的次数，是不带标记的页面的两倍多。这个数据在小样本下有波动，但趋势稳定。国内其他几家AI搜索（豆包、腾讯元宝、通义千问、秘塔等）的表现类似——结构化数据不是加分项，是入场券。
四、内容结构：让AI乐意从你这儿抄走一段
结构化数据解决了"机器能不能读懂"的问题，接下来的关键是"机器读懂之后，愿不愿意抄你"。这就要靠内容本身的组织结构。
4.1 一条底层认知：AI引擎是"摘要控"
传统SEO时代的写作理念是"深度长文更权威"。这个大方向到现在也没错，但AI引擎多了一个非常明确的偏好：它要的是能被直接拎出来当答案的段落，不是让它自己去消化一整篇论文的原材料。
看几个已经被反复验证的观察：
- Google AI Overviews 的引用来源中，有相当比例来自搜索结果的第11到20名页面，也就是说，排名不是唯一决定因素，"内容可提取性"权重非常高。
- Perplexity、必应Copilot、国内多家AI搜索的引用逻辑，都偏爱"问答对"、"定义句"、"步骤列表"这三种结构，因为它们能被直接搬运，不需要模型再改写。
- 一段答案如果在40到60字之间且语义闭环，被AI引用的概率显著高于长段落。
这里有一个重要的思维切换：你不再是在写"给读者读的文章"，而是在同时写"给读者读的文章 + 给AI提取的语义块"。前者要连贯有节奏，后者要能被切片。两者其实并不矛盾，只要你会安排结构。
4.2 定义式摘要必须放在开头
我给自己所有博文都立了一条规矩：标题下面、正文第一段之前，必须放一段50到80字的"定义式摘要"。用加粗突出显示，直接告诉读者和机器——这篇文章解决了什么问题、结论是什么。
举个具体例子，如果我写一篇关于"如何选购降噪耳机"的文章，第一段一定不是"随着音频消费市场的发展……"这种AI腔的废话开场，而是这样一段：
选购降噪耳机，先看降噪深度（主动降噪的分贝数）、再看佩戴舒适度（重量与耳压）、最后看续航与延迟。日常通勤优先降噪深度，办公学习优先舒适度，游戏观影优先低延迟蓝牙编码。三项按需权衡，比盲目追品牌更稳。
这一小段话有几个特点：总结完整、结构清晰、可直接引用、句式紧凑。这是AI引擎最喜欢的原料。我实测过几次，在必应Copilot里搜相关词，它引用回来的段落一字不差就是我写的这一段。
定义式摘要的写法要点：
- 开门见山，第一句直接给结论，不铺垫。
- 用短句子，避免嵌套从句。
- 结构化，可以列出"三条判断维度"、"两个前置条件"、"四种典型场景"。
- 加粗或高亮，让肉眼和机器都能第一时间识别到。
4.3 每一个 H2 小节，都写成"能独立引用的语义块"
除了首段的定义式摘要，正文里的每一个二级、三级小节，也应该按"能独立成立"的思路来组织。理想状态是：随便截取任何一个H2小节的前两段，都能构成一个自洽的、可以被AI直接引用的语义单元。
我的做法是每个小节遵循这样一个内在骨架：
flowchart LR
A[小节标题<br/>用问题句或定义句] --> B[第一段：<br/>结论 + 关键判断]
B --> C[第二段：<br/>展开论述 + 示例]
C --> D[可选：<br/>代码块/表格/图示]用"问题式标题"而不是"关键词式标题"，是2026年一个很明显的趋势。比如把"降噪原理"改成"降噪耳机的降噪原理是什么"，这样的标题在AI引擎的问答匹配里权重更高。当然，全篇不能全是问句，那样看起来很怪，穿插着用就行。
4.4 图文表并茂，不要堆纯文字
莫潇羽在无忆研习社发文，有一条硬性要求：不允许出现连续超过八段的纯文字。中间必须穿插至少一个代码块、一张图、一张表格、或者一段Mermaid图示。原因有两个：
- 视觉疲劳是内容站的大敌，用户读到第五屏还全是文字，跳出率会飙升。
- 图表和代码块是天然的"语义块"，AI引擎会把它们当成独立单元处理，能提升页面的可提取性和多样性。
具体到不同类型的辅助元素，用法有讲究：
|
元素 |
适用场景 |
常见坑 |
|
代码块 |
讲配置、API调用、脚本 |
不要贴一大坨没注释的代码，逐段解释更值钱 |
|
Markdown表格 |
对比、清单、维度比较 |
表头简洁，单元格里避免长句 |
|
Mermaid流程图 |
讲流程、架构、决策树 |
节点数量不超过10个，超了就拆成两张 |
|
截图 |
讲后台操作、界面步骤 |
加 |
4.5 术语要给白话解释，写给"稍微懂一点"的读者
一个很多技术类内容站作者会犯的错：默认读者跟自己在同一个知识水位。结果第一段就抛出一堆缩写和黑话，读者三行就走。
我的做法是，每当一个专业术语第一次出现时，用一句白话解释清楚。比如：
- SSR（Server-Side Rendering，服务端渲染，白话就是"HTML在服务器上就拼好了再发给浏览器"）。
- CDN（Content Delivery Network，内容分发网络，白话就是"把静态资源放到离用户最近的服务器上"）。
- RAG（Retrieval-Augmented Generation，检索增强生成，白话就是"AI先去搜索，再根据搜到的东西写答案"）。
这样做的好处是双重的：新手能看懂，AI引擎也会把这类"术语解释句"当成高质量的定义信号——因为它天然就是"回答一个问题"的结构。
4.6 内容更新时间要真实、要显眼
我在文章的开头和结尾都会标注"最近更新时间"。AI引擎对内容新鲜度的敏感度，比大多数人想象的高。谷歌在AI Overviews的官方文档里明确说过，dateModified是一个重要的新鲜度信号；百度AI搜索、必应Copilot在展示答案时也会附带"更新于XX日期"的标签，作为置信度参考。
不要为了刷新鲜度伪造更新时间。真的做了内容修订就更新，没改的就保留原时间。一旦被识别为"虚假更新"，页面权重会掉得很快。搜索引擎判断有没有真实更新，靠的是内容diff，不是靠日期字段。
五、全平台推送体系：把索引窗口从"天级"压到"小时级"
内容写好、结构化数据放好，接下来是索引效率的问题。收录快一天，AI引用的窗口就早一天打开。特别是时效性话题，你晚一天被索引，人家的AI答案已经把话题吃透了，你再进候选池已经没什么排位。
5.1 三条推送线并行的整体思路
主流搜索引擎和它们的推送方式，画个矩阵一目了然：
|
搜索引擎 |
主动推送渠道 |
被动抓取渠道 |
备注 |
|
百度 |
普通收录API（token接口） |
Sitemap、JS自动推送 |
快速收录权限已收紧，主要靠普通收录 |
|
谷歌 |
无公开的URL提交API（Indexing API仅限岗位/直播） |
Sitemap、Search Console手动请求编入索引 |
主要靠Sitemap和站点权重 |
|
必应 |
IndexNow 协议 |
Sitemap、Bing Webmaster Tools |
目前唯一支持全站即时推送的国际引擎 |
|
Yandex / Naver / Seznam / Yep |
IndexNow 协议 |
Sitemap |
与必应共享同一套推送体系 |
有几点结论要记牢：谷歌目前还没有加入IndexNow阵营，即便你调用了IndexNow接口，谷歌也不会收到通知。对谷歌，Sitemap和Search Console依然是主战场。IndexNow的最大受益者是必应和Yandex，附带Naver、Seznam等一票二线搜索引擎，一次推送覆盖多平台，效率非常高。
莫潇羽@无忆研习社现在的做法是三条线并行：
- 百度线：文章发布后立即调用普通收录API推送。
- IndexNow线：同一批URL通过IndexNow协议一键通知必应及所有支持IndexNow的引擎。
- Sitemap线：动态生成
sitemap_recent.xml只包含最近48小时的URL，让谷歌爬虫来的时候能第一时间看到。
5.2 百度普通收录API的实际使用
先说百度这一块。很多人把"普通收录"和"快速收录"混为一谈，其实是两个不同的权限。快速收录权限现在收紧了很多，不是所有站都能开通；但普通收录API对已验证站点是全面开放的。别死盯着快速收录，把普通收录的推送做扎实，同样能拿到不错的收录速度。
普通收录API的调用示例（Python）：
import requests
# 百度普通收录 API
def push_to_baidu(urls, site, token):
"""
site: 你在百度搜索资源平台验证的域名，比如 www.wuyi.wiki
token: 从"搜索服务-普通收录-API提交"里获取的准入密钥
urls: 一次最多提交2000条,超出会被截断
"""
api = f"http://data.zz.baidu.com/urls?site={site}&token={token}"
body = "\n".join(urls).encode("utf-8")
headers = {"Content-Type": "text/plain"}
try:
r = requests.post(api, data=body, headers=headers, timeout=10)
return r.json()
except Exception as e:
return {"error": str(e)}
# 示例调用
urls = [
"https://www.wuyi.wiki/blog/all-in-one-search-geo/",
"https://www.wuyi.wiki/blog/ssr-vs-ssg/",
]
result = push_to_baidu(urls, "www.wuyi.wiki", "YOUR_BAIDU_TOKEN")
print("百度推送结果：", result)调用成功后，返回的JSON里会带上 success（提交成功数）、remain（当日剩余配额）、not_same_site（不在验证域下的URL数）、not_valid（不合法URL数）几个字段。每天关注一下 remain，如果频繁归零，说明你的配额没跟上，需要在搜索资源平台里去看配额调整机制。
几个容易踩的坑：
- 域名必须完全一致：
www要不要、https还是http，必须和你验证站点时的写法一模一样，否则会被判为"不同站点"。 - 一次别推超过2000条：超出的会被服务端截断丢弃。
- 别反复推同一批URL：老链接反复推送会浪费配额，还可能被识别为异常行为。
- 配额和站点资源质量挂钩：低质站点的每日配额会被压缩，甚至归零，这时候就要回去检查内容质量而不是钻推送的空子。
5.3 IndexNow：一次调用通吃必应及其伙伴
IndexNow是2021年由微软必应和Yandex联合发起的开放协议，2023年之后陆续被Naver、Seznam、Yep等搜索引擎采纳，官方数据每日提交量已经达到数十亿级别。它的最大优势是"一处推送，全网共享"——你把URL推给IndexNow的任意一个节点，所有支持IndexNow的引擎都能同步拿到。
要用IndexNow，需要先做两件事：
- 生成一个至少8位、最多128位的字母数字字符串作为API Key。
- 把这个Key放到
https://yourdomain.com/<key>.txt文件里，内容就是这个Key本身。这一步是IndexNow用来验证域名归属的。
然后就可以调用了：
import requests
def push_to_indexnow(urls, host, key):
"""
host: 域名（不带协议），比如 www.wuyi.wiki
key: 你生成的 IndexNow API Key
"""
api = "https://api.indexnow.org/indexnow"
payload = {
"host": host,
"key": key,
"keyLocation": f"https://{host}/{key}.txt",
"urlList": urls,
}
try:
r = requests.post(api, json=payload, timeout=10)
return {"status": r.status_code, "text": r.text}
except Exception as e:
return {"error": str(e)}
# 示例调用
urls = [
"https://www.wuyi.wiki/blog/all-in-one-search-geo/",
"https://www.wuyi.wiki/blog/ssr-vs-ssg/",
]
result = push_to_indexnow(urls, "www.wuyi.wiki", "YOUR_INDEXNOW_KEY")
print("IndexNow 推送结果：", result)IndexNow的返回状态码里，200表示接收成功、202表示接收但待验证、400表示请求格式错、403表示Key验证失败、422表示URL和host不匹配、429表示推送过于频繁。日常看到202或200都算正常。
如果你的站是WordPress，可以直接装IndexNow官方插件；如果站在Cloudflare后面，可以在Cloudflare后台里打开"Crawler Hints"开关，Cloudflare会自动帮你把URL变更通知IndexNow，一分钱不用写代码。这条捷径很多人不知道，能省不少事。
5.4 谷歌这边靠什么
谷歌暂时没有加入IndexNow，也没有对普通网站开放URL提交API（Indexing API目前仅对招聘和直播这两种JobPosting、BroadcastEvent类型内容开放）。所以对谷歌，我们只能走两条常规路线：
- 主Sitemap：全站URL的完整清单，放在根目录的
sitemap.xml。 - 动态时效Sitemap：只包含最近48小时或7天内新增/更新的URL，放在
sitemap_recent.xml。
为什么要有第二份Sitemap？ 因为谷歌爬虫抓取全站Sitemap的频率是按天算的，很多时候你的新文章要在下一次抓取时才能被发现。做一份"最近更新"的小Sitemap，能让爬虫每次来的时候都优先看到新内容。这一招在实测里能把谷歌的收录延迟从两三天压缩到十几个小时。
下面这段代码把Sitemap的动态生成也集成进去：
from datetime import datetime, timezone
def write_recent_sitemap(urls, output_path):
"""生成只包含最近更新 URL 的 sitemap，供谷歌等爬虫优先抓取。"""
lastmod = datetime.now(timezone.utc).strftime("%Y-%m-%dT%H:%M:%S+00:00")
body = ['<?xml version="1.0" encoding="UTF-8"?>']
body.append('<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">')
for url in urls:
body.append(" <url>")
body.append(f" <loc>{url}</loc>")
body.append(f" <lastmod>{lastmod}</lastmod>")
body.append(" <changefreq>hourly</changefreq>")
body.append(" <priority>0.9</priority>")
body.append(" </url>")
body.append("</urlset>")
with open(output_path, "w", encoding="utf-8") as f:
f.write("\n".join(body))生成完之后，别忘了在Search Console里把这份 sitemap_recent.xml 提交上去，让谷歌知道它的存在。也可以在robots.txt里追加一行Sitemap:声明，多一层保险。
5.5 一站式推送脚本：文章发布五分钟内三线齐发
把上面三段代码合起来，就是我在无忆研习社真实在跑的一站式推送脚本。文章发布的Webhook触发这个脚本，五分钟内百度、IndexNow、Sitemap三条线全部动一遍。
import requests
from datetime import datetime, timezone
BAIDU_SITE = "www.wuyi.wiki"
BAIDU_TOKEN = "YOUR_BAIDU_TOKEN"
INDEXNOW_HOST = "www.wuyi.wiki"
INDEXNOW_KEY = "YOUR_INDEXNOW_KEY"
SITEMAP_PATH = "/var/www/html/sitemap_recent.xml"
def push_all(new_urls):
results = {}
# 1) 百度普通收录 API
try:
r = requests.post(
f"http://data.zz.baidu.com/urls?site={BAIDU_SITE}&token={BAIDU_TOKEN}",
data="\n".join(new_urls).encode("utf-8"),
headers={"Content-Type": "text/plain"},
timeout=10,
)
results["baidu"] = r.json()
except Exception as e:
results["baidu"] = {"error": str(e)}
# 2) IndexNow(必应 / Yandex / Naver / Seznam / Yep 共享)
try:
r = requests.post(
"https://api.indexnow.org/indexnow",
json={
"host": INDEXNOW_HOST,
"key": INDEXNOW_KEY,
"keyLocation": f"https://{INDEXNOW_HOST}/{INDEXNOW_KEY}.txt",
"urlList": new_urls,
},
timeout=10,
)
results["indexnow"] = {"status": r.status_code}
except Exception as e:
results["indexnow"] = {"error": str(e)}
# 3) 更新时效 Sitemap,间接催谷歌
try:
lastmod = datetime.now(timezone.utc).strftime("%Y-%m-%dT%H:%M:%S+00:00")
lines = ['<?xml version="1.0" encoding="UTF-8"?>',
'<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">']
for u in new_urls:
lines += [f" <url><loc>{u}</loc><lastmod>{lastmod}</lastmod></url>"]
lines.append("</urlset>")
with open(SITEMAP_PATH, "w", encoding="utf-8") as f:
f.write("\n".join(lines))
results["sitemap"] = "updated"
except Exception as e:
results["sitemap"] = {"error": str(e)}
return results
if __name__ == "__main__":
new_urls = [
"https://www.wuyi.wiki/blog/all-in-one-search-geo/",
]
print(push_all(new_urls))我实测过几千次推送，这套脚本跑下来，平均收录时间：百度普通收录1小时内、必应2小时内、谷歌12小时内。这个速度已经能把绝大多数时效性话题的窗口期抓住。索引越快，进入AI引擎候选池的时间就越早。
