Dari HTML Site ke WordPress Custom: Studi Kasus exportimportdept.com

Pada 9 Maret 2026, Mas Bagus dari PT Milenial Solusi Internusa atau MSI Freight menghubungi saya untuk membahas website company profile mereka di exportimportdept.com.

Permintaan awalnya bukan sekadar membuat tampilan baru. MSI ingin website yang lebih siap untuk marketing dan SEO.

Website tersebut juga perlu lebih mudah dikelola oleh tim internal tanpa bergantung pada developer untuk perubahan kecil sampai sedang.

Rencana awal saya adalah membangun ulang website tersebut dengan GeneratePress dan GenerateBlocks.

Namun saat meeting online, tim MSI menunjukkan HTML site yang sudah mereka desain dan develop sendiri.

Di titik itu, arah proyek berubah. Saya tidak perlu membuat konsep visual baru dari nol, melainkan mentransformasikan desain HTML tersebut ke WordPress dengan custom theme dan custom blocks.

Hasil akhirnya adalah 13 halaman berbasis HTML site dengan desain yang dipertahankan.

Di belakangnya ada sistem konten WordPress, migrasi 32 artikel, dan 346 aturan 301 redirect untuk menjaga kesinambungan URL lama.

Ringkasan Singkat

Kondisi Awal: Desain Sudah Ada, Workflow Belum Siap

MSI sebenarnya sudah memiliki website dengan informasi layanan, portfolio, artikel, foto, video, dan halaman kontak.

Masalahnya, website tersebut belum cukup siap untuk menjadi fondasi marketing dan SEO jangka panjang.

Sebagian referensi yang tersedia juga berupa frontend backup. Saya tidak memulai dari source code dan database lengkap yang bisa langsung dipindahkan.

Karena itu, rebuild perlu dilakukan dengan membaca struktur dan tampilan yang sudah ada.

Dari diskusi awal, kebutuhan MSI cukup jelas: pengunjung harus lebih mudah memahami layanan freight forwarding.

Tim internal juga perlu bisa memperbarui konten tanpa meminta bantuan developer setiap kali ada perubahan.

Tracking website lama juga belum membedakan dengan baik antara web lead dan aktivitas lain seperti local action di Google Maps.

Jadi, website baru perlu disiapkan agar interaksi seperti WhatsApp, telepon, dan form bisa diukur dengan lebih jelas.

Kenapa Rencana GeneratePress Berubah?

GeneratePress dan GenerateBlocks sebenarnya tetap masuk akal untuk website company profile yang membutuhkan fondasi ringan dan fleksibel.

Itu sebabnya keduanya menjadi rencana awal saya.

Namun, HTML site yang ditunjukkan tim MSI sudah memuat arah visual yang mereka inginkan.

Homepage memiliki hero dengan foto container, headline besar, warna brand biru-oranye, panel tracking shipment, dan area informasi kantor di bagian bawah.

Kalau saya tetap menggunakan pendekatan template lalu mendesain ulang dari awal, ada risiko hasil akhirnya bergeser dari desain yang sudah disetujui MSI.

Akan ada pekerjaan tambahan untuk menerjemahkan ulang layout, spacing, komponen, dan visual hierarchy.

Karena itu saya menyarankan custom theme yang disesuaikan dengan HTML site tersebut.

Keputusannya bukan karena GeneratePress atau GenerateBlocks buruk, tetapi karena kebutuhan proyeknya sudah lebih spesifik daripada sekadar memilih tema yang siap pakai.

Scope Final: 13 Halaman Berbasis HTML Site

Dalam scope final, saya mengerjakan 13 halaman berdasarkan struktur HTML site yang dibawa oleh tim MSI.

Angka ini merujuk pada halaman utama yang menjadi bagian dari website, bukan sekadar jumlah record yang nantinya terlihat di database WordPress.

Di luar halaman tersebut, website juga membutuhkan beberapa content type agar pengelolaannya tidak kembali menjadi HTML mentah.

