WordPress .htaccess: Panduan Teknis Lengkap untuk Performa, Keamanan, dan SEO

File .htaccess (Hypertext Access) adalah file konfigurasi Apache tingkat direktori yang menginstruksikan server web tentang cara menangani permintaan untuk situs WordPress Anda — tanpa memerlukan perubahan pada httpd.conf global. Setiap direktif yang Anda tempatkan di .htaccess berlaku secara rekursif untuk direktori tempat file tersebut berada dan semua subdirektori di bawahnya, menjadikan file tingkat root sebagai pengungkit paling kuat yang tersedia bagi administrator WordPress di luar server itu sendiri.

Khusus untuk WordPress, .htaccess adalah mesin di balik permalink yang rapi, lini pertahanan pertama terhadap lalu lintas berbahaya, dan pengganda performa langsung melalui kompresi dan caching browser — semuanya tanpa menyentuh plugin.

Apa yang Sebenarnya Dilakukan File .htaccess WordPress

Apache memproses .htaccess pada setiap permintaan HTTP tunggal. Artinya setiap direktif yang Anda tulis memiliki dampak terukur pada latensi, postur keamanan, dan perilaku crawl. WordPress menulis blok penulisan ulang minimal ke .htaccess secara otomatis saat Anda menyimpan struktur permalink, tetapi blok tersebut hanyalah titik awal. File ini mampu menangani:

• Penulisan ulang URL dan pengalihan melalui mod_rewrite
• Kontrol akses melalui mod_authz_host dan mod_access_compat
• Injeksi header respons HTTP melalui mod_headers
• Kompresi output melalui mod_deflate
• Kontrol cache browser melalui mod_expires
• Gerbang autentikasi melalui mod_auth_basic
• Dokumen error kustom melalui direktif ErrorDocument

Memahami modul Apache mana yang mendukung setiap direktif sangat penting — jika modul tidak dimuat di server Anda, direktif tersebut gagal secara diam-diam atau menampilkan error 500. Selalu verifikasi ketersediaan modul dengan host Anda sebelum menerapkan aturan lanjutan.

Di Mana File .htaccess Berada dan Cara Mengaksesnya

File .htaccess utama untuk instalasi WordPress berada di document root — biasanya /public_html/, /var/www/html/, atau jalur setara yang ditetapkan host Anda. Ini adalah direktori yang sama yang berisi wp-config.php, wp-login.php, dan folder wp-content/.

Karena nama file dimulai dengan titik, sebagian besar sistem operasi dan klien FTP menyembunyikannya secara default.

Untuk menampilkan file tersembunyi di FileZilla:

Server menu > Force showing hidden files

Untuk menampilkan file tersembunyi di cPanel File Manager:

Settings > Show Hidden Files (dotfiles)

Pada lingkungan VPS Hosting di mana Anda memiliki akses SSH, Anda dapat mengonfirmasi keberadaan file dan memeriksa izinnya secara langsung:

ls -la /var/www/html/ | grep htaccess

File tersebut harus dimiliki oleh pengguna server web (umumnya www-data atau apache) dan memiliki izin 644. Izin yang dapat ditulis oleh semua orang (666 atau 777) pada .htaccess adalah kerentanan keamanan serius — proses apa pun di server dapat menimpa aturan Anda.

Penjelasan Blok .htaccess WordPress Default

Saat Anda menavigasi ke Settings > Permalinks di dasbor WordPress dan menyimpan, WordPress menulis blok berikut:

# 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

Penjelasan baris per baris:

RewriteEngine On — mengaktifkan mesin penulisan ulang untuk konteks direktori ini.
RewriteBase / — menetapkan jalur URL dasar untuk penulisan ulang relatif. Pada instalasi subdirektori, ubah ini menjadi /subdirectory/.
RewriteRule ^index.php$ - [L] — jika permintaan secara harfiah untuk index.php, hentikan pemrosesan dan sajikan langsung.
RewriteCond %{REQUEST_FILENAME} !-f — hanya lanjutkan jika jalur yang diminta bukan file yang ada.
RewriteCond %{REQUEST_FILENAME} !-d — hanya lanjutkan jika jalur yang diminta bukan direktori yang ada.
RewriteRule . /index.php [L] — arahkan semua yang lain melalui front controller WordPress.

