WordPress-in defolt .htaccess faylı: tərkibi və bərpası

WordPress-in defolt .htaccess faylı, /2026/10/yazi-adi/ kimi daimi keçidlərin 404 vermək əvəzinə həll olunması üçün proqram təminatının saytınızın köküundəki .htaccess-ə yazdığı qısa RewriteEngine blokudur. Belə görünür:

# 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

Bu, WordPress-in Apache HTTP Server haqqında rəsmi bələdçisindən və gözəl daimi keçidlər üzrə HelpHub səhifəsində sənədləşdirilmiş yazma məntiqindən götürülmüş dəqiq blokdur. Əgər RewriteBase dəyəriniz / deyilsə — məsələn, WordPress alt qovluqda qurulduğu üçün — bunun əvəzinə həmin yola uyğunlaşacaq, bu da eyni dərəcədə normaldır və WordPress-in özü tərəfindən yaradılır.

Əsas məqamlar

• WordPress bu bloku avtomatik, yalnız Apache və LiteSpeed-də, fayl yazıla bilən olduqda və Tənzimləmələr > Daimi Keçidlər-i saxladığınızda yaradır.
• Fayl çatışmırsa və ya zədələnibsə, ana səhifə istisna olmaqla bütün daimi keçidlər 404 qaytarır, çünki yazma qaydaları olmadan yalnız ana səhifə tapıla bilər.
• Sizin və ya bir plaginin əlavə etdiyi hər şey # BEGIN WordPress-in üstündə olmalıdır, heç vaxt işarələrin içində — WordPress hər daimi keçid saxlanışında aralarındaki hər şeyin üzərinə yazır.

Faylı həqiqi yolunuz və əlavə qaydalarla yenidən qurmaq lazımdır? WordPress .htaccess generatoru birbaşa brauzerinizdə düzgün bir fayl toplayır.

Hər sətir nə edir

RewriteEngine On bu qovluq üçün Apache-nin mod_rewrite modulunu aktivləşdirir; bu sətirsiz aşağıdakı hər şey işləmir.

RewriteBase / Apache-yə yenidən yazılan yolların sayt kökünə nisbətən olduğunu bildirir. WordPress bunu saytın həqiqətən harada yerləşdiyinə uyğun təyin edir — alt qovluqda quraşdırma / yox, RewriteBase /blog/ alır.

RewriteRule ^index\.php$ - [L] təsirsiz bir qoruyucudur: sorğu artıq index.php-dirsə, yenidən yazma dayanır və sorğu dəyişməz keçir.

İki RewriteCond sətri əsl məntiqdir. %{REQUEST_FILENAME} !-f və !-d soruşur: “bu sorğu həqiqi fayla UYĞUN GƏLMİR, və həqiqi qovluğa UYĞUN GƏLMİR?”. Son qaydanın işləməsi üçün hər ikisi doğru olmalıdır — beləliklə həqiqi şəkil, CSS faylı və ya yüklənmiş PDF birbaşa verilir və WordPress-in yönləndirməsinə heç vaxt toxunmur.

RewriteRule . /index.php [L] daimi keçidləri işlək edən qaydadır: əvvəlki iki şərtdən sağ çıxan hər şey — yəni həqiqi fayl və ya qovluq olmayan — index.php-yə göndərilir və WordPress-in öz yönləndirməsi (WP_Query, yazma teqləri) həmin URL-in həqiqətən hansı yazı, səhifə və ya arxiv olduğuna qərar verir.

WordPress bu faylı nə vaxt yenidən yaradır, nə vaxt yarada bilmir

WordPress ekranda heç nə dəyişməsə belə, Tənzimləmələr > Daimi Keçidlər-i açıb Dəyişiklikləri Saxla-ya hər klikləməkdə .htaccess-i özü yazmağa cəhd edir. Bu saxlama flush_rewrite_rules()-u işə salır, o da .htaccess-i yazma üçün açmağa və işarələr arasına cari bloku daxil etməyə cəhd edir.

Bu cəhd aşağıdaki hallarda səssizcə uğursuz olur, faylı çatışmayan və ya köhnəlmiş saxlayır:

