Wpisy zwracają błąd 404, choć istnieją. Jak naprawić bezpośrednie odnośniki?

Strona główna otwiera się bez zarzutu, kokpit działa, wpisy widnieją na liście w panelu, a mimo to po kliknięciu dowolnego artykułu pojawia się komunikat o błędzie 404, czyli informacja, że strony nie znaleziono. To jedna z najczęstszych usterek WordPressa i zarazem jedna z tych, które wyglądają groźniej, niż są. Treści zwykle nie zginęły. Zawiódł mechanizm, który zamienia czytelny adres na właściwy wpis.

Ta instrukcja jest przeznaczona dla właścicieli firm i osób, które same opiekują się stroną na WordPressie. Nie wymaga umiejętności programowania. Potrzebny jest dostęp do kokpitu oraz, w części przypadków, do plików na serwerze przez menedżer plików w panelu hostingu albo program FTP.

Po lekturze czytelnik będzie umiał odróżnić usterkę adresów od rzeczywistego braku treści, ustalić, która z kilku przyczyn zachodzi, naprawić każdą z nich i sprawdzić, czy naprawa się utrzymała. Opisuję także sytuacje, w których sam właściciel strony niczego nie zmieni i sprawę trzeba przekazać dostawcy hostingu, razem z gotową treścią zgłoszenia.

Po czym rozpoznać, że zawiodły bezpośrednie odnośniki, a nie zniknęła treść?

Bezpośrednie odnośniki to stałe adresy wpisów, stron, kategorii i tagów. WordPress potrafi je budować na dwa sposoby. Adres prosty ma postać https://przyklad.pl/?p=123, gdzie liczba jest numerem wpisu w bazie danych. Adres przyjazny zawiera słowa, na przykład https://przyklad.pl/oferta-letnia/.

Adres prosty działa na każdym serwerze, ponieważ nie wymaga żadnej dodatkowej konfiguracji. Adres przyjazny działa tylko wtedy, gdy serwer przekazuje do WordPressa także te zapytania, którym nie odpowiada żaden prawdziwy plik ani katalog. Jeśli to przekazywanie przestaje działać, serwer sam szuka katalogu o nazwie „oferta-letnia”, nie znajduje go i zwraca błąd 404.

Typowy obraz usterki wygląda następująco:

• strona główna i kokpit otwierają się poprawnie, a wszystkie wpisy i podstrony zwracają błąd 404,
• wpisy są widoczne w kokpicie w menu „Wpisy” i mają status opublikowanych,
• komunikat o błędzie ma surowy wygląd serwera albo wygląd szablonu strony, zależnie od przyczyny,
• kłopot pojawił się po konkretnym zdarzeniu: przeniesieniu strony, zmianie hostingu, przywróceniu kopii, instalacji wtyczki, aktualizacji albo ręcznej edycji plików.

Prosty test, który rozstrzyga sprawę

Najpewniejszą odpowiedź daje otwarcie wpisu pod adresem prostym. Numer wpisu widać w kokpicie: po otwarciu wpisu do edycji w pasku adresu przeglądarki znajduje się fragment post=123. Tę liczbę wstawia się do adresu https://przyklad.pl/?p=123, zastępując przykładową domenę własną.

Jeśli wpis wyświetla się pod adresem prostym, treść jest bezpieczna, a naprawy wymaga wyłącznie obsługa adresów przyjaznych. Jeśli również adres prosty zwraca błąd, przyczyna leży gdzie indziej: wpis mógł trafić do kosza, mieć status szkicu albo zostać usunięty. Wtedy dalsze kroki z tej instrukcji nie pomogą i trzeba sięgnąć do kopii zapasowej.

Warto też zwrócić uwagę na wygląd komunikatu. Surowa strona serwera z napisem „Not Found” oznacza zwykle, że zapytanie w ogóle nie dotarło do WordPressa, więc winny jest plik konfiguracyjny albo ustawienia serwera. Strona błędu w wyglądzie szablonu, z nagłówkiem i stopką witryny, oznacza, że WordPress zapytanie otrzymał, ale nie dopasował go do żadnej treści. Wtedy częściej zawodzą nieodświeżone reguły, wtyczka albo konflikt nazw.

