Htaccess Adalah: Fungsi, Cara Kerja & Penyebab Errornya

Setiap web server berjalan mengikuti sebuah berkas konfigurasi induk. Di Apache, berkas itu bernama httpd.conf. Isinya menentukan hal-hal mendasar: folder mana yang disajikan ke publik, berkas apa yang dibuka saat pengunjung mengetik alamat folder, dan siapa yang boleh mengakses apa. Masalahnya, berkas tersebut milik administrator server dan setiap perubahannya menuntut server dimuat ulang.

Batasan itu terasa nyata di layanan hosting bersama. Satu server melayani ratusan pelanggan sekaligus, sehingga konfigurasi induknya tidak mungkin diserahkan kepada salah satu dari mereka. Di sinilah Apache menawarkan jalan tengah. Htaccess adalah berkas konfigurasi Apache yang diletakkan di dalam sebuah folder website, berlaku untuk folder itu beserta seluruh isinya, dan dapat diubah pemilik website tanpa akses administrator server. Perubahannya berlaku seketika, tanpa perlu menyalakan ulang server.

Apa Itu File htaccess?

File .htaccess adalah berkas teks berisi perintah konfigurasi yang diletakkan langsung di dalam folder website. Dokumentasi resmi Apache menyebutnya distributed configuration files, atau berkas konfigurasi yang disebar. Istilah itu tepat: alih-alih memusatkan semua aturan di satu berkas besar, Apache mengizinkan potongan aturan tersebar di folder mana pun yang membutuhkannya.

Tiga sifat membedakannya dari konfigurasi induk. Pertama, cakupannya terbatas pada folder tempat berkas itu berada beserta seluruh subfolder di bawahnya. Kedua, perubahannya berlaku seketika, karena Apache membaca ulang berkas ini pada setiap permintaan. Ketiga, dan inilah yang paling menentukan, Anda tidak membutuhkan akses administrator untuk memakainya.

Namanya sendiri bukan sesuatu yang baku. Kata .htaccess hanyalah nilai bawaan dari direktif AccessFileName, dan administrator server dapat menggantinya.

Ketika sebuah folder dan folder induknya sama-sama memiliki berkas ini, aturan digabungkan mengikuti kedalamannya. Aturan di folder yang lebih dalam menimpa aturan di atasnya, dan keduanya menimpa konfigurasi induk. Perlu diperhatikan, "menimpa" di sini berarti mengganti, bukan menambahkan. Dokumentasi Apache memberi contoh gamblang: bila folder induk mengaktifkan Options +ExecCGI lalu subfolder menulis Options Includes, kemampuan CGI di subfolder itu justru mati sepenuhnya.

Di Mana Letaknya dan Kenapa Sering Tidak Terlihat

Tempat paling umum berkas ini adalah folder web root, yakni folder yang isinya langsung tersaji ke pengunjung. Pada cPanel, folder itu bernama public_html. Anda juga bebas menaruh berkas tambahan di subfolder mana pun, misalnya di folder unggahan yang perlu diperketat aksesnya.

Banyak pengguna melaporkan berkasnya hilang padahal berkas itu ada. Penyebabnya terletak pada titik di awal nama. Di sistem operasi keluarga Unix, berkas berawalan titik disebut dotfile (berkas tersembunyi), dan program penjelajah berkas menyembunyikannya secara bawaan. File Manager cPanel pun berperilaku sama sampai Anda mencentang opsi menampilkan berkas tersembunyi.

Alasan yang sama melatarbelakangi kebiasaan lama menyimpan berkas bernama htaccess.txt di komputer, lalu mengganti namanya setelah diunggah. Langkah pembuatannya dari nol sudah kami bahas terpisah di panduan cara membuat file htaccess dan contoh redirect.

AllowOverride: Saklar yang Menentukan .htaccess Anda Dibaca atau Tidak

Sebelum menulis satu baris aturan pun, ada satu hal yang perlu Anda pastikan lebih dulu. Kemampuan .htaccess tidak menyala dengan sendirinya. Administrator server memegang sebuah direktif bernama AllowOverride yang menentukan sejauh mana berkas Anda boleh mengubah konfigurasi, dan nilai bawaannya adalah None.

