内容站过 1000 篇怎么管：一套脚本优先的实操手册

100 篇的时候，整个站还能装在脑子里；1000 篇就装不下了。站点开始自相矛盾、长出重复意图页、积累失效内链，还藏着一堆你早忘了发过的死簇。过 1000 篇之后的管理，核心是系统：一个生成式内容索引、一个重复扫描器、一个内链检查器，再加上一套由 Search Console 数据驱动的退役货架。这时候写作反而是最轻松的部分，把已有的 1000 篇维持健康才是真正的活。

这套手册就是本站在每语种约 1200 篇规模下实际跑的流程，并附上你必须照着设计的 2026 年 6 月最新 Google API 限额。

一句话总结

• 内容索引用脚本从内容目录生成，绝不手动维护。过期的表格正是重复页溜进来的根源。
• 按主关键词分组扫重复意图；用 301 加 draft: true 合并，绝不删除。
• 内链失效检查至少每周一次；1000 篇的站每天都在改 slug。
• 拉 180 天 Search Console 数据，每月跑一次退役货架。Search Analytics API 单次返回 25000 行，每站每搜索类型每天上限 50000 行，超了就用 startRow 翻页。
• 每周内容时间拿出 30% 到 40% 做维护，并把审计接进构建，确保它真的会跑。

为什么过 1000 篇之后流量会停滞

过了 1000 篇却没有管理纪律的站，常常是一边继续发文、一边流量见顶甚至下滑。原因几乎都在内部，而不是外部算法变化：

• 重复竞争。 两三篇文章打同一个 query、瓜分点击；Google 只挑一篇当 canonical，其余忽略。
• 链接腐烂。 改过的 slug 留下死内链，既浪费爬取预算，又把 PageRank 漏进 404。
• 爬取预算浪费。 单薄的零点击页和标签归档页吃掉 Google 分配给你的爬取额度，新页面被发现得更慢。

过 1000 之后，每个反复要做的任务背后都得有脚本。纯手动的做法大约在 500 篇上下就会悄悄崩在某处。

你已经管不动的信号

• 不查仓库就回答不了”我是不是已经写过 X 这篇”。
• Search Console 的 Indexing 报告里 “Duplicate without user-selected canonical” 数量在上升。
• 还在持续发文，但 indexed 数量却在下降。
• 多篇文章在 Performance 报告里排同一个 query，互相吃流量。
• sitemap 有 1200 条，但 Search Console 只报告 700 篇 indexed。

开始前的准备

• 第一次完整审计留 2 到 3 周；之后每周留几个小时做持续维护。
• 跑任何批量改文脚本前，确认 git status 干净，这样跑坏了一条 git checkout 就能还原。
• 配好 Search Console API 访问（一个在该 property 上验证为 owner 的服务账号 OAuth 凭证），以便程序化拉数据。同一份凭证同时驱动 Search Analytics 和 URL Inspection 两个端点。

实操步骤

1. 内容索引从目录生成，不要手动维护

40 行 Node 脚本就能让索引永远是最新的，并彻底消除”忘了更新表格”这个故障模式：

// scripts/build-content-index.mjs
import { readdirSync, readFileSync, writeFileSync } from 'node:fs';
import { join } from 'node:path';
import matter from 'gray-matter';

const ROOT = 'src/content/articles';
const rows = [];

for (const lang of readdirSync(ROOT)) {
  for (const cat of readdirSync(join(ROOT, lang))) {
    for (const file of readdirSync(join(ROOT, lang, cat))) {
      if (!file.endsWith('.mdx')) continue;
      const { data, content } = matter(readFileSync(join(ROOT, lang, cat, file), 'utf8'));
      rows.push({
        slug: data.urlSlug,
        lang,
        category: data.category,
        title: data.title,
        primaryKeyword: data.primaryKeyword || '',
        publishedAt: data.publishedAt,
        words: content.split(/\s+/).length,
      });
    }
  }
}

writeFileSync('content-index.csv',
  'slug,lang,category,title,primaryKeyword,publishedAt,words\n' +
  rows.map(r => Object.values(r).map(v => `"${v}"`).join(',')).join('\n')
);
console.log(`Wrote ${rows.length} rows`);

需要时随手跑一下；想要一份带日期、日后能做 diff 的快照，就 commit 这个 CSV。

2. 扫描重复意图

按 primaryKeyword 分组。任何关键词对应超过一篇文章，就是一个待决的合并或 canonical 决策：

awk -F, 'NR>1 {print $5}' content-index.csv | sort | uniq -c | sort -rn | head
#  3 "submit sitemap search console"
#  2 "firebase hosting cache"
# ...
# 任何 count > 1 都要决定合并或 canonical

