SEO techniczne obejmuje sposób, w jaki wyszukiwarka odkrywa, pobiera, renderuje i indeksuje strony. Jego celem jest zapewnienie, że ważne treści są dostępne pod właściwymi adresami i mogą zostać prawidłowo zinterpretowane.
Nie każdy komunikat z crawlera jest problemem wymagającym naprawy. Poprawna strona 404 może być lepsza niż nietrafne przekierowanie. Adres z noindex może być celowo wyłączony z wyników. Znaczenie błędu zależy od funkcji URL-a, skali oraz skutków biznesowych.
Skanowanie i indeksowanie to różne etapy
Google może pobrać stronę, ale jej nie zaindeksować. Może również znać adres, do którego chwilowo nie wraca. Dlatego informacja „Google wykrył URL” nie oznacza, że materiał może już pojawić się w wynikach.
Podczas diagnozy trzeba ustalić:
- czy robot może dotrzeć do adresu przez link,
- jaki kod odpowiedzi zwraca serwer,
- czy robots.txt pozwala pobrać potrzebne zasoby,
- czy strona ma dyrektywę index czy noindex,
- jaki canonical wskazuje witryna,
- jaki adres kanoniczny wybrało Google,
- czy treść jest widoczna po renderowaniu,
- czy materiał różni się od innych zaindeksowanych stron.
Samo ponowne zgłoszenie URL-a do indeksowania nie usuwa przyczyny. Najpierw trzeba poprawić stronę albo strukturę, a dopiero później poprosić o ponowne sprawdzenie.
Kody odpowiedzi i ich znaczenie
200
Kod 200 oznacza prawidłową odpowiedź serwera, ale nie gwarantuje dobrej strony. Adres może zwracać 200 i jednocześnie zawierać pustą treść, komunikat błędu albo canonical prowadzący gdzie indziej.
301 i 308
Służą do trwałego przekierowania. Powinny prowadzić możliwie bezpośrednio do trafnego adresu docelowego. Łańcuchy zwiększają liczbę żądań i utrudniają późniejsze zarządzanie serwisem.
302 i 307
Informują o przekierowaniu tymczasowym. Mają zastosowanie, gdy zmiana rzeczywiście nie jest stała. Nie powinny być wybierane tylko dlatego, że tak skonfigurowano domyślną regułę wtyczki.
404 i 410
Informują, że zasobu nie ma. Są prawidłowe dla usuniętych adresów bez odpowiednika. Problem pojawia się wtedy, gdy błąd dotyczy strony nadal linkowanej z menu, materiału z ruchem lub produktu mającego bezpośredniego następcę.
5xx
Wskazują problem po stronie serwera. Pojedynczy incydent należy odróżnić od powtarzalnej niedostępności ważnych szablonów.
Canonical nie jest przekierowaniem
Element rel="canonical" wskazuje preferowany adres dla podobnych treści. Użytkownik nadal może otworzyć wersję niekanoniczną. Przekierowanie natomiast przenosi go pod inny URL.
Problemy pojawiają się, gdy:
- canonical prowadzi do błędu lub przekierowania,
- strona wskazuje jako kanoniczny niepowiązany adres,
- mapa XML zawiera wersje niekanoniczne,
- linkowanie wewnętrzne promuje inny URL niż canonical,
- warianty językowe albo produktowe zostały połączone bez analizy ich treści.
Szczegóły działania mechanizmu opisuję w poradniku o adresach kanonicznych.
Mapa witryny XML nie zastępuje linkowania
Mapa XML pomaga wskazać ważne adresy, ale nie gwarantuje ich indeksowania. Powinna zawierać aktualne, indeksowalne i kanoniczne URL-e zwracające kod 200.
Nie należy umieszczać w niej:
- błędów 404,
- przekierowań,
- stron z noindex,
- duplikatów z parametrami,
- adresów wskazujących canonical do innej strony.
Jeżeli ważny produkt znajduje się wyłącznie w mapie, a nie prowadzi do niego żaden link z kategorii, problemem jest również architektura sklepu.
Robots.txt i noindex pełnią inne funkcje
Plik robots.txt kontroluje możliwość pobierania zasobów przez określone roboty. Dyrektywa noindex informuje, że strona nie powinna znajdować się w indeksie. Jeśli robot nie może pobrać adresu, może nie zobaczyć dyrektywy znajdującej się w kodzie strony.
Robots.txt nie jest zabezpieczeniem poufnych danych. Wersje testowe, panele i dokumenty wymagające ochrony powinny korzystać z mechanizmów kontroli dostępu.
Renderowanie JavaScript
Interfejs może działać poprawnie dla użytkownika, a jednocześnie utrudniać pobranie treści lub linków. Szczególną kontrolę wymagają:
- menu tworzone wyłącznie po wykonaniu skryptu,
- linki bez prawidłowego atrybutu href,
- produkty doładowywane podczas przewijania,
- treści dostępne dopiero po interakcji,
- tytuły i canonicale zmieniane po stronie przeglądarki,
- błędy API pozostawiające pusty szablon.
Narzędzie kontroli adresu URL w Search Console pozwala porównać pobraną stronę i wyrenderowany kod. W większym serwisie trzeba dodatkowo sprawdzić reprezentatywne szablony, a nie tylko stronę główną.
Architektura i linki wewnętrzne
Techniczna struktura powinna prowadzić od strony głównej i sekcji nadrzędnych do ważnych ofert, kategorii oraz produktów. Problemy stanowią między innymi:
- osierocone strony,
- linki prowadzące przez kilka przekierowań,
- nawigacja zależna wyłącznie od wyszukiwarki wewnętrznej,
- niekontrolowane filtry tworzące tysiące kombinacji,
- paginacja, która nie zapewnia dostępu do dalszych elementów,
- duplikaty tworzone przez wielkie litery, ukośniki albo parametry.
Proces porządkowania połączeń omawiam w artykule o linkowaniu wewnętrznym.
Wydajność i wersja mobilna
Wydajność wpływa na korzystanie ze strony, ale wynik testu nie powinien być analizowany bez kontekstu. Najpierw trzeba sprawdzić szablony generujące ruch i konwersje, a następnie ustalić źródło problemu.
Może nim być duży obraz główny, kod zewnętrznej integracji, blokujący skrypt, rozbudowany DOM albo niestabilny układ. Szczegółowy proces opisuję w poradniku o Core Web Vitals.
Dane uporządkowane
Dane uporządkowane pomagają jednoznacznie opisać typ zawartości, np. produkt, firmę, artykuł lub breadcrumbs. Muszą odpowiadać informacjom widocznym dla użytkownika.
Poprawny technicznie kod nie gwarantuje rozszerzonego wyniku. Błędne jest również dodawanie oznaczeń dla treści, której faktycznie nie ma na stronie.
Jak wykonać techniczny audyt SEO?
Podstawowy zestaw źródeł obejmuje:
- crawl serwisu,
- Google Search Console,
- mapy XML i robots.txt,
- logi serwera, jeśli skala uzasadnia ich analizę,
- narzędzia do pomiaru wydajności,
- kod i wyrenderowaną wersję strony,
- listę adresów z CMS, analityki oraz kampanii.
Zestawienie źródeł wykrywa różnice. Adres obecny w CMS i analityce, ale nieznaleziony podczas crawlu może być osierocony. URL widoczny w GSC, lecz nieobecny w aktualnej strukturze może pochodzić ze starej wersji serwisu.
Jak ustalać priorytety?
Każdy problem oceniam według pięciu pytań:
- Czy dotyczy strony ważnej dla sprzedaży?
- Ilu adresów lub szablonów dotyczy?
- Czy dane potwierdzają wpływ na pobieranie, indeksowanie lub użytkowników?
- Jakiego nakładu i kompetencji wymaga naprawa?
- Jakie ryzyko wiąże się z wdrożeniem?
Przypadkowe noindex na stronach usługowych ma wyższy priorytet niż kosmetyczne ostrzeżenie dotyczące archiwalnego tagu. Zmiana jednego szablonu może być ważniejsza niż ręczna edycja stu meta descriptions.
Jak odebrać wdrożenie?
Zadanie nie kończy się po informacji programisty, że zmiana została opublikowana. Trzeba sprawdzić:
- kod odpowiedzi,
- robots i canonical,
- renderowanie treści oraz linków,
- działanie formularza lub koszyka,
- mapę XML,
- reprezentatywne adresy z każdego zmienionego szablonu.
Dopiero po potwierdzeniu technicznym można obserwować ponowne pobieranie i przetwarzanie stron przez Google. Datę wdrożenia warto zapisać, aby później porównać właściwe okresy.
SEO techniczne w praktyce
Techniczny zakres stanowi część audytu SEO. Po diagnozie przygotowuję listę zadań, ich priorytety i kryteria odbioru. Mogę również zweryfikować wdrożenia w ramach optymalizacji strony.
Jeżeli serwis ma problemy z indeksowaniem, migracją albo powtarzalnymi błędami szablonu, prześlij adres na czesc@seomariusz.pl lub zadzwoń pod numer 665 015 610. Do zgłoszenia warto dołączyć datę wystąpienia problemu i przykładowe URL-e.