Techniczne SEO: co to jest i co obejmuje

Techniczne SEO to warstwa optymalizacji, która decyduje, czy roboty Google w ogóle dotrą do Twojej strony, poprawnie ją wyrenderują i uznają za wartą zaindeksowania. To fundament każdej strategii SEO, który obejmuje kilkanaście obszarów, od dostępności dla robotów i architektury serwisu po Core Web Vitals i dane strukturalne. W serwisach B2B i e-commerce zaniedbanie technicznego SEO oznacza przepalanie budżetu na treści i linki, bo najlepszy artykuł nie zdobędzie pozycji, jeśli Googlebot nie może go przeczytać. Jeśli chcesz ocenić stan techniczny swojego serwisu, zacznij od audytu SEO.

Czym jest techniczne SEO: definicja i zakres

Techniczne SEO to zbiór działań dotyczących infrastruktury strony, a nie treści ani linków, dzięki którym Google może dotrzeć do każdej podstrony, poprawnie ją wyrenderować i zaindeksować. W praktyce obejmuje cztery główne obszary: dostępność dla Googlebota (crawlability), szybkość ładowania i Core Web Vitals, bezpieczeństwo (HTTPS, certyfikaty SSL) oraz uporządkowanie danych dla wyszukiwarki.

Porównanie do „fundamentu” jest trafne, ale niepełne. Techniczne SEO to nie jednorazowe przygotowanie gruntu, tylko stała praca inżynierska, którą trzeba sprawdzać po każdej aktualizacji platformy, kampanii treści czy zmianie struktury adresów URL. W projektach z klientami B2B widzę ten sam schemat: firma inwestuje w treści i linki, zanim naprawi infrastrukturę, a efekty są wielokrotnie mniejsze, niż mogłyby być.

Cztery obszary technicznego SEO:

• Dostępność dla robotów i indeksacja: czy Googlebot może znaleźć, odwiedzić i zaindeksować wszystkie podstrony
• Szybkość i Core Web Vitals: czy strona ładuje się na tyle szybko, żeby Google uznał ją za przyjazną użytkownikowi
• Bezpieczeństwo: HTTPS jako sygnał rankingowy i podstawa zaufania użytkownika
• Uporządkowanie danych: dane strukturalne Schema.org, meta tagi, architektura informacji

Bez sprawnej technicznej bazy treści i linki działają słabiej, niż mogłyby: artykuł, którego Google nie zaindeksuje, nie zdobędzie pozycji niezależnie od jakości. Dlatego błędy blokujące skanowanie i indeksację naprawia się przed publikacją kolejnych tekstów.

Techniczne SEO, on-page i off-page: czym się różnią

Trzy filary SEO działają hierarchicznie: techniczne SEO jest zawsze pierwsze, bo warunkuje skuteczność pozostałych. Bez poprawnej infrastruktury ani jakość treści, ani liczba linków nie przyniesie oczekiwanych efektów rankingowych.

W audytach, szczególnie w e-commerce i fintechu, najczęściej spotykam odwróconą kolejność priorytetów: firma buduje linki i produkuje treści, a podstawowe problemy techniczne (duplikaty adresów URL, błędne przekierowania, zasoby zablokowane w robots.txt) od miesięcy blokują efekty.

Jak Google indeksuje strony: crawlowanie i indeksacja

Zanim Google oceni treść Twojej strony, Googlebot musi ją znaleźć, przeskanować i zaindeksować, a te trzy etapy regulują plik robots.txt, mapa witryny XML i budżet indeksowania. Proces wygląda tak: Googlebot odkrywa adres URL (przez linki albo mapę witryny), odwiedza stronę, renderuje JavaScript, a potem decyduje, czy dodać ją do indeksu.

Co blokuje ten proces:

• Robots.txt z błędnym Disallow: najczęstszy błąd to zablokowanie plików CSS i JS, przez co Googlebot renderuje stronę bez stylów i widzi inną treść niż użytkownicy
• Tagi noindex: strona jest skanowana, ale nie trafia do indeksu
• Brak linków wewnętrznych: Googlebot nie ma jak dotrzeć do stron osieroconych („orphan pages”)
• Błędy serwera 5xx: robot traktuje stronę jako niedostępną i odkłada ją na później
• Wolna odpowiedź serwera: budżet indeksowania idzie na czekanie zamiast na skanowanie