精确字符串匹配能抓住明显的重复。措辞不同的近似重复，见 FAQ 里的 embedding 方法。

3. 重复用 301 合并，绝不删除

在 host 配置里加一次 redirect，然后把被合并的文件改 draft: true，让它停止构建。直接删会丢掉旧 URL 原有的链接权重；301 则把它传给留下来那篇。

# _redirects（Astro / Netlify 风格）
/articles/dup-slug-old  /articles/canonical-slug  301

如果用的是 Firebase Hosting，等价配置写在 firebase.json 的 hosting.redirects 里，"type": 301。

4. 每周审计内链

这个规模的站 slug 改个不停，每次改名都可能让指向它的内链变成孤儿。要赶在 Google 之前发现：

// scripts/check-internal-links.mjs
import { readFileSync, readdirSync } from 'node:fs';
import { join } from 'node:path';

const known = new Set(/* content-index.csv 里所有活 slug */);
const offenders = [];

walk('src/content/articles', (file) => {
  const md = readFileSync(file, 'utf8');
  const matches = md.matchAll(/\]\(\/[a-z]+\/articles\/([a-z0-9-]+)\/\)/g);
  for (const m of matches) {
    if (!known.has(m[1])) offenders.push({ file, broken: m[1] });
  }
});

console.table(offenders.slice(0, 50));

5. sitemap 只保留可索引的 URL

凡是既放进 sitemap、又被你 noindex 的 URL，都会在 Search Console 拿到一个 “Submitted but blocked” 标记，还稀释爬取。用 @astrojs/sitemap 时，filter 回调拿到的是完整页面 URL，返回 true 保留；serialize 可以返回 undefined 来彻底剔除某一条：

// astro.config.mjs
sitemap({
  filter: (page) =>
    !/\/tag\//.test(page) &&     // 剔除标签归档
    !/\/draft\//.test(page),     // 剔除草稿路由
})

6. 每月用 Search Console 数据跑退役货架

拉 180 天按 page 的点击，列出零点击文章。Search Analytics API 单次最多返回 25000 行，并且每站每搜索类型每天上限 50000 行（截至 2026 年 6 月），所以 1000 多篇的站通常一次请求就够，但若哪天要更多，记得用 startRow 翻页：

# 从 Search Analytics API 拉过去 180 天按 page 的点击
curl -X POST "https://www.googleapis.com/webmasters/v3/sites/$SITE/searchAnalytics/query" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  --data '{
    "startDate": "2025-12-06",
    "endDate":   "2026-06-04",
    "dimensions": ["page"],
    "rowLimit": 25000,
    "startRow": 0
  }' \
  | jq -r '.rows[] | select(.clicks==0) | .keys[0]' > retire-shelf.txt

wc -l retire-shelf.txt
# 1k 篇站预期 200-400 条

每条三选一：合到更强的邻居、原地刷新、或改 noindex,follow。把决策记回内容索引，下个月就不用再纠结一遍。

7. 调整发布与维护的比例

1000 篇以下你几乎可以全职发文。过了之后，维护必须在每周固定占一块，否则审计永远跑不起来。一份具体的每周 content-ops 预算：

weekly:
  - audit_duplicates:  1 h    # 跑重复扫描，决定合并
  - audit_internal:    1 h    # 死链检查 + 修
  - retire_review:     2 h    # 拉 GSC 数据，退役 5-10 篇
  - publish_new:       6 h    # ~3 篇
total: 10 h
maintenance_ratio: 40%

8. 把审计接进构建闸门

只在你记得时才跑的脚本，等于不跑。把审计接进 prebuild，让回归直接挂掉 CI，而不是带着问题上线：

node scripts/find-duplicate-keywords.mjs || exit 1
node scripts/check-internal-links.mjs    || exit 1
node scripts/audit-sitemap-vs-index.mjs  || exit 1

加速重新索引：2026 年真正有用的做法

合并或退役页面后，你希望搜索引擎尽快重爬。两个要先摆正预期的事实：

• Google 不支持 IndexNow（截至 2026 年 6 月），它的 Indexing API 只限招聘信息和直播页，不适用于普通内容。对 Google 来说，你的抓手是干净的 sitemap、指向改动页的内链、以及偶尔在 URL Inspection 工具里手动点 “Request indexing”。
• IndexNow 对 Bing、Yandex、Naver、Seznam 有效。 单次最多 ping 10000 个 URL，合并后批量提交绰绰有余。它就是一个带你 key 的 HTTP 请求。

