给站点加一块内容（博客、文档、帮助中心）时，URL 有两种选择：子域名（blog.yoursite.com）或子目录（yoursite.com/blog）。看着可以互换，但对 SEO——现在还包括 AI 引用——并非如此。这篇给你决策、背后的数据，以及让子目录方案跑起来的具体 rewrite 配置，哪怕你的博客在另一个仓库或另一个 host 上。
一句话结论
- 默认选子目录（
yoursite.com/blog），凡是想计入同一品牌的内容都该如此。它直接继承你现有的域名权威，不用从零重新积累信任。 - 只在这些情况选子域名（
app.yoursite.com、status.yoursite.com）：那块确实是独立产品、是你无法反代的另一套技术栈，或是第三方工具强制要求独立 host。 - 2026 年的新变化： ChatGPT、Gemini、AI Overviews 都把 host（第一个斜杠前的部分）当成实体。在大模型眼里，子域名像是另一个站点，哪怕 Google 把它们当成同一品牌。子目录内容被引用的次数更多。
- 博客在另一个仓库也没事。 用平台 rewrite（Vercel、Next.js、Cloudflare）把独立托管的博客挂在
yoursite.com/blog。Google 和大模型看到的是子目录，而你的部署仍然各自独立。
数据到底怎么说
Google 官方口径来自搜索布道者 John Mueller：子域名和子目录一视同仁——「总体上我们一样看待。我个人会尽量把东西放在一起，同一个站就放同一个站上。」这话十多年没变过。
但真实排名数据讲的是更实际的故事。有两个发现值得记住：
| 来源 | 发现 |
|---|---|
| Backlinko 对 1180 万条 Google 搜索结果的分析（数据来自 Ahrefs） | 子目录在排名上持续优于子域名，尤其在竞争激烈的关键词上，因为权威传递得更直接。 |
| G2.com 迁移案例（同一批研究中提到） | G2 把内容搬到 learn.g2.com 后，Google 花了好几个月才信任这个新子域名——而根域名是 DR 88、月访问 75 万以上。换成子目录本可以立刻继承这份信任。 |
经典案例（World First、HotPads）重复同样的规律：从子域名搬到子目录后，自然流量大幅上涨。机制很简单——子域名要为那个 host 从头重建链接权重；子目录开局就用上了母域名已经汇聚的权威。
2026 角度：AI 引用
这是大多数老攻略漏掉的部分。Google 的索引或许对子域名和子目录差不多，但生成式引擎不一样。ChatGPT、Gemini、Google 的 AI Overviews 都把 host 当作主要实体信号——也就是第一个 / 前那一串。在大模型看来，blog.yoursite.com 是个跟 yoursite.com 不同的发布者，于是品牌认知、过往引用、主题权威都不会延续过去。
在 2026 年 1 月到 3 月之间的 13 次客户审计里，同一篇文章放在子目录上拿到的 ChatGPT 引用，是放在子域名上同一篇文章的 2 到 5 倍（90 天窗口）。截至 2026 年 6 月，如果你在意被 AI 答案引擎引用——独立发布者越来越在意——子目录的优势比传统蓝链 SEO 还要大。
快速判断
想计入同一 SEO 与 AI 实体的内容，默认子目录（yoursite.com/blog）。只有当那块技术上隔离、托管在你无法套反代的平台上、或者真的是独立产品时，才用子域名（app.yoursite.com、status.yoursite.com、docs.yoursite.com）。「独立部署更方便」不是拆散权威的理由——用 rewrite 修部署，别改 URL 结构。
同仓库的子目录方案
如果博客和主站在同一个仓库，把 /blog 路由到它即可，不用反代。
Astro：
src/pages/blog/index.astro
src/pages/blog/[...slug].astroNext.js（App Router）：
app/blog/page.tsx
app/blog/[slug]/page.tsx博客在不同仓库或不同 host 的子目录方案
很多人卡在这里。博客跑在自己的 host 上（一个 Vercel 项目、一个 Docusaurus 构建、一个 headless CMS），但你想让它在 yoursite.com/blog 提供服务。在主站上配 rewrite。博客自己渲染页面，Google 和大模型看到的是 yoursite.com/blog/...。
主站 Vercel vercel.json：
{
"rewrites": [
{ "source": "/blog", "destination": "https://blog-app.vercel.app/" },
{ "source": "/blog/:path*", "destination": "https://blog-app.vercel.app/:path*" }
]
}Next.js next.config.js（rewrite 到外部源对上游用什么框架都通用）：
module.exports = {
async rewrites() {
return [
{ source: '/blog', destination: 'https://blog.internal.host/' },
{ source: '/blog/:path*', destination: 'https://blog.internal.host/:path*' },
];
},
};Cloudflare Workers：
export default {
async fetch(request) {
const url = new URL(request.url);
if (url.pathname.startsWith('/blog')) {
const upstream = new URL(url.pathname.replace(/^\/blog/, ''), 'https://blog.internal.host');
return fetch(upstream, request);
}
return fetch(request);
},
};给上游博客设 basePath。 这一步最容易翻车。博客 app 必须把页面、资源、链接都生成在 /blog 下，否则反代之后你的 CSS 和 JS 会 404。Next.js 博客里：
// 博客 app 的 next.config.js
module.exports = { basePath: '/blog', assetPrefix: '/blog' };从 Next.js 15 起，在 multi-zone 配置下只设 basePath 就能正确路由静态资源；旧版本还要额外给 /_next/ 路径加一条 rewrite。如果部署后样式坏了，几乎都是 basePath 没设或设错了。
canonical 标签指向子目录
反代的博客里，canonical 必须指子目录 URL，绝不能指上游 host。这点没得商量——canonical 指向 blog-app.vercel.app 等于告诉 Google 去索引上游，整套配置就白做了。
<link rel="canonical" href="https://yoursite.com/blog/foo/" />部署后验证：
curl -sL https://yoursite.com/blog/foo/ | grep -i canonical
# rel="canonical" href="https://yoursite.com/blog/foo/" ✓（不是上游 host）一份 sitemap，一个 Search Console property
子目录方案意味着一个 property 覆盖主域名下的一切，外加一份 sitemap：
<!-- yoursite.com/sitemap.xml -->
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url><loc>https://yoursite.com/</loc></url>
<url><loc>https://yoursite.com/blog/</loc></url>
<url><loc>https://yoursite.com/blog/foo/</loc></url>
<!-- ... -->
</urlset>（相比之下，子域名要单独的 Search Console property、单独的 sitemap、单独的 SSL——更多需要维护、也更容易出错的环节。）
验证反代正确穿透
# 响应头应该像主站，不是上游
curl -sI https://yoursite.com/blog/ | head
# server: Vercel （不是上游 host）
# 不要有泄露上游域名的 Set-Cookie 或 Location 头然后主站和这块内容之间多多互链——header 链接、footer 链接、内容里双向引用。内链是把权威集中到母域名上的关键，也是你能掌控的最便宜的 SEO 杠杆。
上线后检查清单
- 子目录 rewrite 干净穿透（
curl -I显示你的 host，不是上游）。 - 博客页面只引用
yoursite.com的 URL——没有混合 host 的资源或链接。 - 博客内 canonical 指
yoursite.com/blog/...，绝不指上游。 - 一个 property 一份 sitemap，覆盖主域名下的博客 URL。
- 主站与博客之间内链密集。
- Search Console URL Inspection 抽查博客 URL，报告 canonical 是子目录。
- 4–8 周后，曝光和收录数集中到主域 property 上。
容易踩的坑
- 为了基础设施方便选子域名，然后纳闷那块内容怎么排不上去。主站的权威传不过来；在 Google 眼里你开了个新站。
- 因为某框架独立部署更省事就把文档放子域名。 用 rewrite 修部署，别改 URL。
- 两个都开着——
blog.yoursite.com/post-1和yoursite.com/blog/post-1同时存在，这是重复内容问题。选一个，另一个 301。 - canonical 对不上——页面在子目录但 canonical 指子域名（或反过来）。内部不一致，Google 不会买账。
- 上游博客忘了设
basePath，反代后资源 404。切 DNS 之前先设好。
FAQ
- Google 说哪个更好了吗？ 官方说「都行」——John Mueller 多年来反复这么讲。但大规模排名数据（尤其 Backlinko 的 1180 万条结果研究）和迁移案例持续偏向子目录，因为权威会集中而不是被打散。
- 这对现在的 AI 搜索有影响吗？ 有，而且比传统 SEO 更明显。ChatGPT、Gemini、AI Overviews 把 host 当实体，所以子域名读起来像另一个发布者。在 2026 年 1—3 月的审计中，子目录内容拿到的 ChatGPT 引用是同内容子域名版本的 2—5 倍。
- 把博客挂 Medium 或 Substack 的子域名呢？ 那些平台占着它们自己根域名的权威，你几乎继承不到。能自托管就自托管到自己域名的子目录。
- 能子域名做托管、对外暴露成子目录吗？ 能。源站在
blog.yoursite.com，通过上面的 rewrite 在yoursite.com/blog对外提供服务。Google 和大模型看到的是子目录，你的部署照样独立。 - 从子域名搬到子目录会短期掉 SEO 吗？ 会短暂掉。当域名迁移来做：把每个老 URL 301 到对应的子目录路径。通常 4—8 周恢复，往往还净增长。
- 多一跳反代会慢吗？ 几毫秒，实际可忽略。Vercel、Cloudflare、Netlify 都在边缘激进缓存，大多数请求根本到不了上游。
相关阅读
标签: #独立开发 #域名 #SEO #Technical SEO #建站策划