Cara Menghapus “wordpress” Dari URL Situs Anda (Panduan Teknis Lengkap)

Ketika WordPress diinstal ke subdirektori bernama /wordpress, setiap URL yang menghadap publik membawa segmen jalur tersebut — yourdomain.com/wordpress/about, yourdomain.com/wordpress/shop — yang merusak kredibilitas merek dan mengurangi ekuitas SEO. Solusinya adalah migrasi file yang terkontrol dikombinasikan dengan pembaruan URL database: Anda memindahkan semua file inti WordPress dari subdirektori ke document root server (public_html), memperbarui pengaturan WordPress Address dan Site Address, meregenerasi aturan rewrite, dan menerbitkan redirect 301 untuk URL lama yang telah diindeks. Tidak diperlukan instalasi ulang.

Panduan ini mencakup setiap lapisan teknis dari proses tersebut — operasi sistem file, penggantian string database, logika rewrite .htaccess, strategi redirect, dan validasi pasca-migrasi — termasuk kasus tepi yang menyebabkan kegagalan diam dalam sebagian besar tutorial.

Mengapa WordPress Berakhir di Subdirektori

Memahami akar penyebabnya mencegah masalah yang sama terulang kembali. Skenario yang paling umum adalah:

• Default installer: Banyak installer satu klik (Softaculous, Installatron) secara default menggunakan jalur subdirektori jika pengguna tidak secara eksplisit menetapkan jalur instalasi ke /.
• Promosi staging ke produksi: Seorang developer menginstal WordPress di /wordpress untuk pengujian dan situs tersebut ditayangkan tanpa koreksi jalur.
• Perencanaan multi-situs yang tidak terwujud: Seseorang mengantisipasi menjalankan beberapa CMS di bawah satu domain dan menempatkan WordPress di foldernya sendiri.
• Keanehan auto-installer cPanel: Di lingkungan VPS dengan cPanel, installer terkadang menambahkan nama aplikasi sebagai subdirektori kecuali ditimpa.

Terlepas dari asalnya, prosedur migrasi adalah identik.

Daftar Periksa Pra-Migrasi

Sebelum menyentuh satu file pun, selesaikan setiap item dalam daftar ini. Melewatkan salah satunya adalah penyebab utama downtime selama operasi ini.

• Backup situs lengkap: Arsipkan sistem file dan database MySQL. Plugin seperti UpdraftPlus atau Duplicator bekerja dengan baik; begitu juga snapshot tingkat server jika penyedia VPS Hosting Anda mendukungnya.
• Kredensial database tersedia: Anda akan membutuhkannya jika pengeditan wp-config.php manual menjadi diperlukan.
• Mode pemeliharaan aktif: Gunakan plugin atau tambahkan define('WP_MAINTENANCE_MODE', true); sementara untuk mencegah penulisan selama jendela migrasi.
• Pencatatan error PHP diaktifkan: Atur WP_DEBUG_LOG ke true di wp-config.php sehingga error pasca-migrasi ditulis ke /wp-content/debug.log daripada muncul di layar.
• TTL DNS dicatat: Jika perubahan DNS juga terlibat, turunkan TTL ke 300 detik setidaknya satu jam sebelum memulai.

Langkah 1: Pindahkan File WordPress ke Document Root

Tujuannya adalah menyalin semua yang ada di dalam /public_html/wordpress/ langsung ke /public_html/ — bukan foldernya sendiri, melainkan isinya.

Menggunakan Klien FTP (FileZilla)

1. Hubungkan ke server Anda melalui SFTP (port 22) daripada FTP biasa untuk menghindari intersepsi kredensial.
2. Navigasi ke public_html/wordpress/.
3. Pilih semua file dan folder termasuk file tersembunyi. Di FileZilla, aktifkan View > Show Hidden Files untuk menampilkan .htaccess dan file .env apa pun.
4. Seret pilihan tersebut satu tingkat direktori ke atas ke public_html/.
5. Ketika diminta tentang penimpaan index.php (jika ada placeholder di root), konfirmasi penimpaan.

Menggunakan Command Line (Direkomendasikan untuk VPS)

Jika Anda memiliki akses SSH — yang seharusnya ada di lingkungan VPS Hosting atau Dedicated Server yang dikonfigurasi dengan benar — pendekatan command-line lebih cepat dan menghindari masalah timeout FTP pada instalasi besar:

# Navigate to the document root
cd /var/www/html/public_html

