SEO techniczne — kompletna checklista 2026
SEO techniczne to optymalizacja infrastruktury strony internetowej — szybkości, indeksowalności, architektury i kodu — tak, aby wyszukiwarki mogły ją efektywnie crawlować, renderować i indeksować.
Czym jest SEO techniczne i dlaczego jest fundamentem?
W audytach, które robimy, powtarza się jeden wzorzec: klient inwestuje w treść i linki, a nikt wcześniej nie sprawdził, czy Google w ogóle widzi to, co powstało. SEO techniczne to fundament, na którym stoi cała reszta — treści, linkowanie, optymalizacja konwersji. Możesz mieć najlepszy treść na świecie, ale jeśli Google nie może go zaindeksować albo strona ładuje się 8 sekund, nikt tego treści nie zobaczy.
Analogia jest prosta: SEO techniczne to jak instalacja elektryczna i hydraulika w domu. Nikt ich nie widzi, ale bez nich dom nie funkcjonuje. Możesz malować ściany i kupować meble (content marketing, link building), ale jeśli nie ma prądu i wody, dom jest bezużyteczny. Problem w tym, że instalację łatwo zignorować właśnie dlatego, że jest niewidoczna — dopóki coś nie przestanie działać.
W 2026 roku SEO techniczne jest ważniejsze niż kiedykolwiek. Strony są bardziej złożone (JavaScript frameworks, SPA, PWA), Google jest bardziej wymagający (Core Web Vitals jako czynnik rankingowy), a konkurencja nie śpi.
Ta checklista zawiera 50+ punktów podzielonych na 7 kategorii — to w praktyce ta sama kolejność, w jakiej sami przechodzimy przez stronę na audycie, nie lista złożona losowo. Możesz jej użyć do samodzielnego audytu albo jako punkt wyjścia do profesjonalnego audytu SEO. Naszą własną stronę trzymamy na tych samych zasadach — kilka punktów niżej pokazujemy dokładnie, które.
1. Crawlability — czy Google może dotrzeć do Twoich stron?
Crawlability to zdolność wyszukiwarki do odkrywania i odwiedzania stron Twojego serwisu. Jeśli Google nie może dotrzeć do strony, nie zaindeksuje jej — niezależnie od tego, jak dobra jest treść.
Robots.txt
- Plik
robots.txtistnieje i jest dostępny pod/robots.txt - Nie blokuje dostępu do ważnych zasobów (CSS, JS, obrazów)
- Nie blokuje stron, które powinny być indeksowane
- Zawiera link do sitemap:
Sitemap: https://arduralab.com/sitemap.xml - Blokuje strony, które NIE powinny być indeksowane (panel admina, wersje testowe, strony z parametrami)
Częsty błąd: Deweloperzy dodają Disallow: / na staging i zapominają usunąć po deploy na produkcję. Jeden wiersz blokuje cały serwis.
Warto przy okazji sprawdzić coś, czego ta checklista formalnie nie wymaga, ale co coraz częściej ma znaczenie: czy robots.txt blokuje crawlery AI (GPTBot, ClaudeBot, PerplexityBot, Google-Extended). U nas te crawlery są wprost dopuszczone obok Googlebota — bo skoro sprzedajemy widoczność w AI, własna strona musi być widoczna dla botów, które tę widoczność w ogóle umożliwiają.
Sitemap XML
- Sitemap XML istnieje i jest poprawny (walidacja w Google Search Console)
- Zawiera TYLKO strony, które powinny być indeksowane (status 200, bez noindex)
- Daty
<lastmod>odpowiadają rzeczywistym zmianom treści (nie dacie generowania sitemap) - Nie zawiera więcej niż 50 000 URL-i (limit Google — podziel na mniejsze pliki)
- Jest zarejestrowana w Google Search Console
- Generuje się automatycznie po dodaniu/usunięciu stron
Crawl budget
- Strona nie generuje nadmiernej liczby URL-i (filtry, sortowania, paginacja)
- Parametry URL nietzorzące unikalnych treści mają
noindexlubcanonical - Przekierowania łańcuchowe (A → B → C) są skrócone do bezpośrednich (A → C)
- Brak pętli przekierowań (A → B → A)
- Strony z kodem 404 nie są linkowane wewnętrznie
2. Indeksowanie — czy Google zaindeksował właściwe strony?
Indeksowanie to proces, w którym Google analizuje treść strony i dodaje ją do swojego indeksu. Strona, której nie ma w indeksie, nie pojawi się w wynikach wyszukiwania.
Status indeksowania
- Sprawdzono raport Coverage/Indexing w Google Search Console
- Wszystkie ważne strony mają status „Valid" (zaindeksowane)
- Strony z „Excluded" mają uzasadniony powód wykluczenia
- Brak nieoczekiwanych stron z
noindex - Test
site:arduralab.comzwraca oczekiwaną liczbę wyników
Jeśli masz problemy z indeksowaniem, sprawdź nasz poradnik o tym, jak przyspieszyć indeksowanie w Google.
Canonical tags
- Każda strona ma tag
<link rel="canonical"> - Canonical URL wskazuje na samą siebie (self-referencing) lub na stronę kanoniczną
- Canonical jest spójny z wersją HTTP/HTTPS i z/bez www
- Strony z parametrami URL mają canonical do wersji bez parametrów
- Canonical jest w
<head>, nie w<body>
Meta robots
- Strony do indeksacji nie mają tagu
noindex - Strony prywatne/techniczne mają
noindex, nofollow - Brak sprzeczności między robots.txt a meta robots (robots.txt blokuje, ale strona nie ma noindex — Google może ją mimo to zaindeksować z innego źródła)
3. Architektura URL i struktura strony
Struktura URL wpływa zarówno na SEO, jak i na doświadczenie użytkownika. Dobrze zaprojektowane URL-e komunikują tematykę strony zanim użytkownik ją kliknie.
URL-e
- URL-e są krótkie, opisowe i zawierają słowa kluczowe
- Używają myślników jako separatorów (nie podkreślników)
- Nie zawierają parametrów sesji, identyfikatorów ani zbędnych katalogów
- Konsystentny trailing slash (albo wszystkie z
/, albo bez) - Brak wielkich liter w URL-ach
- Kodowanie UTF-8 dla polskich znaków (lub transliteracja: ą→a, ś→s)
Nawigacja i linkowanie wewnętrzne
- Każda strona jest osiągalna w max 3 kliknięciach od strony głównej
- Breadcrumbs z danymi strukturalnymi
BreadcrumbList - Nawigacja główna jest crawlowalna (nie jest renderowana wyłącznie przez JavaScript)
- Brak sierocych stron (orphan pages — strony bez żadnych linków wewnętrznych)
- Logiczna hierarchia: strona główna → kategorie → podstrony
Przekierowania
- Stare URL-e mają redirect 301 do nowych
- Brak łańcuchów przekierowań (max 1 hop)
- Brak przekierowań 302 tam, gdzie powinno być 301 (permanentne)
- Strony po redesignie/migracji mają kompletne mapowanie URL old → new
4. Core Web Vitals i wydajność
Od 2021 roku Core Web Vitals są czynnikiem rankingowym. W 2026 wymagania są jeszcze bardziej rygorystyczne — Google premiuje strony, które oferują doskonałe doświadczenie użytkownika. Więcej o wpływie CWV na pozycje znajdziesz w artykule o Core Web Vitals i pozycjonowaniu.
LCP (Largest Contentful Paint)
Cel: poniżej 2.5 sekundy
- Największy element (hero image, nagłówek) ładuje się w poniżej 2.5s
- Hero image ma
preloadw<head> - Obrazy są w nowoczesnych formatach (WebP, AVIF) z fallbackiem
- Krytyczny CSS jest inline'owany w
<head> - Fonty mają
font-display: swapluboptional - Serwer odpowiada w poniżej 600ms (TTFB)
INP (Interaction to Next Paint)
Cel: poniżej 200ms
- Kliknięcia i interakcje reagują w poniżej 200ms
- Brak long tasks (blokujących JavaScript powyżej 50ms) przy ładowaniu
- Event handlers nie wykonują ciężkich operacji na głównym wątku
- Third-party scripts ładują się asynchronicznie
CLS (Cumulative Layout Shift)
Cel: poniżej 0.1
- Obrazy i video mają zdefiniowane wymiary (
widthiheight) - Reklamy i embedy mają zarezerwowane miejsce
- Fonty nie powodują przeskoku layoutu
- Dynamicznie ładowany treść nie przesuwa istniejących elementów
Wydajność ogólna
- Lighthouse Skuteczność score powyżej 90 (mobile)
- GZIP lub Brotli compression włączony na serwerze
- Browser caching skonfigurowany (Cache-Control headers)
- CDN obsługuje statyczne zasoby
- Lazy loading dla obrazów poniżej fold
- Minifikacja CSS i JavaScript
- Brak nieużywanego CSS/JS (tree shaking, code splitting)
5. HTTPS i bezpieczeństwo
HTTPS to czynnik rankingowy od 2014 roku. W 2026 strona bez HTTPS to strona, która nie powinna istnieć w wynikach wyszukiwania — Chrome oznacza ją jako „Niezabezpieczona".
- Cała strona jest na HTTPS (nie tylko logowanie/koszyk)
- Certyfikat SSL jest ważny i nie wygasł
- Brak mixed treść (HTTP zasoby na HTTPS stronie)
- Redirect 301 z HTTP na HTTPS (nie 302)
- Redirect z wersji bez www na wersję z www (lub odwrotnie — konsystentnie)
- HSTS header włączony (Strict-Transport-Security)
- Certyfikat obejmuje wszystkie subdomeny (wildcard lub osobne certy)
6. Dane strukturalne (Schema.org)
Dane strukturalne pomagają Google zrozumieć zawartość strony i mogą generować rich snippets w wynikach wyszukiwania — gwiazdki, FAQ, breadcrumbs, logo. To też jeden z punktów, gdzie łatwo o przesadę — nie każda strona potrzebuje kompletu schematów z listy niżej, a wdrożenie złego typu szkodzi bardziej niż brak schema w ogóle.
Obowiązkowe schema
-
Organization— nazwa firmy, logo, kontakt, social media -
WebSite— z SearchAction dla sitelinks searchbox -
BreadcrumbList— na każdej podstronie -
Article/BlogPosting— na artykułach blogowych -
LocalBusiness— jeśli masz fizyczną lokalizację -
FAQPage— na stronach z sekcją FAQ
Opcjonalne schema (ale wartościowe)
-
HowTo— na poradnikach krok po kroku -
Product— na stronach produktowych (e-commerce) -
Review/AggregateRating— recenzje i oceny -
VideoObject— na stronach z osadzonym video -
SoftwareApplication— dla produktów SaaS
Walidacja
- Schema jest w formacie JSON-LD (preferowany przez Google)
- Walidacja w Google Rich Results Test — brak błędów
- Walidacja w Schema.org Validator — brak ostrzeżeń
- Schema nie zawiera treści niewidocznych dla użytkownika (cloaking)
U nas artykuły blogowe niosą Article, FAQPage i Person — Organization obowiązuje w głównym layoucie na całej witrynie, a Service celowo zostaje tylko na stronach /uslugi, nie na blogu. To rozróżnienie ma znaczenie: mieszanie typów schema tam, gdzie faktycznie ich nie ma, to dokładnie ten błąd, który wyżej nazywamy przesadą.
7. Mobile-first i responsywność
Google indeksuje przede wszystkim wersję mobilną strony. Jeśli Twoja strona wygląda świetnie na desktopie, ale źle na mobile — Google widzi tę złą wersję.
- Strona jest w pełni responsywna (brak osobnej wersji m.arduralab.com)
- Viewport meta tag:
<meta name="viewport" content="width=device-width, initial-scale=1"> - Tekst jest czytelny bez zoomowania (min 16px font-size)
- Przyciski i linki mają wystarczającą strefę dotyku (min 48x48px)
- Brak horizontal scrolling na mobile
- Menu mobilne jest crawlowalne (nie blokowane przez JS)
- Treści są identyczne na mobile i desktop (nie ukrywaj treści na mobile)
- Pop-upy nie blokują treści na mobile (interstitial penalty)
8. JavaScript rendering
Nowoczesne strony często opierają się na JavaScript — React, Next.js, Vue, Angular. Google renderuje JavaScript, ale z opóźnieniem i nie zawsze idealnie. Nasze podejście jest tu bezkompromisowe: własna strona jest zbudowana na Next.js, ale wynikowo generowana jako gotowe, statyczne strony HTML — cały kod źródłowy jest kompletny, zanim jakikolwiek crawler o niego poprosi, więc pytania z listy niżej po prostu nie stanowią u nas ryzyka.
- Treść krytyczna jest dostępna bez JavaScript (SSR lub SSG)
- Linki wewnętrzne używają tagów
<a href>(nie JavaScriptonClicknavigation) - Meta tagi (title, description, canonical) są renderowane server-side
- Dane strukturalne są w HTML (nie generowane client-side)
- Test „View Page Source" pokazuje pełną treść (nie puste
<div id="root"> - Google Search Console → URL Inspection → „View Crawled Page" pokazuje poprawną treść
Narzędzia do audytu SEO technicznego
Samodzielny audyt SEO technicznego wymaga odpowiednich narzędzi. Oto zestawienie — a jeśli mielibyśmy zostawić tylko dwie pozycje z tej tabeli, zostałyby Google Search Console i Screaming Frog. Reszta ułatwia pracę, ale te dwie pokazują, czy Google w ogóle widzi to, co widzisz Ty.
| Narzędzie | Darmowe? | Do czego służy |
|---|---|---|
| Google Search Console | Tak | Indeksowanie, crawl errors, Core Web Vitals, skuteczność |
| Google PageSpeed Wnioski | Tak | Core Web Vitals, Lighthouse score |
| Chrome DevTools | Tak | Rendering, skuteczność, network, Lighthouse |
| Screaming Frog | Do 500 URL | Crawl strony, analiza meta tagów, redirect, hreflang |
| Ahrefs Site Audit | Nie | Kompleksowy audyt techniczny z priorytetyzacją |
| Schema Validator | Tak | Walidacja danych strukturalnych |
| Mobile-Friendly Test | Tak | Test responsywności |
| GTmetrix | Tak | Wydajność, waterfall, Core Web Vitals |
Workflow audytu
- Crawl strony — Screaming Frog lub Ahrefs Site Audit
- Sprawdź indeksowanie — Google Search Console → Coverage
- Przetestuj wydajność — PageSpeed Wnioski na 5 kluczowych stronach
- Zwaliduj schema — Rich Results Test na każdym typie strony
- Sprawdź mobile — Chrome DevTools → Device Mode na 3 rozdzielczościach
- Zweryfikuj przekierowania — mapa starych URL-i + test w Screaming Frog
Priorytety — od czego zacząć?
Nie musisz naprawiać wszystkiego naraz — i szczerze mówiąc, próba naprawienia wszystkiego naraz to najczęstszy powód, dla którego audyty techniczne kończą się na liście w Excelu, a nie na realnych zmianach. Priorytetyzuj według wpływu na ruch:
Priorytet 1 — Krytyczne (rób natychmiast):
- Strony z
noindex, które powinny być indeksowane - Blokady w robots.txt
- Błędy 5xx i 4xx na ważnych stronach
- Brak HTTPS
- Przekierowania łańcuchowe
Priorytet 2 — Wysokie (w ciągu tygodnia):
- Core Web Vitals poniżej progów
- Brak danych strukturalnych
- Duplikaty canonical
- Broken internal links
Priorytet 3 — Średnie (w ciągu miesiąca):
- Optymalizacja sitemap
- Orphan pages
- Optymalizacja obrazów
- Hreflang (jeśli wielojęzyczność)
Priorytet 4 — Ciągłe (monitoring):
- Regularne sprawdzanie Coverage w GSC
- Monitoring Core Web Vitals
- Walidacja schema po zmianach
- Testowanie nowych stron przed publikacją
Podsumowanie
SEO techniczne to nie jednorazowy projekt — to ciągły proces. Algorytmy się zmieniają, strona ewoluuje, nowe strony się pojawiają. Rekomendujemy pełny audyt techniczny co 6 miesięcy i ciągły monitoring w Google Search Console.
Ta checklista to punkt wyjścia, nie substytut audytu — na papierze łatwo odhaczyć wszystkie punkty i wciąż mieć stronę, która traci ruch, bo priorytety były odwrócone. Jeśli chcesz profesjonalny audyt SEO z priorytetyzacją i planem naprawczym, skontaktuj się z nami — przejdziemy przez Twoją stronę punkt po punkcie i pokażemy, co naprawić, żeby Google zaczął Cię kochać.
Powiązane: prowadzisz software house? SEO techniczne to filar 1 — pełna strategia w przewodniku SEO dla software house.