WordPress .htaccess: Пълното техническо ръководство за производителност, сигурност и SEO

Файлът .htaccess (Hypertext Access) е конфигурационен файл на Apache на ниво директория, който инструктира уеб сървъра как да обработва заявките към вашия WordPress сайт — без да изисква промени в глобалния httpd.conf. Всяка директива, която поставите в .htaccess, се прилага рекурсивно към директорията, в която се намира, и всички поддиректории под нея, което прави файла на коренно ниво единствения най-мощен инструмент, достъпен за WordPress администратор извън самия сървър.

Специално за WordPress, .htaccess е двигателят зад красивите постоянни връзки, първата линия на защита срещу злонамерен трафик и директен множител на производителността чрез компресия и кеширане в браузъра — всичко това без да се докосва плъгин.

Какво всъщност прави файлът .htaccess на WordPress

Apache обработва .htaccess при всяка отделна HTTP заявка. Това означава, че всяка директива, която напишете, има измеримо въздействие върху латентността, позицията за сигурност и поведението при обхождане. WordPress записва минимален блок за пренаписване в .htaccess автоматично, когато запазите структура на постоянни връзки, но този блок е само отправна точка. Файлът е способен да обработва:

• Пренаписване на URL адреси и пренасочвания чрез mod_rewrite
• Контрол на достъпа чрез mod_authz_host и mod_access_compat
• Инжектиране на HTTP заглавки на отговора чрез mod_headers
• Компресия на изхода чрез mod_deflate
• Контрол на кеша на браузъра чрез mod_expires
• Портали за удостоверяване чрез mod_auth_basic
• Персонализирани документи за грешки чрез директивата ErrorDocument

Разбирането кой Apache модул поддържа всяка директива е от критично значение — ако модулът не е зареден на вашия сървър, директивата мълчаливо се проваля или хвърля грешка 500. Винаги проверявайте наличността на модулите при вашия хост преди да внедрявате разширени правила.

Къде се намира файлът .htaccess и как да получите достъп до него

Основният файл .htaccess за инсталация на WordPress се намира в основната директория на документите — обикновено /public_html/, /var/www/html/, или еквивалентния път, зададен от вашия хост. Това е същата директория, която съдържа wp-config.php, wp-login.php и папката wp-content/.

Тъй като името на файла започва с точка, повечето операционни системи и FTP клиенти го скриват по подразбиране.

За да разкриете скрити файлове във FileZilla:

Server menu > Force showing hidden files

За да разкриете скрити файлове в cPanel File Manager:

Settings > Show Hidden Files (dotfiles)

В среда за VPS Хостинг, където имате SSH достъп, можете да потвърдите, че файлът съществува, и да проверите правата му директно:

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

Файлът трябва да е собственост на потребителя на уеб сървъра (обикновено www-data или apache) и да има права 644. Права за запис от всички (666 или 777) върху .htaccess са сериозна уязвимост в сигурността — всеки процес на сървъра може да презапише вашите правила.

Обяснение на стандартния WordPress .htaccess блок

Когато отидете на Настройки > Постоянни връзки в таблото на WordPress и запазите, WordPress записва следния блок:

# 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

Разбивка ред по ред:

RewriteEngine On — активира двигателя за пренаписване за контекста на тази директория.
RewriteBase / — задава базовия URL път за относителни пренаписвания. При инсталации в поддиректория, променете на /subdirectory/.
RewriteRule ^index.php$ - [L] — ако заявката е буквално за index.php, спрете обработката и го сервирайте директно.
RewriteCond %{REQUEST_FILENAME} !-f — продължете само ако заявеният път не е съществуващ файл.
RewriteCond %{REQUEST_FILENAME} !-d — продължете само ако заявеният път не е съществуваща директория.
RewriteRule . /index.php [L] — насочете всичко останало през предния контролер на WordPress.

