Podobnie może wyglądać poszukiwanie usługi w Google, gdy nad wynikami pojawi się odpowiedź AI Overviews. Twoja strona nadal ma znaczenie, ale klient może pierwszy raz zetknąć się z firmą poprzez opis przygotowany przez AI. Dlatego trzeba zadbać zarówno o to, czy system znajdzie informacje o Twojej ofercie, jak i o to, czy przedstawi je poprawnie.

Co to jest GEO i jaki ma cel?

GEO (Generative Engine Optimization) to przygotowanie treści i obecności firmy w internecie tak, aby systemy wyszukiwania generatywnego mogły odnajdywać, rozumieć i wykorzystywać informacje o niej w odpowiedziach dla użytkowników. Celem może być wskazanie strony jako źródła albo uwzględnienie marki w porównaniu usług.

Spotkasz też nazwy AEO (Answer Engine Optimization), AI SEO i LLMO (Large Language Model Optimization). W praktyce opisują to samo zjawisko: pracę nad widocznością w odpowiedziach AI, choć autorzy tych określeń różnie wyznaczają ich zakres. Dla właściciela firmy ważniejsze od nazwy jest ustalenie, na jakie pytania klientów odpowiada strona i czy odpowiedzi można sprawdzić.

Jak działa wyszukiwanie generatywne?

Wyszukiwanie generatywne łączy znalezione informacje z modelem językowym, który układa z nich odpowiedź dopasowaną do pytania. Zamiast samodzielnie przeglądać każdą stronę, użytkownik dostaje omówienie tematu, często z odnośnikami do źródeł.

AI Overviews to podsumowania w wyszukiwarce Google, a AI Mode pozwala szerzej rozwijać temat w rozmowie. Systemy te korzystają z zasobów indeksu Google, czyli zbioru rozpoznanych stron. Mogą rozbić pytanie na powiązane wyszukiwania, dlatego źródła odpowiedzi nie muszą odpowiadać kolejności zwykłych wyników.

ChatGPT z wyszukiwaniem i Perplexity również sięgają do internetu, korzystając z infrastruktury wyszukiwania i pobierania stron. Gemini może wskazywać publiczne witryny jako źródła lub materiały powiązane. Copilot Chat przy włączonym wyszukiwaniu korzysta z Bing. To różne produkty: odpowiedź na identyczne pytanie może w każdym z nich uwzględnić inne firmy.

Grounding oznacza oparcie odpowiedzi modelu na konkretnych materiałach, na przykład odnalezionych stronach. Cytowanie źródła to wskazanie takiego materiału, zwykle linkiem; nie musi oznaczać dosłownego cytatu. Sam odnośnik nie dowodzi poprawności całej odpowiedzi. Modele mogą błędnie połączyć informacje, a rozmowa bez wyszukiwania nie musi uwzględniać aktualnej oferty.

GEO a SEO: co się zmienia?

GEO rozszerza cele SEO o obecność w generowanych odpowiedziach, zachowując wspólne podstawy: dostępność strony i przydatną, wiarygodną treść. Google wskazuje, że podstawowe zasady SEO pozostają aktualne również dla jego funkcji AI.

Podział pokazuje różnicę akcentów, bo dobre opisy usług czy czytelne nagłówki służą obu celom. Dlatego pozycjonowanie SEO i AI powinno mieć wspólny plan. Zaniedbana witryna nie zyska wiarygodności przez samo dopisanie sekcji FAQ.

Dlaczego widoczność w AI ma znaczenie dla firmy?

Widoczność w AI daje firmie szansę wejścia do porównania ofert już wtedy, gdy klient dopiero ustala, komu warto się przyjrzeć. Późniejsze wejście na stronę może być kolejnym etapem tej decyzji.

Gdy odpowiedź zaspokaja potrzebę użytkownika bez przejścia do witryny, mamy sytuację określaną jako zero-click. Takie zachowanie może obniżać CTR, czyli udział kliknięć w wyświetleniach wyniku. Skala zależy od zapytania i branży. Spadku klikalności Twojej strony nie należy automatycznie przypisywać AI, pomijając sezonowość czy zmianę pozycji.

