Skip to content
··9 menit baca

Apa yang Terjadi Setelah Migrasi: 8 Hari Return yang Berlipat Ganda

Saya memigrasikan blog ke Next.js dan mengira bagian sulitnya sudah selesai. Lalu efek berlipat ganda dimulai — 6 mega guide, asisten AI yang lebih pintar, newsletter native, perlindungan bot, dan overhaul SEO dalam 8 hari.

Delapan hari lalu, saya membangun ulang seluruh backend blog dalam 4 hari. Saya memigrasikan 485 postingan WordPress ke Next.js, menghidupkan kembali Sydney (chatbot AI saya), dan meluncurkan situs produksi.

Saya pikir itu ceritanya. Migrasi selesai, rayakan, lanjut.

Saya salah. Migrasi bukan tujuannya — itu garis startnya.

Ini tampilan situs saya pada 5 Feb vs hari ini:

Fitur5 Feb (Hari Migrasi)13 Feb (Hari Ini)
Postingan blog485 (migrasi dari WordPress)492 (6 mega guide baru)
Sydney AIRAG dasar, kualitas belum terujiDievaluasi, dioptimasi, hit rate 81%
NewsletterEmbed Beehiiv (pihak ketiga)Native Supabase + Resend, berbasis minat
SEOSitemap dasar + meta tagsStructured data, FAQ schema, llms.txt, AEO
KeamananRate limiting sajaCloudflare Turnstile + rate limiting
PerformaCek Lighthouse dasarProfiling sistematis dengan Chrome DevTools MCP
Featured imagesPembuatan manualPipeline AI-generated (Gemini + auto-optimize)

Setiap peningkatan terjadi karena yang sebelumnya membuatnya lebih mudah. Itulah efek berlipat ganda yang tidak saya duga.


Unlock-nya: Blog Kamu Sekarang Adalah Kode

Ini hal yang tidak ada yang bilang tentang migrasi dari WordPress ke stack berbasis kode: migrasi itu sendiri bukan intinya. Intinya adalah apa yang menjadi mungkin setelahnya.

Ketika blog kamu adalah 492 file MDX di repo Git, bukan baris di database MySQL, semuanya berubah:

  • Setiap postingan adalah file — Claude Code bisa membaca, mencari, dan memodifikasinya dalam skala
  • Setiap perubahan adalah diff — kamu bisa meninjau persis apa yang berubah, di 50 postingan sekaligus
  • Setiap fitur bisa dikomposisi — sistem newsletter kamu bisa membaca metadata postingan yang sama seperti chatbot AI
  • Setiap deployment adalah perintahpnpm build && vercel --prod, selesai

Dengan WordPress, memperbarui 12 postingan blog berarti login ke wp-admin, klik satu per satu, buat perubahan, update, ulang. Dengan file MDX dan Claude Code? Saya bisa bilang "tambahkan link ke postingan pillar taman nasional di semua 12 panduan taman yang ada" dan dia akan membaca setiap file, menambahkan cross-link yang tepat dalam konteks yang tepat, dan menunjukkan diff-nya. Semua 12 update dalam hitungan menit.

Ini unlock-nya. Bukan migrasinya. Kecepatan yang datang setelahnya.


Enam Mega Guide dalam 4 Hari

Hal pertama yang saya bangun setelah migrasi? Konten. Banyak.

Saya sudah ingin menulis panduan ekspatriat komprehensif selama berbulan-bulan — jenis postingan pillar 2.000-4.000 kata yang benar-benar membantu orang menavigasi kekacauan pindah ke AS. WordPress membuat itu menyakitkan. Setiap postingan memerlukan formatting manual, upload gambar, konfigurasi plugin SEO, manajemen kategori.

Sekarang? Pipeline-nya seperti ini:

  1. Brainstorm struktur dan outline postingan
  2. Tulis MDX lengkap dengan optimasi SEO/AEO bawaan
  3. Generate featured image — Claude membaca postingan, menulis prompt, mengirim ke Gemini untuk generate gambar
  4. Optimasi — Script Python mengonversi ke WebP, kompres untuk web
  5. Upload ke Vercel Blob
  6. Publishgit push, vercel --prod, pnpm db:publish
  7. Sydney langsung tahu — postingan disinkronkan ke Supabase dengan embedding

Ini yang terkirim dalam 4 hari itu:

PostinganTopikKata
Panduan KesehatanHSA, FSA & HDHP dijelaskan~3.200
Membangun KreditNol ke 720+ skor kredit~3.500
Tabungan & InvestasiPerbandingan T-Bills vs HYSA~2.800
Rewards Kartu KreditStrategi poin, miles, cashback~3.000
Panduan RelokasiPlaybook pindah ke AS lengkap~3.800
Taman Nasional26 taman, 4 road trip~4.200

