W tym wpisie dowiesz się, czym jest techniczne SEO, co obejmuje i jak zoptymalizować stronę technicznie w 7 krokach. Techniczne SEO to praca nad tym, żeby roboty wyszukiwarek mogły stronę pobrać, wyrenderować i zaindeksować, a użytkownik dostał ją szybko i bezpiecznie. Kroki: dostęp dla robotów, kody HTTP, sitemapa i canonical, renderowanie, wersja mobilna, Core Web Vitals, dane strukturalne.
Wpis jest dla właściciela strony i początkującego SEO-wca. Progi, nazwy raportów i dokumentacja Google są aktualne na październik 2026. Przykłady pochodzą z audytu bynajmniej.pl z 14.10.2026 (crawl Screaming Frog na 441 wewnętrznych URL-ach i URL Inspection w Google Search Console dla 84 URL-i z sitemap).
Techniczne SEO w skrócie: definicja i zakres
Techniczne SEO to optymalizacja infrastruktury strony (serwera, kodu, adresów URL, plików sterujących robotami) pod crawlowanie, renderowanie i indeksację. Google nie używa nazwy „techniczne SEO”, ale część Technical requirements w Google Search Essentials podaje trzy minimalne warunki indeksacji: Googlebot nie jest zablokowany, strona zwraca kod HTTP 200 i ma treść, którą da się zaindeksować. Według tej samej dokumentacji spełnienie trzech warunków nie gwarantuje indeksacji.
Zakres technicznego SEO wykracza poza trzy minimalne warunki Google. Do technicznego SEO zaliczam też szybkość (Core Web Vitals), HTTPS, wersję mobilną, kanonizację duplikatów, dane strukturalne i dostęp botów AI. Techniczne SEO różni się od on-page SEO i off-page SEO tym, czego dotyczy:
| Obszar | Czego dotyczy | Przykładowe elementy |
|---|---|---|
| Techniczne SEO | czy robot pobierze, wyrenderuje i zaindeksuje stronę | robots.txt, kody HTTP, sitemapa XML, canonical, renderowanie JS, Core Web Vitals, HTTPS |
| On-page SEO | treść i jej opis na stronie | title, meta description, nagłówki, alt, linkowanie wewnętrzne |
| Off-page SEO | sygnały spoza strony | linki zewnętrzne, wzmianki o marce, wizytówka Google |
Moim zdaniem granice między trzema obszarami SEO są umowne: linkowanie wewnętrzne poprawia indeksację, a dane strukturalne opisują treść. Kolejność prac jest za to stała: najpierw techniczne SEO, bo strona poza indeksem nie skorzysta z treści ani linków.
Jak Google przetwarza stronę: crawl, renderowanie, indeksacja
Techniczne SEO najłatwiej zrozumieć przez trzy fazy, które dokumentacja Google „JavaScript SEO basics” opisuje dla każdej strony:
- Crawling: Googlebot pobiera URL, sprawdza robots.txt i wyciąga linki z HTML.
- Renderowanie: strona czeka w kolejce, a headless Chromium wykonuje JavaScript.
- Indeksacja: Google indeksuje wyrenderowany HTML.
Według dokumentacji „JavaScript SEO basics” Googlebot kieruje do renderowania wszystkie strony z kodem 200, a strony z innym kodem, np. 404, mogą renderowanie pominąć. Każdy błąd techniczny zatrzymuje stronę na jednej z trzech faz: blokada w robots.txt na crawlingu, treść widoczna tylko po kliknięciu w skrypt na renderowaniu, a noindex albo canonical na inny adres na indeksacji.
Elementy technicznego SEO: co sprawdzić i gdzie
Każdy element technicznego SEO ma raport albo narzędzie, w którym widać błąd, i konkretny próg. Zestawienie elementów z progami według dokumentacji Google (stan na październik 2026):
| Element | Gdzie sprawdzić | Próg lub reguła Google |
|---|---|---|
| Indeksacja | GSC: raport Indeksowanie stron, Narzędzie do sprawdzania adresów URL | 3 warunki: brak blokady, kod 200, treść do zaindeksowania |
| robots.txt | GSC: raport robots.txt | limit 500 KiB, cache do 24 h, crawl-delay i noindex ignorowane |
| Sitemapa XML | GSC: raport Mapy witryn | 50 000 URL-i lub 50 MB na plik; priority i changefreq ignorowane |
| Kody HTTP i przekierowania | crawl (Screaming Frog) | 301 dla przeniesionych stron, bez łańcuchów; 404 lub 410 dla usuniętych |
| Canonical | URL Inspection: adres kanoniczny wybrany przez Google | wskazówka, nie reguła |
| Core Web Vitals | GSC: raport Podstawowe wskaźniki internetowe, PageSpeed Insights | LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1 (75. percentyl, 28 dni) |
| Wersja mobilna | Lighthouse | ta sama treść co na desktopie |
| HTTPS | GSC: raport HTTPS | lekki sygnał rankingowy od 2014 roku |
| Dane strukturalne | Rich Results Test, raporty wyników rozszerzonych w GSC | brak wymaganych pól = brak wyniku rozszerzonego |
| Rozmiar HTML | crawl, DevTools | Googlebot pobiera pierwsze 2 MB pliku HTML |
Źródła progów: specyfikacja robots.txt, przewodnik po tworzeniu sitemap, pomoc do raportu Core Web Vitals, dokumentacja Googlebota i ogłoszenie HTTPS jako sygnału rankingowego z 7.08.2014.
Jak zoptymalizować stronę technicznie w 7 krokach
Optymalizację techniczną robię w kolejności faz Google: najpierw dostęp i indeksacja, potem renderowanie i szybkość, na końcu dane strukturalne. Pełną procedurę z narzędziami opisałem w poradniku jak zrobić audyt SEO.
Krok 1. Sprawdź, czy roboty mają dostęp do strony
Plik robots.txt steruje crawlowaniem, a nie indeksacją. Według wprowadzenia Google do robots.txt plik „nie jest mechanizmem trzymania strony poza Google”, a zablokowany URL może trafić do wyników bez opisu, jeśli linkują do niego inne strony. Do wykluczenia strony z indeksu służy noindex w meta robots albo nagłówku HTTP, a strona z noindex nie może być zablokowana w robots.txt, bo Google nie zobaczy dyrektywy.
Na bynajmniej.pl robots.txt generuje Yoast SEO i plik niczego nie blokuje. W URL Inspection 80 z 84 URL-i z sitemap ma status „Strona przesłana i zindeksowana”, a 2 wpisy z lat 2008–2009 mają status „Strona zeskanowana, ale jeszcze niezindeksowana”.
Krok 2. Wyczyść kody HTTP i przekierowania
Crawl strony w Screaming Frog pokazuje kody HTTP wszystkich linkowanych adresów. Usunięta strona powinna zwracać 404 lub 410, przeniesiona 301 prosto do celu, a łańcuchy przekierowań warto skrócić do jednego skoku. Szczegóły kodów 4xx opisałem we wpisie o błędzie 404.
Crawl bynajmniej.pl z 14.10.2026 znalazł 60 wewnętrznych adresów z kodem 4xx (głównie obrazki z wpisów z lat 2008–2009) i 186 przekierowań, z czego 61 to łańcuchy, a 92 kończą się błędem lub brakiem odpowiedzi. Przykład z crawla: http://www.bynajmniej.pl/wp-content/uploads/2009/06/kaspar.jpg → 301 → 404. W treści wpisów jest też 83 linkowanych adresów po HTTP, czyli każdy z nich wymaga przekierowania na HTTPS.
Krok 3. Uporządkuj sitemapę XML i canonical
Sitemapa XML powinna zawierać tylko kanoniczne URL-e, które zwracają 200. Według przewodnika Google po sitemapach jeden plik mieści 50 000 URL-i lub 50 MB, Google używa <lastmod> tylko wtedy, gdy data jest konsekwentnie prawdziwa, a <priority> i <changefreq> ignoruje.
Tag canonical wskazuje preferowaną wersję zduplikowanej treści, ale według dokumentacji Google o kanonizacji jest „wskazówką, nie regułą”. Rozbieżność widać w URL Inspection, w polach „Adres kanoniczny określony przez użytkownika” i „Adres kanoniczny wybrany przez Google”. Więcej o kanonizacji piszę we wpisie o adresie kanonicznym.
Sitemapa bynajmniej.pl zawiera 2 URL-e, które nie zwracają 200 (/podcast/ i /wordpress-seo/, oba 301), a /wordpress-seo/ ma w GSC status „Błąd przekierowania”. Jednocześnie 23 indeksowalne URL-e, głównie strony paginacji, są poza sitemapą.
Krok 4. Sprawdź renderowanie JavaScriptu
Treść i linki generowane JavaScriptem Google widzi dopiero po renderowaniu. Według dokumentacji „JavaScript SEO basics” Google wykrywa linki tylko jako elementy <a> z atrybutem href, odradza nawigację opartą na fragmentach (#/produkty) i zaleca renderowanie po stronie serwera albo prerendering, bo nie wszystkie roboty wykonują JavaScript. W aplikacjach SPA Google radzi unikać pozornych błędów 404 przekierowaniem do adresu zwracającego 404 albo dodaniem noindex na stronie błędu.
Renderowanie sprawdzam w Narzędziu do sprawdzania adresów URL w GSC (test wersji opublikowanej, zakładka z wyrenderowanym HTML). Na bynajmniej.pl cała treść jest w HTML bez JavaScriptu, a HTML strony waży 116 KB, czyli daleko poniżej limitu 2 MB Googlebota.
Krok 5. Zadbaj o wersję mobilną i HTTPS
Google indeksuje wersję mobilną strony. Według dokumentacji mobile-first indexing Google używa do indeksacji i rankingu treści pobranej robotem smartfonowym, więc wersja mobilna ma mieć tę samą treść co desktop. Google ogłosił zakończenie przejścia na mobile-first indexing 31 października 2023 roku.
Mobile-Friendly Test i raport Mobile Usability w GSC Google wycofał 1 grudnia 2023 roku (ogłoszenie z kwietnia 2023), a wersję mobilną sprawdza się teraz w Lighthouse. HTTPS kontroluje raport HTTPS w Google Search Console.
Krok 6. Popraw Core Web Vitals i czas odpowiedzi serwera
Core Web Vitals to trzy metryki z danych prawdziwych użytkowników (CrUX, 28 dni, 75. percentyl): LCP (ładowanie), INP (reakcja na interakcję) i CLS (stabilność układu). Według pomocy Google do raportu Core Web Vitals dobry wynik to LCP do 2,5 s, INP do 200 ms i CLS do 0,1. INP zastąpił FID 12 marca 2024 roku, więc poradnik z progami FID jest nieaktualny.
Według Web Almanac 2025 dobre Core Web Vitals ma 48% witryn na urządzeniach mobilnych i 56% na desktopie. Strona dokumentacji page experience mówi, że Core Web Vitals są używane w rankingu, ale nie ma jednego sygnału page experience, a trafna treść wygrywa ze szybkością.
Na bynajmniej.pl TTFB wynosi ok. 190 ms (web.dev uznaje za dobry TTFB do 0,8 s), ale 10 URL-i archiwów tagów i kategorii odpowiadało w crawlu dłużej niż 1000 ms, a 6 obrazków waży ponad 2 MB, w tym PNG z ChatGPT z 2025 roku o wadze 3,7 MB. Obrazy ważące kilka MB uważam za najtańszą poprawkę LCP na blogu.
Krok 7. Dodaj poprawne dane strukturalne
Dane strukturalne opisują treść strony słownikiem Schema.org, a Google zaleca format JSON-LD. Według wytycznych Google dla danych strukturalnych element bez wymaganych właściwości nie kwalifikuje się do wyniku rozszerzonego, a nawet poprawny znacznik nie gwarantuje wyświetlenia. Znacznik FAQ daje wynik rozszerzony od 8.08.2023 tylko stronom rządowym i medycznym.
Na bynajmniej.pl JSON-LD z Yoast SEO jest na wszystkich 150 indeksowalnych stronach HTML. Poprawność sprawdzam w Rich Results Test, wpisując URL zamiast kodu.
Kiedy techniczne SEO wymaga więcej: crawl budget i duże serwisy
Siedem kroków wystarcza stronie firmowej i blogowi. Przewodnik Google o zarządzaniu crawl budgetem jest przeznaczony dla witryn z ponad milionem stron zmienianych raz w tygodniu albo ponad 10 000 stron zmienianych codziennie, a Gary Illyes pisał w 2017 roku, że witryna z kilkoma tysiącami URL-i zwykle jest crawlowana wydajnie. Sklepy z nawigacją fasetową, portale i serwisy z wieloma parametrami w URL-ach potrzebują dodatkowo analizy logów serwera i raportu Statystyki indeksowania; szczegóły są we wpisie o crawl budgecie.
Techniczne SEO a widoczność w AI search
Widoczność w AI Overviews i trybie AI Google zaczyna się od technicznego SEO. Według dokumentacji Google o funkcjach AI strona musi być zaindeksowana i kwalifikować się do wyświetlenia z fragmentem, a dodatkowych wymagań technicznych nie ma. Przewodnik Google po optymalizacji pod AI dodaje, że Google Search nie używa pliku llms.txt.
Boty AI spoza Google mają w robots.txt osobne tokeny, które rozdzielają trening modeli od wyszukiwania:
GPTBot(trening) iOAI-SearchBot(wyszukiwarka ChatGPT) według dokumentacji OpenAI.ClaudeBot(trening) iClaude-SearchBot(wyszukiwanie) według pomocy Anthropic.PerplexityBot(wyniki Perplexity, bez treningu) według dokumentacji Perplexity.Google-Extended(trening Gemini), który według dokumentacji crawlerów Google nie wpływa na obecność w wyszukiwarce Google.
Blokadę tokenów treningowych uważam za decyzję biznesową, a blokadę OAI-SearchBot, Claude-SearchBot czy PerplexityBot za błąd, bo według dostawców ogranicza widoczność w ich wyszukiwarkach. Treść w czystym HTML jest moim zdaniem bezpieczniejsza niż treść ładowana JavaScriptem, bo Google sam przyznaje, że nie wszystkie roboty wykonują JavaScript. Od 31.08.2026 wszystkie witryny mają w GSC raporty skuteczności generatywnej AI z wyświetleniami w AI Overviews i trybie AI.
Na bynajmniej.pl GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, PerplexityBot, Googlebot i Bingbot dostają w teście pełną treść (podszyty user agent, wynik orientacyjny).
Czego nie robić w technicznym SEO
Część porad technicznych krąży po sieci latami po tym, jak Google przestał je obsługiwać. Wpis z 2026 roku polecający Mobile-Friendly Test to jak instrukcja obsługi faksu w dziale IT: wygląda fachowo, tylko urządzenia już nie ma. Najczęstsze martwe porady:
noindexicrawl-delayw robots.txt: Google nie obsługuje ich od 1 września 2019 roku.- Ustawianie
priorityichangefreqw sitemapie: Google oba pola ignoruje. - Optymalizacja pod FID: metryka FID przestała być Core Web Vital 12 marca 2024 roku.
- Blokada strony w robots.txt, żeby usunąć ją z indeksu: zablokowany URL może zostać w wynikach bez opisu.
- Plik llms.txt jako warunek widoczności w AI Google: Google Search pliku llms.txt nie używa.
FAQ: najczęstsze pytania o techniczne SEO
Co obejmuje techniczne SEO?
Techniczne SEO obejmuje dostęp robotów (robots.txt), kody HTTP i przekierowania, sitemapę XML, canonical, renderowanie JavaScriptu, wersję mobilną, HTTPS, Core Web Vitals i dane strukturalne. W 2026 roku do zakresu technicznego SEO dochodzi dostęp botów AI.
Od czego zacząć techniczne SEO?
Techniczne SEO zaczyna się od raportu Indeksowanie stron w Google Search Console i crawla strony w darmowej wersji Screaming Frog (do 500 URL-i). Pierwsze do poprawy są błędy blokujące indeksację: blokady w robots.txt, noindex na ważnych stronach, błędy 5xx i łańcuchy przekierowań.
Czym różni się techniczne SEO od on-page SEO?
Techniczne SEO dotyczy tego, czy robot pobierze, wyrenderuje i zaindeksuje stronę, a on-page SEO dotyczy treści i jej opisu: title, nagłówków, meta description i linkowania wewnętrznego. Techniczne SEO jest warunkiem, bo strona spoza indeksu nie zyska na treści.
Czy Core Web Vitals wpływają na pozycje w Google?
Core Web Vitals są według Google używane przez systemy rankingowe, ale dobre wyniki nie gwarantują wysokich pozycji, a trafna treść wygrywa ze szybkością. Dobry wynik to LCP do 2,5 s, INP do 200 ms i CLS do 0,1.
Czy techniczne SEO wpływa na widoczność w AI Overviews?
Techniczne SEO jest warunkiem widoczności w AI Overviews, bo Google wymaga, żeby strona była zaindeksowana i kwalifikowała się do wyświetlenia z fragmentem. Dodatkowych wymagań technicznych, np. pliku llms.txt, Google nie stawia.
Jakie narzędzia są potrzebne do technicznego SEO?
Do technicznego SEO strony firmowej wystarczą darmowe narzędzia: Google Search Console, PageSpeed Insights, Lighthouse, Rich Results Test i Screaming Frog SEO Spider (bez opłat do 500 URL-i). Przy dużych serwisach dochodzi analiza logów serwera.
Członek zarządu i współwłaściciel agencji IF.PL, w SEO od ponad 20 lat (m.in. Gazeta.pl, Wirtualna Polska, Polska Press). Na bynajmniej.pl piszę z pomocą AI: temat, dane i testy są moje, AI pomaga ubrać to w słowa.
Dodaj komentarz