SEO techniczne (on-site): jak Google pobiera, renderuje i indeksuje stronę — i od czego zacząć poprawki

Czym jest SEO techniczne — i czym nie jest

SEO techniczne obejmuje wszystko, co decyduje o tym, czy robot wyszukiwarki może stronę znaleźć, pobrać, wyrenderować i włączyć do indeksu — oraz jak sprawnie strona działa dla użytkownika. To warstwa infrastruktury: kody odpowiedzi, dyrektywy indeksowania, adresacja, renderowanie, wydajność, przekierowania. Nie zajmuje się tym, co strona mówi, tylko tym, czy ma szansę zostać usłyszana.

Trzy dźwignie widoczności

• Technika — czy Google może stronę pobrać, wyrenderować i zaindeksować, nie gubiąc treści po drodze. Praca głównie deweloperska, ze skończoną listą usterek.
• Treść — czy strona odpowiada na intencję zapytania lepiej niż konkurencja. Proces redakcyjny, który nie kończy się nigdy.
• Linki i autorytet — czy inne serwisy potwierdzają wiarygodność domeny. Działania poza stroną, rozłożone w czasie.

Po co to rozdzielać przy ustalaniu priorytetów

Każda dźwignia ma inną diagnozę, innego wykonawcę i inne tempo zmian. Usterka techniczna potrafi wyzerować efekty dobrej treści — ale miesiące pracy deweloperskiej nie pomogą stronie, która nie odpowiada na żadne realne pytanie.

Rozdzielenie techniki od treści i linków to pierwszy krok każdej sensownej diagnozy: pozwala ustalić, czy Google strony nie widzi, czy widzi ją, ale nie ma powodu jej pokazywać. To dwa różne problemy, dwa różne budżety i dwóch różnych wykonawców.

Czym SEO techniczne nie jest: instalacją wtyczki, wypełnieniem pól meta, jednorazowym audytem ani gwarancją pozycji. Jest warunkiem koniecznym widoczności — ale niewystarczającym (sekcja „Czego SEO techniczne nie zrobi”).

Dostępność dla robota: zanim Google w ogóle zobaczy stronę

Zanim strona ma szansę na indeks, robot musi rozwiązać domenę w DNS, nawiązać połączenie, dostać odpowiedź HTTP i pobrać treść razem z zasobami — dopóki ta sekwencja nie działa, reszta nie ma znaczenia.

Kody odpowiedzi: pierwszy sygnał

Kod odpowiedzi serwera to pierwsza informacja, jaką robot dostaje o stronie:

Zachowania opisane w dokumentacji Google (odczyt 30.07.2026); odesłania w sekcji Źródła.

robots.txt: zarządzanie ruchem robota, nie ukrywanie stron

Plik robots.txt mówi robotom, których adresów nie pobierać. Dokumentacja Google jest jednoznaczna: to narzędzie do zarządzania ruchem crawlera, nie do ukrywania stron z wyników. Adres zablokowany w robots.txt może zostać zindeksowany, jeśli prowadzą do niego linki — tyle że bez treści i opisu, bo robot go nie przeczytał.

Blokady, o których się zapomina

• Zapora i filtrowanie botów — reguły anty-botowe serwera lub CDN potrafią serwować robotom 403, CAPTCHA albo puste odpowiedzi.
• Uwierzytelnianie — treść za hasłem jest dla robota niedostępna; poprawne dla środowisk testowych, groźne, gdy blokada zostaje na produkcji.

Częsty błąd: zablokowane pliki CSS i JavaScript

Robot renderuje stronę jak przeglądarka, więc potrzebuje arkuszy stylów i skryptów. Jeśli robots.txt blokuje katalogi z tymi zasobami, Google nie wykona skryptów z zablokowanych plików — treść od nich zależna dla wyszukiwarki nie istnieje. Takie blokady bywają pozostałością po starych konwencjach CMS-ów.

Indeksowanie i duplikaty: dlaczego Google nie indeksuje wszystkiego