Skąd bierze się błąd 404 przy wpisach, które istnieją?

Przyczyn jest kilka i każda wymaga innej naprawy. Kolejność poniżej odpowiada temu, jak często spotykam je w praktyce, i jednocześnie kolejności, w jakiej najrozsądniej je sprawdzać.

Pierwsza przyczyna to nieaktualne reguły przepisywania adresów zapisane w bazie danych. WordPress przechowuje listę wzorców, według których rozpoznaje adresy. Po instalacji wtyczki dodającej nowy rodzaj treści, po zmianie motywu albo po przywróceniu kopii lista bywa niezgodna ze stanem faktycznym.

Druga przyczyna to brak, uszkodzenie albo niepełna zawartość pliku .htaccess w głównym katalogu strony. Na serwerach Apache i zgodnych z nim (często spotykanych na hostingach współdzielonych) właśnie ten plik nakazuje przekazywać zapytania do WordPressa. Plik zaczyna się od kropki, więc wiele programów traktuje go jako ukryty i pomija przy kopiowaniu. Dlatego usterka tak często pojawia się po przenosinach strony.

Trzecia przyczyna leży po stronie serwera: wyłączony moduł mod_rewrite, zakaz stosowania reguł z pliku .htaccess albo serwer innego rodzaju, na przykład Nginx, który tego pliku w ogóle nie czyta. Czwarta to wtyczka lub motyw, które zmieniają adresy bądź nadpisują reguły. Piąta dotyczy pojedynczych adresów: konflikt nazw, katalog na serwerze o takiej samej nazwie jak podstrona albo wpis o innym statusie, niż się wydaje.

Co zabezpieczyć przed rozpoczęciem naprawy?

Opisane niżej czynności są bezpieczne, ale dwie z nich dotyczą pliku, od którego zależy działanie całej witryny. Błąd w pliku .htaccess, nawet jedna zbędna litera, potrafi wywołać błąd 500 na wszystkich podstronach łącznie z kokpitem. Dlatego przed jakąkolwiek zmianą należy zrobić kopię tego pliku.

1. Należy zalogować się do panelu hostingu i otworzyć menedżer plików albo połączyć się z serwerem programem FTP.
2. W ustawieniach menedżera lub programu trzeba włączyć wyświetlanie plików ukrytych. Bez tego plik .htaccess nie będzie widoczny, nawet jeśli istnieje.
3. Należy przejść do głównego katalogu strony, czyli tego, w którym znajdują się katalogi wp-admin, wp-content i wp-includes oraz plik wp-config.php.
4. Jeśli plik .htaccess istnieje, pobiera się go na dysk komputera i zapisuje pod zmienioną nazwą, na przykład htaccess-kopia.txt. Jeśli pliku nie ma, należy to zanotować, ponieważ jest to już połowa diagnozy.

Przy okazji dobrze jest upewnić się, że istnieje aktualna kopia całej strony. Jeżeli nie ma co do tego pewności, sposób jej wykonania i sprawdzenia opisuję w tekście o tym, jak zrobić kopię zapasową WordPressa, która naprawdę działa. Naprawa odnośników nie zmienia treści wpisów, ale kopia pozwala pracować bez nerwów.

Jak odświeżyć reguły na ekranie „Bezpośrednie odnośniki”?

To czynność, która rozwiązuje większość przypadków i zajmuje minutę. Dokumentacja WordPressa podaje, że samo otwarcie ekranu ustawień bezpośrednich odnośników powoduje ponowne zbudowanie reguł. Zapis ustawień dodatkowo aktualizuje plik .htaccess, o ile WordPress ma prawo go zmienić.

