一句话: 一个内容多个 URL 是常态(region/device/protocol/筛选/事故),Google 必须选一个 canonical 来去重。你可以给 hint(rel=canonical / 301 / sitemap),但Google 最终决定。搞砸 canonical = SEO 信号分裂、流量被稀释、Search Console 报告全是别人 property 的。
TL;DR — 5 个核心决策
| 你的场景 | 用啥 |
|---|---|
| 重复页面想统一信号 | rel="canonical" link 标签(HTML 页)或 HTTP header(PDF/非 HTML) |
| 弃用一个旧 URL | 301 / 308 永久 redirect 到新 URL |
| 临时维护要导流到 alternate 页 | 302 / 307 临时 redirect |
| 换域名 / HTTP→HTTPS / 路径大改 | Site move 5 步法 + Change of Address tool |
| 换 host / CDN 不改 URL | Site move 4 步法 + 不需要 Change of Address |
| 电商临时缺货 / 短暂歇业 | 限制功能 + 改 structured data(不要整站关 / 不要 noindex / 不要 503 > 几天) |
| 服务器临时挂 1-2 天 | 返回 503 + Retry-After header(但 robots.txt 必须仍正常 200) |
Part 1 — Canonicalization: Google 怎么选 canonical
1.1 为什么会有重复 URL?(5 大常见来源)
- Region variants —
/us/、/uk/、/au/同内容不同地区 - Device variants — desktop + mobile 不同子域(m.example.com)
- Protocol variants — http:// 和 https:// 都能访问
- Site functions — 排序 / 筛选参数(
?sort=price&color=red) - Accidental variants — 测试环境忘记 block 了
⚠️ 重复内容本身不违反 spam policy,但用户体验差 + 跟踪困难 + Google crawl budget 浪费。
1.2 Google 怎么自动选
收齐"signals" → 选最完整、最有用那一版作为 canonical。
signals 来源:
- HTTPS vs HTTP
- 是否在 sitemap 里
- redirect 关系
rel="canonical"显式声明- 内部 + 外部链接指向
canonical 的待遇:爬得最勤(duplicates 爬得少,节省 crawl 资源)。
搜索结果展示哪个: 通常 canonical,但移动用户搜可能展示 mobile variant(即便 desktop 是 canonical),这是有意为之。
1.3 ⚠️ 多语言不算 duplicate
不同语言版本默认不是 duplicates。除非只翻译了 header/footer 但 body 没翻译 → 才算 dup。多语言用 hreflang,不是 canonical。
Part 2 — 4 种指定 canonical 方法(按强度排)
2.1 强度优先级表
| 方法 | 强度 | 适用 | 优缺点 |
|---|---|---|---|
| Permanent redirect(301/308) | ⭐⭐⭐ 最强 | 要弃用旧 URL时 | 直接告诉 Google "用新 URL,旧的不要了" |
rel="canonical" <link>(HTML 内) |
⭐⭐ 强 | HTML 页 | 可映射无限多 dup;大站维护复杂;只对 HTML |
rel="canonical" HTTP header |
⭐⭐ 强 | PDF / 非 HTML 文件 | 不增加文件大小;Google 仅 web 搜索支持 |
| Sitemap 列出 | ⭐ 弱 | 大站批量声明 | 简单 + 易维护;Google 仍需自行判 dup;比 rel=canonical 弱 |
| AMP variant | n/a | AMP 页 | 遵循 AMP guidelines |
核心: 这些方法可叠加(同一个目标用多种,信号更强)。
2.2 rel=canonical 6 大反 pattern
- ❌ 用 robots.txt Disallow 当 canonical 工具 — disallow 的 URL 仍可能被索引(无内容),完全无效
- ❌ 用 URL Removals tool 当 canonical 工具 — 它隐藏所有版本,过头了
- ❌ 同一页用不同方法声明不同 canonical(sitemap 写 A,rel=canonical 写 B)— Google 困惑
- ❌ URL fragment 作 canonical(
#section)— Google 不支持 fragment - ❌ noindex 当 canonical 工具 — noindex 完全屏蔽该页,不是选最佳版的工具。用 rel=canonical。
- ❌ hreflang + canonical 跨语言 —
rel="canonical"必须指向同语言的页,不同语言用 hreflang
2.3 rel=canonical link 元素的实施
<html>
<head>
<title>Explore the world of dresses</title>
<link rel="canonical" href="https://example.com/dresses/green-dresses" />
<!-- 其他元素 -->
</head>
<body>...</body>
</html>
铁律:
- ✅ 绝对 URL(
https://www.example.com/...)— 相对 URL Google 支持但不推荐(测试站不小心被爬时会乱) - ✅ 必须在
<head>里 — 放<body>里 Google 不接受 - ✅ 自指 canonical 也要 — 每个 URL 都应该有 rel=canonical 指向自己(避免被夺权)
移动 variant 配合 rel="alternate":
<link rel="alternate" media="only screen and (max-width: 640px)" href="https://m.example.com/dresses/green-dresses">
<link rel="canonical" href="https://example.com/dresses/green-dresses" />
2.4 rel=canonical 的 HTTP header(非 HTML 文件唯一选)
HTTP/1.1 200 OK
Content-Length: 19
...
Link: <https://www.example.com/downloads/white-paper.pdf>; rel="canonical"
...
例: .docx 版告诉 Google 其 .pdf 版才是 canonical。
⚠️ 不要同时用 HTML 元素 + HTTP header(易出错,容易冲突)。选一个。
2.5 JS 设 canonical 的特殊纪律
最佳: HTML 源码里设 canonical → JS 别动。
次选: HTML 源码里不设 → 完全由 JS 设(避免 Google 抓 raw HTML 看到一个 / 渲染后看到另一个)。
最差: HTML 写 A,JS 改成 B → Google 行为不可预测。
Part 3 — 其他隐式 canonical 信号
3.1 HTTPS 优先 ⭐
Google 默认偏好 HTTPS(就算你不显式说)。但几种情况会反向让 Google 错选 HTTP:
- ❌ HTTPS 页 SSL 证书无效
- ❌ HTTPS 页有不安全依赖(除图以外的 http:// 资源)
- ❌ HTTPS 页redirect 到 HTTP 页
- ❌ HTTPS 页的
rel="canonical"指向 HTTP 页
强制 HTTPS 的 3 个手段:
- HTTP → HTTPS 加 301 redirect
- HTTP 页加
rel="canonical"指向 HTTPS 页 - 实施 HSTS
⚠️ 致命组合: 坏证书 + HTTPS→HTTP redirect → Google 会强烈偏好 HTTP → HSTS 都救不回。
⚠️ 证书 host-variant 必须正确:example.com 不能用 subdomain.example.com 的证书。要么精确匹配,要么 wildcard。
3.2 hreflang cluster 偏好
如果 /de-de/cats 和 /de-ch/cats 互相 hreflang 引用,但 /de-at/cats 不在 cluster 里 → Google 优先选 cluster 里的页作 canonical,把 /de-at/ 当 dup。
Part 4 — Canonicalization Troubleshooting
4.1 用 URL Inspection tool 查
URL Inspection tool 直接告诉你 Google 当前选了哪个作 canonical。先看 Google 选的是否比你想要的更合理 — 有时候 Google 是对的。
4.2 6 大常见 issue
| Issue | 表现 | 修法 |
|---|---|---|
| 多语言没注 hreflang | 英美澳同内容,Google 把它们当 dup,只展示其中一个 | 加 hreflang 标注每个 locale 版 |
| CMS 或插件写错 rel=canonical | rel=canonical 指向意外 URL | 用浏览器 devtools 查实际 HTML;联系 CMS 提供商 |
| 服务器配错 | example.com 请求返回 other.example 内容 / 两站返回相同 soft 404 |
联系 hosting provider |
| 被黑客注入恶意 rel=canonical / 3xx redirect | canonical 指向恶意 / spam URL | 走 hacked sites recovery |
| Syndication partner 抢 canonical | 内容被合法转载,但 Google 选了 partner 的版 | partner 应该 block 索引你的转载内容,canonical 不可靠(syndicated 内容差异大,canonical 不合适) |
| 抄袭网站抢 canonical | 别的站偷你内容,Google 选了他的版 | 联系对方 hosting 要求移除 + 给 Google 发 DMCA request |
⚠️ 如果 canonical 落到你不拥有的 Search Console property → 你看不到任何流量数据,必须先把 canonical 抢回来。
Part 5 — HTTP 状态码完整表 ⭐⭐⭐
Google 对每类 status code 的处理决定了你的 URL 命运。
5.1 完整对照表
| 状态码类 | Google 行为 |
|---|---|
| 2xx (success) | 处理内容(可能索引,不保证) |
| 3xx (redirection) | follow up to 10 hops(Google Inspection Tools 不 follow);忽略中间 URL 的内容,只处理最终目标 |
| 4xx (client errors) | 不索引;原来索引过的会被移除;429 例外(当作 server overload) |
| 5xx (server errors) | 临时降低 crawl rate;原索引保留一段时间最终也会掉;恢复 2xx 后逐步回升 |
5.2 关键单码语义
| Code | 含义 | Google 行为 |
|---|---|---|
200 |
OK | 进索引 pipeline(不保证索引) |
201 / 202 |
Created / Accepted | 同 200;202 会等内容(timeout 因 UA 而异) |
204 |
No content | 没内容,跳过 |
301 |
Moved permanently | 强信号: redirect target 应作 canonical |
302 / 303 / 307 |
Found / See other / Temp redirect | 弱信号: redirect target 该处理,但不变 canonical |
304 |
Not modified | 内容没变(用上次抓到的版),索引信号可能重算 |
308 |
Moved permanently | 等价 301 |
400 / 401 / 403 / 404 / 410 / 411 |
各类客户端错 | 从索引移除(逐步 crawl 频率降) |
429 |
Too many requests | 当 server overload(不算 4xx 同类),临时降速 |
500 / 502 / 503 |
Server error | 临时降 crawl rate,内容继续存索引但久了会掉 |
5.3 ⚠️ 关键纪律
- ❌ 不要用 401 / 403 限流 — 它们不会影响 crawl rate。要限流走 reduce crawl rate
- ✅ 301 vs 308 / 302 vs 307 在 Google 看来相同,但语义不同,选对的让其他 client(e-readers / 其他搜索引擎)也能正确解读
- ⚠️ 2xx 内容如果像 error 页(空页 / 错误提示)→ Search Console 报 soft 404
Part 6 — 5 种 Redirect 类型 + 实施
6.1 类型对照
| 类型 | 永久/临时 | Google 视角 | 备注 |
|---|---|---|---|
HTTP 301 |
永久 | 强信号,target 作 canonical | 首选 |
HTTP 308 |
永久 | 等价 301 | |
meta refresh (0s) |
永久 | 等价 301 | 服务器侧不行才用 |
HTTP refresh (0s) |
永久 | 等价 301 | |
JavaScript location |
永久 | 等价 301,但渲染失败就丢失 | 最后选项,有风险 |
Crypto redirect |
永久 | 可能识别(像尼斯湖水怪,争议中) | 再没别的辙才用 |
HTTP 302 / 303 / 307 |
临时 | follow 但不变 canonical | 短期下线 / 维护 |
meta refresh (>0s) |
临时 | 等价 302 | |
HTTP refresh (>0s) |
临时 | 等价 302 |
永久 vs 临时的搜索结果差异:
- 永久: 搜索结果展示新 URL
- 临时: 搜索结果仍展示老 URL(target 也可能被索引,如果有其他 canonical 信号)
6.2 Server-side redirect 实施
PHP:
// 永久
header('HTTP/1.1 301 Moved Permanently');
header('Location: https://www.example.com/newurl');
exit();
// 临时
header('HTTP/1.1 302 Found');
header('Location: https://www.example.com/newurl');
exit();
Apache .htaccess(简单 mod_alias):
# 永久
Redirect permanent "/old" "https://example.com/new"
# 临时
Redirect temp "/two-old" "https://example.com/two-new"
复杂的用 mod_rewrite:
RewriteEngine on
RewriteRule "^/service$" "/about/service" [R=301] # 永久
RewriteRule "^/service$" "/about/service" [R] # 临时
NGINX:
location = /service {
return 301 $scheme://example.com/about/service; # 永久
return 302 $scheme://example.com/about/service; # 临时
}
复杂用 rewrite:
location = /service {
rewrite service?name=$1 ^service/offline/([a-z]+)/?$ permanent; # 永久
rewrite service?name=$1 ^service/offline/([a-z]+)/?$ redirect; # 临时
}
6.3 meta refresh 实施
<!-- 永久(0 秒) -->
<meta http-equiv="refresh" content="0; url=https://example.com/newlocation">
<!-- 临时(5 秒后跳)-->
<meta http-equiv="refresh" content="5; url=https://example.com/newlocation">
或者放 HTTP header:
HTTP/1.1 200 OK
Refresh: 0; url=https://www.example.com/newlocation
6.4 JavaScript redirect(最后选)
<script>
window.location.href = "https://www.example.com/newlocation";
</script>
⚠️ Google 必须渲染成功才能看到 JS 跳转。渲染失败会丢。
6.5 Crypto redirect(实在没辙)
<a href="https://newsite.example.com/newpage.html">We moved! Find the content on our new site!</a>
Google 可能识别为伪 redirect,别的搜索引擎多半不识别。
6.6 Alternate name 概念
URL 重定向后,Google 同时跟踪 old + new。其中一个是 canonical,另一个变成 alternate name。当用户搜索 query 显示更信任旧 URL 时,Google 可能仍展示旧 URL。这是正常的,用户习惯新域名后会自然消退,不用管。
Part 7 — Site Move A: 换 hosting / CDN(不改 URL)
7.1 4 步法
- 准备新 infra
- 启动(改 DNS)
- 监控流量
- 关掉老 infra
7.2 关键准备
- 复制 + 测试: 文件 / DB 整套移到新 host,完整功能测
- 测试环境用 IP 限制访问 + noindex 防止意外索引
- 临时 hostname(
beta.example.com)给 Googlebot 测可达性,用 noindex 防索引 - Search Console 用 URL Inspection 测 Googlebot 是否能达新 infra
- 防火墙 / DDoS 防护别 block Googlebot — 走 verify Googlebot
- DNS TTL 提前一周降到几小时 → DNS 切换时 ISP 缓存更新更快
- Search Console 验证文件 别忘记带到新 infra(HTML file 或 meta tag 或 GA snippet)
7.3 启动后行为
- 移除临时 block(robots.txt disallow / noindex)
- 改 DNS 指新 infra
- 看日志:老 host 流量降 + 新 host 流量升
- 不同地区 ISP DNS 更新用 公共 DNS check tools
- Search Console 看 Index coverage
7.4 Googlebot crawl rate 行为
新 host 上线后,crawl rate 短期会跌,然后稳步回升,有可能比原来还高。属于正常,因 Google 重新对新 infra 做信号评估。
7.5 关老 host
老 host 日志显示流量到 0 → 关。
Part 8 — Site Move B: 换 URL(换域名 / HTTP→HTTPS / 路径改)⭐⭐⭐
8.1 5 步法
- General best practices
- Prepare 新站
- Prepare URL mapping(老 → 新)
- 启动(开 redirect)
- Monitor
8.2 总体 best practices
- 小步拆分: 大站先移一小块测试,再批量(选变化少 / 不被频繁影响的小块)
- 一次只改一件事 — 别同时换域名 + 换 CMS + 换 layout,分批做
- 挑流量低谷迁 — 季节性 / 工作日有低谷就用
- 预期排名波动 — 中型站几周,大站更长
- 301 不会丢 PageRank — 别担心 link credit
- 大量用 Search Console — Index Status / Sitemaps report
- 耐心: Googlebot 每个 URL 都得新老站各访一次,逐 URL 完成
8.3 Prepare 新站(细)
- 用同一种 CMS 最佳,避免多重变量
- 移图片 / PDF 等下载文件(它们也可能有 SEO 流量)
- HTTP→HTTPS: 配 TLS 证书
- 配新的
robots.txt(注意 dev 阶段的 disallow 要在迁移开始时移除) - 已删 / 已合并的内容: 新站返回正确的
404或410 - Search Console:
- 验证所有变体(
www.example.com/example.com/ HTTP / HTTPS) - Disavow file: 如果老站有,重新上传到新站的 Search Console
- 检查新域名是否清白: 看 Manual Actions / Removed URLs(防上手主留下毒瘤)
- 验证所有变体(
- 服务器 capacity: 迁移期 Google 会比平时爬得更猛(redirected old + new 同时爬)— 大站联系 hosting 商提前预警
8.4 Prepare URL mapping
找老 URL 的渠道:
- Sitemap
- Server log(看最近被访问的 URL)
- Analytics 软件(高流量 URL)
- Search Console Links to your site(有外链的 URL 优先)
- CMS 内容列表
- 包括嵌入资源: 图、视频、JS、CSS(也要 redirect)
建 mapping: DB 或 URL rewriting rules。
新站每个 URL 准备:
- 自指 rel=canonical 用新 URL
- hreflang annotations 更新到新 URL
- 新 sitemap(列新 URL)+ 旧 sitemap(列旧 URL)— 两份都留着,Search Console 提交看两份分别索引进度
8.5 Redirect 策略
- Server-side permanent 优先(301/308)
- 避免 redirect chain — Google follow 最多 10 hops,推荐 ≤3,绝不超过 5。Chain 拖慢用户,有些 client 不支持长链
- 避免无关 redirect — 别把一堆旧 URL 全 redirect 到新首页,会被当作 soft 404。只有内容真的合并到新页才能多对一 redirect
- 小中型站: 一次性全迁
- 大站: 分批
8.6 启动迁移
- 开 redirect(改 server config / CMS)
- 确认新站 rel=canonical 都指向新 URL + 移除迁移用的 noindex
- 测 redirect: URL Inspection + 命令行批量测
- Search Console 老站提交 Change of Address tool(注:HTTP→HTTPS 不用 Change of Address)
- 保留 redirect 至少 1 年(理想永久 — 用户体验考虑 + 等所有外链转换)
- 新站提交新 sitemap
8.7 启动后立刻更新链接
- 内链: 按 mapping 把所有内链改成新 URL
- 外链: 联系链你的高流量站,请改链接
- Profile links(Facebook/Twitter/LinkedIn)
- 广告 campaign 改 landing page
8.8 监控
- Sitemaps report: 老 sitemap 索引数会逐渐降到 0,新 sitemap 升;老 sitemap 的 redirect warning 可忽略(预期的)
- Index Coverage: 老站索引数降 / 新站升;定期看意外 crawl errors
- Search queries: 新站逐渐出现 query impression 和 click
8.9 5 大常见迁移错误
| Mistake | 后果 | 修法 |
|---|---|---|
忘移除迁移用的 noindex / robots.txt block |
新站完全不索引 | 检查 robots.txt + URL Inspection |
| Redirect 指向不存在的新 URL | 大量 404 | Search Console "Not found" 报告 / Screaming Frog 扫 |
| 其他 crawl errors | 索引中断 | Index Coverage 报告找尖峰 |
| Server capacity 不足 | crawl 超载 / 服务器挂 | 提前扩容 + 联系 hosting |
| Sitemap 没更新到新 URL | Google 没法发现新 URL | 更新并 resubmit |
8.10 资源推荐
- Aleyda Solis' site migration checklists — 业界 SEO 大牛的清单
- Screaming Frog — 站点迁移工具
Part 9 — 临时停业 / Pause Online Business ⭐
9.1 决策树
预期停业多久?
├─ 几小时到几天 → "限制功能"(强烈推荐)
├─ 1-2 天(服务器层面挂)→ 503 + Retry-After
├─ 几周以上 → 仍走"限制功能"
└─ 永久 → 走 site move 或 remove information
9.2 推荐: 限制功能(不要全关)⭐
| 措施 | 怎么做 |
|---|---|
| 禁购物车 | 最简单 — Search 可见性不变 |
| 加 banner / popup 提示状态 | 必须包 data-nosnippet 避免出现在搜索结果 snippet。遵守 intrusive interstitials guideline |
| 改 structured data | Product availability 改 OutOfStock / Event 改 cancelled / LocalBusiness opening hours 更新 |
| 更新 Merchant Center feed | 走 availability attribute best practices |
| 告诉 Google 你改了 | 单页改: URL Inspection 请求 recrawl;批量改: 重新 submit sitemap |
9.3 ⚠️ 不推荐: 整站关闭(副作用严重)
- 客户找不到你 → 信誉下降
- 第三方信息(可能不准确 / 不全)填补真空
- Knowledge Panel 丢电话 / logo
- Search Console 验证失败 → 失去所有数据
- 重新上线后,reindex 漫长且不确定 — 多久能恢复到原状不确定
9.4 真的要关 → 503 + 最佳实践(< 几天)
HTTP/1.1 503 Service Unavailable
Retry-After: <date or seconds>
Mime-Version: 1.0
Content-Type: text/html
必做:
- robots.txt 必须仍返回 200(不能 503!503 robots.txt 会 block 全部 crawling)
curl -I -X GET "https://www.example.com/"本地验证- 用
Retry-AfterHTTP header 给 best-effort 时间 - 静态 HTML + inline CSS + base64 图 减负
- 给用户清晰指引:何时回来 / 联系方式
禁忌:
- ❌ 用 403 / 404 / 410(URL 被移除)
- ❌ 加 noindex(URL 被移除)
- ❌ 用 Search Console 的 Removals tool(用户完全找不到你)
- ❌ robots.txt 全 Disallow(等同被移除)
- ❌ 用 503 给 robots.txt
9.5 关 > 几天怎么办?
返回 200 的 placeholder 页(放官方信息),不要 503。
9.6 短期紧急想从 Search 隐藏
→ Removals tool 临时移除。临时,~6 个月有效。
9.7 临时降 crawl rate
Googlebot 抓太狠拖服务器 → reduce crawl rate。记得设提醒,以后要 reset。
9.8 ⚠️ 别 block 某个 region
Google 通常从美国爬。block 美国 = block 整个 Google Search。
9.9 ⚠️ 别用 Removals tool 移除缺货商品
要让用户能看到"缺货"信息 — 直接 Removals 会让人完全找不到该商品,以为该公司没了。标 OutOfStock structured data,留页面。
Part 10 — Ask Google to Recrawl
10.1 几个 URL: URL Inspection tool
URL Inspection → Request Indexing。
前提: 你是 Search Console owner 或 full user。有配额上限,对同 URL 重复请求不会加快。
10.2 大量 URL: Sitemap
1. 建 sitemap 列所有要重爬的 URL
2. Search Console submit
3. Google 按自己节奏爬,几天到几周不等
10.3 注意事项
- Crawl 可能要几天到几周
- 监控用 Index Status report 或 URL Inspection
- 请求 crawl ≠ 保证索引(Google 优先索引高质内容)
- 用 hosted CMS(Blogger / WordPress)通常自动 submit,不用你管
Part 11 — 14 条反 pattern 集锦
| # | 反 pattern | 后果 |
|---|---|---|
| 1 | 用 robots.txt 当 canonical 工具 | 完全无效 |
| 2 | 用 URL Removals tool 当 canonical 工具 | 隐藏所有版本,过头 |
| 3 | 用 noindex 当 canonical 工具 | 整页被屏蔽,不是择优 |
| 4 | sitemap 写 A,rel=canonical 写 B | Google 选哪个不可预测 |
| 5 | rel=canonical 指向 URL fragment(#xxx) |
Google 不支持 fragment |
| 6 | rel=canonical 在 <body> 里 |
Google 不接受 |
| 7 | 相对 URL 当 canonical | 测试站被爬时炸 |
| 8 | HTTP→HTTPS 迁移用 Change of Address tool | 不需要,该 tool 是给换域名用的 |
| 9 | redirect chain > 5 hop | 用户慢 + 部分 client 不支持 |
| 10 | 一堆旧 URL 全 redirect 到新首页 | 被当 soft 404 |
| 11 | 临时停业返回 403/404/410 或加 noindex | URL 从索引移除,恢复极慢 |
| 12 | 临时停业 503 时 robots.txt 也返回 503 | block 全部 crawling,毁灭性 |
| 13 | 用 401/403 限流 | 不会影响 crawl rate,该用 reduce crawl rate tool |
| 14 | 重复 request URL Inspection recrawl 想加速 | 配额浪费,重复无效 |
Part 12 — 相关 wiki
- 为啥 canonical 重要 — 帮 Google 聚合信号: Google SEO 入门 + Search 工作原理 + Search Essentials 的 indexing 阶段
- 多语言: 国际化 (hreflang/多语言/多地区) + 显式内容 (SafeSearch/Adult) 完全指南(后续 wiki)
- Sitemap 怎么写: Sitemap 完全指南 (XML / RSS / Text + image / video / news / hreflang 扩展 + sitemap index)
- noindex / robots.txt 细节: 抓取与索引控制完全指南 (robots.txt / noindex / X-Robots-Tag / data-nosnippet / rel)
- Search Console 看迁移效果: Search Console + Analytics + Trends 三件套用法 (流量诊断 / 关键词调研 / Looker Studio) 的 Performance + Index Coverage
- AMP variant 怎么标 canonical: 后续 amp wiki(本仓库 AMP 4 篇可考虑后续整合)
- 已索引内容移除细则: 安全 / Spam / Removal / 搜索运算符 完全指南 (malware + phishing + UGC + redacted + site:)(后续 wiki)
Last updated
2026-05-17 — 基于 Google Search Central 9 篇 crawling-indexing 系列(2025-12 ~ 2026-04 最新)整理。301-redirects 2026-04 更新含 alternate name 详解。HTTP status code 完整覆盖 + 503 临时停业最新 best practice。
来源与关联资料
- https://developers.google.com/search/docs/crawling-indexing/canonicalization?hl=en
- https://developers.google.com/search/docs/crawling-indexing/canonicalization?hl=zh-cn
- https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls?hl=en
- https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls?hl=zh-cn
- https://developers.google.com/search/docs/crawling-indexing/canonicalization-troubleshooting?hl=en
- https://developers.google.com/search/docs/crawling-indexing/canonicalization-troubleshooting?hl=zh-cn
- https://developers.google.com/search/docs/crawling-indexing/301-redirects?hl=en
- https://developers.google.com/search/docs/crawling-indexing/301-redirects?hl=zh-cn
- https://developers.google.com/search/docs/crawling-indexing/site-move-no-url-changes?hl=en
- https://developers.google.com/search/docs/crawling-indexing/site-move-no-url-changes?hl=zh-cn
- https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes?hl=en
- https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes?hl=zh-cn
- https://developers.google.com/search/docs/crawling-indexing/pause-online-business?hl=en
- https://developers.google.com/search/docs/crawling-indexing/pause-online-business?hl=zh-cn
- https://developers.google.com/search/docs/crawling-indexing/http-network-errors?hl=en
- https://developers.google.com/search/docs/crawling-indexing/http-network-errors?hl=zh-cn
- https://developers.google.com/search/docs/crawling-indexing/ask-google-to-recrawl?hl=en
- https://developers.google.com/search/docs/crawling-indexing/ask-google-to-recrawl?hl=zh-cn