Domyślny plik .htaccess WordPressa: kod i jak go przywrócić

Domyślny plik .htaccess WordPressa to krótki blok RewriteEngine, który oprogramowanie zapisuje w .htaccess w głównym katalogu witryny, aby linki bezpośrednie takie jak /2026/10/nazwa-wpisu/ działały, zamiast zwracać 404. Wygląda tak:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Te reguły pochodzą z kodu, którym WordPress generuje ten blok, i zgadzają się z własnym przewodnikiem WordPressa o .htaccess. WordPress zapisuje też trzy linie komentarza zaraz po # BEGIN WordPress, ostrzegające, że zmiany między znacznikami zostaną nadpisane. Nie wpływają one na działanie reguł.

W instalacji w podkatalogu WordPress wstawia ścieżkę podkatalogu zarówno do RewriteBase, jak i do ostatniej reguły, na przykład RewriteBase /blog/ i RewriteRule . /blog/index.php [L]. Sieci multisite używają innego bloku i WordPress nie zapisuje dla nich tego pliku automatycznie.

Najważniejsze informacje

• WordPress generuje ten blok na Apache i LiteSpeed, gdy ma prawo zapisu, a linki w przyjaznej formie są włączone. Wystarczy otworzyć Ustawienia > Bezpośrednie odnośniki.
• Jeśli plik jest brakujący lub uszkodzony, linki bezpośrednie zwracają 404, a strona główna nadal się wczytuje, bo nie potrzebuje reguł przepisywania.
• Wszystko, co dodajesz ty lub wtyczka, umieszczaj nad # BEGIN WordPress, nigdy między znacznikami. WordPress zastępuje wszystko między nimi, gdy aktualizuje plik.

Co robi każda linia

RewriteEngine On włącza moduł mod_rewrite Apache dla tego katalogu; bez tego poniższe reguły nic nie robią.

RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}] nie zmienia adresu URL (to właśnie oznacza -) i kopiuje nagłówek Authorization żądania do zmiennej serwera. WordPress odczytuje tę zmienną, aby pobrać nazwę użytkownika i hasło wysłane w nagłówku, na przykład hasło aplikacji.

RewriteBase / ustawia prefiks ścieżki, którego Apache używa dla przepisanych adresów URL. WordPress ustawia go zgodnie z położeniem witryny, więc instalacja w podkatalogu otrzymuje RewriteBase /blog/.

RewriteRule ^index\.php$ - [L] to zabezpieczenie: jeśli żądanie jest już index.php, przepisywanie się zatrzymuje i żądanie przechodzi bez zmian.

Dwie linie RewriteCond to właściwa logika. %{REQUEST_FILENAME} !-f i !-d pytają: „czy to żądanie NIE odpowiada prawdziwemu plikowi i NIE odpowiada prawdziwemu katalogowi?”. Oba warunki muszą być spełnione, aby zadziałała ostatnia reguła, więc prawdziwy obraz, plik CSS czy przesłany PDF są serwowane bezpośrednio i nigdy nie trafiają do trasowania WordPressa.

RewriteRule . /index.php [L] sprawia, że linki bezpośrednie działają. Wszystko, co przeszło te dwa warunki, trafia do index.php, a WordPress decyduje, jaki wpis, stronę lub archiwum oznacza dany adres URL.

Kiedy WordPress odtwarza ten plik, a kiedy nie

WordPress odświeża swoje reguły przepisywania za każdym razem, gdy wczytuje się ekran Ustawienia > Bezpośrednie odnośniki, więc wystarczy go otworzyć i nie trzeba klikać Zapisz zmiany. Jeśli brakuje .htaccess, WordPress go tworzy, o ile katalog ma prawo zapisu, a linki w przyjaznej formie są włączone. Jeśli plik istnieje i ma prawo zapisu, WordPress zastępuje blok między znacznikami.

To nie rozwiązuje problemu w tych przypadkach:

• Plik lub jego katalog nie ma prawa zapisu dla użytkownika, na którym działa PHP. Ekran pokaże błąd z informacją, że plik .htaccess nie ma prawa zapisu, oraz reguły do wklejenia. Na niektórych hostingach PHP działa jako inny użytkownik systemowy niż właściciel plików wgranych przez FTP, więc uprawnienia wyglądające dobrze w kliencie FTP mogą mimo to blokować WordPressa.
• Działasz na nginx. Przewodnik WordPressa o nginx mówi, że nginx nie ma pliku konfiguracyjnego na poziomie katalogu, takiego jak .htaccess, a WordPress nie może zmienić konfiguracji serwera. Odpowiednikiem tego trasowania jest dyrektywa try_files w konfiguracji serwera, którą musi edytować administrator.
• AllowOverride jest ustawione na None dla katalogu witryny w głównej konfiguracji Apache. Dokumentacja Apache mówi (cytat w oryginale): “This means .htaccess files are completely ignored unless you explicitly enable them for a directory.” Oznacza to, że pliki .htaccess są całkowicie ignorowane, dopóki nie włączysz ich jawnie dla katalogu. WordPress może zapisać idealny plik, a i tak nie będzie on działał. Reguły przepisywania wymagają AllowOverride FileInfo (lub All), co być może musi zmienić twój hosting.
• Linki bezpośrednie są ustawione na Prosty. Proste adresy URL nie potrzebują reguł przepisywania, więc WordPress nie tworzy dla nich tego pliku.

Jak przywrócić go ręcznie

Jeśli wpisy i strony zwracają 404, a strona główna działa, najpierw sprawdź, czy .htaccess nie jest brakujący lub uszkodzony. Napraw to w dwóch krokach.

1. Najpierw spróbuj poprawki jednym kliknięciem. Otwórz Ustawienia > Bezpośrednie odnośniki w panelu WordPressa i kliknij Zapisz zmiany, niczego nie zmieniając. Jeśli WordPress może zapisać plik, to go odtworzy. Jeśli nie może, ekran pokaże błąd i potrzebne reguły.

2. Jeśli to nie pomoże, utwórz plik ręcznie. Połącz się przez FTP/SFTP lub menedżer plików hostingu i przejdź do głównego katalogu witryny, zwykle tego, który zawiera wp-admin. Sprawdź, czy .htaccess istnieje. To plik z kropką na początku, więc niektóre menedżery plików domyślnie go ukrywają; włącz „pokaż pliki ukryte”.

• Jeśli go nie ma, utwórz nowy plik o nazwie dokładnie .htaccess (bez .txt, nic przed kropką).
• Wklej reguły pokazane przez WordPressa albo domyślny blok z początku tego przewodnika. W instalacji w podkatalogu dopasuj RewriteBase i ostatnią regułę.
• Zapisz i przeładuj link bezpośredni wpisu, aby potwierdzić, że działa.

Jeśli nadal jest 404, .htaccess może być ignorowany. Zapytaj hosting o AllowOverride, bo Apache ignoruje poprawny plik, gdy ta opcja jest wyłączona.

Twoje własne reguły a blok WordPressa

Wtyczka lub ręczna edycja może dodać własne reguły, takie jak przekierowania, ochrona przed hotlinkingiem czy nagłówki cache. Trzymaj je poza blokiem WordPressa i nad nim, aby działały przed jego ostatnią regułą, która przechwytuje resztę żądań:

# Reguły dodane przez ciebie lub wtyczkę: NAD znacznikami WordPressa
<FilesMatch "\.(jpg|jpeg|png|gif)$">
    # przykład: ochrona przed hotlinkingiem, reguły cache itd.
</FilesMatch>

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Wszystko umieszczone między # BEGIN WordPress i # END WordPress przepada przy następnej aktualizacji pliku przez WordPressa, a wystarczy do tego wczytanie ekranu Bezpośrednich odnośników. Linie przed znacznikami i po nich są zachowywane. Jeśli chodzi o przekierowania, zobacz reguły przekierowań .htaccess WordPressa zrobione dobrze, aby wiedzieć, gdzie powinny się znajdować i jak unikać pętli.