Saya menyiapkan struktur untuk layanan, portfolio, artikel, dan jadwal export-import sesuai kebutuhan operasional MSI.

Daftar layanan memiliki field dan metadata yang bisa dikelola dari dashboard, bukan lagi HTML mentah.

Editor layanan LCL memisahkan hero, lead, metadata SEO, dan pengaturan navigasi dari template frontend.

Keputusan ini penting karena halaman statis dan konten berulang memiliki kebutuhan pengelolaan yang berbeda.

Halaman utama perlu menjaga layout, sedangkan artikel, layanan, portfolio, dan jadwal perlu bisa ditambah atau diperbarui secara rutin.

Portfolio juga memiliki editor sendiri untuk featured image, gallery, kategori, dan informasi proyek.

Field portfolio membantu tim menambah proyek baru tanpa menyusun ulang layout dari awal.

Membangun Custom Theme dan Custom Blocks

Custom theme saya gunakan untuk mengatur fondasi tampilan, template, header, footer, dan gaya visual yang harus konsisten.

Area konten kemudian dibuat agar bisa diisi menggunakan block-block custom yang sudah disiapkan sesuai desain homepage.

Dalam demo kepada tim MSI, homepage dimulai dari area konten yang kosong dengan header, footer, dan call to action sebelum footer.

Tim kemudian bisa menambahkan section menggunakan block yang tersedia, mengubah teks, URL, foto, atau video, dan mengatur urutannya dengan drag and drop.

Homepage bisa diedit dari block editor, sementara struktur hero, CTA, dan panel tracking tetap mengikuti desain yang sudah disepakati.

Ini adalah perbedaan penting antara mempertahankan desain dan mempertahankan cara kerja HTML. Desainnya tetap menjadi acuan visual, tetapi pengelolaan kontennya berpindah ke workflow WordPress yang lebih praktis.

Saya juga memisahkan fungsi website dari theme sejauh mungkin.

Custom block, custom post type, pengaturan website, form penawaran, dan fitur khusus ditempatkan di layer fungsional agar tidak semuanya menempel pada file template.

Layer fungsional MSI Core menangani CPT, settings, Gutenberg blocks, form penawaran, dan kebutuhan khusus website.

Pengaturan yang sifatnya global, seperti header dan footer, juga dibuat dari area khusus agar tidak perlu diedit langsung dari file theme.

Pengaturan global untuk brand, alamat kantor, footer, dan bagian lain yang dipakai lintas halaman.

Block editor juga dipakai untuk area logo klien dan partner. Tim MSI dapat mengatur urutan logo, mengganti gambar, dan mengisi alt text dari editor yang sama.

Logo cloud dibuat sebagai block dengan pengelolaan gambar dan alt text yang lebih terstruktur.

Trade-off-nya, custom theme membutuhkan waktu development dan QA lebih besar di awal.

Sebagai gantinya, MSI mendapatkan sistem yang lebih sesuai dengan desain mereka dan tidak perlu memelihara kumpulan override untuk memaksa tema generik mengikuti HTML site.

Menyusun Fondasi SEO dan Konten

Sebelum development berjalan penuh, saya menyusun struktur SEO dan konten berdasarkan target pasar Indonesia.

Riset ini bukan hanya mencari keyword dengan volume terbesar. Saya perlu memastikan keyword tersebut sesuai dengan layanan MSI, intent pencariannya jelas, dan bisa diterjemahkan menjadi halaman yang berguna.

Metode Riset Keyword

Saya menggunakan Semrush sebagai sumber data utama. Database yang dipakai adalah Indonesia, dan lampiran dasar pemilihan keyword dikirimkan ke MSI pada 22 Juli 2026.

Semrush saya gunakan untuk menemukan variasi keyword dan melihat data volume yang tersedia. Angka volume tetap saya perlakukan sebagai estimasi provider, bukan jumlah pencarian absolut yang pasti terjadi setiap bulan.

