Alamat WordPress vs Alamat Situs: Perbedaan Teknis, Konfigurasi, dan Kesalahan Umum

WordPress Address (URL) dan Site Address (URL) adalah dua parameter konfigurasi berbeda yang mengontrol, masing-masing, di mana file inti WordPress berada di server dan URL apa yang digunakan publik untuk mengakses bagian depan situs Anda. Pada sebagian besar instalasi standar, kedua nilai ini identik, tetapi keduanya bisa — dan terkadang harus — berbeda ketika Anda menghosting file WordPress di subdirektori sambil menyajikan situs dari domain root.

Kesalahan pada kedua nilai ini, bahkan satu karakter saja, dapat mengunci Anda dari dasbor admin, memicu peringatan mixed-content, merusak endpoint REST API, dan mengacaukan rantai redirect. Bagian-bagian di bawah ini menjelaskan logika arsitektur di balik setiap pengaturan, setiap skenario yang sah untuk mengubahnya, dan metode yang tepat untuk melakukannya dengan aman.

Logika Arsitektur di Balik Dua Parameter URL

WordPress menyimpan konfigurasi URL-nya di dua tempat secara bersamaan: tabel database wp_options (baris siteurl dan home) dan, secara opsional, file wp-config.php melalui konstanta PHP. Memahami sumber mana yang lebih diprioritaskan sangat penting sebelum mengubah apa pun.

Urutan prioritas (tertinggi ke terendah):

1. Konstanta yang didefinisikan di wp-config.php (WP_SITEURL, WP_HOME)
2. Nilai yang tersimpan di tabel wp_options
3. Nilai yang dimasukkan di Settings > General di dasbor

Ketika sebuah konstanta didefinisikan di wp-config.php, kolom yang sesuai di Settings > General menjadi hanya-baca dan berwarna abu-abu. Ini disengaja — untuk mencegah penimpaan yang tidak disengaja melalui UI sambil tetap memungkinkan kontrol secara programatik.

WordPress Address (URL) — WP_SITEURL

WordPress Address dipetakan ke opsi siteurl di wp_options dan konstanta WP_SITEURL di wp-config.php. Ini memberi tahu WordPress di mana file PHP inti, direktori wp-admin, dan direktori wp-includes secara fisik berada. WordPress menggunakan nilai ini untuk membangun setiap referensi jalur file internal, termasuk URL login admin, endpoint AJAX (/wp-admin/admin-ajax.php), dan basis REST API (/wp-json/).

Contoh: jika instalasi WordPress Anda berada di https://example.com/wordpress, maka WP_SITEURL harus berupa https://example.com/wordpress. Menavigasi ke https://example.com/wordpress/wp-admin akan membuka dasbor.

Site Address (URL) — WP_HOME

Site Address dipetakan ke opsi home di wp_options dan konstanta WP_HOME di wp-config.php. Ini mendefinisikan URL publik kanonik — alamat yang diketik pengguna di browser mereka dan basis dari mana WordPress menghasilkan semua struktur permalink bagian depan.

Contoh: meskipun file inti berada di https://example.com/wordpress, Anda dapat mengatur WP_HOME ke https://example.com sehingga halaman utama, posting, dan halaman disajikan dari domain root. Ini memerlukan file index.php tambahan dan aturan .htaccess di root (dibahas di bawah).

Perbandingan: WordPress Address vs Site Address

Kapan Kedua Nilai Ini Harus Berbeda

Alasan sah yang paling umum untuk memisahkan WP_SITEURL dan WP_HOME adalah pola instalasi subdirektori: Anda ingin file WordPress diisolasi di subdirektori yang bersih (misalnya, /wordpress atau /cms) sementara situs publik diselesaikan di domain root. Ini adalah pilihan arsitektur yang disengaja, bukan solusi sementara.

Skenario lain yang mengharuskan pembaruan satu atau kedua nilai:

• Migrasi domain — berpindah dari http://old-domain.com ke https://new-domain.com mengharuskan pembaruan kedua nilai secara bersamaan.
• Peningkatan HTTP ke HTTPS — menambahkan sertifikat SSL berarti mengubah awalan protokol di kedua pengaturan dari http:// ke https://. Memperbarui hanya satu akan menghasilkan kesalahan mixed-content.
• Promosi staging ke produksi — lingkungan staging biasanya berjalan di subdomain atau domain yang berbeda; kedua nilai harus ditulis ulang selama deployment.
• Reverse proxy atau offloading CDN — ketika load balancer atau CDN mengakhiri SSL dan meneruskan lalu lintas ke server backend, pengaturan URL WordPress harus mencerminkan domain yang menghadap publik, bukan alamat server internal.
• Rekonfigurasi jaringan Multisite — di WordPress Multisite, WP_SITEURL dan WP_HOME berinteraksi dengan konstanta DOMAIN_CURRENT_SITE dan PATH_CURRENT_SITE, membuat konfigurasi yang benar menjadi semakin kritis.

