Skip to content

Domain, hosting, code and data — in your name, in writing

jagaweb.

Reka Bentuk & Reka Bentuk Semula Laman Web

Cara Reka Bentuk Semula Laman Web Tanpa Kehilangan Kedudukan Carian

Bacaan 7 minitOleh JagaWeb

Inventori URL, peta pengalihan dan senarai semak pelancaran kurangkan risiko reka bentuk semula kehilangan trafik carian, tapi tak jamin sifar kehilangan.

Jurang antara laman lama dan laman baharu

Reka bentuk semula laman web mengubah URL, templat, dan selalunya platform asas — semuanya sekali gus. Enjin carian tidak menilai semula sesebuah laman sebaik sahaja ia berubah — Google perlu mengimbas semula halaman baharu, mengenal pasti kaitannya dengan halaman lama, dan mengemas kini indeksnya. Dokumentasi rasmi Google mengenai pemindahan laman dengan perubahan URL menyatakan dengan jelas bahawa proses ini mengambil masa: "bagi laman web bersaiz sederhana, ia boleh mengambil masa beberapa minggu atau lebih untuk Google secara beransur-ansur mula memaparkan URL baharu berbanding URL lama (dan bagi laman yang lebih besar, lebih lama lagi)." Dalam tempoh itu, halaman yang sama menyatakan, "keterlihatan kandungan anda dalam Carian mungkin turun naik buat sementara waktu semasa pemindahan berlangsung. Ini adalah perkara biasa."

Satu ayat itu sahaja wajar difikirkan sebelum apa-apa lagi dalam artikel ini. Migrasi yang dijalankan dengan teliti adalah faktor tunggal terbesar yang dimiliki sesebuah perniagaan untuk menentukan berapa banyak trafik carian yang dapat dikekalkan selepas reka bentuk semula — tetapi Google sendiri tidak menjanjikan turun naik itu akan menjadi sifar, dan tiada agensi yang boleh berkata jujur sedemikian juga. Berikut ialah bentuk sebenar migrasi yang teliti, langkah demi langkah, serta perkara yang perlu dipantau sebaik sahaja laman baharu dilancarkan.

Langkah 1: Buat inventori laman lama sebelum menyentuhnya

Anda tidak boleh mengalihkan apa yang belum disenaraikan. Sebelum sebarang kerja reka bentuk atau pembangunan bermula, kumpulkan senarai lengkap setiap URL yang boleh diindeks pada laman semasa — bukan sekadar halaman dalam menu utama, tetapi juga catatan blog, halaman pendaratan lama, arkib kategori dan tag, serta apa-apa sahaja yang telah diindeks oleh Google yang mungkin sudah dilupakan kewujudannya. Tiga sumber wajar disemak silang antara satu sama lain: senarai halaman dari CMS anda sendiri, imbasan laman langsung menggunakan alat seperti Screaming Frog, dan laporan Pages dalam Google Search Console di bawah Indexing, yang menunjukkan apa yang sebenarnya telah diindeks oleh Google, bukan apa yang anda anggap patut ada di sana.

Bagi setiap URL, catatkan: tajuk dan meta description semasa halaman itu, anggaran trafik organik atau impresi jika anda mempunyai sejarah Search Console, dan halaman dalaman mana yang memaut kepadanya. Inventori ini menjadi dokumen rujukan untuk setiap keputusan seterusnya, termasuk halaman mana yang berbaloi dikekalkan — reka bentuk semula juga masa yang munasabah untuk menghentikan halaman yang tidak pernah menjana trafik, dengan syarat ia dialihkan secara wajar dan bukan dibiarkan menjadi 404 senyap.

Langkah 2: Bina peta pengalihan satu-lawan-satu

Peta pengalihan ialah hamparan: URL lama dalam satu lajur, URL baharu dalam lajur satunya, untuk setiap halaman dari Langkah 1. Bukan satu peraturan pukal yang menghantar semuanya ke halaman utama — panduan Google secara khusus menyatakan pengalihan patut menuju ke "halaman baharu yang sepadan," dan pengalihan pukal ke halaman utama dianggap sebagai isyarat yang lemah, bukan penggantian setara, kerana ia memberitahu Google bahawa kandungan halaman lama itu benar-benar berpindah ke halaman utama — yang biasanya tidak benar.