Setiap postingan mengikuti pola AEO yang sama: pembukaan jawaban-dulu, tabel perbandingan, bagian 120-180 kata, definisi tebal, FAQ schema di bawah. Jenis struktur yang mendapat 340% lebih banyak kutipan AI.

Panduan taman nasional adalah yang terbesar — postingan pillar yang menautkan kembali ke 12 ulasan taman yang ada. Saya juga membuat komponen PhotoGallery untuknya, karena scroll 20 gambar individual itu menyiksa. Sekarang jadi grid rapi dengan lightbox. Simpel, tapi efektif.


Sydney Jadi Lebih Pintar

Ketika saya pertama kali menghidupkan kembali Sydney selama migrasi, dia berfungsi — dan saya mengujinya secara manual sebelum launch. Dia bisa menjawab pertanyaan, menemukan postingan relevan, mengutip sumber. Tapi pengujian manual hanya memberi tahu "ini tampak oke." Tidak memberi tahu seberapa oke, atau di mana celahnya, atau bagaimana membuatnya lebih baik.

Saya tidak punya cara sistematis untuk mengukur kualitas — dan tanpa pengukuran, saya tidak punya cara untuk meningkatkan.

Jadi saya membangun framework evaluasi RAG. 32 query uji di 12 kategori, masing-masing dengan hasil yang diharapkan yang saya kurasi manual. Pertanyaan seperti "Kartu kredit apa yang harus didapat ekspatriat?" harus mengembalikan panduan membangun kredit. "Ceritakan tentang Yosemite" harus mengembalikan laporan perjalanan Yosemite.

Kemudian saya menguji 30 kombinasi konfigurasi berbeda — 6 threshold similarity × 5 jumlah hasil — dan mengukur hit rate, precision, dan temporal diversity.

Hasilnya sangat membuka mata:

MetrikSebelum (Default)Sesudah (Teroptimasi)
Hit rate~30%81,2%
Query tanpa hasil6 dari 300 dari 30
Sebaran temporal1,2 tahun6,7 tahun

Perbaikan terbesar sangat memalukan: SDK OpenAI secara diam-diam menjatuhkan parameter dimensions saat berjalan di bawah Next.js. Sydney menghasilkan embedding 1536-dimensi tapi mencari indeks 384-dimensi. Pantas hasilnya buruk. Beralih ke panggilan fetch() langsung memperbaikinya semalaman.

Saya juga memperluas system prompt Sydney untuk mencakup semua 490+ topik blog — dia sekarang tahu tentang taman nasional, kartu kredit, kesehatan, dan seluruh perpustakaan konten ekspatriat. Bukan hanya AI dan marketing.

Dua perintah untuk mengujinya sendiri:

pnpm eval:rag        # Uji terhadap Supabase lokal
pnpm eval:rag:prod   # Uji terhadap produksi

Sekarang saya bisa benar-benar mengukur kapan Sydney menjadi lebih pintar. Itu jenis infrastruktur yang tidak pernah kamu bangun saat menjalankan WordPress.


SEO dan AEO dalam Skala

SEO di 2026 bukan hanya soal Google lagi. Ini soal dikutip oleh ChatGPT, Perplexity, dan Claude ketika seseorang mengajukan pertanyaan yang dijawab konten kamu.

Saya mengimplementasikan stack SEO/AEO penuh dalam satu akhir pekan:

Untuk pencarian tradisional:

  • Sitemap dinamis (639 halaman terindeks)
  • Structured data — schema Person, WebSite, Article, BreadcrumbList, FAQPage
  • RSS feed untuk sindikasi
  • Google Search Console terverifikasi

Untuk mesin AI (AEO/GEO):

  • llms.txt — panduan konten prioritas untuk crawler AI (GPTBot, Claude-Web, PerplexityBot semua diizinkan di robots.txt)
  • Pola jawaban-dulu di setiap pembukaan bagian (pernyataan kunci tebal di 150 kata pertama)
  • H2 format pertanyaan yang cocok dengan cara orang bertanya ke asisten AI
  • Bagian FAQ yang terdeteksi otomatis dan dirender sebagai schema FAQPage

Untuk performa: Saya menggunakan Chrome DevTools MCP untuk memprofilkan berbagai tipe halaman — homepage, daftar blog, postingan individual, halaman /ask — dan mengidentifikasi bottleneck. Bisa menjalankan performance trace, menganalisis hasilnya, dan memperbaiki masalah dalam sesi Claude Code yang sama itu... sangat efisien.

