Co to jest techniczne SEO i jak zoptymalizować stronę?

Techniczne SEO decyduje, czy Google w ogóle zobaczy Twoją treść

Techniczne SEO to zbiór działań dotyczących infrastruktury strony – nie treści i nie linków zewnętrznych, ale architektury oraz sposobu, w jaki serwis komunikuje się z robotami wyszukiwarek. Jego zadanie jest proste: umożliwić Googlebotowi dotarcie do każdej podstrony, poprawne jej wyrenderowanie i zrozumienie kontekstu.

To rozróżnienie ma praktyczne konsekwencje. Content odpowiada na pytanie, co mówi strona. Link building buduje jej autorytet. Techniczne SEO sprawia, że Google w ogóle może ją ocenić. Można mieć artykuł idealnie dopasowany do intencji i nie rankować, bo plik robots.txt blokuje katalog, canonical wskazuje na wersję staging, a treść generuje się dopiero po wykonaniu JavaScriptu.

Kolejność ma znaczenie. Optymalizacja treści i linki działają dopiero na fundamencie, który przepuszcza roboty. Odwrotnie to nie działa. Jeśli te trzy filary układają Ci się w głowie w jedną całość, warto cofnąć się o krok i sprawdzić, czym właściwie jest SEO i z czego się składa.

Jak sprawdzić stan techniczny strony w Google Search Console i PageSpeed Insights?

Nie potrzebujesz pełnego audytu, żeby znaleźć najpoważniejsze problemy. Cztery kroki poniżej zwykle wystarczą, żeby wiedzieć, czy masz do czynienia z awarią, czy z kosmetyką.

• Google Search Console → Indeksowanie → Strony. Sprawdź, ile adresów jest w indeksie, a ile zostało odrzuconych i z jakiego powodu. Wzrost kategorii „Wykluczone” po wdrożeniu to najczęstszy sygnał alarmowy.

• PageSpeed Insights. Przetestuj po jednym URL z każdego typu podstrony – nie tylko stronę główną. Patrz na dane terenowe (Field Data), bo to rzeczywiste doświadczenie użytkowników, a nie symulacja.

• Plik robots.txt. Otwórz twojadomena.pl/robots.txt i przeczytaj go linijka po linijce. Po migracjach potrafi tam zostać Disallow: / ze środowiska testowego.

• Screaming Frog (bezpłatnie do 500 adresów URL). Przeskanuj witrynę i sprawdź błędy 404, łańcuchy przekierowań oraz zduplikowane meta title.

Do tego dochodzi narzędzie „Sprawdź adres URL” w Search Console, które pokaże wyrenderowaną wersję strony. To najbliższe temu, co widzi robot. Cały zestaw do samodzielnej analizy technicznego SEO zmieści się w darmowych narzędziach SEO – płatne crawlery przydają się dopiero przy większych serwisach.

Dlaczego Google nie indeksuje części Twoich podstron?

Brak indeksacji rzadko oznacza karę. Zwykle to jedna z czterech przyczyn: blokada techniczna, duplikacja, brak ścieżki dotarcia albo niska ocena wartości strony. Raport „Strony” w GSC podaje powód wprost – warto go przeczytać dosłownie, zanim zaczniesz zgadywać.

Typowy scenariusz w sklepie: kategoria istnieje, ma treść i produkty, ale prowadzi do niej jeden link z czwartej strony paginacji. Google odkrywa ją wolno i traktuje jako mało istotną. Drugi scenariusz: strona jest dostępna pod czterema wariantami adresu (z www i bez, http i https), więc wyszukiwarka widzi cztery kopie i indeksuje tę, którą sama uzna za główną. Jeśli problem dotyczy całego serwisu, a nie pojedynczych adresów, przyczyn bywa więcej niż techniczne – zebrałem je w osobnym materiale o tym, dlaczego strona nie jest widoczna w Google.

Plik robots.txt, meta robots i tag kanoniczny – co naprawdę robi każdy z nich

Te trzy mechanizmy są nagminnie mylone, a każdy robi coś innego. Pomylenie ich to najczęstsza przyczyna sytuacji, w której strona „ma noindex, a mimo to jest w Google” albo odwrotnie.

Mechanizm	Komunikat dla robota	Typowy błąd
robots.txt	„Nie skanuj tego adresu”	Blokowanie plików CSS i JS, przez co robot nie widzi strony tak jak użytkownik
meta robots / nagłówek X-Robots-Tag	„Nie umieszczaj tego w indeksie”	Zostawiony noindex na produkcji po wdrożeniu nowej wersji serwisu
rel=”canonical”	„To jest kopia – oryginał jest tutaj”	Tag kanoniczny wskazujący na stronę główną lub na środowisko testowe