Apabila struktur URL berubah (corak folder baharu, peraturan slug CMS baharu, domain baharu), latihan pemetaan inilah tempat sebahagian besar risiko migrasi sebenar berada. Ia membosankan, lebih-lebih lagi pada laman dengan beratus-ratus halaman, tetapi ia juga satu-satunya bahagian reka bentuk semula yang boleh dikesan kesilapannya melalui hamparan sebelum pelancaran, bukan selepasnya.

Langkah 3: Laksanakan pengalihan di peringkat pelayan, kekal (301/308)

Panduan Google mengenai pengalihan dan Carian mengesyorkan pengalihan kekal di peringkat pelayan — status HTTP 301 atau 308 — berbanding pengalihan meta-refresh atau JavaScript, yang hanya disenaraikan sebagai pilihan sandaran apabila pengalihan di peringkat pelayan benar-benar tidak dapat dilakukan. Pengalihan kekal dianggap sebagai isyarat kanonikalisasi: Googlebot mengikutinya, dan saluran pengindeksan Google menggunakannya sebagai isyarat bahawa URL destinasi patut menjadi versi kanonikal yang diranking. Itulah mekanisme yang membawa isyarat sedia ada sesebuah halaman kepada penggantinya — ia bukan automatik, dan bukan segera, tetapi itulah laluan yang didokumenkan oleh Google.

Satu peringatan daripada panduan yang sama: gunakan pengalihan kekal hanya apabila anda pasti perubahan itu tidak akan dibatalkan semula. Pengalihan sementara (302) membawa isyarat berbeza — bahawa perpindahan itu mungkin tidak kekal — jadi jangan jadikan 301 sebagai lalai untuk apa-apa yang mungkin ingin anda batalkan kelak, seperti halaman penyelenggaraan sementara.

Langkah 4: Kekalkan apa yang sudah berfungsi

Tajuk, meta description, dan struktur heading yang sudah meranking dengan baik tidak sepatutnya ditulis semula hanya kerana laman mempunyai reka bentuk baharu. Jika <title> dan H1 halaman lama sudah menjalankan fungsinya, bawa terus ke templat baharu tanpa perubahan, atau ubah secara sengaja dan berasingan daripada proses migrasi — bukan sebagai kesan sampingan format lalai CMS baharu. Perkara sama terpakai kepada data berstruktur: jika sesebuah halaman mempunyai schema review, produk, atau FAQ yang sah, pastikan templat baharu masih mengeluarkannya, kerana tema atau platform baharu tidak akan mengekalkan markup yang sedia ada pada yang lama secara automatik.

Langkah 5: Kemas kini pautan dalaman, jangan bergantung kepada pengalihan untuknya

Setiap pautan dalaman pada laman baharu patut menuju terus ke URL baharu, bukan ke URL lama melalui pengalihan. Pengalihan berantai menambah kelewatan dan melemahkan isyarat yang diikuti Google, dan panduan pemindahan Google sendiri menyeru supaya pautan dalaman dikemas kini secara terus. Ini termasuk menu navigasi, pautan footer, pautan dalam kandungan, dan tag canonical — semuanya mudah terlepas pandang kerana ia tidak kelihatan rosak kepada pelawat sepertimana pengalihan yang hilang.

Langkah 6: Sediakan staging dengan betul, dan pastikan ia tidak diindeks Google

Persekitaran staging patut disekat daripada diindeks — sama ada dengan tag meta noindex di seluruh laman atau dinding pengesahan HTTP, bukan sekadar disallow dalam robots.txt, kerana robots.txt menghentikan pengimbasan tetapi tidak semestinya menghentikan sesuatu URL daripada diindeks jika ia dipaut dari tempat lain. Kesilapan hari pelancaran yang paling biasa ialah terlupa mengalih keluar tag noindex itu apabila laman sebenar dilancarkan, yang secara senyap memberitahu Google supaya jangan indeks apa-apa pada domain baharu. Semak ini secara khusus sebagai satu langkah pelancaran, bukan andaian semata-mata.

Senarai semak pelancaran