Można przypuszczać, że osoba, która wcześniej omówiła swoje potrzeby z asystentem, trafi na stronę lepiej przygotowana do rozmowy. To jednak hipoteza do sprawdzenia w danych firmy. Oceniaj jakość zapytań i sprzedaż, zamiast zakładać, że każde wejście z ChatGPT jest bardziej wartościowe.

Samo pojawienie się nazwy może pomóc w jej zapamiętaniu. Rekomendacja AI nie jest certyfikatem jakości, ale może wpłynąć na listę rozważanych wykonawców. Kosztem braku obecności bywa więc pominięcie firmy jeszcze przed kontaktem, którego później nie zobaczysz w statystykach odwiedzin.

Co pomaga budować widoczność w wynikach generatywnych?

Najrozsądniej zacząć od sprawdzalnych informacji, czytelnej struktury i technicznego dostępu do strony. To obszary, nad którymi masz kontrolę; nie istnieje publiczna lista czynników gwarantujących cytowanie we wszystkich narzędziach AI.

• Układaj treść wokół pytań klientów. Nagłówek „Co obejmuje opieka nad stroną?” jest konkretniejszy niż „Nasze możliwości”. Zaraz pod nim wyjaśnij zakres usługi, a potem dodaj warunki i wyjątki. Pytania w nagłówkach pomagają czytelnikowi, lecz nie są technicznym wymogiem wyszukiwarek AI.
• Twórz fragmenty zrozumiałe bez reszty artykułu. Zamiast „robimy to szybko” opisz, od czego zależy termin i jakie materiały musi dostarczyć klient. Własne dane publikuj razem z metodą ich zebrania, okresem i ograniczeniami. Nie dopisuj statystyk wyłącznie dla wrażenia fachowości.
• Dane strukturalne schema.org opisują treść w formacie czytelnym dla maszyn. Typ LocalBusiness pozwala uporządkować informacje o lokalnej firmie, w tym adres i telefon. Oznaczenia muszą odpowiadać widocznej treści; specjalny schemat „pod GEO” nie jest wymagany przez Google.
• Dane NAP, czyli nazwa, adres i telefon firmy, powinny być spójne. Jeśli witryna podaje inne dane niż profil firmowy, odbiorca ma problem z ustaleniem, które są prawidłowe. Spójność ułatwia identyfikację tej samej firmy w różnych miejscach.
• Pokaż, kto odpowiada za publikację i jakie ma doświadczenie. E-E-A-T to używane przez Google pojęcia doświadczenia, wiedzy fachowej, autorytetu i wiarygodności. Nie są pojedynczym wynikiem punktowym ani uniwersalnym algorytmem AI. Pomagają natomiast ocenić, czy tekst opiera się na rzeczywistej praktyce.
• Sprawdź wydajność i dostępność witryny. Opis oferty powinien dać się odczytać jako tekst, również na telefonie. Błędy serwera lub blokady robotów mogą utrudnić pobranie materiału. Sama szybkość strony nie zapewni cytowania.
• Zadbaj o rzetelne wzmianki w serwisach zewnętrznych: opis wykonanej realizacji u partnera albo wypowiedź w lokalnym medium. Takie materiały mogą dostarczyć kontekstu o firmie. Masowe kupowanie pozornych rekomendacji nie zastępuje reputacji.
• Aktualizuj informacje po zmianie oferty, obszaru obsługi czy zasad współpracy. Popraw treść i dopiero wtedy datę aktualizacji. Przestarzały opis może wprowadzić w błąd klienta również wtedy, gdy zostanie poprawnie przytoczony.

Osobnej kontroli wymaga robots.txt, czyli plik z zasadami dostępu dla robotów. OAI-SearchBot służy wyszukiwaniu w ChatGPT, a GPTBot pobiera treści, które mogą służyć trenowaniu modeli OpenAI. Te ustawienia są niezależne. PerplexityBot odpowiada za wyszukiwanie w Perplexity. Dostęp trzeba sprawdzić również w zabezpieczeniach serwera; sam poprawny plik nie usuwa wszystkich blokad.

