Jak sprawdzić technologie strony internetowej

Wchodzisz na jakąś stronę i zastanawiasz się: na czym to w ogóle działa? WordPress, sklep na Shopify, a może autorski silnik napisany w Laravelu albo front w Next.js? Dobra wiadomość: w 90% przypadków odpowiedź masz na wyciągnięcie ręki, bez instalowania niczego i bez zgadywania. Wystarczy przeglądarka, jeden skrót klawiszowy i czasem jedna komenda w terminalu.

W tym poradniku pokażę Ci konkretne metody rozpoznawania silnika strony (CMS) oraz całego stosu technologicznego (serwer, CDN, framework front-endowy). Od najprostszych trików dla każdego, po sztuczki, których używają specjaliści SEO i pentesterzy. Zaczynamy od narzędzia, które masz już otwarte.

Po co w ogóle sprawdzać, na czym postawiona jest strona?

To nie jest wiedza tylko dla geeków. Znajomość technologii pod spodem ma bardzo praktyczne zastosowania:

• Analiza konkurencji — widzisz, że rywal stoi na WordPressie z gotowym motywem? Wiesz, że jego strona ma swoje ograniczenia wydajnościowe i że da się go wyprzedzić lepszą optymalizacją.
• Bezpieczeństwo — każdy CMS ma swoje znane podatności. Jeśli wiesz, że strona to WordPress 5.x sprzed lat, wiesz też, że prawdopodobnie wisi na niej kilka niezałatanych dziur.
• Wycena i planowanie pracy — zanim weźmiesz zlecenie „przerób mi tę stronę”, warto wiedzieć, czy to prosty WordPress (zmiany w godzinę), czy autorski silnik, w którym każda poprawka to grzebanie w kodzie.
• Nauka i inspiracja — podoba Ci się, jak działa czyjś sklep albo jak szybko ładuje się portal? Sprawdzasz stack i wiesz, czego się uczyć.

Metoda 1: kod źródłowy strony (Ctrl+U)

Najszybsza i najbardziej niezawodna metoda. Wejdź na stronę i wciśnij Ctrl+U (na Macu Cmd+Option+U). Otworzy się surowy kod HTML. Teraz wciśnij Ctrl+F i szukaj charakterystycznych śladów. To są odciski palca poszczególnych silników:

• wp-content lub wp-includes — niemal pewny znak, że to WordPress.
• wp-json — aktywne REST API WordPressa, kolejne potwierdzenie.
• woocommerce albo klasy z prefiksem wc- — WordPress ze sklepem na WooCommerce.
• data-drupal- lub /sites/default/files/ — to Drupal.
• /templates/ + /media/jui/ albo ścieżka /administrator — typowe dla Joomli.
• cdn.shopify.com lub /collections/ w linkach — sklep na Shopify.
• Mage.Cookies albo /skin/frontend/ — to Magento.
• presta-, id_product w adresach — PrestaShop.

Tag meta generator — silnik na tacy

Wielu CMS-ów grzecznie podpisuje się w sekcji . Wyszukaj w kodzie frazę generator. Często trafisz na coś takiego:

Bonus: czasem widzisz tu nawet numer wersji, co jest złotem dla kogoś, kto sprawdza bezpieczeństwo. Dlatego porządnie zabezpieczone strony ten tag usuwają — jego brak to też informacja.

Metoda 2: nagłówki HTTP w terminalu

Druga warstwa to nie HTML, tylko to, co serwer odpowiada zanim w ogóle wyśle stronę. Najprościej podejrzeć to komendą w terminalu:

curl -I https://adres-strony.pl

Flaga -I (duże „i”) pobiera same nagłówki, bez treści. W odpowiedzi szukaj takich linii:

• Server: nginx / Apache / LiteSpeed — jaki serwer WWW obsługuje stronę.
• X-Powered-By: PHP/8.2 — język i wersja backendu (jeśli admin tego nie ukrył).
• cf-ray lub Server: cloudflare — strona stoi za CDN-em Cloudflare.
• X-Pingback: .../xmlrpc.php — kolejny ślad WordPressa.
• X-Generator, X-Drupal-Cache, X-Shopify-Stage — silnik podany wprost w nagłówku.
• Set-Cookie z nazwami w stylu PHPSESSID, wordpress_logged_in, PrestaShop- — ciasteczka też zdradzają CMS.