• Fayl və ya onun ana qovluğu PHP-nin işlədiyi istifadəçi üçün yazıla bilən deyil. Bir çox paylaşılan hostinqlərdə PHP, faylları FTP ilə yükləyən istifadəçidən fərqli sistem istifadəçisi altında işləyir, buna görə FTP müştərisində düzgün görünən icazələr yenə də WordPress-in yazmasını əngəlləyə bilər.
• Siz nginx istifadə edirsiniz. .htaccess yalnız Apache və LiteSpeed mexanizmidir (Apache-nin AllowOverride haqqında sənədləşdirilməsi səbəbini izah edir: nginx-də hər sorğuda yenidən oxunan qovluq-əsaslı konfiqurasiya faylı yoxdur). nginx-dəki ekvivalenti server blokundakı try_files direktividir, onu yalnız server girişi olan biri redaktə edə bilər; WordPress bunu sizin üçün heç vaxt yaza bilməz.
• Əsas Apache konfiqurasiyasında saytınızın qovluğu üçün AllowOverride None olaraq təyin edilib. Bu, bir .htaccess-in ümumiyyətlə nəyisə üzərinə yazmasına icazə verən tənzimləmədir; Apache sənədləşdirməsi açıqdır: AllowOverride None ilə “.htaccess faylları tamamilə nəzərə alınmır” — WordPress qüsursuz bir fayl yaza bilər, bu tənzimləmə server səviyyəsində dəyişdirilənə qədər heç bir təsiri olmayacaq.
• Fayl silinib və ya heç mövcud olmayıb və saxlamada bir şey yenidən yaratmanı işə salmayıb — ən çox səbəb daimi keçid strukturunun artıq eyni olması, buna görə WordPress yenidən yazılacaq heç bir dəyişiklik görməyib.

Əllə necə bərpa edilir

Yazılar və səhifələr 404 verərkən ana səhifə işləməyə davam edirsə, bu çatışmayan və ya pozulmuş .htaccess-in imzasıdır. İki addımda düzəldin.

1. Əvvəlcə bir kliklə həlli sınayın. WordPress idarə panelində Tənzimləmələr > Daimi Keçidlər-ə gedin və heç nə dəyişmədən Dəyişiklikləri Saxla-ya klikləyin. Fayl yazıla bilən olarsa, bu tək başına onu yenidən yaradır və iş bitir.

2. Bu həll etmirsə, faylı əllə yaradın. FTP/SFTP ilə və ya hostinqinizin fayl idarəçisi ilə qoşulun, WordPress-in quraşdırıldığı qovluğa gedin (wp-config.php-ni ehtiva edən qovluq) və .htaccess-in ümumiyyətlə mövcud olub-olmadığını yoxlayın — bu, gizli bir fayldır, bəzi fayl idarəçiləri onu defolt olaraq gizlədir; “gizli faylları göstər”i aktivləşdirin.

• Yoxdursa, dəqiq .htaccess adlı yeni bir fayl yaradın (.txt yox, nöqtədən əvvəl heç nə).
• Yuxarıdaki defolt bloku yapıştırın, WordPress alt qovluqda yerləşirsə RewriteBase-i uyğunlaşdırın.
• Saxlayın və işlədiyini təsdiqləmək üçün bir yazının daimi keçidini yenidən yükləyin.

Bundan sonra hələ də 404 alırsınızsa, səbəb “.htaccess çatışmır”dan “.htaccess nəzərə alınmır”a dəyişib — hostinqinizdən AllowOverride haqqında soruşun, çünki Apache-nin nəzərə almaq əmri aldığı bir qovluqdakı düzgün fayl, fayl heç olmayan kimi davranır.

Sizin öz qaydalarınız WordPress-in blokuna qarşı

Bir plagin və ya əl redaktəsi öz qaydalarını əlavə edə bilər — yönləndirmələr, hotlink qoruması, keş başlıqları. Bu, WordPress-in yaratdığından fərqli, ayrı bir blokdur və ikisi heç vaxt üst-üstə düşməməlidir:

# Sizin və ya bir plaginin əlavə etdiyi qaydalar — WordPress işarələrinin ÜSTÜNDƏ
<FilesMatch "\.(jpg|jpeg|png|gif)$">
    # nümunə: hotlink qoruması, keş qaydaları və s.
</FilesMatch>

# 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