500 Internal Server Error zaraz po edycji pliku wskazuje na to, co właśnie zmieniono. Dokumentacja Apache mówi, że dziennik błędów prawdopodobnie wskaże niedozwoloną dyrektywę lub błąd składni. Mogą to powodować reguły skopiowane ze starego poradnika: Order to nieprawidłowe polecenie w Apache 2.4, chyba że załadowano mod_access_compat. Cofnij zmianę, aby przywrócić witrynę, a potem przeczytaj dziennik błędów.

Poza domyślnym blokiem

Domyślny blok obsługuje tylko trasowanie linków bezpośrednich i nagłówek Authorization. Aby zaostrzyć dostęp do wrażliwych plików, na przykład zablokować wykonywanie PHP w /uploads lub odmawiać bezpośrednich żądań do wp-config.php, zobacz reguły bezpieczeństwa .htaccess WordPressa, które naprawdę pomagają. Jeśli linki bezpośrednie zwracają 404 z innego powodu, takiego jak błędna struktura linków, warstwa cache serwująca stare reguły lub konflikt multisite w podkatalogu, inne przyczyny omawia przewodnik bezpośrednie odnośniki WordPressa, które nie działają.

Najczęściej zadawane pytania

Co to jest domyślny plik .htaccess WordPressa? To blok RewriteEngine, który WordPress zapisuje między # BEGIN WordPress i # END WordPress w pliku .htaccess w głównym katalogu witryny. Przekazuje nagłówek Authorization do PHP i wysyła każde żądanie, które nie jest prawdziwym plikiem ani katalogiem, do index.php.

Jaki jest dokładny domyślny kod .htaccess WordPressa? RewriteEngine On, reguła przekazująca nagłówek Authorization do PHP, RewriteBase /, reguła przepuszczająca dla index.php, dwa warunki sprawdzające, że żądanie nie jest prawdziwym plikiem ani katalogiem, oraz końcowa reguła wysyłająca wszystko inne do index.php. Pełny blok znajduje się na początku tego przewodnika.

Czemu wszystkie moje wpisy zwracają 404, oprócz strony głównej? Taki wzorzec daje brakujący lub uszkodzony plik .htaccess na Apache. Serwer znajduje stronę główną bez reguł przepisywania. Każdy inny link bezpośredni potrzebuje tych reguł, aby dotrzeć do index.php, więc bez nich Apache szuka pliku, który nie istnieje, i zwraca 404.

Czy WordPress automatycznie odtwarza .htaccess? Tak, na Apache lub LiteSpeed z mod_rewrite, jeśli linki bezpośrednie w przyjaznej formie są włączone i WordPress może tam zapisywać. Wystarczy otworzyć Ustawienia > Bezpośrednie odnośniki. Brakujący plik wymaga katalogu z prawem zapisu, a istniejący plik musi mieć prawo zapisu. W przeciwnym razie ekran pokaże błąd oraz reguły do ręcznego wklejenia.

Czemu nginx nie ma pliku .htaccess WordPressa? nginx nie ma pliku konfiguracyjnego na poziomie katalogu, takiego jak .htaccess w Apache. To samo trasowanie zapisuje się jako regułę try_files w konfiguracji serwera nginx, którą musi edytować administrator, bo WordPress nie może jej zmienić.

Czemu mój .htaccess zepsuł się po zapisaniu bezpośrednich odnośników? Sprawdź, czy własna reguła nie trafiła między znaczniki # BEGIN WordPress i # END WordPress. WordPress zastępuje wszystko między nimi, gdy aktualizuje plik, więc ta reguła przepada. Własne reguły trzymaj nad znacznikami.

Źródła

• WordPress Advanced Administration: .htaccess
• WordPress Advanced Administration: Nginx
• Kod źródłowy WordPressa: class-wp-rewrite.php, options-permalink.php, misc.php, load.php, user.php, vars.php
• Apache HTTP Server 2.4: .htaccess files, mod_rewrite, Upgrading to 2.4

---

Zbuduj czysty, poprawny .htaccess z domyślnym blokiem linków bezpośrednich i tymi regułami bezpieczeństwa lub przekierowań, których naprawdę potrzebujesz, za pomocą darmowego generatora .htaccess WordPressa.