Nie masz curl pod ręką? Te same dane zobaczysz w przeglądarce: otwórz narzędzia deweloperskie (F12), zakładka Network, odśwież stronę, kliknij pierwsze żądanie i przejdź do Headers.

Metoda 3: wtyczki do przeglądarki (najwygodniej)

Jeśli nie chcesz grzebać w kodzie, zainstaluj wtyczkę, która robi to za Ciebie jednym kliknięciem. Najpopularniejsze:

• Wappalyzer — klasyk. Po wejściu na stronę pokazuje CMS, framework, biblioteki JavaScript (np. jQuery, React), system analityczny, serwer i CDN. Dostępny dla Chrome i Firefoxa, działa automatycznie.
• BuiltWith — podobny zakres, mocny zwłaszcza przy wykrywaniu narzędzi marketingowych i tagów reklamowych.
• WhatRuns — lekka alternatywa, czytelnie grupuje wykryte technologie.

Wtyczki to świetny punkt startu, ale traktuj je jak wskazówkę, nie wyrocznię. Potrafią się pomylić — głównie przy stronach headless i niestandardowych konfiguracjach (o tym za chwilę).

Metoda 4: narzędzia online (gdy nie chcesz nic instalować)

Wpisujesz adres URL, dostajesz raport. Przydatne, gdy sprawdzasz cudzy komputer albo chcesz dane historyczne:

• WhatCMS.org — skupia się konkretnie na rozpoznaniu silnika.
• BuiltWith.com — najobszerniejszy profil technologiczny, pokazuje też zmiany w czasie.
• W3Techs — bardziej do statystyk rynkowych, ale potrafi sprawdzić pojedynczą domenę. To stąd pochodzą popularne dane o udziałach: według W3Techs WordPress odpowiada za ponad 40% wszystkich stron w sieci (wartość waha się i jest regularnie aktualizowana, więc sprawdzaj bieżący odczyt na w3techs.com).

Metoda 5: triki, gdy strona „nie chce się przyznać”

Część stron celowo zaciera ślady — usuwa wp-content, chowa nagłówki, stoi za Cloudflare. Wtedy wchodzą w grę metody pośrednie:

• Ścieżka panelu logowania — dopisz do adresu typowy login danego CMS-a. /wp-admin (WordPress), /administrator (Joomla), /user/login (Drupal), /admin (PrestaShop, choć często zmieniany). Jeśli wyświetli się znajomy ekran logowania — masz silnik.
• Strona błędu 404 — wpisz losowy, nieistniejący adres (np. domena.pl/abcxyz123). Domyślny wygląd komunikatu o błędzie często jest charakterystyczny dla danego systemu czy serwera.
• Plik robots.txt — otwórz domena.pl/robots.txt. Reguły blokujące /wp-admin/ czy /administrator/ zdradzają CMS na pierwszy rzut oka.
• Plik sitemap.xml — struktura mapy strony (np. osobne sitemapy dla wpisów, stron, kategorii generowane przez Yoast albo Rank Math) też wskazuje na WordPressa.
• Stopka strony — brzmi banalnie, ale mnóstwo wdrożeń wciąż zostawia w stopce „Powered by WordPress” albo nazwę szablonu.

Strony headless i frameworki front-endowe — uwaga na pułapkę

Coraz częściej trafisz na stronę, gdzie Wappalyzer pokazuje React albo Next.js i… nic poza tym. To architektura headless: silnik treści (np. WordPress, Strapi czy Sanity) siedzi w tle jako API, a to, co widzisz, renderuje aplikacja front-endowa. Jak ją rozpoznać?

• W kodzie źródłowym widać mało treści, za to dużo pustych kontenerów
  i jeden duży skrypt JS.
• Pliki w folderze /_next/ to znak Next.js, /static/js/main.*.js z długimi hashami — typowy Create React App.
• Atrybuty data-v- w HTML wskazują na Vue.js, a ng-version na Angular.
• Obecność /wp-json/ przy froncie w Next.js = headless WordPress.