Aturan kritis: Jangan pernah mengedit secara manual apa pun di antara penanda # BEGIN WordPress dan # END WordPress. WordPress meregenerasi blok tersebut secara otomatis dan akan menimpa perubahan Anda. Tempatkan semua direktif kustom di atas komentar # BEGIN WordPress atau di bawah komentar # END WordPress.
Cara Membuat File .htaccess Jika Tidak Ada
File .htaccess yang hilang menyebabkan semua URL WordPress kecuali beranda mengembalikan error 404, karena Apache tidak memiliki instruksi untuk merutekan permintaan melalui index.php.
Metode 1: Regenerasi melalui Dasbor
Navigasi ke Settings > Permalinks dan klik Save Changes tanpa mengubah apa pun. WordPress akan mencoba menulis file secara otomatis jika direktori dapat ditulis.
Metode 2: Buat secara manual melalui SSH
nano /var/www/html/.htaccess
Tempel blok default yang ditampilkan di atas, simpan dengan Ctrl+O, dan keluar dengan Ctrl+X. Kemudian atur izin yang benar:
chmod 644 /var/www/html/.htaccess
chown www-data:www-data /var/www/html/.htaccess
Metode 3: Buat melalui FTP
Buat file teks biasa secara lokal, beri nama .htaccess (bukan .htaccess.txt — ekstensi harus tidak ada), tempel blok default, dan unggah ke document root dalam mode transfer ASCII.
Pengalihan URL: 301, 302, dan Aturan Penulisan Ulang
Pengalihan Permanen 301
Pengalihan 301 memberi sinyal kepada mesin pencari bahwa URL telah dipindahkan secara permanen. Google mentransfer sekitar 90–99% ekuitas tautan melalui 301. Gunakan saat Anda mengganti nama slug postingan, bermigrasi dari HTTP ke HTTPS, atau mengkonsolidasikan konten duplikat.
# Redirect a single old page to a new URL
Redirect 301 /old-page/ https://yourdomain.com/new-page/

# Redirect an entire old directory
Redirect 301 /old-category/ https://yourdomain.com/new-category/
Pengalihan Sementara 302
Gunakan 302 hanya ketika tujuan benar-benar sementara — misalnya, selama pengujian A/B atau jendela pemeliharaan. Mesin pencari tidak mentransfer ekuitas tautan melalui 302.
Redirect 302 /sale/ https://yourdomain.com/promo-page/
Paksa HTTPS dengan mod_rewrite
Ini adalah salah satu aturan terpenting untuk situs WordPress produksi mana pun. Menempatkan ini di atas blok WordPress memastikan semua lalu lintas HTTP dialihkan secara permanen ke HTTPS sebelum WordPress memproses permintaan:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</IfModule>
Jika situs Anda berada di belakang load balancer atau CDN yang mengakhiri SSL (umum pada infrastruktur cloud), gunakan X-Forwarded-Proto sebagai gantinya:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</IfModule>
Memasangkan ini dengan Sertifikat SSL yang valid adalah hal yang tidak bisa ditawar untuk keamanan maupun sinyal peringkat Google.
Hapus Garis Miring di Akhir dari URL Non-Direktori
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{THE_REQUEST} s(.+?)/+s
RewriteRule ^(.+)/$ /$1 [R=301,L]
</IfModule>
Hapus “category” dari URL Kategori
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^category/(.+)$ https://yourdomain.com/$1 [R=301,L]
</IfModule>
Peringatan: Aturan ini memerlukan plugin seperti WP No Category Base untuk juga memperbarui perutean internal WordPress, atau Anda akan membuat loop pengalihan.
Penguatan Keamanan melalui .htaccess
Lindungi wp-config.php
wp-config.php berisi kredensial database, kunci autentikasi, dan salt Anda. Akses browser langsung harus diblokir tanpa syarat:
<Files wp-config.php>
    Order Allow,Deny
    Deny from all
</Files>
Lindungi .htaccess Itu Sendiri
Cegah file .htaccess dibaca melalui permintaan browser:
<Files .htaccess>
    Order Allow,Deny
    Deny from all