Setelah mendapatkan daftar awal, saya melakukan validasi manual melalui Google Search dan SERP. Saya melihat halaman yang muncul, bentuk kontennya, jenis intent, serta apakah Google lebih sering menampilkan halaman layanan atau artikel untuk query tertentu.

Saya juga membandingkan pola dari website yang muncul di SERP dengan referensi industri. Tujuannya bukan menyalin isi kompetitor, tetapi memahami standar informasi yang perlu dijawab untuk topik seperti LCL, FCL, air freight, customs clearance, PPJK, dan project cargo.

Untuk istilah yang berkaitan dengan proses import, export, dan regulasi, saya melakukan pengecekan silang dengan sumber resmi. Langkah ini membantu agar copywriting tidak hanya mengikuti istilah yang dipakai website lain.

Hasil riset kemudian saya validasi lagi menggunakan company profile, brand guideline, daftar layanan, dan diskusi bersama tim MSI. Dari sini saya bisa memastikan bahwa keyword yang dipilih memang mewakili layanan yang benar-benar tersedia.

Data website lama dan laporan analytics juga saya gunakan sebagai konteks. Namun, saya tidak menjadikannya satu-satunya dasar karena tracking lama masih banyak mencatat local action seperti Google Maps, bukan web lead yang bisa diverifikasi.

Dari Keyword ke Struktur Halaman

Riset keyword dilakukan untuk homepage dan 11 layanan yang tercantum dalam company profile. Setelah itu, saya membuat keyword mapping agar setiap kelompok intent memiliki pemilik halaman yang jelas.

Untuk setiap halaman, hasilnya diterjemahkan menjadi:

• keyword utama dan variasi pendukung;
• SEO title, H1, dan meta description;
• rekomendasi permalink;
• arah isi halaman berdasarkan intent;
• rencana internal linking dari artikel dan halaman layanan lain.

Dengan cara ini, keyword research tidak berhenti sebagai spreadsheet. Hasilnya menjadi dasar sitemap, struktur URL, copywriting, dan sistem internal linking yang kemudian dipakai dalam development.

Keputusan bahasa Indonesia sebagai primary language juga lahir dari proses ini. Keyword transactional yang relevan banyak memakai istilah seperti “jasa”, “import”, dan “freight forwarder”.

Riset awal menghasilkan 85 variasi keyword. Sebanyak 60 keyword memiliki data volume.

Sisanya perlu diperlakukan lebih hati-hati karena tidak memiliki data volume yang cukup untuk dijadikan dasar klaim demand.

Saya juga tidak memaksakan semua keyword yang pernah disebut oleh vendor sebelumnya.

Contohnya, MSI pernah melihat homepage muncul untuk istilah “jasa LCL murah”. Namun data riset menunjukkan “jasa import LCL” memiliki volume, sedangkan tambahan kata “murah” tidak memiliki data yang memadai.

Jadi, saya tetap menyiapkan halaman layanan LCL, tetapi tidak menjejalkan kata “murah” ke dalam copywriting hanya karena pernah muncul dalam klaim ranking.

Struktur halaman, title, meta description, dan internal linking perlu mengikuti intent serta bukti yang lebih masuk akal.

Selain halaman layanan, saya memigrasikan 32 artikel dari website lama beserta gambar dan metadata SEO-nya.

Artikel-artikel tersebut tetap penting karena bisa menjadi sumber internal linking menuju halaman layanan baru.

Fitur yang Mendukung Operasional MSI

Salah satu fitur utama adalah form permintaan penawaran.

Form ini dilengkapi Cloudflare Turnstile untuk mengurangi spam, pengiriman email melalui Resend SMTP, email konfirmasi untuk pengirim, dan notifikasi untuk tim MSI.

Untuk konten layanan dan portfolio, saya menggunakan struktur data yang lebih terarah daripada menulis semuanya sebagai satu halaman panjang.

