Techniczne SEO (po angielsku technical SEO) to część pozycjonowania, która dotyczy infrastruktury strony, a nie jej tekstów ani linków z innych serwisów. Jego zadaniem jest to, żeby robot Google mógł stronę znaleźć, pobrać, wyrenderować, zrozumieć i dodać do indeksu, a użytkownik dostał ją szybko i bez błędów.

Pozycjonowanie zwykle dzieli się na trzy obszary. SEO techniczne odpowiada za fundament: kod, serwer, adresy URL, indeksację. Optymalizacja treści, czyli on-page, odpowiada za to, czy podstrona dobrze odpowiada na zapytanie. Działania poza stroną, przede wszystkim linki z portali, budują jej wiarygodność. Te obszary zależą od siebie. Świetny tekst kategorii nic nie da, jeśli kategoria ma noindex, a publikacja na portalu prowadząca do adresu z błędem 404 marnuje budżet.

W praktyce techniczne SEO to kilkanaście tematów: crawl, indeksacja, robots.txt, mapy witryny XML, adresy kanoniczne, przekierowania i statusy HTTP, hreflang, dane strukturalne, renderowanie JavaScriptu, Core Web Vitals, wersja mobilna, HTTPS i logi serwera. Poniżej opisujemy każdy z nich tak, jak sprawdzamy go w audycie technicznym SEO.

Google przetwarza stronę w trzech krokach: Googlebot odkrywa i pobiera adres (crawl), potem uruchamia kod strony, w tym JavaScript (renderowanie), a na końcu decyduje, czy dodać podstronę do indeksu i z jakim adresem kanonicznym. Błąd na każdym etapie zatrzymuje cały proces, więc audyt sprawdza je po kolei.

Robot odkrywa adresy głównie przez linki wewnętrzne i mapy witryny. Podstrona, do której nie prowadzi żaden link (tak zwana sierota), może istnieć w sitemapie, ale Google uzna ją za mało ważną. Dlatego w crawlu patrzymy na głębokość kliknięć: ile kroków dzieli stronę główną od oferty, kategorii czy produktu. Ważne podstrony powinny być blisko, a nie na piątym poziomie paginacji.

Indeksacja to osobna decyzja. Raport indeksowania stron w Google Search Console pokazuje, które adresy są w indeksie, a które nie i z jakiego powodu. Statusy „Strona zeskanowana, ale jeszcze nie zindeksowana” i „Strona wykryta, ale jeszcze nie zindeksowana” zwykle nie są błędem technicznym w ścisłym sensie, tylko sygnałem, że Google nie widzi wartości w danej podstronie albo ma do przejrzenia zbyt wiele podobnych adresów. Szerzej o tym, jak wprowadzić strony do indeksu, piszemy przy optymalizacji SEO.

• głębokość kliknięć do najważniejszych podstron
• podstrony bez linków wewnętrznych (sieroty)
• powody wykluczenia w raporcie indeksowania stron
• test adresu URL w Search Console dla wzorcowych szablonów

Plik robots.txt mówi robotom, których adresów nie pobierać, a tag meta robots lub nagłówek X-Robots-Tag mówi, czego nie dodawać do indeksu. To dwa różne narzędzia. Strona zablokowana w robots.txt może trafić do wyników bez opisu, bo Google nie zobaczy na niej tagu noindex.

Najczęstszy błąd, który widzimy, to próba usunięcia stron z Google przez Disallow w robots.txt. Działa to odwrotnie do zamierzeń: robot przestaje wchodzić na adres, więc nie odczyta noindex i nie usunie go z indeksu. Jeśli strona ma zniknąć z wyników, najpierw musi być dostępna dla robota z tagiem noindex, a dopiero potem można ją ewentualnie zablokować.

Robots.txt ma sens tam, gdzie chcemy oszczędzić robotowi pracy: wyniki wyszukiwarki wewnętrznej, koszyk, panel klienta, niekończące się kombinacje filtrów. Nie powinien blokować plików CSS i JavaScript, bo wtedy Google renderuje stronę bez stylów i skryptów i może źle ocenić jej treść oraz wersję mobilną. Nagłówek X-Robots-Tag stosujemy do plików, w których nie da się wstawić tagu, na przykład do PDF-ów z cennikami starszych lat.

W robots.txt warto też świadomie zdecydować o robotach AI, takich jak GPTBot, i o tokenie Google-Extended, który określa użycie treści przez modele Google. To osobny wybór biznesowy, który opisujemy niżej, w części o widoczności w AI.

