Timeline
November 2025 -> Januari 2026
Proyek ini dimulai pada November 2025 dan selesai pada Januari 2026. Secara timeline, dua bulan untuk migrasi seperti ini tergolong cepat, apalagi saya mengerjakannya sambil tetap menangani proyek-proyek klien di Harun Studio.
Yang menarik: migrasi ini bukan lahir karena WordPress gagal.
Sebelum pindah, PenasihatHosting.com sebenarnya sudah terasa meyakinkan di WordPress. Dari sisi SEO, pengelolaan konten, stabilitas, hingga kemudahan kustomisasi dengan stack ringan seperti GeneratePress dan GenerateBlocks, semuanya masih sangat layak. Saya sendiri juga sudah menggunakan WordPress hampir setiap hari selama sekitar 10 tahun, jadi tidak ada masalah mendasar yang membuat saya harus “kabur” dari WordPress.
Titik baliknya justru datang dari arah produk.
Penasihat Hosting tidak lagi ingin berhenti sebagai blog review biasa. Arahnya berubah menjadi ekosistem hosting yang lebih lengkap: review, direktori hosting, wiki, blog, panduan, sampai halaman tools seperti uptime calculator, DNS lookup tool, SSL checker, dan seterusnya. Di titik itu, saya merasa kebutuhan jangka panjang 5-10 tahun ke depan akan jauh lebih mudah ditangani dengan stack yang lebih fleksibel.
Timeline
November 2025 -> Januari 2026
Motif Utama
Pivot produk, bukan “kabur” dari WordPress
Stack Baru
Next.js 16 + PostgreSQL + CMS kustom
Rendering
Static-first, cache-heavy, tag revalidation
PageSpeed
95 mobile / 100 desktop
CWV
Core Web Vitals Assessment: Passed
Jika website WordPress Anda mulai berkembang dari sekadar situs konten menjadi produk yang jauh lebih kompleks, diskusikan dulu via konsultasi gratis agar stack yang dipilih benar-benar cocok untuk 5-10 tahun ke depan.
Saya perlu tekankan ini dulu, karena sering kali narasi migrasi terlalu sederhana: seolah-olah jika pindah dari WordPress berarti WordPress-nya buruk. Padahal tidak sesederhana itu.
Stack WordPress Penasihat Hosting sebelumnya juga sudah tergolong sehat:
Jadi masalahnya bukan “WordPress lambat”, “WordPress jelek”, atau “WordPress tidak bisa diandalkan”.
Masalah sebenarnya adalah: produk yang sedang dibangun makin jauh dari bentuk website biasa.
Ketika target akhirnya adalah platform hosting yang punya direktori provider, kategori, data center, promo, plans, wiki, blog, dan tool pages yang interaktif, kompleksitas logika bisnisnya mulai naik cukup tajam. Di sini saya merasa memaksakan semuanya tetap tumbuh di WordPress akan membuat beban jangka panjangnya ikut naik: lebih banyak manual labor, lebih banyak kompromi arsitektur, dan lebih banyak area yang terasa “bisa jalan, tapi kurang natural”.
Setelah mempertimbangkan beberapa opsi, saya memilih Next.js 16.
Bukan karena saya adalah developer Next.js hardcore. Justru sebaliknya: saya masih dalam fase belajar dan belum selama itu hidup di ekosistem React/Next. Namun untuk kebutuhan Penasihat Hosting, Next.js terasa sebagai titik kompromi terbaik antara fleksibilitas, produktivitas, dan masa depan produk.
Alasan utamanya:
Satu stack untuk front-end dan back-end
Saya bisa membangun interface publik, route dinamis, server actions, admin CMS, sampai logic yang lebih custom dari satu ekosistem yang sama.
Lebih natural untuk produk hybrid content + app
Penasihat Hosting bukan hanya blog. Ia punya area yang sangat content-heavy, tetapi juga punya area yang lebih menyerupai application layer: direktori, filtering, perbandingan, dan berbagai tool utilitas.
Lebih enak untuk fitur tool ke depan
Untuk kebutuhan seperti uptime calculator, DNS lookup, SSL checker, .htaccess generator, robots.txt generator, dan tool-tool lain, Next.js memang terasa lebih rapi dan lebih fleksibel dibanding saya harus memaksakan semuanya ke pola plugin/page builder WordPress.
AI workflow jauh lebih cocok
Dengan stack modern seperti Next.js, TypeScript, dan komponen yang modular, workflow pengembangan dengan AI terasa jauh lebih produktif. Porsi pekerjaan manual saya turun cukup banyak dibanding pola kerja lama yang lebih banyak berkutat di kombinasi PHP, snippets, hook, CSS, dan plugin behavior.
Jadi kalau pertanyaannya adalah, “apakah benar untuk kasus seperti ini Next.js lebih cocok daripada WordPress?”
Jawaban saya: ya, untuk kasus seperti Penasihat Hosting, itu benar.
Kalau yang dibangun hanya company profile, blog biasa, atau website konten yang tidak terlalu kompleks, WordPress masih sangat rasional. Tetapi untuk platform yang bergerak ke arah product ecosystem dengan banyak custom data relationships dan tools interaktif, Next.js terasa lebih pas.
Saya bukan developer Next.js yang sudah bertahun-tahun hidup penuh di stack ini. Tapi saya juga tidak benar-benar mulai dari nol.
Sebelum proyek ini, saya sudah beberapa kali membangun aplikasi dengan Next.js, termasuk:
Artinya, saya memang belum “veteran”, tapi saya sudah punya cukup fondasi untuk tahu bahwa proyek ini realistis untuk dikerjakan sambil belajar lebih dalam.
Dan jujur, inilah salah satu alasan kenapa momentum migrasi ini terasa tepat: AI untuk coding sudah jauh lebih bisa diandalkan. Saya bisa fokus di arsitektur, validasi, perbaikan hasil, dan quality control, sementara banyak pekerjaan repetitif bisa dipercepat oleh tool seperti Cursor, Codex, dan workflow prompt-first yang sekarang semakin matang.
Seperti mayoritas proyek WordPress saya, stack lama di Penasihat Hosting juga dibangun dengan pendekatan yang ringan:
Ini tetap stack WordPress yang bagus. Jadi lagi-lagi, titik masalahnya bukan di kualitas stack lama, tapi di kebutuhan produk yang berkembang melampaui bentuk website WordPress biasa.
Arsitektur barunya saya susun dengan komponen utama berikut:
Saya memilih menjalankan website ini di VPS Singapura, yang sangat dekat dengan target pengunjung utama di Indonesia. Buat saya, ini kombinasi yang nyaman: saya tetap punya kontrol server, performa terasa cepat untuk market Indonesia, dan tidak tergantung pada terlalu banyak third-party untuk core hosting dan database.
Salah satu keputusan yang paling “berani”, tapi justru paling saya syukuri, adalah membuat CMS internal sendiri.
Secara teknis, saya paham ini terdengar repot. WordPress sudah punya Gutenberg, editor visual, plugin ekosistem, dan workflow publikasi yang jauh lebih matang. Tapi untuk saya pribadi, kebutuhan editor yang super intuitif tidak terlalu wajib, karena saya adalah developer dan sudah nyaman dengan MDX.
Jadi pendekatannya bukan membangun CMS general-purpose seperti WordPress. Saya hanya membangun CMS yang sesuai dengan workflow saya sendiri.
Struktur internal yang saya bangun mencakup:
Untuk editor konten, saya menggunakan pendekatan MDX editor berbasis CodeMirror, lengkap dengan toolbar untuk menyisipkan elemen-elemen yang sering dipakai. Hasilnya memang tidak se-“ramah pemula” Gutenberg, tapi jauh lebih pas untuk workflow saya.
Di sisi lain, kategori juga tidak lagi sekadar taxonomy “seadanya”. Saya membuat area pengelolaan kategori yang lebih serius karena kategori di proyek ini benar-benar punya peran penting dalam struktur direktori dan navigasi produk.
Keuntungan utamanya:
Bagian ini menurut saya adalah alasan bisnis paling penting di balik migrasi.
Sebelumnya, Penasihat Hosting sangat identik dengan halaman homepage yang kuat untuk keyword seperti “hosting terbaik” dan turunannya. Namun setelah pivot, homepage tidak lagi diposisikan sebagai landing page tunggal untuk keyword tersebut.
Homepage sekarang lebih berfungsi sebagai gerbang ke seluruh ekosistem, yang mencakup:
Ini perubahan besar secara arsitektur informasi. Dan konsekuensinya memang ada.
Halaman yang sebelumnya berfungsi sebagai pusat keyword “hosting terbaik” saya pindahkan ke /hosting-terbaik. Saat ini halaman itu masih berada di sekitar rank #11, dan saya memang menganggap ini sebagai fase transisi yang wajar. Fokus saya sekarang adalah memperkuat internal linking dan membantu Google memahami bahwa intent keyword tersebut sekarang bukan lagi homepage, melainkan halaman /hosting-terbaik.
Buat saya, ini penting untuk dijelaskan jujur: jika ada penurunan traffic, itu bukan semata-mata karena migrasi teknis, tetapi juga karena perubahan strategi produk dan struktur keyword target.
Dalam migrasi seperti ini, bagian paling sensitif memang bukan desain atau stack, tetapi SEO continuity.
Karena itu saya menjaga beberapa prinsip:
Untuk redirect, saya memilih menaruhnya langsung di Nginx, bukan di Cloudflare Rules atau Next.js redirect config. Buat saya ini lebih cepat, lebih fleksibel, dan lebih enak dikelola langsung di VPS.
Dari sisi implementasi, konten lama saya migrasikan dengan kombinasi bantuan AI, input manual lewat CMS, dan penyesuaian bertahap di database. Ini bukan migrasi “sekali klik selesai”, tetapi lebih seperti proses kurasi sambil memastikan hasil akhirnya tetap rapi.
Walau Next.js secara default memang sudah cepat, saya tetap tidak ingin hanya mengandalkan “bawaan framework”.
Beberapa optimasi yang saya terapkan:
Halaman-halaman penting dibangun dengan pola yang sangat cache-oriented. Banyak data yang dianggap stabil disimpan dengan cache profile jangka panjang dan di-invalidasi lewat tag saat ada perubahan dari area admin. Pendekatan ini membuat halaman marketing tetap terasa ringan, sambil tetap memberi ruang untuk data yang berubah terkontrol.
Saya mengaktifkan cache components sehingga halaman bisa memanfaatkan rendering yang lebih efisien. Untuk blok yang sifatnya statis, ini sangat membantu menjaga respons cepat tanpa harus semua request bekerja penuh seperti halaman dinamis tradisional.
Image remote dibatasi ke domain yang saya kontrol sendiri, lalu tetap memanfaatkan optimasi image dari Next.js dengan format modern seperti AVIF dan WebP. Karena aplikasi berjalan di VPS sendiri, saya bisa tetap mengaktifkan full image optimization tanpa terlalu khawatir biaya transformasi pihak ketiga.
Alih-alih menumpuk redirect di layer aplikasi, saya arahkan ke Nginx. Untuk kebutuhan migrasi yang cukup banyak, ini terasa lebih cepat dan lebih bersih.
Saya juga menaruh security headers di level aplikasi untuk hal-hal seperti clickjacking, MIME sniffing, referrer policy, HSTS, permissions policy, dan CSP yang lebih disiplin.
Saya menggunakan Upstash untuk rate limiting pada area-area yang memang rentan disalahgunakan: contact form, newsletter, admin login, search, API, dan tools tertentu.
Analytics saya tangani dengan Umami, sementara form kontak dan newsletter menggunakan Resend. Pilihan ini membuat development lebih cepat, lebih rapi, dan tidak membuat sistem terasa gemuk.
Untuk saya pribadi, hasil terbaik dari migrasi ini bukan sekadar skor PageSpeed tinggi, tetapi fakta bahwa website sekarang terasa cepat dan lolos Core Web Vitals sambil punya fondasi yang jauh lebih siap berkembang.
Hasil PageSpeed Insights yang saya catat:
Yang paling penting:
Karena server berada di Singapura dan target visitor utama adalah Indonesia, pengalaman real-world juga terasa sangat cepat. Jadi saya tidak terlalu terobsesi harus selalu melihat angka 100 di semua kombinasi device. Selama Core Web Vitals lolos, halaman terasa cepat, dan pengalaman pengguna konsisten, itu sudah jauh lebih penting.
Workflow development saya sekarang juga terasa lebih bersih:
Di sisi maintenance, yang benar-benar rutin saya lakukan praktis hanya:
Ini berbeda dengan pola maintenance WordPress yang hampir selalu membawa checklist update core, theme, plugin, dan kompatibilitas.
Dari sisi biaya juga relatif efisien. Tidak ada lonjakan biaya besar saat migrasi ini. Tambahan utamanya lebih ke tool kerja seperti editor AI/coding assistant bulanan, sementara infrastruktur inti tetap saya pegang sendiri.
Setelah migrasi, dampak yang paling terasa adalah:
Untuk SEO, saya tidak melihat kerusakan dramatis akibat migrasi teknis itu sendiri. Mapping URL dan 301 redirect membantu menjaga transisi tetap masuk akal.
Kalau ada penurunan traffic, faktor utamanya justru datang dari pivot strategi konten dan struktur keyword. Homepage yang sebelumnya kuat untuk keyword “hosting terbaik” sekarang berubah fungsi menjadi gateway ekosistem, sedangkan intent keyword itu dipindahkan ke /hosting-terbaik.
Jadi penurunan itu saya lihat lebih sebagai efek repositioning, bukan sinyal bahwa migrasinya gagal.
Jangan migrasi hanya karena stack lama terasa “kurang keren”.
Migrasi seharusnya terjadi karena kebutuhan produk memang berubah.
WordPress tetap sangat kuat untuk banyak use case.
Tapi untuk platform hybrid yang menggabungkan konten, direktori, tooling, dan admin logic yang cukup custom, Next.js bisa menjadi pilihan yang lebih natural.
Custom CMS tidak harus mewah.
Kadang yang dibutuhkan bukan CMS universal, tetapi CMS yang tepat untuk cara kerja Anda sendiri.
AI mengubah ekonomi development.
Proyek seperti ini jauh lebih realistis dikerjakan sekarang karena AI bisa memangkas banyak pekerjaan manual yang dulu menghabiskan energi.
SEO migration tidak cukup dengan “copy content”.
Yang lebih penting adalah menjaga intent, URL mapping, internal linking, redirect, dan struktur informasi agar tetap terbaca masuk akal oleh mesin pencari.
Tidak sama sekali.
Justru setelah selesai, saya makin yakin bahwa ini adalah keputusan yang tepat untuk arah Penasihat Hosting ke depan. Saya merasa lebih produktif, lebih mudah memasukkan AI ke workflow harian, lebih leluasa membangun fitur yang custom, dan lebih tenang karena fondasinya sekarang sudah jauh lebih cocok untuk kompleksitas produk yang sedang saya bangun.
Kalau Penasihat Hosting tetap sekadar blog review biasa, mungkin saya tidak akan melakukan migrasi ini.
Tetapi untuk platform yang ingin tumbuh menjadi ekosistem hosting lengkap, keputusan ini menurut saya sangat tepat.
Jika website Anda mulai tumbuh dari sekadar situs konten menjadi platform yang jauh lebih kompleks, kita bisa audit dulu apakah memang perlu migrasi stack, atau justru cukup merapikan arsitektur di sistem yang sekarang.
Mulai dari konsultasi gratis atau lihat juga jasa pembuatan website untuk kebutuhan pembangunan ulang dengan fondasi yang lebih siap berkembang.
Founder Harun Studio & web developer, blogger, serta hosting reviewer. Telah membantu pemilik bisnis meraih kesuksesan dengan design, development dan maintenance sejak 2021.
Baca juga insight lain yang masih relevan dengan topik ini.
Bagaimana kami meningkatkan kecepatan loading website 8x lipat, mengurangi biaya hosting 100%, dan menyederhanakan workflow dengan memigrasikan dari WordPress ke Astro.js.
Dari error 404 di firesystem.co.id hingga rebuild total menjadi hydrantsystem.co.id: studi kasus pembuatan website ringan, cepat, dan mudah dikelola dengan stack WordPress modern.
Studi kasus PT Zumatic: peningkatan performa mobile 53→93 dan desktop 81→100 lewat audit teknis, optimasi loading WordPress, dan penyederhanaan sistem pengelolaan konten.