Techniczne podstawy widoczności w Google
Strona musi być dostępna, poprawnie wyrenderowana i jednoznaczna. Sprawdzam statusy HTTP, łańcuchy przekierowań, canonicale, mapy XML, dyrektywy robots, wersje językowe, paginację oraz strukturę adresów. Analizuję, czy serwer zwraca prawidłową zawartość robotom i użytkownikom, czy zasoby niezbędne do renderowania nie są blokowane oraz czy ważne informacje znajdują się w kodzie HTML. W serwisach opartych na JavaScript oceniam, co jest dostępne bez wykonania skryptów i jak opóźnione renderowanie wpływa na odkrywanie linków, treści oraz danych strukturalnych.
Dużą uwagę poświęcam spójności sygnałów. Jeżeli mapa XML wskazuje adres A, canonical prowadzi do adresu B, linkowanie wewnętrzne używa wariantu C, a przekierowanie kończy się na D, Google otrzymuje sprzeczne informacje. Podobne problemy powstają przez mieszanie protokołów, subdomen, końcowych ukośników, wielkości liter i parametrów. Uporządkowanie tych elementów zmniejsza duplikację, ogranicza niepotrzebne skanowanie i pozwala skupić sygnały na właściwych adresach. To praca niewidoczna na pierwszy rzut oka, ale często decydująca dla stabilności całego serwisu.
- statusy HTTP i przekierowania
- canonical, robots i mapy XML
- SSR, JavaScript i renderowanie
- hreflang i wersje językowe
- dane strukturalne i semantyka HTML
Logi serwera i crawl budget bez mitów
Logi pokazują, które adresy roboty faktycznie odwiedzają, jak często wracają i jakie odpowiedzi otrzymują. Pozwalają wykryć nadmierne skanowanie filtrów, parametrów, błędów 404, zasobów technicznych lub starych adresów po migracji. Można też sprawdzić, czy najważniejsze kategorie i produkty są regularnie odwiedzane oraz czy wdrożone zmiany wpłynęły na zachowanie Googlebota. Analiza jest szczególnie cenna w dużych sklepach, portalach, katalogach i serwisach z rozbudowaną nawigacją fasetową, gdzie zwykły crawler nie odtwarza całego obrazu ruchu robotów.
Nie traktuję crawl budgetu jako uniwersalnego wyjaśnienia każdego problemu. W małym serwisie ważniejsze może być brak linkowania, słaba treść albo sprzeczny canonical. W dużym serwisie miliony bezwartościowych kombinacji filtrów mogą jednak realnie utrudniać odkrywanie zmian. Dlatego dane z logów łączę ze strukturą strony, mapami XML, indeksem Google i wartością biznesową poszczególnych sekcji. Dopiero takie zestawienie pozwala zdecydować, czy adresy należy blokować, usuwać, przekierować, oznaczyć canonicalem, pozostawić dostępne bez indeksacji albo przebudować mechanizm ich generowania.
Wydajność i Core Web Vitals w praktyce
Szybkość strony zależy od serwera, szablonu, sposobu ładowania CSS i JavaScriptu, obrazów, fontów, skryptów zewnętrznych oraz cache. Nie optymalizuję wyłącznie wyniku pojedynczego testu. Sprawdzam dane terenowe, urządzenia użytkowników i elementy odpowiadające za LCP, INP oraz CLS. Priorytetem jest usunięcie przyczyn: ciężkiego obrazu hero, blokujących zasobów, długich zadań JavaScript, niestabilnych wymiarów modułów, nadmiaru wtyczek albo niewłaściwej konfiguracji cache. Strona ma działać szybciej dla użytkownika, a nie tylko przez chwilę wyglądać lepiej w raporcie.
Zalecenia uwzględniają możliwości technologii i ryzyko biznesowe. Czasem warto przebudować komponent, czasem wystarczy zmienić kolejność ładowania, ustawić wymiary obrazów, ograniczyć skrypt lub poprawić nagłówki cache. W WordPressie analizuję wpływ motywu, wtyczek i bazy danych. W rozwiązaniach własnych współpracuję bezpośrednio z programistami. Po wdrożeniu wykonuję ponowną kontrolę, ponieważ optymalizacja techniczna jest skuteczna dopiero wtedy, gdy poprawa pozostaje stabilna i nie psuje analityki, formularzy, dostępności ani działania kluczowych funkcji serwisu.
Diagnoza techniczna zamiast automatycznej checklisty
Analiza SEO technicznego obejmuje kod HTML, odpowiedzi serwera, sposób renderowania JavaScriptu, indeksowalność zasobów, canonicale, przekierowania i architekturę adresów. Sprawdzam także, czy robot otrzymuje tę samą istotną treść, którą widzi użytkownik, oraz czy elementy szablonu nie tworzą masowo słabych lub powielonych stron.
Raporty z crawlerów traktuję jako źródło sygnałów, a nie gotową diagnozę. Błąd 404 może być prawidłowym zakończeniem usuniętego adresu, a strona wyłączona z indeksu może pełnić potrzebną funkcję dla użytkownika. Znaczenie ma kontekst całego serwisu i cel konkretnego typu adresu.
Logi, wydajność i renderowanie
W dużych serwisach logi pokazują, które sekcje Googlebot odwiedza często, gdzie traci budżet indeksowania i jak reaguje na błędy serwera. Dane te łączę z analizą czasu odpowiedzi, cache, zasobów blokujących renderowanie i Core Web Vitals. Pozwala to oddzielić problem przeglądarki użytkownika od problemu robota lub infrastruktury.
Przy witrynach JavaScriptowych sprawdzam HTML początkowy, wynik renderowania oraz dostępność linków i treści bez interakcji. Zalecenia uwzględniają używaną technologię, dlatego rozwiązanie dla WordPressa, sklepu SaaS i aplikacji React nie jest kopiowane z jednego schematu.
Bezpieczne wdrażanie zmian technicznych
Zmiany grupuję według zależności i ryzyka. Przed migracją przygotowuje się mapę adresów i testy przekierowań, przed zmianą canonicali sprawdza się warianty indeksowane, a przed modyfikacją cache określa zasoby, które muszą aktualizować się natychmiast. Takie podejście ogranicza ryzyko utraty ruchu podczas wdrożenia.
Po publikacji weryfikuję odpowiedzi serwera, kod wygenerowanych stron, wersję mobilną i reprezentatywną próbę adresów. Dzięki temu potwierdzenie wdrożenia opiera się na rzeczywistym działaniu serwisu, a nie wyłącznie na informacji, że zmiana została wprowadzona w panelu lub repozytorium.
Dla jakich serwisów SEO techniczne jest szczególnie ważne?
Największe znaczenie ma w sklepach z filtrami, portalach publikujących wiele materiałów, witrynach po migracji oraz aplikacjach generujących treść za pomocą JavaScriptu. Im więcej typów adresów, parametrów i zależności pomiędzy szablonami, tym większe ryzyko, że robot będzie pobierał niewłaściwe strony albo nie dotrze do ważnej zawartości.
Mała strona również może mieć krytyczny błąd techniczny: przypadkowy noindex, błędną domenę kanoniczną, pętlę przekierowań lub treść niedostępną bez skryptu. Zakres analizy powinien być jednak proporcjonalny. Nie ma sensu wdrażać rozwiązań przeznaczonych dla milionów adresów, jeżeli serwis składa się z kilkunastu stabilnych podstron.
Dobre SEO techniczne tworzy przewidywalne zasady rozwoju. Nowa kategoria, artykuł lub wersja językowa powinna automatycznie otrzymać poprawne meta dane, canonical, miejsce w nawigacji i mapie XML. Dzięki temu widoczność nie zależy od ręcznego naprawiania każdego adresu po publikacji.
Bezpośrednia współpraca z Robertem Wiertelem
Od pierwszej analizy do kontroli wdrożenia współpracujesz bezpośrednio ze mną. Nie przekazuję projektu handlowcowi ani przypadkowemu wykonawcy. Osobiście poznaję historię strony, sprawdzam dane, przygotowuję zalecenia i omawiam je z osobami odpowiedzialnymi za serwis. Dzięki temu decyzje techniczne pozostają powiązane z celem biznesowym.
Stronami internetowymi zajmuję się od 1998 roku. Pracowałem przy małych witrynach usługowych, sklepach, portalach, finansach i rozwiązaniach SaaS, między innymi dla Wirtualnej Polski, Ceneo, Comperii i LiveChat. Doświadczenie wykorzystuję do dopasowania rozwiązania do skali projektu, zamiast przenosić kosztowne procedury dużego portalu na niewielką stronę firmy.
Pytania o usługę
Najczęściej zadawane pytania
Czy SEO techniczne jest potrzebne małej stronie?
Tak, choć zakres powinien być proporcjonalny. Niewielka strona zwykle nie wymaga analizy milionów adresów, ale nadal potrzebuje poprawnej indeksacji, przekierowań, wydajności i struktury.
Czy pracujesz z programistami klienta?
Tak. Mogę przygotować zalecenia techniczne, omówić je z zespołem, odpowiedzieć na pytania wdrożeniowe i sprawdzić efekt po publikacji.
Czy analizujesz logi serwera?
Tak. Analiza logów jest szczególnie przydatna w dużych serwisach, po migracjach i przy problemach z odkrywaniem lub indeksowaniem ważnych adresów.