Hasilnya? Setiap postingan baru yang saya tulis secara otomatis mendapat structured data, FAQ schema (jika punya bagian FAQ), dan diformat untuk ekstraksi AI. Tanpa plugin. Tanpa konfigurasi manual. Begitulah cara situs bekerja sekarang.


Beehiiv Keluar, Newsletter Native Masuk

Yang ini mengejutkan saya. Saya punya newsletter yang berfungsi di Beehiiv. Mengumpulkan email. Mengirim update. Kenapa menggantinya?

Tiga alasan:

  1. Kontrol — Saya ingin langganan berbasis minat. Subscriber "AI & Technology" tidak seharusnya mendapat konten taman nasional. Tier gratis Beehiiv tidak mendukung itu.
  2. Integrasi — Data subscriber sekarang tinggal di database Supabase yang sama dengan indeks pencarian Sydney. Satu sumber kebenaran.
  3. Biaya — Supabase (tier gratis) + Resend (tier gratis untuk volume rendah) = $0/bulan.

Sistem yang saya bangun:

  • Double opt-in — subscribe → email verifikasi → terkonfirmasi → email selamat datang dengan rekomendasi personal
  • 5 grup minat — AI, Expat Life, Leadership, Marketing, Travel & National Parks
  • Smart matching — kategori postingan otomatis dipetakan ke minat subscriber. Ketika saya publish panduan kartu kredit, hanya subscriber "Expat Life" yang dinotifikasi.
  • Cron harian — Vercel menjalankan job jam 11 AM PST, menemukan postingan 48 jam terakhir, mengirim notifikasi tertarget
  • Deduplikasi — Tabel notification_log mencegah email duplikat, selamanya

Bagian terbaiknya? Form subscribe di bawah setiap postingan blog otomatis memilih minat yang relevan berdasarkan kategori postingan. Membaca artikel AI? Pil "AI & Technology" sudah terpilih saat kamu scroll ke bawah untuk subscribe.

Membangun ini dari nol terdengar banyak pekerjaan. Butuh sekitar satu malam kerja fokus. Migrasi Supabase, API routes, template email, dan cron job — Claude Code menangani scaffolding sementara saya fokus pada logika dan copy-nya.


Keamanan: Tidak Terlihat Sampai Kamu Butuh

Dengan chatbot AI publik dan signup newsletter, saya punya dua endpoint yang bot suka serang. Rate limiting sudah ada (Upstash Redis, 5 request per menit), tapi saya ingin lapisan kedua.

Masuk Cloudflare Turnstile — CAPTCHA invisible yang hanya menampilkan tantangan jika mencurigai aktivitas mencurigakan. Untuk 99% pengunjung nyata, sepenuhnya invisible. Untuk bot? Tembok.

Saya menambahkannya ke endpoint /ask dulu (chat Sydney), lalu menggunakan pola yang sama persis untuk /api/subscribe. Library verifikasi sama, degradasi graceful yang sama:

  • Tidak ada environment variables yang dikonfigurasi → bypass (development lokal berfungsi tanpanya)
  • API Cloudflare down → fail-open (rate limiter sebagai fallback)
  • Token hilang tapi secret key diset → reject (menangkap bot yang bypass frontend)

Reuse inilah yang membuat ini cerita tentang efek berlipat ganda. Integrasi Turnstile untuk newsletter butuh menit, bukan jam, karena infrastrukturnya sudah ada dari Sydney.


Efek Berlipat Ganda

Ini yang tidak saya rencanakan tapi terjadi secara natural:

Migrasi ke Next.js (1-5 Feb)
  └─→ File MDX memungkinkan Claude Code membaca/memodifikasi konten dalam skala
       └─→ 6 mega guide ditulis dengan optimasi SEO/AEO (6-11 Feb)
            └─→ Konten baru mengekspos masalah kualitas pencarian Sydney
                 └─→ Framework evaluasi RAG dibangun, Sydney dioptimasi (11 Feb)
                      └─→ Lebih banyak konten butuh newsletter (bukan Beehiiv)
                           └─→ Newsletter native dibangun di Supabase (12 Feb)
                                └─→ Endpoint publik butuh perlindungan bot
                                     └─→ Turnstile ditambahkan ke Sydney + subscribe (12-13 Feb)

Tidak ada yang direncanakan sebagai urutan. Setiap peningkatan mengungkapkan kebutuhan berikutnya. Migrasi membuat pembuatan konten cepat. Pembuatan konten cepat mengekspos celah kualitas pencarian. Memperbaiki pencarian membuat saya ingin distribusi yang lebih baik. Distribusi yang lebih baik butuh perlindungan.

