Audyt techniczny strony: TLS, przekierowania, nagłówki, DNS

Audyt techniczny strony sprawdza fundamenty: certyfikat, przekierowania, robots.txt i sitemap, nagłówki bezpieczeństwa, cache, DNS, pocztę i wycieki plików.

Infrastruktura · Opublikowano: 11 października 2026 · 5 min czytania · Анна Ковалёва

O projekcie graficznym można dyskutować, teksty można przepisać, ale warstwa techniczna albo działa, albo nie. Wygasły certyfikat, łańcuch czterech przekierowań, plik .env zostawiony w katalogu głównym czy brak rekordu DMARC nie pojawiają się w makiecie ani na przeglądzie sprintu — aż do dnia, w którym strona przestaje się otwierać, faktury trafiają do spamu, a połowa podstron wypada z indeksu. Audyt techniczny strony to kontrola właśnie tych fundamentów: wszystkiego, co dzieje się między przeglądarką, serwerem i DNS, zanim pojawi się pierwszy piksel.

Czym różni się od audytu SEO i UX

Audyt SEO pyta, czy wyszukiwarka rozumie stronę; przegląd UX — czy człowiek potrafi z niej skorzystać. Audyt techniczny strony pyta, czy którykolwiek z nich w ogóle dostaje poprawną odpowiedź: przez HTTPS, z właściwym kodem, bez objazdów, z nagłówkami blokującymi typowe ataki i z domeną, która nie wygaśnie za tydzień. Większość punktów jest zero-jedynkowa i da się je sprawdzić z zewnątrz, bez dostępu do serwera, więc łatwo je zautomatyzować. Ogólną metodę — od skanu przez zadania po ponowną weryfikację — opisujemy w tekście o audycie strony online; tutaj przechodzimy przez warstwę techniczną blok po bloku.

1. HTTPS i certyfikat

• Ważność. Alerty na 30, 14 i 7 dni przed końcem. Automatyczne odnawianie psuje się częściej, niż się wydaje: zmiana DNS, zamknięty port 80, nginx bez przeładowania. Szczegóły w artykule o terminach certyfikatu i domeny, a opis wiersza raportu — na stronie ważność certyfikatu TLS.
• Wersje protokołu. TLS 1.0 i 1.1 są wycofane; serwer powinien obsługiwać TLS 1.2 i 1.3.
• Pełny łańcuch. Bez certyfikatu pośredniego Chrome na komputerze często sobie poradzi, ale Android, curl i webhooki płatności już nie.

Z terminala:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -enddate -issuer

2. Adresy i przekierowania

Strona powinna mieć dokładnie jeden adres główny. http:// odpowiada 301 na https:// (zob. przekierowanie na HTTPS), a wariant z www lub bez — 301 na wersję główną. Każdy dodatkowy krok to kolejna podróż w sieci przed pierwszym bajtem, więc policz przekierowania do strony wejściowej: zero lub jedno jest w porządku, trzy to zadanie do zrobienia. Sprawdź też odwrotny przypadek: nieistniejący adres musi zwracać 404, a nie 200 z napisem „nie znaleziono”.

curl -sI http://example.com/ | head -3
curl -s -o /dev/null -w "%{http_code}" https://example.com/no-such-page-123

3. robots.txt i sitemap.xml

To pliki techniczne, choć od nich zależy SEO. Klasyczna awaria to Disallow: / przeniesione ze stagingu na produkcję razem z wdrożeniem. Upewnij się, że robots.txt nie blokuje strony głównej, CSS ani JavaScriptu i wskazuje mapę witryny. Sama sitemap.xml powinna być poprawnym XML-em, zawierać wyłącznie kanoniczne adresy odpowiadające 200 i nie ciągnąć URL-i ze stagingu ani z obcej domeny.

4. Nagłówki bezpieczeństwa i wycieki

Podstawa to Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options: nosniff, ochrona przed osadzaniem w ramce i Referrer-Policy; po co każdy z nich i jak wdrożyć CSP bez psucia strony, piszemy w artykule o nagłówkach bezpieczeństwa. Równie ważne jest to, czego na serwerze być nie powinno:

• pliki zostawione przez wdrożenie — .env, .git/, zrzuty bazy; boty szukają ich w ciągu kilku godzin (odsłonięte pliki);
• listowanie katalogów i opublikowane source maps;
• banery wersji w stylu Server: nginx/1.18.0 czy X-Powered-By: PHP/7.4;
• metoda TRACE, którą serwer odbija z powrotem.

5. Dostarczanie: kompresja, cache, protokół

HTML i pliki statyczne powinny wychodzić skompresowane (gzip, najlepiej Brotli) przez HTTP/2 lub HTTP/3. Pliki z hashem w nazwie dostają Cache-Control: public, max-age=31536000, immutable, a sam HTML — krótki czas życia albo no-cache z ETag, by powrót kosztował tylko odpowiedź 304. Rozsądny cel dla serwera to pierwszy bajt poniżej 800 ms.

6. DNS, domena i poczta

Co najmniej dwa serwery nazw, włączona blokada transferu i automatyczne odnawianie domeny. Dla poczty: jeden rekord SPF w limicie dziesięciu zapytań DNS, DKIM oraz DMARC — najpierw p=none z adresem do raportów, potem quarantine. CAA, DNSSEC i MTA-STS są opcjonalne, ale warte wdrożenia.

dig +short TXT example.com
dig +short TXT _dmarc.example.com

Audyt techniczny z SiteScan

1. Uruchom bezpłatny skan na stronie głównej: wpisz domenę, a raport pojawi się po minucie lub dwóch.
2. Otwórz bloki „Certyfikat TLS”, „Rejestracja domeny”, „Adresy i przekierowania”, „Indeksowanie”, „Nagłówki bezpieczeństwa” oraz „DNS i poczta”. Każdy wiersz ma przycisk z objaśnieniem, który prowadzi do centrum pomocy.
3. Kliknij „Kopiuj specyfikację”: ustalenia krytyczne, wysokie i średnie trafią do schowka jako lista zadań dla programisty — z adresami i kryterium akceptacji.
4. Po poprawkach zeskanuj stronę ponownie. Sekcja „Co się zmieniło od ostatniego skanowania” pokaże, co naprawiono, co doszło i co zostało.
5. Terminów nie trzymaj w głowie: „Monitoruj tę witrynę” dodaje domenę do regularnych kontroli, a powiadomienia przychodzą e-mailem, przez Telegram lub SMS.