</Files>
Nonaktifkan Penjelajahan Direktori
Jika sebuah direktori tidak berisi index.php atau index.html, Apache akan mencantumkan isinya secara default — mengekspos struktur file Anda kepada penyerang:
Options -Indexes
Blokir Penyalahgunaan XML-RPC
xmlrpc.php adalah target umum untuk serangan amplifikasi brute-force. Jika Anda tidak menggunakan Jetpack, penerbitan jarak jauh, atau pingback, blokir sepenuhnya:
<Files xmlrpc.php>
    Order Deny,Allow
    Deny from all
</Files>
Batasi wp-login.php ke Alamat IP Tertentu
Pada VPS dengan cPanel atau lingkungan dedicated mana pun di mana IP Anda statis, ini adalah salah satu langkah keamanan berdampak tertinggi yang tersedia:
<Files wp-login.php>
    Order Deny,Allow
    Deny from all
    Allow from 203.0.113.10
    Allow from 198.51.100.25
</Files>
Ganti alamat IP dengan IP statis Anda yang sebenarnya. Jika Anda bekerja dari beberapa lokasi atau menggunakan IP dinamis, pertimbangkan VPN dengan node keluar tetap sebagai gantinya.
Blokir User Agent Berbahaya
Scraper, pemindai kerentanan, dan bot spam komentar sering mengidentifikasi diri mereka dengan string user agent yang dapat dikenali:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (ahrefsbot|semrushbot|mj12bot|dotbot|nikto|sqlmap) [NC]
RewriteRule .* - [F,L]
</IfModule>
Catatan: Memblokir crawler SEO yang sah seperti Ahrefs dan SEMrush akan mencegah Anda melihat data backlink Anda sendiri di alat tersebut. Evaluasi trade-off ini berdasarkan kasus penggunaan Anda.
Blokir Akses berdasarkan Alamat IP
<Limit GET POST HEAD>
    Order Allow,Deny
    Allow from all
    Deny from 192.0.2.50
    Deny from 198.51.100.0/24
</Limit>
Notasi CIDR (misalnya, /24) memungkinkan Anda memblokir seluruh subnet, yang berguna saat menangani serangan terkoordinasi dari satu rentang IP.
Cegah Hotlinking Gambar
Hotlinking mengonsumsi bandwidth Anda tanpa memberikan manfaat. Blokir situs eksternal dari menyematkan gambar Anda secara langsung:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^https://(www.)?yourdomain.com/ [NC]
RewriteRule .(jpg|jpeg|png|gif|webp|svg)$ - [F,NC]
</IfModule>
Tambahkan Header Keamanan melalui .htaccess
Header keamanan HTTP adalah lapisan pertahanan yang sering diabaikan yang dapat disuntikkan oleh .htaccess tanpa plugin apa pun:
<IfModule mod_headers.c>
    Header always set X-Frame-Options "SAMEORIGIN"
    Header always set X-Content-Type-Options "nosniff"
    Header always set X-XSS-Protection "1; mode=block"
    Header always set Referrer-Policy "strict-origin-when-cross-origin"
    Header always set Permissions-Policy "geolocation=(), microphone=(), camera=()"
</IfModule>
Untuk Content Security Policy (CSP), nilai header harus disesuaikan dengan sumber aset spesifik situs Anda — CSP generik akan merusak skrip inline dan embed pihak ketiga.
Optimasi Performa
Aktifkan Kompresi Gzip dengan mod_deflate
Kompresi Gzip mengurangi ukuran respons HTML, CSS, dan JavaScript sebesar 60–80%, secara langsung meningkatkan Time to First Byte (TTFB) dan skor Core Web Vitals:
<IfModule mod_deflate.c>
    AddOutputFilterByType DEFLATE text/html
    AddOutputFilterByType DEFLATE text/plain
    AddOutputFilterByType DEFLATE text/xml
    AddOutputFilterByType DEFLATE text/css
    AddOutputFilterByType DEFLATE text/javascript
    AddOutputFilterByType DEFLATE application/javascript
    AddOutputFilterByType DEFLATE application/x-javascript
    AddOutputFilterByType DEFLATE application/json
    AddOutputFilterByType DEFLATE application/xml
    AddOutputFilterByType DEFLATE application/rss+xml
    AddOutputFilterByType DEFLATE image/svg+xml

    # Remove browser bugs for older clients
    BrowserMatch ^Mozilla/4 gzip-only-text/html
    BrowserMatch ^Mozilla/4.0[678] no-gzip
    BrowserMatch bMSIE !no-gzip !gzip-only-text/html
    Header append Vary User-Agent