Kluczowa zależność: strona zablokowana w robots.txt nie zostanie przeskanowana, więc Google nigdy nie odczyta z niej dyrektywy noindex. Jeśli chcesz coś usunąć z indeksu, potrzebujesz meta robots i dostępu robota do tej strony.

Mapa strony XML i linkowanie wewnętrzne, czyli jak doprowadzić roboty do ważnych stron

Mapa strony XML pomaga w odkrywaniu adresów, ale niczego nie gwarantuje. To spis treści, nie przepustka. Jeśli URL jest w sitemapie, a mimo to nie trafia do indeksu, przyczyna leży gdzie indziej – w blokadzie, duplikacji lub ocenie jakości.

Realną pracę wykonuje linkowanie wewnętrzne. Ono decyduje o dwóch rzeczach: czy robot dotrze do strony i jak wysoko oceni jej ważność w hierarchii serwisu. Strona podlinkowana z głównej nawigacji i kilku powiązanych artykułów jest traktowana zupełnie inaczej niż ta zakopana na czwartym poziomie.

• Zgłoś mapę strony w GSC. Google znajdzie ją sam, ale nie ma powodu liczyć na przypadek – to dwa kliknięcia.

• Wyeliminuj strony sieroty. To adresy bez żadnego linku wewnętrznego. Screaming Frog porównany z sitemapą pokaże je od ręki.

• Spłaszcz strukturę. Ważne podstrony powinny być w zasięgu trzech kliknięć od strony głównej.

• Zadbaj o nawigację i breadcrumbs. Sam układ menu strony internetowej przenosi więcej sygnałów, niż się wydaje – i jednocześnie mówi użytkownikowi, gdzie jest.

Crawl budget – kiedy Google marnuje zasoby na Twoje nieistotne adresy URL

Crawl budget to pula zasobów, jaką Google przeznacza na skanowanie Twojej witryny. Dla strony wizytówkowej z trzydziestoma podstronami to problem teoretyczny. Dla sklepu z filtrami – jak najbardziej realny.

Mechanizm jest prosty. Każda kombinacja filtrów (kolor, rozmiar, cena, producent) generuje osobny adres URL. Przy kilkuset produktach i kilku filtrach powstają tysiące adresów z niemal identyczną treścią. Robot przegląda je zamiast nowych kart produktowych. Efekt: świeże produkty wchodzą do indeksu tygodniami.

Wyjątkiem są filtry celowo zaprojektowane pod indeksację, na przykład osobne strony dla wariantów kolorystycznych o realnym potencjale wyszukiwania. To jednak świadoma decyzja strategiczna, a nie efekt uboczny działania szablonu.

Przyjazne adresy URL i struktura strony, którą rozumieją użytkownicy i roboty

Dobry adres URL opisuje zawartość i odzwierciedla hierarchię serwisu. Porównaj: domena.pl/blog/techniczne-seo/ kontra domena.pl/index.php?id=1247&cat=3. Pierwszy niesie informację dla robota i użytkownika, drugi tylko dla bazy danych.

Zasady optymalizacji adresów URL są mało kontrowersyjne: małe litery, myślniki zamiast podkreśleń, brak polskich znaków i znaków specjalnych, sensowna długość, fraza w adresie. Znacznie ważniejsza jest jednak inna zasada.

Nie zmieniaj istniejących adresów bez powodu. Każda zmiana wymaga przekierowania 301, a każde przekierowanie to strata części sygnałów i ryzyko błędu. Powyższe wytyczne dotyczą projektowania nowych struktur, nie porządkowania starych na siłę. Dobrze zaplanowana struktura strony internetowej oszczędza większość takich decyzji na starcie.

Core Web Vitals – jakie progi musi spełnić szybkość ładowania strony

Core Web Vitals to trzy wskaźniki mierzące realne doświadczenie użytkownika podczas ładowania. Google podaje dla nich konkretne progi:

Wskaźnik	Co mierzy	Próg „dobry”
LCP	Czas wyświetlenia największego elementu (zwykle grafiki hero lub nagłówka)	do 2,5 s
INP	Czas reakcji strony na interakcję użytkownika	do 200 ms
CLS	Przesuwanie się elementów podczas ładowania	do 0,1