Dokumentasi keamanan Apache menyatakan hal itu secara terbuka: konfigurasi AllowOverride None pada folder root merupakan nilai bawaan sejak Apache 2.3.9. Artinya, pada server yang dipasang tanpa penyesuaian, seluruh berkas .htaccess diabaikan. Penyedia hosting bersama umumnya sudah mengaktifkannya karena memang menjadi bagian dari layanan, tetapi server yang Anda kelola sendiri belum tentu.

Izin yang diberikan pun bertingkat, terbagi ke dalam lima kelompok direktif.

Ketika Anda memakai direktif dari kelompok yang tidak diizinkan, Apache membalas dengan 500 Internal Server Error dan mencatat alasannya di error log. Kami mengujinya pada Apache 2.4.67 dengan AllowOverride AuthConfig: satu baris Options -Indexes cukup untuk memunculkan pesan Options not allowed here.

Kegagalan yang berisik seperti itu sebenarnya kabar baik, karena Anda tahu ada yang salah. Yang jauh lebih merepotkan adalah kebalikannya. Pada pengujian yang sama dengan AllowOverride None, kami menaruh kata ngawur TestMe di dalam .htaccess. Server membalas HTTP 200 seolah tidak terjadi apa-apa, dan error log tidak memuat satu baris pun. Seluruh berkas diabaikan dalam senyap.

Inilah sebabnya banyak orang menghabiskan berjam-jam memperbaiki aturan yang sebenarnya tidak pernah dibaca. Tidak ada pesan error yang bisa dicari di internet, karena memang tidak ada pesan error yang dihasilkan.

Untungnya perilaku itu sekaligus menjadi alat diagnosa yang disarankan dokumentasi Apache. Tulis satu kata ngawur di baris pertama berkas Anda, simpan, lalu muat ulang halaman.

Uji AllowOverride: tulis kata ngawur di .htaccess, muat ulang. Error 500 berarti dibaca, halaman normal berarti diabaikan.

Satu kata ngawur cukup untuk memastikan berkas Anda benar-benar dibaca. Halaman yang tetap terbuka normal justru pertanda AllowOverride None.

Bila muncul error 500, berkas Anda dibaca dan Anda boleh melanjutkan menulis aturan. Bila halaman terbuka normal, hampir dapat dipastikan AllowOverride None sedang berlaku dan Anda perlu menghubungi penyedia hosting. Jangan lupa menghapus kembali kata ngawur tersebut setelah pengujian.

Fungsi htaccess yang Benar-Benar Sering Dipakai

Daftar kemampuan .htaccess sangat panjang, tetapi yang benar-benar dipakai sehari-hari berkisar pada tujuh hal berikut.

1. Mengalihkan alamat: memindahkan pengunjung dari satu alamat ke alamat lain, baik satu halaman maupun seluruh situs. Perintah Redirect 301 menandainya sebagai perpindahan permanen, sehingga mesin pencari ikut memindahkan peringkat halaman lama ke alamat baru. Dua kebutuhan paling umum adalah pengalihan ke HTTPS dan penyeragaman alamat dengan atau tanpa www, yang langkahnya kami bahas di panduan redirect HTTP ke HTTPS dan redirect www ke non-www.
2. Menulis ulang alamat agar rapi: mengubah alamat teknis seperti ?p=17 menjadi alamat yang terbaca manusia. Inilah mekanisme di balik permalink WordPress dan routing framework seperti Laravel dan CodeIgniter.
3. Membatasi akses: menolak permintaan dari alamat tertentu, atau sebaliknya hanya mengizinkannya. Di cPanel, fitur setara tersedia lewat menu Block IP Address.
4. Memasang kata sandi pada folder: melindungi folder administrasi dengan kotak login bawaan browser. cPanel menyediakannya sebagai Directory Privacy, yang di balik layar menulis aturan .htaccess juga.
5. Mematikan daftar isi folder: mencegah Apache menampilkan seluruh isi folder ketika tidak ada berkas index di dalamnya. Satu baris Options -Indexes menutup salah satu kebocoran informasi yang paling sering terlewat.
6. Mengganti halaman error: menyajikan halaman buatan sendiri saat terjadi 404 atau 403, alih-alih halaman putih bawaan Apache.
7. Menambahkan header respons: memasang header cache agar gambar dan CSS disimpan lebih lama di browser pengunjung, atau header keamanan yang mengatur perilaku browser.