</IfModule>
Jangan kompres format yang sudah terkompresi: image/jpeg, image/png, image/gif, image/webp, application/zip, application/pdf. Mencoba mengompresnya membuang siklus CPU dan sebenarnya dapat meningkatkan ukuran respons.
Caching Browser dengan mod_expires
Caching browser menginstruksikan browser pengunjung yang kembali untuk menyajikan aset statis dari cache lokal daripada mengunduhnya kembali dari server Anda:
<IfModule mod_expires.c>
    ExpiresActive On

    # Images
    ExpiresByType image/jpeg "access plus 1 year"
    ExpiresByType image/png "access plus 1 year"
    ExpiresByType image/gif "access plus 1 year"
    ExpiresByType image/webp "access plus 1 year"
    ExpiresByType image/svg+xml "access plus 1 year"
    ExpiresByType image/x-icon "access plus 1 year"

    # Fonts
    ExpiresByType font/woff2 "access plus 1 year"
    ExpiresByType font/woff "access plus 1 year"
    ExpiresByType application/font-woff "access plus 1 year"

    # CSS and JavaScript
    ExpiresByType text/css "access plus 1 month"
    ExpiresByType application/javascript "access plus 1 month"
    ExpiresByType text/javascript "access plus 1 month"

    # HTML and XML (short cache — content changes frequently)
    ExpiresByType text/html "access plus 1 hour"
    ExpiresByType application/xml "access plus 1 hour"
    ExpiresByType application/rss+xml "access plus 1 hour"

    # Default fallback
    ExpiresDefault "access plus 1 month"
</IfModule>
Pertimbangan cache-busting: Masa cache yang lama untuk CSS dan JS berarti browser tidak akan mengambil pembaruan hingga cache kedaluwarsa. Gunakan nama file berversi atau string kueri (misalnya, style.css?ver=2.1) — wp_enqueue_style() WordPress menangani ini secara otomatis melalui parameter $ver.
Header Cache-Control untuk Kontrol Granular
mod_expires menetapkan header Expires. Untuk kepatuhan HTTP/1.1 dan HTTP/2 modern, juga atur Cache-Control secara eksplisit:
<IfModule mod_headers.c>
    <FilesMatch ".(ico|jpg|jpeg|png|gif|webp|css|js|woff2|woff)$">
        Header set Cache-Control "max-age=31536000, public, immutable"
    </FilesMatch>
    <FilesMatch ".(html|php)$">
        Header set Cache-Control "max-age=3600, must-revalidate"
    </FilesMatch>
</IfModule>
Direktif immutable memberi tahu browser yang mendukung (Firefox, Chrome) untuk tidak memvalidasi ulang sumber daya selama masa hidupnya, menghilangkan permintaan GET kondisional sepenuhnya.
Aktifkan Keep-Alive
Koneksi persisten mengurangi overhead handshake TCP untuk beberapa aset di halaman yang sama:
<IfModule mod_headers.c>
    Header set Connection keep-alive
</IfModule>
Perbandingan: .htaccess vs. Konfigurasi Berbasis Plugin




Kemampuan
Direktif .htaccess
Plugin WordPress yang Setara
Dampak Performa




Penulisan ulang URL
Aturan mod_rewrite
Yoast SEO, Redirection
.htaccess lebih cepat (tanpa overhead PHP)


Kompresi Gzip
mod_deflate
WP Super Cache, W3 Total Cache
.htaccess lebih cepat (tingkat Apache)


Caching browser
mod_expires
WP Rocket, LiteSpeed Cache
.htaccess lebih cepat (tingkat Apache)


Pemblokiran IP
Deny from
Wordfence, iThemes Security
.htaccess lebih cepat (sebelum PHP)


Header keamanan
mod_headers
Plugin HTTP Headers
.htaccess lebih cepat (tingkat Apache)


Perlindungan wp-login.php
Blok <Files>
Limit Login Attempts Reloaded
.htaccess lebih cepat (sebelum PHP)