Narzędzia kontroli: Google Search Console (raport Indeksowanie stron), Screaming Frog (tryb crawl), logi serwera (rzeczywiste zachowanie Googlebota).

Plik robots.txt: co blokować, a czego nie

Plik robots.txt to pierwszy kontakt Googlebota z Twoim serwerem, a błędy w nim mogą zablokować indeksację całego serwisu albo jego najważniejszych sekcji. Składnia: Disallow: /sciezka/ blokuje dostęp, Allow: /sciezka/ go przywraca, a Sitemap: wskazuje lokalizację mapy witryny.

Najczęstszy i najkosztowniejszy błąd: Disallow: /wp-content/ lub Disallow: *.css. Googlebot nie może wtedy załadować stylów i skryptów, renderuje stronę jako gołe HTML i ocenia ją jako uboższą treściowo, niż jest w rzeczywistości. W audytach sklepów na WordPressie i Magencie widzę ten błąd regularnie.

Najważniejsza zasada: robots.txt blokuje skanowanie, a nie indeksowanie. Google może zaindeksować adres zablokowany regułą Disallow, jeśli prowadzą do niego linki, tylko nie zobaczy jego treści. Żeby wykluczyć stronę z indeksu, użyj <meta name="robots" content="noindex"> albo nagłówka HTTP X-Robots-Tag i nie blokuj jej w robots.txt, bo robot musi odczytać tę dyrektywę.

Co blokować: panele administracyjne, strony logowania, katalogi z duplikatami wygenerowanymi przez parametry sesji, ścieżki testowe. Czego nigdy nie blokować: plików CSS i JS, właściwych podstron serwisu i mapy witryny.

Sitemap XML: mapa serwisu dla Googlebota

Mapa witryny XML to lista adresów URL serwisu przekazana bezpośrednio do Google, szczególnie ważna w dużych serwisach i na stronach z niewielką liczbą linków wewnętrznych. Mapa witryny nie gwarantuje indeksacji, ale skraca czas, po którym Googlebot odwiedza nowe lub zaktualizowane podstrony.

Jak dodać: Google Search Console → Indeksowanie → Pliki sitemap → Dodaj nowy plik sitemap. Standardowa lokalizacja to twojastrona.pl/sitemap.xml lub sitemap_index.xml dla dużych serwisów z wieloma plikami sitemap.

Trzy zasady: nie dodawaj do mapy witryny stron z tagiem noindex, adresów zwracających błąd 404 ani stron z przekierowaniem 301. Mapa witryny powinna zawierać wyłącznie kanoniczne adresy URL, które mogą być indeksowane.

Crawl budget: kiedy ma znaczenie

Budżet indeksowania (crawl budget) to liczba podstron, które Googlebot może przeskanować w Twoim serwisie w określonym czasie; dla większości małych stron nie stanowi problemu, ale w serwisach z ponad 10 000 adresów może decydować o widoczności. Google ustala go dla każdej domeny osobno, biorąc pod uwagę m.in. wydajność serwera i zapotrzebowanie na skanowanie jej treści.

Crawl budget staje się krytyczny w trzech sytuacjach:

1. Sklep z nawigacją fasetową: filtry produktów tworzą tysiące duplikatów adresów (np. /sukienki/?kolor=czerwony&rozmiar=M&sortowanie=cena-asc). Googlebot marnuje budżet na mało wartościowe warianty zamiast na strony kategorii i produktów
2. Serwis z dziesiątkami tysięcy adresów URL: duże portale, serwisy ogłoszeniowe, platformy SaaS
3. Serwis z wieloma błędami 404 i łańcuchami przekierowań: robot traci czas na obsługę błędów

Optymalizacja: blokowanie duplikatów URL przez robots.txt lub canonical, eliminacja redirect chain, przyspieszenie serwera (szybki serwer = więcej crawlów w oknie), usunięcie zbędnych stron z indeksu (noindex lub 301 na kanoniczną wersję).