Sebagian besar dari tujuh hal itu memiliki padanan berupa menu siap pakai di panel hosting. Menulisnya langsung tetap berguna ketika Anda membutuhkan aturan yang lebih spesifik daripada yang disediakan menu. Berguna juga ketika aturan itu perlu ikut berpindah bersama berkas website saat migrasi.

Enam fungsi .htaccess: mengalihkan dan merapikan alamat, membatasi akses, kata sandi folder, tutup daftar isi, halaman error.

Enam pekerjaan yang paling sering diserahkan ke .htaccess. Sebagian besar punya padanan berupa menu siap pakai di panel hosting.

Anatomi Aturan: Membaca Satu Blok .htaccess Baris per Baris

Kemampuan yang lebih berharga daripada menyalin kode adalah membaca kode yang sudah ada, karena menghapus satu baris yang salah dapat mematikan seluruh situs. Blok di bawah ini adalah pola front controller, yaitu pola yang mengarahkan semua permintaan ke satu berkas pusat. Bentuknya mirip pada hampir semua aplikasi PHP modern.

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php [L]
</IfModule>

Dibaca baris demi baris, isinya sebagai berikut. <IfModule mod_rewrite.c> memastikan aturan di dalamnya hanya dijalankan bila modul penulisan ulang alamat tersedia, sehingga server tanpa modul itu tidak langsung error. RewriteEngine On menyalakan mesinnya, sedangkan RewriteBase / menetapkan alamat dasar sebagai titik acuan saat menyusun kembali alamat hasil penulisan ulang.

Dua baris RewriteCond berikutnya adalah syarat yang keduanya harus terpenuhi. %{REQUEST_FILENAME} berisi nama berkas yang diminta pengunjung, tanda !-f berarti berkas itu tidak ada, dan !-d berarti foldernya tidak ada. Digabungkan, keduanya berbunyi: jalankan aturan berikut hanya jika yang diminta memang bukan berkas atau folder yang benar-benar ada.

Barulah RewriteRule bekerja. Pola ^(.*)$ menangkap apa pun, lalu mengarahkannya ke index.php. Flag [L] adalah singkatan dari last, yang menghentikan pemrosesan setelah baris ini cocok. Hasil akhirnya, gambar dan CSS tetap disajikan apa adanya sementara alamat halaman diserahkan ke aplikasi.

Setiap CMS dan framework membawa blok bawaannya masing-masing dengan variasi berbeda. Kumpulan isi .htaccess default untuk WordPress, Joomla, OpenCart, dan Lokomedia sudah kami rangkum terpisah di artikel default file .htaccess pada berbagai CMS.

Blok bawaan CMS sebaiknya dibiarkan utuh di tempatnya semula. Tambahkan aturan Anda sendiri di atas atau di bawah blok tersebut, jangan di tengahnya, karena sebagian CMS menulis ulang isi bloknya sendiri secara berkala.

Aturan Sudah Benar tapi Tidak Jalan: Soal Garis Miring di Depan

Keluhan yang paling sering muncul berbunyi kurang lebih begini: aturannya sudah disalin persis dari tutorial, tetapi tidak terjadi apa-apa. Pada sebagian besar kasus, penyebabnya adalah satu karakter garis miring.

Di konteks .htaccess, Apache memotong awalan folder dari alamat sebelum mencocokkannya dengan pola. Dokumentasi resminya memberi contoh langsung: bila berkas berada di /var/www/htdocs/app/ dan pengunjung meminta /app/products/widget, maka RewriteRule hanya melihat products/widget. Awalan /app/ hilang bersama garis miring di depannya.

Akibatnya, aturan yang sama harus ditulis berbeda tergantung tempatnya.

Dokumentasi Apache menyatakannya tanpa ambiguitas: pola yang diawali ^/ tidak akan pernah cocok di konteks per-folder. Kami memverifikasinya sendiri pada Apache 2.4.67 dengan berkas di folder /app/. Versi berawalan garis miring membalas 404, versi tanpa garis miring membalas 200 dan berhasil memanggil berkas tujuan. Yang perlu diperhatikan, permintaan yang gagal itu tidak meninggalkan satu baris pun di error log — sama senyapnya dengan kasus AllowOverride None.

Permintaan /app/produk/lampu dipotong jadi produk/lampu, sehingga pola berawalan garis miring tidak pernah cocok.

Awalan folder dipotong sebelum pola dicocokkan, sehingga aturan yang disalin dari konfigurasi VirtualHost tidak akan pernah cocok di .htaccess.