Google-Extended jest oznaczeniem sterującym wykorzystaniem treści do trenowania i groundingu w określonych usługach Gemini, a nie osobnym robotem wyszukiwarki. Nie decyduje o obecności w Google Search, w tym AI Overviews i AI Mode. W tych funkcjach znaczenie ma dostęp Googlebota oraz ustawienia indeksowania i prezentacji fragmentów.

Plik llms.txt to propozycja udostępniania informacji i odsyłaczy dla narzędzi AI. Nie jest powszechnym warunkiem widoczności, a Google deklaruje, że nie wykorzystuje go do poprawiania pozycji. Potraktuj go jako dodatek dla systemów, które go obsługują. Kontrolę dostępu i ustawień witryny możesz zlecić w ramach wsparcia technicznego WordPress.

Co trzeba wiedzieć przed rozpoczęciem GEO?

Przed rozpoczęciem GEO trzeba zaakceptować niepełny pomiar i zmienność odpowiedzi: narzędzia monitorujące istnieją, ale żadne nie pokazuje całej obecności firmy we wszystkich rozmowach użytkowników. Raport z wybranej grupy pytań jest próbką.

Odpowiedzi mogą zmieniać się wraz z pytaniem, kontekstem rozmowy i aktualizacją systemu. Cytowanie nie gwarantuje kliknięcia, a kliknięcie nie oznacza sprzedaży. Ustal z wykonawcą, jakie pytania będzie sprawdzał i jak połączy obserwacje z zapytaniami od klientów. Wynik jednego testu nie wystarczy do oceny działań.

Google Search Console ma osobny raport „Funkcje oparte na generatywnej AI”, oznaczony jako Beta. Znajdziesz w nim wykres wyświetleń w czasie dla wybranego okresu i opcję dodania filtra. Na zrzucie powyżej nie ma kliknięć, CTR ani zapytań, więc raport nie daje pełnego obrazu kontaktów z marką. Analitykę strony uzupełnij pytaniem zadawanym klientom: skąd dowiedzieli się o firmie.

Wykres powyżej pochodzi z jednej konkretnej witryny. Widać na nim, że liczba wyświetleń w funkcjach generatywnych AI wzrosła w ciągu kilku miesięcy z pojedynczych dziennie do kilkudziesięciu. To pojedynczy przypadek, a nie benchmark ani obietnica podobnego wyniku dla innej witryny.

Masowe publikowanie tekstów generowanych bez kontroli grozi powielaniem błędów i tworzeniem stron bez wartości; treści produkowane głównie w celu manipulowania wynikami mogą naruszać zasady wyszukiwarki. Zaplanuj czas na poprawki, ponowne pobranie stron i kolejne obserwacje. Sensowny horyzont oceny to zwykle miesiące pracy, bez obietnicy efektu w konkretnym terminie.

Jak podejść do GEO w Olsztynie i regionie?

Lokalne GEO zacznij od jednoznacznego wskazania, gdzie działasz, jakie usługi oferujesz i jak można się z Tobą skontaktować. Firma obsługująca Olsztyn oraz województwo warmińsko-mazurskie powinna opisać rzeczywisty zasięg pracy, warunki dojazdu lub możliwość obsługi zdalnej.

Uzupełnij Profil Firmy w Google, potocznie nazywany wizytówką, i pilnuj godzin otwarcia. Proś klientów o uczciwe opinie oraz odpowiadaj na konkretne uwagi. Lokalne publikacje i wzmianki partnerów mogą potwierdzać związek firmy z regionem. To dobre podstawy obecności lokalnej, choć nie dają automatycznej rekomendacji przez AI.

Treści powinny rozwiązywać miejscowe problemy. Pensjonat może wyjaśnić zasady późnego przyjazdu, a wykonawca stron opisać współpracę z lokalnym przedsiębiorcą. Na stronie dotyczącej tworzenia stron internetowych w Olsztynie przyda się informacja o sposobie przekazywania materiałów i opiece po publikacji. Samo powtarzanie frazy „GEO Olsztyn” niczego klientowi nie wyjaśnia.

Od czego zacząć optymalizację pod AI?