# Copy all contents (including hidden files) from the subdirectory to the root
cp -a wordpress/. .

# Verify the copy succeeded before deleting anything
ls -la | head -30

Jangan hapus direktori /wordpress dulu. Biarkan tetap utuh sampai migrasi sepenuhnya divalidasi. Anda dapat menghapusnya di langkah pembersihan akhir.

Kasus Tepi Kritis: Symlink dan Absolute Path di Plugin

Beberapa plugin (terutama plugin backup dan keamanan) menyimpan absolute path file di database — misalnya, /var/www/html/public_html/wordpress/wp-content/uploads/2024/01/image.jpg. Ini akan rusak secara diam-diam setelah pemindahan. Pencarian-dan-penggantian database di Langkah 5 menangani hal ini, tetapi Anda harus menyertakan tabel wp_options dan tabel plugin kustom apa pun dalam cakupan penggantian.

Langkah 2: Perbarui WordPress Address dan Site Address

WordPress menyimpan dua nilai URL kritis di tabel wp_options: siteurl (WordPress Address, menunjuk ke lokasi file inti WordPress berada) dan home (Site Address, URL yang digunakan pengunjung untuk mengakses situs). Keduanya harus diperbarui.

Metode A: Dashboard WordPress

1. Masuk ke yourdomain.com/wordpress/wp-admin — ini masih berfungsi karena file masih ada di kedua lokasi pada titik ini.
2. Pergi ke Settings > General.
3. Perbarui kedua bidang:

• WordPress Address (URL): https://yourdomain.com
• Site Address (URL): https://yourdomain.com

1. Klik Save Changes.

Metode B: Edit Database Langsung (Ketika Dashboard Tidak Dapat Diakses)

Jika dashboard sudah tidak dapat dijangkau, gunakan WP-CLI atau phpMyAdmin:

# Using WP-CLI from the document root
wp option update siteurl 'https://yourdomain.com'
wp option update home 'https://yourdomain.com'

Atau di phpMyAdmin, jalankan:

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

Ganti wp_ dengan prefiks tabel aktual Anda jika diubah selama instalasi.

Metode C: Override Sementara wp-config.php

Jika dashboard dan database keduanya sementara tidak dapat diakses, tambahkan dua baris ini ke wp-config.php sebagai override bootstrap:

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

Ini menimpa apa pun yang tersimpan di database. Hapus baris-baris ini setelah mengonfirmasi bahwa dashboard dapat diakses dan nilai database telah diperbarui secara permanen.

Langkah 3: Verifikasi dan Perbarui File .htaccess

File .htaccess di document root mengontrol penulisan ulang URL Apache untuk WordPress. Setelah memindahkan file, file ini seharusnya sudah ada di public_html/ — tetapi direktif RewriteBase-nya harus mencerminkan instalasi tingkat root yang baru.

Buka public_html/.htaccess dan pastikan berisi blok rewrite WordPress berikut ini dengan tepat:

# 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

Perubahan utama dari instalasi subdirektori adalah RewriteBase / alih-alih RewriteBase /wordpress/. Jika baris ini salah, semua permalink cantik mengembalikan error 404 sementara beranda memuat dengan benar — tanda diagnostik klasik dari RewriteBase yang salah dikonfigurasi.

Pengguna Nginx: WordPress tidak menggunakan .htaccess. Perbarui direktif try_files blok server Anda sebagai gantinya:

location / {
    try_files $uri $uri/ /index.php?$args;
}

Langkah 4: Flush Struktur Permalink

WordPress menyimpan cache aturan rewrite di database. Setelah mengubah URL situs, aturan yang di-cache tersebut mereferensikan struktur jalur lama dan harus diregenerasi.

1. Pergi ke Settings > Permalinks di dashboard WordPress.
2. Tanpa mengubah struktur permalink yang dipilih, klik Save Changes.

Ini memaksa WordPress untuk membangun ulang dan menyimpan cache aturan rewrite terhadap jalur tingkat root yang baru. Sebagai alternatif, gunakan WP-CLI:

wp rewrite flush --hard

Flag --hard meregenerasi file .htaccess selain mem-flush cache database — berguna jika Anda tidak yakin apakah .htaccess sudah benar.

Langkah 5: Penggantian URL di Seluruh Database

Memindahkan file dan memperbarui siteurl/home saja tidak cukup. WordPress menyimpan string URL yang diserialisasi di seluruh database — dalam konten posting, postmeta, pengaturan widget, opsi tema, dan tabel konfigurasi plugin. Referensi jalur /wordpress yang tersisa akan menghasilkan gambar yang rusak, tag kanonik yang salah, dan fitur plugin yang tidak berfungsi.