要程序化查索引状态，URL Inspection API 的限额是每个 property 每天 2000 次、每分钟 600 次（截至 2026 年 6 月），所以批量查，别每晚把每个 URL 都轰一遍。

执行检查清单

• 内容索引由脚本生成，不手动维护。
• 重复关键词扫描接进 prebuild。
• 内链检查至少每周跑一次。
• 退役货架每月对照 180 天 Search Console 数据复查。
• 每周内容时间的 30% 到 40% 用在维护，且有记录。

怎么验证它在起作用

• Indexing 报告里 “Duplicate without user-selected canonical” 计数在 4 到 8 周内下降。
• indexed / submitted 比例升到 90% 以上。
• 内链检查器最新一次报告 0 条死链。
• 随着继续发文，文章平均点击不再下滑（说明吃流量的损耗没了）。

容易踩的坑

• 用 100 篇时的工作流去管 1000 篇。 纯手动操作过 500 篇就崩。
• 舍不得退役旧文。 死页拖累整站的爬取效率。
• 加作者但没有编辑流程。 不一致放大的速度比产量还快。
• 一年只做一次大审计。 持续小审每次都赢偶尔大审。
• 直接删而不是 301 合并。 把旧 URL 本来有的链接权重全丢掉。
• noindex 页还留在 sitemap。 Search Console 标 “Submitted but blocked”，白白浪费爬取。

FAQ

• 1000 篇要不要拆成两个站？: 只有主题完全不重合、各自都能独立存活时才拆。拆站同时会把域名权威拆开，通常对两边的伤害大于聚焦带来的好处。
• “死页”占比多少算正常？: 即使是健康的站，月点击 1 以下的文章占 20% 到 40% 也很常见。真正要问的是：它们是主动拖累（重复意图、死链），还是只是安静坐着等刷新的低优先级页。
• 到这个规模需要 CMS 吗？: 不一定。Astro Content Collections 加一个生成式索引，撑到几千篇都很从容。瓶颈是流程，不是工具。
• AI 能帮做审计吗？: 能，主要用在近似重复检测。用 embedding 模型把每篇的标题和首段嵌入，算余弦相似度，把相似度高于约 0.9 的配对标为合并候选；再让模型起草合并理由，但每次真正的合并都要人工复核。
• 做一次完整审计要多久？: 1000 篇第一次大约 2 到 3 周兼职。之后每月维护几个小时。

相关阅读

• 如何做站内内容审计
• 如何避免内容重复
• 如何让 AI 帮你做站点 QA
• 内容站文章数量与质量怎么平衡
• 什么时候更新旧文章

标签: #独立开发 #内容运营 #SEO #建站策划 #工作流

相关文章

独立开发 / 建站指南

内容站季度复盘节奏：真能发现问题

一份 4 小时的季度复盘模板，在流量漂移、话题腐化、排名下滑变严重之前把它们抓出来，附具体的 GSC 查询、AI Overview 检查和决策规则（2026 年 6 月）。

2026/05/23 #独立开发 #内容运营

独立开发 / 建站指南

内容站招人：写手、编辑、运营什么时候招

内容站在 1 人、2 人、3 人、5 人各阶段需要哪些角色，附 2026 年自由写手、编辑、VA 的真实报价，告诉你下一个人招在哪里才解瓶颈，而不是徒增工资。

2026/05/23 #独立开发 #内容运营

独立开发 / 建站指南

内容站快速扩量时怎么避免内容重复：在 Google 之前先发现自己的重复页

站点过几百篇之后，内容重复会悄悄把收录拖死。用脚本化流程在 Google 发现之前先把重复页揪出来——附真实的 embedding 成本和 Search Console 信号。

2026/05/15 #独立开发 #内容运营

独立开发 / 建站指南

内容站文章数量与质量怎么平衡

数量买覆盖，质量买排名。用 Search Console 数据驱动的决策流程，加上构建期强制的质量下限，每月判断该投哪边。

2026/05/15 #独立开发 #内容运营

独立开发 / 建站指南

新内容站的前 30 天：一份能让你被收录的计划

一份具体的新站 30 天计划：在 Search Console 拿到收录、锁死 URL 结构、写满 15-20 篇成簇的文章，并跳过现在不必管的事。

2026/05/15 #独立开发 #内容运营

独立开发 / 建站指南

Pillar 页和 cluster 页：Google 和 AI 搜索都偏爱的站点结构

把 pillar/cluster 关系编码进内容 schema，而不是装在脑子里。含 Zod schema、自动生成的内链块、孤儿审计脚本，以及 2026 年的锚文本配比建议。

2026/05/15 #独立开发 #内容运营