Kenapa Setelan PHP di File htaccess Memicu Error 500

Ada satu kategori aturan yang paling sering disalin pemilik website, dan sekaligus menjadi penyebab error 500 yang paling sering ditemui. Bentuknya seperti ini:

php_value upload_max_filesize 64M
php_value memory_limit 256M

Aturan tersebut hanya bekerja bila PHP dijalankan sebagai modul Apache, yang dikenal sebagai mod_php. Alasannya masuk akal: direktif php_value disediakan oleh modul PHP itu sendiri, sehingga tanpa modul tersebut Apache tidak mengenalinya sama sekali.

Persoalannya, mayoritas hosting hari ini tidak lagi memakai mod_php. Yang dipakai adalah LiteSpeed SAPI, suPHP, CGI, atau PHP-FPM — semuanya menjalankan PHP sebagai proses terpisah demi keamanan dan efisiensi memori. Kami mengujinya pada Apache 2.4.67 tanpa mod_php: satu baris php_value membalas 500 Internal Server Error dengan pesan Invalid command 'php_value' di log.

Jalan keluarnya bukan memaksakan .htaccess, melainkan memakai berkas lain bernama .user.ini. Manual PHP menegaskan berkas tersebut diproses khusus oleh SAPI CGI dan FastCGI, yaitu justru lingkungan tempat php_value gagal. Sintaksnya memakai format INI biasa tanpa awalan apa pun.

upload_max_filesize = 64M
memory_limit = 256M

Alur memilih tempat setelan PHP: mod_php memakai php_value di .htaccess, PHP-FPM dan LSAPI memakai .user.ini.

Tempat menaruh setelan PHP ditentukan oleh cara PHP dijalankan, bukan oleh selera. Salah tempat berujung pada 500 Internal Server Error.

Dua catatan perlu Anda ingat saat memakainya. Pertama, PHP menyimpan hasil pembacaan berkas ini selama 300 detik secara bawaan. Tunggu sekitar lima menit sebelum menyimpulkan aturannya gagal. Kedua, tidak semua pengaturan dapat diubah dari sini; pengaturan bertingkat sistem tetap hanya bisa disentuh lewat php.ini oleh administrator. Bila error 500 sudah muncul di situs Anda, langkah penanganan lengkapnya kami bahas di panduan mengatasi 500 Internal Server Error.

Sintaks Lama yang Masih Beredar: Order, Allow, dan Deny

Jebakan berikutnya berasal dari usia. Apache 2.4 dirilis pada 2012 dan mengganti cara pengaturan kendali akses, tetapi panduan yang ditulis untuk Apache 2.2 masih mudah Anda temukan sampai hari ini.

Sintaks lama tidak langsung hilang. Apache menyediakan modul kompatibilitas bernama mod_access_compat yang masih menerimanya, dan banyak distribusi Linux memuat modul itu secara bawaan. Status resminya, bagaimanapun, sudah deprecated alias tidak dianjurkan, dan dokumentasinya secara khusus melarang mencampur sintaks lama dengan sintaks baru dalam satu berkas.

Perbedaannya nyata dan mudah diuji. Pada Apache 2.4.67 dengan modul kompatibilitas dimuat, aturan Order deny,allow berjalan normal dan membalas HTTP 200. Ketika modul yang sama kami lepas, aturan identik langsung membalas 500 dengan pesan Invalid command 'Order'.

Kesimpulan praktisnya sederhana. Bila Anda menemukan panduan yang memakai Order, Allow, atau Deny, anggaplah panduan itu berumur lebih dari sepuluh tahun. Cari padanan Require-nya sebelum menyalin.

Htaccess di Luar Apache: LiteSpeed dan Nginx

Pertanyaan yang wajar muncul berikutnya adalah sejauh mana keterampilan ini berlaku. Jawabannya bergantung pada web server yang menjalankan website Anda, dan peta pemakaiannya hari ini cukup terbelah. Data W3Techs yang dikumpulkan pada 20 Agustus 2026 mencatat Nginx di 31,4%, Cloudflare Server di 29,6%, Apache di 22,6%, dan LiteSpeed di 14,9%.