To ważne rozróżnienie: „strona w React” nie mówi Ci, gdzie jest zarządzana treść. Front i CMS to wtedy dwie osobne warstwy, które trzeba rozpoznać oddzielnie.

Czy warto ukrywać, na czym stoi strona?

Skoro tak łatwo to sprawdzić, może lepiej wszystko pochować? Tu trochę psuję zabawę: samo ukrywanie CMS-a to bezpieczeństwo przez zaciemnienie i niewiele daje. Boty atakujące i tak strzelają standardowymi exploitami pod /wp-login.php, niezależnie od tego, czy tag generator istnieje.

Co realnie podnosi bezpieczeństwo: regularne aktualizacje rdzenia, wtyczek i motywów, porządna zapora aplikacyjna (WAF), ograniczenie dostępu do panelu i wyłączenie zbędnych usług, np. xmlrpc.php w WordPressie. Usunięcie nagłówka X-Powered-By czy tagu generator to co najwyżej wisienka na torcie, nie fundament obrony.

Metoda na sklepy internetowe i kreatory

Sklepy i kreatory mają wyjątkowo czytelne odciski palca:

• Shopify — adresy /collections/ i /products/, zasoby z cdn.shopify.com.
• WooCommerce — prefiksy wc-, ścieżka /cart/, klasy woocommerce.
• Shoper i IdoSell — charakterystyczne, stałe adresy panelu i zasobów.
• Wix — domena wixstatic.com w obrazkach i nietypowe, generowane klasy CSS.
• Webflow — atrybuty data-wf- i odwołania do domeny website-files.com (zasoby serwowane są z cdn.prod.website-files.com).

Jak to robić metodycznie (gdy sprawdzasz wiele stron)

Klikanie wtyczką na jednej stronie jest okej. Ale jeśli analizujesz dziesiątki domen, podejdź do tego jak praktyk:

1. Pobierz nagłówki hurtowo — pętla po curl -I w skrypcie bash zapisze odpowiedzi do plików.
2. Ściągnij kod źródłowy i przeszukaj go pod kątem wzorców (wp-content, shopify, drupal) komendą grep.
3. Skonfrontuj wyniki z różnych metod — dopiero gdy kilka tropów się pokrywa, masz pewność.

Jeden sygnał potrafi mylić (CDN ukrywa serwer, ktoś zostawił stary skrypt po migracji). Pewność daje dopiero krzyżowanie kilku metod.

FAQ — najczęstsze pytania

Jak najszybciej sprawdzić, czy strona jest na WordPressie?

Dopisz /wp-admin do adresu domeny. Jeśli pojawi się ekran logowania WordPressa — masz odpowiedź. Druga droga to Ctrl+U i wyszukanie frazy wp-content w kodzie. Obie metody zajmują kilka sekund.

Czy da się sprawdzić technologię strony bez instalowania wtyczek?

Tak. Wystarczy kod źródłowy (Ctrl+U), komenda curl -I w terminalu albo narzędzie online jak WhatCMS.org czy BuiltWith.com. Wtyczki są tylko wygodniejsze, nie niezbędne.

Dlaczego Wappalyzer pokazuje React, ale nie pokazuje CMS-a?

To prawdopodobnie strona headless — front zbudowany w React lub Next.js pobiera treść z osobnego silnika przez API. Front i CMS rozpoznajesz wtedy oddzielnie; poszukaj śladów typu /wp-json/, żeby znaleźć zaplecze.

Czy ukrywanie CMS-a zwiększa bezpieczeństwo strony?

Minimalnie. Większość ataków to automaty próbujące standardowych ścieżek niezależnie od tego, co ukryjesz. Dużo skuteczniejsze są aktualizacje, WAF i ograniczenie dostępu do panelu logowania.

Jak rozpoznać, na jakim serwerze działa strona?

Sprawdź nagłówki HTTP komendą curl -I https://domena.pl i szukaj linii Server: — zwykle zobaczysz tam nginx, Apache albo LiteSpeed. Jeśli jest tam tylko cloudflare, prawdziwy serwer chowa się za CDN-em.

Krzysztof Fronczak