Zanim zaczniesz: kopia i kopia testowa
Audyt strony, która działa od lat bez opieki, zaczyna się od zabezpieczenia tego, co jest. Pierwszym krokiem jest pełna kopia plików i bazy danych, pobrana na dysk poza serwerem — zanim ktokolwiek dotknie wtyczek czy aktualizacji.
Drugim krokiem jest kopia testowa pod osobnym adresem, zablokowana przed indeksowaniem. Wszystkie próby — usuwanie wtyczek, aktualizacje, zmiany w motywie — wykonuje się najpierw tam. Dopiero sprawdzone zmiany trafiają na stronę, którą widzą klienci.
Brzmi jak ostrożność na wyrost, ale to najczęstsza różnica między audytem, po którym strona działa lepiej, a takim, po którym przez dwa dni nie działa wcale.
1. Wersje: silnik, motyw, wtyczki
Strona na WordPressie to nie jeden program, tylko silnik, motyw i zwykle kilkanaście wtyczek — każde z osobnym autorem i osobnym harmonogramem wydań. Wszystkie aktualizują się niezależnie i wszystkie mogą przestać ze sobą współpracować.
Sprawdzenie zaczyna się od listy: co jest zainstalowane, w jakiej wersji i kiedy autor ostatni raz wydał aktualizację. Wtyczka nierozwijana od dwóch lat jest ryzykiem niezależnie od tego, czy obecnie działa.
Osobno warto sprawdzić wtyczki płatne. Bez ważnej licencji przestają dostawać aktualizacje, a to najczęstsza droga, którą do strony dostają się automaty wykorzystujące znane luki.
Aktualizacje automatyczne: co włączyć, a czego pilnować ręcznie
Przy audycie często okazuje się, że strona ma włączone automatyczne aktualizacje wszystkiego albo nie ma ich wcale. Obie skrajności mają swoją cenę: pierwsza potrafi zepsuć stronę w nocy bez niczyjej wiedzy, druga zostawia znane luki otwarte przez miesiące.
Rozsądny układ zależy od tego, co dana aktualizacja może zepsuć. Poprawki bezpieczeństwa silnika i drobne wydania prostych wtyczek zwykle można zostawić automatom. Wtyczki, od których zależą formularze, płatności albo wygląd całej strony, lepiej aktualizować ręcznie, po sprawdzeniu na kopii testowej.
| Element | Aktualizacja | Dlaczego |
|---|---|---|
| Poprawki bezpieczeństwa silnika | automatycznie | małe zmiany, duża waga dla bezpieczeństwa |
| Duże wydania silnika | ręcznie, po teście | zmieniają działanie edytora i zgodność wtyczek |
| Kreator stron i motyw | ręcznie, po teście | od nich zależy wygląd wszystkich podstron |
| Wtyczki formularzy i sklepu | ręcznie, po teście | błąd widać dopiero po utracie zapytań lub zamówień |
| Proste wtyczki pomocnicze | automatycznie, z monitoringiem | niskie ryzyko, szybka poprawka luk |
Automatyczne aktualizacje mają sens tylko razem z codzienną kopią i monitoringiem dostępności. Bez nich nocna aktualizacja, która wyłączy stronę, zostanie zauważona dopiero przez klienta.
Wersja PHP i ustawienia serwera
Obok wersji WordPressa i wtyczek warto sprawdzić wersję PHP, na której działa strona. Stare strony często stoją na wersji, która nie dostaje już poprawek bezpieczeństwa, bo przełączenie na nowszą „coś psuło” i nikt do tego nie wrócił.
Przejście na nowszą wersję zwykle przyspiesza stronę, ale wymaga sprawdzenia, czy motyw i wtyczki są z nią zgodne. Robi się to na kopii testowej: przełączenie, przejście przez najważniejsze podstrony i formularze, przegląd dziennika błędów.
Przy okazji warto zajrzeć w limity serwera: pamięć, czas wykonania skryptów i wielkość wgrywanych plików. Zbyt niskie wartości objawiają się błędami przy aktualizacjach i kopiach zapasowych. Więcej o parametrach serwera w artykule o wyborze hostingu pod WordPress.
2. Ślady po włamaniu, których nie widać
Większość infekcji nie objawia się zepsutą stroną. Strona działa normalnie, a w kodzie ktoś doklejł setki podstron z odnośnikami do obcych serwisów, widocznych wyłącznie dla wyszukiwarki.
Sygnałów jest kilka: nagły wzrost liczby zaindeksowanych podstron, wpisy o treści niezwiązanej z firmą, konta administratorów, których nikt nie zakładał, oraz pliki o dziwnych nazwach w katalogach, w których nie powinno ich być.
Najprostsze sprawdzenie: wyszukanie w wyszukiwarce wszystkich podstron z Waszej domeny. Jeśli jest ich znacznie więcej, niż powinno, warto przyjrzeć się bliżej — to zwykle pierwszy widoczny objaw.
Pliki na serwerze, które nie powinny być publiczne
Poza śladami włamania audyt powinien objąć rzeczy zostawione na serwerze przez samych wykonawców. Najczęściej są to archiwa z kopią strony wgrane do katalogu publicznego, stare instalacje w podkatalogach o nazwach w rodzaju „test” albo „stara” i pliki dziennika z włączonego kiedyś trybu debugowania.
Każda z tych rzeczy jest problemem z innego powodu. Archiwum kopii zawiera plik konfiguracyjny z hasłem do bazy danych i często da się je po prostu pobrać, znając adres. Porzucona instalacja nie jest aktualizowana, więc staje się najłatwiejszym wejściem na całe konto hostingowe.
- Archiwa z kopią strony i bazy leżące w katalogu publicznym
- Stare wersje strony w podkatalogach, nadal dostępne z przeglądarki
- Kopie testowe bez hasła i bez blokady indeksowania
- Pliki dziennika błędów dostępne pod publicznym adresem
- Edycja plików motywu i wtyczek włączona w panelu administratora
- Skrypty diagnostyczne i instalacyjne zostawione po wdrożeniu
Porządek polega na przeniesieniu potrzebnych kopii poza katalog publiczny, a najlepiej poza serwer, i usunięciu reszty. Jak przechowywać kopie tak, żeby same nie stały się zagrożeniem, opisujemy w artykule kopie zapasowe w firmie.
3. Kopie zapasowe: czy istnieją i czy da się je odtworzyć
Najczęstsza odpowiedź na pytanie o kopie brzmi: „hosting je robi". Warto sprawdzić, czy to prawda, jak często, ile wstecz sięgają i — najważniejsze — gdzie leżą.
Kopia przechowywana na tej samej maszynie co strona chroni przed pomyłką użytkownika, ale nie przed awarią sprzętu ani przed problemem obejmującym całe konto. Sensowna kopia leży gdzie indziej niż oryginał.
Druga rzecz to test odtworzenia. Kopia, której nikt nigdy nie próbował przywrócić, jest obietnicą. Warto raz przywrócić ją na adres testowy i sprawdzić, ile to trwa oraz czy strona wstaje w całości — razem z bazą i zdjęciami.
4. Wydajność i to, co ją zjada
Strona z czasem zwalnia, nawet jeśli nikt jej nie zmienia. Baza puchnie od zapisanych wersji roboczych wpisów, katalog ze zdjęciami rośnie, a kolejne wtyczki dokładają swoje pliki do każdego wczytania.
Najczęstsze znaleziska: zdjęcia wgrane w oryginalnych rozmiarach z aparatu, wtyczki ładujące się na wszystkich podstronach mimo używania na jednej i skrypty zewnętrzne dodane kiedyś do jednorazowej kampanii.
Warto zmierzyć czas odpowiedzi serwera osobno od czasu wczytania zasobów. Te dwie liczby wskazują winnego: pierwsza to hosting i baza, druga to zdjęcia i skrypty. Szerzej we wpisie o wskaźnikach szybkości.
Zadania w tle i dziennik błędów
WordPress wykonuje część pracy w tle: publikuje zaplanowane wpisy, wysyła powiadomienia, uruchamia kopie i zadania wtyczek. Na stronach z małym ruchem te zadania potrafią się spóźniać albo nie wykonywać wcale, bo uruchamiają się przy wizytach odwiedzających.
Objawy bywają mylące: kopia, która „czasem się nie robi”, wpis, który nie opublikował się o zaplanowanej godzinie, albo tysiące zaległych zadań po odinstalowanej wtyczce, spowalniające każde wczytanie strony. Audyt powinien sprawdzić listę zaplanowanych zadań i to, czy uruchamia je serwer według stałego harmonogramu.
Drugim źródłem wiedzy jest dziennik błędów serwera. Powtarzające się ostrzeżenia z jednej wtyczki często zapowiadają problem po najbliższej zmianie wersji PHP. Kilka minut z dziennikiem pozwala wskazać wtyczki do wymiany, zanim przestaną działać.
Skrypty zewnętrzne i dane odwiedzających
Na stronach działających od lat zbiera się warstwa skryptów zewnętrznych: narzędzia analityczne, piksele reklamowe, czaty, mapy, widżety opinii. Część z nich od dawna nie jest używana, a nadal wczytuje się na każdej podstronie.
Każdy taki skrypt spowalnia stronę i przekazuje dane o odwiedzających do zewnętrznej usługi. Audyt powinien zestawić je w jednej liście: co to jest, kto z tego korzysta i czy jest objęte informacją o plikach cookies na stronie.
Po takim przeglądzie zwykle da się usunąć kilka pozycji bez żadnych skutków poza szybszą stroną i krótszą listą rzeczy, o których trzeba pamiętać.
5. Przegląd wtyczek: mniej znaczy lepiej
Typowa przejmowana strona ma dwadzieścia kilka wtyczek, z których używanych jest kilkanaście, a potrzebnych mniej niż dziesięć. Każda niepotrzebna to dodatkowy kod, dodatkowe ryzyko i dodatkowa rzecz do aktualizowania.
Szczególnej uwagi wymagają wtyczki dublujące funkcje: dwie do pamięci podręcznej, trzy do formularzy, dwie do optymalizacji obrazów. Zwykle przeszkadzają sobie nawzajem i utrudniają diagnozę problemów.
Usuwanie warto robić ostrożnie i pojedynczo, na kopii testowej. Część wtyczek zostawia po sobie dane w bazie albo krótkie fragmenty kodu wpisane w treść — wyłączenie ich bez sprawdzenia potrafi zepsuć układ strony.
- Wtyczki wyłączone, ale wciąż zainstalowane
- Kilka wtyczek robiących to samo
- Wtyczki płatne bez ważnej licencji
- Wtyczki nierozwijane przez autora od ponad dwóch lat
- Motyw modyfikowany bezpośrednio, bez motywu potomnego
6. Motyw i sposób jego modyfikacji
Najbardziej kosztowne znalezisko przy przejmowaniu strony to motyw modyfikowany bezpośrednio, bez motywu potomnego. Każda aktualizacja kasuje wtedy wszystkie zmiany — a więc albo nie aktualizuje się motywu, albo traci się przeróbki.
Drugą rzeczą jest motyw kupiony jednorazowo i nierozwijany. Działa, dopóki nie zmieni się wersja silnika albo języka po stronie serwera. Wtedy okazuje się, że autor nie wydał aktualizacji od trzech lat.
Trzecią — kreatory stron. Nie są złe same w sobie, ale wiążą treść z konkretnym narzędziem. Zmiana motywu albo kreatora oznacza wtedy przepisanie wszystkich podstron od nowa i warto o tym wiedzieć zawczasu.
Strona ze sklepem WooCommerce: dodatkowe punkty
Jeśli na WordPressie działa sklep, audyt musi objąć obszary, których strona firmowa nie ma. Najważniejszy z nich to ścieżka zakupowa sprawdzona realnym zamówieniem: koszyk, dostawa, płatność, potwierdzenie mailowe i dokument sprzedaży.
- Moduły płatności i dostaw — wersje i ważność kluczy
- Zadania cykliczne: anulowanie nieopłaconych zamówień, synchronizacje
- Rozmiar bazy: zamówienia, sesje, dzienniki zdarzeń
- Pamięć podręczna wyłączona dla koszyka i konta klienta
- Integracje z systemem magazynowym i kurierami
- Wiadomości wysyłane do klientów i to, czy docierają
O tym, jak integracje psują się po cichu, piszemy w artykule o integracji sklepu z systemem magazynowym.
7. Dostępy i konta
Lista kont administratorów bywa najbardziej pouczającą częścią audytu. Zwykle znajdują się tam byli pracownicy, poprzedni wykonawcy i konta o nazwach, których nikt nie rozpoznaje.
Osobno warto sprawdzić, na kogo zarejestrowana jest domena i kto ma dostęp do panelu hostingu. To dwie rzeczy, których brak boli najbardziej w najgorszym momencie — a odzyskiwanie ich bywa długie.
Porządek robi się raz: usunięcie zbędnych kont, zmiana haseł, włączenie logowania dwuskładnikowego dla administratorów i spisanie, kto do czego ma dostęp. Godzina pracy, która oszczędza tygodnie kłopotów.
Dokumentacja: co zapisać po audycie
Najczęstszym problemem stron bez opieki nie jest technika, tylko brak wiedzy, jak coś jest zrobione. Poprzedni wykonawca odchodzi, a razem z nim informacja, dlaczego dana wtyczka jest potrzebna i gdzie wprowadzono zmiany w kodzie.
Audyt to dobry moment, żeby tę wiedzę spisać. Wystarczy prosty dokument: lista wtyczek z opisem, do czego służą, miejsca zmian w motywie, dane dostępowe przechowywane w menedżerze haseł, harmonogram kopii i kontakt do dostawcy hostingu.
Taki dokument skraca każdą przyszłą pracę przy stronie — niezależnie od tego, kto będzie ją wykonywał.
8. Warstwa widoczności w wyszukiwarce
Przy przejmowanych stronach najczęstszym znaleziskiem jest blokada indeksowania zostawiona po pracach albo po przenosinach. Strona działa, wygląda dobrze i nie pojawia się w wynikach — czasem od miesięcy.
Drugą grupą są duplikaty: ta sama treść pod adresem z ukośnikiem i bez, z parametrami kampanii, w wersji do druku. Wyszukiwarka zużywa wtedy zasoby na warianty zamiast na podstrony, na których zależy firmie.
Trzecią — brak przekierowań po dawnych zmianach. Adresy z ulotek sprzed lat, odnośniki z portali, stare podstrony usług: wszystko to kończy się błędem, a razem z tym przepada część zbudowanego dorobku.
9. Rzeczy, które przestały działać po cichu
Formularze przestają wysyłać wiadomości zaskakująco często: po zmianie na hostingu, po aktualizacji, po zmianie adresu poczty. Nikt tego nie zauważa, bo brak zapytań wygląda po prostu jak słabszy miesiąc.
Podobnie z pocztą wychodzącą ze strony. Bez poprawnych wpisów uwierzytelniających wiadomości trafiają do folderu ze spamem — także te do klientów, potwierdzające zamówienie albo zapytanie.
Trzecia rzecz to certyfikat i jego automatyczne odnawianie. Wygasły certyfikat oznacza ostrzeżenie w przeglądarce, które odsiewa zdecydowaną większość odwiedzających — i zdarza się to zwykle w weekend.
Dostępność: czy każdy skorzysta ze strony
Część odwiedzających korzysta ze strony inaczej niż za pomocą myszki i dobrego wzroku: z klawiatury, z powiększeniem tekstu albo z czytnikiem ekranu. Strona, która dla nich nie działa, traci klientów, o których istnieniu firma nawet nie wie.
Podstawowy przegląd obejmuje kontrast tekstu, opisy zdjęć, możliwość obsługi menu i formularzy z klawiatury oraz czytelność na telefonie przy powiększonym tekście. Wiele z tych rzeczy da się poprawić w motywie bez zmiany wyglądu strony.
To także element jakości, który zauważa wyszukiwarka: poprawne nagłówki, opisy zdjęć i czytelna struktura pomagają zarówno ludziom, jak i robotom indeksującym.
Monitoring: kto pierwszy dowie się o awarii
Na stronach bez opieki o awarii najczęściej informuje klient — telefonem albo, gorzej, nie informuje wcale, tylko dzwoni do konkurencji. Proste monitorowanie dostępności odwraca tę kolejność.
Minimum to sprawdzanie co kilka minut, czy strona odpowiada, i powiadomienie wysyłane do osoby, która może zareagować. Warto dodać kontrolę ważności certyfikatu i domeny, żeby nie wygasły niezauważone.
Przy stronach, które zbierają zapytania, dobrze działa też cotygodniowy test formularza. Brak zapytań przez kilka dni przestaje być wtedy zagadką — albo formularz działa, albo wiadomo, że trzeba go naprawić.
Jak uporządkować wyniki w plan działania
Lista znalezisk sama w sobie niewiele daje. Wartość powstaje, gdy uporządkuje się ją według dwóch osi: ryzyka i nakładu. Rzeczy ryzykowne i tanie robi się pierwsze, niezależnie od tego, jak mało efektownie wyglądają.
| Priorytet | Co | Typowy nakład |
|---|---|---|
| Natychmiast | Kopie poza serwerem, dostępy, hasła administratorów | kilka godzin |
| Pilne | Aktualizacje, usunięcie ryzykownych wtyczek, certyfikat | 1–2 dni |
| Ważne | Blokady indeksowania, przekierowania, formularze | 1–2 dni |
| Do zaplanowania | Wydajność, zdjęcia, przegląd motywu | tygodnie |
| Do rozważenia | Przebudowa, jeśli motyw blokuje rozwój | projekt |
Przykład: co wychodzi na stronie przejętej po wykonawcy
Poniżej zestawienie znalezisk typowych dla strony firmowej, która przez kilka lat działała bez opieki. Nie jest to opis jednej konkretnej strony, tylko obraz powtarzający się przy przejęciach.
| Obszar | Znalezisko | Pilność |
|---|---|---|
| Kopie | kopia tylko na serwerze, nigdy nie testowana | natychmiast |
| Dostępy | trzy konta administratorów byłych wykonawców | natychmiast |
| Wtyczki | dwadzieścia cztery, w tym pięć nieaktualizowanych od lat | pilne |
| Motyw | zmiany w motywie bez motywu potomnego | ważne |
| Formularz | wiadomości trafiające do spamu | pilne |
| Widoczność | stare adresy usług bez przekierowań | ważne |
| Szybkość | zdjęcia wgrane w oryginalnych rozmiarach | do zaplanowania |
Strony firm z regionu: typowe sytuacje
Przy stronach firm z Lublina, Świdnika czy Zamościa powtarza się jeden scenariusz: stronę zrobił kilka lat temu lokalny wykonawca albo znajomy, który przestał się nią zajmować. Strona działa, ale nikt nie wie, kto ma hasła, gdzie są kopie i czy wtyczki są aktualne.
W takich przypadkach audyt ma dwa etapy. Najpierw odzyskanie kontroli: dostępy do hostingu, domeny i panelu strony. Dopiero potem właściwy przegląd techniczny i lista działań.
Audyty i stałą opiekę prowadzimy dla firm z całego województwa — zobacz audyt strony WordPress w Lublinie i opiekę nad WordPress w Lublinie.
Co dalej: jednorazowo czy na stałe
Audyt porządkuje stan na dziś. Za rok strona wróci do podobnego stanu, jeśli nikt nie będzie jej doglądał — bo aktualizacje, kopie i certyfikaty wymagają regularności, a nie jednorazowego zrywu.
Dla firm, w których nie ma kto tego pilnować, sensowna jest stała opieka: aktualizacje na kopii testowej, kopie poza serwerem, monitoring dostępności i pula godzin na drobne zmiany — zobacz opiekę nad WordPress.
Alternatywą jest wyznaczenie osoby w firmie i prosty harmonogram: aktualizacje raz w miesiącu, sprawdzenie formularza raz w miesiącu, test odtworzenia kopii raz na kwartał. To wykonalne — pod warunkiem, że ktoś się tego podejmie.
Kiedy zrobić audyt: zmiana hostingu, wykonawcy albo kampania
Audyt najwięcej daje nie wtedy, gdy strona już nie działa, tylko przed ważną zmianą. Przeniesienie strony na inny serwer, przejęcie jej przez nowego wykonawcę albo start płatnej kampanii to momenty, w których ukryte problemy kosztują najwięcej.
| Moment | Na co zwrócić szczególną uwagę |
|---|---|
| Przed zmianą hostingu | wersja PHP, rozmiar bazy, kopie, poczta wysyłana ze strony |
| Przy zmianie wykonawcy | dostępy, licencje wtyczek, zmiany w motywie, dokumentacja |
| Przed kampanią reklamową | formularze, szybkość na telefonie, pomiar zapytań |
| Przed przebudową strony | adresy przynoszące ruch, treści do zachowania, przekierowania |
| Po infekcji lub awarii | droga wejścia, hasła, obce podstrony w wynikach wyszukiwania |
Firmy z Chełma, Kraśnika czy Łęcznej często zgłaszają się właśnie przy zmianie hostingu, kiedy dotychczasowy pakiet przestaje wystarczać albo zmieniają się jego warunki. Audyt i przenosiny dobrze jest wtedy zaplanować razem, żeby nie przenosić starych problemów na nowy serwer.
O tym, na co uważać przy wyborze serwera, piszemy w artykule pułapka tanich hostingów. Stałą opiekę po audycie prowadzimy także poza Lublinem — zobacz opiekę nad WordPress w Chełmie.
Przegląd w godzinę: co możesz sprawdzić sam
Część audytu da się wykonać bez wiedzy technicznej. Poniższa lista nie zastąpi pełnego przeglądu, ale pokaże, czy strona wymaga pilnej uwagi.
- Czy w panelu czekają aktualizacje i od jak dawna?
- Ilu jest administratorów i czy wszystkich znasz?
- Czy wiesz, gdzie jest ostatnia kopia i z którego jest dnia?
- Czy formularz kontaktowy wysłany teraz dotarł do skrzynki?
- Czy certyfikat jest ważny i kiedy wygasa domena?
- Ile podstron z Twojej domeny pokazuje wyszukiwarka?
Jeśli na dwa albo więcej pytań odpowiedź brzmi „nie wiem” albo „źle”, pełny audyt jest wart swojej ceny.
Ile kosztuje strona bez opieki
Strona bez opieki nie kosztuje nic — dopóki coś się nie stanie. Wtedy koszt pojawia się naraz: odtwarzanie strony po infekcji, czyszczenie wyników wyszukiwania z obcych podstron, odzyskiwanie dostępów i dni bez zapytań.
Porównanie jest proste. Po jednej stronie leży regularna praca: aktualizacje, kopie, monitoring, kilka godzin w miesiącu. Po drugiej — nieprzewidywalny koszt awarii, który zwykle przychodzi w najgorszym momencie i wymaga pilnej, droższej pracy.
Nie każda strona potrzebuje rozbudowanej opieki. Ale każda potrzebuje kogoś, kto wie, co się na niej dzieje — w firmie albo poza nią.
Kiedy audyt kończy się rekomendacją nowej strony
Czasem wniosek z audytu brzmi: nie naprawiać, tylko zbudować od nowa. Dzieje się tak, gdy motyw nie jest rozwijany i nie działa z aktualnym oprogramowaniem, gdy kod był wielokrotnie przerabiany bez dokumentacji albo gdy strona nie odpowiada już temu, czym firma się zajmuje.
W takim przypadku audyt nie jest stracony. Pokazuje, co z obecnej strony warto zachować: treści, które przynoszą ruch, adresy, do których prowadzą odnośniki, i funkcje, z których korzystają klienci.
Przebudowę trzeba wtedy połączyć z przemyślaną migracją — opisujemy ją w artykule o migracji WordPressa bez utraty pozycji.
Najczęstsze pytania
Zwykle tak — po śladach w plikach, w bazie i w liczbie zaindeksowanych podstron. Przy starannie ukrytych infekcjach potrzebne bywa głębsze skanowanie, ale większość przypadków widać od razu.
Przy typowej stronie firmowej jeden–dwa dni. Przy sklepie z integracjami i dużą liczbą wtyczek dłużej, bo trzeba sprawdzić też ścieżkę zakupową i wymianę danych.
Częściowo. Widoczność, szybkość, certyfikat i przekierowania da się ocenić z zewnątrz. Wtyczki, kopie i konta wymagają już dostępu.
Zacząć od dostawcy hostingu i rejestratora domeny — oni potwierdzają uprawnienia na podstawie danych firmy. To częstsza sytuacja, niż się wydaje, i zwykle da się ją rozwiązać.
Tylko jeśli motyw albo architektura uniemożliwiają rozwój. W większości przypadków porządny przegląd i kilka dni pracy dają więcej niż nowa strona zbudowana bez zrozumienia, co poszło nie tak.
Tak. Przegląd wykonuje się na kopii testowej, a na stronę trafiają tylko sprawdzone zmiany, zwykle w porze najmniejszego ruchu.
Usunąć infekcję, znaleźć drogę, którą się dostała, zmienić wszystkie hasła i sprawdzić wyniki wyszukiwania pod kątem obcych podstron. Samo przywrócenie kopii nie wystarcza.
Nie zawsze. Jeśli w firmie jest osoba, która będzie regularnie aktualizować stronę i sprawdzać kopie, wystarczy jasny harmonogram. Jeśli nie ma — opieka zapobiega powrotowi problemów.
Dla poprawek bezpieczeństwa i prostych wtyczek zwykle tak, pod warunkiem codziennej kopii i monitoringu. Motyw, kreator stron oraz wtyczki formularzy i sklepu lepiej aktualizować ręcznie, po teście na kopii.
Tak, jeśli leżą w katalogu publicznym. Archiwum kopii zawiera dane dostępowe do bazy, a porzucona instalacja nie dostaje aktualizacji. Kopie warto trzymać poza serwerem, a zbędne pliki usunąć.


