Domyślny plik .htaccess WordPressa: co zawiera 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/ były rozwiązywane, a nie zwracały 404. Wygląda tak:

# 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

To dokładny blok, zaczerpnięty z oficjalnego przewodnika WordPressa o Apache HTTP Server oraz logiki przepisywania opisanej na stronie HelpHub o przyjaznych linkach. Jeśli twoje RewriteBase nie jest / — na przykład bo WordPress jest zainstalowany w podkatalogu — będzie zamiast tego odpowiadać tej ścieżce, co jest równie normalne i generowane przez sam WordPress.

Najważniejsze informacje

• WordPress generuje ten blok automatycznie, tylko na Apache i LiteSpeed, gdy plik ma uprawnienia do zapisu i zapisujesz Ustawienia > Bezpośrednie odnośniki.
• Jeśli plik jest brakujący lub uszkodzony, wszystkie linki bezpośrednie oprócz strony głównej zwracają 404, bo tylko stronę główną można znaleźć bez reguł przepisywania.
• Wszystko, co dodasz ty lub wtyczka, musi znajdować się nad # BEGIN WordPress, nigdy wewnątrz znaczników — WordPress nadpisuje wszystko między nimi przy każdym zapisie bezpośrednich odnośników.

Potrzebujesz odbudować plik z prawdziwą ścieżką i dodatkowymi regułami? Generator .htaccess WordPressa zbuduje poprawny plik prosto w przeglądarce.

Co robi każda linia

RewriteEngine On włącza moduł mod_rewrite Apache dla tego katalogu; bez tego wszystko poniżej jest nieaktywne.

RewriteBase / mówi Apache, że przepisane ścieżki są względne do głównego katalogu witryny. WordPress ustawia to zgodnie z rzeczywistym miejscem instalacji — instalacja w podkatalogu otrzymuje RewriteBase /blog/, nie /.

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

Dwie linie RewriteCond to prawdziwa logika. %{REQUEST_FILENAME} !-f i !-d pytają “czy to żądanie NIE odpowiada prawdziwemu plikowi i NIE odpowiada prawdziwemu katalogowi?”. Obie muszą być prawdziwe, by zadziałała ostatnia reguła — dzięki temu prawdziwy obraz, plik CSS czy przesłany PDF są serwowane bezpośrednio i nigdy nie dotykają trasowania WordPressa.

RewriteRule . /index.php [L] to to, co sprawia, że linki bezpośrednie działają: wszystko, co przetrwało dwa poprzednie warunki — czyli nie jest prawdziwym plikiem lub katalogiem — zostaje wysłane do index.php, a własne trasowanie WordPressa (WP_Query, znaczniki przepisywania) decyduje, który wpis, strona czy archiwum jest naprawdę tym adresem URL.

Kiedy WordPress odtwarza ten plik, a kiedy nie

WordPress sam próbuje zapisać .htaccess każdym razem, gdy otwierasz Ustawienia > Bezpośrednie odnośniki i klikasz Zapisz zmiany, nawet jeśli nic się na ekranie nie zmieniło. Ten zapis wywołuje flush_rewrite_rules(), które próbuje otworzyć .htaccess do zapisu i wstawić aktualny blok między znacznikami.

Ta próba zawodzi bez ostrzeżenia, pozostawiając plik brakujący lub nieaktualny, gdy:

• Plik lub jego katalog nadrzędny nie mają uprawnień do zapisu dla użytkownika, na którym działa PHP. Na wielu hostingach współdzielonych PHP działa jako inny użytkownik systemowy niż ten, który wgrał pliki przez FTP, więc uprawnienia wyglądające poprawnie w kliencie FTP mogą mimo to blokować zapis WordPressa.
• Działasz na nginx. .htaccess to mechanizm wyłącznie Apache i LiteSpeed (sama dokumentacja Apache o AllowOverride wyjaśnia dlaczego: nginx nie ma pliku konfiguracyjnego na katalog, który wczytuje ponownie przy każdym żądaniu). Odpowiednikiem na nginx jest dyrektywa try_files w bloku server, którą może edytować tylko osoba z dostępem do serwera; WordPress nigdy nie może jej zapisać za ciebie.
• AllowOverride jest ustawiony na None dla katalogu witryny w głównej konfiguracji Apache. To ustawienie decyduje, czy .htaccess może w ogóle coś nadpisać; dokumentacja Apache mówi wyraźnie: przy AllowOverride None “pliki .htaccess są całkowicie ignorowane” — WordPress może zapisać idealny plik, a mimo to nie będzie miał żadnego efektu, dopóki ustawienie to nie zostanie zmienione na poziomie serwera.
• Plik został usunięty lub nigdy nie istniał, a coś w zapisie nie wywołało regeneracji — najczęściej dlatego, że struktura bezpośrednich odnośników była już taka sama, więc WordPress nie zobaczył żadnej zmiany do zapisania.

Jak przywrócić go ręcznie

Jeśli wpisy i strony zwracają 404, a strona główna wciąż działa, to typowy sygnał brakującego lub uszkodzonego .htaccess. Napraw to w dwóch krokach.