Dobra mapa witryny XML zawiera tylko adresy, które chcesz mieć w Google: ze statusem 200, bez noindex, kanoniczne i aktualne. Jeden plik może mieć do 50 000 adresów i 50 MB, więc większe serwisy dzielą mapę na kilka plików połączonych indeksem map. Mapę zgłaszasz w Search Console i wskazujesz w robots.txt.

W audytach często znajdujemy mapy, które generuje wtyczka lub platforma i nikt ich nie sprawdzał od lat. Są w nich przekierowane adresy, strony tagów z jednym wpisem, wersje testowe, produkty wycofane z oferty i podstrony z noindex. Każdy taki adres to sprzeczny sygnał: sitemapa mówi „indeksuj”, a strona mówi „nie”.

Przy większych sklepach dzielimy mapy na typy: kategorie, produkty, wpisy, strony informacyjne. Dzięki temu w Search Console widać osobno, jaki procent produktów jest w indeksie, a jaki kategorii. Data ostatniej modyfikacji (lastmod) ma sens tylko wtedy, gdy zmienia się przy realnej zmianie treści. Jeśli każda podstrona ma dzisiejszą datę, Google przestaje ją brać pod uwagę.

Tag canonical wskazuje Google, który adres jest główną wersją treści dostępnej pod kilkoma adresami. Google traktuje go jako wskazówkę, a nie polecenie, więc canonical działa tylko wtedy, gdy inne sygnały, czyli linki wewnętrzne, sitemapa i przekierowania, wskazują ten sam adres.

Duplikaty powstają zwykle bez niczyjej wiedzy: wersja z ukośnikiem na końcu i bez niego, http i https, z www i bez, parametry sortowania i filtrów, identyfikatory kampanii w adresach, wersje do druku, produkt dostępny w kilku kategoriach pod różnymi ścieżkami. W sklepie z kilkuset produktami łatwo dojść do kilkudziesięciu tysięcy adresów, z których większość to te same treści.

Nie każdy duplikat rozwiązujemy tak samo. Wersje techniczne adresu (www, ukośnik, http) przekierowujemy 301. Sortowanie i większość filtrów dostają canonical do kategorii. Filtry, na które są wyszukiwania, na przykład kolor lub marka, czasem warto zostawić jako osobne, indeksowalne podstrony z własnym tytułem i opisem. Paginacji nie kierujemy canonicalem na pierwszą stronę, bo wtedy produkty z dalszych stron tracą drogę do indeksu.

Każdy adres w serwisie powinien odpowiadać właściwym kodem: 200 dla działającej strony, 301 dla adresu przeniesionego na stałe, 404 lub 410 dla treści usuniętej bez zamiennika. Problemy zaczynają się, gdy kody kłamią, na przykład pusta strona zwraca 200 (soft 404) albo przekierowanie prowadzi przez trzy adresy po drodze.

W crawlu sprawdzamy wszystkie linki wewnętrzne i ich statusy. Najczęściej znajdujemy łańcuchy przekierowań po kolejnych zmianach adresów, pętle, przekierowania 302 tam, gdzie zmiana jest stała, linki w menu i stopce prowadzące do 404 oraz błędy 5xx przy większym ruchu robota. Linki wewnętrzne poprawiamy tak, żeby prowadziły od razu do adresu docelowego, a nie przez przekierowanie.

Błąd 404 sam w sobie nie szkodzi stronie, jeśli dotyczy treści, której naprawdę już nie ma. Szkodzi wtedy, gdy znika produkt lub usługa z ruchem i linkami z portali, a nikt nie ustawił przekierowania na najbliższy odpowiednik. Przy dużej zmianie adresów, nowej platformie lub domenie potrzebna jest pełna mapa przekierowań, którą przygotowujemy w ramach osobnej usługi migracji strony.

Atrybut hreflang informuje Google, która wersja strony jest przeznaczona dla jakiego języka lub kraju, na przykład pl, de-AT czy en-GB. Działa tylko wtedy, gdy każda wersja wskazuje wszystkie pozostałe i siebie samą, a adresy w hreflang są kanoniczne i zwracają kod 200.

