Techniczne SEO – czym jest i jak zoptymalizować swoją stronę

Google może nie zobaczyć Twojej strony, nawet jeśli masz świetny content. Techniczne SEO to warstwa, która decyduje, czy robot w ogóle dotrze do treści, zrozumie ją i uzna za wartą pokazania użytkownikom. Pokażę Ci czym jest optymalizacja techniczna, z jakich elementów się składa i jak sprawdzić, że Twoja witryna nie blokuje się sama przed sobą.

Czym jest techniczne SEO

Techniczne SEO to zbiór działań optymalizacyjnych, które dotyczą infrastruktury strony internetowej – nie treści, nie linków zewnętrznych, ale samej architektury i sposobu, w jaki serwis komunikuje się z robotami wyszukiwarek. Chodzi o to, żeby Google mógł sprawnie dotrzeć do każdej podstrony, poprawnie ją wyrenderować, zrozumieć jej kontekst i zdecydować, czy warto ją zaindeksować.

W uproszczeniu, content SEO odpowiada na pytanie co mówi strona, linkbuilding buduje jej autorytet, a techniczne SEO sprawia, że Google w ogóle może ją zobaczyć i ocenić. To trzy filary pozycjonowania stron – i techniczne SEO jest tym, od którego wszystko się zaczyna.

Można mieć artykuł idealnie dopasowany do intencji użytkownika, pokryty frazami, z sensownymi nagłówkami i nadal nie rankować, bo plik robots.txt blokuje indeksowanie, czas ładowania strony wynosi 9 sekund, a wersja mobilna się sypie. Widziałem to w audytach dziesiątki razy.

Z czego składa się techniczne SEO

Techniczne SEO obejmuje kilka dużych obszarów. Każdy z nich można by rozpisać na osobny artykuł – i zrobię to – ale tutaj chcę dać Ci przegląd całości, żebyś rozumiał jak te elementy łączą się ze sobą.

Indeksowanie i crawlowanie

Robot Google (Googlebot) skanuje internet, podążając za linkami. Kiedy trafia na Twoją witrynę, przechodzi przez kolejne adresy URL i decyduje, które strony warto zaindeksować.

Skąd o tym wiemy?

Ta informacje jest udokumentowana w patencie Google o numerze US20120078874A1 – Search Engine Indexing.

Żebyś mógł na to wpłynąć, masz dwa podstawowe narzędzia:

Plik robots.txt – to plik tekstowy w katalogu głównym domeny, który mówi robotom wyszukiwarek, czego nie powinny skanować. Może blokować całe sekcje, konkretne pliki albo określone parametry URL. Błąd w robots.txt potrafi zablokować całą witrynę przed indeksowaniem – i to bez żadnego komunikatu błędu w przeglądarce. Użytkownik widzi stronę normalnie, Google nie widzi nic.

Mapa witryny XML (sitemap) – plik, który zawiera listę adresów URL, które chcesz zaindeksować. To coś w rodzaju spisu treści dla Googlebota. Nie gwarantuje indeksacji, ale ułatwia robotowi znalezienie wszystkich podstron, szczególnie tych, do których nie prowadzą linki wewnętrzne.

Oba te pliki zweryfikować można za pomocą Google Search Console. To podstawowe narzędzie każdego, kto zajmuje się SEO technicznym – bezpłatne, bezpośrednio od Google, pokazuje błędy indeksowania, pokrycie indeksu, problemy z mobilnością i dużo więcej.

Struktura URL i architektura strony

Adresy URL to nie tylko estetyka. Logiczna struktura URL pomaga robotom zrozumieć hierarchię serwisu i powiązania między podstronami.

Dobry adres URL wygląda tak: digispot.pl/blog/techniczne-seo/

A nie tak: digispot.pl/index.php?id=1247&cat=3&lang=pl

Poza samym formatem ważna jest architektura informacji – jak strony linkują do siebie nawzajem, jak głęboko są zakopane (ile kliknięć od strony głównej), czy nie ma stron-sierot (ang. orphan pages) bez żadnych linków wewnętrznych.

