Ch 16 — Redirects & site moves¶

Part VI — Change events · The Technical SEO Reference

Playbook coupling: seo-checklist.md covers this in the migration playbook (line 223: redirect map, 1-year retention, dual GSC verification, Change of Address, canonical/sitemap updates) plus scattered items (redirect chains, line 100; host consolidation, line 86). This chapter is the canonical home of the redirect taxonomy and the full migration machinery: how Google interprets every redirect type, what redirects do inside canonicalization, the Change of Address tool's exact mechanics and 180-day clock, hosting/CDN moves, A/B testing rules, and planned downtime.

A redirect is a canonicalization signal wearing an HTTP costume. Google's pipeline asks two questions of every redirect: permanent or temporary? (which decides whether the target or the source should be canonical) and how confident can I be in interpreting it? (which ranks server-side above meta refresh above JavaScript). Every migration rule in this chapter derives from those two questions plus one fact practitioners underrate: Google remembers both URLs.

16.1 The redirect taxonomy¶

From the redirects doc (2026-04-14) and the HTTP status doc — all 🟢:

Type	Google's interpretation	Notes
301, 308	Permanent: "the indexing pipeline uses the redirect as a signal that the redirect target should be canonical." SERPs "show the new redirect target"	308 "Equivalent to 301" — semantically different (📘 RFC 9110: 308 forbids method change); "use the status code that's appropriate… so other clients may benefit"
302, 303, 307	Temporary: "the indexing pipeline doesn't use the redirect as a signal that the redirect target should be canonical." SERPs "show the source page"	307 "Equivalent to 302"; ⚠️ real-world 307s are usually browser-synthesized HSTS upgrades, not server responses (📘)
Meta refresh, 0s	"interprets instant meta refresh redirects as permanent"	head or HTTP header placement
Meta refresh, delayed	"interprets delayed meta refresh redirects as temporary"
JavaScript redirect	Works, last-resort-but-one: "Only use JavaScript redirects if you can't do server-side or meta refresh redirects… if you set a JavaScript redirect, Google might never see it if rendering of the content failed" (→ Ch 6)
"Crypto" redirect	A "We moved!" link — Google's own doc: "(like the Loch Ness monster, its existence may be disputed…)". "Don't rely on crypto redirects… unless you have no other choice"

🟢 The ordering doctrine: methods are "ordered by how likely Google is able to interpret correctly (for example, a server side redirect has the highest chance)." Signal-strength wording: a 301 is "a strong signal that the redirect target should be processed"; a 302 "a weak signal."

16.2 What a redirect does inside canonicalization¶