Критично правило: Никога не редактирайте ръчно нищо между маркерите # BEGIN WordPress и # END WordPress. WordPress регенерира автоматично този блок и ще презапише вашите промени. Поставяйте всички персонализирани директиви над коментара # BEGIN WordPress или под коментара # END WordPress.
Как да създадете файл .htaccess, ако липсва
Липсващ файл .htaccess кара всички WordPress URL адреси, с изключение на началната страница, да връщат грешки 404, тъй като Apache няма инструкция да насочва заявките през index.php.
Метод 1: Регенериране чрез таблото
Отидете на Настройки > Постоянни връзки и кликнете Запази промените без да променяте нищо. WordPress ще се опита да запише файла автоматично, ако директорията е с права за запис.
Метод 2: Създаване ръчно чрез SSH
nano /var/www/html/.htaccess
Поставете стандартния блок, показан по-горе, запазете с Ctrl+O и излезте с Ctrl+X. След това задайте правилните права:
chmod 644 /var/www/html/.htaccess
chown www-data:www-data /var/www/html/.htaccess
Метод 3: Създаване чрез FTP
Създайте локално обикновен текстов файл, наименувайте го .htaccess (не .htaccess.txt — разширението трябва да отсъства), поставете стандартния блок и го качете в основната директория на документите в режим на прехвърляне ASCII.
URL пренасочвания: 301, 302 и правила за пренаписване
Постоянни пренасочвания 301
Пренасочването 301 сигнализира на търсачките, че URL адресът е преместен постоянно. Google прехвърля приблизително 90–99% от авторитета на връзките чрез 301. Използвайте го, когато преименувате slug на публикация, мигрирате от HTTP към HTTPS или консолидирате дублирано съдържание.
# 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/
Временни пренасочвания 302
Използвайте 302 само когато дестинацията е наистина временна — например по време на A/B тестване или прозорци за поддръжка. Търсачките не прехвърлят авторитет на връзките чрез 302.
Redirect 302 /sale/ https://yourdomain.com/promo-page/
Принудително HTTPS с mod_rewrite
Това е едно от най-важните правила за всеки производствен WordPress сайт. Поставянето му над WordPress блока гарантира, че целият HTTP трафик се пренасочва постоянно към HTTPS, преди WordPress дори да обработи заявката:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</IfModule>
Ако вашият сайт се намира зад балансьор на натоварването или CDN, който прекратява SSL (обичайно при облачна инфраструктура), използвайте вместо това X-Forwarded-Proto:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</IfModule>
Съчетаването на това с валиден SSL Сертификат е задължително условие както за сигурността, така и за сигналите за класиране на Google.
Премахване на наклонена черта в края от URL адреси, които не са директории
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{THE_REQUEST} s(.+?)/+s
RewriteRule ^(.+)/$ /$1 [R=301,L]
</IfModule>
Премахване на „category” от URL адресите на категориите
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^category/(.+)$ https://yourdomain.com/$1 [R=301,L]
</IfModule>
Предупреждение: Това правило изисква плъгин като WP No Category Base, за да актуализира и вътрешното маршрутизиране на WordPress, иначе ще създадете пренасочващи цикли.
Укрепване на сигурността чрез .htaccess
Защита на wp-config.php
wp-config.php съдържа вашите идентификационни данни за базата данни, ключове за удостоверяване и соли. Директният достъп от браузър трябва да бъде блокиран безусловно:
<Files wp-config.php>
    Order Allow,Deny
    Deny from all
</Files>
Защита на самия .htaccess
Предотвратете четенето на файла .htaccess чрез заявка от браузър:
<Files .htaccess>
    Order Allow,Deny
    Deny from all
</Files>
Деактивиране на разглеждането на директории
Ако дадена директория не съдържа index.php или index.html, Apache ще изброи съдържанието й по подразбиране — излагайки файловата ви структура на атакуващи:
Options -Indexes
Блокиране на злоупотреби с XML-RPC
xmlrpc.php е честа цел за атаки с усилване чрез груба сила. Ако не използвате Jetpack, отдалечено публикуване или pingback-ове, блокирайте го изцяло:
<Files xmlrpc.php>
    Order Deny,Allow
    Deny from all
</Files>
Ограничаване на достъпа до wp-login.php до конкретни IP адреси
На VPS с cPanel или всяка специализирана среда, където вашият IP е статичен, това е една от мерките за сигурност с най-голямо въздействие:
<Files wp-login.php>
    Order Deny,Allow
    Deny from all
    Allow from 203.0.113.10
    Allow from 198.51.100.25