Angka LiteSpeed pantas diperhatikan karena banyak dipakai penyedia hosting di Indonesia. Edisi Enterprise-nya sengaja dirancang membaca .htaccess Apache apa adanya, dan kemampuan itulah yang membuat perpindahan dari Apache dapat dilakukan tanpa menulis ulang aturan pelanggan.

Edisi gratisnya, OpenLiteSpeed, bercerita lain. Dokumentasinya menyatakan hanya aturan mod_rewrite yang didukung, sementara direktif lain diabaikan tanpa pemberitahuan. RewriteBase tidak dikenali, dan pembacaan .htaccess harus dinyalakan lebih dulu lewat pengaturan Rewrite Control. Yang paling mengubah cara kerja, setiap perubahan aturan menuntut server dinyalakan ulang, sehingga keunggulan berlaku seketika yang menjadi ciri khas .htaccess justru hilang di sini.

Adapun Nginx tidak memiliki mekanisme setara dalam bentuk apa pun. Seluruh konfigurasinya terpusat di nginx.conf, hanya dapat disunting pemegang akses server, lalu dimuat ulang secara sengaja. Keputusan itu diambil justru demi menghindari biaya pembacaan berkas per permintaan yang melekat pada model Apache. Bila Anda berpindah ke Nginx, seluruh aturan harus diterjemahkan ke sintaks Nginx dan dipindahkan ke konfigurasi induk. Alat konversi htaccess ke Nginx memang tersedia daring, tetapi hasilnya tetap perlu diperiksa manual karena kedua sintaks tidak berpadanan satu lawan satu.

Kelemahan dan Hal yang Perlu Anda Pertimbangkan

Kenyamanan .htaccess datang bersama sejumlah konsekuensi yang layak Anda ketahui sejak awal.

1. Ada biaya pada setiap permintaan: Apache mencari berkas ini di seluruh folder induk setiap kali ada permintaan, bahkan ketika berkasnya tidak ada. Pola pencocokannya juga diproses ulang. Aturan yang sama di konfigurasi induk cukup diproses sekali saat server dinyalakan. Rinciannya kami bahas lebih dalam di artikel Apache adalah.
2. Satu kesalahan ketik mematikan seluruh situs: Berbeda dengan kesalahan di kode program yang biasanya hanya merusak satu halaman, kesalahan sintaks di sini membuat seluruh folder beserta subfoldernya membalas 500. Halaman administrasi tempat Anda hendak memperbaikinya pun ikut mati.
3. Aturan mudah terserak: Pada website yang sudah lama berjalan, aturan dapat tersebar di beberapa folder sekaligus. Melacak aturan mana yang sebenarnya berlaku untuk satu alamat bisa menyita waktu yang tidak sebentar.
4. Kendali konfigurasi berpindah tangan: Dari sudut pandang pemilik server, mengaktifkan .htaccess berarti menyerahkan sebagian kendali kepada pengguna. Dokumentasi Apache menyarankan izin dibatasi pada kelompok direktif yang memang dibutuhkan, bukan langsung All.

Satu kekhawatiran yang justru sering berlebihan adalah soal isi berkas yang terbaca pengunjung. Konfigurasi bawaan Apache sudah memuat blok <Files ".ht*"> dengan Require all denied, yang menolak permintaan langsung ke berkas mana pun berawalan .ht. Yang perlu Anda periksa adalah server yang konfigurasi bawaannya sudah diubah, bukan server standar.

Aturan Main yang Kami Sarankan

Berikut kebiasaan kerja yang menghemat banyak waktu, disusun dari urutan yang paling sering menyelamatkan.

Salin cadangan sebelum menyunting. Ganti nama berkas lama menjadi htaccess-backup-20260820 sebelum mengubah apa pun. Memulihkan situs yang mati kemudian cukup dilakukan dengan mengganti nama, bukan menyusun ulang aturan dari ingatan.

Ubah satu blok dalam satu kali sunting. Simpan, lalu segera muat ulang halaman untuk memastikan situs masih hidup. Menambahkan lima aturan sekaligus lalu mendapati 500 berarti Anda harus menebak baris mana pelakunya.

Buka error log sebagai langkah pertama, bukan terakhir. Setiap kegagalan yang berisik meninggalkan pesan yang cukup spesifik, seperti Invalid command atau not allowed here. Membaca satu baris log jauh lebih cepat daripada mencocokkan aturan satu per satu.