Architektura strony i struktura URL

Architektura serwisu, czyli sposób łączenia stron linkami, decyduje o tym, jak głęboko Googlebot wejdzie w serwis i które podstrony uzna za najważniejsze. Zasada płaskiej architektury: każda podstrona powinna być dostępna najwyżej w 3–4 kliknięciach od strony głównej. Podstrony głębiej w hierarchii są rzadziej skanowane i mają słabszy wewnętrzny PageRank.

Struktura URL powinna być logiczna, czytelna i zawierać słowa kluczowe. Przykłady:

• Dobry URL: /blog/techniczne-seo/core-web-vitals/
• Zły URL: /index.php?cat=12&id=874&session=abc123

Dobre URL-e: używają myślników (nie podkreślników), są jak najkrótsze przy zachowaniu sensu, zawierają keyword, nie zawierają parametrów sesji ani zbędnych ID.

Architektura to nie tylko kwestia techniczna, ale też sygnał znaczeniowy. Struktura /uslugi/audyt-seo/ pokazuje Google relację między stroną usługi a stroną z listą usług. Właściwa hierarchia pomaga wyszukiwarce zrozumieć tematykę serwisu.

Linkowanie wewnętrzne i strony osierocone

Linkowanie wewnętrzne przekazuje PageRank między podstronami, a strony bez linków wewnętrznych (orphan pages) są dla Googlebota praktycznie niewidoczne. Link wewnętrzny robi dwie rzeczy: prowadzi Googlebota do strony docelowej i przekazuje kontekst przez tekst linku (anchor).

Orphan pages to podstrony bez żadnego linku przychodzącego z innych stron serwisu. Googlebot nie ma jak ich znaleźć (chyba że są w sitemapie, ale wtedy są crawlowane rzadziej i słabiej). W audytach e-commerce orphan pages to najczęściej: stare strony kampanii, produkty wycofane ze sprzedaży (ale nadal aktywne), podstrony dodane przez CMS bez edycji nawigacji.

Jak je wykryć: w Screaming Frog przejrzyj strony bez linków przychodzących albo porównaj eksport skanowania z mapą witryny. W Google Search Console → Strony status „Strona wykryta – obecnie niezindeksowana” często dotyczy właśnie stron osieroconych.

Ścieżka nawigacji (breadcrumbs)

Okruszki (breadcrumbs) pomagają i użytkownikom, i SEO: dla Google są sygnałem hierarchii serwisu, a dla użytkownika ułatwiają orientację w strukturze. Poprawnie wdrożone okruszki z danymi strukturalnymi Schema.org BreadcrumbList pozwalają Google pokazać w wynikach ścieżkę Strona główna > Kategoria > Artykuł zamiast samego adresu, co może poprawić CTR.

Warunek: okruszki muszą odpowiadać rzeczywistej hierarchii adresów i mieć dane strukturalne w JSON-LD albo w mikrodanych. Częsty błąd to okruszki w nawigacji HTML bez danych strukturalnych: Google może je zrozumieć, ale nie ma gwarancji. Poprawność sprawdzisz w teście wyników z elementami rozszerzonymi (Rich Results Test).

Kanonizacja i duplikaty treści

Duplikacja treści, czyli identyczna lub bardzo podobna treść pod wieloma adresami URL, rozmywa sygnały rankingowe i utrudnia Google wybór właściwej strony. Tag canonical wskazuje wyszukiwarce adres preferowany. Skąd biorą się duplikaty w e-commerce: parametry w adresach (sortowanie, filtry, paginacja), wersje z www i bez, HTTP i HTTPS bez przekierowania, adresy z ukośnikiem na końcu i bez.

Trzy mechanizmy, z których trzeba wybrać właściwy:

Canonical to najczęstszy błąd w audytach e-commerce: strona /produkt-x/?kolor=czerwony ma canonical wskazujący na samą siebie, zamiast na /produkt-x/. Efekt: dziesiątki wariantów rywalizujących o tę samą frazę zamiast jednej mocnej strony produktowej.