Pobranie strony to nie to samo co jej zaindeksowanie. Z pobranych dokumentów Google buduje indeks, grupując duplikaty i wybierając z każdej grupy wersję kanoniczną — tę pokazuje w wynikach.

Skąd biorą się duplikaty

• Warianty protokołu i domeny — http/https oraz www/bez www to dla robota cztery adresy tego samego dokumentu, jeśli nie sprowadzają się przekierowaniami do jednej formy; jako kanoniczną Google preferuje wersję HTTPS.
• Ukośnik końcowy — /oferta i /oferta/ to technicznie dwa adresy; serwujemy jedną formę, drugą przekierowujemy.
• Parametry w adresach — sortowania, filtry, identyfikatory sesji i parametry kampanii mnożą kombinacje adresów z tą samą treścią.
• Kopie środowisk — publicznie dostępny serwer testowy to duplikat całej witryny naraz.

Canonical: sygnał, nie rozkaz

Dokumentacja Google opisuje rel=canonical jako silny sygnał, nie twardą dyrektywę: przy sprzecznych sygnałach Google może wybrać inny adres. Kolejność siły sygnałów według dokumentacji: przekierowania, potem rel=canonical, na końcu sitemapa. Canonicale muszą więc być spójne z linkowaniem wewnętrznym i sitemapą. O tym, że wybór wersji kanonicznej nie jest ostateczny, pisaliśmy w artykule o ponownej ocenie canonicali przez Google.

Paginacja

Google traktuje strony paginacji jako osobne strony. Dokumentacja e-commerce zaleca: nie ustawiać pierwszej strony jako canonicala dla kolejnych — każda ma mieć własny kanoniczny adres. Znaczniki rel=next/prev nie są już przez Google używane; strony łączymy zwykłymi linkami po kolei.

Gdy Google zna stronę i świadomie jej nie indeksuje

Raport „Indeksowanie stron” w Search Console rozróżnia dwie sytuacje, które nie są usterkami. „Strona przeskanowana, ale jeszcze niezindeksowana”: Google pobrał stronę i zdecydował się jej teraz nie indeksować — może to zrobić w przyszłości, a ponowne zgłaszanie adresu nic nie zmienia. „Strona wykryta, ale jeszcze niezindeksowana”: Google zna adres, ale go jeszcze nie pobrał, np. by nie przeciążać serwisu. W obu przypadkach odpowiedź leży zwykle w wartości treści i osadzeniu strony w strukturze linków, nie w „technicznej naprawie”.

Canonical, noindex, robots.txt czy 404/410 — kiedy użyć czego

Cztery narzędzia, cztery cele — i jedna pomyłka częstsza niż wszystkie pozostałe razem: blokada w robots.txt użyta po to, „żeby strona wypadła z indeksu”. Mechanizm błędu: robot nie może pobrać zablokowanej strony, więc nie zobaczy noindex. Dokumentacja Google stawia twardy warunek: żeby noindex zadziałał, strona nie może być zablokowana w robots.txt i musi być dostępna dla robota.

Dla treści naprawdę niepublicznych zostaje uwierzytelnianie — dokumentacja wymienia ochronę hasłem obok noindex: nie ma dostępu, nie ma indeksowania.

Architektura serwisu i linkowanie wewnętrzne

Architektura bywa traktowana jako temat „miękki” — układ menu. Z perspektywy wyszukiwarki jest twardo techniczna: robot odkrywa strony, podążając za linkami, a struktura linków mówi mu, które strony są ważne i jak łączą się tematycznie.

Głębokość klikalna i strony-sieroty

• Strona-sierota — nie prowadzi do niej żaden link wewnętrzny; robot może ją znaleźć najwyżej przez sitemapę lub link z zewnątrz, a brak linków to brak kontekstu i sygnału ważności. Sieroty wykrywa porównanie listy adresów z CMS-a z wynikami crawlu.
• Głębokość klikalna — liczba kliknięć od strony głównej. Struktura linków jest mapą ważności serwisu: strony istotne biznesowo powinny być osiągalne w kilku kliknięciach, nie ukryte na dnie hierarchii.