Optymalizacja pod AI powinna zacząć się od najważniejszej usługi i pytań poprzedzających jej zakup. Wybierz ograniczony zakres, który pozwoli sprawdzić jakość informacji oraz sposób mierzenia zmian.

1. Zbierz pytania z rozmów handlowych i wiadomości klientów. Zapisz je zwykłym językiem, bez dopasowywania każdego zdania do frazy SEO.
2. Sprawdź odpowiedzi kilku narzędzi z wyszukiwaniem. Zanotuj datę, pytanie i wskazane źródła oraz to, czy opis firmy jest poprawny. Zachowaj te same warunki przy późniejszym porównaniu.
3. Zrób audyt strony internetowej: oceń dostęp robotów, indeksowanie, czytelność oferty i działanie formularza. Najpierw usuń przeszkody w dotarciu do informacji.
4. Popraw wybraną stronę usługi. Dodaj odpowiedzi na realne wątpliwości, zakres współpracy i potwierdzone przykłady. Wskaż osobę odpowiedzialną za treść.
5. Porównaj dane kontaktowe na stronie, w wizytówce i istotnych katalogach. Ustal, kto aktualizuje je po zmianach.
6. Połącz obserwacje cytowań z analityką i informacjami od handlowców. Wracaj do tej samej listy pytań, zapisuj zmiany i oceniaj także jakość pozyskanych kontaktów.

Najczęściej zadawane pytania

Wdrożenie GEO najczęściej wymaga decyzji o zakresie prac, sposobie pomiaru i czasie potrzebnym na ocenę. Poniższe odpowiedzi pomagają ustalić te kwestie przed zamówieniem usługi.

Czy GEO zastępuje klasyczne SEO?

GEO uzupełnia klasyczne SEO, ponieważ skupia uwagę również na obecności firmy w odpowiedziach AI. Dostępność strony i rzeczowe informacje są przydatne w obu obszarach. Rezygnacja z SEO może utrudnić odnalezienie materiałów, z których korzysta wyszukiwanie generatywne. W małej firmie najpraktyczniejszy jest wspólny plan obejmujący witrynę, treść i pomiar zapytań od klientów.

Czy można zagwarantować widoczność w ChatGPT?

Nie można zagwarantować widoczności w ChatGPT dla dowolnego pytania użytkownika. Dobór źródeł zależy od sposobu wyszukiwania i kontekstu rozmowy, a odpowiedzi mogą się zmieniać. Można natomiast sprawdzić dostęp do strony, poprawić opisy usług i obserwować wybrane zapytania. Rzetelna oferta określa zakres tych prac oraz ograniczenia pomiaru, zamiast obiecywać stałe polecenia firmy.

Czy zgoda na GPTBot jest konieczna do obecności w wyszukiwaniu ChatGPT?

Zgoda na GPTBot nie jest warunkiem obecności w wyszukiwaniu ChatGPT, ponieważ GPTBot i OAI-SearchBot mają odrębne zadania. Pierwszy pobiera materiały potencjalnie używane do trenowania modeli, drugi służy wyszukiwaniu. Możesz rozdzielić ustawienia dostępu tych robotów. Sama zgoda dla OAI-SearchBot nadal nie gwarantuje, że system wybierze stronę jako źródło konkretnej odpowiedzi.

Czy plik llms.txt jest potrzebny do GEO?

Plik llms.txt nie jest uniwersalnym warunkiem prowadzenia GEO ani gwarancją cytowania strony. Może porządkować informacje dla narzędzi, które go obsługują, ale nie zastępuje dostępnej witryny i poprawnej treści. Google deklaruje, że ten plik nie wpływa na widoczność w jego wyszukiwarce. Przy ograniczonym budżecie zacznij od oferty, danych firmy i usunięcia błędów technicznych.

Jak mierzyć efekty pozycjonowania w wyszukiwarkach AI?

Efekty pozycjonowania w wyszukiwarkach AI oceniaj przez powtarzalne sprawdzanie pytań, obserwowanie cytowań oraz analizę kontaktów od klientów. Zapisuj warunki testu, aby móc porównać odpowiedzi w czasie. Analityka pokaże część wejść z asystentów, ale nie wszystkie wcześniejsze zetknięcia z marką. Rozdzielaj obecność nazwy, link do strony i rzeczywiste zapytanie o usługę.

