Paano mag-migrate ng domain nang hindi bumabagsak ang iyong search rankings

Ang pagpapalit ng domain ay isa sa iilang SEO project kung saan ang isang teknikal na maliit na pagkakamali ay maaaring maging napakakita agad. Ang nawawalang redirect, naka-block na crawl path, o nakalimutang canonical ay maaaring gawing ilang linggo ng ranking volatility ang isang simpleng rebrand.

Normal ang kaunting paggalaw. Kailangan ng oras ng mga search engine para i-crawl ang mga lumang URL, matuklasan ang mga redirect, iproseso ang mga signal, at maayos na mailagay ang bagong domain sa index. Ang layunin ay hindi iwasan ang bawat pagbaba. Ang layunin ay gawing boring ang migration: isang lumang URL ang tumuturo sa isang katumbas na bagong URL, malinaw ang tugon ng server, at walang mahalagang nawawala.

Magsimula sa imbentaryo, hindi sa redirect rule

Ang pinakakaraniwang pagkabigo sa migration ay ang pagtrato rito bilang server configuration task. Hindi ito ganoon. Isa itong information architecture task na nagtatapos lamang sa server configuration.

Bago galawin ang DNS, gumawa ng listahan ng mga URL na mahalaga:

• Mga URL na tumatanggap ng organic traffic
• Mga URL na may external backlinks
• Mga URL na nagko-convert, bumubuo ng leads, o sumusuporta sa campaigns
• Mga canonical URL na kasalukuyang nasa iyong XML sitemap
• PDFs, images, at downloadable files na naka-link mula sa labas
• Mga high-value legacy URL na maaaring wala sa kasalukuyang navigation

Para sa bawat lumang URL, magtalaga ng destinasyon sa bagong domain. Sa karamihan ng kaso, ang destinasyong iyon ay dapat ang parehong page na may parehong intent. Kung ang /pricing ay magiging https://newdomain.com/pricing, simple iyon. Kung tatlong lumang product page ang pagsasamahin sa isang bagong guide, idokumento ang desisyong iyon nang sinasadya.

Iwasan ang tamad na pattern: i-redirect ang lahat papunta sa bagong homepage. Maginhawa ito, pero tinatapon nito ang relevance. Parehong inaasahan ng mga search engine at user na sasagutin ng destinasyon ang parehong pangangailangan gaya ng orihinal na URL.

Panatilihin ang URL structure kung kaya

Mas madali ang domain migration kapag nananatiling stable ang mga path. Ang paglipat mula oldsite.com/blog/example papuntang newsite.com/blog/example ay mas malinis kaysa sabay-sabay na pagbabago ng domain, CMS, slugs, folder structure, at content.

Minsan, hindi maiiwasan ang pagbabago ng URL dahil sa redesign o CMS migration. Kung ganoon, paghiwalayin ang mga desisyon:

1. Ano ang nagbabago dahil nagbabago ang domain?
2. Ano ang nagbabago dahil nagbabago ang site structure?
3. Ano ang dine-delete, pinagsasama, o muling isinusulat?

Habang mas marami kang variable na ipinapasok, mas mahirap i-diagnose ang mga problema kalaunan. Kung mahalaga ang migration at maganda ang performance ng kasalukuyang site, isaalang-alang munang ilipat ang domain at mag-redesign na lang pagkatapos.

Gumamit ng permanent, one-hop redirects

Para sa tunay na domain migration, gumamit ng server-side 301 o 308 redirects mula sa mga lumang URL papunta sa kanilang bagong katumbas. Ang temporary redirects ay para sa pansamantalang sitwasyon. Ang JavaScript redirects, meta refreshes, at soft redirects ay mas mahihinang signal at mas madaling masira.

Simple ang mga layunin ng iyong redirect:

• Bawat mahalagang lumang URL ay nagbabalik ng permanent redirect.
• Bawat redirect ay direktang papunta sa final destination.
• Malinis ang pag-redirect ng HTTP papuntang HTTPS.
• Consistent ang paghawak sa www at non-www variants.
• Hindi umaasa ang redirects sa marupok na query-string behavior maliban kung kinakailangan.

Ganito ang isang masamang chain:

http://oldsite.com/page → https://oldsite.com/page → https://www.oldsite.com/page → https://newsite.com/page → https://www.newsite.com/page

Maaaring makarating din iyon sa tamang page sa huli, pero mabagal ito, mas mahirap i-crawl, at mas malamang na magtago ng mga pagkakamali. Sikaping magkaroon ng isang hop mula sa bawat lumang variant papunta sa final new URL.

