The Complete Guide to Canonicalization / Redirects / Site Migration (with full HTTP status code table + 503 temporary business closure playbook)

In one sentence: It is normal for one piece of content to have multiple URLs (due to region/device/protocol/filtering/incidents), and Google must select one canonical to deduplicate. You can provide hints(rel=canonical / 301 / sitemap), but Google makes the final decision. Messing up canonicalization = split SEO signals, diluted traffic, and Search Console reports all showing data for someone else's property.

TL;DR — 5 core decisions

Your scenario	What to use
Unify signals across duplicate pages	`rel="canonical"` link tag (for HTML pages) or HTTP header (for PDFs/non-HTML resources)
Retire an old URL	301 / 308 Permanent redirect to the new URL
Divert traffic to an alternate page during temporary maintenance	302 / 307 Temporary redirect
Domain change / HTTP→HTTPS / major path restructuring	5-step site move process + Change of Address tool
Host/CDN change without modifying URLs	4-step site move process + no Change of Address required
Temporary out-of-stock / short-term business closure for e-commerce	Limit functionality + update structured data(Do not shut down the entire site / do not use noindex / do not serve 503 for more than a few days)
Server is temporarily down for 1–2 days	Return 503 + `Retry-After` header(but robots.txt must still return a normal 200)

Part 1 — Canonicalization: How Google selects the canonical

1.1 Why do duplicate URLs exist? (5 common sources)

Region variants — /us/, /uk/, /au/ Same content for different regions
Device variants — Separate subdomains for desktop + mobile (m.example.com)
Protocol variants — Both http:// and https:// are accessible
Site functions — Sorting / filtering parameters (?sort=price&color=red)
Accidental variants — Test environment was not blocked

⚠️ Duplicate content does not itself violate spam policy, but it causes poor user experience, tracking difficulties, and wastes Google crawl budget.

1.2 How Google automatically selects

Gather all "signals" → select the most complete, most useful version as the canonical.

Signal sources:

HTTPS vs HTTP
Whether it is included in the sitemap
Redirect relationships
rel="canonical" Explicit declarations
Internal + external link pointing

Treatment of the canonical:Crawled most frequently(duplicates are crawled less often, to save crawl resources).

Which version appears in search results: Usually the canonical,but mobile searchers may be shown the mobile variant (even if the desktop version is canonical), and this is intentional.

1.3 ⚠️ Multilingual content is not considered duplicate

Different language versions are by default not duplicates. They only count as duplicates if only the header/footer is translated but the body is not. For multilingual sites use hreflang,not canonical.

Part 2 — 4 methods to specify canonical (ordered by strength)

2.1 Strength priority table

Method	Strength	Use case	Pros and cons
Permanent redirect(301/308)	⭐⭐⭐ Strongest	When retiring an old URL	Directly tells Google "use the new URL, the old one is obsolete"
`rel="canonical"` `<link>`(within HTML)	⭐⭐ Strong	HTML pages	Can map an unlimited number of duplicates; complex to maintain for large sites;Only works for HTML
`rel="canonical"` HTTP header	⭐⭐ Strong	PDFs / non-HTML files	Does not increase file size;Google only supports this for web search
Listed in Sitemap	⭐ Weak	Bulk declaration for large sites	Simple + easy to maintain; Google still needs to determine duplicates on its own;Weaker than rel=canonical
AMP variant	n/a	AMP pages	Follow AMP guidelines

Key point: These methods can be combined(using multiple methods for the same target creates a stronger signal).

2.2 6 major rel=canonical anti-patterns

