Hexo博客SEO：利用IndexNow与GSC实现自动提交，加速收录

Hexo博客搭到第12期我终于把“收录”这件事认真对待起来。前两周我的日常就是发完新文章打开Google Search Console点URL检查再点“请求编入索引”然后等。等完Google还要去Bing那边手工提交一次一天重复好几遍。后来我研究了一圈改成IndexNow加Google Search Console的自动提交组合总算把“发文章后还要手动通知搜索引擎”这件事从流程里删掉了。这篇就把我的实现过程、踩坑记录和实测数据完整写出来给同样在折腾Hexo收录的朋友一个能直接抄的作业。1. 为什么新文章发布一周还是“未收录”1.1 搜索引擎收录的完整路径抓取、索引、排名先说一个经常被误解的前提。很多博主以为“提交URL 收录”其实不是。搜索引擎处理一个URL的过程可以拆成四步发现、抓取、索引、排序。发现爬虫从哪里知道你有一个新页面来源可能是sitemap、外链、主动提交或者顺着你站内的其他链接爬过来。抓取爬虫根据“发现”的结果实际请求你的URL拿到HTML内容再解析里面的资源。索引抓取完成后搜索引擎分析内容质量、时效性、相关性决定是否放进索引库。这一步是“和书库有关但还没到排名”。排序进了索引库之后用户在搜索时看到的顺序由排名算法决定。大部分人把精力全放在“提交URL”上却忽略了“发现”和“抓取”只是最前面两环。你可以用一座图书馆来类比爬虫是采购员你提交URL相当于告诉他“有一本新书出版了”他会去出版社取书但取回来之后是否上架取决于这本书本身有没有馆藏价值。提交URL只是把“把书送到采购员手里”这件事变快不能替他做上架判断。我一开始的误区就在这里。我以为只要手动去GSC点一遍“请求编入索引”谷歌就会很快收录。实际上这个操作只是把你的URL塞进“待抓取队列”抓完之后它依然会根据你的文章质量、站内结构、外部引用做判断。老牌站点本身权重高抓取预算充足这一步很快对新博客来说抓取慢、待索引更慢才是常态。1.2 小站点的收录困境权重、外链、孤岛页面为什么小博客发一篇新文章经常一周甚至两周都没收录我根据自己几个站的经验总结出四个很现实的原因第一站点权重低抓取预算少。搜索引擎每天要处理海量URL它对每个域名能给的抓取次数是有限的。新域名、少外链的站点分配到的抓取预算很低爬虫不是不想来而是很少来。你主动提交一次URL他可能来但不会天天来看你有没有更新。第二文章成了“孤岛页面”。这是Hexo博客最容易踩的坑。默认主题通常只在首页展示最新文章文章页和文章页之间如果没有“上一篇/下一篇”的导航或者你很少在正文里做内链那一篇文章就只有归档页、标签页这几个入口。爬虫要顺着首页-归档页-文章页这么一层层挖层级深了URL的优先级就会降低。第三sitemap不完善。之前的文章如果没生成sitemap或者生成之后URL带了一堆错误参数、重复后缀搜索引擎在sitemap里看到一堆“看起来不值得抓”的页面整站的可信度都会受影响。这属于基础配置问题跟文章质量无关。第四修改URL太随意。我今天把文章链接从?p123改成/post/name明天又从/post/name换成/2024/name搜索引擎每次都要重新判断等于给自己上了一道减速buff。这四点决定了单纯“提交URL”不一定能等来收录你还需要把站内结构理顺给爬虫留出清晰的发现路径。这个我们放到第5章细说。1.3 IndexNow和GSC到底解决哪一段问题搞清上面几个节点后再看两类工具就清楚多了IndexNow是“主动推送协议”你在发布新页面后把URL直接推给支持该协议的搜索引擎主要是Bing及其生态相当于告诉爬虫“这里有新书快来取”。它解决的是“发现”和“抓取排队”的问题让你的URL进入待抓取队列的优先级大幅提高。Google Search Console不是“推送”工具而是一套站点管理和数据观察平台。你可以通过里面的Sitemap提交、URL检查工具来提醒Google爬虫也可以看到你的页面到底处于“已发现-尚未抓取”还是“已抓取-尚未编入索引”哪种状态。这里有一个特别多人误解的点Google并不支持IndexNow协议。IndexNow是微软Bing、Seznam等主导的开放协议Google官方明确表态过不会接入。所以网上流传的“配一个IndexNow就全网收录”是不对的。你对IndexNow提交受益的是Bing系搜索引擎Google这边还是得靠sitemap和URL检查工具踏实走它自己的路。知道了分工下面的方案就清晰了IndexNow负责Bing系自动推送Google Search Console负责Google生态的验证、sitemap和单条催收两边各管各的。2. IndexNow给Bing系搜索引擎的加急通道2.1 协议原理一个key文件加一条请求IndexNow的机制其实极其简单。它不需要你注册什么平台账号核心就是一个key文件加一条HTTP请求。Key文件机制你给自己域名生成一个唯一标识这个标识是一个GUID比如a1b2c3d4-xxxx-xxxx-xxxx-xxxxxxxxxxxx。然后你要把这个GUID写进一个文本文件文件名叫{这个GUID}.txt放到你网站的根目录确保能通过https://你的域名/{这个GUID}.txt访问到。搜索引擎收到你的提交请求时会去这个地址验证文件内容确认“提交者确实是这个域名的拥有者”。这相当于给搜索引擎查验“门禁卡”。提交方式有两种GET方式适合单条提交https://api.indexnow.org/indexnow?urlhttps://example.com/pagekey你的GUIDPOST方式适合批量提交每次最多10,000个URL。请求体是一个JSON{ host: example.com, key: 你的GUID, keyLocation: https://example.com/你的GUID.txt, urlList: [ https://example.com/page1, https://example.com/page2 ] }POST方式返回200即代表接收成功不需要关心响应体内容。我用的是POST批量提交因为博客每次更新一般会同时发布或者修改多个页面批量提交一次搞定而且日志里只有一条请求排查起来也干净。目前参与IndexNow协议的搜索引擎主要是微软Bing、Seznam、Naver等。不同参与方的覆盖能力可能会有变化具体名单建议以IndexNow官网为准。对你的博客来说最直接的价值是在Bing Webmaster Tools里你的新文章一般会在提交后很短的时间内被抓取。至于Google直接忽略IndexNow不用白费力气。2.2 Hexo接入现成插件还是自己写脚本Hexo生态里已经有现成的hexo-generator-indexnow插件。如果你只是想让Bing快一点收录装插件是最快的方式大致配置是在_config.yml里指定api_key和hostname它会在生成站点时自动产出key文件并在部署后提交URL。但我实际用了几天后还是换成了自己写的Node脚本原因有三个第一插件是个黑盒。你不知道它什么时候提交、提交了哪些URL、用GET还是POST、失败了是否重试。出了状况只能翻插件源码排查成本不低。第二重复提交比较严重。默认逻辑往往是每次部署就把站内URL全量提交一遍。我统计了一下有一次它把历史200多个URL全都重新提交了IndexNow那边大量返回“already known”纯属浪费配额还容易触发平台的频控。第三自定义空间不够。我想在提交前过滤一下“这周改过的老文章”插件没有这种语义化的钩子。所以我的建议是如果你只是临时试一下效果插件完全可以如果你想长期自动化并且想彻底搞清楚“哪个URL在什么时候被提交过”我建议走自写脚本这条路线。下面的脚本就是我自己在用的版本你直接复制改个域名就能跑。2.3 自写Node脚本收集URL、对比历史、批量提交我的脚本放在scripts/submit-indexnow.js整体分四步遍历public目录下所有.html文件转成线上URL。读取本地历史记录.indexnow-history.json过滤出这次真正新增或修改的URL。生成key文件到public根目录。用POST批量提交到api.indexnow.org成功后合并历史记录。核心代码如下// scripts/submit-indexnow.js const fs require(fs); const path require(path); const SITE process.env.SITE_URL || https://yourdomain.com; const KEY process.env.INDEXNOW_KEY || xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx; const API_URL https://api.indexnow.org/indexnow; // 1. 遍历 public 目录收集所有 .html function walk(dir) { let results []; for (const file of fs.readdirSync(dir, { withFileTypes: true })) { const full path.join(dir, file.name); if (file.isDirectory()) { results results.concat(walk(full)); } else if (file.name.endsWith(.html)) { results.push(full); } } return results; } // 2. 把文件路径映射为线上URLindex.html 结尾要处理掉 function pathToUrl(filePath) { const rel path.relative(path.join(__dirname, .., public), filePath); const clean rel.replace(/\\/g, /).replace(/index\.html$/, ); return ${SITE}/${clean}; } // 3. 读取历史记录只提交新增URL const historyFile path.join(__dirname, .., .indexnow-history.json); const history fs.existsSync(historyFile) ? JSON.parse(fs.readFileSync(historyFile, utf8)) : []; const allUrls [...new Set(walk(path.join(__dirname, .., public)).map(pathToUrl))]; const newUrls allUrls.filter((u) !history.includes(u)); if (newUrls.length 0) { console.log(没有新增URL跳过提交); process.exit(0); } // 4. 确保 key 文件在 public 根目录部署后必须能通过 https 访问 fs.writeFileSync(path.join(__dirname, .., public, ${KEY}.txt), KEY); // 5. POST 批量提交 fetch(API_URL, { method: POST, headers: { Content-Type: application/json; charsetutf-8 }, body: JSON.stringify({ host: new URL(SITE).hostname, key: KEY, keyLocation: ${SITE}/${KEY}.txt, urlList: newUrls, }), }) .then((res) res.text()) .then((text) { console.log(IndexNow 返回: ${text}); fs.writeFileSync(historyFile, JSON.stringify([...history, ...newUrls])); }) .catch((err) { console.error(提交失败, err); process.exit(1); });这个脚本有几个地方要特别说明。index.html结尾的处理是很多人会漏掉的细节。Hexo生成的文章页路径可能是public/2024/06/my-post/index.html对应URL应该是https://yourdomain.com/2024/06/my-post/。如果不把末尾的index.html去掉提交的URL就多了个尾巴虽然搜索引擎也能处理但最好保持规范统一后面GSC里的地址也会更干净。[...new Set(...)]这一步是去重。Hexo的静态站里经常会出现tag/xxx/index.html、category/xxx/index.html这种归档页它们和正文文章页混在一起。我的博客归档页也允许被收录所以没有额外过滤但我把URL去重避免同一篇文章出现在两个路径下被重复提交。key文件写入到public根目录这个操作需要放在hexo generate之后再执行。如果脚本在generate之前跑key文件会被hexo clean清掉部署上去之后访问就是404。所以我建议把脚本挂到部署流程的最后一步这个在后面第4章的自动化方案里会细讲。2.4 关键细节与踩坑我在接入IndexNow的过程中踩过几个坑值得单独列出来。坑一key文件404提交报403。刚开始我把key文件放在了项目根目录也就是hexo的source外结果hexo generate之后public里根本没有这个文件。部署完去访问https://你的域名/key.txt直接404。排查方式很简单提交成功后自己先访问一次https://你的域名/{你的key}.txt如果打不开说明搜索引擎也打不开一定会拒绝。解决办法就是像脚本里那样在部署前把它写进public或者更简单把key文件直接放到source目录generate时会自动复制到public。坑二HTTP和HTTPS不一致。我第一次提交时host填的是https://example.com的域名但key文件只部署到了HTTP环境的缓存层接下来Bing抓key文件时访问的是HTTPS地址自然失败。现在主流站点都全站HTTPS这个坑不大但如果你用了CDN或者反向代理要确认HTTPS回源能到你服务器的根目录文件。坑三重复提交历史URL。这个前面已经提过。IndexNow虽然没有明确说“重复提交会封禁”但你在后台看到的全是“URL already known”既影响你判断到底哪些URL是真新增的也让平台对你的站点产生疲劳感。加了历史记录之后这个问题彻底消失。坑四POST批量提交时urlList不要放分页参数或者临时参数。有一次我脚本里写new URL(SITE).hostname时误把整个URL字符串塞进去了导致host变成https://yourdomain.com这种带协议的形式API直接返回400。host只应该是yourdomain.com不带协议、不带路径、不加尾斜杠。3. Google Search Console的正确用法Sitemap与Indexing API的取舍3.1 站点验证HTML文件验证最省事Google Search Console的第一步是验证你对这个站点的所有权。验证方式有很多种HTML文件、HTML标签、Google Analytics、Google Tag Manager、DNS记录、域名服务商等。对Hexo博客来说HTML文件验证是最省事的。流程是在GSC添加资源时选择“域名”类型它会要求你验证域名或者选“网址前缀”类型输入你的完整首页地址。下载它给出的google-site-verification.html文件。把这个文件放到你Hexo项目的source目录下。执行hexo generate hexo deploy让文件进入public根目录并且线上可访问。回到GSC点“验证”。为什么推荐这个方式因为Hexo的source目录里的文件在generate时会原样复制到public根目录不需要额外配置而且验证文件可以长期保留。以后即使你换域名也能在GSC后台看到历史验证记录。DNS验证也可以在域名解析里加一条TXT记录即可。但DNS验证有个问题如果你用的是某些域名服务商DNS解析生效时间可能需要几分钟到几小时还要去域名后台操作一次比放HTML文件繁琐。HTML方式唯一的缺点是它依赖部署流程如果哪次忘了hexo deploy验证自然失败。但只要你已经能用hexo deploy上线博客这个缺点就不存在。3.2 Sitemap提交看着简单容易漏掉两步验证通过之后先别急着发文章把sitemap配好。Hexo端用hexo-generator-sitemap插件即可。安装后在_config.yml里配置url: https://yourdomain.com sitemap: path: sitemap.xmlurl这个字段非常关键。如果你这里填的是http://localhost:4000或者漏了协议生成的sitemap里所有URL都会是错的。我之前有一次临时改本地调试忘了改回来部署后GSC看到的就是一版localhost开头的sitemap状态直接报错。生成后确认一下public/sitemap.xml存在然后到GSC左侧菜单点“站点地图”输入sitemap.xml点提交。这里容易漏掉两步第一步检查生成的URL到底对不对。打开sitemap.xml看一眼确认是https://yourdomain.com/xxx这种完整URL没有多余参数没有小写错乱。很多人提交sitemap后状态显示“成功”但里面的URL全是错的等于白提交。第二步提交之后不要频繁重复提交同一个sitemap。GSC后台的“重新提交”按钮并不是“加急通道”。你提交一次之后Google爬虫会根据自己的节奏来抓取通常几天到两周抓一次。你每天去刷新提交只是给自己制造焦虑并不会让爬虫跑得更快。Sitemap提交后GSC会告诉你“已发现”sitemap但这不表示你的文章已经被抓取或者索引。它只是知道了你的站点地图在哪里后面的抓取和索引依然是爬虫自己决定。3.3 URL检查工具与“请求编入索引”的真实效果GSC里的URL检查工具是排查单个URL状态最直接的地方。你可以输入一篇文章地址它会显示当前状态已编入索引这个URL已经在Google的索引库里可以参与排名。已抓取-尚未编入索引爬虫来过了内容也抓到了但Google暂时没有把它放进索引库。已发现-尚未抓取Google知道了这个URL但还没真正来抓过。抓取失败或页面不可访问代码状态有问题可能是404、500或者robots拦截。当你看到“已抓取-尚未编入索引”或者“已发现-尚未抓取”时可以点“请求编入索引”按钮。这个操作本质上打了一个“催抓”标记让Google尽快把这个URL加入抓取队列。但这里有一个我必须说清楚的经验“请求编入索引”不是“要求收录”而且它有频率限制。对于小站点频繁点击反而可能让Google认为你过于着急把这个请求降级处理。我现在的做法是新文章上线后最多手动请求一次然后不管它。如果两周后看还是有状态的异常我才会再去点一次。别把用户口水的那个按钮当成救命稻草。3.4 Indexing API为什么普通博主别碰既然讲了GSC就不得不提一个看起来很美的东西Google Indexing API。很多人听说它是“Google的官方API可以程序化提交URL”就觉得这才是终极自动化的答案。我在调研时也差点陷进去后来仔细读完文档果断放弃了。Indexing API的定位是给“时间高度敏感的页面”用的比如新闻文章、事件页面、招聘信息等。它需要你具备几个条件一个Google Cloud项目开启Indexing API。创建服务账号下载JSON私钥。生成OAuth2的access token。在页面上标记对应的Schema.org结构化数据比如NewsArticle或JobPosting。调用https://indexing.googleapis.com/v3/urlNotifications:publish接口提交URL。我实际操作了一遍发现即使配置全部成功普通博客文章没有的NewsArticle结构化数据标记接口会直接报错或者根本不加速。而且Google官方文档说得很明白这个API不适用于普通内容站点也不适合每天全量提交所有URL。所以我的建议是普通博客博主别在这上面花时间。有那功夫不如把sitemap配好把文章内容写扎实。Indexing API是给新闻编辑部用的工具不是给个人博客用的。4. 把提交动作塞进部署流程4.1 方案A本地deploy后自动提交适合本地写作如果你和我一样习惯在本地写完文章再hexo deploy发布最简单的方式是把IndexNow提交脚本挂到npm scripts里。在Hexo项目的package.json中把deploy脚本改成{ scripts: { deploy: hexo clean hexo generate hexo deploy node scripts/submit-indexnow.js } }之后你只需要执行npm run deploy它就会依次完成清理旧文件、生成最新静态站、部署到远端、提交新增URL到IndexNow。整个过程一条命令不用记四个命令。这个方案的好处是简单粗暴适合绝大多数Hexo博主。缺点是它依赖你本地执行命令如果你换了电脑、忘了跑这条命令或者博客已经改成“推送代码到仓库由CI自动部署”那它就不会触发。另外脚本里的.indexnow-history.json是保存在本地的如果你在另一台机器上跑历史记录就是空的第一次会全量提交一次之后才会正常只提交新增。对我来说这个方案还解决了一个问题hexo clean会把public目录删掉所以key文件如果直接放在source目录里就会跟着一起被重新生成如果我放在别的目录clean就会把它清掉。放在脚本里写public根目录既保证了clean后能被脚本重新创建也能确保在部署前存在。这个顺序刚好接上。4.2 方案BGitHub Actions全自动流水线适合远程部署如果你的博客已经用GitHub Actions自动部署到GitHub Pages那可以再往后走一步把提交动作塞进同一个流水线。整个流程变成你本地git push- Actions跑起来 - 生成站点 - 部署 - 提交URL到IndexNow。下面是我用的workflow核心部分文件放在.github/workflows/deploy.ymlname: Deploy and Submit on: push: branches: - main permissions: contents: write jobs: build-deploy: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 with: fetch-depth: 0 - name: Setup Node uses: actions/setup-nodev4 with: node-version: 18 - name: Install dependencies run: npm ci - name: Generate site run: npx hexo generate - name: Deploy to GitHub Pages run: | git config --global user.name GitHub Actions git config --global user.email actionsgithub.com npx hexo deploy - name: Submit URLs to IndexNow env: INDEXNOW_KEY: ${{ secrets.INDEXNOW_KEY }} SITE_URL: https://yourdomain.com run: node scripts/submit-indexnow.js这段workflow有几个关键点fetch-depth: 0是拉取完整提交历史避免部分提交场景下部署失败。Node版本我用18是因为我的提交脚本用到了原生fetchNode 18以后才稳定支持。当然你换成axios或者node-fetch也行但用18能少装一个依赖。INDEXNOW_KEY通过secrets.INDEXNOW_KEY传入。你需要在GitHub仓库的 Settings - Secrets and variables - Actions 里添加这个secret不要把它写死在代码里。密钥一旦泄露别人就能用你的key提交任意URL到IndexNow虽说影响范围可控但没必要给自己找麻烦。git config这一步是给hexo-deployer-git用的它需要知道提交者的身份。如果你用的部署方式不同比如直接用actions/gh-pages这里可以省略。方案B的好处是真正做到全自动文章本地写好、push上去剩下的发布和通知都是机器干的。我现在的主力方案就是这个。唯一要注意的是GitHub Actions的时区默认UTC如果你希望脚本里打印的时间是按北京时间显示需要在workflow里加TZ: Asia/Shanghai环境变量。4.3 控制提交频率只提交新增URL无论是方案A还是方案B脚本里维护历史记录.indexnow-history.json都是必要的。这个文件每次都只记录成功提交的URL字符串下次跑的时候过滤掉旧URL只提交新增的。有人会问如果我只是修改了老文章没有新增URL但希望搜索引擎尽快抓取最新版怎么办我的回答是暂不建议为这个场景折腾。大部分博客文章发布后内容不会频繁变动搜索引擎对已索引页面本来就会定期重新抓取你改了内容它早晚会看到。你为了“让搜索引擎立刻知道老文章更新了”去提交一遍反而破坏了历史记录机制的简洁性。如果你真的在意可以在历史记录里多保存一个lastmod时间脚本对比文件修改时间超过某个阈值就重新提交。但我觉得投入产出比不高所以我的脚本只处理“新增URL”。控制频率的另一层意思是不要每天把博客全量提交一遍。IndexNow是给“新增/更新通知”用的不是给“全站提交”用的。你全站提一次等于告诉搜索引擎“所有页面都变了”但搜索引擎很聪明它会去对比sitemap发现大部分页面都没变化就会慢慢降低对你通知的信任度。这个信任度如果掉了后面真新增URL时反而得不到快速响应。5. 实测与排错两周的数据和三个高频问题5.1 我的实测数据跑了一周多自动化之后我先说结论性数据再给分析。我选了一周内发布的3篇文章做样本统一在部署后立即提交IndexNow。Bing Webmaster Tools后台的状态是文章A提交后约1小时显示“已发现”当天晚些时候变成“已抓取”。文章B提交后约3小时才显示“已发现”第二天才抓取。文章C提交后10分钟左右就在Bing搜索里用site:查到了速度出乎意料。GSC那边则是另一个节奏sitemap提交后前3天内Google爬虫开始抓取其中部分页面但索引速度明显慢于Bing有1篇文章一直到第10天才“已编入索引”。另外1篇到目前为止还是“已发现-尚未抓取”也就是还在排队。这些数据只是我个人的环境搜索引擎的算法和抓取频率每天都在变不能当作标准答案。但有两个趋势是稳定的第一IndexNow对Bing系确实有效提交后通常以“小时”为单位响应。相比之前完全依赖爬虫自然发现这已经是质的提升。第二Google不会因为你在IndexNow提交了URL就动起来。它的抓取节奏属于自己的一套逻辑sitemap和URL检查工具能帮的忙有限最终还是要靠内容质量和外链。所以我的结论是排除法做策略Bing靠IndexNowGoogle靠sitemap加内容别想着一键通吃。5.2 高频问题排查key文件404、重复提交、状态卡住如果你照着上面的方案配置完大概率会遇到下面几个问题之一。按我的排查经验把清单放在这里方便你直接对照。问题一IndexNow返回403或者400。先自查四件事key文件能不能通过https://你的域名/{key}.txt访问到返回内容是不是GUID本身。用浏览器直接打开最快。host字段有没有写成https://开头正确的是你的域名不带协议。urlList里的URL是不是都以https://开头并且和host是同一个域名。你的GUID是不是标准UUID格式别自己随手编一串数字。问题二提交显示成功但Bing Webmaster Tools里看不到。这个通常是时间问题至少等几个小时再看别刚提交就回来看。如果超过24小时还“未发现”检查你的robots.txt是不是把所有路径都disallow了或者你的站点根目录被某层CDN缓存了。问题三GSC状态一直停在“已发现-尚未抓取”。这种状态说明Google爬虫知道你的URL但迟迟不来抓。原因可能是站点权重低、sitemap没更新、或者这篇文章没有内链入口。我的处理方式是先确认文章页有从首页或者归档页的链接能到达然后手动请求一次编入索引之后就不管了。反复点击不会带来实质帮助。问题四脚本报 “Cannot find module node:fs/promises” 这类错误。这多半是Node版本太老。我的脚本用了Node 18的fetch和比较新的API建议升级Node到18以上或者在GitHub Actions里明确指定node-version: 18。5.3 提交之外内链和更新频率才是长期收录的发动机最后想聊一点容易被自动化掩盖掉的东西。自动提交URL确实方便但它只是在“通知”这个环节帮你省了力气。搜索引擎对一个站点长期的信任仍然来自内容质量、站内结构和更新规律。我的博客现在每篇文章底部都会做“相关文章”区域手动放两三个内链指向之前写过的相关话题。这个习惯比任何提交工具都重要因为内链让新文章不再孤立爬虫从老文章就能顺着走到新页面发现成本大幅下降。更新频率方面我不建议为了“保持活跃”而硬凑更新。搜索引擎能识别出垃圾更新和真实更新一个稳定、有内容逻辑的更新节奏比如每周一两篇比一个爆发式发十篇然后又停更一个月要好得多。还有一点不要轻易改文章URL。一旦URL变了之前积累的索引和权重全部作废sitemap里也要同步更新。我一般是在文章内容定稿、标题确定之后才发布尽量避免“先拿个URL上线之后又改”的情况。我现在每天的工作流程已经很简单了写完文章本地npm run deploy或者直接push到GitHub脚本自己会跑IndexNow提交GSC那边由sitemap兜底。偶尔打开后台看一遍日志看到“提交成功”就会很安心。搜索引擎本质上是一个只看不说的读者你能做的就是用最快、最直接的方式告诉它更新了剩下的交给时间和内容去说服它。