Najczęstsze błędy to brak odwołań zwrotnych (wersja polska wskazuje niemiecką, ale niemiecka nie wskazuje polskiej), błędne kody języka i kraju, hreflang prowadzący do przekierowań oraz canonical z wersji obcojęzycznej na polską. Ten ostatni przypadek sprawia, że Google ignoruje wersję językową, bo canonical mówi mu, że to tylko kopia. Wartość x-default warto ustawić dla strony wyboru języka lub wersji domyślnej.

Hreflang można wdrożyć w kodzie strony, w nagłówkach HTTP albo w mapie witryny. Przy dużych sklepach z kilkoma wersjami językowymi sitemapa jest zwykle najwygodniejsza. Sam hreflang to jednak tylko technika. Strategię wejścia na rynki, frazy w innych językach i linki z lokalnych portali opisujemy przy pozycjonowaniu zagranicznym.

Dane strukturalne to opis strony w formacie zrozumiałym dla maszyn, najczęściej JSON-LD ze słownika schema.org. Pomagają Google i asystentom AI zrozumieć, czy podstrona to produkt, firma, artykuł czy lista pytań, a przy niektórych typach dają rozszerzone wyniki, na przykład cenę i dostępność produktu.

Na stronach firmowych wdrażamy zwykle Organization lub LocalBusiness z danymi firmy, BreadcrumbList dla ścieżki nawigacji, Service dla usług i Article dla poradników. W sklepach podstawą jest Product z ofertą, ceną i dostępnością. FAQPage ma sens, gdy pytania i odpowiedzi są widoczne na stronie, choć Google pokazuje je w wynikach już tylko dla wybranych serwisów.

Zasada jest jedna: dane strukturalne muszą opisywać to, co użytkownik widzi na stronie. Ocena gwiazdkowa bez opinii na stronie, cena inna niż w koszyku albo pytania, których nie ma w treści, to prosta droga do ręcznego działania w Search Console. Każde wdrożenie sprawdzamy w teście wyników z elementami rozszerzonymi i w raportach ulepszeń w GSC.

Google potrafi renderować JavaScript, ale robi to później niż pobranie kodu i nie zawsze w całości. Jeśli opis, cena albo linki wewnętrzne pojawiają się dopiero po wykonaniu skryptów, część podstron może trafić do indeksu niepełna albo wcale. Większość robotów AI nie wykonuje JavaScriptu, a część innych wyszukiwarek robi to w ograniczonym zakresie.

Problem dotyczy głównie stron zbudowanych w React, Vue czy Angular bez renderowania po stronie serwera, sklepów headless oraz zwykłych stron, w których ważne elementy dociąga skrypt, na przykład opinie, opisy z zakładek czy menu. Sprawdzamy to, porównując kod źródłowy z kodem po renderowaniu i z tym, co pokazuje test adresu URL w Search Console.

Drugi częsty błąd to linki zrobione jako przyciski lub elementy z obsługą kliknięcia zamiast zwykłego znacznika a z atrybutem href. Robot nie kliknie w przycisk, więc nie dotrze do podstron, które prowadzą tylko z takiego menu. Rozwiązaniem jest renderowanie po stronie serwera (SSR), generowanie statycznych stron albo przynajmniej podanie najważniejszej treści i linków w pierwotnym HTML.

Core Web Vitals to trzy wskaźniki Google: LCP mierzy czas pokazania głównej treści, INP szybkość reakcji na kliknięcie, a CLS przesuwanie się elementów podczas ładowania. Dobre wartości to LCP do 2,5 s, INP do 200 ms i CLS do 0,1, liczone na danych od prawdziwych użytkowników.

W audycie technicznym SEO sprawdzamy raport Core Web Vitals w Search Console, wskazujemy, które szablony podstron mają słabe wyniki, i opisujemy główne przyczyny. Samo przyspieszanie strony, czyli obrazy, cache, CDN, skrypty zewnętrzne i hosting, to osobna, szeroka praca, którą prowadzimy jako usługę przyspieszenia strony. Wstępny pomiar zrobisz w naszym teście szybkości strony.

Google indeksuje strony na podstawie wersji mobilnej. Dlatego porównujemy wersję na telefon i na komputer: czy mają tę samą treść, te same nagłówki, linki wewnętrzne i dane strukturalne. Ukryte na telefonie opisy kategorii albo uproszczone menu bez linków do podkategorii to częsta przyczyna gorszej widoczności, mimo że na komputerze strona wygląda dobrze. Do tego dochodzi HTTPS bez mieszanej treści i poprawne przekierowanie z http.