</Files>
Заменете IP адресите с вашите действителни статични IP адреси. Ако работите от множество места или използвате динамичен IP, помислете вместо това за VPN с фиксиран изходен възел.
Блокиране на злонамерени потребителски агенти
Скрейпъри, скенери за уязвимости и спам ботове за коментари често се идентифицират с разпознаваеми низове на потребителски агент:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (ahrefsbot|semrushbot|mj12bot|dotbot|nikto|sqlmap) [NC]
RewriteRule .* - [F,L]
</IfModule>
Забележка: Блокирането на легитимни SEO обхождачи като Ahrefs и SEMrush ще ви попречи да виждате собствените си данни за обратни връзки в тези инструменти. Преценете този компромис въз основа на вашия случай на употреба.
Блокиране на достъп по 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>
Нотацията CIDR (напр. /24) ви позволява да блокирате цели подмрежи, което е полезно при справяне с координирани атаки от един IP диапазон.
Предотвратяване на хотлинкване на изображения
Хотлинкването консумира вашата честотна лента без да ви носи полза. Блокирайте външни сайтове да вграждат вашите изображения директно:
<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>
Добавяне на заглавки за сигурност чрез .htaccess
HTTP заглавките за сигурност са често пренебрегван слой на защита, който .htaccess може да инжектира без никакъв плъгин:
<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>
За Content Security Policy (CSP) стойността на заглавката трябва да бъде съобразена с конкретните източници на ресурси на вашия сайт — общ CSP ще наруши вградените скриптове и вграждания от трети страни.
Оптимизация на производителността
Активиране на Gzip компресия с mod_deflate
Gzip компресията намалява размера на HTML, CSS и JavaScript отговорите с 60–80%, като директно подобрява времето до първия байт (TTFB) и резултатите от 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>
Не компресирайте вече компресирани формати: image/jpeg, image/png, image/gif, image/webp, application/zip, application/pdf. Опитът за компресирането им губи CPU цикли и всъщност може да увеличи размера на отговора.
Кеширане в браузъра с mod_expires
Кеширането в браузъра инструктира браузърите на завръщащите се посетители да сервират статичните ресурси от локалния кеш, вместо да ги изтеглят отново от вашия сървър:
<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>
Съображение за cache-busting: Дългите времена за кеширане на CSS и JS означават, че браузърите няма да вземат актуализациите, докато кешът не изтече. Използвайте версионирани имена на файлове или низове за заявки (напр. style.css?ver=2.1) — функцията wp_enqueue_style() на WordPress обработва това автоматично чрез параметъра $ver.
Cache-Control заглавки за детайлен контрол
mod_expires задава заглавката Expires. За съответствие с модерните HTTP/1.1 и HTTP/2, задайте също изрично Cache-Control:
<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>
Директивата immutable казва на поддържащите браузъри (Firefox, Chrome) да не преvalidират ресурса по време на неговия живот, елиминирайки изцяло условните GET заявки.
Активиране на Keep-Alive
Постоянните връзки намаляват разходите за TCP ръкостискане при множество ресурси на една и съща страница:
<IfModule mod_headers.c>
    Header set Connection keep-alive
</IfModule>
Сравнение: .htaccess срещу конфигурация базирана на плъгини




Възможност
Директива .htaccess
Еквивалент на WordPress плъгин
Въздействие върху производителността




Пренаписване на URL адреси
Правила mod_rewrite
Yoast SEO, Redirection
.htaccess е по-бърз (без PHP разходи)


Gzip компресия
mod_deflate
WP Super Cache, W3 Total Cache
.htaccess е по-бърз (на ниво Apache)


Кеширане в браузъра
mod_expires
WP Rocket, LiteSpeed Cache
.htaccess е по-бърз (на ниво Apache)


Блокиране на IP
Deny from
Wordfence, iThemes Security
.htaccess е по-бърз (преди PHP)


Заглавки за сигурност
mod_headers
HTTP Headers plugin
.htaccess е по-бърз (на ниво Apache)


Защита на wp-login.php
Блок <Files>
Limit Login Attempts Reloaded
.htaccess е по-бърз (преди PHP)


Content Security Policy
mod_headers
CSP плъгини
Еквивалентно — и двете инжектират заглавки


Пренасочвания базирани на база данни
Не е приложимо
Redirection плъгин
Плъгинът печели при голям брой пренасочвания


GUI управление
Не е приложимо
All In One WP Security
Плъгинът печели за нетехнически потребители




Ключово архитектурно прозрение: Правилата .htaccess се изпълняват на ниво Apache модул, преди да бъде извикан PHP. Това означава, че блокираната заявка практически не консумира сървърни ресурси. Блокирането базирано на плъгин трябва да зареди WordPress, да зареди плъгина и след това да отхвърли заявката — консумирайки 10–50 пъти повече памет и CPU на блокирано попадение. При сайтове с голям трафик под бот атака, тази разлика е границата между оставането онлайн и срива.
Защита на чувствителни директории
Заключване на директорията wp-includes
Директорията wp-includes никога не трябва да сервира PHP файлове директно на браузъри:
<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>
Ограничаване на достъпа до директорията Uploads
Директорията wp-content/uploads/ трябва да сервира медийни файлове, но никога да не изпълнява PHP. PHP файл, качен чрез уязвим плъгин и изпълнен от тази директория, е класически вектор за атака с уеб шел:
<Directory "/var/www/html/wp-content/uploads">
    <FilesMatch ".php$">
        Order Deny,Allow
        Deny from all
    </FilesMatch>