Szybkość strony i Core Web Vitals

Od 2021 roku Google oficjalnie używa Core Web Vitals jako sygnału rankingowego: trzy wskaźniki (LCP, CLS, INP) mierzą rzeczywiste doświadczenie użytkownika podczas ładowania strony i wpływają na pozycje w wynikach organicznych. Szybkość wpływa też na sprzedaż: wolna strona częściej traci użytkowników przed załadowaniem i rzadziej kończy się zakupem albo zapytaniem. Skalę tego efektu sprawdzaj na danych własnego serwisu, bo badania podają różne wartości dla różnych branż.

Core Web Vitals trzeba sprawdzać dla każdego typu podstrony, nie tylko dla strony głównej. W sklepach internetowych karta produktu z galerią dużych zdjęć często ma znacznie gorszy LCP niż strona główna, a to karty produktów zbierają większość ruchu z wyszukiwarki.

LCP, CLS, INP: co mierzą i jakie są progi

LCP, CLS i INP mierzą trzy różne aspekty odczuwalnej szybkości i każdy wymaga innej optymalizacji.

Najczęstsze przyczyny słabego LCP: nieskompresowane obrazy, wolny TTFB (czas odpowiedzi serwera), brak preloadowania kluczowych zasobów. Słaby CLS: obrazy bez atrybutów width i height, dynamicznie wstrzykiwane reklamy i bannery, czcionki bez font-display: swap. Słaby INP: ciężkie skrypty JS blokujące wątek główny, niezoptymalizowane event listenery.

Optymalizacja obrazów i zasobów

Obrazy są najczęstszą przyczyną słabego LCP. Zmiana formatu na WebP lub AVIF i leniwe ładowanie obrazów poniżej pierwszego ekranu to zwykle najszybsze sposoby na mniejszy transfer bez widocznej utraty jakości. Kolejne obszary optymalizacji:

• Format WebP: średnio o 25–35% mniejsze pliki niż JPEG przy tej samej jakości; dla przeglądarek bez obsługi WebP zapasowy JPEG w elemencie <picture>
• Leniwe ładowanie: loading="lazy" dla wszystkich obrazów poniżej pierwszego ekranu, a loading="eager" i fetchpriority="high" dla głównego obrazu na górze strony (to element LCP)
• Atrybut alt: obowiązkowy dla dostępności (WCAG) i SEO; powinien opisywać obraz, a nie zawierać upchanych fraz
• Minimalizacja CSS i JS: usuń nieużywane reguły CSS (narzędzie Coverage w Chrome DevTools), łącz i zmniejszaj pliki JS
• CDN: skraca czas transferu, bo pliki trafiają do użytkownika z serwera położonego blisko niego
• Pamięć podręczna po stronie serwera: nagłówki Cache-Control i Expires dla zasobów statycznych

Bezpieczeństwo i protokół HTTPS

HTTPS jest sygnałem rankingowym Google od 2014 roku, ale ważniejsze jest poprawne wdrożenie, bo błędne przekierowania przy przejściu z HTTP na HTTPS mogą na wiele tygodni zniszczyć widoczność serwisu. Po przejściu na HTTPS sprawdź przede wszystkim łańcuchy przekierowań, bo to najczęstszy ślad po niedokończonej zmianie.

Certyfikat SSL (dziś standardowo TLS 1.3) zapewnia trzy rzeczy: szyfrowanie przesyłanych danych, potwierdzenie tożsamości serwera i integralność danych. Chrome oznacza strony HTTP jako „Niezabezpieczone”, co obniża zaufanie użytkowników i sprawia, że częściej opuszczają stronę.

Przejście z HTTP na HTTPS, najważniejsze kroki:

1. Zainstaluj certyfikat SSL na serwerze
2. Skonfiguruj pełne przekierowania 301 z HTTP na HTTPS dla wszystkich URL-i (nie tylko strony głównej)
3. Zaktualizuj wszystkie linki wewnętrzne w treści CMS na wersje HTTPS
4. Zaktualizuj atrybut href w sitemapie
5. Dodaj nową właściwość HTTPS w Google Search Console (GSC traktuje HTTP i HTTPS jako osobne serwisy)
6. Sprawdź łańcuchy przekierowań: http:// → https://www. → https:// to już redirect chain, który obniża szybkość i traci link equity