Content Security Policy
mod_headers
Plugin CSP
Setara — keduanya menyuntikkan header


Pengalihan berbasis database
Tidak berlaku
Plugin Redirection
Plugin unggul untuk set pengalihan besar


Manajemen GUI
Tidak berlaku
All In One WP Security
Plugin unggul untuk pengguna non-teknis




Wawasan arsitektur utama: Aturan .htaccess dieksekusi di tingkat modul Apache, sebelum PHP dipanggil. Ini berarti permintaan yang diblokir hampir tidak mengonsumsi sumber daya server. Pemblokiran berbasis plugin harus mem-bootstrap WordPress, memuat plugin, lalu menolak permintaan — mengonsumsi memori dan CPU 10–50x lebih banyak per hit yang diblokir. Pada situs dengan lalu lintas tinggi di bawah serangan bot, perbedaan ini adalah garis antara tetap online dan crash.
Melindungi Direktori Sensitif
Kunci Direktori wp-includes
Direktori wp-includes tidak boleh pernah menyajikan file PHP langsung ke browser:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^wp-includes/[^/]+.php$ - [F,L]
RewriteRule ^wp-includes/js/tinymce/langs/.+.php - [F,L]
RewriteRule ^wp-includes/theme-compat/ - [F,L]
</IfModule>
Batasi Akses ke Direktori Uploads
Direktori wp-content/uploads/ harus menyajikan file media tetapi tidak pernah mengeksekusi PHP. File PHP yang diunggah melalui plugin yang rentan dan dieksekusi dari direktori ini adalah vektor serangan webshell klasik:
<Directory "/var/www/html/wp-content/uploads">
    <FilesMatch ".php$">
        Order Deny,Allow
        Deny from all
    </FilesMatch>
</Directory>
Jika Anda menggunakan Shared Web Hosting dan tidak dapat menggunakan blok <Directory> di .htaccess, buat file .htaccess terpisah di dalam wp-content/uploads/ dengan:
<FilesMatch ".php$">
    Order Deny,Allow
    Deny from all
</FilesMatch>
Halaman Error Kustom
Ganti halaman error default Apache dengan alternatif yang bermerek dan ramah pengguna:
ErrorDocument 400 /400.html
ErrorDocument 401 /401.html
ErrorDocument 403 /403.html
ErrorDocument 404 /404.html
ErrorDocument 500 /500.html
Untuk WordPress, halaman 404 biasanya ditangani oleh perutean index.php ke template 404.php tema — tetapi memiliki fallback statis untuk error 500 sangat berharga karena 500 berarti PHP itu sendiri mungkin rusak.
Konfigurasi .htaccess WordPress Multisite
WordPress Multisite memerlukan blok penulisan ulang yang berbeda tergantung pada apakah Anda menggunakan struktur jaringan subdirektori atau subdomain.
Multisite berbasis subdirektori:
# BEGIN WordPress Multisite
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]

# Uploaded files
RewriteRule ^([_0-9a-zA-Z-]+/)?files/(.+) wp-includes/ms-files.php?file=$2 [L]

# Add a trailing slash to /wp-admin
RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*.php)$ $2 [L]
RewriteRule . index.php [L]
</IfModule>
# END WordPress Multisite
Multisite berbasis subdomain memerlukan konfigurasi DNS wildcard di tingkat registrar domain — perubahan .htaccess saja tidak cukup. Jika Anda mengelola DNS sendiri, ini ditangani melalui panel DNS penyedia Registrasi Domain Anda dengan rekaman A wildcard (*.yourdomain.com).
Teknik Lanjutan: Pembatasan Laju dan Penyaringan Permintaan
Blokir Pola Serangan Umum dalam String Kueri
<IfModule mod_rewrite.c>
RewriteEngine On

# Block SQL injection attempts
RewriteCond %{QUERY_STRING} (union.*select|select.*from|insert.*into|drop.*table) [NC]
RewriteRule .* - [F,L]

# Block script injection
RewriteCond %{QUERY_STRING} (<script|javascript:|vbscript:) [NC]
RewriteRule .* - [F,L]

