Jak sprawdzić czy strona jest na WordPressie? Szybkie metody rozpoznania CMS

Żeby sprawdzić, czy strona działa na WordPressie, często wystarczy szybki rzut oka w kod źródłowy lub adresy podstron. Pomogą też proste narzędzia online, które w kilka sekund podpowiedzą, na jakim CMS działa witryna.

Po co w ogóle sprawdzać, czy strona działa na WordPressie?

Znajomość tego, czy strona działa na WordPressie, pomaga podejmować lepsze decyzje – zarówno techniczne, jak i biznesowe. Dla osoby, która dopiero zaczyna przygodę z tworzeniem stron, to często pierwszy wyznacznik: „czy da się zrobić coś podobnego samemu, bez programisty?”. Jeśli okazuje się, że oglądana strona opiera się na WordPressie, łatwiej oszacować poziom trudności, czas pracy (np. czy to kwestia kilku godzin konfiguracji, czy raczej tygodni), a nawet budżet na wdrożenie podobnego rozwiązania.

Rozpoznanie WordPressa przydaje się też wtedy, gdy planowane jest zlecenie prac wykonawcy. Znając CMS, można precyzyjniej zapytać o ofertę, unikając ogólników w stylu „strona wizytówka”, i poprosić od razu o konkrety: konfigurację motywu, dobór wtyczek czy optymalizację pod szybkość. Dla osób bardziej zaawansowanych informacja „to jest WordPress” otwiera możliwość podpatrzenia rozwiązań: jakie wtyczki mogły zostać użyte, jak rozwiązano blog, sklep czy wielojęzyczność. W praktyce oszczędza to wiele godzin eksperymentów i poszukiwań na ślepo.

Nie bez znaczenia jest także kwestia bezpieczeństwa i utrzymania. Jeśli zarządza się kilkoma serwisami i nie ma się pewności, na czym działają, trudno planować aktualizacje czy kopie zapasowe. Świadomość, że to WordPress, pozwala od razu przewidzieć typowe zadania administracyjne: regularne aktualizacje rdzenia i wtyczek, kontrolę kompatybilności z PHP czy monitoring wydajności. Dla osób zajmujących się marketingiem czy SEO wiedza o CMS ułatwia z kolei ocenę, jakie funkcje są „w zasięgu” bez kodowania, na przykład szybkie wdrożenie analityki, formularzy czy optymalizacji pod wyszukiwarki.

Jak najszybciej poznać CMS po adresie URL i strukturze linków?

Na pierwszy rzut oka o używanym CMS-ie często najwięcej mówi sam adres strony. W przypadku WordPressa bardzo często pojawiają się charakterystyczne fragmenty URL, które można wychwycić w kilka sekund, nawet bez wchodzenia w kod. Już sama struktura linków podstron, kategorii czy wpisów blogowych bywa tak typowa, że po krótkim „rzucie okiem” da się z dużym prawdopodobieństwem stwierdzić, że w tle działa WordPress, a nie autorskie rozwiązanie czy inny system.

Dobrym punktem wyjścia jest przyjrzenie się temu, jak zbudowane są adresy poszczególnych podstron. Wiele witryn na WordPressie korzysta z przyjaznych linków typu: domena.pl/kategoria/nazwa-wpisu lub domena.pl/2024/11/nazwa-wpisu. Taki format, z datą w środku lub segmentem „category”, jest bardzo częsty, bo znajduje się w domyślnych ustawieniach WordPressa od wielu lat. Innym sygnałem bywa obecność końcówki „/tag/nazwa-xtagu” przy stronach z tagami albo „/author/nazwa-autora” przy archiwum autora. Oczywiście sam „ładny” URL jeszcze niczego nie przesądza, bo wiele innych systemów też tak potrafi, ale im więcej takich powtarzalnych elementów, tym większa szansa, że to właśnie WordPress.

Kolejny krok to sprawdzenie, jak wyglądają adresy bardziej „technicznych” podstron. Po wpisaniu na końcu domeny fragmentu „/wp-admin” lub „/wp-login.php” wiele stron na WordPressie przekierowuje od razu do panelu logowania. Czasami jest on dodatkowo ukryty, więc może się pojawić komunikat błędu 404, ale jeśli zamiast tego pokazuje się klasyczny ekran logowania z logo WordPressa albo formularz w dobrze znanym układzie, jest to mocny sygnał. Ciekawa bywa też struktura linków w nawigacji. Jeśli w menu często pojawia się logiczny podział typu „Blog”, „Kategorie”, „Archiwum”, a pod tym kryją się właśnie adresy z datami, tagami i kategoriami, można już dość świadomie podejrzewać, że strona opiera się na WordPressie, a nie na zupełnie niestandardowym systemie tworzonym od zera.

• Adresy wpisów w formacie rok/miesiąc/tytuł, np. „/2023/08/nazwa-wpisu”.
• Strony kategorii i tagów z segmentami „/category/” lub „/tag/”.
• Próba wejścia na „/wp-admin” lub „/wp-login.php” prowadząca do znanego ekranu logowania.