Kapag vine-validate ang behavior, inspeksyunin ang aktwal na HTTP responses sa halip na magtiwala sa ipinapakita ng browser. Kapaki-pakinabang dito ang aming guide sa pag-debug ng redirects at HTTP headers sa production dahil masyadong magalang ang mga browser: sinusundan nila ang chain at itinatago ang magugulong bahagi.

Ihanda ang DNS at certificates bago mag-launch

Hindi direktang naglilipat ng rankings ang DNS, pero ang masamang DNS ay maaaring magmukhang sira ang migration. Ibaba ang TTL values bago ang launch window para mas predictable ang propagation ng mga pagbabago. Kumpirmahing may tamang records ang bagong domain para sa web traffic, email, at anumang kinakailangang subdomains.

Kailangan mo rin ng valid TLS certificates para sa parehong domain. Madaling makaligtaan ito. Kailangan pa ring magsilbi ng HTTPS redirects ang lumang domain pagkatapos ng migration. Kung mag-expire ang certificate nito, maaaring makaranas ang users at crawlers ng browser warnings bago pa man sila makarating sa bagong site.

Kung maaapektuhan ng paglipat ang email, huwag itong ituring na pahabol na usapin. Madalas masira ng domain changes ang SPF, DKIM, DMARC, MX records, tracking links, at transactional mail. Para sa refresher sa mga record na mahalaga, tingnan ang aming developer-friendly guide sa MX, SPF, DKIM, at DMARC.

Suriin ang canonicals, internal links, at sitemaps

Pagkatapos ng launch, dapat kumilos ang bagong domain na parang ito na palagi ang canonical home ng content.

Ibig sabihin:

• Ang canonical tags ay tumuturo sa mga bagong URL, hindi sa lumang domain.
• Ang internal links ay gumagamit ng bagong domain o root-relative paths.
• Ang XML sitemaps ay naglalaman lamang ng final, indexable na bagong URLs.
• Ang hreflang annotations, kung ginagamit, ay tumutukoy sa mga bagong URL.
• Na-update ang Open Graph, structured data, at alternate links.
• Hindi bina-block ng Robots.txt ang mahahalagang section.

Huwag mag-publish ng sitemap na puno ng lumang URLs at asahang lilinisin ito ng redirects. Ang sitemap ay dapat listahan ng mga URL na gusto mong ma-index. Pagkatapos ng migration, ibig sabihin nito ay final URLs sa bagong domain.

Bantayan din ang canonical contradictions. Ang page na nagre-redirect mula luma papuntang bago pero may canonical na tumuturo pabalik sa lumang domain ay nagpapadala ng magkahalong signal. Karaniwang kaya ng mga search engine na lusutan ang ilang inconsistency, pero hindi mo dapat hingin iyon sa kanila.

Huwag baguhin ang lahat sa launch day

Malaki na ang isang migration bilang event. Kung maaari, iwasang isabay ito sa malalaking content pruning, template rewrites, navigation changes, JavaScript rendering changes, o bagong performance profile.

Hindi ito pamahiin. Disiplina ito sa debugging. Kung bumagsak ang rankings pagkatapos ng launch, kailangan mong malaman kung ang sanhi ay redirect mapping, crawl access, binagong content, mas mabagal na rendering, nawawalang structured data, o iba pa.

Panatilihing kasinglapit ng praktikal sa lumang site ang initial launch. Kapag stable na ang bagong domain, gawin ang mas malalaking editorial at design changes sa mas maliliit na batch.

Sabihin sa mga search engine kung ano ang nagbago

Sa Google Search Console, i-verify ang parehong luma at bagong domain. Pagkatapos, gamitin ang Change of Address tool kapag domain-level change ang paglipat at ang content ay lilipat sa bagong domain. Isumite ang bagong sitemap pagkatapos ng launch.

Hindi nito pinapalitan ang redirects. Sinusuportahan nito ang mga iyon. Kailangan pa rin ng mga search engine ng crawlable at persistent redirects para maunawaan ang URL-level mapping.

Para sa Bing at iba pang search engine, gamitin ang kanilang webmaster tools kung available. I-update din ang mga lugar na kontrolado mo: social profiles, business listings, ad destinations, email footers, documentation, partner links, at canonical references sa syndicated content.

Hindi maa-update ang lahat ng external links, at ayos lang iyon. Pero dapat ma-update ang pinakamahahalaga. Kung ang isang major partner, app marketplace, documentation portal, o press page ay naka-link sa lumang domain, humiling ng update.

I-monitor ang mga tamang bagay pagkatapos ng launch