1. W kokpicie należy otworzyć menu „Ustawienia” i wybrać pozycję „Bezpośrednie odnośniki”.
2. Trzeba sprawdzić, która struktura jest zaznaczona. Do wyboru są: „Prosty”, „Dzień i nazwa”, „Miesiąc i nazwa”, „Liczbowy”, „Nazwa wpisu” oraz „Własny format”. Zaznaczenia nie należy zmieniać. Dobrze jest zanotować je albo zrobić zrzut ekranu.
3. Bez wprowadzania jakichkolwiek zmian należy przewinąć ekran na dół i kliknąć przycisk „Zapisz zmiany”.
4. Na górze ekranu pojawi się komunikat. Trzeba go przeczytać, ponieważ jego treść mówi, co stało się z plikiem .htaccess.
5. W nowej karcie przeglądarki, najlepiej w oknie prywatnym, należy otworzyć jeden z wpisów, które zwracały błąd.

Co oznaczają komunikaty po zapisaniu ustawień?

Komunikat „Format bezpośrednich odnośników został zaktualizowany.” oznacza, że WordPress zbudował reguły na nowo i sam zaktualizował plik konfiguracyjny. Jeśli po tym komunikacie wpisy się otwierają, naprawa jest zakończona i pozostaje kontrola opisana w dalszej części.

Komunikat „Teraz należy zaktualizować plik .htaccess.” oznacza, że WordPress nie ma uprawnień do zapisu tego pliku. W takiej sytuacji u dołu ekranu pojawia się pole z regułami mod_rewrite, które powinny znaleźć się w pliku. Ich zawartość trzeba zaznaczyć, skopiować i wkleić do pliku samodzielnie, zgodnie z opisem w następnej sekcji.

Kto woli nie zajmować się tym samodzielnie, może zadzwonić pod numer 533 525 168 albo napisać na info@lukaszwudyka.pl, a przejmę sprawę: ustalę, dlaczego wpisy zwracają błąd 404, przywrócę działanie adresów bez zmiany ich struktury i sprawdzę, czy żaden odnośnik nie ucierpiał.

Jak sprawdzić i odtworzyć plik .htaccess?

Plik .htaccess to zwykły plik tekstowy z poleceniami dla serwera. WordPress zapisuje w nim swoje reguły między dwoma wierszami: # BEGIN WordPress oraz # END WordPress. Wszystko, co znajduje się między nimi, WordPress może w każdej chwili nadpisać, dlatego własnych poleceń nie wolno tam umieszczać.

W kokpicie można podejrzeć podstawowe informacje o tym pliku bez logowania na serwer. Należy otworzyć menu „Narzędzia”, wybrać „Stan witryny”, przejść do zakładki „Informacja” i rozwinąć sekcję „Serwer”. Wiersz „Serwer webowy” podaje rodzaj serwera, a wiersz „Reguły .htaccess” informuje, czy plik zawiera wyłącznie reguły WordPressa, czy także dodane własne. W sekcji „Uprawnienia systemu plików” widać, czy WordPress może zapisywać pliki w swoich katalogach.

Jak powinna wyglądać podstawowa zawartość pliku?

Dla pojedynczej witryny zainstalowanej w głównym katalogu domeny dokumentacja WordPressa podaje następujący zestaw reguł:

# BEGIN WordPress

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]

# END WordPress

WordPress zapisuje ten blok samodzielnie i często obejmuje go dodatkowo wierszami <IfModule mod_rewrite.c> oraz </IfModule>. Obie postaci są poprawne. Sens reguł jest prosty: jeśli zapytanie nie dotyczy istniejącego pliku ani katalogu, serwer ma je przekazać do pliku index.php, a WordPress sam ustali, który wpis wyświetlić.

Odtworzenie pliku krok po kroku