# Block base64 encoded payloads in query strings
RewriteCond %{QUERY_STRING} base64_encode.*(.*) [NC]
RewriteRule .* - [F,L]
</IfModule>
Peringatan penting: Pola regex ini adalah lapisan pertama yang berguna tetapi bukan pengganti Web Application Firewall (WAF). Penyerang canggih menggunakan variasi encoding yang melewati pencocokan string sederhana. Perlakukan aturan ini sebagai filter kebisingan, bukan pertahanan komprehensif.
Batasi Metode Permintaan
WordPress hanya membutuhkan GET, POST, dan HEAD. Blokir semua metode HTTP lainnya:
<LimitExcept GET POST HEAD>
    Order Deny,Allow
    Deny from all
</LimitExcept>
Praktik Terbaik dan Disiplin Operasional
Sebelum setiap pengeditan:

Unduh .htaccess saat ini ke mesin lokal Anda sebagai cadangan bertanggal (misalnya, htaccess-backup-2025-01-15.txt).
Uji perubahan di lingkungan staging terlebih dahulu jika tersedia.
Buat satu perubahan logis sekaligus — jangan pernah menggabungkan beberapa direktif yang tidak terkait dalam satu sesi pengeditan.

Setelah setiap pengeditan:

Muat ulang Apache untuk mengonfirmasi sintaks valid sebelum menguji di browser:

apachectl configtest

Jika configtest lulus, muat ulang dengan baik:

systemctl reload apache2

Uji fungsionalitas spesifik yang Anda ubah, lalu jalankan pemeriksaan situs penuh dengan alat seperti curl -I https://yourdomain.com untuk memverifikasi header respons.

Validasi sintaks tanpa akses server:
apachectl -t -f /path/to/.htaccess
Pada Server Dedicated di mana Anda mengontrol konfigurasi Apache, pertimbangkan untuk memindahkan direktif kritis performa dari .htaccess ke konfigurasi virtual host (blok <VirtualHost> di httpd.conf atau file conf khusus situs). Apache membaca .htaccess pada setiap permintaan saat AllowOverride diaktifkan — memindahkan direktif ke konfigurasi utama menghilangkan overhead per-permintaan tersebut sepenuhnya.
Pemecahan Masalah Error .htaccess Umum
500 Internal Server Error
Penyebab paling umum adalah kesalahan sintaks di .htaccess. Log error Apache akan berisi nomor baris yang tepat:
tail -n 50 /var/log/apache2/error.log
Kesalahan sintaks umum:

Tag </IfModule> penutup yang hilang
Menggunakan akhiran baris gaya Windows (CRLF) alih-alih Unix (LF) — simpan file dalam UTF-8 tanpa BOM, akhiran baris LF
Mereferensikan modul yang tidak dimuat (misalnya, mod_rewrite dinonaktifkan)

Loop Pengalihan
Loop pengalihan (ERR_TOO_MANY_REDIRECTS) biasanya terjadi ketika:

Aturan pengalihan HTTPS Anda tidak mendeteksi dengan benar bahwa koneksi sudah aman
Anda memiliki aturan pengalihan yang bertentangan di .htaccess dan di pengaturan WordPress Anda (Settings > General URLs)
CDN atau proxy menghapus variabel server HTTPS

Diagnosis:

curl -I -L http://yourdomain.com 2>&1 | grep -E "HTTP|Location"

Aturan Penulisan Ulang Tidak Berfungsi

Jika aturan mod_rewrite tampaknya tidak berpengaruh:

1. Konfirmasi mod_rewrite diaktifkan: apache2ctl -M | grep rewrite
2. Konfirmasi AllowOverride All (atau minimal AllowOverride FileInfo) diatur dalam konfigurasi virtual host untuk document root Anda
3. Konfirmasi RewriteEngine On muncul sebelum RewriteRule apa pun dalam konteks yang sama

Halaman Mengembalikan 403 Forbidden Setelah Menambahkan Pembatasan IP

Jika Anda mengunci diri sendiri dengan menambahkan aturan pembatasan IP dengan kesalahan ketik pada alamat IP Anda sendiri, akses file melalui File Manager panel kontrol hosting (yang beroperasi di tingkat filesystem, melewati Apache) dan perbaiki atau hapus aturan tersebut.

Matriks Keputusan: Kapan Menggunakan .htaccess vs. Alternatif