Orphan pages to strony, do których Google może nie dotrzeć nigdy – bo żadna inna podstrona do nich nie prowadzi. Linkowanie wewnętrzne decyduje też o tym, jak sygnały rankingowe rozchodzą się po serwisie. Strona zakopana na czwartym poziomie struktury, do której prowadzi jeden link z 4 strony paginacji, będzie traktowana przez Google zupełnie inaczej niż ta podlinkowana z poziomu głównej nawigacji i kilku powiązanych artykułów.

Linkowanie wewnętrzne to jeden z niedocenianych elementów technicznego SEO, który ma realny wpływ na widoczność w wynikach wyszukiwania.

Meta tagi – title, description i dyrektywy dla robotów

Meta tagi to fragmenty kodu HTML, których użytkownik nie widzi bezpośrednio na stronie, ale jeszcze w wynikach wyszukiwania.

Title i description to dwa najważniejsze tagi pod kątem CTR. Title pojawia się jako niebieski nagłówek w wynikach Google, description jako szary tekst poniżej. Meta Description nie jest bezpośrednim czynnikiem rankingowym (przynajmniej description na pewno nie), ale mają realny wpływ na kliknięcia co może zaliczać go do czynników behawioralnych.

Nie jestem w stanie zliczyć ile razy widziałem zduplikowane title’e oraz meta descritpion na setkach podstron – szczególnie w sklepach internetowych, gdzie szablony generują identyczne tytuły dla całych kategorii produktów.

Meta robots – mówi Googlebotowi, czy może zaindeksować stronę (index) i podążać za linkami (follow), czy nie – czy to zawsze respektuje to już inny temat na inny wpis 🙂

Tag kanoniczny (rel=”canonical”) – wskazuje, która wersja strony jest „oryginalna”. Pomocne gdy ta sama treść dostępna jest pod kilkoma adresami URL (np. wersja z www i bez, wersja HTTP i HTTPS, strony z parametrami filtrów w sklepie internetowym). Bez canonicali Google może uznać treści za zduplikowane i obniżyć widoczność.

To trzy różne mechanizmy, które są często mylone. Robots.txt mówi „nie skanuj tego”, meta robots mówi „nie indeksuj tego”, a kanoniczny mówi „traktuj to jako kopię tamtego”. Każdy robi coś innego.

Szybkość ładowania strony i Core Web Vitals

Google od 2021 roku używa Core Web Vitals jako sygnału rankingowego. To trzy wskaźniki, które mierzą doświadczenie użytkownika podczas ładowania strony:

• LCP (Largest Contentful Paint) – jak szybko ładuje się największy element widoczny na ekranie (najczęściej hero image lub główny nagłówek). Dobry wynik to poniżej 2,5 sekundy.
• CLS (Cumulative Layout Shift) – czy elementy strony skaczą podczas ładowania (np. przyciski, które się przesuwają zanim zdążysz kliknąć). Dobry wynik to poniżej 0,1.
• INP (Interaction to Next Paint) – jak szybko strona reaguje na kliknięcia i interakcje użytkownika. Zastąpił FID w 2024 roku.

W praktyce największe problemy z LCP widuje na sklepach internetowych – ale nie tylko na stronie głównej. Core Web Vitals muszą być spełnione na każdej podstronie. Strona główna często wypada nieźle, bo jest zadbana i lekka. Problem zaczyna się na stronach kategorii z dziesiątkami miniatur produktów, na kartach produktowych z galerią w wysokiej rozdzielczości albo na starszych wpisach blogowych, gdzie nikt nie myślał o optymalizacji obrazów.

Sprawdź po jednym URL z każdego typu:

• stronę główną,
• kategorię,
• produkt,
• wpis blogowy
• stronę informacyjną.

Dopiero to daje realny obraz kondycji serwisu.

Osobiście bardzo często wspieram się narzędziem Google Search Console, który w raporcie o nazwie „Podstawowe wskaźniki internetowe” pokaże kondycje wszystkich rodzajów podstron w 1 miejscu:

JavaScript SEO

Osobna kwestia, o której warto wiedzieć – szczególnie jeśli Twoja strona opiera się mocno na JavaScripcie. Googlebot renderuje JS, ale nie robi tego od razu. Istnieje coś, co nazywa się second wave of indexing – Google najpierw skanuje HTML, a dopiero w drugim podejściu renderuje JavaScript i indeksuje treści generowane dynamicznie. To może oznaczać opóźnienie indeksacji od kilku godzin do kilku dni.

