GSC 提示「网页会自动重定向」未编入索引?根域名与 www 规范化全复盘
一、现象:GSC 后台突然报警「网页会自动重定向」
在日常维护站长工具时,Google Search Console(GSC)的「编制索引 -> 网页」报告中突然提示:4 个网页未编入索引,原因为「网页会自动重定向」。
图:GSC 网页索引编制总览面板,显示 4 个网页因重定向未被编入索引
图:GSC 未编入索引原因明细列表,明确列出「网页会自动重定向」
点击进入「网页会自动重定向」详情页,可以查看到受影响网页趋势与具体的示例网址:
图:GSC 网页会自动重定向详情页及受影响趋势
图:受影响的 4 个示例 URL 列表明细
受影响的具体 URL 为:
https://eryuemu.com/blog/knowledge-base-and-blog-setup/https://eryuemu.com/blog/hbu-wiki-dev-env-setup/https://eryuemu.com/blog/https://eryuemu.com/about/
很多新手站长一看到“未编入索引”或标红报警,第一反应往往是“网站出 Bug 挂了”或者“被 Google 降权了”。其实,这背后隐藏着现代 Web 规范化(Canonicalization)、DNS 架构与搜索引擎索引机制的核心逻辑。
二、破案:为什么会出现「网页会自动重定向」?
2.1 网址前缀资源(URL-prefix)的视角局限
- 当初在 GSC 中添加的是
https://eryuemu.com/(不带www的 Apex 根域名网址前缀资源)。 - 网站托管在 Vercel 上,此前将主站(Production)设为了
www.eryuemu.com,服务器对所有非 www 请求(eryuemu.com)执行了 308 Permanent Redirect 永久重定向。 - 当 Googlebot 访问
https://eryuemu.com/blog/...时,服务器返回了 308 跳转到https://www.eryuemu.com/blog/...。 - 结论:对于
https://eryuemu.com/这个资源视角而言,这 4 个 URL 请求后确实发生了重定向。Google 正确识别并把索引权重传递给了带www的页面,因此不在当前不带 www 的资源下重复建立索引。这属于符合预期的正常现象,绝非网站故障。
2.2 隐藏的代码诱因:robots.txt 与内链泄露
为什么 Googlebot 会优先去抓取不带 www 的链接?
- 排查博客代码发现,根目录下的
public/robots.txt遗留了一行旧配置:Sitemap: https://eryuemu.com/sitemap-index.xml - 爬虫在读取 robots.txt 时,被引导去了不带
www的地址,进而触发了整条重定向链。 - 此外,站内部分友链名片、头像硬编码了
https://eryuemu.com/...,也为爬虫提供了非规范 URL 的线索。
2.3 破案细节:为什么 7 月 20 日就绑定了域名,GSC 却显示这些日期?
很多站长在看 GSC 报告时容易把 「上次抓取日期」(Last Crawl Date) 误认为是“首次收录日期”。
[!NOTE] 概念辨析:「上次抓取日期」 指的是 Google 爬虫最近一次来访巡检、刷新快照的时间,而不是首次发现或收录网站的日期。 本站在 7 月 20 日 首次完成域名绑定并上线后,Googlebot 在 7 月下旬就已经进站并收录了首页(例如那篇 7 月 27 日被抓取的文章就是铁证)。
破案的关键,就藏在两张 GSC 详情图中的 「上次抓取日期」全时间线 中:
图:GSC 中已编入索引的 3 个页面(上次抓取日期分别为 8月10日、8月11日、8月15日)
1. 全量 7 个页面抓取时间线对比表
| 网址(URL) | 上次抓取日期(最近回访) | Google 判定状态 | 抓取路径与历史成因 |
|---|---|---|---|
https://eryuemu.com/blog/knowledge-base-and-blog-setup/ |
7 月 27 日 | 网页会自动重定向 | 7/20 绑域名时开启了跳 www,爬虫撞上 308 跳转 |
https://eryuemu.com/blog/ |
8 月 05 日 | 网页会自动重定向 | 爬虫抓取列表页,撞上 7/20 配好的 308 跳转 |
https://eryuemu.com/about/ |
8 月 06 日 | 网页会自动重定向 | 爬虫抓取关于页,撞上 7/20 配好的 308 跳转 |
https://eryuemu.com/blog/hbu-wiki-dev-env-setup/ |
8 月 08 日 | 网页会自动重定向 | 爬虫抓取文章页,撞上 7/20 配好的 308 跳转 |
https://eryuemu.com/thoughts/2026-08-05-ai-and-curiosity/ |
8 月 10 日 | ✅ 成功编入索引 | 顺着首页内链抓取,无跳转阻碍 |
https://eryuemu.com/(博客首页) |
8 月 11 日 | ✅ 成功编入索引 | 7 月早已收录,8/11 为最近一次例行巡检刷新 |
https://eryuemu.com/thoughts/(心迹列表) |
8 月 15 日 | ✅ 成功编入索引 | 首页重点内链,最近一次回访直接收录 |
2. 两条截然不同的爬虫入站路径剖析
-
路径 A(成功收录通道):GitHub 外链引导与首页内链
- 7 月 20 日绑定域名上线后,你在 GitHub Profile、开源仓库 README 等公开渠道留下了个人博客首页
https://eryuemu.com。 - Googlebot 的外链探测爬虫顺藤摸瓜访问了 首页,并将其纳入权威索引库。
- 8 月 10 日~11 日爬虫例行回访时,爬取了首页重点展示的「心迹」模块及当时最新的动态(8 月 5 日的
2026-08-05-ai-and-curiosity)。 - 这几个页面没有触发复杂的子域跳转,页面结构与原创内容完整,Googlebot 持续保持其在
eryuemu.com索引库中的正常收录状态。
- 7 月 20 日绑定域名上线后,你在 GitHub Profile、开源仓库 README 等公开渠道留下了个人博客首页
-
路径 B(重定向记录通道):7 月 20 日绑定域名时默认开启的 308 跳转
- 7 月 20 日在 Vercel 绑定域名时,按照 Vercel 官方推荐的默认选项勾选了「Redirect apex domains to www」(根域名自动重定向到 www)。
- 因此从 7 月 20 日上线起,Vercel 服务器一直执行着“访问
eryuemu.com自动 308 永久重定向到www.eryuemu.com”的规则。 - Google 爬虫在 7 月 27 日、8 月 5 日、8 月 6 日、8 月 8 日这几天去爬取
/blog/...与/about/时,每次请求都如实收到了服务器返回的 308 响应,因此被真实记录为了「网页会自动重定向」。
3. 为什么这些数据在 8 月 14 日~15 日突然集中爆发?
- 原因在于站长所有权验证的触发点:你是在 8 月 14 日 才首次在 Google Search Console 中完成域名所有权验证并提交 Sitemap 的。
- 在 8 月 14 日之前,Google 底层爬虫早在 7 月下旬就已经在后台静默抓取并记录了。
- 8 月 14 日完成验证的一瞬间,GSC 后台将过去所有底层积累的历史爬虫账单一次性汇总呈现在控制台上,从而在趋势图表上形成了一条陡峭的统计折线。
三、核心科普:www 与「不带 www」到底有什么区别?
在普通用户眼里,输入 eryuemu.com 和 www.eryuemu.com 都能打开同一个博客,感觉“完全一样”。但在互联网协议和搜索引擎眼里,它们完全是两个东西:
eryuemu.com ← 根域名(裸域名 / Apex Domain)
www.eryuemu.com ← 子域名(Subdomain,与 guide.hbuwiki.top 属于同级概念)
| 维度 | 不带 www(根域名:eryuemu.com) |
带 www(www.eryuemu.com) |
|---|---|---|
| 视觉体验 | 极简、现代、干净,分享给他人时一目了然 | 传统稳重,多打 4 个字符 |
| 适用场景 | 个人博客、独立开发者、现代技术社区(强烈推荐) | 大型企业门户、巨型跨子域系统 |
| Cookie 隔离 | 根域名 Cookie 会默认广播到所有子域名 | 可通过子域独立隔离 Cookie |
| 行业趋势 | GitHub, Twitter/X, V2EX, 90%+ 现代博客 | 百度、传统政企与门户网站 |
⚠️ 致命大忌:如果两个都设为主站(都不做跳转)会怎样?
有些站长为了“省事”,在 Vercel 里把 eryuemu.com 和 www.eryuemu.com 都设为 Production,这在 SEO 领域属于严重踩坑:
- 搜索权重腰斩(Link Juice Dilution):
- 搜索引擎会判定互联网上出现了两个 100% 重复的镜像站点。
- 外链和流量被拆成两半,原本能排第 1 名的页面可能被拆成两个各排第 10 名,甚至触发 Google 的「重复内容惩罚」导致全站降权。
- 深色模式与缓存“人格分裂”:
- 浏览器的
localStorage与 Cookie 是按完整域名隔离的。访客在eryuemu.com开启了 🌙 深色模式,下次通过www.eryuemu.com进入又会跳回 ☀️ 浅色模式。
- 浏览器的
- 评论系统与访问量割裂:
- 博客底部的 Waline 评论系统与访问量计数若按当前页面 URL 匹配,会导致在两个域名下看到的评论数据完全互不相通。
[!IMPORTANT] 行业黄金准则:无论选哪一个当主站,都必须做 「一主一辅、301/308 自动跳转」,让所有流量与权重 100% 汇聚到单一主域名!
四、最终架构决策:全面转正为「不带 www(eryuemu.com)」
综合个人博客的美观度与现代标准,最终决定:全面确立 https://eryuemu.com 为唯一权威主域名,www.eryuemu.com 作为辅助跳转通道。
五、全流程闭环实战:代码、服务器与 GSC 一网打尽
5.1 代码层面:全量规范化(Canonicalization)
1. Astro 主站点配置(astro.config.mjs)
export default defineConfig({
site: 'https://eryuemu.com', // 统一收敛为根域名
integrations: [mdx(), sitemap()],
});
2. 爬虫路标(public/robots.txt)
User-agent: *
Allow: /
Sitemap: https://eryuemu.com/sitemap-index.xml
3. 结构化数据与规范标签(src/components/BaseHead.astro)
<link rel="canonical" href={canonicalURL} />自动跟随Astro.site生成https://eryuemu.com/...。- 将 JSON-LD 中的
WebSite与SiteNavigationElement统一收敛至https://eryuemu.com。
4. 友链名片与站内资源
src/pages/friends.astro中的博客名片link与logo统一改为https://eryuemu.com/。- 站内静态资源引用(如头像)统一改为站内相对路径
/avatar.jpg。
5.2 托管服务器层面(Vercel 域名重定向配置)
进入 Vercel 项目控制台 -> Settings -> Domains:
图:调整前状态——eryuemu.com 显示 308 跳转,需将其设为主站
操作步骤:
- 点击
eryuemu.com右侧Edit-> 选择Production-> 保存。 - 点击
www.eryuemu.com右侧Edit-> 勾选Redirect to Another Domain-> 状态码选308 Permanent Redirect-> 目标选择eryuemu.com-> 保存。
图:将 www.eryuemu.com 配置为 308 Permanent Redirect 重定向至 eryuemu.com
5.3 Google Search Console 站长平台规范化
在 GSC 资源管理中,曾经因添加了带 www 与不带 www 导致面板混淆:
图:GSC 资源下拉菜单中同时存在两个网址前缀资源
⚠️ 避坑警示:千万不要在「移除」页面申请删除资源!
图:GSC 左侧菜单的「移除」是申请在搜索结果中紧急下架屏蔽网页,切勿在此提交删除资源申请!
正确删除冗余资源的步骤:
- 在左上角下拉框切换选中
https://www.eryuemu.com/(待删除的多余资源)。 - 点击左侧菜单底部的
设置(Settings,齿轮图标)。 - 滚动到设置页面最下方,点击红色的
移除资源(Remove property) 并确认。 - 回到主面板
https://eryuemu.com/,在「网页会自动重定向」详情页点击 「验证修正情况」(Validate Fix)。
5.4 访问量统计服务(Vercount vs Umami)的定位与无缝继承排坑
在站长工具链中,很多开发者容易对 Vercount 与 Umami 这两套访客系统的分工产生混淆。其实在博客与 HBU Wiki 的架构实践中,它们是各司其职的互补关系:
┌───────────────────────────────────────────────────────────┐
│ 访客流量进入站点 │
└───────────────┬───────────────────────────┬───────────────┘
│ │
▼ ▼
【Vercount:前台门面】 【Umami:后台指挥部】
(events.vercount.one) (cloud.umami.is)
• 极简轻量 API,零运维成本 • 专业可视化流量分析大屏
• 面向普通读者公开展示: • 面向站长自己做深度洞察:
「访问人数 490 · 总访问量 2538」 • 访客来自哪个国家/城市?
• 用户用的是 Chrome 还是 iPhone?
• 从哪个网站跳转进来的(搜索/B站/GitHub)?
• 每篇文章平均停留了几分钟?
为什么博客和 HBU Wiki 都选用了 Vercount 作为前台计数器?
- 轻量与响应速度:Vercount 是类似不蒜子(busuanzi)的现代无服务器替代品。它只需要几行前端 JavaScript 发送一个微小的 POST 请求即可获取全站 UV/PV,无需配置复杂的后台鉴权 Token。
- 前后端解耦:我们在 HBU Wiki 的指南子站(
guide.hbuwiki.top)底部就是使用了这套 API 进行阅读量统计,因此博客也复用了相同的技术选型。
⚠️ 踩坑实录 ①:博客主域名切换导致整站访问量“归零”?
主域名切换为 eryuemu.com 后,博客底部的访问量计数器突然出现了一个现象:原本 7 月以来积累的 490 访问人数与 2500+ 总访问量,在页面上突然重置显示为 「访问人数 2 · 总访问量 7」。
图:域名切换后,底部 Vercount 访问计数器因新域名账本独立而重置
- 根因分析:Vercount(
events.vercount.one)统计接口是严格按照请求报文中的url(即window.location.href的 Hostname)分别独立记账的。原本在www.eryuemu.com下积累了site_uv: 490、site_pv: 2538;换到eryuemu.com后,Vercount 认为这是一个全新的独立站点,开辟了新账本。 - 代码修复方案:在
src/components/Footer.astro中,将上报统计的 URL 显式映射到历史统计标识:
修复部署后,页面刷新即可立即恢复 490 访问人数 · 2538 总访问量,后续所有新访问均在历史累计数据上继续自然递增。// 将计数请求映射到历史统计标识(www.eryuemu.com),无缝继承 7 月以来积累的 490+ 人数与 2500+ 访问量 const statUrl = window.location.href.replace(/^https?:\/\/eryuemu\.com/, 'https://www.eryuemu.com'); const res = await fetch(API_URL, { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ url: statUrl, isNewUv: isNewUv }) });
⚠️ 踩坑实录 ②:HBU Wiki 开启 cleanUrls 后单页阅读量骤降(105+ 变成 6)?
在 HBU Wiki 项目中,为了美化 URL 开启了 VitePress 的 cleanUrls: true(让网页访问路径从 /academics/transfer.html 变为无扩展名的 /academics/transfer)。
更新上线后,发现底部的 “全站总 PV(590+)”与“全站 UV(39)”完好无损,但“本文阅读量”却突然从 105+ 变成了 6。
- 根因分析:
- 全站 PV/UV:是以域名(
guide.hbuwiki.top)作为聚合维度的,因此不受单页路径变化影响; - 本文阅读量(page_pv):Vercount 会把传入的完整 URL 字符串当作唯一 key。当浏览器中的 URL 由带
.html变为不带.html时,Vercount 将其视为了一个“全新发布的网页”,从而开辟了全新的单页计数器,导致老页面积累的 100+ 阅读量被锁在带.html的旧标识中。
- 全站 PV/UV:是以域名(
- 代码修复方案:
在
HBU-Wiki/.vitepress/theme/components/PageView.vue中,在向 Vercount 发送请求前做一层 URL 规范化映射,自动补齐.html后缀以对齐历史账本:
通过这层简单优雅的映射,// 规范化统计 URL:统一映射到带 .html 的历史统计标识,无缝继承 cleanUrls 开启前的单页历史阅读量资产 let statUrl = window.location.href.split('?')[0].split('#')[0].replace(/\/$/, ''); if (!statUrl.endsWith('.html') && !statUrl.endsWith('.top') && !statUrl.endsWith('.io') && !statUrl.endsWith('.com')) { statUrl = `${statUrl}.html`; } const res = await fetch(API_URL, { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ url: statUrl, isNewUv: isNewUv }) });/academics/transfer瞬间找回并累加了 105+ 次历史阅读量,/academics/data-explorer找回了 179+ 次阅读量,/about也找回了 88+ 次阅读量,彻底解决 URL 美化与历史数据继承的冲突!
5.5 「心迹」模块 SEO 实战:Google SERP 真实收录检验与动态 Title 优化
在日常追踪中,我们在 Google 搜索框直接检索 eryuemu心迹,对心迹模块的收录情况进行了实战检验:
图:Google 搜索「eryuemu心迹」实测结果——心迹主页、3 条心迹动态全部被 Google 收录并排名前列,下方还聚合展示了动态中的多张图片卡片
1. 发现问题:千篇一律的「重复标题」痛点
从上图的搜索结果中可以发现一个明显的 SEO 瑕疵:
- 3 条动态的蓝色大标题全部显示为一模一样的
心迹动态、心迹动态、心迹动态。 - 根因:此前在
src/pages/thoughts/[...id].astro中,写死了固定元数据<BaseHead title={"心迹动态 — " + SITE_TITLE} />。 - 危害:在搜索引擎眼里,标题重复率 100% 的页面容易被算法判定为“模板重复页”,读者在搜索结果列表里也无法凭标题区分具体内容。
2. 优化方案:智能内容感知(Content-Aware)动态 SEO 标签
在 src/pages/thoughts/[...id].astro 中,加入动态文本截取逻辑,自动抓取正文第一句话作为独一无二的 Title 与 Description:
// 动态提取心迹文本内容生成独特的 SEO Title 与 Description
const rawBody = thought.body || '';
const cleanText = rawBody.replace(/[\s\r\n#*`_>[\]()\-+!]+/g, ' ').trim();
const seoTitle = cleanText
? `心迹: “${cleanText.slice(0, 32)}${cleanText.length > 32 ? '...' : ''}” — ${SITE_TITLE}`
: `心迹动态 (${thought.id}) — ${SITE_TITLE}`;
const seoDescription = cleanText
? cleanText.slice(0, 140)
: `eryuemu(二月木)于 ${pubDate.toISOString().slice(0, 10)} 发布的心迹动态`;
3. 优化效果:
- 8 月 02 日动态:
心迹: “感觉自己这辈子也就这样了,Galgame 里的女主...” — eryuemu's blog - 8 月 05 日动态:
心迹: “现在的小孩确实是挺幸运的,记得我小时候...” — eryuemu's blog - 8 月 14 日动态:
心迹: “人生的意义在于什么呢,我在初高中思考过...” — eryuemu's blog
Google 爬虫在下一次周期性回访刷新快照后,搜索结果列表中的标题将变得极其生动且各具特色,大幅提升搜索点击率(CTR)与页面权重!
六、复盘总结:老域名资产如何做到「零损耗无缝过渡」?
┌────────────────────────────────────────────────────────┐
│ 最终规范化架构 │
│ │
│ 访客/爬虫访问 www.eryuemu.com │
│ │ (Vercel 308 永久重定向) │
│ ▼ │
│ 统一汇聚于主站 https://eryuemu.com │
│ │ (Astro Canonical + Sitemap + JSON-LD) │
│ ▼ │
│ Google & Bing 权威收录单一主库,权重 100% 聚焦 │
└────────────────────────────────────────────────────────┘
对于从 www 切换到根域名的站点,老域名的所有资产已按以下 4 个维度做到 100% 继承与无损过渡:
| 资产类型 | 处理机制 | 效果与保障 |
|---|---|---|
| 访问量与访客数据 | Footer.astro 接口统一映射历史 key |
7 月以来的 490 UV / 2538 PV 完好保留并继续累加 |
| 搜索引擎权重与外链 | Vercel 308 Permanent Redirect + Canonical | 老域名反向链接与搜索排名历史 100% 转移并合并至新主站 |
| 文章评论数据(Waline) | 数据库按页面相对路径(/blog/...)匹配 |
历史读者留言完全不受域名切换影响,100% 正常展现 |
| 访客书签与外部老链接 | CDN 边缘节点 0.01 秒极速重定向 | 访客点击老链接无感滑入新主站,绝无 404 故障 |
七、后记与系列续篇(8 月 20 日随访追踪)
在 8 月 18 日完成根域名规范化并在 GSC 提交「验证修正情况」后,很多站长会关心:提交验证后 Google 到底会经历怎样的周期?副站知识库又会遇到什么新挑战?
- 8 月 20 日随访:GSC 定时汇总机器人触发了阶段性邮件通知(证明验证正在后台排队回访);
- 系列进阶:从博客的「域名级规范化」延伸到 VitePress 知识库的「路径级 Clean URLs 规范化」,我们在续篇中完成了多站统一的改造实战;
- 📖 续篇传送门:《GSC 报警「备用网页」与「未编入索引」全复盘:VitePress Clean URLs 与多站 SEO 规范化》