1. W menedżerze plików z włączonym widokiem plików ukrytych należy otworzyć główny katalog strony i odszukać plik .htaccess.
2. Jeśli plik istnieje, otwiera się go w edytorze i sprawdza, czy zawiera blok między wierszami # BEGIN WordPress i # END WordPress oraz czy blok jest kompletny.
3. Jeśli bloku brakuje albo jest urwany, najbezpieczniej skopiować reguły z pola u dołu ekranu „Bezpośrednie odnośniki”, ponieważ WordPress przygotowuje je dla konkretnej instalacji. Gdy pole się nie wyświetla, można użyć wzoru podanego wyżej.
4. Pozostałych poleceń w pliku nie należy usuwać. Poza blokiem WordPressa często znajdują się tam reguły wtyczek pamięci podręcznej, zabezpieczeń i przekierowania.
5. Jeśli pliku nie ma wcale, tworzy się nowy plik tekstowy o nazwie .htaccess, wkleja do niego blok reguł i zapisuje w głównym katalogu strony. Część systemów nie pozwala nadać na komputerze nazwy zaczynającej się od kropki. Wtedy plik wysyła się jako htaccess.txt i zmienia nazwę już na serwerze.
6. Po zapisaniu należy otworzyć wpis, który zwracał błąd, i sprawdzić wynik.

Jeżeli po zapisaniu pliku cała strona zaczęła zwracać błąd 500, w pliku znalazł się błąd składni albo polecenie, którego serwer nie obsługuje. Należy natychmiast przywrócić kopię pobraną przed zmianą. Dalszą diagnostykę takiej sytuacji opisuję w tekście o tym, jak ustalić przyczynę błędu 500 w WordPressie.

Co zrobić, gdy WordPress nie może zapisać pliku?

Komunikat o konieczności ręcznej aktualizacji wynika z uprawnień do pliku. Dokumentacja WordPressa wskazuje jako typowe ustawienie wartość 644 dla plików i 755 dla katalogów. Uprawnienia zmienia się w menedżerze plików albo w programie FTP, zwykle po kliknięciu pliku prawym przyciskiem myszy.

Nie należy nadawać uprawnień 777. Taki zapis pozwala modyfikować plik każdemu procesowi na serwerze, co na hostingu współdzielonym jest poważnym zagrożeniem. Jeśli przy wartości 644 WordPress nadal nie zapisuje pliku, przyczyną jest zwykle niezgodność właściciela plików po przenosinach strony. To już sprawa dla dostawcy hostingu.

Strona zainstalowana w podkatalogu

Jeśli WordPress działa pod adresem z podkatalogiem, na przykład https://przyklad.pl/blog/, reguły wyglądają nieco inaczej: wiersz RewriteBase i ostatni wiersz zawierają nazwę podkatalogu. Wklejenie wzoru przeznaczonego dla katalogu głównego spowoduje, że błąd 404 pozostanie. Dlatego w takich instalacjach reguły należy kopiować wyłącznie z ekranu „Bezpośrednie odnośniki”, a nie z cudzych przykładów.

Po zmianie domeny albo przejściu na https warto też otworzyć „Ustawienia”, a następnie „Ogólne” i porównać pola „Adres WordPressa (URL)” oraz „Adres witryny (URL)” z rzeczywistym adresem strony. Rozbieżność między nimi a faktycznym położeniem plików daje podobne objawy. Pola te trzeba zmieniać z rozwagą: błędny wpis odcina dostęp do kokpitu.

Co zrobić, gdy serwer nie stosuje reguł z pliku?

Zdarza się, że plik jest poprawny, WordPress potwierdził zapis, a wpisy wciąż zwracają surowy błąd serwera. Oznacza to, że serwer nie bierze reguł pod uwagę. Rodzaj serwera podaje wspomniany wiersz „Serwer webowy” na ekranie „Stan witryny”.

Serwer Apache: moduł mod_rewrite i zgoda na plik .htaccess

Adresy przyjazne wymagają na serwerze Apache włączonego modułu mod_rewrite oraz zgody na stosowanie reguł z pliku .htaccess w katalogu strony. Tę zgodę ustawia się w konfiguracji serwera dyrektywą AllowOverride. Dokumentacja WordPressa wymienia też opcję FollowSymLinks jako potrzebną do działania modułu.