Ang unang ilang araw pagkatapos ng migration ay dapat aktibong monitoring, hindi selebrasyon.

Suriin:

• Server logs para sa crawl activity sa luma at bagong domains
• 404s at hindi inaasahang 5xx errors
• Redirect chains at loops
• Indexing status sa Search Console
• Sitemap discovery at processing
• Organic landing pages at query patterns
• Conversion paths na umaasa sa lumang URLs
• Analytics filters at referral exclusions

Asahan ang ingay sa reporting. Itinuturing ng ilang analytics tools ang bagong domain bilang bagong property maliban kung na-configure nang tama. Inihahambing ng ilang dashboards ang old-domain traffic sa new-domain traffic at pinapalabas na mas masama ang migration kaysa sa tunay na kalagayan.

Maaaring mag-fluctuate ang search visibility sa loob ng ilang linggo. Ang ayaw mong mangyari ay isang pattern kung saan paulit-ulit na kina-crawl ang high-value old URLs pero hindi nare-redirect nang tama, o kung saan nadidiskubre ang bagong pages pero namamarkahan bilang duplicates ng lumang domain.

Hindi rin dapat balewalain ang performance. Kung mag-launch ang bagong domain na may mas mabibigat na templates, sirang caching, o hindi na-optimize na assets, maaaring maramdaman ng users ang migration bilang pagbagal. Kung ginagamit mo ang Lighthouse bilang bahagi ng iyong checks, basahin ito nang may priorities sa isip; ipinapaliwanag ng aming artikulo sa paano magbasa ng Lighthouse report nang hindi nagpapanic kung paano paghiwalayin ang mahahalagang isyu mula sa ingay.

Panatilihin ang lumang domain nang matagal

Huwag hayaang mag-expire ang lumang domain pagkatapos “gumana” ang migration. Panatilihin itong registered, panatilihing valid ang certificates, at panatilihing tumatakbo ang redirects hangga't maaari. Sa praktika, madalas itong nangangahulugan ng maraming taon.

Patuloy na umiiral ang lumang links sa blog posts, bookmarks, documentation, PDFs, emails, at social posts. Ang redirects ang tulay sa pagitan ng historical footprint na iyon at ng bagong domain. Ang pag-off sa mga ito nang masyadong maaga ay sumisira sa landas ng users at nagsasayang ng naipong signals.

Magpanatili rin ng kopya ng iyong redirect map at launch notes. Pagkalipas ng anim na buwan, kapag may nagtanong kung bakit ganoon ang behavior ng isang legacy URL, ikatutuwa mong naidokumento mo ito.

<!-- tool-cta:start -->

💡 Subukan ito: Pagkatapos ng cutover, i-trace ang iyong mga lumang URL sa pamamagitan ng Redirect Checker upang makumpirmang ang bawat isa ay nagre-resolve sa tamang bagong page sa iisang 301 hop.

<!-- tool-cta:end -->

Isang makatuwirang migration checklist

Bago ang launch:

• I-verify ang parehong domains sa Search Console.
• I-crawl ang kasalukuyang site at i-export ang mahahalagang URLs.
• Bumuo ng one-to-one redirect map.
• Ibaba ang DNS TTLs.
• Ihanda ang TLS certificates para sa luma at bagong domains.
• I-update ang canonicals, internal links, hreflang, structured data, at sitemaps.
• I-test ang redirects sa staging o controlled environment.

Sa launch day:

• I-deploy ang redirects.
• Kumpirmahin ang HTTP to HTTPS behavior.
• I-test ang mahahalagang URL sample mula sa bawat template type.
• Isumite ang bagong sitemap.
• Gamitin ang Change of Address tool kung naaangkop.
• Bantayan ang server errors, redirect loops, at blocked resources.

Pagkatapos ng launch:

• I-monitor ang crawl errors at indexing reports.
• I-update ang mahahalagang external links kung kaya.
• Ihambing ang traffic ayon sa landing page intent, hindi lang domain totals.
• Panatilihing live ang redirects nang walang takdang katapusan.
• Ipagpaliban ang hindi kaugnay na redesign o content experiments hanggang maging stable ang paglipat.

Hindi risk-free ang domain migrations, pero manageable ang mga ito. Karaniwang napipinsala ang rankings kapag nagpapadala ang migration ng malalabong signal: nawawalang redirects, binagong content, magkakasalungat na canonicals, naka-block na crawlers, o nakalimutang lumang domain. Bigyan ang mga search engine at user ng malinaw na mapa, at magiging mas hindi dramatiko ang paglipat.