# BEGIN WordPress ilə # END WordPress arasında yerləşdirilən hər şey, kim isə növbəti dəfə Daimi Keçidlər ekranını saxladıqda səssizcə silinir, çünki WordPress bütün bu hissəni öz malı kimi qəbul edir və tamamilə yenidən yazır. Bu, “öz qaydam yoxa çıxdı” şikayətinin ən çox yayılmış səbəbidir — qəsdən heç vaxt silinməyib, sadəcə WordPress-in öz malı hesab etdiyi bir blokun içində olub. Xüsusilə yönləndirmələr üçün, haradan yerləşdirilməli olduqlarını və dövrələrdən necə qaçmağı öyrənmək üçün düzgün edilmiş WordPress .htaccess yönləndirmə qaydalarına baxın.

Faylı redaktə etdikdən dərhal sonra qəfil 500 Internal Server Error almağın da ən çox yayılmış səbəbidir: başqa bir Apache versiyası üçün yazılmış bir forum yazısından kopyalanan bir qayda (2.2-nin Order/Deny sintaksisi 2.4-ün Require sintaksisi ilə qarışdırılıb) bütün faylın təhlilini pozur, aşağıdaki WordPress bloku daxil olmaqla, və toxunduğunuz hissə yox, bütün sayt çöküş edir.

Defolt blokdan kənarda

Defolt blok yalnız daimi keçid yönləndirməsi ilə məşğul olur. Həmçinin həssas fayllara girişi möhkəmləndirmək və ya hücum səthini həqiqətən azaldan bir ovuc .htaccess qaydası əlavə etmək istəyirsinizsə — /uploads-da PHP icrasını bloklamaq, wp-config.php-yə birbaşa sorğuları rədd etmək — həqiqətən köməkçi olan WordPress .htaccess təhlükəsizlik qaydalarına baxın. Və daimi keçidlər başqa bir səbəbdən 404 verirsə — yanlış daimi keçid strukturu, köhnə qaydaları verən keş qatı, alt qovluqlarda çoxsaytlı münaqişələr — işləməyən WordPress daimi keçidləri digər səbəbləri nəzərdən keçirir.

Tez-tez verilən suallar

WordPress-in defolt .htaccess faylı nədir? Daimi keçidlərin 404 vermək əvəzinə index.php-yə həll olunması üçün WordPress-in # BEGIN WordPress ilə # END WordPress arasında yazdığı RewriteEngine blokudur.

WordPress-in dəqiq defolt .htaccess kodu nədir? RewriteEngine On, RewriteBase /, index.php üçün keçid qaydası, sorğunun həqiqi fayl və ya qovluq olmadığını yoxlayan iki şərt və qalan hər şeyi index.php-yə göndərən son bir qayda. Tam blok bu bələdçinin əvvəlində verilib.

Niyə ana səhifə istisna olmaqla bütün yazılarım 404 verir? Ana səhifə heç bir yazma qaydası olmadan tapıla bilər; hər digər daimi keçid onlara ehtiyac duyur. Apache-də çatışmayan və ya zədələnmiş .htaccess dəqiq bu nümunəni yaradır.

WordPress .htaccess-i avtomatik yenidən yaradır? Yalnız fayl yazıla bilən olduqda — Tənzimləmələr > Daimi Keçidlər-i yenidən saxlamaq bunu işə salır. Fayl yazıla bilən deyilsə, onu avtomatik yaratmayan bir hostinqdə çatışmırsa, və ya AllowOverride söndürülübsə, WordPress bunu sizin üçün düzəldə bilməz və faylı əllə yaratmalı və ya düzəltməlisiniz.

Niyə nginx-də WordPress .htaccess faylı yoxdur? .htaccess yalnız Apache və LiteSpeed-də işləyir. nginx-də qovluq-əsaslı konfiqurasiya faylı yoxdur və .htaccess-i tamamilə nəzərə almır; eyni yönləndirmə nginx-in server blokunda try_files qaydası kimi yazılır.

Daimi keçidləri saxladıqdan sonra niyə .htaccess-im pozuldu? Öz qaydanız # BEGIN WordPress / # END WordPress işarələrinin üstündə yox, içərisində yerləşdirilib, və WordPress növbəti daimi keçid saxlanışında bütün bu hissənin üzərinə yazıb.

---

Defolt daimi keçid bloku ilə həqiqətən lazım olan təhlükəsizlik və ya yönləndirmə qaydalarını birləşdirən təmiz, düzgün bir .htaccess qurun — pulsuz WordPress .htaccess generatoru ilə.