Logi serwera zapisują każde wejście Googlebota: jaki adres pobrał, kiedy i z jakim kodem odpowiedzi. To jedyne źródło, które pokazuje, gdzie robot faktycznie spędza czas, a nie gdzie powinien. Analiza logów ma największy sens w sklepach i serwisach z dziesiątkami tysięcy adresów.

Budżet crawlowania to liczba adresów, które Google jest gotów pobrać z serwisu w danym czasie. Mała strona firmowa z kilkudziesięcioma podstronami nie musi się nim przejmować. Sklep z rozbudowanymi filtrami, który generuje setki tysięcy kombinacji adresów, często ma sytuację, w której robot krąży po parametrach, a nowe produkty czekają tygodniami na pierwszą wizytę.

W logach szukamy adresów, które robot odwiedza najczęściej, sekcji, do których nie zagląda, błędów 5xx i przekierowań, na które trafia, oraz tego, czy wejścia pochodzą od prawdziwego Googlebota. Jeśli nie masz dostępu do logów, część tych danych widać w raporcie „Statystyki indeksowania” w Search Console. Wnioski zamieniamy na konkretne zmiany: blokady w robots.txt, canonical, porządek w linkowaniu wewnętrznym i mapach witryny.

ChatGPT, Perplexity, Claude i AI Overviews korzystają z własnych robotów lub z indeksu Google. Jeśli robots.txt, zapora sieciowa albo usługa ochrony przed botami blokuje GPTBot, OAI-SearchBot, PerplexityBot czy ClaudeBot, strona nie trafi do ich odpowiedzi, nawet jeśli w Google jest wysoko.

W audycie technicznym sprawdzamy reguły robots.txt dla robotów AI, ustawienia CDN i zapory, które czasem blokują je bez wiedzy właściciela, oraz to, czy treść jest dostępna bez JavaScriptu. Roboty AI rzadko renderują skrypty, więc strona widoczna w Google może być dla nich pusta. Decyzja, którym robotom dać dostęp, należy do Ciebie, my pokazujemy skutki każdej opcji.

Do tego dochodzi plik llms.txt, który podaje modelom językowym skrót najważniejszych treści serwisu. Opisujemy go na stronie llms.txt, a szerzej o widoczności w asystentach AI piszemy przy pozycjonowaniu w AI.

W sklepie internetowym techniczne SEO dotyczy głównie skali: filtrów, sortowania, paginacji, wariantów produktów i produktów wycofanych. Sklep z kilkoma tysiącami produktów łatwo generuje wielokrotnie więcej adresów niż ma realnych podstron, a robot traci czas na kopie zamiast na nowe kategorie.

Każda platforma ma swoje typowe problemy. W PrestaShop są to często duplikaty adresów produktów w kilku kategoriach i parametry w adresach. W WooCommerce strony tagów, archiwa i atrybuty jako osobne adresy. W Shoperze i IdoSell ustawienia filtrów i stron wyników. W sklepach headless renderowanie treści po stronie przeglądarki. Dlatego przy sklepach zaczynamy od rozpoznania platformy i jej ustawień, a dopiero potem od crawla.

Osobno traktujemy produkty niedostępne. Produkt chwilowo niedostępny powinien zostać pod tym samym adresem z informacją o dostępności. Produkt wycofany na stałe przekierowujemy na następcę lub kategorię, jeśli ma ruch i linki, a w innym przypadku zostawiamy kod 404 lub 410. Szczegóły przeglądu sklepu opisujemy przy audycie SEO sklepu.

• filtry i sortowanie: canonical, noindex lub blokada
• paginacja z linkami do kolejnych stron i bez canonical na pierwszą
• warianty produktów pod jednym adresem lub z jasnym canonical
• dane strukturalne Product z ceną i dostępnością

Audyt techniczny SEO w Backlink24 to raport z błędami technicznymi strony, przykładowymi adresami, oceną wpływu i sposobem naprawy dla każdego punktu. Kosztuje od 1 229 zł brutto (999 zł netto), a przy dużych sklepach i serwisach wyceniamy go indywidualnie, zależnie od wielkości.

Podstawą jest pełny crawl serwisu i dane z Google Search Console. Jeśli masz dostęp do logów serwera, dołączamy ich analizę. Raport nie jest zrzutem ekranu z narzędzia z listą ostrzeżeń. Każdy punkt ma opis po polsku, wyjaśnienie, dlaczego to problem, liczbę adresów, których dotyczy, i zalecenie, które programista może od razu wdrożyć. Na końcu jest lista zadań ułożona według priorytetu.