Im więcej z tych elementów pojawia się na badanej stronie, tym mniej przypadkowa staje się zbieżność. Sama struktura URL nie daje stuprocentowej pewności, ale często pozwala w mniej niż minutę wyrobić sobie całkiem trafną pierwszą opinię o tym, czy pod spodem działa WordPress.

Jak rozpoznać WordPressa po kodzie strony i charakterystycznych ścieżkach plików?

Najpewniejszym sposobem rozpoznania WordPressa jest zajrzenie „pod maskę”, czyli do kodu strony i ścieżek plików. W wielu przypadkach już po 10–20 sekundach przeglądania źródła przeglądarka zdradzi, z jakim CMS-em ma się do czynienia. Nawet jeśli część elementów zostanie ukryta lub przebudowana przez programistę, w kodzie często zostają małe ślady, które działają jak cyfrowe odciski palców WordPressa.

Najprościej zacząć od podglądu źródła strony (np. prawy przycisk myszy i „Pokaż źródło strony”). Widać tam od razu, skąd ładowane są style CSS, skrypty JavaScript i obrazki. W przypadku WordPressa bardzo często pojawiają się charakterystyczne katalogi, które występują na milionach stron z tym CMS-em. Najczęściej zdradzają go takie ścieżki jak:

• /wp-content/themes/nazwa-motywu/ – katalog motywów (szablonów wyglądu), w którym widać style i pliki graficzne danego motywu
• /wp-content/plugins/ – katalog wtyczek, w którym pojawiają się nazwy popularnych rozszerzeń, na przykład do formularzy czy galerii
• /wp-includes/ – katalog techniczny WordPressa, w którym znajdują się pliki odpowiedzialne za działanie rdzenia systemu

Jeśli w kodzie źródłowym lub w konsoli przeglądarki widać kilka takich ścieżek naraz, istnieje duże prawdopodobieństwo, że strona działa właśnie na WordPressie. Czasem pojawiają się też nagłówki typu meta name="generator" content="WordPress 6.x", choć coraz częściej są one świadomie usuwane ze względów bezpieczeństwa. Brak tych elementów nie oznacza więc automatycznie, że WordPressa nie ma – ale ich obecność bywa bardzo mocnym sygnałem, który pomaga oszczędzić sporo czasu na dalsze sprawdzanie.

Jakie darmowe narzędzia online pomogą wykryć, czy strona jest na WordPressie?

Najszybszym sposobem na sprawdzenie, czy strona działa na WordPressie, bywają darmowe narzędzia online, które analizują kod za nas. Wystarczy wkleić adres strony, kliknąć przycisk i po kilku sekundach pojawia się informacja o wykrytym CMS, czasem razem z wersją WordPressa, używanymi wtyczkami czy motywem. Dla osoby nietechnicznej to duże ułatwienie, bo nie trzeba zaglądać w źródło strony ani szukać charakterystycznych ścieżek plików.

Dobrze sprawdza się łączenie takich narzędzi, na przykład użycie dwóch różnych skanerów pod rząd, aby porównać wyniki. Zdarza się, że trudniejsze strony, z mocno zmienioną strukturą lub dodatkowymi zabezpieczeniami, nie zostaną rozpoznane od razu, dlatego przy braku jednoznacznej odpowiedzi pomocne bywa sięgnięcie po kolejne detektory lub ręczne sprawdzenie kilku charakterystycznych elementów strony.

Jakie sygnały w panelu logowania i cookies zdradzają WordPressa?

Panel logowania i cookies często zdradzają WordPressa szybciej niż analiza kodu źródłowego. Już sam adres strony logowania bywa mocną podpowiedzią, bo wiele witryn używa domyślnej ścieżki /wp-login.php lub przekierowania z /wp-admin. Jeśli po wejściu pod taki adres pojawia się znajomy ekran logowania z logo WordPressa albo charakterystycznym układem pól „Nazwa użytkownika” i „Hasło”, istnieje duże prawdopodobieństwo, że oglądana strona działa właśnie na tym CMS-ie. Nawet gdy administrator zmienił adres logowania, niektóre elementy interfejsu, układ przycisków czy styl komunikatów błędów nadal wyglądają tak, jak w klasycznym WordPressie, bo ich pełne „zamaskowanie” wymaga dodatkowej pracy.

Sporym tropem są także cookies, czyli małe pliki zapisywane w przeglądarce. Po wejściu na stronę można podejrzeć je w narzędziach deweloperskich przeglądarki (w Chrome zwykle zajmuje to mniej niż 30 sekund) i sprawdzić ich nazwy. WordPress często zostawia po sobie charakterystyczne ciasteczka, na przykład zawierające fragment wordpress_, wordpress_logged_in_ lub wp-settings-. Jeśli ktoś jest zalogowany do panelu, w cookies pojawiają się też wpisy związane z sesją użytkownika, które łatwo odróżnić od ciasteczek typowo analitycznych czy reklamowych. Dla osób bardziej zaawansowanych dobrym sygnałem bywa także obecność cookies ustawianych przez popularne wtyczki bezpieczeństwa lub cache, które często są instalowane właśnie na WordPressie.