Tim bisa mengelola itemnya melalui dashboard, sementara template frontend tetap menjaga konsistensi tampilan.

Dashboard merangkum layanan, portfolio, artikel, dan permintaan penawaran agar tim bisa melihat pekerjaan utama dari satu tempat.

Jadwal export dan import juga dibuat agar bisa diperbarui dari dashboard WordPress.

Informasi yang sebelumnya disiapkan dalam file dapat ditampilkan dalam bentuk tabel di website, dengan opsi file PDF jika pengunjung tetap membutuhkan format unduhan.

Editor jadwal menyediakan tab export dan import, route, vessel, voyage, cut off, ETD, ETA, serta file unduhan.

Di frontend, data jadwal tampil sebagai tabel yang lebih mudah dipindai dan tetap bisa dilengkapi file resmi.

Pada salah satu pengujian, data jadwal sempat terlihat hilang setelah disimpan.

Saya memulihkannya melalui revisions WordPress, lalu memperbaiki masalah escaping pada data yang dikirim ke editor.

Ini contoh kecil mengapa revisions dan alur recovery perlu dianggap sebagai bagian dari sistem, bukan fitur tambahan yang boleh diabaikan.

Shipment tracking sengaja tidak saya masukkan sebagai fitur produksi pada fase ini.

MSI memang sudah menyiapkan dokumentasi API dan homepage menampilkan area “segera hadir”, tetapi sumber data masih berkaitan dengan transisi ERP dan sistem internal.

Membangun plugin tracking sebelum sumber datanya stabil hanya akan membuat pekerjaan berulang.

Karena itu, integrasi API saya posisikan sebagai pengembangan lanjutan setelah ERP MSI sudah menjadi source of truth yang final.

Migrasi: Redirect dan Permalink Sama Pentingnya dengan Tampilan

Migrasi website tidak selesai ketika homepage baru sudah tampil.

URL lama, artikel, sitemap, analytics, email, dan konfigurasi DNS juga perlu diperiksa agar perpindahan tidak memutus alur yang sudah berjalan.

Untuk menjaga URL lama, saya menyiapkan 346 aturan 301 redirect di Cloudflare.

Aturan tersebut kemudian diaktifkan ketika website dipindahkan ke hosting MSI dan proses launch sudah siap dilakukan.

Ada juga masalah klasik setelah migrasi: URL /artikel/ sempat mengembalikan 404. Penyebabnya bukan halaman yang hilang, melainkan aturan permalink WordPress yang perlu di-refresh.

Saya menyelesaikannya dengan flush atau menyimpan ulang permalink di WordPress.

Setelah itu route artikel kembali normal. Kasus seperti ini terlihat sederhana, tetapi tetap perlu masuk checklist QA karena sering muncul setelah perpindahan hosting atau perubahan struktur URL.

Navigasi mobile juga ikut diuji karena menu layanan memiliki beberapa tingkat kategori. Pada layar kecil, menu tetap memberi akses ke layanan, artikel, kontak, dan CTA utama tanpa mengubah struktur informasi desktop.

Menu mobile mempertahankan hierarki layanan dan CTA utama dalam ruang layar yang lebih sempit.

Hasil yang Terlihat

Perubahan proyek ini bisa dilihat dari beberapa sisi:

Area	Sebelum	Sesudah
Sumber visual	HTML site sebagai frontend	Custom theme yang mengikuti desain HTML
Pengelolaan halaman	Bergantung pada implementasi frontend	WordPress dengan custom blocks
Scope halaman utama	Website lama dengan struktur terbatas	13 halaman berbasis HTML site
Konten artikel	Berada di sistem lama	32 artikel dimigrasikan dengan gambar dan metadata
URL lama	Perlu dipetakan ulang	346 aturan 301 aktif di Cloudflare
Jadwal export-import	File dan proses manual	Bisa diatur dari dashboard dan ditampilkan di website

Snapshot PageSpeed Insights yang saya simpan mencatat performance desktop 100 dan mobile 92.