Na hostingu współdzielonym klient nie ma dostępu do tych ustawień. Dokumentacja WordPressa mówi wprost, że serwer powinien zostać przygotowany przez dostawcę hostingu, a gdy tak nie jest, należy się z nim skontaktować. Zgłoszenie może mieć następującą treść:

Dzień dobry, na stronie w domenie [adres domeny] działającej na WordPressie wszystkie adresy wpisów zwracają błąd 404, choć wpisy otwierają się pod adresem w postaci ?p=numer. Plik .htaccess w głównym katalogu zawiera standardowy blok reguł WordPressa. Proszę o sprawdzenie, czy dla tej domeny włączony jest moduł mod_rewrite oraz czy konfiguracja serwera pozwala na stosowanie reguł z pliku .htaccess (dyrektywa AllowOverride), a także o podanie, czy przed serwerem Apache działa inny serwer pośredniczący.

Na własnym serwerze albo serwerze VPS zmiany wprowadza administrator w konfiguracji Apache, po czym uruchamia serwer ponownie. Nie polecam wykonywania tych czynności osobom bez doświadczenia, ponieważ błąd w konfiguracji wyłącza wszystkie strony na danym serwerze.

Serwer Nginx: reguły w konfiguracji serwera

Nginx nie ma odpowiednika pliku .htaccess. Według dokumentacji WordPressa cała konfiguracja odbywa się na poziomie serwera, a WordPress nie potrafi jej sam zmienić ani wygenerować reguł. Plik .htaccess przesłany na taki serwer niczego nie zmieni.

W konfiguracji witryny musi znajdować się polecenie przekazujące nieznane adresy do WordPressa. Wzorcowa konfiguracja z dokumentacji zawiera w tym celu następujący zapis:

location / {
    try_files $uri $uri/ /index.php?$args;
}

Na hostingach z panelem bywa to pojedynczy przełącznik albo gotowy zestaw reguł dla WordPressa. Jeśli panel takiej możliwości nie daje, zmianę wprowadza dostawca hostingu po zgłoszeniu. Warto wiedzieć, że wiele serwerów przedstawia się jako Nginx, choć Nginx pełni tam jedynie rolę pośrednika przed serwerem Apache. W takim układzie plik .htaccess nadal obowiązuje.

Rozwiązanie przejściowe: adresy z fragmentem index.php

Gdy na zmianę po stronie serwera trzeba poczekać, WordPress przewiduje rozwiązanie pośrednie. W polu „Własny format” strukturę można poprzedzić fragmentem /index.php/, na przykład /index.php/%postname%/. Takie adresy nie wymagają reguł przepisywania.

Trzeba jednak mieć świadomość skutków: adresy wszystkich wpisów się zmienią, a dotychczasowe przestaną działać. Traktuję to wyłącznie jako ratunek na krótki czas dla strony, która musi być dostępna. Po naprawie serwera należy wrócić do poprzedniej struktury, zapisanej wcześniej na zrzucie ekranu.

Jak znaleźć wtyczkę albo motyw, które psują adresy?

Jeśli reguły są odświeżone, plik poprawny, a serwer go stosuje, podejrzenie pada na dodatki. Adresy zmieniają wtyczki do wielojęzyczności, sklepy, wtyczki członkowskie, wtyczki dodające własne rodzaje treści, a także dodatki do przekierowań i zabezpieczeń, które dopisują własne polecenia do pliku .htaccess.

