Nie działa u wszystkich czy tylko u Ciebie? Od tego zacznij diagnozę
Zanim zaczniesz cokolwiek zmieniać, sprawdź stronę w drugim środowisku: inne urządzenie i inna sieć. Najszybszy test to otwarcie adresu na telefonie z transmisją komórkową zamiast Wi-Fi. Jeśli tam działa, problem leży między Tobą a serwerem – w przeglądarce, DNS, sieci lokalnej, VPN lub u operatora. Jeśli nie działa nigdzie, awaria dotyczy samego serwisu.
To rozróżnienie wygląda banalnie, a decyduje o tym, czy nie stracisz godziny na naprawianie czegoś, co działa. Najczęstszy błąd polega na pominięciu tego kroku i rzuceniu się od razu do panelu hostingu. Druga pułapka jest subtelniejsza: strona może odpowiadać poprawnie, ale pokazywać starą zawartość z pamięci podręcznej. Wtedy „nie działa” oznacza zupełnie inny problem niż brak odpowiedzi serwera i wymaga innej ścieżki diagnostycznej.
Nie możesz wejść na cudzą stronę – co możesz sprawdzić po swojej stronie
Jeśli to nie Twoja witryna, Twoje możliwości kończą się na wykluczeniu własnego urządzenia i sieci. Zrób to w tej kolejności, od najszybszego testu do najbardziej czasochłonnego:
Tryb prywatny przeglądarki. Pomija pliki cookie i część pamięci podręcznej. Jeśli strona tam działa, winne są dane zapisane w przeglądarce lub rozszerzenie.
Inna przeglądarka. Rozdziela problem przeglądarki od problemu systemu i sieci. Jeśli działa w drugiej, nie szukaj dalej na poziomie routera.
Wyłączenie VPN i serwera proxy. Część serwisów blokuje ruch z adresów IP znanych dostawców VPN, a źle skonfigurowane proxy potrafi zatrzymać połączenie bez żadnego komunikatu.
Zmiana serwera DNS na publiczny. Google DNS (8.8.8.8) lub Cloudflare (1.1.1.1) omijają resolver operatora. Jeśli po zmianie strona się otwiera, problemem był DNS Twojego dostawcy internetu.
Antywirus i zapora. Oprogramowanie ochronne czasem klasyfikuje stronę jako zagrożenie i blokuje ją bez wyraźnej informacji.
Gdy żaden z tych kroków nie pomaga, a inne strony działają normalnie, problem jest po stronie serwisu i nie masz nad nim kontroli. Jedyne sensowne działania to poinformowanie właściciela i odczekanie. Opisany dalej katalog przyczyn pomoże Ci ocenić, czy chodzi o chwilową usterkę, czy o coś, co potrwa dłużej – jeśli domena przekierowuje na stronę parkingową z reklamami, to nie jest awaria serwera, tylko wygasły adres, a to zwykle kwestia dni, nie minut.
To Twoja strona przestała działać – jak potwierdzić skalę awarii
Jako właściciel potrzebujesz twardej informacji o tym, co zwraca serwer, a nie tego, co pokazuje Twoja przeglądarka. Trzy rzeczy ustal od razu: kod odpowiedzi HTTP, moment rozpoczęcia problemu i zakres – czy nie działa cała witryna, czy tylko wybrane podstrony albo funkcje.
Kod odpowiedzi sprawdzisz zewnętrznym narzędziem sprawdzającym nagłówki HTTP lub dostępność z kilku lokalizacji. Brak jakiejkolwiek odpowiedzi oznacza co innego niż błąd 500 – pierwszy wskazuje na DNS, serwer lub połączenie, drugi na aplikację, która odpowiada, ale się wywraca. Zapisz też godzinę pierwszego zgłoszenia i sprawdź, czy pokrywa się z jakąkolwiek zmianą: aktualizacją, wdrożeniem, migracją, zmianą wersji PHP.
Jedno zastrzeżenie, o którym łatwo zapomnieć: strona może zwracać poprawny kod 200 i mimo to być bezużyteczna dla klienta, jeśli nie działa koszyk, logowanie lub formularz. Monitoring, który sprawdza tylko stronę główną, takiej awarii nie wykryje. To argument za obserwowaniem kluczowych ścieżek, a nie samego adresu domeny – szerzej opisuję to w tekście o tym, jak kontrolować dostępność i uptime serwisów.
Co oznacza komunikat błędu, który widzisz zamiast strony?
Komunikat błędu to najszybsza wskazówka, w której warstwie szukać przyczyny: w DNS, w połączeniu, w serwerze czy w aplikacji. Nie wskazuje winowajcy wprost, ale zawęża obszar z kilkunastu możliwości do dwóch lub trzech.
|
Komunikat / kod |
Co się stało |
Gdzie szukać przyczyny |
|---|---|---|
|
DNS_PROBE_FINISHED_NXDOMAIN |
Domena nie rozwiązuje się na żaden adres IP |
Wygasła domena, usunięty rekord A, zmiana serwerów nazw |
|
ERR_NAME_NOT_RESOLVED |
Przeglądarka nie uzyskała odpowiedzi od serwera DNS |
DNS urządzenia lub operatora, strefa DNS domeny |
|
ERR_CONNECTION_TIMED_OUT |
Serwer nie odpowiedział w ogóle |
Serwer offline lub przeciążony, zapora, zły wpis w pliku hosts |
|
ERR_CONNECTION_REFUSED |
Serwer aktywnie odrzucił połączenie |
Usługa WWW nie działa, zablokowany port, proxy |
|
„Połączenie nie jest prywatne” |
Problem z certyfikatem |
Wygasły SSL, brak wersji www w certyfikacie, niepełny łańcuch |
|
403 Forbidden |
Serwer odpowiada, ale blokuje dostęp |
Uprawnienia plików, reguły .htaccess, blokada IP, WAF |
|
404 Not Found |
Serwer działa, zasobu pod tym adresem nie ma |
Zmiana adresów, błędne przekierowania, przeniesiona treść |
|
500 Internal Server Error |
Aplikacja przerwała działanie |
Błąd PHP, konflikt wtyczki, uszkodzony .htaccess, baza danych |
|
502 / 504 |
Serwer pośredniczący nie dostał odpowiedzi |
Proces PHP, timeouty, długie zapytania do bazy, CDN |
|
503 Service Unavailable |
Usługa czasowo niedostępna |
Prace techniczne, przekroczone limity zasobów, tryb konserwacji |
|
Biała strona |
Serwer odpowiada, ale bez treści |
Błąd krytyczny PHP z ukrytym wyświetlaniem, limit pamięci |
Dwa rozróżnienia warte zapamiętania. Pierwsze: kody z grupy 4xx oznaczają, że serwer działa – nie dzwoń do hostingu z błędem 404. Drugie: 503 jest jedynym kodem z tej listy, który komunikuje stan tymczasowy, i to właśnie jego należy zwracać podczas planowanych prac, zamiast pokazywać błąd 500 albo pustą stronę. Różnicę w tym, jak traktuje to wyszukiwarka, rozwijam w sekcji o wpływie awarii na pozycje.
Jeśli widzisz białą stronę lub komunikat o błędzie krytycznym w WordPressie, przyczyna jest zwykle po stronie konkretnej wtyczki lub motywu – rozkładam to na czynniki pierwsze we wpisie o tym, co zrobić, gdy w witrynie wystąpił błąd krytyczny.
Domena, hosting i DNS – przyczyny, o których właściciel strony zapomina najczęściej
Najczęstsza przyczyna nagłego zniknięcia strony nie jest techniczna, tylko administracyjna: nieopłacona domena albo hosting. Pliki strony leżą nietknięte na serwerze, a mimo to nikt nie może się do nich dostać, bo przestał działać adres albo usługa została zawieszona.
Domena nie jest kupowana na własność – to prawo do korzystania z nazwy przez opłacony okres. Po jego upływie przechodzi przez kolejne stany: okres, w którym można ją jeszcze odnowić w zwykłej cenie, fazę wykupu z dodatkową opłatą reaktywacyjną, a na końcu kolejkę do usunięcia, po której nazwa wraca do puli wolnych adresów. Dokładne długości tych etapów zależą od końcówki domeny i polityki rejestratora, więc nie zgaduj – sprawdź status w bazie WHOIS albo w panelu rejestratora. Praktyczny wniosek jest prosty: im wcześniej to zrobisz, tym tańsze i pewniejsze odzyskanie adresu. Po przejściu do fazy usuwania nie ma już czego ratować.
Drugi obszar to DNS. Strona przestaje się otwierać nie dlatego, że zniknęła, ale dlatego, że domena wskazuje na niewłaściwy adres IP. Typowe momenty, w których to się dzieje:
Zmiana hostingu. Rekord A wskazuje jeszcze na stary serwer, który został już wyłączony. Objaw bywa niespójny – część użytkowników widzi stronę, część nie.
Zmiana serwerów nazw. Domena zaczyna korzystać z nowej strefy DNS, w której brakuje części rekordów. Najczęściej razem ze stroną przestaje działać poczta, bo zgubiono rekordy MX.
Rekord AAAA. Jeśli domena ma wpis IPv6 wskazujący na nieaktywny adres, strona będzie niedostępna wyłącznie dla użytkowników w sieciach z IPv6. To jedna z trudniejszych do namierzenia sytuacji, bo u właściciela zwykle wszystko działa.
Proxy CDN. Przy włączonym proxy ruch nie trafia bezpośrednio na serwer, więc sprawdzanie adresu IP domeny nie powie Ci nic o stanie hostingu.
Trzecia typowa przyczyna z tej grupy to certyfikat SSL. Darmowe certyfikaty odnawiają się automatycznie co kilkadziesiąt dni i problem pojawia się dopiero wtedy, gdy automat przestanie działać po migracji albo zmianie konfiguracji, a nikt tego nie zauważa aż do dnia wygaśnięcia. Przeglądarka nie zablokuje wtedy strony całkowicie, ale pokaże ostrzeżenie, które dla większości odwiedzających jest równoznaczne z awarią. Druga wersja tego samego problemu jest podstępniejsza: certyfikat obejmuje tylko adres bez „www”, więc jedna wersja strony otwiera się normalnie, a druga straszy komunikatem o braku bezpieczeństwa.
Zanim zmienisz cokolwiek w strefie DNS, obniż wartość TTL rekordów do około 300 sekund i odczekaj dobę. Dzięki temu ewentualna pomyłka będzie odwracalna w kilka minut, a nie przez kolejne 24 godziny. Jeśli zmianę już wprowadziłeś i okazała się błędna, cofnięcie jej nie działa natychmiast – stary wpis siedzi w pamięci podręcznej resolverów dokładnie tyle, ile wynosił TTL.
Ten sam mechanizm jest najczęstszym źródłem kłopotów przy przenosinach serwisu, dlatego przed migracją warto przejść całą procedurę po kolei – opisałem ją w poradniku o tym, jak przenieść stronę WordPress na inną domenę.
Aktualizacja, kod, baza danych i włamanie – kiedy problem leży w samej stronie
Jeśli serwer odpowiada, a domena rozwiązuje się poprawnie, przyczyna jest w aplikacji. Pierwsze pytanie brzmi zawsze tak samo: co zmieniło się tuż przed awarią. W zdecydowanej większości przypadków strona nie psuje się sama – psuje ją aktualizacja, nowa wtyczka, zmiana wersji PHP albo modyfikacja pliku konfiguracyjnego.
Cztery scenariusze, które warto rozpoznawać po objawach:
Konflikt po aktualizacji. Biała strona albo błąd krytyczny pojawiający się natychmiast po zaktualizowaniu wtyczki lub motywu. Rozwiązanie polega na wyłączeniu podejrzanego komponentu przez FTP lub menedżer plików, gdy panel jest niedostępny. Ryzyko tej sytuacji mocno spada, jeśli aktualizacje przeprowadzasz etapami, a nie wszystkie naraz – opisuję to w poradniku o bezpiecznej aktualizacji WordPressa.
Niezgodność wersji PHP. Objawy bywają częściowe: działa strona główna, nie działa panel albo konkretna funkcja. Zwykle to efekt przełączenia wersji PHP na serwerze przy starym motywie lub wtyczce, która jej nie obsługuje. Zmianę wersji zawsze testuj wcześniej, co rozwijam w tekście o tym, jak zaktualizować PHP w WordPressie.
Błąd połączenia z bazą danych. Komunikat jest jednoznaczny i wskazuje albo na zmienione hasło w pliku konfiguracyjnym, albo na przeciążoną lub uszkodzoną bazę. To jedna z nielicznych sytuacji, w których kontakt z hostingiem jest sensowny od razu.
Włamanie lub infekcja. Typowe objawy to przekierowania na obce adresy, doklejony kod w nagłówku strony, ostrzeżenie Google o niebezpiecznej witrynie albo nagły wzrost obciążenia serwera. Niedziałająca strona jest tu scenariuszem łagodniejszym niż strona, która działa i rozsyła złośliwy kod.
Przy podejrzeniu infekcji kolejność działań jest inna niż przy zwykłej awarii: najpierw odcinasz dostęp i zmieniasz hasła, dopiero potem przywracasz kopię. Przywrócenie backupu bez usunięcia luki oznacza ponowne zainfekowanie, często w ciągu kilkudziesięciu godzin. Praktyczną procedurę krok po kroku opisałem w tekście o tym, jak usunąć wirusa ze strony internetowej.
Narzędziem, które najszybciej zamienia zgadywanie w diagnozę, są logi błędów serwera. W WordPressie możesz dodatkowo włączyć zapis komunikatów diagnostycznych do pliku, ustawiając w wp-config.php stałe WP_DEBUG i WP_DEBUG_LOG na true, przy WP_DEBUG_DISPLAY ustawionym na false, żeby błędy nie pokazywały się odwiedzającym. Po zakończeniu diagnostyki debugowanie wyłącz – logi potrafią zawierać ścieżki systemowe i dane, których nie chcesz udostępniać.
Strona się otwiera, ale formularz, koszyk lub panel nie działa – jak zawęzić przyczynę
Awaria pojedynczej funkcji wymaga innej diagnostyki niż awaria całej witryny, bo serwer odpowiada poprawnie i logi strony głównej nie pokażą niczego niepokojącego. Zacznij od ustalenia, czy błąd występuje przed wysłaniem danych, czy po – to rozdziela problem przeglądarki od problemu serwera.
Praktyczna ścieżka wygląda tak:
Otwórz konsolę przeglądarki (F12) i zakładkę Network. Jeśli kliknięcie przycisku nie generuje żadnego żądania, błąd jest w JavaScripcie po stronie przeglądarki. Jeśli żądanie wychodzi i wraca z kodem 500 lub 403, problem jest na serwerze.
Sprawdź, czy funkcja działa w trybie prywatnym i bez rozszerzeń. Blokery reklam i skryptów potrafią zablokować captcha, widget płatności albo mapę, co wygląda identycznie jak awaria strony.
Zweryfikuj integracje zewnętrzne. Formularz, bramka płatnicza, system rezerwacji i narzędzie do newslettera komunikują się z cudzymi serwerami. Jeśli to one nie odpowiadają, Twoja strona jest sprawna, a naprawa nie leży po Twojej stronie.
Osobno przetestuj wysyłkę wiadomości. Formularz może zapisywać zgłoszenie i jednocześnie nie dostarczać e-maila, najczęściej przez konfigurację SMTP albo filtry antyspamowe. Klient zgłosi to jako „formularz nie działa”, choć dane są na serwerze.
W sklepie internetowym test kończ dopiero na pełnej ścieżce: dodanie produktu, przejście do kasy, płatność, status zamówienia i wiadomość do klienta. Sprawna strona główna przy niedziałającym koszyku to z perspektywy sprzedaży ta sama awaria co niedostępny serwer, tylko trudniejsza do zauważenia. Jeśli problem dotyczy wyłącznie formularza, pomocny będzie wpis o tym, jak poprawnie skonfigurować formularz kontaktowy.
Co zrobić w pierwszych 30 minutach awarii – kolejność kroków
W pierwszym pół godzinie chodzi o ustalenie przyczyny i zatrzymanie strat, a nie o naprawę. Kolejność ma znaczenie, bo każdy krok eliminuje część możliwości i chroni przed działaniem po omacku.
Potwierdź awarię z zewnątrz. Inne urządzenie, inna sieć, zewnętrzne narzędzie sprawdzające kod odpowiedzi HTTP. Zapisz dokładny komunikat i godzinę.
Sprawdź status usług. Strona statusu hostingu i skrzynka e-mail. Jeśli trwa znana awaria infrastruktury, dalsza diagnostyka jest stratą czasu.
Zweryfikuj domenę i certyfikat. WHOIS pokaże datę wygaśnięcia i status domeny w kilka sekund. To najtańszy do wykluczenia scenariusz.
Ustal, co się zmieniło. Aktualizacje, wdrożenia, zmiany konfiguracji, nowe wtyczki, zmiana wersji PHP – z ostatnich 48 godzin.
Zajrzyj do logów błędów. Szukaj wpisów z godziny, w której pojawił się problem, a nie najnowszych.
Zrób kopię obecnego stanu. Zanim cokolwiek zmienisz. Nawet zepsuta wersja jest punktem odniesienia i materiałem dowodowym, jeśli doszło do włamania.
Wykonaj jeden kontrolowany test. Jedna zmiana, jedno sprawdzenie. Wyłączenie trzech rzeczy naraz pozbawia Cię informacji o tym, która z nich była przyczyną.
Poinformuj zainteresowanych. Jeśli strona sprzedaje lub obsługuje klientów, krótka informacja w social mediach albo wiadomość do zespołu ogranicza liczbę zgłoszeń i nerwów.
Jeśli po tych krokach nie masz hipotezy, przekaż sprawę dalej. Granica jest dość jasna: diagnozuj sam dopóty, dopóki możesz cofnąć każdą wykonaną czynność. Przy uszkodzonej bazie danych, podejrzeniu włamania albo błędach dotyczących płatności dalsze samodzielne próby zwykle zwiększają koszt naprawy, zamiast go obniżać. W takich sytuacjach sensowne jest zlecenie tematu komuś, kto zajmuje się naprawą niedziałających stron internetowych na co dzień.
Ile trwa przywrócenie strony w zależności od przyczyny awarii
Czas powrotu strony zależy niemal wyłącznie od tego, co ją zatrzymało. Część przyczyn usuwa się w kilka minut, część wymaga czekania, na które nikt nie ma wpływu – i właśnie to rozróżnienie decyduje o tym, co powiesz klientom. Poniższe widełki to orientacyjne ramy oparte na typowym przebiegu każdego z tych procesów, nie gwarancja.
|
Przyczyna |
Orientacyjny czas powrotu |
Co wydłuża |
|---|---|---|
|
Konflikt wtyczki lub motywu |
Minuty po wyłączeniu komponentu |
Brak dostępu do FTP, nieznana przyczyna |
|
Przywrócenie kopii zapasowej |
Od kilkunastu minut do kilku godzin |
Rozmiar bazy, częstotliwość backupów |
|
Nieopłacony hosting |
Zwykle tego samego dnia po zaksięgowaniu |
Weekend, przelew tradycyjny, zawieszone konto |
|
Wygasły certyfikat SSL |
Minuty do kilkudziesięciu minut |
Ręczna instalacja, niepełny łańcuch certyfikatów |
|
Błędny rekord DNS |
Od kilku minut do kilkudziesięciu godzin |
Wysoki TTL, buforowanie u operatorów |
|
Domena odnowiona tuż po wygaśnięciu |
Od kilku godzin do doby |
Odświeżenie delegacji i propagacja DNS |
|
Domena w fazie wykupu |
Dni |
Procedura rejestratora, dodatkowa opłata |
|
Usunięcie infekcji |
Godziny do kilku dni |
Zakres zmian, usuwanie ostrzeżeń Google |
|
Awaria infrastruktury hostingu |
Poza Twoją kontrolą |
Skala awarii u dostawcy |
Największym źródłem frustracji jest propagacja DNS, bo wygląda jak awaria długo po tym, jak problem został naprawiony. Zmiany w rekordach rozchodzą się stopniowo i zależą od ustawionego TTL oraz polityk buforowania u operatorów, więc część użytkowników widzi już nową wersję, a część jeszcze starą. Jeśli po poprawieniu rekordu strona działa u Ciebie, ale nie u klienta, zwykle nie trzeba nic więcej robić – trzeba odczekać.
Czego nie robić, gdy strona przestała działać – błędy, które pogłębiają awarię
Większość nieodwracalnych szkód powstaje nie w momencie awarii, tylko w trakcie pospiesznej naprawy. Lista poniżej to działania, które w panice wydają się rozsądne, a realnie utrudniają powrót do normy:
Zmiana kilku rzeczy naraz. Wyłączenie wszystkich wtyczek, przełączenie motywu i zmiana wersji PHP w jednym podejściu może przywrócić stronę, ale nie dowiesz się, co ją zepsuło – więc awaria wróci.
Przywracanie kopii bez diagnozy. Backup cofa objaw, nie przyczynę. Przy infekcji przywraca też lukę, przez którą doszło do włamania.
Ponowna instalacja WordPressa „na czysto”. Przy niedziałającej stronie to zwykle nadmiarowy ruch, który grozi utratą danych. Wcześniej warto sprawdzić, czy wystarczy cofnięcie ostatnich zmian w WordPressie.
Usuwanie plików, których nie rozpoznajesz. Dotyczy to zwłaszcza plików konfiguracyjnych i wpisów w
.htaccess. Jeśli podejrzewasz ten plik, zmień mu nazwę zamiast go kasować – test jest odwracalny.Zmiana serwerów nazw w trakcie awarii. Dokładasz do problemu kilkanaście godzin propagacji i tracisz możliwość szybkiego cofnięcia zmiany.
Zgłaszanie strony do ponownej indeksacji, zanim działa stabilnie. Robot sprawdzi ją w stanie, w jakim jest w tym momencie.
Usuwanie adresów w Search Console. Narzędzie usunięć ukrywa URL na kilka miesięcy i nie rozwiązuje żadnego problemu technicznego.
Publikowanie pełnych logów na forum lub w grupie. Zawierają ścieżki systemowe, adresy IP i czasem fragmenty konfiguracji.
Zasada, która porządkuje wszystkie powyższe punkty: wykonuj tylko te działania, które potrafisz cofnąć w ciągu minuty. Jeśli nie potrafisz – zrób najpierw kopię albo przekaż sprawę specjaliście.
Komu zgłosić awarię i ile kosztuje naprawa niedziałającej strony
Adresat zgłoszenia zależy od warstwy, w której leży problem, i pomylenie go kosztuje zwykle kilka godzin odbijania się między stronami. Hosting odpowiada za serwer, dostępność usługi i konfigurację środowiska. Rejestrator domeny – za sam adres i strefę DNS. Osoba lub firma opiekująca się stroną – za CMS, wtyczki, motyw, bazę danych i kod. Dostawca zewnętrznej usługi (płatności, rezerwacje, CRM) – za swoją integrację.
W praktyce hosting rzadko naprawi Ci błąd 500 wynikający z konfliktu wtyczek, a programista nie przywróci zawieszonej usługi za brak płatności. Jeśli nie wiesz, do kogo się zwrócić, zacznij od hostingu z pytaniem o kod odpowiedzi i wpisy w logach – to informacja, którą dostaniesz szybko i która wskaże właściwego adresata.
Jakie informacje przygotować, żeby naprawa trwała krócej
Dobrze przygotowane zgłoszenie skraca diagnozę, bo oszczędza osobie po drugiej stronie całego etapu odtwarzania sytuacji. Przygotuj:
dokładny adres URL, pod którym występuje błąd, i informację, czy dotyczy całej witryny, czy wybranych podstron;
pełną treść komunikatu błędu i zrzut ekranu;
godzinę pierwszego wystąpienia problemu oraz informację, czy jest stały, czy pojawia się okresowo;
wynik testu z innego urządzenia i innej sieci;
listę zmian wprowadzonych w ostatnich dniach, włącznie z aktualizacjami i zmianami konfiguracji;
informację o posiadanych kopiach zapasowych i dacie najnowszej;
dane dostępowe do panelu hostingu, FTP i CMS, jeśli zlecasz naprawę na zewnątrz.
Różnica między zgłoszeniem „strona nie działa” a opisem zawierającym kod błędu, godzinę i ostatnią zmianę to często różnica między kilkoma godzinami a kilkunastoma minutami pracy.
Od czego zależy cena naprawy i kiedy opłaca się stała opieka
Koszt naprawy zależy przede wszystkim od tego, czy przyczyna jest znana i czy strona ma kopię zapasową. Przywrócenie działającego backupu to zupełnie inna pozycja kosztowa niż odtwarzanie serwisu bez kopii albo czyszczenie zainfekowanych plików. Na wycenę wpływają zwykle cztery rzeczy:
Czas diagnozy. Płacisz głównie za ustalenie przyczyny, nie za samą poprawkę. Dlatego informacje z poprzedniego punktu realnie obniżają rachunek.
Dostępność kopii zapasowej. Jej brak zamienia 30-minutowe przywrócenie w kilkugodzinne odtwarzanie.
Rodzaj problemu. Konflikt wtyczki jest tańszy niż infekcja, a infekcja tańsza niż utrata danych z uszkodzonej bazy.
Tryb realizacji. Naprawa poza godzinami pracy albo w trybie pilnym bywa rozliczana wyżej.
Z perspektywy rachunku ekonomicznego jednorazowa naprawa prawie zawsze kosztuje więcej niż miesiąc stałej opieki nad stroną – nie dlatego, że praca jest droższa, tylko dlatego, że przy stałej opiece istnieją aktualne kopie, monitoring i znajomość serwisu, a przy naprawie awaryjnej nie ma żadnej z tych rzeczy. Stała opieka ma sens głównie tam, gdzie strona generuje przychód lub kontakt z klientem; przy prostej wizytówce rozsądnym minimum są automatyczne kopie zapasowe i monitoring dostępności.
Jak długa niedostępność wpływa na pozycje w Google i co sprawdzić po usunięciu awarii
Krótka awaria zwykle nie szkodzi pozycjom – problemem jest dopiero niedostępność utrzymująca się przez dni. Google traktuje błędy serwera jako sygnał tymczasowy i przy powtarzających się odpowiedziach 5xx ogranicza tempo indeksowania, a przy dłuższym stanie zaczyna usuwać adresy z indeksu. Dlatego kod odpowiedzi w czasie awarii ma większe znaczenie niż jej długość: 503 komunikuje „wróć później”, a 404 albo 200 z pustą treścią mówią robotowi, że strona przestała istnieć lub straciła zawartość.
Po przywróceniu serwisu sprawdź po kolei:
Kod odpowiedzi kluczowych adresów. Strona główna, najważniejsze podstrony usługowe, mapa witryny. Wszystkie powinny zwracać 200.
Stan indeksowania w Search Console. Raport stron pokaże, czy w czasie awarii pojawiły się masowe błędy serwera lub wykluczenia.
Plik robots.txt. Po przywróceniu kopii lub pracach technicznych potrafi wrócić wersja blokująca indeksowanie. To jeden z najczęstszych cichych skutków ubocznych naprawy.
Ustawienie widoczności w CMS. W WordPressie opcja zniechęcania wyszukiwarek bywa włączana na czas prac i zapominana.
Certyfikat i przekierowania HTTP → HTTPS. Po zmianach konfiguracji łatwo o pętlę przekierowań albo mieszane wersje adresów.
Ostrzeżenia bezpieczeństwa. Jeśli doszło do infekcji, po wyczyszczeniu strony trzeba zgłosić ją do ponownej weryfikacji, inaczej ostrzeżenie zostanie w wynikach.
Powrót pozycji po usuniętej awarii zwykle następuje samoistnie, w tempie ponownego przeskanowania serwisu. Jeśli po dwóch-trzech tygodniach widoczność nie wraca, przyczyna najczęściej nie leży już w samej awarii, tylko w czymś, co zostało po naprawie – blokadzie indeksowania, zmienionych adresach bez przekierowań albo brakujących treściach z niepełnej kopii. Co sprawdzić w takiej sytuacji, rozkładam w tekście o tym, dlaczego strona nie jest widoczna w Google, a samo śledzenie efektów ułatwia regularne sprawdzanie pozycji strony.
Jak zmniejszyć ryzyko kolejnej awarii strony
Awarii nie da się wyeliminować, ale można sprawić, że przestaną być niespodzianką i przestaną trwać długo. Największy zwrot dają trzy rzeczy: automatyczne odnawianie usług, działające kopie zapasowe i monitoring, który powiadomi Cię wcześniej niż klient.
Włącz automatyczne odnawianie domeny i hostingu oraz sprawdź, czy adres e-mail w panelu rejestratora jest aktualny. Powiadomienia o wygaśnięciu trafiające na nieistniejącą skrzynkę to klasyczny początek tej awarii.
Dopasuj częstotliwość kopii do charakteru serwisu. Wizytówka – raz w tygodniu, blog – kilka razy w tygodniu, sklep – codziennie lub częściej. Sprawdź też, czy kopia da się odtworzyć; backup, którego nigdy nie testowano, jest założeniem, nie zabezpieczeniem. Szczegóły opisuję w poradniku o kopiach zapasowych stron www.
Testuj aktualizacje przed wdrożeniem, zwłaszcza przy wtyczkach obsługujących płatności, formularze i cache. Środowisko testowe oferuje dziś większość hostingów.
Monitoruj dostępność i ścieżki funkcjonalne, a nie tylko stronę główną. Przy sklepie monitoring powinien obejmować co najmniej dodanie produktu do koszyka i przejście do płatności.
Pilnuj wydajności, bo przeciążenie to awaria rozłożona w czasie. Rosnący czas odpowiedzi serwera i regularne spowolnienia w godzinach szczytu zwykle poprzedzają pierwszy błąd 503 – praktyczne działania zebrałem w tekście o tym, jak przyspieszyć stronę na WordPressie.
Zadbaj o podstawy bezpieczeństwa: aktualne komponenty, silne hasła, ograniczony dostęp do panelu i regularne skanowanie. Zakres opisałem we wpisie o bezpieczeństwie strony www.
Zrób sobie jednostronicową kartę awaryjną i trzymaj ją poza stroną – w notatkach lub w menedżerze haseł. Powinna zawierać: nazwę hostingu i link do panelu, rejestratora domeny, datę wygaśnięcia domeny, lokalizację kopii zapasowych, kontakt do osoby technicznej i adres strony statusu dostawcy. Brzmi trywialnie, dopóki nie okaże się, że dane dostępowe do hostingu były w skrzynce pocztowej na tej samej, niedziałającej domenie.