Po jakim czasie można ocenić działania GEO?

Działania GEO najlepiej oceniać po serii obserwacji rozłożonych w czasie, zwykle w perspektywie miesięcy. Systemy muszą odnaleźć i przetworzyć zmienione materiały, a pojedyncza wzmianka może być przypadkowa. Termin zależy od stanu strony i zakresu poprawek. Ustal daty przeglądów oraz sposób raportowania, ale nie traktuj harmonogramu prac jako obietnicy uzyskania cytowań.

Czy mała lokalna firma może skorzystać na GEO?

Mała lokalna firma może skorzystać na GEO, jeśli jej potencjalni klienci szukają usług z pomocą AI, a informacje o ofercie są dostępne i konkretne. Na początek potrzebuje spójnych danych, aktualnej wizytówki oraz odpowiedzi na pytania o współpracę. Opłacalność trzeba ocenić według pozyskanych kontaktów, uwzględniając czas i koszt utrzymywania treści.

Jak ustalić pierwszy zakres prac dla Twojej strony?

Pierwszy zakres prac najlepiej ustalić po sprawdzeniu strony i pytań, z którymi przychodzą klienci. Virtualmedia działa na rynku od ponad 20 lat i zajmuje się stronami internetowymi oraz pozycjonowaniem SEO i AI. Skontaktuj się z Virtualmedia, podaj adres witryny i usługę, którą chcesz promować. To wystarczy, żeby rozpocząć rozmowę o potrzebnych zmianach.

Artykuł Co to jest GEO? Dlaczego warto być widocznym w wyszukiwaniu generatywnym AI? pochodzi z serwisu Strony Internetowe Olsztyn, Strony www - Virtualmedia Sklepy Internetowe, Profesjonalne, Indywidualne.

17 lipca 2026 roku zespół bezpieczeństwa WordPressa opublikował wydanie 7.0.2 – i nie była to zwykła, rutynowa aktualizacja. Załatano dwie podatności (jedną krytyczną, jedną o wysokim priorytecie), które połączone w łańcuch pozwalały atakującemu wykonać własny kod na serwerze bez logowania – bez hasła, bez konta, bez żadnej podatnej wtyczki. Wystarczyła czysta, domyślna instalacja WordPressa i jedno anonimowe żądanie z Internetu.

Kilka dni po publikacji luki trafił do nas klient, którego serwer padł ofiarą dokładnie takiego ataku. To, co zastaliśmy, było podręcznikowym przykładem tego, jak jedna nieaktualna strona plus źle skonfigurowany serwer zamieniają lokalny incydent w infekcję wszystkich domen na hostingu. W tym artykule opisujemy ten przypadek krok po kroku – i wyjaśniamy, czym jest open_basedir, dlaczego współdzielenie katalogów to proszenie się o kłopoty oraz dlaczego usuwanie wirusów w takiej konfiguracji przypomina walkę z hydrą.

Co się stało? WordPress 7.0.2 w pigułce

Zanim przejdziemy do case study – krótko o samej luce, bo dotyczy ona praktycznie każdego, kto ma stronę na WordPressie:

• Data wydania poprawki: 17 lipca 2026
• Charakter podatności: ułatwiona iniekcja SQL oraz błąd w obsłudze zbiorczych żądań REST API, które połączone razem prowadziły do zdalnego wykonania kodu (RCE) bez uwierzytelnienia
• Wersje podatne: WordPress od 6.8.0 do 7.0.1
• Wersje bezpieczne: 7.0.2, 6.9.5, 6.8.6
• Skala zagrożenia: na tyle poważna, że WordPress.org włączył wymuszone automatyczne aktualizacje dla podatnych instalacji

To rzadka sytuacja – zdecydowana większość problemów bezpieczeństwa WordPressa dotyczy wtyczek, a nie samego rdzenia. Tym razem podatny był sam WordPress. Dlatego jeśli po zalogowaniu do kokpitu w zakładce Kokpit → Aktualizacje widzisz wersję inną niż 7.0.2 (lub 6.9.5 / 6.8.6 dla starszych gałęzi) – zaktualizuj stronę natychmiast. To dwie minuty pracy, które mogą oszczędzić tygodni sprzątania.

