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 są egzekwowane coraz rygorystyczniej, a tylko 48% stron mobilnych na świecie je spełnia (HTTP Archive, 2025).

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. Błąd. 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. A strona ładująca się ponad 3 sekundy traci 53% użytkowników mobilnych (Google / Think with Google). Sam skrypt Google Tag Managera załadowany synchronicznie potrafi dodać 1,5 sekundy do czasu renderowania strony głównej. Półtorej sekundy. 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ć. Widzimy to u większości klientów, których audytujemy — i za każdym razem skala problemu zaskakuje właściciela sklepu.

Konkretne działania naprawcze:

• Zablokuj parametryczne URL w pliku robots.txt lub skonfiguruj obsługę parametrów w Google Search Console.
• 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? To niemal pewny sygnał problemów 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.

Ile razy widzieliśmy te same błędy w robots.txt polskich sklepów? Za dużo, żeby liczyć. 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ć 30–60% 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 to nie responsywny design. To pełna paryteta treści między wersją desktop a mobilną. Bo jak wygląda częsty scenariusz? Sklepy, które na desktopie mają rozbudowane opisy kategorii (500+ słów kluczowych długiego ogona), na mobile skracają je do 50 słów albo całkowicie ukrywają za przyciskiem „Czytaj więcej”. A ta ukryta treść? Google jej nie widzi przy rankingowaniu fraz. I to nie spekulacja — widzieliśmy spadki pozycji bezpośrednio powiązane z tym jednym błędem.

Lista kontrolna dla mobile-first:

• Przetestuj witrynę w Google Mobile-Friendly Test i napraw wszelkie błędy dostępności.
• 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 – fundament widoczności w AI

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”. Dane strukturalne decydują obecnie nie tylko o rich snippets, ale też o cytowaniach w AI Overview i odpowiedziach silników generatywnych.

Dla sklepów e-commerce priorytetowe typy Schema to: Product (cena, dostępność, ocena, marka, SKU), BreadcrumbList (ścieżka nawigacji widoczna w SERP), FAQPage (rozwijane pytania i odpowiedzi poszerzające wynik), Organization i LocalBusiness (budowa profilu encji marki w Knowledge Graph) oraz AggregateRating – gwiazdki w wynikach wyszukiwania zwiększają CTR średnio o 15–25% w porównaniu z wynikami bez ocen.

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

„Adding Schema (structured data) helps search engines interpret your content and can trigger rich results. It’s an important technical SEO tactic for enhancing visibility in AI Search.”

(pol. Dane strukturalne pomagają wyszukiwarkom zinterpretować treść. To ważna taktyka technicznego SEO dla widoczności w AI Search.)

Solis trafia w sedno — i na polskim rynku widać to już w danych. AIO pojawia się w 24,17% polskich zapytań Google (Senuto, analiza 17,7 mln słów kluczowych, 2025/2026), a strony w top 3 Google dostarczają 65,9% wszystkich źródeł cytowanych w AIO (Senuto, 2025). Nie masz Schema? Nie będziesz cytowany. Proste.

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 i z odpowiedzi AI Overview.

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ść. Dlaczego? Bo Google interpretuje 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. I bardzo często przynosi szybkie efekty widocznościowe bez konieczności tworzenia nowych treści ani pozyskiwania backlinków. Zero dodatkowego budżetu, a wyniki w ciągu tygodni.

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.

„If Googlebot can’t see it, it doesn’t exist.”

(pol. Jeśli Googlebot tego nie widzi, to nie istnieje.)

Splitt nie przesadza. 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 — bo nowocześniejsza architektura nie oznacza automatycznie lepszej indeksowalności. Kiedyś też tak myśleliśmy. Kosztowało to klienta trzy miesiące opóźnionego indeksowania nowych produktów.

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, szybkiego TTFB serwera i poprawnych danych strukturalnych.

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 nie przyszłość. To teraźniejszość. Na polskim rynku spadek CTR po wdrożeniu AIO wyniósł średnio -19,4% rok do roku (Senuto / PurePC, analiza 1435 domen, 2025), a 38% polskich e-commerce w ogóle nie pojawia się w odpowiedziach AI (Harbingers, 2025). Ci, którzy zignorują ten trend, po prostu 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.
• FAQ Schema 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 AI Visibility Stack Westom – 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.