Daftar Periksa Poin Kunci Teknis

• Tempatkan semua direktif kustom di luar penanda # BEGIN WordPress / # END WordPress — di atas atau di bawah, tidak pernah di dalam.
• Verifikasi setiap pembungkus <IfModule> cocok dengan modul yang benar-benar dimuat di server Anda sebelum menerapkan.
• Selalu atur izin file .htaccess ke 644 — tidak pernah 666 atau 777.
• Lindungi wp-config.php, .htaccess itu sendiri, xmlrpc.php, dan wp-includes/*.php dengan aturan deny eksplisit.
• Gunakan mod_deflate untuk kompresi dan mod_expires dengan Cache-Control: immutable untuk aset statis — dua perubahan ini saja dapat meningkatkan skor Core Web Vitals secara signifikan.
• Paksa HTTPS di tingkat .htaccess, bukan hanya di pengaturan WordPress, untuk mencegat permintaan sebelum PHP dimuat.
• Pada lingkungan VPS atau dedicated, migrasikan direktif yang stabil dari .htaccess ke konfigurasi virtual host untuk menghilangkan parsing file per-permintaan.
• Cadangkan .htaccess dengan nama file bertanggal sebelum setiap sesi pengeditan, dan validasi sintaks dengan apachectl configtest setelah setiap perubahan.
• Buat .htaccess terpisah di dalam wp-content/uploads/ yang memblokir eksekusi PHP — aturan tunggal ini menutup vektor serangan webshell yang kritis.
• Perlakukan aturan keamanan .htaccess sebagai lapisan pengurangan kebisingan, bukan WAF lengkap — padukan dengan alat tingkat server seperti ModSecurity atau WAF berbasis CDN untuk lingkungan produksi.

Pertanyaan yang Sering Diajukan

Apakah mengedit .htaccess memerlukan restart Apache?

Tidak. Apache membaca .htaccess pada setiap permintaan HTTP saat AllowOverride diaktifkan, sehingga perubahan langsung berlaku tanpa restart server. Namun, menjalankan apachectl configtest sebelum dan sesudah pengeditan sangat disarankan untuk menangkap kesalahan sintaks sebelum menyebabkan error 500 di produksi.

Apakah aturan .htaccess berfungsi di server Nginx?

Tidak. .htaccess adalah mekanisme khusus Apache. Nginx tidak membaca file .htaccess sama sekali. Aturan yang setara harus ditulis dalam blok server {} atau location {} di file konfigurasi utama Nginx. Banyak host WordPress terkelola menggunakan Nginx dan menangani aturan penulisan ulang di tingkat konfigurasi server, membuat .htaccess tidak relevan di platform tersebut.

Apa biaya performa menggunakan .htaccess?

Saat AllowOverride diaktifkan, Apache memeriksa file .htaccess di setiap direktori dari document root hingga file yang diminta pada setiap permintaan tunggal. Pada situs dengan struktur direktori yang dalam, ini dapat berarti 4–6 pembacaan filesystem per permintaan. Pada situs dengan lalu lintas tinggi, memindahkan direktif ke konfigurasi virtual host dan mengatur AllowOverride None menghilangkan overhead ini sepenuhnya.

Dapatkah aturan .htaccess bertentangan dengan pengaturan permalink WordPress?

Ya. Konflik paling umum terjadi ketika RewriteRule kustom mengganggu pola front-controller WordPress. Selalu tempatkan aturan penulisan ulang kustom di atas blok # BEGIN WordPress agar dievaluasi terlebih dahulu, dan uji semua struktur permalink setelah menambahkan logika penulisan ulang baru.

Bagaimana cara men-debug aturan .htaccess yang tidak berfungsi seperti yang diharapkan?

Aktifkan logging mod_rewrite Apache sementara di konfigurasi virtual host Anda dengan LogLevel alert rewrite:trace3, lalu reproduksi permintaan dan periksa /var/log/apache2/error.log. Output trace menunjukkan dengan tepat kondisi mana yang dievaluasi, aturan mana yang cocok, dan apa URL yang ditulis ulang akhirnya. Nonaktifkan logging trace segera setelah debugging — ini menghasilkan output yang sangat verbose dan berdampak pada performa.