1. Najpierw spróbuj poprawki jednym kliknięciem. Przejdź do Ustawienia > Bezpośrednie odnośniki w panelu WordPressa i kliknij Zapisz zmiany bez niczego zmieniania. Jeśli plik ma uprawnienia do zapisu, to samo go odtworzy i problem zniknie.

2. Jeśli to nie pomoże, utwórz plik ręcznie. Połącz się przez FTP/SFTP lub menedżer plików hostingu, przejdź do katalogu, w którym zainstalowany jest WordPress (ten, który zawiera wp-config.php), i sprawdź, czy .htaccess w ogóle istnieje — to plik skryty, niektóre menedżery plików domyślnie go ukrywają; włącz “pokaż pliki skryte”.

• Jeśli go nie ma, utwórz nowy plik o nazwie dokładnie .htaccess (bez .txt, nic przed kropką).
• Wklej domyślny blok z góry, dopasowując RewriteBase, jeśli WordPress jest w podkatalogu.
• Zapisz i przeładuj link bezpośredni wpisu, by potwierdzić, że działa.

Jeśli po tym wciąż jest 404, przyczyna zmieniła się z “brakuje .htaccess” na “.htaccess jest ignorowany” — zapytaj hosting o AllowOverride, bo poprawny plik w katalogu, gdzie Apache ma rozkaz go ignorować, zachowuje się identycznie jak brak pliku.

Twoje własne reguły a blok WordPressa

Wtyczka lub ręczna edycja może dodać własne reguły — przekierowania, ochronę przed hotlinkingiem, nagłówki cache. To odrębny, osobny blok od tego, który generuje WordPress, i te dwa nigdy nie powinny się nakładać:

# 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
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 zostaje usunięte bez ostrzeżenia, gdy ktoś następny raz zapisze ekran Bezpośrednich odnośników, bo WordPress traktuje cały ten fragment jako swój i przepisuje go od nowa. To najczęstsza przyczyna “moja własna reguła zniknęła” — nigdy nie została usunięta celowo, po prostu znajdowała się w bloku, który WordPress uważa za swój. Jeśli chodzi konkretnie o przekierowania, zobacz reguły przekierowań .htaccess WordPressa zrobione dobrze, żeby wiedzieć, gdzie powinny się znajdować i jak unikać pętli.

To też najczęstsza przyczyna nagłego 500 Internal Server Error zaraz po edycji pliku: reguła skopiowana z forum napisanego dla innej wersji Apache (składnia Order/Deny z 2.2 wymieszana ze składnią Require z 2.4) psuje parsowanie całego pliku, w tym blok WordPressa poniżej, i pada cała witryna — nie tylko ta część, którą edytowałeś.

Poza domyślnym blokiem

Domyślny blok obsługuje tylko trasowanie bezpośrednich odnośników. Jeśli chcesz też zabezpieczyć dostęp do wrażliwych plików albo dodać kilka reguł .htaccess, które naprawdę ograniczają powierzchnię ataku — blokowanie wykonywania PHP w /uploads, odmawianie bezpośrednich żądań do wp-config.php — zobacz reguły bezpieczeństwa .htaccess WordPressa, które naprawdę pomagają. A jeśli bezpośrednie odnośniki zwracają 404 z innego powodu — błędna struktura linków, warstwa cache serwująca stare reguły, konflikty multisite w podkatalogach — bezpośrednie odnośniki WordPressa, które nie działają przechodzi przez inne przyczyny.

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, aby linki bezpośrednie były rozwiązywane do index.php, a nie zwracały 404.

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

Czemu wszystkie moje wpisy zwracają 404, oprócz strony głównej? Stronę główną można znaleźć bez żadnej reguły przepisywania; każdy inny link bezpośredni ich potrzebuje. Brakujący lub uszkodzony .htaccess na Apache daje właśnie taki wzorzec.

Czy WordPress automatycznie odtwarza .htaccess? Tylko gdy plik ma uprawnienia do zapisu — ponowne zapisanie Ustawień > Bezpośrednich odnośników to wywołuje. Jeśli plik nie ma uprawnień do zapisu, nie istnieje na hostingu, który go nie generuje automatycznie, albo AllowOverride jest wyłączony, WordPress nie może tego naprawić za ciebie i musisz utworzyć lub poprawić plik ręcznie.

Czemu nginx nie ma pliku .htaccess WordPressa? .htaccess działa tylko na Apache i LiteSpeed. nginx nie ma pliku konfiguracyjnego na katalog i całkowicie ignoruje .htaccess; to samo trasowanie zapisuje się jako reguła try_files w bloku server nginx.

Czemu mój .htaccess zepsuł się po zapisaniu bezpośrednich odnośników? Własna reguła została umieszczona wewnątrz znaczników # BEGIN WordPress / # END WordPress zamiast nad nimi, a WordPress nadpisał cały ten fragment przy kolejnym zapisie bezpośrednich odnośników.

---

Zbuduj czysty, poprawny .htaccess — domyślny blok bezpośrednich odnośników plus wszelkie reguły bezpieczeństwa czy przekierowań, których naprawdę potrzebujesz — za pomocą darmowego generatora .htaccess WordPressa.