Najpierw zatrzymaj incydent, potem poprawiaj widoczność
Obce tytuły w Google, strony z nieznanymi produktami lub przekierowanie widoczne tylko części odwiedzających mogą oznaczać ingerencję w serwis. Nie zaczynaj od poprawiania opisów SEO. Najpierw potrzebna jest diagnoza bezpieczeństwa oraz zatrzymanie nieuprawnionych zmian. Jeżeli napastnik nadal ma dostęp, usunięte adresy mogą wrócić. Praca nad widocznością bez usunięcia przyczyny przypomina porządkowanie witryny sklepowej przy otwartych drzwiach do zaplecza.
Zachowaj materiał do analizy: czas zauważenia problemu, przykładowe adresy, objawy i kopię potrzebnych logów. Nie wykonuj przypadkowych zmian na jedynej kopii danych. Ustal, kto odpowiada za hosting, aplikację i kontakt z właścicielem. W przykładowym portalu usługowym jedna osoba może koordynować listę zadań, ale samo usuwanie złośliwego kodu powinno trafić do osoby umiejącej ocenić zasięg incydentu, także poza plikami publicznej strony.
Oddziel prawdziwe podstrony od treści dodanych przez napastnika
Zbuduj listę adresów z kilku miejsc: danych CMS, map witryny, logów, odnośników wewnętrznych i raportów wyszukiwarki. Nie wszystkie zainfekowane zasoby muszą znajdować się w zwykłym spisie artykułów. Zdarza się, że adres jest generowany przez zmieniony routing lub warunkową odpowiedź. Dlatego porównuj także treść faktycznie zwracaną przez serwer. Sam brak podejrzanego rekordu w panelu nie potwierdza usunięcia problemu.
Podziel listę na prawidłowe strony, prawidłowe strony zmodyfikowane oraz całkowicie obce adresy. To trzy różne zadania. Stronie oferty trzeba przywrócić właściwą treść. Fałszywa publikacja nie powinna otrzymać nowego artykułu tylko po to, by zachować status 200. W notatkach zapisz decyzję dla każdego wzorca adresów. Grupowanie jest pomocne, lecz próbki należy sprawdzić, aby nie usunąć legalnych materiałów mających podobną nazwę.
Dobierz odpowiedź serwera do rzeczywistego znaczenia URL
Adres utworzony wyłącznie przez atak, bez uzasadnionego odpowiednika, powinien przestać udawać istniejącą stronę. Odpowiedź 404 lub 410 może przekazać brak zasobu. Masowe przekierowanie wszystkich podejrzanych URL na stronę główną nie odtwarza ich znaczenia i utrudnia ocenę sprzątania. Przekierowanie stosuj tam, gdzie rzeczywiście istnieje właściwy następca, nie jako uniwersalny sposób zakrywania błędów.
Przywrócone strony powinny mieć własne, prawidłowe tytuły, treść i adresy kanoniczne. Sprawdź mapy witryny, linki w menu i automatycznie generowane listy. Fałszywy adres usunięty z CMS może nadal występować w statycznej mapie lub cache. Przeprowadź próbę bez zalogowania, także z różnymi nagłówkami klienta, jeżeli objawy wskazywały na warunkowe zachowanie. Nie otwieraj podejrzanych materiałów na urządzeniu zawierającym niezabezpieczone dane administracyjne.
Search Console pomaga w kontroli, ale nie naprawia aplikacji
Raport problemów bezpieczeństwa może wskazać rozpoznane zagrożenia i przykładowe adresy. To ważna wskazówka, nie pełny wykaz każdego zmienionego pliku. Raport działa na podstawie danych Google i nie zastępuje analizy serwera. Podobnie narzędzie do tymczasowego ukrycia wyniku nie usuwa treści z hostingu. Rozdziel działania ograniczające widoczność szkodliwego wyniku od trwałej naprawy technicznej.
Po oczyszczeniu serwisu i zamknięciu przyczyny problemu wykonaj procedurę weryfikacji właściwą dla zgłoszonego ostrzeżenia. Opisz konkretne poprawki, a nie samo „już działa”. Nie obiecuj właścicielowi stałego czasu odzyskania pozycji. Usunięcie ostrzeżenia, ponowne pobranie stron i odbudowa ruchu to odrębne zdarzenia. W harmonogramie zostaw miejsce na obserwację oraz ponowną analizę, gdy raport wskaże kolejne przykłady.
Przywrócenie kopii wymaga kontroli jej pochodzenia
Kopia zapasowa może pochodzić z okresu, w którym problem już istniał, lecz nie był zauważony. Odtworzenie plików bez sprawdzenia daty i zakresu nie daje pewności powrotu do bezpiecznego stanu. Poza kodem trzeba ocenić konta, zadania cykliczne, konfigurację, zależności i zapisane treści. Zmiana hasła administratora jest ważnym elementem, ale nie usuwa wszystkich możliwych sposobów utrzymania dostępu przez napastnika.
W planie odbioru uwzględnij zwykłe funkcje biznesowe: formularz, płatność, logowanie i pobieranie dokumentów. Strona pozbawiona spamu, ale niedziałająca dla klientów, nadal wymaga pracy. Testuj na odizolowanej kopii, a potem potwierdź rezultat produkcyjny. Zachowaj historię wykonanych zmian i osoby odpowiedzialne. To pomaga odróżnić powrót incydentu od późniejszego błędu redakcyjnego lub niezależnej zmiany konfiguracji hostingu.
Oceniaj powrót do normalności przez kilka sygnałów
Po wdrożeniu obserwuj liczbę nowych podejrzanych adresów, odpowiedzi serwera, alerty bezpieczeństwa oraz ruch do najważniejszych prawidłowych stron. Zapisz punkt odniesienia i daty zmian. Sam wzrost ogólnej liczby zaindeksowanych URL nie jest sukcesem, jeżeli obejmuje śmieciowe treści. W raporcie rozdziel odzyskane strony, usunięty spam oraz problemy nadal wymagające analizy. Nie łącz tych grup w jeden zielony wskaźnik.
Przygotuj prostą procedurę na przyszłość: aktualizacje, minimalny dostęp, sprawdzane kopie i kanał zgłaszania niepokojących objawów. Ustal również, kto odbiera komunikaty Search Console, gdy dotychczasowy wykonawca kończy współpracę. Odbudowa SEO po włamaniu to przywrócenie wiarygodnego serwisu, nie produkcja nowych linków w nadziei przykrycia problemu. Najpierw potrzebna jest kontrola nad tym, co domena naprawdę udostępnia odwiedzającym.