W praktyce problem dotyka głównie aplikacji SPA (Single Page Application) i serwisów zbudowanych w oparciu o frameworki jak Next.js czy Nuxt, gdzie duża część treści generowana jest po stronie klienta. Jeśli Twoja strona wygląda w źródle jak pusta struktura HTML bez treści – Google może mieć problem z jej poprawnym zaindeksowaniem. W Google Search Console możesz sprawdzić jak Google faktycznie widzi Twoją stronę korzystając z narzędzia „Sprawdź URL” i podglądu wyrenderowanej wersji. Warto dodać, że to narzędzie nie pokazuje w 100% tego jak Google bot „widzi” naszą stronę, ale to narzędzie jest temu najbliższe.

Google Search Console → Sprawdź dowolny adres URL → Wyświetl przetestowaną stronę

Responsywność i mobile-first indexing

Google indeksuje strony głównie w wersji mobilnej. To się nazywa mobile-first indexing i obowiązuje od 2019 roku (dla nowych stron) i 2023 roku dla wszystkich pozostałych.

Responsywność to nie tylko „strona się wyświetla na telefonie”. Wersja mobilna powinna zawierać dokładnie tę samą treść i funkcje co desktopowa – bez ukrytych sekcji, skróconych opisów ani brakujących danych strukturalnych.

Bezpieczeństwo – certyfikat SSL i HTTPS

HTTPS to od lat sygnał rankingowy w Google – słaby, ale jest. Ważniejsze jest to, że przeglądarka oznacza strony HTTP jako „niezabezpieczone”, co zniechęca użytkowników i obniża współczynnik konwersji.

Migracja z HTTP na HTTPS wymaga prawidłowego skonfigurowania przekierowań 301 ze wszystkich starych adresów na nowe w odpowiedniej kolejności, żeby nie stworzyć dodatkowo łańcucha przekierowań. Jeśli przekierowania są ustawione źle (np. HTTP → HTTPS, ale www → non-www bez przekierowania), możesz skończyć z duplicate content i rozproszonym link juice.

Dane strukturalne

Dane strukturalne (schema markup) to kod dodawany do HTML strony, który pomaga Google zrozumieć kontekst treści. Dzięki nim wyniki wyszukiwania mogą zawierać rozszerzone informacje – gwiazdki ocen, ceny produktów, daty wydarzeń, przepisy kulinarne. To tzw. rich snippets.

Nie wpływają bezpośrednio na pozycję, ale jeśli już rankujesz w top 10, rich snippets mogą wyraźnie zwiększyć klikalność – gwiazdki ocen, cena produktu czy data artykułu wyróżniają wynik na tle konkurencji. Warto też pamiętać, że z danych strukturalnych korzystają nie tylko roboty Google – AI Overview i inne systemy AI używają schema do rozumienia kontekstu strony przy generowaniu odpowiedzi. Schema jest również nieocenionym dodatkiem w SEO lokalnym, o którym napiszę więcej w innym artykule.

Jak sprawdzić stan techniczny swojej strony

Nie trzeba od razu robić pełnego audytu. Zacznij od kilku rzeczy, które możesz zweryfikować w ciągu godziny:

Google Search Console – zakładka „Indeksowanie” → „Strony”. Sprawdź, ile stron jest zaindeksowanych, a ile nie – i dlaczego.

PageSpeed Insights – wklej adres URL strony głównej, strony kategorii i strony produktu, wybierz widok mobilny. Patrz na dane Field Data (rzeczywiste dane użytkowników), nie tylko Lab Data.

Plik robots.txt – otwórz twojastrona.pl/robots.txt i przeczytaj. Czy nie ma tam blokad ważnych ścieżek, a w skrajnych przypadkach nawet całej witryny – zdarza się po migracjach.

Screaming Frog (wersja darmowa do 500 URL) – przeskanuj stronę i sprawdź zakładki z błędami 404 i przekierowaniami.