Dwie rzeczy, o których łatwo zapomnieć. Po pierwsze, progi obowiązują na każdym typie podstrony, nie tylko na stronie głównej – a ta jest zwykle najlżejsza i najbardziej zadbana. Problemy zaczynają się na kategoriach z dziesiątkami miniatur i na starych wpisach blogowych. Po drugie, przyspieszenie strony o ułamek sekundy nie przełoży się na skok pozycji. Wolna witryna szkodzi, szybka nie daje przewagi automatycznie – szybkość ładowania strony to jeden z wielu czynników rankingowych Google, a nie przełącznik.

Jak przyspieszyć ładowanie witryny – kompresja obrazów, lazy loading i kompresja kodu

W praktyce za wolne ładowanie odpowiada kilka powtarzalnych przyczyn. Zanim zaczniesz optymalizować kod, sprawdź, czy nie masz któregoś z klasyków.

• Nieskompresowane obrazy. Pliki PNG ważące po kilka megabajtów to najczęstszy powód złego LCP. Kompresja obrazów i konwersja do WebP lub AVIF dają największy zysk przy najmniejszym nakładzie.

• Lazy loading grafik poniżej pierwszego ekranu. Uwaga: nie stosuj go do obrazu odpowiadającego za LCP, bo pogorszysz wynik zamiast go poprawić.

• Kompresja kodu i usunięcie zbędnych skryptów. Trzy widgety czatu i pięć wtyczek robiących to samo obciążają stronę bardziej niż nieoptymalny CSS – tu zaczyna się właściwa optymalizacja kodu strony internetowej.

• Cache przeglądarki i serwera. Powracający użytkownik dostaje wersję statyczną, co zdejmuje obciążenie z serwera.

• CDN. Ma sens przy ruchu z wielu regionów. Przy lokalnym sklepie z klientami z jednego kraju zysk bywa symboliczny.

Jeśli mimo poprawek czas odpowiedzi serwera pozostaje wysoki, problem leży poza kodem. Wtedy jedynym sensownym ruchem jest zmiana hostingu. Osobnego zestawu poprawek wymaga najpopularniejszy CMS – tam większość zysku daje przyspieszenie strony na WordPressie od strony wtyczek i cache’owania.

Kiedy JavaScript ukrywa treść przed Google?

Googlebot renderuje JavaScript, ale nie od razu. Najpierw skanuje surowy HTML, a renderowanie trafia do osobnej kolejki. Efekt: treść generowana po stronie klienta może czekać na indeksację od kilku godzin do kilku dni.

Problem dotyczy głównie aplikacji SPA i serwisów opartych na frameworkach, gdzie w źródle strony widać pustą strukturę HTML bez treści. Diagnoza jest prosta: porównaj widok źródła (Ctrl+U) z DOM po wykonaniu skryptów w narzędziach deweloperskich. Jeśli w surowym HTML brakuje nagłówka H1 i głównej treści, masz odpowiedź.

Rozwiązania są trzy: renderowanie po stronie serwera (SSR), generacja statyczna dla treści niepersonalizowanych albo renderowanie dynamiczne jako obejście na czas migracji.

Co widzą boty AI, gdy wchodzą na Twoją stronę?

To pytanie, którego trzy lata temu nie było w żadnym audycie. Dziś ma bezpośrednie przełożenie na widoczność, bo część zapytań kończy się odpowiedzią AI, a nie kliknięciem w wynik.

Najważniejsza różnica techniczna: crawlery modeli językowych zachowują się inaczej niż Googlebot. Nie mają zaawansowanej kolejki renderującej, więc treść dostępna dopiero po wykonaniu JavaScriptu może być dla nich niewidoczna. Serwis, który poprawnie indeksuje się w Google dzięki drugiej fali renderowania, dla bota AI potrafi być pustą stroną.

Druga kwestia to blokady. Wiele witryn zablokowało crawlery treningowe AI, przy okazji odcinając crawlery odpowiedzialne za wyszukiwanie i cytowania. To dwie różne kategorie botów i warto podjąć wobec nich dwie osobne decyzje w pliku robots.txt, zamiast jednej ogólnej.

Praktyczny wniosek: jeśli zależy Ci na cytowaniach, treść musi być w surowym HTML, mieć jasne definicje i konkretne fakty, a kluczowe informacje nie mogą siedzieć za formularzem ani w rozwijanych sekcjach ładowanych na żądanie.

Dane strukturalne Schema.org – które typy dają rich snippets i cytowania w AI Overviews