Redirect chain (łańcuch przekierowań) to sytuacja, gdy URL przechodzi przez więcej niż jedno przekierowanie przed dotarciem do miejsca docelowego. Googlebot zwykle podąża za maksymalnie dziesięcioma przekierowaniami, ale każdy dodatkowy krok wydłuża skanowanie i opóźnia przeniesienie sygnałów na adres docelowy. Dlatego łańcuchy skraca się do jednego przekierowania. Znajdziesz je w Screaming Frog w raporcie Redirect Chains.

Meta tagi, dane strukturalne i Schema Markup

Meta tagi (title, description) wpływają na CTR w wynikach, a dane strukturalne Schema.org pomagają Google zrozumieć treść i mogą dać stronie wynik rozszerzony, na przykład z oceną produktu albo ścieżką nawigacji. Meta tagi można poprawić najszybciej i od razu wpływa to na CTR, bez wielomiesięcznego czekania jak przy budowaniu autorytetu domeny.

Zasady meta title:

• 55–65 znaków (Google przycina dłuższe, zazwyczaj po 600px szerokości)
• Zawiera główne słowo kluczowe, najlepiej na początku
• Unikalny dla każdej podstrony, bo powtarzające się tytuły to błąd wykazywany przez narzędzia SEO
• Odzwierciedla intencję zapytania użytkownika

Meta description:

• 120–160 znaków: opis nie jest czynnikiem rankingowym, ale mocno wpływa na CTR
• Powinien zawierać USP i wezwanie do działania
• Google często generuje własne „snippety” z treści, gdy description nie odpowiada zapytaniu

Szerokość tytułu i opisu w pikselach sprawdzisz w liczniku znaków z podglądem wyniku Google. Google ucina tytuł według szerokości, a nie liczby znaków, więc 60 szerokich liter może się nie zmieścić.

Tagi meta robots:

• <meta name="robots" content="noindex, nofollow">: nie indeksuj i nie podążaj za linkami
• <meta name="robots" content="noindex, follow">: nie indeksuj, ale podążaj za linkami (np. strony filtrów)

Dane strukturalne (Schema.org) to kod JSON-LD w <head> dokumentu HTML, który daje Google kontekst treści zrozumiały dla maszyn. Google zaleca JSON-LD, bo nie miesza się z kodem HTML dokumentu. Ważne typy:

• Article: artykuły na blogu (autor, data, obraz)
• FAQPage: opisuje sekcję pytań i odpowiedzi; od 7 maja 2026 r. Google nie pokazuje już na jej podstawie wyników rozszerzonych FAQ
• Product: karty produktów w e-commerce (cena, dostępność, opinie)
• BreadcrumbList: ścieżka okruszków w wynikach wyszukiwania
• LocalBusiness: firmy lokalne (adres, godziny otwarcia, telefon)

Weryfikacja: Google Rich Results Test (search.google.com/test/rich-results) pokazuje, czy schema jest poprawna i kwalifikuje się do rich snippet.

Mobile-first indexing i responsywność

Od 2023 roku Google indeksuje strony wyłącznie w trybie mobile-first: Googlebot widzi Twoją stronę tak jak użytkownik telefonu, dlatego wersja mobilna musi zawierać tę samą treść co wersja na komputery. Google ogłosił zakończenie przechodzenia na indeksowanie mobile-first 31 października 2023 r.

Indeksowanie mobile-first oznacza, że jeśli w wersji mobilnej część treści nie istnieje (np. zakładki widoczne tylko na komputerach), Google może jej nie zaindeksować. Dane strukturalne też muszą być w wersji mobilnej; jeśli są tylko w szablonie na komputery, to za mało.

Częste błędy:

• Szablon responsywny czy adaptacyjny: szablon responsywny (CSS media queries, ten sam HTML) jest bezpieczniejszy niż adaptacyjny (osobny HTML dla telefonu i komputera), w którym łatwo o okrojoną treść w wersji mobilnej
• Meta viewport: <meta name="viewport" content="width=device-width, initial-scale=1"> musi być w <head> każdej strony
• Za małe elementy dotykowe: przyciski i linki mniejsze niż ok. 48 × 48 px trudno trafić palcem; sprawdzisz je w audycie Lighthouse
• Treść we Flashu albo w nieobsługiwanym JS: Googlebot nie renderuje starszych technologii

Weryfikacja: test Lighthouse w Chrome DevTools i tryb urządzenia (Device Toolbar). Raport „Użyteczność na urządzeniach mobilnych” i narzędzie Mobile-Friendly Test Google wycofał 1 grudnia 2023 r.

Narzędzia do technicznego SEO

Techniczne SEO opiera się na narzędziach: Google Search Console to obowiązkowy i bezpłatny punkt startowy, a roboty skanujące, takie jak Screaming Frog, pozwalają przeprowadzić pełny audyt infrastruktury serwisu. W każdym projekcie zaczynam od GSC, bo tylko to narzędzie pokazuje dane z perspektywy samego Google: historię indeksacji, błędy skanowania i Core Web Vitals dla poszczególnych typów stron.

Narzędzia bezpłatne:

Narzędzia płatne:

Podział według zadania: GSC + PageSpeed Insights do codziennego monitoringu, Screaming Frog do audytu jednorazowego lub kwartalnego, Ahrefs/Semrush do analizy konkurencji i linkowania. Lighthouse do szybkiej diagnozy CWV bez zewnętrznych usług.

Audyt techniczny SEO: od czego zacząć

Audyt techniczny SEO sprawdza wszystkie opisane wyżej obszary na Twojej stronie i kończy się listą problemów uporządkowaną według wpływu na widoczność, a nie alfabetyczną listą błędów z narzędzia. Bez takiej kolejności programista nie wie, czy zacząć od canonicali, czy od obrazów, choć wpływ tych zadań na ruch bywa zupełnie inny.

Jeśli chcesz zrobić audyt samodzielnie, skorzystaj z instrukcji audyt techniczny SEO krok po kroku. Problemy ze skanowaniem i indeksacją szczegółowo opisuję w artykule o audycie crawlability i indeksacji. Gdy wolisz zlecić audyt, zakres i przebieg znajdziesz na stronie audytu SEO.

Techniczne SEO dla e-commerce i dużych serwisów B2B

W sklepach internetowych i dużych serwisach B2B techniczne SEO staje się wyzwaniem inżynierskim: tysiące adresów, dynamiczne filtry, karty produktów i wiele wersji językowych tworzą problemy nieznane małym witrynom. Typowe przewodniki „techniczne SEO krok po kroku” ich nie opisują, bo pojawiają się dopiero w serwisach powyżej pewnej skali.

Specyfika dużych serwisów e-commerce:

• Nawigacja fasetowa: filtry produktów (/sukienki/?kolor=czerwony&rozmiar=M) tworzą lawinowo rosnącą liczbę duplikatów adresów. W sklepie z kilkoma tysiącami produktów i kilkunastoma filtrami liczba kombinacji łatwo sięga milionów, a budżet indeksowania kończy się na mało wartościowych wariantach
• Duplikacja treści na masową skalę: opisy produktów skopiowane od dostawcy, identyczne na setkach kart produktów
• Serwisy oparte na JavaScripcie: strony na frameworkach (React, Next.js, Vue) są renderowane przez Google z opóźnieniem. Googlebot renderuje JavaScript w osobnym etapie, po pobraniu HTML, więc treść widoczna dopiero po renderowaniu trafia do indeksu później i łatwiej o błędy
• Budżet indeksowania jako realny problem: przy ponad 100 000 adresów każde zmarnowane skanowanie uszczupla zasoby na indeksację

