metrotechs domain migration banner oneline

When you rebrand, your new domain should inherit your hard-won search equity—rankings, links, and trust—not start from zero. When we moved Metrotechs.net → Metrotechs.io, we did two key things:

  1. told Google about the move using its official tool, and

  2. set up clean, site-wide 301 redirects from every .net URL to its .io twin.

Result: the .io domain picked up the same authority signals the .net had, and our search performance held steady.

Below is the exact playbook we use for domain migrations so your rebrand preserves (and often improves) SEO.


Why this matters

Search engines “learn” your site through links, crawl history, and user signals. If you change domains without the right signals, Google can treat the new site as unrelated—causing rankings and traffic to dip (sometimes hard). Using the official Change of Address process and permanent redirects tells Google to consolidate signals to the new home.


The 10-Step Domain Migration Playbook

1) Prep the new domain (before flipping the switch)

  • Mirror your old URL structure wherever possible—same paths, same content, same internal links. Big structural changes + a domain move = unnecessary volatility.

  • Verify the new domain in Search Console (keep the old verified too).

  • Make sure robots.txt, canonical tags, hreflang, and analytics are ready for the new host. If you used a disavow file on the old site, re-upload it to the new property.

2) Map every old URL to its new URL

  • Best case: one-to-one mappings (wildcard works when paths stay identical).

  • Include media files (PDFs, images, JS/CSS) and high-value legacy URLs.

3) Implement server-side 301 redirects (no chains)

  • A 301 is a permanent move and a strong canonical signal. Google treats 3xx redirects as strong signals for which URL to index.

  • Don’t chain redirects (old → interim → new). Go old → new directly.

Apache (.htaccess)

RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www\.)?old-domain\.net$ [NC]
RewriteRule ^(.*)$ https://new-domain.io/$1 [R=301,L]

Nginx

server {
listen 80;
server_name old-domain.net www.old-domain.net;
return 301 https://new-domain.io$request_uri;
}

4) Update canonicals, hreflang, and internal links

  • Every page should self-canonicalize to its new URL. Update hreflang clusters to the new hostnames. Update all internal links to avoid internal 301s.

5) Submit new XML sitemaps & keep the old ones briefly

  • Submit a sitemap of new URLs to speed discovery. Keep an old-URL sitemap online for a short window to help Google see the redirects.

6) Tell Google you moved (the official way)

  • In Search Console for the old domain, use Change of Address and point it to the new domain. This forwards various signals and prioritizes crawling/indexing of the new site for ~180 days.

7) Monitor like a hawk

  • Watch Search Console’s Index Coverage, sitemaps, and URL Inspection.

  • Expect some temporary fluctuation; medium sites often settle in a few weeks (larger sites take longer). Ensure your new host can handle the extra crawl load.

8) Keep redirects in place long enough

  • Minimum: 180 days (per Google’s tool window). Better: keep 301s for at least a year to catch stragglers and external links you don’t control.

9) Update the ecosystem

  • High-value backlinks (ask partners to update), social profiles, business listings, email signatures, ad URLs, and data feeds.

10) Validate the end state

  • Spot-check top URLs with curl -I or a crawler:

    • old URL → 301 to the exact new URL

    • new URL → 200, correct canonical to itself

    • no redirect loops or mixed content


Common mistakes that tank migrations

  • Combining a replatform/rebuild + domain move at once. Change one big thing at a time.

  • Redirect chains and hop-by-hop delays. Always old → new directly.

  • Leaving internal links pointing to old URLs. It wastes crawl budget and muddies canonical signals.

  • Skipping the Change of Address step. It’s an extra, trusted signal to Google.


Do redirects “lose PageRank”?

No. Google’s documentation states that 301/302 and other server-side redirects don’t cause a loss in PageRank. That myth is long dead.


Quick checklist (save this)

  • New domain verified in GSC; analytics & tags deployed

  • URL map complete (includes media files)

  • Server-side 301 redirects live (no chains)

  • Canonicals, hreflang, internal links updated

  • New sitemap submitted; old sitemap temporarily accessible

  • Change of Address filed in GSC (old → new)

  • Crawl, index, errors, and traffic monitored weekly

  • Keep redirects ≥ 180 days (ideally 1 year)

  • Update top backlinks and brand listings


A quick Metrotechs case study: .NET → .IO

During our rebrand, we moved from Metrotechs.net to Metrotechs.io. We:

  • verified both domains in Search Console,

  • launched one-to-one 301s,

  • submitted a fresh sitemap, and

  • filed a Change of Address.

Third-party authority metrics (e.g., “domain rating/authority”) followed as signals consolidated, and our rankings held steady—illustrating what a clean migration can do.


Bonus: If you absolutely can’t redirect

In rare cases where server-side redirects aren’t possible (legacy hosting, contractual limits), a cross-domain canonical can help consolidate signals between highly similar pages—but redirects are stronger and preferred whenever you can use them.


Need help planning your move?

Metrotechs handles domain migrations end-to-end: audit and URL mapping, redirect engineering, Search Console setup, and post-move monitoring. If you’re rebranding, let’s make sure your new name keeps all your old momentum.


Sources & further reading

  • Google: Change of Address—how and when to use it, 180-day window and best practices. Google Help

  • Google: Site moves with URL changes—planning, mapping, redirects, monitoring; redirects don’t lose PageRank. (Updated Mar 6, 2025.) Google for Developers

  • Google: Redirect types & canonical signals—how Google interprets redirects. Google for Developers

  • SEJ: Keep 301s for at least a year (practical guidance echoed by Googlers). Search Engine Journal