Audyt techniczny to część szerszego audytu SEO, który obejmuje też treści, frazy i profil linków. Jeśli wiesz, że problem leży w technice, na przykład po spadku ruchu po wdrożeniu nowej wersji strony, możesz zamówić sam audyt techniczny. Jeśli nie wiesz, zacznij od pełnego audytu, a technikę omówimy w jego ramach.

1. 1Podsumowanie dla właściciela

   Najważniejsze problemy w kilku zdaniach, bez żargonu, z informacją, co grozi, jeśli zostaną.

2. 2Indeksacja i crawl

   Stan indeksu, powody wykluczeń, głębokość kliknięć, sieroty, robots.txt i meta robots.

3. 3Adresy i duplikaty

   Canonical, parametry, filtry, paginacja, przekierowania i statusy HTTP z listą adresów.

4. 4Kod i renderowanie

   JavaScript, wersja mobilna, dane strukturalne, hreflang i HTTPS.

5. 5Wydajność

   Core Web Vitals z Search Console i szablony podstron, które ich nie spełniają.

6. 6Lista zadań

   Zmiany ułożone według priorytetu, gotowe do przekazania programiście.

Optymalizacja techniczna strony to wdrożenie zmian z audytu: poprawa robots.txt, map witryny, canonical, przekierowań, danych strukturalnych, hreflang i ustawień platformy. W Backlink24 jednorazowa optymalizacja kosztuje od 3 690 zł brutto (3 000 zł netto), a jej zakres ustalamy po audycie.

Na popularnych systemach, takich jak WordPress, PrestaShop, WooCommerce czy Shoper, większość zmian wprowadzamy sami: ustawienia wtyczek i modułów SEO, reguły robots.txt, mapy witryny, przekierowania, dane strukturalne. Przy własnym oprogramowaniu, sklepach headless i dużych serwisach pracujemy z Twoim zespołem IT. Przekazujemy zadania z opisem problemu, przykładami adresów i kryterium odbioru, a potem sprawdzamy wdrożenie na kopii testowej i po publikacji.

Po zakończeniu prac robimy kontrolny crawl i porównujemy go z pierwszym. W Search Console prosimy o ponowne sprawdzenie poprawionych błędów i obserwujemy raport indeksowania stron. Zmiany w indeksie Google widać z opóźnieniem, bo robot musi ponownie odwiedzić adresy, dlatego wynik oceniamy na danych z kolejnych tygodni, a nie następnego dnia. Szerszy zakres, z treściami i nagłówkami, opisujemy przy optymalizacji SEO.

Audyt techniczny SEO warto zrobić przed startem pozycjonowania, po każdej większej zmianie strony (nowy szablon, platforma, domena, wersja językowa) i wtedy, gdy ruch z Google spada bez wyraźnej przyczyny. Przy dużych sklepach dobrze sprawdza się też regularna kontrola, bo błędy pojawiają się przy każdej aktualizacji.

Sygnały, że problem może być techniczny: w Search Console rośnie liczba wykluczonych adresów, nowe produkty lub wpisy długo nie pojawiają się w Google, w wynikach widać stare adresy albo wersje z parametrami, Google pokazuje inną podstronę niż ta, którą chcesz pozycjonować, a po wdrożeniu nowej wersji strony ruch spadł w ciągu kilku dni. Spadki po aktualizacjach algorytmu Google częściej mają inne przyczyny, ale technikę i tak warto wtedy wykluczyć. Takie sytuacje opisujemy przy odzyskiwaniu pozycji.

Stan techniczny strony monitoruje się w Google Search Console (raport indeksowania stron, statystyki indeksowania, Core Web Vitals, ulepszenia danych strukturalnych) oraz regularnym crawlem, który porównuje serwis z poprzednim stanem. Najwięcej błędów pojawia się po aktualizacjach systemu, wtyczek i szablonu.

W abonamencie pozycjonowania sprawdzamy technikę co miesiąc, a zmiany i nowe błędy opisujemy w raporcie. Przed większym wdrożeniem po stronie klienta, na przykład nową wersją szablonu, warto dać nam znać. Sprawdzimy kopię testową, zanim zmiana trafi na produkcję, bo naprawa po fakcie zawsze kosztuje więcej niż kontrola przed. Pomiar ruchu i konwersji w GA4 ustawiamy przy analityce GA4.