Audit ini berangkat dari pertanyaan saya sendiri sesudah sebuah insiden di situs klien: adakah domain lain yang me-mirror situs ini, dan apakah SEO-nya sudah maksimal? Di situs klien itu, Nginx menerima Host yang tidak dikenalnya dan tetap melayani situs penuh. Catatan audit bertanggal 6 September 2026 menjawab bagian mirror-nya dengan dua kabar sekaligus. Tidak ada mirror pihak ketiga, tetapi ada dua salinan publik, dan dua-duanya milik saya sendiri.
Salinan yang paling serius adalah alias vercel.app produksi milik projek Next yang waktu itu melayani situs ini. Alias itu membalas 200 untuk seluruh 508 URL, lengkap dengan sitemap dan robots.txt, dengan meta robots index,follow dan tanpa header X-Robots-Tag. Projek itu sebenarnya sudah memakai Deployment Protection, dan proteksi itu sama sekali tidak menyentuh aliasnya.
Pola insiden di situs klien tidak bisa terjadi di Vercel
Kekhawatiran pertama adalah domain asing yang A record-nya diarahkan ke IP edge Vercel lalu ikut menyajikan situs ini. Di Vercel itu tidak bisa terjadi, dan ini diuji, bukan diasumsikan:
# ringkasan hasil uji, bukan keluaran mentah
domain asing, A record ke IP edge Vercel TLS diputus sebelum sertifikat ditawarkan
Host asing lewat HTTP polos 404 DEPLOYMENT_NOT_FOUND
SNI yang tidak cocok dengan Host 403, x-vercel-mitigated: denyAlasannya struktural. Vercel merutekan ketat per hostname yang terdaftar di sebuah projek, jadi Host tak dikenal yang tetap dilayani situs penuh, seperti di situs klien tadi, tidak punya jalan di sini.
Pencarian salinan pihak ketiga juga kosong. Delapan kalimat verbatim, delapan penggalan pendek, dan belasan judul artikel saya cari dengan tanda kutip di Yahoo, yang memakai indeks Bing, dan di satu alat pencarian web lain, dan hasilnya nol di host mana pun selain milik saya. Wayback hanya menyimpan lima rekaman robots.txt dari 2018, dan Common Crawl tidak punya satu pun. Dua puluh satu domain yang mirip nama situs ini semuanya NXDOMAIN, dan satu-satunya yang hidup hanyalah domain parkir milik orang lain. Satu subdomain vercel.app dengan nama yang mirip pun ternyata milik orang lain, karena bundelnya memuat akun GitHub lain dan tidak menyebut nama saya sekali pun.
Dua salinan yang ternyata milik saya sendiri
Yang benar-benar ada justru dua salinan milik saya sendiri. Ringkasan pengukurannya, dengan nama host disamarkan:
# ringkasan pengukuran, nama host disamarkan
alias produksi projek Next 200, meta robots index,follow, tanpa X-Robots-Tag,
seluruh 508 URL + sitemap + robots.txt, canonical ke apex
alias projek CRA lama 200, tanpa meta robots, tanpa canonical, robots.txt allow-all
alias berbasis nama tim, 302 ke SSO Vercel, x-robots-tag: noindex
alias cabang main,
dan URL deploymentAlias projek Next adalah salinan utuh situs ini. Canonical-nya memang menunjuk ke apex, tetapi canonical adalah petunjuk yang boleh diabaikan mesin pencari, bukan larangan mengindeks seperti noindex. Bahkan canonical yang benar pun tidak membuat salinan seperti ini aman dengan sendirinya.
Alias projek CRA ceritanya lain. Projek itu dibuat dengan Create React App pada 2025 dan berisi portofolio versi pertama saya, jadi isinya bukan salinan situs yang sekarang. Tetapi dia tetap publik dengan judul portofolio lama saya, tanpa meta robots, tanpa canonical, dan dengan robots.txt yang mengizinkan semua.
Standard Protection melewati production domain
Projek Next itu sudah memakai Standard Protection, dengan ssoProtection.deploymentType bernilai all_except_custom_domains. Dibaca harfiah, nilainya berarti semua kecuali domain kustom, dan alias vercel.app bukan domain kustom yang saya pasang sendiri. Di situ jebakannya. Cakupan Standard Protection tidak pernah mencakup production domain, dan Vercel mengelompokkan alias vercel.app produksi sebagai production domain, sederet dengan domain kustom situs ini. Jadi alias produksi berada di luar proteksi bersama domain kustomnya, sementara alias berbasis nama tim, alias cabang, dan URL deployment tetap tertutup SSO seperti di tabel tadi.
Catatan audit menandai bagian ini sebagai koreksi penting: saran "nyalakan Deployment Protection" itu salah, dan tidak mengubah apa pun untuk alias ini. Menurut syarat plan Vercel yang dicatat audit yang sama, menaikkan cakupan ke All Deployments butuh plan Pro. Catatan itu tidak menyebut dari mana syarat tersebut diketahui, dan tidak ada percobaan menaikkannya yang terekam.
Alias itu tercatat sebagai domain biasa
Jalan keluarnya ternyata ada di tempat yang lebih biasa. Di API projek, alias itu tercatat sebagai domain dengan field redirect yang kosong, field yang sama dengan yang dipakai apex untuk mengalihkan ke www. Artinya barisnya bisa disunting di Settings > Domains projek dan dialihkan 308 ke www. Apakah dialog suntingnya menampilkan pilihan status code belum dipastikan waktu rekomendasi itu ditulis, jadi PATCH ke endpoint domain projek di API Vercel dicatat sebagai jalan pengganti.
Redirect ini masuk daftar tindakan yang tidak boleh menunggu bangun ulang situs ke Astro, karena tidak bergantung framework. Pada 8 September 2026 saya menjalankannya sendiri dari terminal. Sesudahnya alias itu membalas 308 ke www, baik di akar maupun di /blog, padahal sebelumnya menyajikan 508 URL, sementara akar dan /blog di www tetap 200 dan tidak terganggu.
Projek pengganti mendapat alias publiknya sendiri
Masalah yang sama hampir terulang di projek penggantinya. Rencana bangun ulang ke Astro menetapkan projek Vercel baru dengan URL pratinjau sendiri, dan www baru dipindah dari projek lama setelah situs Astro terverifikasi, supaya tidak ada downtime dan balik kanan cukup dengan memindahkan domainnya kembali. Yang sama sekali belum diperhitungkan rencana itu: projek Vercel baru otomatis mendapat production alias *.vercel.app publik sendiri.
Kalau dibiarkan, perkiraannya begini. Dengan robots.txt allow-all yang diminta ceklis M1, milestone yang membangun cangkang situs, alias itu akan menyajikan salinan lengkap 476 artikel dengan index, follow, dan selama masa peralihan dua situs akan hidup bersamaan dengan isi yang sama sampai domain dipindah. Keputusannya, projek Astro memasang X-Robots-Tag: noindex di semua host selain www sampai peralihan selesai.
Penjaganya cukup satu blok di vercel.json. Domain kanonik di bawah ini saya ganti dengan www.example.com, sisanya apa adanya:
{
"source": "/(.*)",
"missing": [
{ "type": "host", "value": "www.example.com" }
],
"headers": [
{ "key": "X-Robots-Tag", "value": "noindex, nofollow" }
]
}Syarat missing membalik logika yang biasa: header dipasang hanya kalau permintaan tidak datang lewat host www. Selama www masih menempel di projek lama, setiap permintaan yang sampai ke projek Astro pasti datang lewat host lain, jadi semuanya mendapat noindex. Begitu domain pindah, permintaan ke www tidak lagi memenuhi syarat itu, dan penjaganya berhenti berlaku sendiri untuk www. Tidak ada yang perlu diingat untuk dicabut.
Blok ini sudah ada sejak commit pertama repo Astro pada 8 September 2026, dan alias projeknya membawa X-Robots-Tag: noindex, nofollow sejak deploy pertama, ketika isinya baru satu halaman penanda tanpa konten asli. Di M1, cangkang situs diverifikasi terhadap deployment sungguhan di alias itu, dan noindex muncul pada halaman maupun aset.
Ada dua sifat umum yang membuat header ini cocok untuk tugas seperti ini. X-Robots-Tag hidup di respons HTTP, jadi berlaku juga untuk berkas yang tidak bisa membawa meta robots, seperti gambar. Noindex juga hanya terbaca kalau crawler boleh mengambil halamannya, sehingga robots.txt yang mengizinkan semua tidak bertabrakan dengan penjaga ini. Kalau alias itu diblokir lewat robots.txt, crawler tidak akan pernah melihat header noindex-nya.
Satu hal yang tidak dikerjakan penjaga ini adalah membuat alias itu privat. Noindex hanya mengatur mesin pencari, dan alias projek Astro tetap publik. Karena itu PUBLIC_GA_ID sengaja dibiarkan kosong sampai domain pindah, supaya data pertama properti GA4 tidak tercemar kunjungan ke alias preview. Untuk kunci API, keputusan saya sebaliknya, dengan konsekuensi yang saya ketahui. Kunci layanan pengirim email dan kunci API model AI tetap terpasang di projek Astro, jadi alur pengiriman CV hidup penuh di alias preview yang publik, alias itu bisa memakai kuota model AI, dan plafon harian keduanya dipakai bersama produksi.
Redirect yang mengunci www
Domain www dipindah ke projek Astro pada 8 September 2026. Rencananya hanya www yang pindah. Apex sengaja ditinggal di projek lama, karena apex tidak menyajikan situs melainkan 308 ke www, dan memindahkannya berisiko apex mulai menyajikan salinan.
Rencana itu tidak bertahan. Vercel menolak melepas www dari projek lama selama masih ada redirect yang menunjuk ke sana, dan salah satunya adalah 308 dari apex yang disetel di dashboard projek itu. Jadi kedua domain harus pindah bersama, dan redirect apex butuh rumah baru lebih dulu. Rumah barunya vercel.json projek Astro, sekali lagi dengan domain diganti example.com:
"redirects": [
{
"source": "/(.*)",
"has": [{ "type": "host", "value": "example.com" }],
"destination": "https://www.example.com/$1",
"permanent": true
}
]permanent: true menghasilkan 308, dan syarat has host membuat redirect ini tidak pernah menyentuh permintaan yang memang sudah datang ke www. Apex lalu dipindahkan antar projek dan tetap 308 tanpa satu record DNS pun disentuh di registrar.
Redirect kedua yang menunjuk ke www adalah perbaikan dari audit tadi, yang baru dipasang hari itu juga: alias vercel.app projek lama dengan 308 ke www. Melepas aliasnya lewat vercel alias rm membuat alias itu 404, tetapi tidak menghapus entri domain berikut setelan redirect-nya, dan vercel domains ls maupun project inspect tidak menampilkan medan itu sama sekali. Kebuntuannya baru terbongkar lewat REST API Vercel dengan token milik CLI sendiri, yang di macOS tersimpan di ~/Library/Application Support/com.vercel.cli/auth.json.
# disederhanakan, nama projek disamarkan
GET /v9/projects/<projek>/domains
tiap domain membawa redirect dan redirectStatusCode,
dua medan yang tidak pernah muncul di CLI
PATCH medan redirect domain alias itu menjadi null
kuncinya terbukaYang saya hapus adalah redirect-nya, bukan domainnya, karena redirect bisa dikembalikan.
Sesudah www pindah, alias projek Next tidak bisa lagi di-redirect ke www. Redirect itu dulu hanya mungkin karena www masih menempel di projek yang sama, sebab Vercel hanya mengizinkan sebuah domain dialihkan ke domain yang ada di projek yang sama. Aturan yang sama sejak awal menutup jalan untuk alias projek CRA lama, padahal keputusan sebelumnya adalah mengarahkan projek itu 308 ke www, bukan menghapusnya.
Pilihan yang tersisa tinggal membiarkannya 200 atau melepas aliasnya. Saya melepas aliasnya, karena projek beserta seluruh deployment-nya tetap utuh, dan menghidupkannya lagi cukup dengan memasang aliasnya kembali. Per 8 September 2026 kedua alias lama itu 404, dan tidak ada salinan publik yang tersisa. Verifikasi di situs hidup sesudah domain pindah lulus 14 dari 14, apex tetap 308 ke www, dan penjaga noindex berhenti sendiri seperti dirancang.
Keputusan ini ada harganya. Sesudah domain pindah, situs Next tidak bisa lagi dipakai sebagai acuan pembanding, karena URL deployment-nya dilindungi SSO Vercel dan alias publiknya sudah dihapus.
Yang belum terjawab
Satu pertanyaan tidak pernah terjawab di catatan saya: apakah Google sempat mengindeks kedua alias lama itu. Yahoo dengan indeks Bing dan alat pencarian web tadi sama-sama memberi nol hasil, tetapi keduanya bukan indeks Google. Yang tercatat untuk itu hanya rencana pemeriksaan, yaitu kueri site: per alias untuk dijalankan di browser saya sendiri, dan hasilnya tidak pernah tercatat.
Untuk projek Vercel berikutnya, urutannya kira-kira begini. Ukur setiap host yang dijawab projek itu, bukan hanya domain kustomnya, karena alias produksi bisa menyajikan seluruh situs dengan index,follow. Jangan mengandalkan Standard Protection untuk menutup alias itu, karena Vercel menghitungnya sebagai production domain. Pasang penjaga noindex dengan syarat missing host sebelum deploy pertama projek baru, supaya dia berhenti sendiri begitu domain kanonik pindah. Sebelum memindahkan domain antar projek, periksa medan redirect di setiap domain projek lewat REST API, karena CLI tidak menampilkannya.