W sektorach fintech i telekomunikacji dochodzą wymogi regulacyjne: niektóre strony muszą mieć ograniczony dostęp, co wymaga precyzyjnej konfiguracji robots.txt i tagów noindex bez blokowania najważniejszych podstron. Analiza logów serwera (Apache, nginx) jest tu obowiązkowa, bo tylko logi pokazują, co Googlebot naprawdę odwiedza, a co pomija.

Czym różni się w technicznym SEO serwis „mały” od „dużego”: małe strony (do 500 adresów) sprawdzisz według listy kontrolnej bezpłatnymi narzędziami, a duże serwisy B2B i sklepy wymagają stałej pracy inżynierskiej: monitorowania budżetu indeksowania, analizy logów i testów renderowania JS.

Kiedy skalowanie serwisu wymaga specjalisty technicznego SEO

Pięć sygnałów, że samodzielne techniczne SEO przestaje wystarczać i warto zaangażować zewnętrznego specjalistę. W prostych serwisach usługowych (do 200 adresów, statyczny HTML albo prosty WordPress) samodzielna opieka techniczna jest realna, a dla właścicieli stron, którzy chcą opanować podstawy, prowadzę szkolenia SEO. Granica przesuwa się wraz ze wzrostem skali albo złożoności.

Sygnały alarmowe:

1. Serwis z ponad 500 adresami i bez monitorowania budżetu indeksowania: bez narzędzi i wiedzy nie wiesz, które strony Google pomija
2. Planowana migracja albo zmiana marki: zmiana domeny, platformy CMS albo przebudowa strony to najczęstsze momenty utraty widoczności organicznej, a specjalista zapobiega temu planem migracji z przekierowaniami
3. Serwis oparty na JavaScripcie (Next.js, Nuxt, Angular): renderowanie po stronie przeglądarki trzeba testować w GSC i Ahrefs, a naprawa problemów wymaga współpracy specjalisty SEO z programistą
4. Wiele wersji językowych lub krajowych: hreflang, osobne domeny albo subdomeny to obszar, w którym jeden błąd może zablokować widoczność na całym rynku
5. Problemy z Core Web Vitals na dużą skalę: poprawa w serwisie z ponad 10 000 podstron to projekt inżynierski, a nie zmiana kilku ustawień

W złożonych serwisach B2B i e-commerce skorzystaj z usługi technicznego SEO: pomogę zdiagnozować skalę problemu i ustalić priorytety. Artykuł o najczęstszych błędach SEO na polskich stronach pokazuje, które problemy techniczne powtarzają się najczęściej; wiele z nich dotyczy właśnie e-commerce i dużych serwisów. Jeśli chcesz zrozumieć, jak działa ranking, artykuł jak działa SEO dobrze uzupełnia ten przewodnik o warstwę algorytmiczną. Jeśli szukasz usługi obejmującej technikę, treści i linki, sprawdź ofertę pozycjonowania.

FAQ: pytania o techniczne SEO

Co to jest techniczne SEO?

Techniczne SEO to zbiór działań dotyczących infrastruktury strony, a nie treści ani linków, dzięki którym Google może dotrzeć do każdej podstrony, poprawnie ją wyrenderować i zaindeksować. Obejmuje dostępność dla robotów, szybkość ładowania, bezpieczeństwo (HTTPS) i dane strukturalne (Schema.org). Bez solidnej bazy technicznej inwestycja w treści i link building daje znacznie słabsze efekty.

Czym różni się techniczne SEO od on-page SEO?

Techniczne SEO dotyczy infrastruktury (jak Google widzi stronę), a on-page SEO treści (co widzą użytkownik i Google po wyrenderowaniu strony). Techniczne SEO obejmuje robots.txt, mapę witryny, architekturę adresów, szybkość, HTTPS i dane strukturalne. On-page SEO to słowa kluczowe, nagłówki, treść artykułów, meta title i description oraz linkowanie wewnętrzne pod kątem tematyki. Oba działają razem: bez techniki on-page jest nieskuteczne.

Jakie są najważniejsze elementy technicznego SEO?