1. Należy przypomnieć sobie, co zmieniło się tuż przed pojawieniem się błędu: instalacja, aktualizacja albo zmiana ustawień konkretnej wtyczki. Od niej zaczyna się sprawdzanie.
2. W menu „Wtyczki” wyłącza się podejrzaną wtyczkę odnośnikiem „Wyłącz”. Wyłączenie nie usuwa jej ustawień.
3. Trzeba otworzyć „Ustawienia”, „Bezpośrednie odnośniki” i kliknąć „Zapisz zmiany”, aby reguły zbudowały się bez udziału tej wtyczki.
4. Należy sprawdzić wpis, który zwracał błąd. Jeśli działa, winowajca jest znany.
5. Jeśli błąd pozostał, wtyczkę włącza się z powrotem i powtarza czynności dla kolejnej. Przy dużej liczbie wtyczek szybciej jest wyłączyć wszystkie naraz, sprawdzić wynik, a potem włączać je pojedynczo.
6. Na końcu, na krótko, można przełączyć motyw na jeden z domyślnych motywów WordPressa i ponowić próbę.

Testy z wyłączaniem wtyczek najlepiej prowadzić poza godzinami największego ruchu albo na kopii roboczej strony, ponieważ na czas próby znikają funkcje, za które wtyczki odpowiadają. W sklepie internetowym oznacza to na przykład chwilowy brak koszyka.

Gdy winna okaże się wtyczka, są trzy drogi: zmiana jej ustawień dotyczących adresów, aktualizacja do nowszej wersji albo zgłoszenie błędu autorowi i zastąpienie jej inną. Nie radzę zostawiać strony z wtyczką, po której każdej aktualizacji trzeba ręcznie zapisywać ustawienia odnośników.

Co zrobić, gdy błąd dotyczy tylko jednego wpisu albo jednej grupy treści?

Jeśli większość adresów działa, a błąd 404 zwraca pojedynczy wpis, kategoria albo cała grupa treści jednego rodzaju, reguły ogólne są sprawne. Przyczyny trzeba szukać bliżej samej treści.

Status i adres pojedynczego wpisu

W pierwszej kolejności należy otworzyć wpis do edycji i sprawdzić jego status. Wpis zaplanowany na późniejszy termin, oczekujący na przegląd, prywatny albo zapisany jako szkic nie jest dostępny dla osób niezalogowanych. Autor zalogowany w kokpicie widzi go normalnie, co łatwo wprowadza w błąd. Dlatego test zawsze wykonuje się w oknie prywatnym przeglądarki.

Następnie trzeba porównać adres, pod którym wpis jest szukany, z adresem widocznym w edytorze w ustawieniach wpisu. Jeśli końcówka adresu została kiedyś zmieniona, stare odnośniki w menu, w treści innych wpisów albo w wynikach Google mogą prowadzić pod adres, który już nie istnieje. WordPress zwykle sam przekierowuje ze starej końcówki wpisu na nową, ale nie w każdej sytuacji. W razie potrzeby ustawia się przekierowanie ręcznie, zgodnie z opisem w tekście o przekierowaniu 301 w pliku .htaccess.

Konflikt nazw i katalog o tej samej nazwie

Reguły WordPressa przekazują mu tylko te zapytania, którym nie odpowiada prawdziwy plik ani katalog. Jeśli na serwerze, w głównym katalogu strony, istnieje katalog o nazwie sklep, to adres podstrony „sklep” obsłuży serwer, a nie WordPress. Skutkiem bywa błąd 404, błąd 403 albo lista plików. Rozwiązaniem jest zmiana nazwy katalogu albo końcówki adresu podstrony.

Podobny skutek daje zbieżność nazw wewnątrz WordPressa, gdy podstrona ma taką samą końcówkę adresu jak archiwum kategorii, baza odnośnika własnego rodzaju treści albo strona sklepu. WordPress dopasowuje adres do pierwszej pasującej reguły i druga treść staje się nieosiągalna. Wystarczy zmienić końcówkę adresu jednej z nich.

Własne rodzaje treści, kategorie i tagi

Gdy błąd zwracają wszystkie pozycje jednego rodzaju, na przykład realizacje, produkty albo oferty pracy dodawane przez wtyczkę lub motyw, przyczyną są niemal zawsze reguły nieodświeżone po rejestracji tego rodzaju treści. Pomaga otwarcie ekranu „Bezpośrednie odnośniki” i kliknięcie „Zapisz zmiany”. Jeśli po wyłączeniu wtyczki lub zmianie motywu dany rodzaj treści przestał istnieć, jego adresy będą zwracały błąd aż do ponownego włączenia tego dodatku.