Metode 1: Perbarui melalui Dasbor WordPress

Ini adalah metode yang tepat ketika Anda masih memiliki akses admin dan perubahannya sederhana (misalnya, HTTP ke HTTPS di domain yang sama).

1. Masuk ke https://yourdomain.com/wp-admin.
2. Navigasi ke Settings > General.
3. Temukan kolom WordPress Address (URL) dan Site Address (URL).
4. Perbarui kedua nilai sesuai kebutuhan.
5. Klik Save Changes.

WordPress akan segera mengarahkan Anda ke URL admin yang diperbarui. Jika Anda mengubah domain, browser Anda akan mengikuti redirect ke alamat baru. Jika domain baru belum mengarah ke server, Anda akan kehilangan akses dasbor — rencanakan propagasi DNS dengan tepat.

Metode 2: Definisikan Konstanta di wp-config.php

Metode ini lebih disukai di server produksi karena mencegah perubahan UI yang tidak disengaja, bekerja bahkan ketika database sementara tidak tersedia, dan mudah dikontrol versinya. Di lingkungan VPS Hosting dengan akses SSH root, ini adalah pendekatan yang paling andal.

Buka wp-config.php di editor pilihan Anda:

nano /var/www/html/wp-config.php

Tambahkan dua baris berikut di atas komentar /* That's all, stop editing! */:

define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );

Untuk pola instalasi subdirektori di mana file inti berada di /wordpress tetapi situs disajikan dari root:

define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com/wordpress' );

Simpan dan tutup file. Kolom dasbor sekarang akan menjadi hanya-baca, yang merupakan perilaku yang diharapkan.

Instalasi Subdirektori: Langkah .htaccess dan index.php yang Diperlukan

Ketika WP_HOME dan WP_SITEURL berbeda, WordPress saja tidak dapat merutekan permintaan domain root ke file inti di subdirektori. Anda harus menempatkan index.php yang dimodifikasi dan file .htaccess di document root.

Langkah 1: Salin index.php dari subdirektori WordPress ke root:

cp /var/www/html/wordpress/index.php /var/www/html/index.php

Langkah 2: Edit /var/www/html/index.php yang disalin untuk menunjuk ke subdirektori:

<?php
// WordPress view bootstrapper
define( 'WP_USE_THEMES', true );

/** Loads the WordPress Environment and Template */
require __DIR__ . '/wordpress/wp-blog-header.php';

Langkah 3: Pastikan .htaccess root Anda berisi blok rewrite WordPress standar:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Jangan salin .htaccess dari subdirektori — ini akan berisi RewriteBase /wordpress/ yang akan merusak perutean domain root.

Metode 3: Pembaruan Database Langsung melalui WP-CLI

Ketika dasbor tidak dapat diakses dan Anda lebih memilih untuk tidak menyentuh wp-config.php secara permanen, WP-CLI menyediakan solusi yang bersih dan dapat di-script. Ini sangat berguna di Dedicated Servers yang menjalankan pipeline deployment otomatis.

wp option update siteurl 'https://example.com' --path=/var/www/html
wp option update home 'https://example.com' --path=/var/www/html

Untuk memverifikasi perubahan telah diterapkan:

wp option get siteurl --path=/var/www/html
wp option get home --path=/var/www/html

WP-CLI menghormati konstanta wp-config.php — jika WP_SITEURL atau WP_HOME sudah didefinisikan di sana, perintah wp option update tidak akan menimpanya. Anda harus memperbarui konstanta langsung di file tersebut.

Metode 4: Pembaruan MySQL Langsung (Pilihan Terakhir)

Gunakan ini hanya ketika akses SSH tersedia tetapi WP-CLI tidak terinstal dan dasbor terkunci. Identifikasi awalan tabel Anda terlebih dahulu (periksa $table_prefix di wp-config.php, umumnya wp_).

mysql -u db_user -p db_name

UPDATE wp_options SET option_value = 'https://example.com' WHERE option_name = 'siteurl';
UPDATE wp_options SET option_value = 'https://example.com' WHERE option_name = 'home';

Konfirmasi pembaruan:

SELECT option_name, option_value FROM wp_options WHERE option_name IN ('siteurl', 'home');

Keluar dari MySQL dan bersihkan cache objek apa pun (Redis, Memcached, atau OPcache) sebelum menguji situs.

Konfigurasi SSL dan Pembaruan URL

Peningkatan dari HTTP ke HTTPS adalah alasan paling umum untuk memperbarui kedua parameter URL secara bersamaan. Setelah menginstal sertifikat SSL — baik melalui Let’s Encrypt via Certbot atau sertifikat komersial dari penyedia seperti yang tersedia melalui SSL Certificates — Anda harus memperbarui WP_HOME dan WP_SITEURL untuk menggunakan awalan https://.