</Directory>
Ако сте на Споделен Уеб Хостинг и не можете да използвате блокове <Directory> в .htaccess, създайте отделен файл .htaccess вътре в wp-content/uploads/ със:
<FilesMatch ".php$">
    Order Deny,Allow
    Deny from all
</FilesMatch>
Персонализирани страници за грешки
Заменете стандартните страници за грешки на Apache с брандирани, удобни за потребителя алтернативи:
ErrorDocument 400 /400.html
ErrorDocument 401 /401.html
ErrorDocument 403 /403.html
ErrorDocument 404 /404.html
ErrorDocument 500 /500.html
За WordPress страницата 404 обикновено се обработва от маршрутизирането index.php към шаблона 404.php на темата — но наличието на статичен резервен вариант за грешки 500 е ценно, тъй като 500 означава, че самият PHP може да е повреден.
Конфигурация на .htaccess за WordPress Multisite
WordPress Multisite изисква различен блок за пренаписване в зависимост от това дали използвате мрежови структури базирани на поддиректории или поддомейни.
Multisite базиран на поддиректории:
# 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 базиран на поддомейни изисква конфигурация на wildcard DNS на ниво регистратор на домейни — промяната само на .htaccess е недостатъчна. Ако управлявате собствения си DNS, това се обработва чрез DNS панела на вашия доставчик на Регистрация на домейни с wildcard A запис (*.yourdomain.com).
Разширени техники: Ограничаване на скоростта и филтриране на заявки
Блокиране на общи модели на атаки в низовете за заявки
<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>
Важна уговорка: Тези regex модели са полезен първи слой, но не са заместител на Web Application Firewall (WAF). Сложните атакуващи използват вариации на кодиране, които заобикалят простото съвпадение на низове. Третирайте тези правила като филтър за шум, а не като цялостна защита.
Ограничаване на методите на заявките
WordPress се нуждае само от GET, POST и HEAD. Блокирайте всички останали HTTP методи:
<LimitExcept GET POST HEAD>
    Order Deny,Allow
    Deny from all
</LimitExcept>
Най-добри практики и оперативна дисциплина
Преди всяко редактиране:

Изтеглете текущия .htaccess на вашата локална машина като резервно копие с дата (напр. htaccess-backup-2025-01-15.txt).
Тествайте промяната първо в staging среда, ако такава е налична.
Правете по една логична промяна наведнъж — никога не групирайте множество несвързани директиви в една сесия за редактиране.

След всяко редактиране:

Презаредете Apache, за да потвърдите, че синтаксисът е валиден, преди да тествате в браузър:

apachectl configtest

Ако configtest премине, презаредете плавно:

systemctl reload apache2

Тествайте конкретната функционалност, която сте променили, след което извършете пълна проверка на сайта с инструмент като curl -I https://yourdomain.com за проверка на заглавките на отговора.

Валидиране на синтаксиса без достъп до сървъра:
apachectl -t -f /path/to/.htaccess
На Dedicated Сървъри, където контролирате конфигурацията на Apache, помислете за преместване на критичните за производителността директиви от .htaccess в конфигурацията на виртуалния хост (блок <VirtualHost> в httpd.conf или специфичен за сайта конфигурационен файл). Apache чете .htaccess при всяка заявка, когато AllowOverride е активиран — преместването на директивите в основната конфигурация елиминира изцяло тези разходи при всяка заявка.
Отстраняване на често срещани грешки в .htaccess
Вътрешна грешка на сървъра 500
Най-честата причина е синтактична грешка в .htaccess. Журналът за грешки на Apache ще съдържа точния номер на реда:
tail -n 50 /var/log/apache2/error.log
Чести синтактични грешки:

Липсващ затварящ таг </IfModule>

Цикъл на пренасочване

Цикълът на пренасочване (ERR_TOO_MANY_REDIRECTS) обикновено се появява когато:

• Вашето правило за пренасочване към HTTPS не открива правилно, че връзката вече е защитена
• Имате конфликтни правила за пренасочване в .htaccess и в настройките на WordPress (Настройки > Общи URL адреси)
• CDN или прокси премахва сървърната променлива HTTPS

Диагностика:

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

Правилата за пренаписване не работят

Ако правилата mod_rewrite изглежда нямат ефект:

1. Потвърдете, че mod_rewrite е активиран: apache2ctl -M | grep rewrite
2. Потвърдете, че AllowOverride All (или поне AllowOverride FileInfo) е зададен в конфигурацията на виртуалния хост за вашата основна директория на документите
3. Потвърдете, че RewriteEngine On се появява преди всякакви RewriteRule в същия контекст

Страниците връщат грешка 403 Forbidden след добавяне на IP ограничения

Ако сте се заключили, като сте добавили правило за IP ограничение с печатна грешка в собствения си IP адрес, получете достъп до файла чрез File Manager на хостинг контролния панел (който работи на ниво файлова система, заобикаляйки Apache) и коригирайте или премахнете правилото.

Матрица за решения: Кога да използвате .htaccess срещу алтернативи

Контролен списък с ключови технически изводи

• Поставяйте всички персонализирани директиви извън маркерите # BEGIN WordPress / # END WordPress — над или под, но никога вътре.
• Проверявайте всеки обвивател <IfModule> дали съответства на модул, който действително е зареден на вашия сървър, преди да го внедрите.
• Винаги задавайте права на файла .htaccess на 644 — никога 666 или 777.
• Защитете wp-config.php, самия .htaccess, xmlrpc.php и wp-includes/*.php с изрични правила за отказ.
• Използвайте mod_deflate за компресия и mod_expires с Cache-Control: immutable за статични ресурси — само тези две промени могат значително да подобрят резултатите от Core Web Vitals.
• Принудете HTTPS на ниво .htaccess, а не само в настройките на WordPress, за да прихванете заявките преди зареждането на PHP.
• На VPS или dedicated среди, мигрирайте стабилните директиви от .htaccess към конфигурацията на виртуалния хост, за да елиминирате парсването на файла при всяка заявка.
• Правете резервно копие на .htaccess с датирано име на файл преди всяка сесия за редактиране и валидирайте синтаксиса с apachectl configtest след всяка промяна.
• Създайте отделен .htaccess вътре в wp-content/uploads/, който блокира изпълнението на PHP — това единствено правило затваря критичен вектор за атака с уеб шел.
• Третирайте правилата за сигурност в .htaccess като слой за намаляване на шума, а не като пълен WAF — съчетавайте ги с инструменти на ниво сървър като ModSecurity или WAF базиран на CDN за производствени среди.

Често задавани въпроси

Изисква ли редактирането на .htaccess рестартиране на Apache?

Не. Apache чете .htaccess при всяка HTTP заявка, когато AllowOverride е активиран, така че промените влизат в сила незабавно без рестартиране на сървъра. Въпреки това, стартирането на apachectl configtest преди и след редактирането е силно препоръчително за улавяне на синтактични грешки, преди да причинят грешка 500 в производствена среда.

Ще работят ли правилата на .htaccess на Nginx сървъри?

Не. .htaccess е механизъм специфичен за Apache. Nginx изобщо не чете файлове .htaccess. Еквивалентните правила трябва да бъдат написани в блоковете server {} или location {} в главния конфигурационен файл на Nginx. Много управлявани WordPress хостове използват Nginx и обработват правилата за пренаписване на ниво конфигурация на сървъра, правейки .htaccess неприложим на тези платформи.

Какви са разходите за производителността при използване на .htaccess?

Когато AllowOverride е активиран, Apache проверява за файл .htaccess във всяка директория от основната директория на документите до заявения файл при всяка отделна заявка. На сайт с дълбоки структури на директории, това може да означава 4–6 четения на файловата система на заявка. При сайтове с голям трафик, преместването на директивите в конфигурацията на виртуалния хост и задаването на AllowOverride None елиминира изцяло тези разходи.

Могат ли правилата на .htaccess да конфликтват с настройките за постоянни връзки на WordPress?

Да. Най-честият конфликт се появява, когато персонализирано RewriteRule пречи на модела на предния контролер на WordPress. Винаги поставяйте персонализираните правила за пренаписване над блока # BEGIN WordPress, за да бъдат оценени първи, и тествайте всички структури на постоянни връзки след добавяне на нова логика за пренаписване.

Как да отстраня грешка в правило на .htaccess, което не работи както се очаква?

Активирайте временно логването mod_rewrite на Apache в конфигурацията на вашия виртуален хост с LogLevel alert rewrite:trace3, след това възпроизведете заявката и прегледайте /var/log/apache2/error.log. Изходът от трасирането показва точно кои условия са били оценени, кои правила са съвпаднали и какъв е бил крайният пренаписан URL адрес. Деактивирайте трасиращото логване незабавно след отстраняване на грешката — то генерира изключително подробен изход и влияе на производителността.