Przy błędach w archiwach kategorii i tagów trzeba spojrzeć na pola „Baza odnośnika kategorii” i „Baza odnośnika tagu” u dołu ekranu „Bezpośrednie odnośniki”. Puste pola oznaczają wartości domyślne. Wpisanie tam nowej wartości zmienia adresy wszystkich kategorii lub tagów, więc stare odnośniki przestają działać. Jeśli zmiana nie była zamierzona, należy przywrócić poprzednią wartość.

Po czym poznać, że naprawa zadziałała?

Jeden otwarty wpis nie jest jeszcze dowodem. Przeglądarka, wtyczka pamięci podręcznej albo sieć dostarczania treści mogą przez pewien czas pokazywać zapamiętaną odpowiedź, zarówno poprawną, jak i błędną. Kontrolę warto przeprowadzić według stałej listy.

• W oknie prywatnym przeglądarki należy otworzyć po kilka adresów każdego rodzaju: wpis, podstronę, kategorię, tag, archiwum autora, produkt lub inną treść własnego rodzaju.
• Jeśli na stronie działa wtyczka pamięci podręcznej albo usługa CDN, trzeba wyczyścić ich zawartość i powtórzyć test.
• Należy otworzyć adres, który na pewno nie istnieje, na przykład z przypadkowym ciągiem liter. Powinien pojawić się błąd 404 w wyglądzie szablonu strony, co potwierdza, że zapytania trafiają do WordPressa.
• Trzeba sprawdzić, czy działa logowanie do kokpitu, podgląd wpisów oraz zapisywanie zmian w edytorze. Edytor korzysta z tych samych reguł i przy ich awarii bywa, że odmawia zapisu.

Po kilku dniach warto zajrzeć do Google Search Console, do raportu „Strony” w sekcji „Indeksowanie”. Jeśli awaria trwała dłużej, część adresów mogła trafić tam z powodem „Nie znaleziono (404)”. Po naprawie można zgłosić poprawkę przyciskiem „Sprawdź poprawkę”, a pojedynczy ważny adres zweryfikować w narzędziu „Sprawdzanie adresu URL”. Sposób odczytywania stanu indeksowania opisuję w tekście o tym, jak sprawdzić, czy Google zaindeksował stronę.

Co zrobić, gdy błąd wraca?

Powracający błąd 404 oznacza, że coś ponownie nadpisuje reguły albo plik. Najczęściej jest to wtyczka zmieniająca plik .htaccess przy każdej aktualizacji lub przy czyszczeniu pamięci podręcznej, rzadziej mechanizm hostingu przywracający pliki z wzorca. Pomaga porównanie zawartości pliku tuż po naprawie i tuż po nawrocie usterki: różnica wskazuje sprawcę.

Jeśli plik znika albo jego zawartość zmienia się na nieznane polecenia, przekierowania do obcych adresów lub ciągi niezrozumiałych znaków, trzeba brać pod uwagę włamanie. Wtedy sama naprawa odnośników nie wystarczy i należy przeprowadzić pełną kontrolę plików oraz zmienić hasła.

Jakich błędów unikać przy naprawie odnośników?

Większość szkód przy tej usterce nie wynika z samej awarii, lecz z pośpiesznych prób jej usunięcia. Poniższe błędy widuję najczęściej.

• Zmiana struktury adresów na inną w nadziei, że to pomoże. Każda taka zmiana zmienia adresy wszystkich wpisów i wymaga później przekierowań.
• Edycja pliku .htaccess bez wcześniejszego pobrania kopii. Przy błędzie składni nie ma wtedy do czego wrócić.
• Usuwanie z pliku wszystkiego poza blokiem WordPressa. Znikają wówczas przekierowania, reguły wymuszające https i ustawienia wtyczek.
• Dopisywanie własnych poleceń między wierszami # BEGIN WordPress i # END WordPress. WordPress nadpisze je przy najbliższym zapisie ustawień.
• Nadawanie plikom uprawnień 777, aby „na pewno dało się zapisać”.
• Usuwanie i ponowne publikowanie wpisów. Treść nie jest przyczyną błędu, a nowy wpis dostaje nowy numer i często nowy adres.