Snapshot desktop: performance 100, FCP 0,5 detik, LCP 0,6 detik, TBT 0 ms, dan CLS 0,001.

Snapshot mobile: performance 92, FCP 2,0 detik, LCP 3,2 detik, TBT 0 ms, dan CLS 0.

Mengapa skor mobile lebih rendah? Hero homepage menggunakan video, sehingga proses download, decode, dan render lebih terasa pada perangkat mobile.

Google Tag Manager dan Meta Pixel juga menambahkan pekerjaan dari script pihak ketiga. Pada scope proyek ini, saya menilai skor 92 sudah menjadi hasil yang masuk akal tanpa menghilangkan elemen yang memang dibutuhkan MSI.

Namun, PageSpeed Insights adalah pengujian lab dengan simulasi perangkat dan jaringan tertentu. Skor 92 tidak otomatis berarti pengalaman nyatanya lebih buruk daripada halaman dengan skor 100.

Dalam kondisi perangkat, jaringan, cache, dan script yang berbeda, halaman dengan skor lab 92 bisa saja terasa lebih cepat dalam praktik. Karena itu, angka ini perlu dibaca bersama data real-user jika traffic dan field data sudah tersedia.

Hal yang juga perlu dibedakan adalah kesiapan tracking dengan hasil bisnis.

GA4, GSC, GTM, Meta Pixel, event WhatsApp, telepon, dan form membantu MSI mengumpulkan data yang lebih berguna, tetapi data tersebut belum otomatis membuktikan kenaikan lead atau revenue.

Pelajaran dari Proyek Ini

1. Discovery bisa mengubah keputusan teknis

Rencana awal dengan GeneratePress dan GenerateBlocks dibuat berdasarkan informasi yang tersedia saat proposal.

Setelah HTML site diperlihatkan dalam meeting, keputusan paling masuk akal berubah menjadi custom theme dan custom blocks.

Untuk saya, ini bukan perubahan scope yang harus dihindari. Ini hasil discovery yang membuat implementasi lebih sesuai dengan aset dan ekspektasi klien.

2. Custom bukan berarti selalu lebih baik

Kalau desain belum ada atau masih sangat fleksibel, tema dan block system yang sudah matang bisa menjadi pilihan yang efisien.

Custom architecture masuk akal ketika desain sudah spesifik, workflow editing perlu dikontrol, dan hasil visual harus konsisten.

3. Migrasi perlu rencana recovery

Redirect, permalink, revisions, dan checklist QA mungkin tidak terlihat di homepage.

Namun justru bagian-bagian tersebut yang menentukan apakah website baru bisa digunakan tanpa kehilangan akses ke konten lama.

4. Fitur yang ditunda juga bagian dari keberhasilan

Shipment tracking tidak saya paksakan hanya karena area UI-nya sudah ada.

Menunggu ERP dan API menjadi lebih stabil lebih aman daripada mengirim fitur yang harus dibangun ulang ketika sumber datanya berubah.

Penutup

Proyek exportimportdept.com menunjukkan bahwa transformasi HTML ke WordPress tidak harus mengorbankan desain yang sudah dimiliki klien.

Tantangan utamanya adalah menerjemahkan visual yang fixed menjadi sistem konten yang tetap fleksibel.

Dengan custom theme dan custom blocks, MSI mendapatkan 13 halaman berbasis HTML site yang bisa dikelola melalui WordPress.

Di belakangnya, ada fondasi SEO, migrasi artikel, redirect, form, jadwal, dan tracking yang disusun untuk kebutuhan marketing dan operasional berikutnya.

Kalau Anda sudah memiliki HTML site dengan desain yang ingin dipertahankan, saya bisa membantu memetakan bagian yang cukup dikonversi ke blocks.

Bagian yang lebih aman dibangun sebagai custom functionality bisa kita pisahkan sejak awal.

Anda bisa mulai dari layanan pembuatan website custom atau layanan konversi website ke blocks WordPress.