Pada ketika pelancaran: matikan perlindungan staging, sahkan peta pengalihan telah digunakan dan berfungsi dengan betul (semak sampel URL lama secara rawak, jangan anggap sahaja), hantar sitemap XML yang dikemas kini yang hanya mengandungi URL baharu yang aktif, dan — jika domain itu sendiri berubah — failkan permintaan Change of Address dalam Search Console, yang khusus untuk migrasi domain dan bukan perubahan laluan URL pada domain yang sama. Jika laman itu berbilang bahasa, anotasi hreflang perlu dikemas kini kepada URL baharu sebagai sebahagian daripada langkah yang sama, bukan selepasnya.

Ia juga wajar menyemak Core Web Vitals pada templat baharu sebelum pelancaran. Ambang semasa ialah Largest Contentful Paint (LCP) pada atau di bawah 2.5 saat, Interaction to Next Paint (INP) pada atau di bawah 200 milisaat, dan Cumulative Layout Shift (CLS) pada atau di bawah 0.1, diukur pada persentil ke-75 lawatan sebenar — rujukan Core Web Vitals web.dev menghuraikannya dengan lengkap. Time to First Byte (TTFB) berguna sebagai diagnostik untuk LCP yang perlahan tetapi ia sendiri bukan Core Web Vital. Reka bentuk semula yang kelihatan lebih baik tetapi memuatkan lebih perlahan daripada laman lama hanya menukar satu risiko dengan risiko lain.

Perkara yang perlu dipantau selepas pelancaran

Sekurang-kurangnya untuk beberapa minggu pertama: pantau Index Coverage dalam Search Console untuk peningkatan ralat "Not found (404)" atau "Page with redirect" — biasanya menandakan jurang dalam peta pengalihan. Pantau Performance untuk klik dan impresi berbanding garis dasar pra-pelancaran, dalam tempoh minggu, bukan hari, kerana bunyi bising jangka pendek adalah perkara biasa. Semak secara berkala bahawa pengalihan masih berfungsi; penggunaan atau perubahan CDN kemudian boleh secara senyap merosakkannya. Kekalkan pengalihan lama aktif selama-lamanya jika praktikal — tiada tempoh luput yang tetap, dan pautan luar atau bookmark mungkin masih menuju ke URL lama berbulan-bulan kemudian.

Bersikap jujur tentang apa yang boleh dicapai

Semua perkara di atas mengurangkan risiko. Tiada satu pun menghapuskannya sepenuhnya. Dokumentasi Google sendiri menganggap turun naik semasa pemindahan sebagai perkara yang dijangka dan biasa, bukan kes terpencil yang boleh direka bentuk supaya tidak berlaku — dan mana-mana perniagaan yang merancang reka bentuk semula wajar bersedia menghadapi sedikit pergerakan sementara dalam kedudukan dan trafik, bukan mengharapkan peralihan yang lancar dan tidak kelihatan langsung. Apa yang diperoleh daripada migrasi yang teliti ialah penurunan yang jauh lebih kecil dan lebih singkat berbanding migrasi yang cuai — bukan jaminan tiada penurunan langsung.

Jika anda sedang merancang reka bentuk semula

Sebelum reka bentuk semula bermula juga waktu yang tepat untuk mendapatkan inventori laman semasa yang lengkap — kandungan, URL, dan apa yang sebenarnya menjana trafik — berbanding bergantung kepada ingatan atau sitemap yang sudah lapuk. Essential System Review JagaWeb (RM1,500 tetap, tidak termasuk SST — kini RM999 sehingga 16 September 2026, untuk satu laman sehingga 25 halaman) menghasilkan tepat jenis inventori itu sebagai sebahagian daripada laporannya, dan yuran tersebut dikreditkan kepada kerja susulan yang layak selama 12 bulan jika anda memutuskan untuk meneruskan. Bagi laman yang lebih besar dengan e-dagang atau pelbagai integrasi, Complete System Review (RM5,000 tetap, tidak termasuk SST, 26–250 halaman) meliputi skop yang sama pada skala lebih besar. Kedua-duanya adalah salah satu daripada beberapa cara untuk bersedia menghadapi migrasi — kami sedia berbincang sama ada mana-mana satu sesuai sebelum apa-apa komitmen dibuat.

WhatsApp