Checklista Technicznego SEO na 2026: 12 elementów, które musisz sprawdzić

1. Core Web Vitals – LCP, INP i CLS

Core Web Vitals to trzy metryki wydajności użytkownika, które Google traktuje jako oficjalny sygnał rankingowy od 2021 roku: LCP (czas renderowania głównego elementu strony), INP (czas reakcji na interakcje) i CLS (stabilność wizualna). Progi „dobrego” wyniku spełniało w sierpniu 2026 r. na telefonach ok. 53% witryn (HTTP Archive, sierpień 2026; rok wcześniej – 48%).

Od marca 2024 INP (Interaction to Next Paint) zastąpił FID (First Input Delay) jako trzecia metryka Core Web Vitals. Sporo agencji i narzędzi monitorujących nadal traktuje tę zmianę pobieżnie, a to istotne niedopatrzenie. INP mierzy latencję wszystkich interakcji na stronie — kliknięcia, tapnięcia, wpisywanie w formularzach — przez cały czas trwania wizyty, nie tylko przy pierwszym kontakcie. To dużo trudniejszy test niż FID.

Sklepy na WooCommerce i PrestaShop szczególnie borykają się z LCP. Duże zdjęcia produktowe bez kompresji, blokujące skrypty analityczne, nieoptymalizowany hosting — potrafią wywindować LCP do 6–8 sekund. 53% wizyt mobilnych jest porzucanych, gdy strona ładuje się dłużej niż 3 sekundy (Google, 2016). Sam skrypt Google Tag Managera załadowany synchronicznie potrafi dodać do czasu renderowania strony głównej 1,5 sekundy — i to za jeden skrypt.

2. Crawl budget i indeksowalność

Crawl budget to liczba stron, które Googlebot jest gotowy przeskanować w Twojej witrynie w danym przedziale czasu. Im większy sklep, tym bardziej krytyczne staje się zarządzanie tym zasobem — nieoptymalizowany katalog z filtrami potrafi zmarnować cały przydział na bezużyteczne, parametryczne adresy URL.

Klasyka gatunku: sklep z 3 000 produktami generuje faktycznie 150 000 unikalnych URL przez kombinacje parametrów filtrowania (kolor=czerwony&rozmiar=L&sortowanie=cena_rosnaco). Google indeksuje te parametryczne adresy, tworzy duplikaty i rozmywa sygnały relevance dla stron kategorii, które powinny rankować. W audytach widzimy ten problem u większości klientów, a jego skala zwykle zaskakuje właściciela sklepu.

Konkretne działania naprawcze:

• Zablokuj parametryczne URL w pliku robots.txt.
• Dodaj rel="canonical" na stronach z filtrami, wskazując na czystą wersję kategorii bez parametrów.
• Usuń z indeksu strony paginacji (/strona-2/, /strona-3/) lub zastosuj canonical wskazujący na pierwszą stronę kategorii.
• Regularnie sprawdzaj Raport Pokrycia Indeksu w GSC – nagły wzrost błędów 404 lub zduplikowanych stron to sygnał marnowania crawl budget.

3. XML Sitemap – co powinna, a czego nie może zawierać

XML Sitemap to mapa drogowa dla Googlebota – informuje, które strony istnieją i kiedy były aktualizowane. Wstawienie URL z noindex, błędami 404 lub nieistniejących przekierowań aktywnie dezorientuje crawler i obniża efektywność indeksowania całej domeny.

Reguły obowiązujące bez wyjątków:

• Sitemap zawiera WYŁĄCZNIE strony, które mają zwracać kod HTTP 200 i nadają się do indeksowania.
• Nigdy nie wstawiaj URL z atrybutem noindex – to sprzeczna instrukcja, którą Google obsługuje nieprzewidywalnie.
• Dla dużych sklepów stosuj sitemap indeksową (plik główny wskazuje na osobne pliki sitemap: produkty, kategorie, blog, strony statyczne).
• Tag <lastmod> ustaw dynamicznie, ale na podstawie faktycznej daty modyfikacji – statyczna data generowana przy każdym odświeżeniu serwera traci wiarygodność.
• Limit jednego pliku sitemap to 50 000 URL lub 50 MB nieskompresowanego pliku.

Po wgraniu lub aktualizacji sitemaps zgłoś ją w Google Search Console (zakładka Sitemaps). Regularnie porównuj liczbę URL przesłanych w sitemap z liczbą faktycznie zaindeksowanych stron — duże rozbieżności zwykle sygnalizują problemy z crawlowalnością lub powieleniem treści.

4. robots.txt – niedoceniana linia obrony i źródło błędów