Itulah efek berlipat ganda. Setiap peningkatan tidak hanya menambah nilai — ia melipatgandakan nilai dari semua yang datang sebelumnya. :)

Dan benang merah melalui semuanya? Setiap bagian situs saya sekarang adalah kode yang bisa dibaca, diuji, dan dimodifikasi secara programatis. Itulah unlock yang sebenarnya.


Angka-angkanya

Karena saya tahu kamu penasaran:

MetrikNilai
Hari sejak migrasi8
Postingan blog baru7 (termasuk ini)
Fitur baru diluncurkan6 (newsletter, Turnstile ×2, RAG eval, stack SEO, PhotoGallery)
Postingan blog diperbarui12+ (cross-linking, perbaikan broken link)
Baris kode ditambahkan~5.600
Tabel database ditambahkan2 (subscribers, notification_log)
API endpoints ditambahkan4 (subscribe, verify, unsubscribe, cron)
Kenaikan biaya$0/bulan (semua tier gratis)

Apa Selanjutnya

Saya belum selesai. Efek berlipat ganda belum berhenti:

  • Lebih banyak panduan ekspatriat — strategi pajak, timeline visa, perbandingan bank. Seri ini punya kaki.
  • Sydney makin pintar — sekarang bisa mengukur kualitas, saya ingin mendorong hit rate melewati 90%.
  • Lebih banyak deep dive tentang membangun dengan AI — tool-nya berevolusi mingguan. Saya mendokumentasikan sambil jalan. (Terbaru: membangun aplikasi iOS native tanpa mengenal Swift dan menemukan bahwa AI mengantarmu 60% — 40% terakhir adalah tempat produknya benar-benar hidup.)

Tapi jujur? Saya paling bersemangat untuk terus menulis. Untuk pertama kalinya dalam 17 tahun ngeblog, mempublish postingan baru benar-benar menyenangkan — bukan tugas WordPress 45 menit. :D

Apakah kamu pernah mengalami efek berlipat ganda semacam ini setelah migrasi atau keputusan teknis besar? Saya penasaran — apa unlock tak terduga pertama yang mengejutkan kamu?

Salam,

Chandler


Pertanyaan yang Sering Diajukan

Apa itu efek berlipat ganda dalam pengembangan website?

Efek berlipat ganda adalah ketika setiap peningkatan pada situs kamu membuat peningkatan berikutnya lebih cepat dan lebih mudah. Misalnya, migrasi ke stack berbasis kode memungkinkan pembuatan konten berbantuan AI, yang mengungkapkan masalah kualitas pencarian, yang mengarah pada pembangunan framework evaluasi. Setiap langkah membangun di atas yang sebelumnya.

Bagaimana cara mengoptimasi postingan blog untuk mesin pencari AI?

Mesin pencari AI lebih menyukai konten terstruktur, jawaban-dulu dengan heading yang jelas dan bagian yang ringkas. Teknik kunci termasuk: pernyataan definisional tebal di 150 kata pertama, heading H2 format pertanyaan, tabel perbandingan, bagian 120-180 kata, dan schema FAQ. Pola-pola ini mendapat hingga 340% lebih banyak kutipan AI.

Apa itu framework evaluasi RAG?

Framework evaluasi RAG menguji seberapa baik asisten AI kamu menemukan dan mengembalikan konten yang relevan. Ia menggunakan query yang telah ditentukan dengan hasil yang diharapkan (ground truth) dan mengukur metrik seperti hit rate, precision, dan temporal diversity. Ini memungkinkan kamu mengoptimasi pengaturan pencarian secara sistematis, bukan menebak.

Mengapa mengganti Beehiiv dengan sistem newsletter kustom?

Sistem newsletter kustom memberi kontrol penuh atas data subscriber, targeting berbasis minat, dan integrasi dengan database yang ada. Dengan membangun di Supabase + Resend, saya mendapat langganan berbasis minat, notifikasi otomatis, dan hosting $0/bulan — semua terintegrasi dengan indeks pencarian Sydney.

Bagaimana Cloudflare Turnstile berbeda dari CAPTCHA tradisional?

Cloudflare Turnstile adalah sistem deteksi bot invisible yang hanya menampilkan tantangan ke pengunjung yang mencurigakan. Berbeda dari CAPTCHA tradisional yang membuat setiap pengguna menyelesaikan puzzle, Turnstile berjalan tanpa suara untuk pengguna yang sah. Ia menggunakan sinyal browser untuk mendeteksi bot tanpa mengganggu pengalaman pengguna.


Masih coding, masih belajar, masih menyaksikan bunga berbunga tumbuh.

Lanjutkan Membaca

Perjalanan Saya
Terhubung
Bahasa
Preferensi