Strona internetowa może mieć piękny design, zielone kółko we wtyczce SEO, a mimo to tracić ludzi, zanim załaduje się główna treść. Google może też indeksować inny adres URL niż ten, którego oczekujesz. Zamówienie może działać, ale pomiar wysyłać je dwukrotnie.
Dlatego audytu technicznego nie zaczynam od pogoni za wynikiem stu punktów w jednym teście. Najpierw szukam błędów, które uniemożliwiają prowadzenie biznesu, indeksowanie lub korzystanie ze strony. Dopiero potem dopracowuję szczegóły.
1. Sprawdź, czy ważne adresy URL zwracają właściwy status
Sprawdź główne strony usług, artykuły generujące ruch, stronę kontaktową i ścieżkę konwersji. Ważna strona powinna zwracać 200. Treść przeniesiona na stałe powinna mieć jedno bezpośrednie przekierowanie 301. Usunięta strona nie powinna po cichu kończyć na stronie głównej.
Sprawdzam też warianty HTTP i HTTPS, www i bez www, końcowe ukośniki oraz parametry. Wynikiem powinien być jeden kanoniczny adres URL. Google opisuje przekierowanie jako silny sygnał kanonikalizacji i zaleca łączenie go ze spójnym adresem kanonicznym oraz mapą witryny w dokumentacji dotyczącej kanonicznych adresów URL.
2. Sprawdź indeksowanie z perspektywy rzeczywistej strony
Robots.txt, meta robots, adres kanoniczny i mapa witryny muszą działać razem. Częstym błędem jest indeksowanie strony, która nie powinna pojawiać się w wyszukiwarce, przy jednoczesnym blokowaniu ważnych treści. Użyj inspekcji adresu URL w Search Console na kilku reprezentatywnych adresach. Zobaczysz, co Google wie o stronie, i przetestujesz jej bieżącą wersję.
- Czy kanoniczny adres URL jest tym, którego chcesz?
- Czy strona jest dostępna bez logowania i blokad?
- Czy mapa witryny zawiera tylko indeksowalne adresy URL zwracające status 200?
- Czy linki wewnętrzne omijają przekierowania?
- Czy ważne strony nie są osierocone?
Google przedstawia przegląd tych obszarów w swojej dokumentacji dotyczącej przeszukiwania i indeksowania.
3. Mierz szybkość u ludzi, nie tylko w laboratorium
PageSpeed Insights i Lighthouse to przydatne narzędzia diagnostyczne. Test laboratoryjny nie jest jednak tym samym co doświadczenie rzeczywistych odwiedzających. Obecne Core Web Vitals to LCP, INP i CLS; dane terenowe działają na rzeczywistych urządzeniach i połączeniach. Oficjalna dokumentacja Web Vitals wyjaśnia przegląd oraz różnicę między danymi terenowymi i laboratoryjnymi.
Priorytety czytałbym tak:
- LCP: kiedy pojawia się główna treść.
- INP: jak szybko strona reaguje na działania.
- CLS: czy elementy przeskakują podczas ładowania.
- TTFB i sieć: czy w ogóle coś zaczyna się szybko dziać.
Google wyraźnie mówi też, że dobry wynik nie gwarantuje wysokich pozycji. Ogólna użyteczność ma większe znaczenie niż pogoń za jedną liczbą. Zobacz dokumentację dotyczącą jakości strony.
4. Znajdź prawdziwego winowajcę ładowania
Na wykresie wodospadowym i w DevTools szukaj długiego czasu odpowiedzi serwera, blokujących CSS i JavaScriptu, zbyt dużych obrazów, fontów, powtarzających się żądań oraz usług zewnętrznych. Stara zasada „połącz wszystkie pliki” nie jest już uniwersalna. Przy nowoczesnych protokołach większe znaczenie może mieć zakres nieużywanego kodu i blokowanie głównego wątku.
- Załaduj główny obraz w odpowiednim rozmiarze i nowoczesnym formacie.
- Ustaw wymiary obrazów, aby nie przesuwały treści.
- Treści poniżej pierwszego widoku mogą korzystać z natywnego leniwego ładowania.
- Ładuj tylko wymagane grubości fontów i zestawy znaków.
- Ładuj skrypty marketingowe asynchronicznie i tylko tam, gdzie są potrzebne.
- Kompresuj zasoby tekstowe i ustaw długi czas pamięci podręcznej dla wersjonowanych plików.
Usługa zewnętrzna kosztuje nie tylko milisekundy. Każdy piksel, widget czatu i mapa cieplna tworzą dodatkową odpowiedzialność operacyjną i za dane. Jeśli nikt nie korzysta z raportu, usuń skrypt.
5. Przejdź przez stronę jak klient, używając klawiatury i telefonu komórkowego
Na telefonie przejdź przez nawigację, formularz, okno dialogowe dotyczące plików cookie i zamówienie. Powiększ tekst, wyłącz obrazy, użyj klawiatury. Nagłówki powinny tworzyć zrozumiałą strukturę, formularz potrzebuje etykiet, a komunikat błędu musi mówić, co należy poprawić.
Każda strona powinna mieć główne zadanie. Nie oznacza to jednego przycisku za wszelką cenę, lecz czytelną hierarchię. Więcej praktycznych punktów znajdziesz w podstawowej checkliście UX.
6. Napraw błędy zasobów i JavaScriptu
404 obrazu, fontu lub skryptu nie jest błahostką. Może zepsuć wygląd, pomiar albo działanie. Sprawdź błędy w konsoli przeglądarki, nieudane żądania sieciowe i powtarzające się odpowiedzi 5xx serwera. Po każdym wdrożeniu przetestuj krytyczne ścieżki.
7. Używaj danych strukturalnych wyłącznie dla prawdziwych treści
Schema nie służy do wymuszania ocen w gwiazdkach. To czytelny dla maszyn opis tego, co rzeczywiście znajduje się na stronie. Użyj obsługiwanego typu i przetestuj go w Rich Results Test. Google wymienia aktualnie obsługiwane formaty i narzędzia testowe w swojej dokumentacji dotyczącej danych strukturalnych.
8. Pomiar nie może psuć strony, którą ma mierzyć
Ładuj GA4, platformy reklamowe i inne skrypty w sposób nieblokujący. Nazywaj zdarzenia na podstawie decyzji, a nie każdego kliknięcia. Sprawdzaj duplikaty, zgodę i to, czy ktoś rzeczywiście korzysta z danych. Praktyczne podstawy znajdziesz w artykułach o Google Tag Managerze i Google Analytics 4.
9. Pieniądze i ryzyko wyznaczają kolejność napraw
- Niedziałające zamówienie, formularz lub logowanie.
- Niedostępna lub nieindeksowalna ważna strona.
- Problem z bezpieczeństwem i przestarzałe komponenty.
- Poważne problemy z użytecznością mobilną i Core Web Vitals.
- Błędy pomiaru prowadzące do złych decyzji.
- Dopiero potem drobne wyniki i problemy kosmetyczne.
Techniczne SEO to linia startu. Samo nie wygrywa wyścigu, ale zepsuta strona może go przegrać, zanim padnie sygnał startu. Jeśli potrzebujesz przełożyć ustalenia techniczne na priorytety biznesowe, możesz opisać stronę i decyzję, przed którą stoisz.