Dziesięć kluczowych elementów technicznego SEO to: robots.txt, sitemap XML, architektura URL, szybkość ładowania, Core Web Vitals (LCP/CLS/INP), HTTPS, meta tagi, dane strukturalne Schema.org, mobile-first indexing i linkowanie wewnętrzne. Priorytetyzacja zależy od rozmiaru serwisu: dla małej strony zacznij od GSC + HTTPS + szybkość; dla e-commerce priorytetem jest crawl budget i canonical.

Co to są Core Web Vitals?

Core Web Vitals to trzy wskaźniki doświadczenia użytkownika, których Google używa jako sygnału rankingowego od 2021 roku: LCP (Largest Contentful Paint, czas ładowania głównego elementu, próg poniżej 2,5 s), CLS (Cumulative Layout Shift, stabilność układu, próg poniżej 0,1) i INP (Interaction to Next Paint, szybkość reakcji, próg poniżej 200 ms). Dane pochodzą z prawdziwych sesji użytkowników Chrome (CrUX) i z testów laboratoryjnych (PageSpeed Insights). Wyniki dla całego serwisu pokazuje raport Core Web Vitals w Google Search Console.

Jak samemu przeprowadzić audyt techniczny SEO?

Zacznij od raportu Indeksowanie stron w Google Search Console, który pokazuje adresy wykluczone z indeksu i powód wykluczenia. Potem zeskanuj serwis w Screaming Frog (bezpłatnie do 500 adresów), żeby znaleźć błędy w tytułach, przekierowaniach i linkach wewnętrznych. Core Web Vitals sprawdź w PageSpeed Insights dla każdego typu podstrony. Pełną procedurę opisuję w instrukcji audyt techniczny SEO krok po kroku.

Ile kosztuje audyt techniczny SEO?

Cena zależy przede wszystkim od liczby adresów w serwisie i technologii, na przykład renderowania JavaScriptu. U mnie projekt technicznego SEO kosztuje od 1500 zł netto dla serwisu do 500 adresów. Pełne widełki dla większych serwisów znajdziesz w cenniku.

Co to jest crawl budget i kiedy ma znaczenie?

Crawl budget to liczba adresów, które Googlebot może i chce zeskanować w danym czasie. Zależy od wydajności serwera oraz od tego, jak bardzo Google chce aktualizować treści serwisu. Według Google problem dotyczy głównie dużych serwisów, liczonych w setkach tysięcy i milionach adresów, albo takich, w których treść zmienia się bardzo często. W sklepach z filtrami tworzącymi tysiące kombinacji adresów pojawia się wcześniej.

Czym są dane strukturalne (Schema Markup)?

Dane strukturalne to kod JSON-LD w <head> dokumentu HTML, który daje Google zrozumiały dla maszyn kontekst treści: czy to artykuł, kto jest autorem, ile kosztuje produkt. Poprawne dane Schema.org pozwalają stronie na wyniki rozszerzone, np. ścieżkę okruszków albo oceny produktów w gwiazdkach. Poprawność sprawdzisz w teście wyników z elementami rozszerzonymi (Rich Results Test).

Co to jest mobile-first indexing?

Indeksowanie mobile-first oznacza, że Google indeksuje i ocenia strony na podstawie ich wersji mobilnej; Google zakończył przejście na ten sposób indeksowania 31 października 2023 r. Jeśli wersja mobilna ma ukrytą treść, brakujące dane strukturalne albo wolno się ładuje, Google uwzględnia to w wynikach na wszystkich urządzeniach. Wersję mobilną sprawdzisz w Lighthouse i narzędziem Sprawdzanie adresu URL w Search Console.

Jak sprawdzić techniczne SEO swojej strony?

Trzy kroki: (1) Google Search Console → Indeksowanie → Strony, czyli błędy skanowania i luki w indeksacji; (2) PageSpeed Insights na 2–3 najważniejszych podstronach, czyli wyniki Core Web Vitals; (3) Screaming Frog (bezpłatny do 500 adresów): meta tagi, łańcuchy przekierowań, strony osierocone, powtórzone tytuły. Wszystkie są bezpłatne. Pełny obraz sklepu albo serwisu B2B wymaga analizy logów i płatnego narzędzia do skanowania.