Case study: jedna luka, kilkanaście zainfekowanych domen

Do naszego działu wsparcia technicznego zgłosił się nowy klient z klasycznym zestawem objawów: strona przekierowuje na podejrzane witryny, Google oznaczył domenę jako niebezpieczną, poczta z serwera ląduje w spamie, a hosting wysłał ostrzeżenie o nadużyciach. Problem? Klient miał na jednym serwerze kilkanaście domen – strony firmowe, landing page, projekty testowe.

Nasza analiza logów wykazała, że punktem wejścia była jedna, dawno nieaktualizowana instalacja WordPressa – strona-wizytówka, o której wszyscy zapomnieli. Atakujący wykorzystał lukę, wgrał tzw. webshell (skrypt dający mu zdalną kontrolę) i… tu zaczyna się właściwa część tej historii.

Bo sama infekcja jednej strony to problem przykry, ale opanowalny. Prawdziwa katastrofa wynikała z konfiguracji serwera.

Czym jest open_basedir i dlaczego jego brak to otwarte drzwi

open_basedir to dyrektywa PHP, która ogranicza skryptom dostęp do plików wyłącznie w obrębie wskazanego katalogu. W praktyce: skrypt działający w katalogu domeny A nie może czytać ani zapisywać plików w katalogu domeny B, nawet jeśli obie leżą na tym samym serwerze.

Na serwerze naszego klienta open_basedir nie był ustawiony w ogóle. Efekt? Skrypt hakerski wgrany przez lukę w jednej stronie mógł swobodnie „spacerować” po całym systemie plików w zasięgu użytkownika – listować katalogi pozostałych domen, czytać pliki wp-config.php z hasłami do baz danych i dopisywać złośliwy kod do plików każdej kolejnej strony.

To dokładnie się wydarzyło. W ciągu kilku godzin od pierwszej infekcji automat atakującego:

• odczytał dane dostępowe do baz danych wszystkich instalacji WordPress i PrestaShop na serwerze,
• dopisał złośliwe przekierowania do plików index.php i .htaccess każdej domeny,
• rozsiał dziesiątki kopii webshelli w losowych katalogach – wp-includes, wp-content/uploads, katalogach motywów i wtyczek,
• utworzył ukryte zadania cron, które przywracały infekcję po każdej próbie czyszczenia.

Jedna luka. Kilkanaście zainfekowanych domen. I to nie dlatego, że wszystkie były podatne – tylko dlatego, że nic nie oddzielało ich od siebie.

Współdzielenie katalogów – jeden użytkownik, wiele domen

Drugim grzechem konfiguracji było to, że wszystkie domeny działały na jednym koncie użytkownika systemowego, ze wspólnymi uprawnieniami do plików. To niestety częsty scenariusz: tanie VPS-y konfigurowane „na szybko”, stare panele hostingowe albo sytuacja, w której kolejne strony dokładano latami do jednego konta, bo tak było wygodniej.

Taka architektura oznacza, że z punktu widzenia systemu każdy skrypt PHP każdej domeny ma identyczne prawa do plików wszystkich pozostałych domen. Nie ma znaczenia, że dziesięć stron jest zaktualizowanych i zabezpieczonych wzorowo – wystarczy jedna zaniedbana, by atakujący dostał klucze do całości. W branży bezpieczeństwa mówi się o tym „lateral movement” – ruch boczny. Bez separacji katalogów i użytkowników ten ruch nie napotyka żadnego oporu.

Prawidłowa konfiguracja wygląda tak:

• osobny użytkownik systemowy dla każdej domeny (lub przynajmniej dla każdego klienta/projektu),
• open_basedir ograniczony do katalogu danej strony plus niezbędne katalogi tymczasowe,
• PHP działające w trybie izolowanym (np. PHP-FPM z osobną pulą per domena),
• uprawnienia plików, które nie pozwalają na zapis tam, gdzie zapis nie jest potrzebny.