Gagal memperbarui keduanya, atau hanya memperbarui satu, menghasilkan peringatan mixed-content: browser menerima halaman HTTPS yang mereferensikan aset HTTP (skrip, stylesheet, gambar). Browser modern memblokir konten aktif campuran sepenuhnya, yang merusak fungsionalitas JavaScript dan dasbor admin.

Setelah memperbarui konstanta URL, jalankan pencarian-dan-penggantian pada database untuk memperbarui semua URL terserialisasi yang tersimpan di konten posting, postmeta, dan opsi:

wp search-replace 'http://example.com' 'https://example.com' --all-tables --path=/var/www/html

Flag --all-tables memastikan data terserialisasi di tabel kustom (WooCommerce, page builder) juga diperbarui. Selalu buat cadangan database sebelum menjalankan perintah ini.

Mengonfigurasi URL WordPress dengan cPanel

Jika Anda mengelola WordPress di VPS dengan cPanel, Anda dapat menggunakan cPanel File Manager untuk mengedit wp-config.php tanpa memerlukan akses SSH:

1. Masuk ke cPanel dan buka File Manager.
2. Navigasi ke document root WordPress Anda (biasanya public_html atau subdirektori).
3. Klik kanan wp-config.php dan pilih Edit.
4. Tambahkan konstanta WP_HOME dan WP_SITEURL seperti yang ditunjukkan di Metode 2.
5. Simpan file.

Atau, gunakan alat phpMyAdmin di cPanel untuk menjalankan pernyataan SQL UPDATE dari Metode 4 langsung terhadap database WordPress Anda.

Jebakan Kritis dan Kasus Tepi

Ketidakcocokan protokol antara dua pengaturan. Mengatur WP_SITEURL ke https://example.com dan WP_HOME ke http://example.com (atau sebaliknya) menciptakan loop redirect. Browser mengikuti redirect HTTPS dari server, tetapi WordPress menghasilkan tautan bagian depan HTTP, yang kemudian diarahkan kembali ke HTTPS oleh server. Loop ini tidak terlihat di dasbor tetapi sangat merusak bagi crawler dan pengguna.

Inkonsistensi garis miring di akhir. WordPress sensitif terhadap garis miring di akhir dalam konstanta ini. https://example.com dan https://example.com/ diperlakukan sebagai nilai yang berbeda. Selalu hilangkan garis miring di akhir pada kedua konstanta untuk memenuhi ekspektasi internal WordPress.

Keracunan cache objek setelah perubahan URL. Jika server Anda menjalankan cache objek persisten (Redis atau Memcached), nilai URL lama mungkin masih tersimpan di memori meskipun database telah diperbarui. Bersihkan cache objek segera setelah perubahan URL apa pun:

wp cache flush --path=/var/www/html

Data terserialisasi di database. WordPress menyimpan banyak nilai opsi dan metadata posting sebagai string terserialisasi PHP. Penggantian string yang naif (misalnya, menggunakan sed pada dump database) akan merusak data terserialisasi dengan membatalkan awalan jumlah byte. Selalu gunakan perintah search-replace WP-CLI, yang menangani serialisasi dengan benar.

Pertimbangan jaringan Multisite. Dalam instalasi WordPress Multisite, WP_SITEURL berlaku untuk admin jaringan, bukan subsitus individual. Setiap subsitus memiliki entri siteurl dan home sendiri di tabel wp_X_options masing-masing. Perubahan URL di seluruh jaringan mengharuskan pembaruan tabel opsi setiap subsitus, yang ditangani WP-CLI dengan flag --network:

wp search-replace 'http://old-domain.com' 'https://new-domain.com' --all-tables --network --path=/var/www/html

Kepercayaan header reverse proxy. Di server di balik load balancer atau Nginx reverse proxy, WordPress mungkin mendeteksi protokol yang salah jika proxy tidak meneruskan header X-Forwarded-Proto. Bahkan dengan konstanta URL yang benar, tautan internal dapat kembali ke HTTP. Tambahkan yang berikut ke wp-config.php untuk memaksa deteksi HTTPS:

if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && 'https' === $_SERVER['HTTP_X_FORWARDED_PROTO'] ) {
    $_SERVER['HTTPS'] = 'on';
}

Memverifikasi Konfigurasi Setelah Perubahan

Setelah memperbarui salah satu parameter URL, lakukan langkah verifikasi berikut sebelum menganggap perubahan selesai:

# Confirm wp_options values reflect the change
wp option get siteurl --path=/var/www/html
wp option get home --path=/var/www/html

# Check for mixed-content issues using curl
curl -sI https://example.com | grep -i location