Najczęstsze pytania

Czy ponowne zapisanie ustawień odnośników może coś zepsuć?

Nie, o ile zaznaczona struktura pozostaje bez zmian. Zapis powoduje jedynie zbudowanie reguł na nowo i aktualizację bloku WordPressa w pliku konfiguracyjnym. Adresy wpisów, treści i ustawienia wtyczek pozostają takie same. Ryzyko pojawia się dopiero wtedy, gdy przed kliknięciem przycisku zostanie wybrana inna struktura.

Dlaczego strona główna działa, skoro wszystkie wpisy zwracają błąd?

Adres strony głównej odpowiada prawdziwemu katalogowi na serwerze, w którym znajduje się plik index.php, więc serwer obsługuje go bez żadnych reguł. Adresy wpisów nie mają odpowiedników wśród plików. Bez przekazania takich zapytań do WordPressa serwer nie ma czego wyświetlić i zwraca błąd 404.

Czy przy tej usterce można stracić wpisy?

Sama awaria odnośników niczego nie usuwa. Wpisy pozostają w bazie danych i są widoczne w kokpicie, a pod adresem prostym z numerem wpisu nadal się otwierają. Utratę treści mogą spowodować dopiero pochopne działania, na przykład usuwanie wpisów albo przywracanie starej kopii bez sprawdzenia jej daty.

Którą strukturę odnośników wybrać dla nowej strony?

Dla większości stron firmowych najwygodniejsza jest struktura „Nazwa wpisu”, ponieważ daje krótkie i zrozumiałe adresy. Wybór ma znaczenie przede wszystkim na początku. Na stronie działającej od dawna najlepszą strukturą jest zazwyczaj ta, która już obowiązuje, bo jej zmiana wymaga przekierowania wszystkich dotychczasowych adresów.

Czy plik .htaccess jest potrzebny na każdym serwerze?

Nie. Plik ten odczytują serwery Apache i zgodne z nim. Serwer Nginx go pomija i wymaga odpowiedniego zapisu w swojej konfiguracji, a serwery Microsoft IIS korzystają z pliku web.config. Rodzaj serwera można odczytać w kokpicie na ekranie „Stan witryny”, w zakładce „Informacja”, w sekcji „Serwer”.

Jak często trzeba odświeżać reguły odnośników?

Na sprawnej stronie nie trzeba robić tego wcale. Odświeżenie jest uzasadnione po przenosinach strony, po przywróceniu kopii zapasowej oraz po instalacji albo usunięciu wtyczki dodającej własne rodzaje treści. Jeśli reguły wymagają odświeżania co kilka dni, należy znaleźć dodatek, który je nadpisuje.

Brak czasu albo ochoty, żeby zająć się tym samodzielnie?

Błąd 404 na wszystkich wpisach potrafi zatrzymać sprzedaż i zapytania z dnia na dzień, a szukanie przyczyny w plikach serwera nie każdemu sprawia przyjemność. Chętnie zajmę się tym od początku do końca: sprawdzę, czy treści są bezpieczne, ustalę, czy zawiodły reguły, plik konfiguracyjny, serwer czy wtyczka, przywrócę działanie adresów bez zmiany ich struktury, a w razie potrzeby przeprowadzę rozmowę z dostawcą hostingu. Na koniec skontroluję odnośniki w serwisie i stan adresów w Google.

Wystarczy zadzwonić pod numer 533 525 168 albo napisać na adres info@lukaszwudyka.pl i podać adres strony oraz moment, w którym kłopot się pojawił. Odpowiem, co da się zrobić i ile to potrwa, spokojnie i bez zobowiązań.