Plik robots.txt instruuje boty, których obszarów witryny nie powinny odwiedzać. Błędna konfiguracja — zablokowanie folderów z zasobami CSS i JS albo niezablokowanie środowiska staging — potrafi zablokować indeksowanie całych sekcji sklepu lub umieścić w Google wersję testową witryny jako duplikat.

Te same błędy w robots.txt powtarzają się w polskich sklepach wyjątkowo często. Oto najczęstsze:

• Blokowanie plików CSS i JS – Google musi je załadować, aby prawidłowo wyrenderować stronę i ocenić jej strukturę wizualną pod kątem mobile-first.
• Blokowanie /wp-content/uploads/ na WooCommerce – skutkuje wypadnięciem zdjęć produktowych z Google Images i Google Shopping.
• Brak blokady środowisk staging (staging.domena.pl, test.domena.pl) – Google indeksuje wersję testową i traktuje ją jako duplikat produkcji.
• Blokowanie stron kategorii przez przypadkowy wpis Disallow: /kategoria/ zamiast konkretnego parametru.

5. Struktura URL i architektura witryny

Prawidłowa architektura URL przekłada się na równomierne rozłożenie autorytetu domeny, czytelne sygnały tematyczne dla Google i lepsze doświadczenie użytkownika. Płaska hierarchia — maksymalnie 3 poziomy głębokości — to standard dla sklepów z katalogiem do 50 000 produktów.

Google preferuje URL, które są krótkie i opisowe: /buty-sportowe/nike-air-max-270/ zamiast /cat/12/p/4492/?ref=list. Ale to nie tylko kwestia estetyki. Czyste URL ułatwiają linkowanie wewnętrzne, są łatwiej zapamiętywalne i rzadziej modyfikowane przez użytkowników przy ręcznym wpisywaniu.

Dla sklepów migrujących platformę (np. z PrestaShop na Shopify lub z Magento na WooCommerce) architektura URL to najważniejszy element planu migracji. Każdy adres zmieniony bez przekierowania 301 to potencjalna utrata pozycji budowanych latami. I to nie teoria — migracje bez mapy przekierowań potrafią zniszczyć dużą część ruchu organicznego w ciągu kilku tygodni. Dla klienta kariera.pl (obecnie rp.pl/ekonomia/praca) przeprowadzaliśmy migrację domeny z pełnym zachowaniem autorytetu — bo bez precyzyjnej mapy przekierowań lata pozycjonowania idą na marne.

6. HTTPS i sygnały bezpieczeństwa

HTTPS jest sygnałem rankingowym Google od 2014 roku i dziś stanowi absolutne minimum. Samo wdrożenie certyfikatu SSL to jednak nie koniec — mieszana zawartość (mixed content), wygasłe certyfikaty i przestarzałe protokoły TLS niwelują ten atut i sygnalizują brak dbałości technicznej.

W narzędziu SSL Labs Server Test sprawdź, czy certyfikat uzyskuje ocenę A lub A+. Ocena B lub niższa oznacza obsługę przestarzałych protokołów TLS 1.0/1.1 lub słabe zestawy szyfrów. Problem coraz częstszy w sklepach na starszych wersjach PrestaShop i Magento 1.

Nagłówki HTTP, które powinny być skonfigurowane na każdym serwerze produkcyjnym:

• Strict-Transport-Security (HSTS) – wymusza połączenia HTTPS przez zdefiniowany czas i chroni przed atakami downgrade.
• Content-Security-Policy – ogranicza źródła ładowanych zasobów, eliminuje ryzyko wstrzyknięć.
• X-Frame-Options: DENY – zapobiega clickjackingowi.
• Referrer-Policy – kontroluje przekazywanie danych referral do zewnętrznych witryn.

7. Mobile-first indexing – paryteta treści, nie tylko responsywność

Google od 2024 roku indeksuje wyłącznie mobilną wersję witryny. Treść niewidoczna na smartfonie — ukryta w elementach dostępnych tylko na desktopie lub ładowana przez JavaScript w trybie niekompatybilnym z renderowaniem mobilnym — po prostu nie istnieje dla algorytmu.

Mobile-first oznacza, że Google opiera ocenę przede wszystkim na mobilnej wersji treści. Tekst schowany w rozwijanym akordeonie może być indeksowany, jeśli znajduje się w HTML/DOM i użytkownik może go normalnie odsłonić. Problem powstaje wtedy, gdy wersja mobilna usuwa ważną treść, linki, dane strukturalne lub obrazy obecne na desktopie albo ładuje je dopiero po błędzie interakcji. W audycie porównuj parytet informacji, a nie sam fakt użycia przycisku „Czytaj więcej”.

Lista kontrolna dla mobile-first:

• Sprawdź wersję mobilną w Lighthouse lub PageSpeed Insights – Test optymalizacji mobilnej Google wycofał 1 grudnia 2023 r. (Google, kwiecień 2023).
• W GSC użyj narzędzia Inspekcja URL i sprawdź podgląd renderowania w wersji mobilnej dla kluczowych stron kategorii.
• Sprawdź prędkość ładowania w symulacji sieci mobilnej (3G/LTE) w PageSpeed Insights – różni się znacznie od pomiarów na WiFi.
• Przetestuj interaktywne elementy (menu hamburger, filtry, karuzele produktowe) na rzeczywistych urządzeniach – symulatory DevTools nie odwzorowują wszystkich problemów z dotykiem.

8. Dane strukturalne Schema.org

Dane strukturalne w formacie Schema.org to semantyczny język, którym sygnalizujesz Google i modelom AI: „ta strona to produkt, ta strona to recenzja, ta sekcja to FAQ”. Google pisze, że dane strukturalne nie są wymagane w wyszukiwaniu z AI i nie ma specjalnych znaczników schema.org, ale warto je stosować, bo dają szansę na wyniki rozszerzone (Google, lipiec 2026).

Dla sklepów e-commerce priorytetowe typy Schema to: Product (cena, dostępność, ocena, marka, SKU), BreadcrumbList (ścieżka nawigacji widoczna w SERP), Organization i LocalBusiness (budowa profilu encji marki w Knowledge Graph) oraz AggregateRating – gwiazdki w wynikach wyszukiwania. Google podaje, że Nestlé zmierzył o 82% wyższy CTR stron wyświetlanych jako wyniki rozszerzone, a Rotten Tomatoes – o 25% wyższy CTR stron z danymi strukturalnymi (Google Search Central).

Bez poprawnego Product Schema sklep nie kwalifikuje się do rich results produktowych ani Google Shopping. To nie opcja — to techniczny wymóg widoczności w e-commerce.

Walidację implementacji Schema przeprowadź w Rich Results Test i monitoruj raport Wzbogacone wyniki w Google Search Console. Błędy w Schema nie blokują indeksowania, ale eliminują stronę z rich results.

9. Canonical i duplicate content – najczęstsze źródło utraty widoczności

Tag canonical (rel="canonical") wskazuje Google, która wersja URL jest „oryginałem” w przypadku podobnych lub identycznych treści. Bez niego Google sam wybiera preferowany URL — często błędnie, faworyzując parametryczne wersje stron zamiast czystych adresów kategorii.

Źródła duplikatów w sklepach e-commerce, o których właściciele często nie mają pojęcia:

• Strona główna dostępna pod czterema adresami: http://, https://, z www. i bez www. – każdy bez przekierowania 301 to osobny duplikat.
• Opisy producenta skopiowane do setek produktów tej samej kategorii – algorytm dewaluuje te strony jako low-value content.
• Warianty produktów (rozmiar S/M/L/XL, kolor czerwony/niebieski) z odrębnymi URL i identycznym opisem.
• Strony generowane przez tagi, archiwa dat i autorów w WordPressie – często indeksowane bez jakiejkolwiek kontroli.
• Wydruk strony (/print/ lub ?format=print) dostępny w indeksie.

10. Internal linking i przepływ link equity

Internal linking to strategiczna dystrybucja autorytetu domeny wewnątrz witryny. Google traktuje linki wewnętrzne jako sygnał ważności i tematycznej relevance — strony z większą liczbą linków wewnętrznych są postrzegane jako priorytetowe. W dużych sklepach to decyzja architektoniczna, nie spontaniczny zabieg redakcyjny.

Strony głęboko zagnieżdżone w strukturze (4–5 kliknięć od strony głównej) rzadko osiągają wysokie pozycje, nawet jeśli mają silne backlinki i dobrą treść, ponieważ Google interpretuje tę głębokość jako niski priorytet. Mechanizmy, które poprawiają sytuację:

• Linkowanie z kart bestsellery i nowości do kategorii nadrzędnych – strony produktów generują dużo ruchu, ich linki wewnętrzne mają realną wartość dla algorytmu.
• Breadcrumbs z linkami – każdy element nawigacji okruszkowej to dodatkowy link wewnętrzny z kontekstem semantycznym (BreadcrumbList Schema).
• Sekcje „Powiązane produkty” i „Klienci kupili też” – nie tylko UX, ale też mechanizm dystrybucji link equity do długiego ogona katalogu.
• Artykuły blogowe linkujące do stron kategorii – treść ekspercka buduje autorytet tematyczny i przekazuje go na strony komercyjne.