Menggunakan Plugin Better Search Replace

1. Instal dan aktifkan plugin Better Search Replace.
2. Pergi ke Tools > Better Search Replace.
3. Konfigurasikan penggantian:

• Search for: https://yourdomain.com/wordpress
• Replace with: https://yourdomain.com

1. Pilih semua tabel database.
2. Hapus centang Run as dry run? hanya setelah mengonfirmasi bahwa dry run menunjukkan jumlah penggantian yang diharapkan.
3. Klik Run Search/Replace.

Juga jalankan pass kedua untuk absolute path server:

• Search for: /public_html/wordpress
• Replace with: /public_html

Menggunakan WP-CLI (Diutamakan untuk Produksi)

Perintah search-replace WP-CLI menangani data yang diserialisasi dengan benar, yang tidak dilakukan oleh fungsi SQL REPLACE() biasa:

wp search-replace 'https://yourdomain.com/wordpress' 'https://yourdomain.com' --all-tables --precise --report-changed-only

Jalankan pass kedua untuk absolute path sistem file:

wp search-replace '/public_html/wordpress' '/public_html' --all-tables --precise --report-changed-only

Flag --precise menggunakan penggantian yang sadar serialisasi PHP daripada regex, yang mencegah kerusakan array yang diserialisasi yang tersimpan di database.

Langkah 6: Implementasikan Redirect 301 untuk Kesinambungan SEO

Jika situs telah dapat diakses publik di URL /wordpress — dan terutama jika URL tersebut telah diindeks oleh Google atau ditautkan dari sumber eksternal — redirect permanen adalah wajib, bukan opsional. Tanpanya, setiap URL yang diindeks menjadi 404, dan semua ekuitas tautan yang terkumpul akan hilang.

Tambahkan aturan redirect berikut ke public_html/.htaccess, di atas blok rewrite WordPress:

# Redirect legacy /wordpress/ URLs to root
RewriteEngine On
RewriteRule ^wordpress/(.*)$ /$1 [R=301,L]

Aturan ini menangkap setiap permintaan yang dimulai dengan wordpress/ dan mengarahkannya ke jalur tingkat root yang setara. Misalnya:

• yourdomain.com/wordpress/about/ → yourdomain.com/about/
• yourdomain.com/wordpress/wp-admin/ → yourdomain.com/wp-admin/

Catatan penempatan penting: Blok redirect ini harus muncul sebelum komentar # BEGIN WordPress. Aturan rewrite WordPress sendiri akan mencegat permintaan terlebih dahulu jika redirect ditempatkan setelahnya.

Untuk Nginx, tambahkan ini ke blok server:

rewrite ^/wordpress/(.*)$ /$1 permanent;

Langkah 7: Validasi Pasca-Migrasi

Pengujian sistematis mencegah kegagalan diam tidak terdeteksi di produksi.

Pemeriksaan Fungsional

Validasi Command-Line

# Verify the homepage returns 200
curl -I https://yourdomain.com

# Verify the legacy URL issues a 301
curl -I https://yourdomain.com/wordpress/

# Check that wp-admin is reachable
curl -I https://yourdomain.com/wp-admin/

Google Search Console

Kirimkan sitemap yang diperbarui di Google Search Console segera setelah validasi. Gunakan alat URL Inspection untuk meminta pengindeksan ulang beranda. Pantau laporan Coverage selama 48–72 jam berikutnya untuk setiap lonjakan error 404, yang akan mengindikasikan penggantian URL yang terlewat.

Langkah 8: Pembersihan dan Penguatan Akhir

Setelah situs berjalan stabil di URL root selama 24–48 jam:

1. Hapus subdirektori /wordpress dari server. Membiarkannya di tempat menciptakan risiko konten duplikat dan mengekspos titik masuk sekunder ke instalasi WordPress.

rm -rf /var/www/html/public_html/wordpress