To nie pełny audyt techniczny SEO, ale te cztery punkty często wystarczają, żeby znaleźć najpoważniejsze problemy. Jeśli masz już listę błędów – naprawiaj w kolejności:

• najpierw wszystko co blokuje indeksowanie wartościowych stron,
• potem duplicate content i błędy canonicali,
• na końcu Core Web Vitals.

Błąd w robots.txt blokujący połowę serwisu boli bardziej niż LCP na poziomie 3,2 sekundy zamiast 2,4.

Błędy techniczne, które widzę najczęściej

Parę rzeczy powtarza się w audytach niezależnie od branży i rozmiaru strony:

Zduplikowane wersje strony głównej – https://domena.pl, https://www.domena.pl, http://domena.pl, http://www.domena.pl – wszystkie cztery dostępne bez przekierowania. Google widzi cztery różne strony z identyczną treścią.

Plik robots.txt blokujący CSS i JavaScript – Stary nawyk z czasów, gdy nikt nie renderował stron. Dziś Google renderuje JavaScript – jeśli zablokujesz dostęp do plików JS i CSS, robot nie zobaczy strony tak, jak widzi ją użytkownik.

Meta tagi kanoniczne wskazujące na inną wersję niż ta zaindeksowana – Widziałem strony, gdzie canonical wskazywał na wersję staging lub na błędny URL. Google grzecznie stosował się do dyrektywy i ignorował właściwą stronę.

Zły canonical na stronach paginacji – Każda strona paginacji powinna mieć canonical wskazujący na siebie samą (self canonical) – nie na stronę pierwszą. Ustawienie /page/2, /page/3 z canonicalem na /page/1 sprawia, że Googlebot przestaje odwiedzać kolejne strony. A tam są linki do produktów – które tym samym wypadają z crawlowania.

Brak sitemaps w Search Console – Mapa witryny XML istnieje, ale nie jest zgłoszona w Google Search Console. Google może ją znaleźć sam, ale po co liczyć na przypadek – skoro przy poprawnie wygenerowanej sitemapie to dosłownie 2 kliknięcia.

Niezablokowane filtry w sklepach internetowych – Każda kombinacja filtrów (kolor, rozmiar, cena, producent) na wielu CMS generuje osobny URL. Przy kilkuset produktach i kilku filtrach robi się z tego tysiące adresów z niemal identyczną treścią. Jeśli nie są zablokowane w robots.txt, Googlebot traci crawl budget na przeglądanie stron, które nigdy nie miały rankować. Wyjątek to filtry celowo zaprojektowane pod indeksację – jak osobne strony dla wariantów kolorystycznych czy konkretnych kategorii produktowych. To jednak część strategii SEO, którą należy świadomie zaplanować zanim na ślepo zablokujemy dostęp do potencjalnie ważnych podstron.

Wraz z rosnącą popularnością sklepów opartych o platformy SaaS wiele z tych problemów rozwiązuje się automatycznie – dostawca wdraża poprawny szablon i część technikaliów dzieje się w tle. W praktyce jednak customowe templatki potrafią zaskoczyć. Widziałem sklepy na popularnych platformach z błędami, które teoretycznie nie powinny tam istnieć.

Techniczne SEO to fundament do którego należy regularnie wracać

Techniczne SEO to nie projekt, który odhaczasz raz i zapominasz. Strony żyją – wdrażane są nowe funkcje, zmienia się CMS, deweloperzy poprawiają rzeczy, które nie były zepsute. Znam sytuacje, w których manager projektu po rozmowie z klientem serwisu dowiedział się, że nagłówki są za małe – developer zamiast zmienić style CSS zmienił H1 na H2, albo ktoś wdrożył nowego searcha opartego o metodę GET, przez co sklep zyskał kilka tysięcy duplikatów z dnia na dzień. Przy każdym deploymencie coś może się posypać – i często są to rzeczy, które wychodzą po kilku miesiącach, gdy z nieznanych przyczyn widoczność sklepu systematycznie spada.

Dlatego monitoring w Google Search Console i cykliczny przegląd techniczny to nie paranoja tylko ubezpieczenie, które działa cicho dopóki nie okaże się, że bardzo go potrzebujesz.