Dane strukturalne to kod opisujący kontekst treści w formacie zrozumiałym dla maszyn. Nie są czynnikiem rankingowym, ale wpływają na wygląd wyniku i na to, jak systemy AI interpretują zawartość strony.

Nie wdrażaj wszystkiego, co znajdziesz w słowniku Schema.org. Sensowny zakres zależy od typu serwisu:

• Product + AggregateRating – sklepy. Daje cenę, dostępność i gwiazdki w wynikach, co wyraźnie podnosi CTR.

• Article + Person – blogi i serwisy eksperckie. Wiąże treść z autorem, co ma znaczenie przy ocenie doświadczenia i wiarygodności.

• LocalBusiness – firmy z lokalizacją. Dane muszą być spójne z tym, co masz w wizytówce, dlatego warto je wdrażać razem z optymalizacją wizytówki Google.

• Organization – każda marka. Porządkuje podstawowe fakty: nazwę, logo, kanały kontaktu.

Poprawność wdrożenia sprawdzisz w teście wyników z elementami rozszerzonymi. Błędna implementacja jest po prostu ignorowana – nie szkodzi, ale nie daje niczego.

Optymalizacja mobilna i mobile-first indexing – co Google ocenia w wersji mobilnej

Google ocenia witrynę na podstawie wersji mobilnej. To znaczy, że wszystko, czego nie ma na telefonie, praktycznie nie istnieje dla wyszukiwarki – nawet jeśli świetnie wygląda na desktopie.

Sama responsywność to za mało, choć bez niej nie ma o czym rozmawiać – dlatego responsywną stronę traktuj jako punkt wyjścia, nie cel. Wersja mobilna powinna zawierać dokładnie tę samą treść, te same linki wewnętrzne i te same dane strukturalne co desktopowa. Typowe pułapki to skrócone opisy kategorii „dla czytelności”, ukryte sekcje ładowane dopiero po kliknięciu oraz uproszczone menu, które wycina połowę linkowania wewnętrznego.

Certyfikat SSL i przekierowania 301 – jak nie stracić widoczności przy migracji

Certyfikat SSL jest dziś standardem, a HTTPS to słaby, ale realny sygnał rankingowy. Ważniejsze jest to, że przeglądarka oznacza strony bez szyfrowania jako niezabezpieczone, co skutecznie zniechęca użytkowników.

Ryzyko nie tkwi w samym certyfikacie, tylko w przekierowaniach. Najczęstszy błąd to niepełna konfiguracja: działa przekierowanie z http na https, ale wersje z www i bez www pozostają dostępne osobno. Powstają duplikaty i rozproszone sygnały.

Zasady, które ograniczają straty przy migracji:

• Jedna kanoniczna wersja domeny – wszystkie pozostałe warianty przekierowane bezpośrednio na nią.

• Przekierowanie 301, nie 302, jeśli zmiana jest trwała.

• Brak łańcuchów typu 1 → 2 → 3. Każdy stary adres powinien prowadzić od razu do docelowego.

• Mapowanie adres w adres, nie zbiorczo na stronę główną – to najszybszy sposób na utratę pozycji.

Bezpieczeństwo witryny to zresztą szerszy temat niż sam certyfikat. Zaniedbany serwis potrafi zostać oznaczony przez Google jako zagrożenie i wypaść z wyników w kilka dni – wtedy priorytetem przestaje być ranking, a staje się usunięcie wirusa ze strony internetowej.

Atrybut hreflang, czyli kierowanie międzynarodowe bez kanibalizacji

Hreflang jest potrzebny wtedy, gdy masz kilka wersji tej samej treści dla różnych języków lub rynków. Jego zadaniem nie jest poprawa pozycji, tylko pokazanie użytkownikowi właściwej wersji i powstrzymanie wersji językowych przed konkurowaniem ze sobą o te same zapytania.

Wdrożenie ma dwie żelazne zasady. Po pierwsze, odniesienia muszą być wzajemne – jeśli strona A wskazuje na B, to B musi wskazywać na A. Po drugie, każda wersja wskazuje także na samą siebie. Brak którejkolwiek z tych relacji sprawia, że Google zignoruje całą konfigurację. Warto dodać wpis x-default dla użytkowników spoza obsługiwanych rynków.

Techniczne SEO w sklepie: filtry, paginacja i duplikacja treści

W e-commerce techniczne SEO przestaje być teorią, bo skala odsłania każdy błąd szablonu. Trzy obszary generują większość problemów.