1. Hapus konstanta WP_MAINTENANCE_MODE dari wp-config.php jika Anda menambahkannya.
2. Hapus define WP_HOME/WP_SITEURL sementara dari wp-config.php jika Anda menggunakan Metode C di Langkah 2.
3. Verifikasi cakupan SSL: Jika SSL Certificate Anda diterbitkan untuk yourdomain.com/wordpress sebagai cakupan berbasis jalur (tidak umum tetapi mungkin dalam beberapa konfigurasi), konfirmasi bahwa sertifikat mencakup domain apex dengan benar.
4. Perbarui konfigurasi DNS atau CDN eksternal apa pun yang mungkin telah menyimpan cache struktur jalur lama.
5. Bersihkan semua lapisan caching: Hapus cache halaman sisi server, cache objek (Redis/Memcached), dan cache CDN. Entri cache yang basi untuk URL /wordpress akan menyajikan konten yang salah bahkan setelah migrasi selesai.

Perbandingan: Metode Migrasi Sekilas

Untuk lingkungan apa pun dengan akses SSH — termasuk Dedicated Server dan instans VPS yang tidak dikelola — pendekatan WP-CLI adalah opsi yang paling andal dan paling sedikit rawan kesalahan.

Matriks Keputusan Teknis

Gunakan matriks ini untuk menentukan langkah mana yang wajib versus situasional untuk skenario spesifik Anda:

Poin Utama

• Operasi inti adalah: salin file ke document root, perbarui siteurl dan home di database, perbaiki .htaccess RewriteBase, jalankan pencarian-penggantian yang sadar serialisasi, tambahkan redirect 301.
• Jangan pernah menggunakan SQL REPLACE() biasa pada tabel WordPress tanpa penanganan serialisasi — ini akan merusak nilai opsi dan merusak plugin secara diam-diam.
• Direktif .htaccess RewriteBase / adalah elemen yang paling sering salah dikonfigurasi dalam migrasi ini; nilai yang salah menghasilkan 404 pada semua URL berbasis permalink sementara beranda terus dimuat.
• Redirect 301 bukan kosmetik — mereka mentransfer ekuitas tautan dan mencegah fragmentasi indeks. Mereka wajib untuk situs apa pun dengan visibilitas pencarian yang ada.
• Hapus direktori /wordpress asli hanya setelah jendela observasi stabil 24 jam.
• Jika Anda menjalankan WordPress di VPS dengan cPanel, gunakan opsi Show Hidden Files File Manager untuk memastikan .htaccess disertakan dalam operasi salin.

Pertanyaan yang Sering Diajukan

Apakah menghapus /wordpress dari URL akan memengaruhi peringkat SEO saya?

Dalam jangka pendek, harapkan fluktuasi peringkat kecil saat Googlebot merayapi ulang URL baru. Jika redirect 301 diimplementasikan dengan benar, ekuitas tautan ditransfer sepenuhnya dan peringkat biasanya stabil dalam dua hingga empat minggu. Melewatkan redirect 301 menyebabkan kehilangan peringkat permanen untuk semua halaman yang sebelumnya diindeks.

Bagaimana jika dashboard WordPress saya tidak dapat diakses setelah memindahkan file?

Penyebab paling umum adalah ketidakcocokan antara nilai siteurl di database dan lokasi file yang sebenarnya. Gunakan WP-CLI (wp option update siteurl) atau tambahkan define('WP_SITEURL', 'https://yourdomain.com'); ke wp-config.php sebagai override sementara untuk memulihkan akses.

Apakah saya perlu memperbarui wp-config.php setelah memindahkan WordPress ke root?

Dalam kebanyakan kasus, tidak. File wp-config.php menggunakan jalur relatif untuk koneksi database dan tidak meng-hardcode jalur instalasi. Pengecualiannya adalah jika ABSPATH telah didefinisikan secara manual sebagai absolute path yang menunjuk ke direktori /wordpress lama — dalam hal itu, perbarui atau hapus baris tersebut.

Mengapa gambar masih rusak setelah menjalankan Better Search Replace?

Ini biasanya berarti plugin berjalan terhadap subset tabel dan melewatkan tabel plugin kustom atau tabel wp_postmeta. Jalankan ulang penggantian dengan semua tabel dipilih, dan juga periksa absolute path sistem file (mis., /public_html/wordpress/wp-content/uploads/) selain string berbasis URL.

Bagaimana cara menangani ini pada instalasi WordPress Multisite?

Multisite memerlukan konstanta tambahan di wp-config.php (DOMAIN_CURRENT_SITE, PATH_CURRENT_SITE) dan URL situs jaringan harus diperbarui di tabel wp_site dan wp_blogs. Prosedur situs tunggal standar tidak memadai — perlakukan ini sebagai migrasi jaringan penuh dan uji pada klon staging terlebih dahulu.