# pSEO 规模架构架构适用于 10K-100K+ 页面的 pSEO 系统。其他 pseo-* 技能中的模式在 1K-10K 时是正确的。超过 10K，内存数据层、全语料库验证和单一部署部署就会崩溃。这项技能提供了大规模所需的架构变更。 ## 规模等级等级 |页数 |数据层|验证 |推出 |网站地图 ---|---|---|---|---|--- 小| < 1K | JSON/文件，内存中 |完全成对 |单一部署 |单文件中等| 1K-10K |文件或DB，两层内存|基于指纹 | 2-4 周批次 |索引 + 子项大| 10K-50K |需要数据库 |增量+采样|逐个类别|索引+分块非常大| 50K-100K+ |数据库+缓存层|仅 Delta + 定期全 | ISR + 站点地图浪潮 |索引+流媒体 **此技能侧重于大型和超大型层。** 如果项目小于 10K 页，则标准 pseo-* 技能就足够了。 ## 1\.数据库支持的数据层当页面超过 10K 时，JSON 文件和内存数组将停止工作。数据层必须移动到具有适当索引的数据库。 ### 为什么内存中断内存中的页面 PageIndex 完整内容（如果已加载） 1K ~1MB ~100-500MB 10K ~10MB ~1-5GB (OOM) 50K ~50MB（边界）~5-25GB（不可能） 100K ~100MB ~10-50GB (不可能) 在 50K+ 时，即使将所有“PageIndex”记录保存在内存中也是临界的。在 100K 时，“getAllSlugs()”返回 100K 对象的数组需要大约 100MB 和几秒的时间来反序列化。您需要基于游标的迭代。 ### 数据库要求 **最小架构：** 创建表页（ id 串行主键， slug TEXT 唯一不为空， canonical_path 文本唯一不为空，标题文本不为空， h1 文本不为空，元描述文本不为空，类别文本不为空，子类别文本，状态文本默认“已发布”， last_modified TIMESTAMPTZ NOT NULL, 发布于 TIMESTAMPTZ， -- 重字段（仅每页加载）介绍文本文本，正文内容文本，常见问题解答 JSONB， related_slugs TEXT[], 特色图像 JSONB， -- 尺度字段 data_sufficiency_score REAL, -- 参见第 2 节 content_hash TEXT, -- 用于增量验证最后验证的时间戳）； -- pSEO 查询所需的索引在页面上创建索引 idx_pages_category（类别）；在页面（状态）上创建索引 idx_pages_status WHERE status = 'published'; 在页面上创建索引 idx_pages_slug(slug); 在页面上创建索引 idx_pages_last_modified(last_modified DESC); 在页面上创建索引 idx_pages_sufficiency(data_sufficiency_score); 在页面上创建索引 idx_pages_category_status（类别，状态）； **类别表：** 创建表类别（ slug 文本主键，名称文本不为空，描述文本， parent_slug 文本参考类别（slug）， page_count INT 默认值 0, 最后修改的 TIMESTAMPTZ ）； **重定向表：** 创建表重定向（源文本主键，目标文本不为空，创建时间为 TIMESTAMPTZ 默认值 NOW() ）；创建索引 idx_redirects_destination ON 重定向（目的地）； ### 大规模数据层 API pseo-data API 合约发生大规模变化： // getAllSlugs() 必须支持 50K+ 时基于游标的迭代异步函数* getAllSlugsCursor(): AsyncGenerator<{ slug: string;类别：字符串 }> { 让光标：字符串|空=空；而（真）{ const 批处理 = 等待 db.query( `从页面中选择 slug、类别 WHERE 状态 = '已发布' ${光标？ `AND slug > $1` : ''} 按 slug LIMIT 1000 排序`, 光标？ [光标] : [] ）； if (batch.length === 0) 中断; 对于（批次的常量行）产量行；光标 = 批次[批次.长度 - 1].slug; } } // getPagesByCategory() 必须使用数据库分页，而不是内存切片异步函数 getPagesByCategory( 类别: 字符串, 选择？：{限制？：数量；偏移量？：数字 } ): Promise { 返回 db.query( `选择 slug、标题、h1、meta_description、canonical_path、类别、last_modified 从页面 WHERE 类别 = $1 AND 状态 = '已发布' 按标题排序限制 $2 抵消 $3`, [类别，选择？.限制？？ 50、选择？.偏移？？ 0] ）； } // getRelatedPages() 需要预先计算的索引或高效的查询异步函数 getRelatedPages(slug: string, limit = 5): Promise { // 选项 A：使用页面记录中的 related_slugs 数组 // 选项B：相同类别+共享标签查询 // 选项 C：预先计算的相关性表（最好在 50K+ 时）返回 db.query( `选择 p.slug、p.title、p.h1、p.meta_description、p.canonical_path、 p.category、p.last_modified 从页 p JOIN 页面源 ON source.slug = $1 WHERE p.category = 源.category 并且 p.slug != $1 AND p.status = '已发布' 按 p.last_modified DESC 排序限$2`, [限制，限制] ）； } ### 连接池在并行页面生成的构建时，您需要连接池：从“pg”导入{池}；常量池=新池（{ max: 10, // 构建期间限制并发连接数空闲超时毫秒：30000，连接超时毫秒：5000， }); **ORM 替代方案：** 如果使用 Prisma 或 Drizzle，请在 ORM 配置中配置连接池限制。对于构建过程来说，默认池大小通常太大。请参阅“references/database-patterns.md”，了解按数据库类型划分的完整模式。 ## 2\.数据充分性门控在 100K 页面中，许多组合会产生单薄的内容。在构建时间之前控制页面生成 - 不要创建无法通过质量检查的页面。 ### 充足性分数根据可用数据计算每个潜在页面的分数：函数computeSufficiencyScore（记录：RawRecord）：数字{ 让分数= 0；常量权重 = { 拥有标题：10， hasDescription: 10, // > 50 个字符 hasBodyContent: 20, // > 200 个字 hasFAQs: 15, // >= 3 问答对 hasUniqueAttributes: 15, // >= 3 个非空结构化属性有图片：5，已分类： 10, hasNumericData: 10, // 统计数据、评级、价格 — LLM 引文信号 hasSourceCitation: 5, // E-E-A-T 的数据来源 }; if (record.title?.length > 10) 分数 += Weights.hasTitle; if (record.description?.length > 50) 分数 += Weights.hasDescription; if (wordCount(record.bodyContent) > 200) 得分 += Weights.hasBodyContent; if (record.faqs?.length >= 3) 分数 += Weights.hasFAQs; // ... 等等返回分数； // 0-100 } ### 门控阈值分数 |行动 ---|--- 80-100 |生成页面——足够的数据 60-79 | 60-79生成带有丰富标志的页面 - 内容管道的标记 40-59 | 40-59 Hold — 在数据丰富之前不生成 0-39 |拒绝——数据不足，不生成 **将分数存储在数据库中**（“data_sufficiency_score”列），以便您可以： * 查询有多少页面已门控与就绪 * 跟踪一段时间内的浓缩进度 * 数据丰富后重新评分 * 构建时的门控：`WHERE data_sufficiency_score >= 60 AND status = 'published'` ### 组合门控对于组合页面（服务×城市，产品×用例），两个维度都必须有足够的数据：函数gateCombination（dimA：RawRecord，dimB：RawRecord）：布尔值{ // 两个维度必须独立清除最小柱 const ScoreA =computeSufficiencyScore(dimA); const ScoreB =computeSufficiencyScore(dimB); // 组合本身必须产生足够的独特内容 // 这不仅仅是“dimA 文本 + dimB 文本”粘贴在一起 const 组合HasUniqueContent = dimA.attributes?.length >= 2 && dimB.attributes?.length >= 2; 返回分数A >= 40 && 分数B >= 40 && 组合HasUniqueContent； } **这是最重要的规模模式。** 500 个服务 × 200 个城市 = 100K 组合，但可能只有 15K 拥有足够的数据来构建高质量的页面。仅生成 15K。 ## 3\.内容丰富管道在 100K 页中，您无法手动编写简介、常见问题解答和说明。您需要一个具有质量控制的自动化富集管道。 ### 管道架构原始数据（DB/CMS/API） │ ▼ 数据充分性评分──→拒绝/保留不充分的记录 │ ▼ 自动丰富──→ 从结构化数据生成介绍、常见问题解答、摘要 │ ▼ 质量抽样──→ 人工审查每批次的随机样本（5-10%） │ ▼ 发布门──→仅记录分数>=60且浓缩完成的记录 │ ▼ 页面生成 ### 丰富来源（非法学硕士）在生成 LLM 之前，请先充实结构化数据： * **多个字段的模板组合**：将 3 个以上的数据字段组合成散文。不是“{城市}的最佳{服务}””，而是使用属性、统计数据和类别上下文的结构化句子。 * **聚合** ：将子数据汇总到父摘要中（类别统计数据、比较表、前 N 列表） * **交叉引用**：通过加入数据源（产品+评论、服务+位置人口统计、列表+类别平均值）来丰富记录 * **从数据模式生成常见问题解答** ：将常见属性变化转化为问答对（“X 在 Y 中花费多少钱？” → 从价格数据中回答） * **比较数据** : 从同一类别的同级记录自动生成比较部分 ### 法学硕士辅助丰富如果结构化富集不足，LLM辅助生成在严格条件下是可以接受的： 1. **永远不要生成整个页面内容** - LLM 填补了数据驱动页面中的空白 2. **始终以真实数据为基础** — LLM 提示包括记录的实际属性、统计数据和上下文 3. **人工审核抽样** — 在发布之前审核每批 LLM 生成内容的 5-10% 4. **存储生成元数据** — 跟踪哪些字段是 LLM 生成的，哪些字段源自数据 5. **丰富后应用质量防护** — 在发布之前对丰富的内容运行 pseo-quality-guard 6. **定期重新生成** — 当底层数据发生变化时，应刷新陈旧的 LLM 内容 **谷歌的立场（2025）：** 如果人工智能生成的内容能够提供真正的价值，那么它就是可以接受的。风险不在于生成方法，而在于输出质量。生成可互换页面的大规模 LLM 生成将引发与模板垃圾邮件相同的处罚。 ## 4\.增量验证对于 100K 页，完整的语料库质量检查需要几个小时。切换到增量验证。 ### 增量验证仅验证自上次验证运行以来发生更改的页面：异步函数 getChangedPages(since: Date): Promise { const 结果 = 等待 db.query( `从页面中选择 slug 哪里最后修改 > $1 或者last_validated IS NULL AND 状态 = '已发布'`, [自] ）；返回结果.map(r => r.slug); } **内容哈希：** 存储每个页面呈现内容的哈希。验证时，仅重新检查哈希值发生更改的页面：从“加密货币”导入{createHash}；函数 contentHash（页面：BaseSEOContent）：字符串 { const content = `${page.title}|${page.h1}|${page.metaDescription}|${page.bodyContent}`; return createHash("sha256").update(content).digest("hex").slice(0, 16); } ### 定期全面扫描每周或在主要版本发布之前运行一次完整的验证。对于 100K 的完整扫描： * **并行化** ：运行 4-8 个验证工作程序，每个验证工作程序处理一个类别分区 * **跨类别相似度示例**：不要比较所有 100K × 100K。将每个页面与其他类别的 50 个随机页面以及同一类别中的所有页面进行比较。 * **将结果流式传输到磁盘** ：将验证结果写入 JSONL 文件，然后聚合。不要将所有结果累积在内存中。 // 按类别并行验证 const 类别 = 等待 getAllCategories(); const 工人 =categories.map(cat => validateCategory(cat.slug) // 每个worker处理一个类别）； const 结果 = 等待 Promise.all(workers); ### 验证预算规模| Delta 验证 |全面验证 ---|---|--- 10K |分钟 | 30-60分钟 5万 |分钟 | 2-4小时 10万 |分钟 | 4-8小时 **优化**：预先计算指纹（MinHash签名）并将其存储在数据库中。然后验证仅比较指纹，而不比较完整内容。 ## 5\.抓取预算管理对于 100K 页面，Google 不会立即抓取所有内容。抓取预算（Google 每天抓取的页面数量）成为一个限制。 ### 站点地图提交策略站点地图索引.xml ├── sitemap-category-a.xml（≤ 50,000 个 URL） ├── 站点地图类别-b.xml ├── 站点地图类别-c.xml └── ... **提交节奏：** * 将站点地图索引提交到 Google Search Console 和 Bing 网站管理员工具 * 添加页面时更新各个类别站点地图 * 不要一次提交所有 100K 个 URL — Google 会限制对 URL 突然激增的新网站的抓取 **程序化站点地图提交：** // 对高优先级页面（职位发布、直播）使用 Google Indexing API // 对于标准页面，依赖站点地图发现 + Search Console // 按类别批量更新站点地图异步函数 updateCategorySitemap(category: string) { const 页面 = 等待 getPagesByCategory(category, { limit: 50000 }); const xml =generateSitemapXml(pages); 等待 writeFile(`public/sitemap-${category}.xml`, xml); } ### 抓取预算优化 * **优先考虑高价值页面** ：在站点地图中设置“优先级”以引导Googlebot（中心为0.8，充分性分数高的页面为0.6，其余为0.4） * **从站点地图中删除低质量页面** ：充足性分数 < 60 的页面不应出现在站点地图中 * **修复抓取浪费**：确保没有软 404、没有重定向链、没有基于参数的重复 — 所有浪费抓取预算 * **服务器响应时间** ：保持 TTFB < 500ms。速度慢的服务器获得的抓取预算较少。 * **监控抓取统计信息** ：每周检查 Google Search Console → 设置 → 抓取统计信息。如果抓取速度下降，请进行调查。 ### 指数化率预期 Google 不保证为所有页面建立索引。现实的期望：网站权限|提交的页面 |可能编入索引（6 个月） ---|---|--- 新网站 | 10万 | 10-30% 成立（DR 30-50）| 10万 | 40-70% 高权威（DR 60+）| 10万 | 70-90% **如果索引率低：** 1. 首先提高索引页面的内容质量 2. 获得更多类别中心的反向链接 3. 减少总页数（修剪薄页）——较小、较高质量的语料库通常比大型、平庸的语料库索引得更好 4. 确保内部链接在 3 次点击内到达每个页面 ## 6\.大规模监控在 100K 页时，您无法手动检查页面。建立自动化监控。 ### 要跟踪的关键指标公制|来源 |警报阈值 ---|---|--- 已编入索引的页面 |谷歌搜索控制台API |每周下降 > 5% 爬行率|谷歌搜索控制台API |掉落 > 20% 抓取错误（5xx、404）|服务器日志、GSC | > 总页数的 1% CWV 回归 | CrUX API 或 RUM |任何模板上的 LCP > 4s 或 CLS > 0.25 构建持续时间| CI/CD 日志 | > 2 倍基线构建内存峰值| CI/CD 日志 | > 80% 的可用内存按状态显示的页数 |数据库|发布的数量与预期存在偏差充分性分数分布|数据库| > 20% 的已发布页面低于阈值 ### 自动监控脚本 // scripts/monitor-pseo.ts — 通过 cron 或 CI 每天运行异步函数监视器() { 常量指标 = { TotalPublished：等待 db.query("从页面中选择 COUNT(*) 个，其中状态 = '已发布'"), avgSufficiency：await db.query（“从状态='已发布'的页面中选择AVG（data_sufficiency_score）”）， belowThreshold:等待 db.query("从 data_sufficiency_score < 60 AND status = '已发布'的页面中选择 COUNT(*) 个"), 最近修改：await db.query("从最后修改的页面中选择 COUNT(*) 个页面，其中 last_modified > NOW() - INTERVAL '7 天'"), neverValidated：等待 db.query("从最后验证为 NULL 且状态 = '已发布'的页面中选择 COUNT(*) 个")， redirectCount：等待 db.query("SELECT COUNT(*) FROM 重定向"), 损坏的重定向：等待 db.query( “SELECT COUNT(*) FROM 重定向 r WHERE NOT EXISTS（SELECT 1 FROM 页 p WHERE p.canonical_path = r.destination）” ), }; // 输出报告或发送到监控服务 console.log(JSON.stringify(metrics, null, 2)); // 危急情况发出警报 if (metrics.brokenRedirects > 0) console.error("ALERT: 发现损坏的重定向"); if (metrics.belowThreshold /metrics.totalPublished > 0.2) { console.error("警报：>20% 的已发布页面低于充足阈值"); } } ### 搜索控制台 API 集成对于 100K 页面，手动 Search Console 检查是不切实际的。使用API： * **索引状态** : 批量查询URL Inspection API以检查新页面的索引状态 * **性能数据**：按页面模板提取点击次数、展示次数、点击率，以识别表现不佳的页面类型 * **覆盖范围问题**：监控“已爬网 - 当前未编入索引”和“已发现 - 当前未编入索引”趋势 ## 7\.边缘和 CDN 架构在 100K 页面时，源服务器无法直接处理所有流量。 ### 缓存策略客户端 → CDN Edge → Origin (Next.js/framework) ↓ 缓存层（Redis/边缘KV） ↓ 数据库 **CDN配置：** * 使用 `s-maxage=86400, stale-while-revalidate=3600` 在边缘缓存所有 pSEO 页面 * 使用 ISR 重新验证来刷新缓存页面（不是完全重建） * 为稳定页面设置较长的 TTL（30 天），为动态数据页面设置较短的 TTL（1 天） **缓存失效：** * 数据更改时 → 通过按需重新验证 API 使特定页面的缓存失效 * 类别更改时 → 使该类别中的所有页面无效 * 模板更改时 → 清除该模板类型所有页面的 CDN **边缘渲染（如果支持）：** * 部署到边缘运行时（Vercel Edge、Cloudflare Workers），全球 TTFB 时间< 50 毫秒 * 并非所有框架都支持边缘渲染 - 检查兼容性 * 边缘函数有内存限制（~128MB），限制了复杂的数据操作 ### 来自边缘的数据库连接边缘功能无法维护持久的数据库连接。选项： * **基于 HTTP 的数据库**（PlanetScale、Neon 无服务器驱动程序、Supabase 边缘功能） * **边缘 KV 存储**（Cloudflare KV、Vercel KV）用于以数据库作为事实来源的索引层数据 * **在构建时预先生成 JSON** 用于索引层数据，数据库仅用于整页内容 ## 8\.特定规模的构建策略对于 100K 页，构建过程本身需要架构。 ### 不要构建所有页面 // 在 100K 时，仅预构建最重要的页面导出异步函数generateStaticParams() { // 预构建：中心页面 + 按流量/优先级排名前 1K 的页面 const hubs = 等待 getAllCategories(); const topPages = 等待 db.query( `从页面中选择 slug、类别 WHERE 状态 = '已发布' 并且 data_sufficiency_score >= 80 按优先级排序 DESC LIMIT 1000` ）；返回[ ...hubs.map(h => ({ 类别: h.slug })), ...topPages.map(p => ({ 类别: p.category, slug: p.slug })), ]; } // ISR 在第一次请求时处理剩余的 99K 页导出常量动态参数 = true; 导出常量重新验证= 86400； // 24 小时 ### 构建时间预算预建页面 |预计构建时间 |内存 ---|---|--- 1K（中心+首页）| 5-15 分钟 | 2-4GB 5K | 15-45 分钟 | 4-6GB 10K | 30-90 分钟 | 6-8GB 100K（不要这样做）| 5-15 小时 | 16GB+ **规则：切勿预构建超过 10K 的页面。** 使用 ISR 处理其他所有事情。 ### 部署后预热部署后，ISR 缓存处于冷状态。每个页面的第一个访问者会触发生成。对于关键页面： // scripts/warm-cache.ts — 部署后运行异步函数 WarmCache() { constpriorityPages = 等待 db.query( `从页面中选择规范路径其中 data_sufficiency_score >= 80 并且状态 = '已发布' 按优先级排序 DESC LIMIT 5000` ）； // 点击每个页面来触发 ISR 生成（速率受限） for (priorityPages 的 const 页) { 等待 fetch(`${baseUrl}${page.canonical_path}`); 等待睡眠（100）； // 10 页/秒 — 不要自己进行 DDoS } } ## 清单 * 数据库是主要数据存储（不是 JSON 文件或内存数组） * slug、category、status、last_modified、sufficiency_score 上存在必需的索引 * 数据充分性评分按页面实施并存储 * 分数 < 60 的页面从生成开始就受到限制 * 组合页面在两个维度上都有门控 * 存在内容丰富管道（结构化数据优先，法学硕士仅通过审核辅助） * 实现增量验证（增量+定期全扫描） * 存储内容哈希值以用于更改检测 * 站点地图通过索引文件按类别划分 * 站点地图不包括低于充足阈值的页面 * 抓取预算通过 Search Console 进行监控 * 监控脚本每天运行并发出警报 * CDN 缓存配置了适当的 TTL * ISR 处理长尾（仅预先构建首页） * 存在用于部署后的缓存预热脚本 * 连接池配置用于构建时查询 * 无功能将 > 10K 整页记录加载到内存中 ## 与其他技能的关系 * **扩展**：pseo-data（用数据库替换内存模式）、pseo-performance（添加 CDN/edge 和特定于规模的构建策略）、pseo-quality-guard（添加增量验证） * **取决于**：在扩展之前所有内容和结构技能都必须到位 * **验证者**：pseo-quality-guard（质量不会改变 - 规模会改变） * **与**合作：伪编排（每个阶段的规模考虑）

伪量表

包含技能