Nawigacja, breadcrumby i grupowanie tematyczne

Breadcrumby pokazują hierarchię użytkownikom i robotom, a oznaczone danymi strukturalnymi (typ Breadcrumb) mogą być odwzorowane w wynikach. Huby kategorii zbierają powiązane materiały i skracają ścieżki między treściami o wspólnym temacie — tak działa struktura tego bloga. Do tego linki kontekstowe w treści — tam, gdzie czytelnik ich potrzebuje.

Czego unikać

• Nawigacja budowana po interakcji — linki pojawiające się w kodzie dopiero po kliknięciu są dla robota niewidoczne: Google nie wykonuje interakcji.
• Fasetowana nawigacja bez kontroli — filtry generujące nieograniczone kombinacje adresów rozpraszają crawlowanie na strony bez wartości.
• Linkowanie przez przekierowania — linki wewnętrzne powinny prowadzić bezpośrednio do celu; dokumentacja migracji każe je aktualizować po zmianie adresów.

Renderowanie i JavaScript: co widzi robot, a co człowiek

Między tym, co widzi użytkownik, a tym, co widzi robot, potrafi być przepaść — i niemal zawsze odpowiada za nią JavaScript budujący treść już w przeglądarce.

Jak Google przetwarza JavaScript

Dokumentacja opisuje trzy fazy: crawlowanie, renderowanie, indeksowanie. Robot pobiera surowy HTML i wyciąga z niego linki; strony z kodem 200 trafiają do kolejki renderowania. Renderuje bezgłowa, stale aktualna wersja Chromium (evergreen), wykonując JavaScript jak przeglądarka — strona może czekać w kolejce od kilku sekund do dłuższego czasu. Wszystko, czego render nie wykona, dla wyszukiwarki nie istnieje.

Jak sprawdzić wyrenderowany HTML

URL Inspection w Search Console pokazuje HTML po wyrenderowaniu — to, co faktycznie trafia do indeksowania — i pozwala przetestować wersję opublikowaną na żywo. Porównanie z surowym źródłem strony ujawnia treść zależną od JavaScriptu.

Kiedy JavaScript realnie szkodzi — a kiedy to mit

Mit brzmi: „Google nie radzi sobie z JavaScriptem” — renderowanie jest częścią standardowego przetwarzania. Realne problemy są węższe:

• Treść ładowana po interakcji — Google nie klika, nie przewija i nie wypełnia pól; treść doładowywana po takich zdarzeniach nie zostanie pobrana.
• Routing na fragmentach (#) — adresy różniące się tylko fragmentem nie są dla crawlu odrębnymi stronami.
• Zablokowane zasoby — skryptów z plików zablokowanych w robots.txt Google nie wykona; treść od nich zależna przepada.
• noindex w pierwotnym HTML — changelog Google (grudzień 2025) przestrzega: jeśli strona ma być indeksowana, nie umieszczać noindex w pierwotnym kodzie i nie liczyć, że skrypt go zdejmie.
• Kanonizacja zależna od JS — kanonizacja zachodzi przed renderowaniem i po nim, więc wskazanie wersji kanonicznej ma być jednoznaczne już w surowym HTML-u.

Dla serwisów w całości zależnych od JavaScriptu opcją niezawodności jest renderowanie po stronie serwera lub prerendering — robot dostaje gotowy HTML.

Wersja mobilna po mobile-first indexing

Google indeksuje strony na podstawie wersji mobilnej — domknięcie przejścia na mobile-first indexing ogłosił na oficjalnym blogu w październiku 2023 roku. Strony pobiera przede wszystkim robot smartfonowy (Googlebot Smartphone). Konsekwencja: to, czego nie ma w wersji mobilnej, z perspektywy indeksu nie istnieje.

Parytet treści

Dokumentacja formułuje podstawową zasadę: wersja mobilna powinna zawierać tę samą treść co desktopowa. Skrócona wersja mobilna oznacza, że indeksowana jest właśnie ta uboższa. Zwijanie treści to co innego: dokumentacja zaleca reorganizację w akordeony lub zakładki zamiast usuwania — treść zwinięta pozostaje w kodzie i jest indeksowana. Problemem nie jest zwinięta sekcja, tylko sekcja, której na mobile w ogóle nie ma.

To samo dotyczy metadanych i znaczników

• Dane strukturalne — obecne na obu wersjach; znaczniki wdrożone tylko w desktopie znikają z wersji, którą Google indeksuje.
• Meta robots — te same dyrektywy na obu wersjach; rozjazd (np. noindex tylko na mobile) potrafi zablokować indeksowanie.
• Obrazy i alt — te same opisy alternatywne, ta sama jakość obrazów, stabilne adresy plików.
• Treść za interakcją — również na mobile Google nie wykonuje gestów; treść po przesunięciu czy dotknięciu nie zostanie załadowana.

Wydajność i Core Web Vitals

Core Web Vitals (podstawowe wskaźniki internetowe) to trzy metryki doświadczenia użytkownika mierzone na realnych wizytach. LCP (Largest Contentful Paint) — moment wyrenderowania największego elementu w oknie: obrazu, wideo lub bloku tekstu. INP (Interaction to Next Paint) — najdłuższa zaobserwowana reakcja na kliknięcia, dotknięcia i klawisze w całej wizycie; w 2024 roku zastąpił metrykę FID. CLS (Cumulative Layout Shift) — suma nieoczekiwanych przesunięć układu, powodowanych typowo przez obrazy bez wymiarów, doładowywane banery i webfonty.

Progi zdefiniowane przez Google (web.dev, odczyt 30.07.2026) — nie umowne wartości branżowe.

Dane terenowe kontra laboratoryjne

Dane terenowe (field) pochodzą z realnych sesji użytkowników Chrome, agregowanych w raporcie CrUX z 28 dni — na nich opiera się raport podstawowych wskaźników internetowych w Search Console. Dane laboratoryjne (lab) to pojedynczy pomiar w kontrolowanych warunkach: przydatny do debugowania, ale nie mierzy INP i nie odzwierciedla realnych urządzeń, sieci i zachowań. Rozjazd między labem a terenem jest normalny — web.dev wskazuje dane terenowe jako podstawę priorytetyzacji.

Co Core Web Vitals dają, a czego nie

Dokumentacja page experience potwierdza, że Core Web Vitals są używane przez systemy rankingowe Google — i zastrzega, że wyszukiwarka pokazuje najtrafniejszą treść nawet przy słabszym page experience, a dobre wyniki w raportach nie gwarantują wysokich pozycji. Czego progi nie załatwią: nie naprawią indeksowania, nie zdejmą blokad, nie zastąpią treści — przyczyną nieobecności w indeksie prawie nigdy nie jest LCP. Praktyczny przykład pracy z tymi progami na konkretnej platformie opisaliśmy w artykule o Core Web Vitals w Shopify.

Dane strukturalne: porządek w treści, nie dźwignia pozycji

Dane strukturalne to ustandaryzowany format opisu zawartości strony. Według dokumentacji Google pomagają zrozumieć, czym strona jest, i mogą kwalifikować ją do wyników rozszerzonych — przy czym wdrożenie niczego nie gwarantuje: to warunek kwalifikacji, nie obietnica.

Które typy mają sens

• Firma usługowa — LocalBusiness (dane firmy, godziny, lokalizacja w panelu wiedzy), Organization (logo, nazwa prawna, kontakt), Breadcrumb oraz Article dla treści blogowych.
• Sklep internetowy — przede wszystkim Product (cena, dostępność, oceny w wynikach), Review snippet tam, gdzie są prawdziwe oceny, oraz Breadcrumb i Organization.
• Czego nie wdrażać „na zapas” — typów z wycofaną prezentacją: wyniki rozszerzone FAQ nie są już pokazywane (changelog Google, czerwiec 2026). Znacznik nie szkodzi, ale nie daje żadnej prezentacji — przed wdrożeniem sprawdzamy changelog i galerię typów.

Parytet znaczników i widocznej treści

Wytyczne Google są jednoznaczne: nie znakować informacji, których nie ma w widocznej treści — nawet prawdziwych — i nie tworzyć pustych stron pod dane strukturalne. Rozjazd między znacznikami a treścią to najkrótsza droga do utraty kwalifikacji do wyników rozszerzonych. A dlaczego to nie dźwignia pozycji: dokumentacja opisuje znaczniki jako pomoc w zrozumieniu treści i warunek udziału w funkcjach prezentacji — nie jako czynnik rankingowy.

Migracje i przekierowania: gdzie widoczność ginie najczęściej

Migracja — zmiana domeny, protokołu, struktury adresów albo CMS-a — to moment najwyższego ryzyka technicznego: jedna zła reguła dotyka tysięcy adresów naraz.

Mapa 1:1

Fundament to mapa przekierowań: każdy stary adres prowadzi do odpowiadającego mu nowego. Google wprost odradza kierowania wielu starych adresów na jeden nietrafny cel, jak strona główna nowego serwisu. Strona bez odpowiednika powinna dostać 404/410. Search Console nadaje status soft 404 stronom, które „wyglądają na błąd” mimo kodu 200 — a lądowanie na stronie głównej zamiast szukanej treści to dokładnie taki błąd.

301, 302 i łańcuchy przekierowań

Dokumentacja podaje twardy limit: roboty Google podążają domyślnie za maksymalnie 10 skokami przekierowań. Każdy skok to dodatkowe żądanie i punkt awarii — przekierowujemy bezpośrednio do celu, a linki wewnętrzne aktualizujemy, by nie przechodziły przez przekierowania.

Co z mocą linków i ile to trwa

Przy stałym przekierowaniu 1:1 sygnały starego adresu są przenoszone na nowy — dlatego dokumentacja każe utrzymywać przekierowania co najmniej rok. Migracja małego lub średniego serwisu jest przetwarzana zwykle przez kilka tygodni; większe potrzebują więcej czasu. Przed startem: weryfikacja obu wersji w Search Console, sitemapa z nowymi adresami i kontrola, czy nowa wersja nie blokuje indeksowania — klasyczny wypadek to noindex ze środowiska testowego na produkcji. Przy zmianie domeny: zgłoszenie Change of Address.

Kolejność diagnozy: jak audytować, żeby nie utonąć

Audyt techniczny tonie, gdy zaczyna się od dwustupunktowej checklisty zamiast od pytań rozstrzygających — sztuką jest ustalenie, które ze znalezisk cokolwiek zmieniają:

1. Czy robot może pobrać stronę? — kody odpowiedzi kluczowych podstron, robots.txt, dostępność zasobów, zachowanie zapory.
2. Co jest w indeksie i dlaczego nie wszystko? — raport „Indeksowanie stron”: przyczyny wykluczeń, usterki kontra decyzje Google.
3. Co robot widzi po renderowaniu? — URL Inspection dla jednego adresu z każdego szablonu.
4. Czy adresacja jest spójna? — jedna wersja domeny, canonicale zgodne z linkowaniem i sitemapą, przekierowania bez łańcuchów.
5. Czy wersja mobilna niesie pełną treść? — parytet treści, znaczników i dyrektyw.
6. Dopiero teraz wydajność i szlify — Core Web Vitals na danych terenowych, dane strukturalne pod konkretne funkcje.

Cztery źródła danych

Usterka czy kosmetyka

Ostatni filtr diagnozy to trzy koszyki. Bloker — uniemożliwia pobranie, indeksowanie albo renderowanie: naprawa natychmiast. Degradacja — utrudnia, ale nie uniemożliwia (łańcuchy, słabe Core Web Vitals, braki parytetu): do zaplanowania. Kosmetyka — nie zmienia niczego ani dla robota, ani dla użytkownika: na koniec kolejki albo wcale. Duża część pozycji z automatycznych raportów to trzeci koszyk.

Czego SEO techniczne nie zrobi

SEO techniczne nie tworzy popytu ani treści — usuwa przeszkody między tym, co strona już oferuje, a tym, co Google może pobrać, zrozumieć i pokazać. Jeśli strona nie odpowiada na żadną realną intencję wyszukiwania, po naprawieniu techniki nadal nie będzie na nią odpowiadać — tylko sprawniej.

• Treść i intencja — technicznie nienaganna strona bez treści odpowiadającej na pytania użytkowników nie ma czego pokazać w wynikach.
• Autorytet i linki — technika nie zbuduje rozpoznawalności domeny ani powodów, by inne serwisy się na nią powoływały.
• Aktualizacje algorytmu dotyczące jakości — zmiany widoczności po aktualizacjach oceniających treść nie mają technicznej naprawy; pisaliśmy o tym przy okazji majowego core update i czerwcowego spam update.
• Popyt — jeśli nikt nie szuka produktu czy usługi, nie ma ruchu do przechwycenia.

Kiedy technika naprawdę jest wąskim gardłem: serwis po migracji z wyraźnym spadkiem, duże partie adresów poza indeksem, rozjazd między treścią a wyrenderowanym HTML-em, wersja mobilna okrojona względem desktopowej. Wtedy naprawa techniczna to warunek wstępny dalszej pracy.

Checklista minimum: co sprawdzić samodzielnie

Jedenaście punktów do przejścia bez płatnych narzędzi — wystarczy przeglądarka i Search Console:

• Kody odpowiedzi — kluczowe podstrony zwracają 200, a nieistniejące adresy 404/410, nie 200 z komunikatem błędu.
• robots.txt — nie blokuje ważnych podstron ani katalogów z plikami CSS i JavaScript.
• Dyrektywy indeksowania — na stronach, które mają być widoczne, nie został przypadkowy noindex.
• Jedna wersja adresu — warianty http/https, www/bez www i ukośnika sprowadzone stałymi przekierowaniami do jednej formy.
• Canonicale — wskazują istniejące, indeksowalne strony; spójne z linkowaniem wewnętrznym i sitemapą.
• Sitemapa — aktualna, tylko kanoniczne adresy z kodem 200, zgłoszona w Search Console.
• Renderowanie — URL Inspection pokazuje pełną treść najważniejszych szablonów.
• Parytet mobilny — wersja mobilna z tą samą treścią, znacznikami i dyrektywami co desktopowa.
• Core Web Vitals — raport w Search Console bez adresów w grupie „Słaba”; poprawki według danych terenowych.
• Przekierowania — bez łańcuchów; linki wewnętrzne prowadzą bezpośrednio do celu.
• Raport „Indeksowanie stron” — przyczyny wykluczeń przejrzane; usterki odróżnione od decyzji Google.

Podsumowanie

SEO techniczne to nie lista dwustu poprawek, tylko sześć pytań zadanych we właściwej kolejności: czy robot może stronę pobrać, czy Google ją indeksuje i dlaczego nie całą, co widać po wyrenderowaniu, czy adresacja jest spójna, czy wersja mobilna niesie pełną treść i czy strona działa sprawnie na realnych urządzeniach. Blokery naprawiamy natychmiast, degradacje planowo, kosmetykę na końcu albo wcale.

Technika jest fundamentem, nie strategią: usuwa przeszkody, ale nie zastępuje treści odpowiadającej na intencje użytkowników ani autorytetu domeny. Serwis wygrywa, gdy trzy dźwignie pracują razem, a budżet trafia do tej, która jest akurat wąskim gardłem. Dokumentacja Google zmienia się w czasie — ten poradnik aktualizujemy, gdy zmiany dotkną opisanych mechanizmów.