• Typowe adresy logowania, takie jak /wp-login.php lub przekierowanie z /wp-admin.
• Charakterystyczny wygląd ekranu logowania, z układem pól i komunikatami błędów WordPressa.
• Obecność cookies zaczynających się od wordpress_, wordpress_logged_in_ lub wp-settings-.
• Ciasteczka tworzone przez popularne wtyczki związane z bezpieczeństwem lub cache, często używane w ekosystemie WordPressa.
• Powtarzalne komunikaty o błędnym haśle lub wylogowaniu, identyczne z tymi znanymi z domyślnej instalacji WordPressa.

Tego typu sygnały rzadko dają stuprocentową pewność w pojedynkę, ale w połączeniu z innymi metodami rozpoznania zwykle pozwalają już z dużą dozą przekonania stwierdzić, że strona działa na WordPressie. Dobrze jest więc traktować panel logowania i cookies jako kolejne źródło danych, a nie jedyne kryterium oceny.

Jak wtyczki i motywy pomagają potwierdzić, że strona działa na WordPressie?

Obecność charakterystycznych motywów i wtyczek bywa jednym z najpewniejszych sygnałów, że strona działa na WordPressie. Nawet gdy administrator ukryje domyślne ścieżki czy nagłówki, ślady konkretnych rozszerzeń często zostają w kodzie, plikach statycznych albo w adresach URL. Można to traktować jak sprawdzanie, z jakich „klocków” zbudowano serwis – jeśli klocki są typowo wordpressowe, sam CMS też zwykle nim jest.

W praktyce wiele motywów i wtyczek zostawia dość jasne znaki rozpoznawcze. Czasem wystarczy przejrzenie kodu strony głównej w przeglądarce, innym razem pomocna bywa zakładka „Sieć” w narzędziach deweloperskich, która pokazuje ładowane pliki CSS i JS. Wśród typowych tropów pojawiają się między innymi:

• adresy plików stylów i skryptów zawierające „/wp-content/themes/nazwa-motywu/” – katalog „themes” jest standardem w WordPressie i zdradza konkretny motyw, np. Astra czy Divi
• skrypty i style z nazwami popularnych wtyczek, na przykład „elementor.min.js”, „wpforms.min.css” czy „woocommerce.js” ładowane na większości podstron
• klasy CSS w HTML, które odnoszą się do znanych page builderów (kreatorów stron), takich jak „elementor-section”, „fl-builder-content” albo „wp-block-…”, typowe dla edytora blokowego Gutenberga
• adresy URL koszyka, konta użytkownika czy sklepu z fragmentami „/cart/”, „/my-account/” albo „/product/”, które w połączeniu z plikami WooCommerce w kodzie bardzo często oznaczają sklep na WordPressie
• publicznie dostępne pliki statyczne w katalogu „/wp-content/uploads/”, na przykład ikony z motywu lub grafiki wgrywane przez konkretne wtyczki SEO, cache czy formularzy

Odnalezienie dwóch lub trzech takich sygnałów jednocześnie zwykle daje już mocne potwierdzenie, że strona stoi na WordPressie, nawet jeśli inne metody nie były jednoznaczne. Trzeba tylko pamiętać, że część zaawansowanych instalacji może zmieniać ścieżki i nazwy plików, więc brak takich śladów nie wyklucza WordPressa, ale ich obecność bardzo często stawia sprawę jasno.

Co zrobić, gdy metody wykrywania WordPressa nie dają jednoznacznej odpowiedzi?

Gdy wszystkie szybkie metody zawodzą, a strona wciąż „udaje”, że nie jest na WordPressie, zwykle oznacza to jedno: twórcy celowo coś ukryli lub mocno przebudowali CMS. W takiej sytuacji sprawdzanie pojedynczych adresów czy nagłówków potrafi zająć 20–30 minut i nadal nie dawać stuprocentowej pewności. Warto wtedy podejść do sprawy jak do układanki: nie szuka się jednego dowodu, tylko składa się kilka słabszych sygnałów w całość i na tej podstawie ocenia się prawdopodobieństwo.

Poniżej znajduje się krótkie porównanie podejścia „zero-jedynkowego” (tak/nie) z podejściem opartym na poszlakach. Taka perspektywa pomaga zarówno osobie początkującej, jak i bardziej technicznej, podjąć decyzję, czy dalsze drążenie ma sens, czy lepiej już przyjąć, że CMS-u po prostu nie da się rozpoznać z zewnątrz na 100%.

Jeśli po przejrzeniu kilku takich „poszlak” wciąż nie da się postawić jednoznacznej diagnozy, rozsądnie jest zmienić cel: zamiast na siłę szukać etykietki „WordPress”, lepiej ocenić, czy dana strona pozwoli zrealizować konkretne potrzeby, jak edycja treści, integracje czy rozbudowa. Dla wielu osób korzystających z gotowego motywu czy sklepu ważniejsze będzie to, jak się na co dzień pracuje ze stroną, niż dokładna nazwa silnika, który działa pod spodem.