# Verify the REST API is reachable at the correct base
curl -s https://example.com/wp-json/ | python3 -m json.tool | head -20

# Confirm no HTTP references remain in post content
wp search-replace --dry-run 'http://example.com' 'https://example.com' --all-tables --path=/var/www/html

Flag --dry-run pada perintah terakhir melaporkan berapa banyak penggantian yang akan dilakukan tanpa benar-benar memodifikasi data. Jika hitungannya nol, migrasi bersih.

Bagi tim yang mengelola beberapa instans WordPress di lingkungan Shared Web Hosting atau VPS, mengotomatiskan langkah verifikasi ini dalam skrip pasca-deployment menghilangkan risiko meluncurkan situs dengan referensi URL yang sudah usang.

Matriks Keputusan: Metode Mana yang Digunakan

Daftar Periksa Poin Teknis Utama

• Selalu perbarui WP_SITEURL dan WP_HOME bersama-sama kecuali Anda sengaja membutuhkan pola subdirektori.
• Definisikan konstanta di wp-config.php di server produksi untuk mencegah penimpaan UI yang tidak disengaja.
• Setelah perubahan URL apa pun, bersihkan cache objek dan jalankan wp search-replace dengan --all-tables untuk menangkap data terserialisasi.
• Untuk migrasi HTTP ke HTTPS, perbarui konstanta URL terlebih dahulu, kemudian jalankan search-replace, lalu verifikasi dengan curl untuk mixed-content.
• Dalam instalasi subdirektori, index.php root harus mereferensikan jalur subdirektori, dan .htaccess harus menggunakan RewriteBase /.
• Jangan pernah menggunakan garis miring di akhir dalam konstanta WP_HOME atau WP_SITEURL.
• Pada pengaturan reverse-proxy, tambahkan deteksi HTTP_X_FORWARDED_PROTO ke wp-config.php atau WordPress akan menghasilkan referensi protokol yang salah terlepas dari pengaturan URL.
• Di Multisite, tabel wp_X_options setiap subsitus harus diperbarui secara independen; gunakan flag --network dengan WP-CLI.

Pertanyaan yang Sering Diajukan

Apa yang terjadi jika WordPress Address dan Site Address berbeda tanpa pengaturan subdirektori?

WordPress akan mencoba memuat file inti dari jalur yang ditentukan di WP_SITEURL. Jika tidak ada instalasi WordPress di jalur tersebut, semua permintaan admin akan mengembalikan kesalahan 404 atau layar putih. Bagian depan mungkin masih dimuat jika WP_HOME benar dan aturan rewrite masih utuh, tetapi permintaan AJAX, panggilan REST API, atau tindakan admin apa pun akan gagal.

Bisakah saya mengatur WP_HOME dan WP_SITEURL ke protokol yang berbeda (satu HTTP, satu HTTPS)?

Tidak. Mencampur protokol antara dua konstanta menciptakan loop redirect yang tidak dapat diselesaikan oleh browser maupun crawler. Kedua konstanta harus menggunakan protokol yang sama. Jika Anda menerapkan HTTPS di tingkat server (melalui Nginx atau Apache), kedua konstanta harus menggunakan https://.

Mengapa kolom WordPress Address berwarna abu-abu di Settings > General?

Kolom tersebut hanya-baca karena WP_SITEURL (atau WP_HOME) didefinisikan sebagai konstanta PHP di wp-config.php. Konstanta yang didefinisikan dalam kode lebih diprioritaskan daripada nilai database dan tidak dapat ditimpa melalui UI. Untuk membuat kolom dapat diedit kembali, hapus atau komentari baris define() yang sesuai di wp-config.php.

Apakah mengubah Site Address memengaruhi SEO dan backlink yang ada?

Ya. Mengubah WP_HOME mengubah URL kanonik dasar untuk setiap halaman di situs Anda. Tanpa redirect 301 yang tepat dari struktur URL lama ke yang baru, mesin pencari akan memperlakukan URL lama dan baru sebagai halaman terpisah, membagi ekuitas tautan dan berpotensi memicu penalti konten duplikat. Selalu konfigurasikan redirect 301 di tingkat server sebelum atau bersamaan dengan perubahan URL.

Bagaimana cara memulihkan jika saya memasukkan URL yang salah dan sekarang terkunci dari wp-admin?

Hubungkan ke server Anda melalui SSH dan definisikan konstanta yang benar di wp-config.php menggunakan Metode 2, atau gunakan WP-CLI untuk memperbarui opsi siteurl dan home langsung melalui Metode 3. Jika keduanya tidak tersedia, gunakan phpMyAdmin atau koneksi MySQL langsung untuk menjalankan pernyataan UPDATE dari Metode 4. Setelah akses dipulihkan, hapus konstanta sementara apa pun jika Anda lebih suka dasbor yang mengelola nilai-nilai tersebut ke depannya.