W SEO dla sklepów e-commerce audyt struktury linkowania wewnętrznego to jeden z pierwszych elementów analizy. Bardzo często przynosi szybkie efekty widocznościowe bez tworzenia nowych treści ani pozyskiwania backlinków, a więc bez dodatkowego budżetu.

11. Renderowanie JavaScript – ukryty wróg indeksowania

Google renderuje JavaScript, ale robi to dwuetapowo: najpierw skanuje surowy HTML, potem — z opóźnieniem sięgającym kilku godzin lub dni — wykonuje JavaScript. Treść dostępna wyłącznie po uruchomieniu JS może być przez ten czas kompletnie niewidoczna dla algorytmu.

To problem szczególnie dotkliwy w aplikacjach Single Page Application (SPA) budowanych w React, Vue.js lub Angular, gdzie całe drzewo DOM generowane jest przez skrypty po załadowaniu strony. Sklepy na headless commerce (Next.js + WooCommerce, Shopify Hydrogen, Gatsby + Strapi) wymagają tu szczególnej weryfikacji — nowocześniejsza architektura nie oznacza automatycznie lepszej indeksowalności.

Jak sprawdzić, czy renderowanie JS jest problemem na Twojej witrynie:

1. W Google Search Console użyj funkcji Inspekcja URL → kliknij „Prześlij do indeksu” → sprawdź zakładkę „Więcej informacji” z podglądem wyrenderowanej strony.
2. Porównaj źródło HTML (Ctrl+U w przeglądarce) z wyrenderowaną strukturą DOM (DevTools → zakładka Elements). Treści widoczne w DOM, ale nieobecne w źródle HTML, są generowane przez JavaScript.
3. W Screaming Frog SEO Spider uruchom crawl z włączonym renderowaniem JavaScript i porównaj wyniki z crawlem bez renderowania – różnice w liczbie wykrytych linków wewnętrznych, nagłówków i treści wskazują na skalę problemu.

Rozwiązaniem jest SSR (Server-Side Rendering) lub SSG (Static Site Generation) – strona dostarczana jest Googlebotowi w pełnym HTML przed wykonaniem JavaScript, co eliminuje ryzyko dwuetapowego opóźnienia indeksowania.

12. Optymalizacja pod AI Overview i wyszukiwanie generatywne

AI Overview to synteza odpowiedzi generowana przez Google na podstawie wybranych witryn, wyświetlana coraz częściej powyżej tradycyjnych wyników organicznych. Bycie cytowanym w AI Overview wymaga spełnienia technicznych warunków: semantycznego podziału treści na odpowiedzi i szybkiego TTFB serwera.

Do standardowego technicznego SEO dochodzi obecnie warstwa GEO (Generative Engine Optimization) — optymalizacja pod modele generatywne — i AEO (Answer Engine Optimization) — optymalizacja pod odpowiedzi bezpośrednie silników takich jak Perplexity, ChatGPT Search czy Microsoft Copilot. To już teraźniejszość, nie przyszłość. W polskich domenach o stabilnych pozycjach mediana spadku kliknięć z Google wyniosła 19,9% r/r w sierpniu–październiku 2025 r. (Senuto, listopad 2025; 1 442 domeny), a blisko 38% polskich sklepów internetowych nie pojawia się w rekomendacjach generowanych przez AI (Harbingers, maj 2025). Firmy, które zignorują ten trend, oddadzą kliknięcia konkurencji.

Techniczne wymagania dla widoczności w AI Overview i modelach generatywnych:

• Szybki TTFB (Time to First Byte) – poniżej 800 ms. Wolne serwery są pomijane przez crawlery AI przy agregacji odpowiedzi.
• Treść dostępna w statycznym HTML – bez konieczności renderowania JavaScript (patrz punkt 11).
• Semantyczne nagłówki H2/H3 odpowiadające na konkretne pytania użytkowników – modele AI wycinają „chunki” odpowiedzi z dobrze ustrukturyzowanych artykułów.
• Sekcje FAQ na stronach produktowych i kategorii – AI Overview często cytuje właśnie sekcje FAQ jako gotowe odpowiedzi na zapytania informacyjne powiązane z produktem.
• Autorstwo i E-E-A-T – linki do profili autora, adres fizyczny organizacji w Schema, opinie zewnętrzne budują sygnały zaufania, które modele AI uwzględniają przy wyborze źródeł.

Kompleksową strategię widoczności w AI znajdziesz w ofercie pozycjonowania w AI – podejście łączące techniczną optymalizację GEO/AEO z pracą nad treścią, tak by witryna była widoczna zarówno w tradycyjnych wynikach, jak i w odpowiedziach modeli językowych.