Atur izin berkasnya ke 644. Nilai tersebut memberi hak baca dan tulis kepada pemilik serta hak baca kepada yang lain. Itu sudah cukup untuk dibaca Apache. Hindari 777, yang mengizinkan siapa pun menulis ulang aturan server Anda. Arti tiap angkanya kami jelaskan di artikel chmod adalah.

Batasi jumlah berkasnya. Untuk website berukuran wajar, dua sampai tiga berkas sudah lebih dari cukup. Satu di web root, satu atau dua di folder yang perlu diperketat. Melewati angka itu, biaya penelusuran mulai terasa dan pelacakan aturan menjadi sulit.

Pindahkan aturan ke konfigurasi induk begitu Anda mampu. Saran ini datang dari dokumentasi Apache sendiri. Selama Anda memakai layanan web hosting bersama, .htaccess memang satu-satunya pilihan. Namun setelah Anda memegang akses administrator lewat VPS, memindahkannya menghilangkan seluruh biaya per-permintaan sekaligus memusatkan aturan di satu tempat.

Pertanyaan yang Sering Muncul

Htaccess untuk apa?

Untuk mengubah perilaku web server hanya pada folder website Anda, tanpa akses administrator. Penggunaan paling umum adalah mengalihkan alamat, merapikan bentuk alamat, membatasi akses, memasang kata sandi folder, dan mengganti halaman error.

Apakah setiap website wajib punya file .htaccess?

Tidak. Website statis berisi HTML biasa berjalan normal tanpa berkas ini. Yang membutuhkannya adalah aplikasi beralamat rapi seperti WordPress dan framework PHP, karena permintaan perlu diarahkan ke satu berkas pusat.

Apa yang terjadi kalau file .htaccess terhapus?

Situs tetap hidup, tetapi seluruh aturan di dalamnya berhenti berlaku. Pada WordPress, gejala khasnya adalah halaman depan terbuka normal sementara semua halaman lain membalas 404. Memulihkan blok bawaannya biasanya sudah cukup.

Apakah pengunjung bisa melihat isi file .htaccess?

Pada Apache dengan konfigurasi bawaan, tidak, karena sudah ada aturan yang menolak akses langsung ke berkas berawalan .ht. Anda tetap perlu memastikannya bila server dikelola sendiri.

Apa bedanya .htaccess dan .user.ini?

Keduanya berlaku per folder, tetapi pembacanya berbeda. Berkas .htaccess dibaca web server dan mengatur perilaku server, sedangkan .user.ini dibaca PHP dan hanya mengatur setelan PHP di lingkungan CGI atau FastCGI.

Apa kegunaan dari file .htaccess di WordPress?

WordPress memakainya untuk satu tugas utama: mengubah alamat teknis ?p=17 menjadi permalink yang rapi. Blok aturannya ditulis otomatis setiap kali Anda menyimpan pengaturan permalink. Plugin cache dan keamanan sering menambahkan aturannya sendiri ke berkas yang sama. Isi bawaannya dapat Anda lihat di artikel default file .htaccess pada berbagai CMS.

Apa itu HTTPD?

HTTPD adalah nama program Apache di dalam sistem, singkatan dari HTTP daemon, yaitu proses yang berjalan di latar belakang untuk melayani permintaan HTTP. Nama itu juga dipakai pada berkas konfigurasi induknya, httpd.conf. Jadi ketika sebuah panduan menyebut httpd, yang dimaksud adalah Apache itu sendiri.

Kesimpulan

Htaccess adalah berkas konfigurasi per-folder milik Apache yang memungkinkan pemilik website mengubah perilaku server tanpa akses administrator. Aturannya berlaku pada folder tempatnya berada beserta seluruh isinya, dan aktif seketika setelah disimpan. Kemampuan itu dibayar dengan pemeriksaan berkas tambahan pada setiap permintaan, dan satu kesalahan ketik cukup untuk mematikan seluruh folder.

Sebelum menduga aturan Anda salah, periksa dulu tiga hal. Pertama, apakah AllowOverride mengizinkan berkas Anda dibaca. Kedua, apakah pola penulisan ulang Anda memakai garis miring di depan. Ketiga, apakah aturan yang Anda salin berasal dari zaman mod_php atau Apache 2.2. Pakailah .htaccess selama Anda berada di hosting bersama, lalu pindahkan aturannya ke konfigurasi induk begitu memegang akses server sendiri.

Semoga artikel ini membantu.