Dlaczego usuwanie wirusów w takiej konfiguracji jest tak trudne

Tu dochodzimy do sedna problemu, z którym mierzy się każdy, kto próbował „wyczyścić” zainfekowany serwer bez separacji domen. Usuwanie złośliwego kodu w takim środowisku to walka z hydrą – odcinasz jedną głowę, odrastają dwie:

1. Reinfekcja krzyżowa. Czyścisz domenę A, ale webshell ukryty w domenie B po godzinie ponownie dopisuje złośliwy kod do domeny A. Dopóki nie znajdziesz i nie usuniesz wszystkich kopii na wszystkich domenach jednocześnie, sprzątanie jest syzyfową pracą.
2. Nie wiadomo, co jest „czyste”. Skoro atakujący miał dostęp do wszystkiego, żadnemu plikowi nie można ufać. Trzeba weryfikować sumy kontrolne rdzenia WordPressa, każdą wtyczkę, każdy motyw – na każdej domenie osobno.
3. Skompromitowane dane dostępowe. Hasła do wszystkich baz danych, kluczy API i kont FTP należy uznać za wykradzione. Wszystkie – nie tylko te z zaatakowanej strony.
4. Mechanizmy przetrwania. Zadania cron, spreparowane wpisy w bazie danych, „uśpione” backdoory czekające tygodniami na ponowną aktywację. Automatyczne skanery antywirusowe hostingu zwykle znajdują tylko część z nich.

Dlatego koszt usunięcia infekcji z serwera bez separacji jest wielokrotnie wyższy niż z serwera poprawnie skonfigurowanego – i dlatego tak wiele „wyczyszczonych” stron wraca do punktu wyjścia po tygodniu.

Jak rozwiązaliśmy problem – krok po kroku

W opisywanym przypadku nasz zespół przeprowadził pełną procedurę naprawczą:

1. Odcięcie i diagnoza. Zablokowaliśmy ruch do zainfekowanych stron, zabezpieczyliśmy kopię materiału do analizy i na podstawie logów serwera ustaliliśmy wektor ataku oraz dokładną oś czasu infekcji.
2. Czyszczenie wszystkich domen równolegle. Porównaliśmy pliki każdej instalacji z oryginalnymi sumami kontrolnymi, usunęliśmy webshelle, złośliwe wpisy w .htaccess, zainfekowane pliki rdzenia oraz spreparowane zadania cron. Przeskanowaliśmy również bazy danych pod kątem wstrzykniętego kodu i fałszywych kont administratorów.
3. Aktualizacje. Wszystkie instalacje WordPressa zostały podniesione do wersji 7.0.2, wtyczki i motywy zaktualizowane, a nieużywane – usunięte. Porzucone strony testowe zostały za zgodą klienta całkowicie wyłączone.
4. Wymiana wszystkich danych dostępowych. Nowe hasła do baz danych, paneli administracyjnych, kont FTP/SFTP oraz nowe klucze i sole bezpieczeństwa WordPressa.
5. Separacja i utwardzenie serwera. Każda domena otrzymała osobnego użytkownika systemowego i własną pulę PHP-FPM z restrykcyjnym open_basedir. Wyłączyliśmy niebezpieczne funkcje PHP, wdrożyliśmy firewall aplikacyjny (WAF), monitoring integralności plików oraz automatyczne aktualizacje bezpieczeństwa.
6. Odzyskanie reputacji. Zgłosiliśmy oczyszczone strony do ponownej weryfikacji w Google Search Console, zdjęliśmy ostrzeżenia „strona może być niebezpieczna” i przywróciliśmy prawidłowe dostarczanie poczty.

Efekt: wszystkie strony wróciły do działania, a od zakończenia prac monitoring nie wykrył ani jednej próby reinfekcji. Co równie ważne – nawet gdyby w przyszłości któraś ze stron została skompromitowana, infekcja zostanie zamknięta w obrębie jednej domeny, a nie całego serwera.

Jak sprawdzić, czy Twój serwer jest podatny? Szybka checklista

Zanim zamkniesz ten artykuł, poświęć pięć minut na weryfikację:

1. Wersja WordPressa – Kokpit → Aktualizacje. Wszystko poniżej 7.0.2 (lub 6.9.5 / 6.8.6) wymaga natychmiastowej aktualizacji. Nie polegaj ślepo na auto-aktualizacjach – potrafią po cichu zawieść przy problemach z uprawnieniami plików.
2. open_basedir – utwórz plik z funkcją phpinfo() i sprawdź, czy dyrektywa jest ustawiona i wskazuje wyłącznie katalog Twojej strony. Wartość „no value” to czerwona lampka.
3. Liczba domen na jednym koncie – jeśli na jednym użytkowniku hostingu działa kilka niezależnych stron, każda z nich jest tak bezpieczna, jak najsłabsza z nich.
4. Zapomniane instalacje – stare wersje testowe, kopie w podkatalogach typu /old/, /backup/, /test/ to ulubione cele automatów skanujących sieć.
5. Kopie zapasowe – przechowywane poza serwerem, testowane, z historią co najmniej kilku tygodni wstecz. Backup na tym samym serwerze, który padł ofiarą ataku, bywa bezużyteczny.

Najczęstsze pytania (FAQ)

Czy aktualizacja do WordPress 7.0.2 może zepsuć moją stronę?

Wydania bezpieczeństwa zawierają wyłącznie poprawki, bez zmian funkcjonalnych, więc ryzyko jest minimalne. Mimo to przed aktualizacją warto wykonać kopię zapasową – a jeśli strona korzysta z wielu wtyczek lub modyfikacji, przetestować aktualizację na kopii roboczej.

Mam włączone automatyczne aktualizacje. Czy jestem bezpieczny?

Prawdopodobnie tak, ale zweryfikuj to. Automatyczne aktualizacje potrafią zawieść po cichu – przez konflikt wtyczki, problem z uprawnieniami plików czy wyłączony cron. Zajrzyj do kokpitu i sprawdź numer wersji na własne oczy.

Moja strona działa normalnie. Czy to znaczy, że nie została zhakowana?

Niestety nie. Nowoczesne infekcje często działają niezauważalnie – wysyłają spam, kopią kryptowaluty albo pokazują złośliwe treści wyłącznie robotom Google. Brak widocznych objawów nie jest dowodem czystości; jest nim dopiero skan integralności plików.

Czy wystarczy usunąć zainfekowane pliki?

Nie – to najczęstszy błąd. Bez ustalenia wektora ataku, wymiany haseł, aktualizacji i zabezpieczenia serwera infekcja wraca zwykle w ciągu kilku dni.

Podsumowanie

Historia tego klienta pokazuje trzy rzeczy naraz. Po pierwsze: aktualizacje bezpieczeństwa nie są opcjonalne – luka załatana w WordPress 7.0.2 pozwalała przejąć stronę jednym anonimowym żądaniem. Po drugie: konfiguracja serwera decyduje o skali szkód – brak open_basedir i współdzielenie katalogów zamieniły infekcję jednej zapomnianej strony w kompromitację kilkunastu domen. Po trzecie: usuwanie wirusów bez separacji domen to walka z hydrą – i dlatego prewencja jest zawsze tańsza niż sprzątanie.

Jeśli podejrzewasz, że Twoja strona mogła zostać zainfekowana, nie masz pewności, czy Twój serwer jest poprawnie odseparowany, albo po prostu chcesz spać spokojnie – napisz do nas. Przeprowadzimy audyt bezpieczeństwa, wyczyścimy zainfekowane strony i zabezpieczymy serwer tak, by następna głośna luka była dla Ciebie tylko newsem, a nie kryzysem. Zajmujemy się tym na co dzień w ramach wsparcia technicznego i hostingu zoptymalizowanego pod WordPress i PrestaShop.

Artykuł Krytyczna luka w WordPressie – dlaczego aktualizacja do 7.0.2 to konieczność. Przykładowe case study – na co zwrócić uwagę. pochodzi z serwisu Strony Internetowe Olsztyn, Strony www - Virtualmedia Sklepy Internetowe, Profesjonalne, Indywidualne.