❌ Using robots.txt Disallow as a canonical tool — disallowed URLs can still be indexed (without content), completely ineffective
❌ Using the URL Removals tool as a canonical tool — it hides all versions, which is overkill
❌ Declaring different canonicals for the same page using different methods(sitemap says A, rel=canonical says B) — Google gets confused
❌ Using URL fragments as canonical(#section) — Google does not support fragments
❌ Using noindex as a canonical tool — noindex completely blocks the page, it is not a tool for selecting the best version.Using rel=canonical.
❌ hreflang + canonical across languages — rel="canonical" must point to same-language pages; use hreflang for different languages

2.3 Implementing the rel=canonical link element

<html>
<head>
<title>Explore the world of dresses</title>
<link rel="canonical" href="https://example.com/dresses/green-dresses" />
<!-- 其他元素 -->
</head>
<body>...</body>
</html>

Hard rules:

✅ Absolute URL(https://www.example.com/...) — Google supports relative URLs but does not recommend them(they will break if a test site is accidentally crawled)
✅ Must be in the <head> — if placed in the <body> Google will not accept it
✅ Self-referential canonical is also required — every URL should have a rel=canonical pointing to itself (to avoid being usurped)

Mobile variant used with 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 in HTTP headers (the only option for non-HTML files)

HTTP/1.1 200 OK
Content-Length: 19
...
Link: <https://www.example.com/downloads/white-paper.pdf>; rel="canonical"
...

Example: .docx version tells Google that its .pdf version is the canonical.

⚠️ Do not use both the HTML element and the HTTP header at the same time(error-prone, easy to cause conflicts). Pick one.

2.5 Special rules for setting canonical with JS

Best: Set canonical in the HTML source → do not touch it with JS.

Second best: Do not set it in the HTML source → set it entirely with JS (to avoid Google seeing one canonical in raw HTML and another after rendering).

Worst: HTML says A, JS changes it to B → Google's behavior is unpredictable.

Part 3 — Other implicit canonical signals

3.1 HTTPS preference ⭐

Google HTTPS is preferred by default(even if you do not explicitly say so). But several situations can reverse this and cause Google to incorrectly select HTTP:

❌ HTTPS page has an invalid SSL certificate
❌ HTTPS page has insecure dependencies(http:// resources other than images)
❌ HTTPS page redirects to an HTTP page
❌ The rel="canonical" on the HTTPS page points to an HTTP page

3 methods to enforce HTTPS:

HTTP → HTTPS Add a 301 redirect
Add rel="canonical" on HTTP pages pointing to the HTTPS page
Implement HSTS

⚠️ Fatal combination: Bad certificate + HTTPS→HTTP redirect → Google will strongly prefer HTTP → even HSTS cannot save it.

⚠️ Certificate host-variant must be correct:example.com you cannot use subdomain.example.com's certificate. It must either be an exact match or a wildcard certificate.

3.2 hreflang cluster preference

If /de-de/cats and /de-ch/cats reference each other via hreflang, but /de-at/cats is not in the cluster → Google will preferentially select a page within the cluster as the canonical, and treat /de-at/ as a duplicate.

Part 4 — Canonicalization Troubleshooting

4.1 Check with the URL Inspection tool

URL Inspection tool directly tells you which URL Google currently selected as the canonical.First check whether Google's selection is more reasonable than the one you want — sometimes Google is correct.

4.2 6 common issues

Issue	Symptom	Fix
Multilingual pages missing hreflang annotations	US/UK/AU have the same content, Google treats them as duplicates and only shows one	Add hreflang annotations for each locale version
CMS or plugin writes incorrect rel=canonical	rel=canonical points to an unintended URL	Check the actual HTML with browser devtools; contact your CMS provider
Server misconfiguration	`example.com` request returns `other.example` content / two sites return the same soft 404	Contact your hosting provider
Malicious rel=canonical / 3xx redirect injected by hackers	Canonical points to a malicious / spam URL	Follow hacked sites recovery
Syndication partner takes over canonical	Content is legally republished, but Google selects the partner's version	The partner should block indexing of your republished content, canonical is unreliable (syndicated content has large differences, canonical is not appropriate)
Scraper site takes over canonical	Another site steals your content, Google selects their version	Contact their hosting to request removal + send Google a DMCA request

⚠️ If the canonical resolves to a Search Console property you do not own → you will not see any traffic data, you must reclaim the canonical first.

Part 5 — Complete HTTP status code table ⭐⭐⭐

Google's handling of each status code category determines the fate of your URLs.

5.1 Complete reference table

Status code class	Google behavior
2xx (success)	Processes content (may index,not guaranteed)
3xx (redirection)	follow up to 10 hops(Google Inspection Tools do not follow); ignores content of intermediate URLs, only processes the final target
4xx (client errors)	Does not index; previously indexed URLs will be removed;429 is an exception(treated as server overload)
5xx (server errors)	Temporarily reduces crawl rate; existing index is retained for a period but will eventually drop; gradually recovers after returning to 2xx

5.2 Key individual code semantics

Code	Meaning	Google behavior
`200`	OK	Enters indexing pipeline (indexing not guaranteed)
`201 / 202`	Created / Accepted	Same as 200; 202 waits for content (timeout varies by UA)
`204`	No content	No content, skipped
`301`	Moved permanently	Strong signal: redirect target should be treated as canonical
`302 / 303 / 307`	Found / See other / Temp redirect	Weak signal: redirect target should be processed, but canonical is not changed
`304`	Not modified	Content unchanged (uses the last crawled version); indexing signals may be recalculated
`308`	Moved permanently	Equivalent to 301
`400 / 401 / 403 / 404 / 410 / 411`	Various client-side errors	Removed from index(crawl frequency gradually decreases)
`429`	Too many requests	When server overload(not counted as the same category as 4xx), temporarily slows crawl rate
`500 / 502 / 503`	Server error	Temporarily reduce crawl rate, content remains in the index but will drop out over time

5.3 ⚠️ Critical rules

❌ Do not use 401 / 403 for rate limiting — they do not affect crawl rate. For rate limiting, use reduce crawl rate
✅ 301 vs 308 / 302 vs 307 are treated the same by Google, but their semantics differ; choose the correct one so other clients (e-readers / other search engines) can also interpret it correctly
⚠️ If 2xx content looks like an error page(blank page / error message) → Search Console reports soft 404

Part 6 — 5 Redirect types + implementation

6.1 Type comparison

Type	Permanent/Temporary	Google's perspective	Notes
`HTTP 301`	Permanent	Strong signal, target treated as canonical	Preferred option
`HTTP 308`	Permanent	Equivalent to 301
`meta refresh (0s)`	Permanent	Equivalent to 301	Use only when server-side implementation is not possible
`HTTP refresh (0s)`	Permanent	Equivalent to 301
`JavaScript location`	Permanent	Equivalent to 301,but lost if rendering fails	Last resort, carries risk
`Crypto redirect`	Permanent	May be recognized (like the Loch Ness Monster, disputed)	Use only when there is absolutely no other option
`HTTP 302 / 303 / 307`	Temporary	Followed but canonical does not change	Short-term downtime / maintenance
`meta refresh (>0s)`	Temporary	Equivalent to 302
`HTTP refresh (>0s)`	Temporary	Equivalent to 302

Search result differences between permanent vs temporary:

Permanent: search results show the new URL
Temporary: search results still show the old URL(the target may also be indexed if there are other canonical signals)

6.2 Server-side redirect implementation

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(simple mod_alias):

# 永久
Redirect permanent "/old" "https://example.com/new"
# 临时
Redirect temp "/two-old" "https://example.com/two-new"

For complex cases use 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;     # 临时
}

For complex cases use 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 implementation

<!-- 永久(0 秒) -->
<meta http-equiv="refresh" content="0; url=https://example.com/newlocation">

<!-- 临时(5 秒后跳)-->
<meta http-equiv="refresh" content="5; url=https://example.com/newlocation">

Or place in HTTP header:

HTTP/1.1 200 OK
Refresh: 0; url=https://www.example.com/newlocation

6.4 JavaScript redirect (last choice)

<script>
  window.location.href = "https://www.example.com/newlocation";
</script>

⚠️ Google must render successfully to see the JS redirect.Lost if rendering fails.

6.5 Crypto redirect (only when there is no other way)

<a href="https://newsite.example.com/newpage.html">We moved! Find the content on our new site!</a>

Google May be recognized as a fake redirect,most other search engines will not recognize it.

6.6 Alternate name concept

After a URL redirect, Google tracks both old + new. One is canonical, the other becomes alternate name. When a user's query shows stronger trust in the old URL, Google may still show the old URL. This is normal; it will naturally fade as users get used to the new domain,no action needed.

Part 7 — Site Move A: Change hosting / CDN (URLs unchanged)

7.1 4-step method

Prepare new infrastructure
Launch(change DNS)
Monitor traffic
Shut down old infrastructure

7.2 Key preparations

Copy + test: Move the full set of files / DB to the new host, run complete functional tests
Restrict access to the test environment via IP + noindex to prevent accidental indexing
Temporary hostname(beta.example.com) to test reachability for Googlebot, use noindex to prevent indexing
Search Console Use URL Inspection to test whether Googlebot can reach the new infrastructure
Do not let firewall / DDoS protection block Googlebot — go through verify Googlebot
Lower DNS TTL to a few hours one week in advance → ISP caches update faster during DNS switch
Search Console verification file Do not forget to bring it to the new infrastructure (HTML file or meta tag or GA snippet)

7.3 Post-launch actions

Remove temporary blocks(robots.txt disallow / noindex)
Change DNS to point to the new infrastructure
Check logs: traffic on old host drops + traffic on new host rises
ISP DNS updates across regions Use public DNS check tools
Check Index coverage in Search Console

7.4 Googlebot crawl rate behavior

After the new host goes live,crawl rate will drop in the short term, then steadily recover,and may become higher than before. This is normal, as Google re-evaluates signals for the new infrastructure.

7.5 Shutting down the old host

Shut down when old host logs show traffic reaching 0.

Part 8 — Site Move B: Change URLs (domain change / HTTP→HTTPS / path changes) ⭐⭐⭐

8.1 5-step method

General best practices
Prepare the new site
Prepare URL mapping(old → new)
Launch(enable redirects)
Monitor

8.2 General best practices

Split into small steps: For large sites, move a small section first to test, then do batches (choose small sections with few changes / not frequently affected)
Change only one thing at a time — do not change domain + CMS + layout simultaneously,do it in batches
Migrate during low-traffic periods — use seasonal / weekday low points if available
Expect ranking fluctuations — a few weeks for medium sites, longer for large sites
301 does not lose PageRank — do not worry about link credit
Use Search Console extensively — Index Status / Sitemaps report
Be patient: Googlebot has to visit each URL on both old and new sites,completing this URL by URL

8.3 Prepare the new site (details)

Using the same CMS is best, to avoid multiple variables
Move downloadable files such as images / PDFs (they may also have SEO traffic)
HTTP→HTTPS: Configure TLS certificate
Configure new robots.txt(note: disallow rules used during the dev stage must be removed)
Deleted / merged content: the new site should return the correct 404 or 410
Search Console:
- Verify all variants(www.example.com / example.com / HTTP / HTTPS)
- Disavow file: If the old site had them,re-upload to the new site's Search Console
- Check that the new domain is clean: Check Manual Actions / Removed URLs (to prevent legacy issues left by the previous owner)
Server capacity: During migration Google will crawl more aggressively than usual(crawling redirected old URLs + new URLs simultaneously) — for large sites, contact your hosting provider to give advance warning

8.4 Prepare URL mapping

Channels for finding old URLs:

Sitemap
Server logs (look at recently accessed URLs)
Analytics software (high-traffic URLs)
Search Console Links to your site(prioritize URLs with external backlinks)
CMS content list
Include embedded resources: images, videos, JS, CSS (these also need redirects)

Build mapping: DB or URL rewriting rules.

Prepare each URL on the new site with:

self-referential rel=canonical using the new URL
hreflang annotations update to new URLs
New sitemap(listing new URLs)+ Old sitemap(listing old URLs)— keep both, submit them in Search Console to track indexing progress for each separately

8.5 Redirect strategy

Server-side permanent redirects are preferred(301/308)
Avoid redirect chains — Google follows up to 10 hops,recommended ≤3, never exceed 5. Chains slow down users, and some clients do not support long chains
Avoid irrelevant redirects — do not redirect a bunch of old URLs all to the new homepage; this will be treated as soft 404. Only use many-to-one redirects when content is truly merged into the new page
Small to medium sites: Migrate all at once
Large sites: Migrate in batches

8.6 Launching the migration

Enable redirects(modify server config / CMS)
Confirm all rel=canonical on the new site point to new URLs + remove migration noindex tags
Test redirects: URL Inspection + batch testing via command line
Submit the Change of Address tool for the old site in Search Console(Note: For HTTP→HTTPS it is not needed Change of Address)
Keep redirects for at least 1 year(ideally permanently — for user experience + to wait for all external links to convert)
Submit the new sitemap for the new site

8.7 Update links immediately after launch

Internal links: Update all internal links to new URLs according to the mapping
External links: Contact high-traffic sites that link to you and ask them to update the links
Profile links(Facebook/Twitter/LinkedIn)
Ad campaigns update landing pages

8.8 Monitoring

Sitemaps report: Index count for the old sitemap will gradually drop to 0, new sitemap will rise;redirect warnings for the old sitemap can be ignored(expected)
Index Coverage: Old site index count drops / new site rises; regularly check for unexpected crawl errors
Search queries: Query impressions and clicks gradually appear for the new site

8.9 5 common migration mistakes

Mistake	Consequence	Fix
Forgetting to remove migration `noindex` / `robots.txt block`	New site is not indexed at all	Check robots.txt + URL Inspection
Redirects point to non-existent new URLs	Large number of 404s	Search Console "Not found" report / crawl with Screaming Frog
Other crawl errors	Indexing interruption	Check Index Coverage report for spikes
Insufficient server capacity	Crawl overload / server crash	Scale up capacity in advance + contact hosting
Sitemap not updated to new URLs	Google cannot discover new URLs	Update and resubmit

8.10 Recommended resources

Aleyda Solis' site migration checklists — checklist from industry SEO experts
Screaming Frog — site migration tool

Part 9 — Temporary business closure / Pause Online Business ⭐

9.1 Decision tree

预期停业多久?
├─ 几小时到几天 → "限制功能"(强烈推荐)
├─ 1-2 天(服务器层面挂)→ 503 + Retry-After
├─ 几周以上 → 仍走"限制功能"
└─ 永久 → 走 site move 或 remove information

9.2 Recommended: Limit functionality (do not shut down completely) ⭐

Measure	How to do it
Disable shopping cart	Simplest option — Search visibility remains unchanged
Add banner / popup to indicate status	Must include `data-nosnippet` to avoid appearing in search result snippets. Comply with intrusive interstitials guideline
Modify structured data	Product `availability` change `OutOfStock` / Event change to `cancelled` / update LocalBusiness opening hours
Update Merchant Center feed	Go through availability attribute best practices
Tell Google you made changes	Single-page changes: request recrawl via URL Inspection; bulk changes: resubmit sitemap

9.3 ⚠️ Not recommended: Shut down the entire site (severe side effects)

Customers cannot find you → reputation declines
Third-party information (which may be inaccurate / incomplete) fills the vacuum
Knowledge Panel loses phone number / logo
Search Console verification fails → lose all data
After going back online, reindexing is long and uncertain — how long it takes to recover to the original state is uncertain

9.4 If you really must shut down → 503 + best practices (for less than a few days)

HTTP/1.1 503 Service Unavailable
Retry-After: <date or seconds>
Mime-Version: 1.0
Content-Type: text/html

Must-do:

robots.txt must still return 200(cannot return 503! A 503 on robots.txt will block all crawling)
curl -I -X GET "https://www.example.com/" local verification
Use Retry-After HTTP header to provide a best-effort time estimate
Static HTML + inline CSS + base64 images to reduce load
Give users clear guidance: when you will be back / contact information

Don'ts:

❌ Use 403 / 404 / 410 (URL gets removed)
❌ Add noindex (URL gets removed)
❌ Use Search Console Removals tool (users cannot find you at all)
❌ Full Disallow in robots.txt (equivalent to being removed)
❌ Return 503 for robots.txt

9.5 What if closure lasts more than a few days?

Return 200 placeholder page (hosting official information),Do not use 503.

9.6 Short-term emergency: hide from Search

→ Temporary removal via Removals tool. temporary, valid for ~6 months.

9.7 Temporarily lower crawl rate

Googlebot is crawling too aggressively and slowing down the server → reduce crawl rate. Remember to set a reminder to reset it later.

9.8 ⚠️ Do not block a specific region

Google usually crawls from the US. Blocking the US = blocking all of Google Search.

9.9 ⚠️ Do not use the Removals tool to remove out-of-stock products

Users should be able to see the "out of stock" information — using Removals directly will make people completely unable to find that product and think the company no longer exists.Mark with OutOfStock structured data, keep the page.

Part 10 — Ask Google to Recrawl

10.1 A few URLs: URL Inspection tool

URL Inspection → Request Indexing.

Prerequisite: You are a Search Console owner or full user. There is a quota limit,Repeating requests for the same URL will not speed things up.

10.2 Large numbers of URLs: Sitemap

1. 建 sitemap 列所有要重爬的 URL
2. Search Console submit
3. Google 按自己节奏爬,几天到几周不等

10.3 Notes

Crawling may take several days to several weeks
Monitor using the Index Status report or URL Inspection
Requesting a crawl ≠ guaranteed indexing(Google prioritizes indexing high-quality content)
Using a hosted CMS (Blogger / WordPress) usually submits automatically, no action needed from you

Part 11 — Collection of 14 anti-patterns

#	Anti-pattern	Consequence
1	Using robots.txt as a canonical tool	Completely ineffective
2	Using the URL Removals tool as a canonical tool	Hides all versions, goes too far
3	Using noindex as a canonical tool	The entire page is blocked, not selecting the preferred version
4	Sitemap lists A, rel=canonical points to B	Which one Google chooses is unpredictable
5	rel=canonical points to a URL fragment(`#xxx`)	Google does not support fragments
6	rel=canonical is inside `<body>`	Google does not accept it
7	Using relative URLs as canonical	Breaks when the test site is crawled
8	Using the Change of Address tool for HTTP→HTTPS migration	Not needed, that tool is for changing domain names
9	redirect chain > 5 hop	Slow for users + some clients do not support it
10	Redirecting a whole bunch of old URLs to the new homepage	Treated as soft 404
11	Returning 403/404/410 or adding noindex during temporary business closure	URL Removed from index, recovery is extremely slow
12	robots.txt also returns 503 during a 503 temporary business closure	Blocks all crawling, catastrophic
13	Using 401/403 for rate limiting	Does not affect crawl rate; you should use the reduce crawl rate tool
14	Repeating URL Inspection recrawl requests to try to speed things up	Wastes quota,repetition is ineffective

Part 12 — Related wiki

Why canonical matters — helps Google aggregate signals: Google SEO Basics + How Search Works + Search Essentials indexing phase
Multilingual: Complete Guide to Internationalization (hreflang/Multilingual/Multiregional) + Explicit Content (SafeSearch/Adult)(upcoming wiki)
How to write a Sitemap: Sitemap Complete Guide (XML / RSS / Text + image / video / news / hreflang extensions + sitemap index)
noindex / robots.txt details: Complete Guide to Crawling and Indexing Control (robots.txt / noindex / X-Robots-Tag / data-nosnippet / rel)
Checking migration results in Search Console: How to Use the Search Console + Analytics + Trends Trio (Traffic Diagnostics / Keyword Research / Looker Studio) Performance + Index Coverage
How to mark canonical for AMP variants: upcoming amp wiki (the 4 AMP articles in this repository may be consolidated later)
Details on removing indexed content: Complete Guide to Security / Spam / Removal / Search Operators (malware + phishing + UGC + redacted + site:)(upcoming wiki)

Last updated

2026-05-17 — Compiled based on Google Search Central's 9-part crawling-indexing series (latest from 2025-12 to 2026-04). 301-redirects updated 2026-04 including detailed explanation of alternate name. Full coverage of HTTP status codes + latest best practices for 503 temporary business closure.