🟢 In the documented canonicalization signal hierarchy, redirects come first: "Redirects: A strong signal that the target of the redirect should become canonical" — ahead of rel=canonical annotations (→ Ch 8, the hierarchy's home).
🟢 ⚠️ Google remembers both URLs. "Google keeps track of both the redirect source (the old URL) and the redirect target (the new URL). One of the URLs will be the canonical." The non-canonical one becomes an "alternate name": "Alternate names may appear in search results when a user's query hints that they might trust the old URL more… if you moved to a new domain name, it's very likely that Google will continue to occasionally show the old URLs in the results, even though the new URLs are already indexed. This is normal." Old URLs surfacing weeks after a move is the single most misdiagnosed migration "failure" — it is documented behavior, not signal loss.
🟢 PageRank, settled in Google's own words: "Don't worry about link credit. 301 and other permanent redirects don't cause a loss in PageRank." The "redirects leak ~15%" figure is dead lore.
🟢 Content on a redirecting URL is ignored ("the final target URL's content is processed instead"); permanent-redirect consolidation is the fastest of the canonical methods ("For the quickest effect, use HTTP (also known as server-side) redirects").
🟢 Legitimate temporary use: outage/unavailable-service pages "without compromising the original URL in search results."

16.3 Chains and hops¶

🟢 "By default, Google's crawlers follow up to 10 redirect hops. However, specific products' crawlers may have different limits… Google Inspection Tools doesn't follow redirects." ⚠️ That last clause is a diagnosis trap: URL Inspection shows the redirect response itself; chain-end testing needs curl -IL or a crawler (Google's own advice: "command line tools or scripts to test large numbers of URLs").
🟢 Chains cost crawl, they don't draw penalties: "Avoid long redirect chains, which have a negative effect on crawling." ⚪ The playbook's "≤1 hop" is our tightening — migration maps should go direct old→new. (→ Ch 2 crawl-budget mechanics.)

16.4 The spam boundary: sneaky redirects¶

🟢 From the spam policies: "Sneaky redirecting is the practice of doing this maliciously in order to either show users and search engines different content or show users unexpected content that does not fulfill their original needs." The two named violation patterns: search-engines-vs-users divergence, and "showing desktop users a normal page while redirecting mobile users to a completely different spam domain" (⚠️ the classic hacked-site symptom — injected mobile-only redirects → Ch 17). The explicit safe harbor: "Moving your site to a new address. Consolidating several pages into one. Redirecting users to an internal page once they are logged in." The test "is intent… to deceive." A Sneaky Redirects manual action exists (→ Ch 18).

16.5 Site move WITHOUT URL changes (hosting / server / CDN)¶

From the no-URL-changes doc (2025-12-10) + the Crawling December CDN post — all 🟢:

Stage safely: test on a temporary hostname (beta.example.com) with noindex so it can't leak into the index (→ Ch 7 §7.10's staging patterns).
DNS: "lowering the TTL to a conservative low value (for example, a few hours) at least a week in advance."
Firewall/DoS check: "Make sure it does not block Googlebot's ability to reach the DNS or the hosting provider's servers" (→ Ch 4).
Expect the documented crawl-rate signature: "it's normal to see a temporary drop in Googlebot's crawl rate immediately after the launch, followed by a steady increase over the next few days, potentially to rates that may be higher than before" — crawl-rate signals reset with the hosting change. Don't diagnose the dip as a problem.
CDN specifics: CDN-backed sites earn higher crawl capacity ("inferred from the IP address of the service"); ⚠️ but first crawls hit a cold cache — "your origin server will still need [to] serve that URL at least once… the crawl rate will likely be high for a few days; keep that in mind if you're planning to launch many URLs at once." ⚠️ WAF blocklists catching Googlebot "may prevent your site from showing up in search results" — allowlist via the published IP ranges (→ Ch 5 §5.4); bot-check interstitials should serve crawlers a 503 so "content is not removed from Google's index automatically."
Decommission only when logs show nobody — including Googlebot — hits the old infrastructure.
⚠️ No Change of Address for this move type — explicitly excluded by the CoA help.

16.6 Site move WITH URL changes — the full playbook¶

From the site-move doc (2026-06-17) — all 🟢. Scope: HTTP→HTTPS, domain changes/merges, and path changes.

Prepare: URL inventory (sitemaps, analytics, logs, GSC); redirect map old→new, one hop; save a pre-move benchmark ("a sitemap file containing the new URLs in the mapping… a list of sites linking to your old URLs"). Verify all variants of both sites in GSC (www/non-www × http/https — a Domain property covers them).

The rules that carry the migration: - Retention: "Keep the redirects for as long as possible, generally at least 1 year… From users' perspective, consider keeping redirects indefinitely." ⚠️ Reconcile with the CoA's 180-day machinery (§16.7): 180 days is the tool's signal-forwarding window ("Maintain the redirects for at least 180 days--longer if you still see any traffic"); 1 year is the doc's signal-transfer floor. Teach the stricter: redirects live ≥1 year, ideally forever. - Dropped content: URLs not moving "correctly return an HTTP 404 or 410." - ⚠️ The homepage-dump trap: "Don't redirect many old URLs to one irrelevant single URL destination, such as the home page… might be treated as a soft 404." Exception: genuinely consolidated content may redirect many→one. - Sizing: small/medium sites move "all URLs… simultaneously"; large sites "one section at a time." - New-site hygiene: self-referencing canonicals on every new URL; hreflang annotations updated to new URLs (→ Ch 11 — stale hreflang pointing at redirecting URLs breaks clusters); submit the new sitemap ("At this point you can remove your old sitemap"); transfer images/PDFs ("These might already be getting traffic"). - Links: update internal links immediately; contact top external linkers; update profiles/campaigns. - Timing & expectations: move in traffic dips; "Expect temporary fluctuation… a medium-sized website can take a few weeks for most pages to move in our index; larger sites can take longer." Site moves also "trigger an increase in crawl demand." - Old-property housekeeping: re-upload any disavow file under the new property; on purchased domains check leftover manual actions and ⚠️ "any URL removals left over from the previous owner, especially a site-wide URL removal" (a classic invisible killer on acquired domains). - ⚠️ Stale-doc alert (V0-verified live): the doc still instructs "Set the crawl rate to 'Let Googlebot determine'" — referencing the crawl-rate limiter retired January 8, 2024 (§16.9). Ignore that line; it's a Google documentation leftover.

16.7 GSC Change of Address — exact mechanics¶

From the CoA help — all 🟢: - What it does: "tells Google to emphasize crawling and indexing your new site over crawling your old site… forwards various signals from the old site to the new site, and tells Google to prefer the new site over the old when determining canonical pages. These actions continue for 180 days." After that, "Google does not recognize any relationship between the old and new sites." - Sequencing: "Use this tool after you've moved and redirected your site" — 301 from old homepage (and recommended: old canonical pages); the tool pre-checks ownership + spot-checks 301s. - Eligibility matrix: domain-level properties only (no path-level sources); ⚠️ "does not move any subdomains below the specified domain (including www)" — each subdomain migrates as its own property; moves all protocols; domain→path destinations allowed (example.com → example3.com/new/location/). Same Google account for both. - Excluded: HTTP→HTTPS ("Google will figure out your changes for you"), path-to-path, www↔non-www ("use canonical tagging and/or redirects"), hosting/CDN moves. - ⚠️ Jun 17, 2026 doc addition: "make sure to use this tool for all subdomain variants of the old domain, including www and non-www… Ensure that you have all of these variants verified in Search Console" — verify them all first. New requirement; older checklists miss it. - Consolidations: "Try not to combine multiple moves to a single location… move sites one at a time… and wait till traffic stabilizes." No chaining ("you can't immediately submit another change of address from site B to site C"). Cancellable for 180 days (reverse the redirects, then Cancel Move). - The old site is not purged: old URLs "can continue to be shown… if they are available and don't have an equivalent page on the new site." Keep paying for the old domain "for at least a year to prevent others from buying and using your abandoned domain for malicious purposes" (⚠️ expired-domain-abuse feedstock — playbook ⛔).

16.8 Move-plus-redesign, HTTPS specifics, A/B testing¶

🟢 ⚠️ Never combine a move with a redesign: "keeping the same site architecture in the new location helps to pass the signals more directly… If you combine a site move with a redesign of the site's content and URL structure, you will probably see some traffic loss as Google might need to relearn and reassess the individual pages." Google twice: "do them one at a time." 🟡 Illyes (SERPConf, Apr 2024, via SEJ): prolonged migration ranking damage "shouldn't happen" — report it to Google.
🟢 HTTPS migration is formally a site move with URL changes, minus CoA; get TLS certs configured, follow every other step (redirect map, canonicals, sitemaps, 1-year retention). HSTS/mixed-content hardening → Ch 17. Sold as security + best practice, never as a ranking play (→ Ch 15 §15.6).
🟢 A/B testing rules (website testing doc): no cloaking ("whether you do it by server logic or by robots.txt, or any other method"); variant URLs get rel=canonical to the original, not noindex ("noindex… can sometimes have unexpected bad effects"); test redirects are 302s, "not a 301 — this tells search engines… they should keep the original URL in their index"; ⚠️ duration matters: "If we discover a site running an experiment for an unnecessarily long time, we may interpret this as an attempt to deceive search engines and take action"; cookie-bucketed tests: "Googlebot generally doesn't support cookies" — it sees the no-cookie variant (→ Ch 6 §6.2).

16.9 Planned downtime¶

From the pause-your-business doc + HTTP status doc + crawl-rate reduction doc — all 🟢:

The decision tree: best = stay online with limited functionality (disable carts, banner, adjust structured-data availability). Urgent 1–2 days = 503 with an informational error page. Longer closure = indexable placeholder homepage with 200 — "Completely closing a site even for just a few weeks can have negative consequences."
⚠️ What 503 freezes: "it's not possible for Google's systems to refresh titles, descriptions, metadata, or structured data… if a page returns a 503."
⚠️ robots.txt must never 503: "Don't return a 503… for the robots.txt file because this blocks all crawling" (→ Ch 3's availability matrix). Serve Retry-After; make the 503 page static with inlined resources.
Error-driven throttling mechanics: "5xx and 429 server errors prompt Google's crawlers to temporarily slow down… already indexed URLs are preserved in the index, but eventually dropped"; the slowdown is host-wide and "proportionate to the number of individual URLs… returning a server error"; persistent per-URL errors ("multiple days") → dropped from the index. Deliberate throttling during overload: serve 500/503/429 for "a couple of hours, or 1-2 days" at most.
⚠️ There is no dashboard throttle anymore: the GSC Crawl Rate Limiter died Jan 8, 2024 — server responses (and the errors above) are the only crawl-rate control. And never use the Removals tool or noindex for a temporary closure ("This will remove the website's URLs from Google Search").

16.10 Monitoring a migration¶

🟢 The healthy-move signature: sitemap crossover ("Initially, the sitemap containing the new URLs would have zero pages indexed… Over time the number of pages indexed from the old URLs sitemap would drop to zero with a corresponding increase" on the new); index-coverage graphs falling old / rising new; for hosting moves — server logs on both ends, public DNS checkers, coverage graphs. ⚠️ Old URLs in SERPs weeks later = alternate names (§16.2), not failure; escalate only if old URLs dominate the same queries after settling. Traffic-drop attribution during/after moves → Ch 21 (site moves are a named cause in Google's debugging doc; segment old vs new properties, never read one alone).

Symptoms & diagnosis¶

Symptom	Likely cause	Where
Old domain still showing in SERPs post-move	Documented alternate-names behavior — normal	§16.2
Mass "Soft 404" statuses after migration	Homepage-dump redirects of dropped content	§16.6
Traffic loss after a "perfect" migration	Move combined with redesign/architecture change	§16.8
Rankings dropped ~6 months after move	CoA window expired while redirects were removed early	§16.7, §16.6
URL Inspection "shows" the redirect but not the destination	Inspection tools don't follow redirects — by design	§16.3
Mobile users redirected to spam domain	Hacked-site sneaky redirect — incident response	§16.4, Ch 17
Crawl rate collapsed after hosting move	Normal dip-and-recover; check firewall/WAF only if it persists	§16.5
Site vanished during maintenance	noindex/Removals used for downtime instead of 503/placeholder	§16.9
Metadata stale for weeks	Long-running 503s freezing refresh	§16.9
Acquired domain won't index	Leftover site-wide URL removal or manual action from previous owner	§16.6

Sources¶

All fetched 2026-08-04 (research corpus + V0; V2 re-fetches all): - Redirects and Google Search (2026-04-14) - Site move with URL changes (2026-06-17) · Site move, no URL changes (2025-12-10) - Change of Address tool · HTTP status codes - Crawling December: CDNs (2024-12) · Crawl-rate limiter retirement (2023-11) · Reduce crawl rate - Website testing · Pause your online business · Spam policies (sneaky redirects) · Consolidate duplicate URLs (2026-07-10) · Crawl budget (2026-07-22) - 🟡 Illyes on migration damage (SERPConf Apr 2024, via SEJ). V0-verified: the stale crawl-rate instruction in the site-move doc; the Jun 17, 2026 all-variants CoA addition. - V2 note (2026-08-04): all doc/help-center quotes above re-verified live; the Crawling December CDN post's quotes could NOT be re-checked (blog body is SPA-rendered, unfetchable to extractors) — they stand on the drafting-era fetch.