• Filtry. Domyślnie zablokuj kombinacje parametrów w robots.txt i pozostaw indeksowalne tylko te, które mają realny potencjał wyszukiwania. Decyzja świadoma, nie automatyczna.

• Paginacja. Każda strona listy powinna mieć tag kanoniczny wskazujący na siebie samą. Ustawienie canonicala z /page/2 na /page/1 sprawia, że robot przestaje odwiedzać kolejne strony – a wraz z nimi linki do produktów.

• Duplikacja treści. Ten sam produkt dostępny pod kilkoma ścieżkami kategorii to klasyk. Rozwiązaniem są płaskie adresy produktowe w formacie domena.pl/nazwa-produktu.

Do tego dochodzą zduplikowane meta title i meta description generowane szablonowo dla całych kategorii. Nie jest to katastrofa rankingowa, ale kosztuje kliknięcia. Skala tych problemów zależy też od silnika – WooCommerce z poprawnie skonfigurowanym szablonem rozwiązuje część z nich natywnie, customowe wdrożenia potrafią zaskoczyć.

Błędy 404, błędy indeksowania i inne problemy, które wychodzą w niemal każdym audycie

Poniższa lista powtarza się niezależnie od branży i wielkości serwisu:

Wspólny mianownik: większość z nich powstaje przy wdrożeniach i wychodzi na jaw kilka miesięcy później, gdy widoczność spada bez wyraźnej przyczyny. Dlatego monitoring dostępności serwisu i cykliczny przegląd techniczny to nie paranoja, tylko ubezpieczenie.

Od czego zacząć naprawę strony?

Kolejność wynika z wpływu, nie z tego, co najłatwiej poprawić. Błąd w robots.txt blokujący połowę serwisu boli bardziej niż LCP na poziomie 3,2 sekundy zamiast 2,4.

1. Blokady indeksacji wartościowych stron. Robots.txt, przypadkowy noindex, błędne canonicale. To awaria, nie optymalizacja.

2. Duplikacja i warianty adresów. Jedna kanoniczna wersja domeny, spójne przekierowania 301, canonical na paginacji.

3. Dostępność treści dla robotów. Renderowanie, linkowanie wewnętrzne, strony sieroty, crawl budget.

4. Core Web Vitals. Zaczynając od LCP na szablonach generujących najwięcej ruchu.

5. Dane strukturalne i elementy CTR. Meta title, meta description, rich snippets – to warstwa zysku, nie ratunku.

Pierwsze dwa punkty potrafią przynieść efekt w kilka dni po ponownym przeskanowaniu. Reszta działa w perspektywie tygodni i zależy od tempa wdrożeń. Efekty weryfikuj w danych, nie na wyczucie – najprościej sprawdzając, jak zmienia się ruch na stronie w rozbiciu na typy podstron.

Kiedy wystarczy Screaming Frog, a kiedy potrzebujesz audytu technicznego SEO

Podstawy ogarniesz sam. Darmowy Screaming Frog do 500 adresów, Google Search Console i PageSpeed Insights wystarczą, żeby wykryć blokady, błędy 404, duplikaty tytułów i najgorsze problemy z wydajnością na małej stronie usługowej.

Pełny audyt strony internetowej ma sens w kilku konkretnych sytuacjach: przy serwisach powyżej kilkuset adresów URL, przy sklepach z filtrami i wieloma szablonami, przed migracją lub po niej, oraz wtedy, gdy widoczność spada, a przyczyna nie jest oczywista. Wchodzi wtedy analiza logów serwera, porównanie renderowania i priorytetyzacja zadań, których nie da się zrobić czterema kliknięciami.

Optymalizacja techniczna sama w sobie rzadko jest celem – to punkt wyjścia. Uporządkowana witryna dopiero wtedy zaczyna zarabiać na treściach i linkach, dlatego pozycjonowanie stron www zaczynam od usunięcia barier technicznych, a nie od publikowania kolejnych artykułów. Kiedy lista błędów jest gotowa, ale brakuje rąk do wdrożenia, zostaje opcja pośrednia – zlecenie samych poprawek w ramach naprawy strony internetowej.

Niezależnie od skali obowiązuje jedna zasada. Techniczne SEO to nie projekt, który odhaczasz raz. Strony żyją: dochodzą funkcje, zmienia się CMS, deweloperzy poprawiają rzeczy, które nie były zepsute. Cykliczny przegląd działa cicho dopóki nie okaże się, że był bardzo potrzebny.