techniczne SEO

Techniczne SEO 2026 – lista kontrolna optymalizacji strony

/ Techniczne SEO, SEO – Podstawy / Przez

Techniczne SEO to fundament, bez którego reszta pracy uderza w ścianę. Najlepsza treść, najsilniejsze linki i dopracowany E-E-A-T nic nie dadzą, jeśli Googlebot nie może strony zcrawlować, zindeksować i zrenderować. W 2026 roku poprzeczka techniczna wzrosła: Core Web Vitals z INP, mobile-first jako standard, schema dla wszystkiego, HTTPS oczywisty.

Ten artykuł to pełna lista kontrolna technicznego SEO z priorytetami, narzędziami i konkretnymi akcjami. Uzupełnia przewodnik SEO podstawy, który łączy tematy w jedną strategię.

W skrócie

  • Top 3 obszary: Core Web Vitals, mobile-first, schema + sitemapa.
  • W 2026 INP zastąpił FID w CWV – nowy parametr bywa 2-3x trudniejszy.
  • Mobile-first oznacza, że Google indeksuje mobilną wersję, nie desktopową.
  • Sitemapa + robots.txt + canonical = trzy pliki, które musi obsłużyć każda domena.
  • Lista kontrolna zawiera 40+ punktów z priorytetami (P0/P1/P2).

Core Web Vitals 2026 – cele i jak je osiągnąć

Core Web Vitals to trzy metryki jakości doświadczenia. Od marca 2024 INP zastąpił FID. Cele:

Metryka Dobre Źle Główna przyczyna
LCP < 2.5s > 4.0s Wolny serwer, duże obrazy
INP < 200ms > 500ms Ciężki JS, third-party scripts
CLS < 0.1 > 0.25 Przesuwające się obrazy, reklamy

LCP – największy widoczny element

Optymalizacja LCP:

  1. Szybki hosting (LiteSpeed, Cloudflare Argo) – TTFB < 200ms.
  2. Obrazy WebP / AVIF, loading="eager" dla hero, fetchpriority="high".
  3. Preload krytycznych zasobów (<link rel="preload">).
  4. Inline CSS krytyczny (above-the-fold).
  5. Cache statycznych zasobów na 1 rok.
  6. CDN dla obrazów i CSS / JS.

INP – responsywność w 2026

INP mierzy opóźnienie najwolniejszej interakcji. Cele 200ms są znacznie trudniejsze niż 100ms dla FID. Optymalizacja:

  1. Code splitting – ładujcie tylko to, co potrzebne.
  2. Defer dla non-critical JS.
  3. Usuwanie blocking third-party (chat widgets, social embeds).
  4. Web Workers dla ciężkich obliczeń.
  5. Optymalizacja event handlerów (debounce, throttle).

CLS – stabilność layoutu

  1. Zawsze definiujcie width i height obrazów i iframe.
  2. Rezerwujcie miejsce na reklamy i embedy.
  3. Używajcie font-display: optional lub swap z poprawnym preload.
  4. Unikajcie DOM injection po loadzie (np. cookies banner na środku).

Mobile-first – nie desktop-first

Od 2019 Google indeksuje mobilną wersję strony. W 2026 to standard dla 100% nowych domen. Najczęstsze problemy mobile-first:

  • Treść dostępna tylko na desktop (widoczność media query).
  • Obrazy nie-responsywne (lazy loading blokujący LCP).
  • Czcionki zbyt małe (minimum 16px dla body text).
  • Przyciski zbyt blisko siebie (minimum 48x48px touch target).
  • Popupy utrudniające użytkowanie (Google Intrusive Interstitials Update).
  • Brak viewport meta (<meta name="viewport" content="width=device-width, initial-scale=1">).

Weryfikacja: Mobile-Friendly Test, Lighthouse, PageSpeed Insights (osobna zakładka Mobile / Desktop).

HTTPS i bezpieczeństwo – sygnały zaufania

HTTPS to ranking signal od 2014. W 2026 brak HTTPS = automatyczne dewaluacja o 10-30% we wszystkich zapytaniach. Checklist:

  1. Certyfikat SSL aktywny (Let’s Encrypt – darmowy, odnawia się automatycznie).
  2. Wszystkie zasoby (obrazy, skrypty, iframe) ładowane przez HTTPS.
  3. HSTS header (Strict-Transport-Security).
  4. Przekierowanie 301 z HTTP na HTTPS.
  5. Bez mixed content warnings (czyści w Chrome DevTools).
  6. Aktualny TLS 1.2+ (TLS 1.0, 1.1 wyłączone).

Bonus 2026: HTTP/3 (QUIC) przyspiesza stronę o 5-15%. Cloudflare, Fastly i niektóre hostingi (LiteSpeed) oferują z pudełka.

Sitemapa XML – zasady poprawnego ustawienia

Sitemapa w WordPressie generowana automatycznie przez RankMath, Yoast, AIOSEO. Sprawdzajcie co miesiąc:

  1. URL do sitemapy w robots.txt: Sitemap: https://example.com/sitemap_index.xml.
  2. Sitemapa zgłoszona w Search Console i Bing Webmaster Tools.
  3. Zero URL-i z 4xx/5xx w sitemapie.
  4. Tylko indeksowalne URL-e (nie noindex).
  5. Max 50 000 URL na plik, 50 MB niekompresowany.
  6. Aktualny lastmod dla zmienianych stron.
  7. Podział tematyczny dla dużych stron (post-sitemap, product-sitemap, category-sitemap).

Robots.txt – krótki plik, wielki efekt

Plik /robots.txt to pierwsza rzecz, którą Googlebot sprawdza. Typowe dla WordPressa:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /*?replytocom
Disallow: /*?s=
Sitemap: https://example.com/sitemap_index.xml

Najczęstsze błędy:

  • Disallow: / zostawiony po dev -> prod.
  • Blokada folderu z CSS/JS – Google nie może renderować (ważne od mobile-first update).
  • Brak sitemapy.
  • Sprzeczne Allow / Disallow.

Szczegółowa mechanika robots.txt i sitemapy jest w przewodniku po crawlowaniu i indeksowaniu.

Schema.org – dane strukturalne, które warto wdrożyć

Schema to kod JSON-LD opisujący zawartość. W 2026 kluczowe typy:

Typ schema Kiedy używać Efekt SERP
Article / BlogPosting Artykuły, posty blogowe Data, autor w SERP
Product Karty produktów Cena, gwiazdki, dostępność
Organization Strona główna firmy Knowledge Panel
LocalBusiness Lokalne firmy Mapa + 3-pack
Person Strona autora Wzmocnienie E-E-A-T
FAQPage Sekcja FAQ Ograniczone do gov/health, ale pomaga LLM
Breadcrumb Ścieżka nawigacji Breadcrumb w SERP zamiast URL
HowTo Procedury krok po kroku Ograniczone w 2023
Review Recenzje produktów Gwiazdki w SERP

Weryfikacja: Google Rich Results Test. Raport „Dane strukturalne” w Search Console pokazuje, co Google rozpoznał.

URL – struktura, która nie szkodzi

Dobry URL w 2026:

  • Krótki (poniżej 75 znaków).
  • Ze słowem kluczowym.
  • Bez parametrów, ID, dat.
  • Polskie znaki transliterowane (aelnoszcz zamiast ąęńłóśćźż).
  • Myślniki zamiast podkreślników.
  • Małe litery (Google traktuje ABC i abc jako różne URL).
  • Logiczna hierarchia: /kategoria/podkategoria/post/.

Złe URL do unikania:

  • /?p=123 (domyślny WP przed włączeniem pretty permalinks).
  • /2026/04/20/tytul-artykulu/ (data w URL – szkodzi świeżości).
  • /kategoria/kategoria/produkt/ (duplikat).
  • /blog_kat/moj_artykul_o_seo/ (podkreślenia).

Canonical – jedna prawda na grupę duplikatów

Tag <link rel="canonical"> mówi Google, która wersja strony jest „kanoniczna”. Reguły 2026:

  1. Self-canonical dla każdej strony.
  2. Warianty produktu -> produkt główny.
  3. Paginacja: strona 2+ -> strona 1 (alternatywa: noindex na strony 2+).
  4. Drukowalne wersje -> wersja web.
  5. Identyczna treść na różnych domenach -> oryginał.

Błędy: canonical do 404, łańcuchowy canonical (A->B->C), canonical do noindex, różne canonicals w HTML i HTTP header.

Szybkość – optymalizacja 2026

Poza Core Web Vitals warto optymalizować także:

  • TTFB (Time to First Byte) – poniżej 200ms na mobile, 100ms na desktop.
  • Speed Index – poniżej 3s.
  • Total Blocking Time (TBT) – poniżej 200ms.
  • Payload – strona startowa poniżej 2MB, artykuł poniżej 3MB.

Narzędzia: PageSpeed Insights, GTmetrix, WebPageTest, Lighthouse (wbudowany w Chrome DevTools).

CDN i hosting – infrastruktura, która robi różnicę

Hosting to fundament technicznego SEO. W 2026 rekomendacje:

Typ witryny Hosting CDN
Blog do 10 tys. wizyt/mc SiteGround, Dreamhost Cloudflare Free
Blog 10-100 tys./mc Kinsta, WP Engine, Cloudways Cloudflare Pro
Sklep e-commerce Nexcess, Rocket.net, Pressable Cloudflare Argo
Portal 500 tys.+/mc Dedykowany VPS + LiteSpeed Cloudflare Enterprise / Fastly

LiteSpeed Cache + Cloudflare to kombinacja, która wyciąga 90%+ zielonych CWV nawet dla ciężkich motywów.

Obrazy – największe źródło kilobajtów

Obrazy to zwykle 60-80% rozmiaru strony. Optymalizacja:

  1. Format: WebP (domyślny), AVIF (jeszcze mniejszy), PNG tylko dla grafik z przejrzystością, SVG dla ikon.
  2. Rozmiar: zdjęcia 1920px szerokości max, kompresja 80% jakości.
  3. Lazy loading: loading="lazy" dla obrazów poniżej fold.
  4. Responsive images: srcset dla różnych rozmiarów ekranu.
  5. Alt text: opis obrazu (nie focus keyword stuffing).

Pluginy WP do optymalizacji: ShortPixel, Imagify, EWWW, Smush.

Cache – warstwy, które przyspieszają

Cache ma kilka warstw:

  1. Browser cache – nagłówki Cache-Control: max-age=31536000 dla statycznych zasobów.
  2. Page cache – cały HTML cachowany (WP Rocket, LiteSpeed Cache).
  3. Object cache – zapytania DB cachowane (Redis, Memcached).
  4. CDN cache – zasoby na edge serwerach Cloudflare.
  5. Opcode cache – skompilowane PHP (OPcache, domyślnie w nowych PHP).

Przy dobrze skonfigurowanym cache generowanie strony trwa 10-50ms zamiast 200-800ms.

Lista kontrolna – 40 punktów z priorytetami

P0 – must have:

  1. HTTPS z HSTS.
  2. Mobile-friendly test – zielony.
  3. Sitemapa XML zgłoszona w GSC i BWT.
  4. Robots.txt bez pomyłek.
  5. Core Web Vitals – LCP < 2.5s, INP < 200ms, CLS < 0.1.
  6. Schema Article lub BlogPosting na postach.
  7. Schema Organization na stronie głównej.
  8. Canonical na każdej stronie.
  9. Meta tytuł i opis na każdej ważnej stronie.
  10. 404 handler z linkami do popularnych stron.

P1 – should have:

  1. Schema Breadcrumb.
  2. Schema Person dla autorów.
  3. Schema Product / LocalBusiness (w zależności od typu).
  4. Lazy loading obrazów.
  5. WebP / AVIF obrazy.
  6. Minifikacja CSS i JS.
  7. Gzip / Brotli kompresja.
  8. CDN dla statycznych zasobów.
  9. Preload krytycznych zasobów.
  10. 404 Gone (status 410) dla trwale usuniętych.

P2 – nice to have:

  1. HTTP/3 (QUIC).
  2. IndexNow dla Binga.
  3. Open Graph + Twitter Cards.
  4. Favicon multi-size.
  5. Manifest PWA (dla niektórych typów).
  6. Service Worker dla offline.
  7. WebSub / PubSubHubbub dla RSS.
  8. Schema ImageObject z licensem.
  9. Hreflang dla międzynarodowych.
  10. Security headers (CSP, Referrer-Policy).

Narzędzia do technicznego SEO

  • Google Search Console – oficjalny punkt odniesienia.
  • PageSpeed Insights – Core Web Vitals.
  • Lighthouse – audyt techniczny (Chrome DevTools).
  • Screaming Frog – crawler lokalny (do 500 URL free).
  • Sitebulb – crawler z wizualizacjami.
  • Ahrefs / Semrush – audyt techniczny wbudowany.
  • Rich Results Test – walidacja schema.
  • Mobile-Friendly Test – testy mobilne.
  • GTmetrix / WebPageTest – szczegółowa analiza szybkości.

Częste błędy techniczne – lista anty-wzorców

  1. JavaScript SPA bez SSR – Google widzi pustą stronę.
  2. Meta tag noindex przez pomyłkę na produktach.
  3. Canonical wskazujący na homepage dla wszystkich stron.
  4. Sitemapa ze starymi URL-ami 404.
  5. Robots.txt blokujący CSS/JS.
  6. Brak mobile viewport meta.
  7. Duże obrazy bez kompresji (5+ MB).
  8. Wolny serwer (TTFB > 1s).
  9. Pop-upy blokujące content na mobile.
  10. Content migotający (CLS > 0.25).
  11. Mixed content warnings.
  12. Certyfikat SSL wygasł.

Pagespeed optymalizacja pod 2026 – przypadek bloga

Case study: blog z WordPressem, motyw Astra Pro, 12 000 sesji miesięcznie. Start: LCP 3.8s (mobile), INP 420ms, CLS 0.18. Po 3 tygodniach optymalizacji: LCP 1.9s, INP 140ms, CLS 0.04. Co konkretnie zrobiliśmy:

  1. Migracja z Hetzner shared na Cloudways Vultr HighFreq (-600ms TTFB).
  2. LiteSpeed Cache zamiast WP Super Cache (-400ms czas ładowania).
  3. ShortPixel konwersja wszystkich obrazów do WebP (45% redukcji rozmiaru).
  4. Usunięcie Facebook Pixel i Hotjar (oba niepotrzebne dla bloga), -180ms INP.
  5. Perfmatters plugin do selektywnego ładowania JS (-120ms INP).
  6. Dodanie fetchpriority=high do hero image każdego artykułu (-400ms LCP).
  7. Preload Google Fonts z font-display: swap (zlikwidowało CLS fontów).
  8. Cloudflare Pro z APO (+30% cache hit rate).

Koszt miesięczny wzrósł ze 180 zł do 350 zł, czyli 94% więcej. Efekt: ruch organic +38% w 90 dni, przychody z afiliacji +62% (lepsza konwersja z szybszej strony).

Security headers – bezpieczeństwo jako sygnał Trust

Nowoczesne security headers podnoszą bezpieczeństwo strony i działają jako pośredni sygnał Trust. Pięć nagłówków wartych wdrożenia:

  1. Strict-Transport-Security (HSTS) – wymusza HTTPS. max-age=31536000; includeSubDomains; preload.
  2. Content-Security-Policy (CSP) – whitelist zewnętrznych zasobów.
  3. X-Frame-Options: SAMEORIGIN – chroni przed clickjackingiem.
  4. X-Content-Type-Options: nosniff – blokuje MIME sniffing.
  5. Referrer-Policy: strict-origin-when-cross-origin – kontrola wycieku Referrer.

Weryfikacja: securityheaders.com (scan + grade A+ jako target). Pluginy WP: „HTTP Headers” albo konfiguracja na poziomie serwera (.htaccess, nginx.conf, Cloudflare Transform Rules).

Optymalizacja bazy danych WP

W WordPressie baza MySQL puchnie z czasem: revisions postów, trash, spam comments, transients, nieużywane metadane. Duża baza = wolniejsze zapytania = wyższy TTFB = gorszy LCP.

Czystka raz na kwartał:

  1. Usuń revisions (WP Optimize: „Optimize database”).
  2. Usuń spam i trash z komentarzy.
  3. Usuń expired transients.
  4. Optymalizuj tabele (OPTIMIZE TABLE wp_posts).
  5. Limit revisions na przyszłość: define('WP_POST_REVISIONS', 3); w wp-config.

Dla dużych sklepów (10k+ produktów, 100k+ postów meta) rozważcie Object Cache (Redis) – zapytania DB z 50ms spadną do 2-5ms.

PWA – czy warto w 2026

Progressive Web App to technika, która przekształca stronę w aplikację (oznacza, że można ją „zainstalować” na telefonie). Dla SEO bezpośrednio niewiele daje, ale poprawia UX, co pośrednio wpływa na ranking.

Kiedy warto: sklepy e-commerce (zwroty, retargeting przez push notifications), portale newsowe (oflline reading), aplikacje B2B (login flows). Kiedy nie warto: klasyczne blogi, landing pages, strony firmowe.

Koszt wdrożenia PWA: 1-5 dni developera. Komponenty: manifest.json, service worker, HTTPS (wymagane), ikony w różnych rozmiarach.

Audyt techniczny – plan na 1 dzień

Jeśli macie 8 godzin na audyt techniczny SEO, oto optymalny plan:

  1. Godz. 1-2: Crawl w Screaming Frog (do 500 URL free). Lista błędów: 404, 5xx, redirects, meta tagi.
  2. Godz. 3: PageSpeed Insights dla 5 najważniejszych URL. Lista poprawek CWV.
  3. Godz. 4: Search Console – raporty Indeksowanie, Core Web Vitals, Usability.
  4. Godz. 5: Rich Results Test dla próbki URL. Weryfikacja schema.
  5. Godz. 6: Mobile-Friendly Test, Chrome DevTools Lighthouse na mobile.
  6. Godz. 7: Analiza sitemapy (walidacja, liczba URL, lastmod).
  7. Godz. 8: Zestawienie wyników + plan naprawy z priorytetami P0/P1/P2.

Migracja strony – najczęstszy moment gdzie SEO umiera

Migracje strony (nowa domena, nowy CMS, nowa struktura URL) to najczęstsza przyczyna nagłego spadku ruchu o 50-80%. Plan migracji wymaga metodyczności.

Minimalna lista przed migracją:

  1. Backup wszystkiego – baza, pliki, konfiguracje.
  2. Mapa redirectów 301 – każdy stary URL do nowego odpowiednika.
  3. Crawl przed migracją – Screaming Frog, export z sitemap.
  4. Pre-live test – staging z nową wersją, audyt techniczny.
  5. Plan rollback – co robić, jeśli coś pójdzie nie tak.
  6. Komunikacja do Google – Change of Address w Search Console.

Po migracji:

  1. Monitoring indeksacji nowych URL (codziennie przez 14 dni).
  2. Weryfikacja przekierowań (sprawdzam, że 100% działa).
  3. Walidacja schema, CWV, sitemapy na nowej wersji.
  4. Update linków wewnętrznych (nie tylko przekierowania 301, też bezpośrednie linki).
  5. 60 dni monitoringu pozycji w GSC.

HTTP status codes – jakie kiedy używać

Status kodu to fundament komunikacji z Googlebotem. Reguły:

  • 200 OK – normalny content, indeksowalny.
  • 301 Moved Permanently – trwałe przekierowanie, przenosi PageRank.
  • 302 Found – tymczasowe przekierowanie (A/B test, sesje), nie przenosi PageRank.
  • 404 Not Found – strona nie istnieje.
  • 410 Gone – trwale usunięta; Google deindeksuje szybciej niż z 404.
  • 503 Service Unavailable – tymczasowe prace konserwacyjne; Google wraca po 24-48h.
  • 500 Internal Server Error – błąd serwera; dłużej niż 48h = dewaluacja.

JavaScript SEO – problematyczny obszar

Jeśli strona bazuje na JavaScript (React, Vue, Angular), trzeba świadomie zadbać o SEO. Cztery opcje:

  1. Server-Side Rendering (SSR) – Next.js getServerSideProps, Nuxt, SvelteKit. HTML generowany na serwerze, Google widzi od razu.
  2. Static Site Generation (SSG) – Next.js getStaticProps, Gatsby. HTML generowany podczas buildu.
  3. Incremental Static Regeneration (ISR) – hybryda SSG + SSR. Next.js revalidate.
  4. Client-Side Rendering (CSR) + dynamic rendering – dla botów inny HTML. Deprecated przez Google, ale wciąż używane.

Dla nowych projektów: Next.js z App Router i React Server Components jest obecnie stackiem rekomendowanym. Stara się optymalizować pod SEO out of the box.

Hreflang – wielojęzyczność i geotargeting

Jeśli strona ma wersje w więcej niż jednym języku albo celuje w różne kraje, hreflang jest konieczny. Tag informuje Google, która wersja strony jest dla którego użytkownika.

Poprawna implementacja:

<link rel="alternate" hreflang="pl" href="https://example.pl/" />
<link rel="alternate" hreflang="en" href="https://example.com/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/" />

Najczęstsze błędy: asymetria (A wskazuje B, B nie wskazuje A), zły kod języka (en-uk zamiast en-GB), brak self-reference, hreflang do noindex.

Log file analysis – zaawansowane techniczne SEO

Analiza logów serwera pokazuje dokładnie, jak Googlebot i inne boty odwiedzają stronę. Dla dużych witryn (10k+ URL) to jedyny sposób zrozumieć realne wzorce crawla.

Co odkrywa analiza logów:

  • Które URL Googlebot odwiedza najczęściej (top rankingujące).
  • Które URL są ignorowane (orphan pages).
  • Marnotrawstwo crawl budgetu na parametry, filtry, paginację.
  • Czasy odpowiedzi pod różnym user-agentem (Googlebot smartphone vs desktop).
  • Statusy odpowiedzi (200/301/404/5xx) w czasie.

Narzędzia: Screaming Frog Log File Analyser, OnCrawl, JetOctopus. Dla małych witryn log analysis jest overkill – wystarczą dane z Search Console.

Cloudflare jako warstwa SEO

Cloudflare to dzisiaj najczęstsza warstwa CDN na polskim rynku. Poza szybkością daje kilka SEO-bonusów:

  • Always Online – strona dostępna, nawet gdy serwer padnie (Googlebot dostaje cache).
  • Image Resizing – automatyczny WebP/AVIF dla każdego użytkownika.
  • APO (Automatic Platform Optimization) – WP cache na edge Cloudflare.
  • Page Rules – kontrola cache, redirectów, headers.
  • Bot Management – Cloudflare rozpoznaje Googlebota i daje mu pełny dostęp.

Plan Free obsługuje podstawy. Pro (25 USD/mc) dodaje Image Resizing i APO. Enterprise (500+ USD/mc) – dla dużych portali.

Najczęstsze problemy z WordPressem – anti-patterns

WordPress jako CMS ma kilka pułapek technicznych, które zjadają SEO:

  1. Motyw z masą efektów (Divi, Avada, Elementor Pro z 15 widgetami) – ciężkie JS, wolne ładowanie.
  2. Nadmiar pluginów – każdy plugin ładuje własne CSS/JS. Minimum: 10-15 pluginów łącznie.
  3. Duplikaty sitemapy – dwa pluginy SEO na raz (RankMath + Yoast) generują dwie sitemapy.
  4. Revisions bez limitu – baza puchnie do kilku GB.
  5. Brak cache – strona renderuje się za każdym razem z bazy.
  6. Nieoptymalne Permalinks – /?p=123 zamiast /%postname%/.
  7. Tagi jako drugi zestaw kategorii – duplikat treści.
  8. Comments włączone bez moderacji – spam, wolne ładowanie.

Schema w szczegółach – najczęstsze typy

Konkretne przykłady schemy w JSON-LD:

Article:

{
"@context": "https://schema.org",
"@type": "BlogPosting",
"headline": "Tytuł artykułu",
"author": {"@type": "Person", "name": "Jan Kowalski"},
"datePublished": "2026-04-20",
"image": "https://example.com/cover.webp"
}

Product:

{
"@context": "https://schema.org",
"@type": "Product",
"name": "Laptop X",
"offers": {"@type": "Offer", "price": "4999", "priceCurrency": "PLN"}
}

Pluginy WP zwykle obsługują te typy automatycznie. Dla ręcznych implementacji: Google oferuje Structured Data Markup Helper i Schema.org dokumentację.

Jak testować techniczne zmiany bez ryzyka

Każda duża zmiana techniczna niesie ryzyko spadku. Trzy sposoby minimalizowania:

  1. Staging environment – klon produkcji na innej domenie. Testujesz, potem deploy.
  2. Feature flags – nowa funkcjonalność włączona tylko dla wybranych użytkowników (np. 10%).
  3. Canary deployment – 5% ruchu na nową wersję, monitoring metryk, stopniowe skalowanie.

Dla WordPressa najprostsza ścieżka: plugin „WP Staging” klonuje stronę, po testach migrujecie zmiany na produkcję.

Monitoring techniczny – ciągły, nie jednorazowy

Techniczne SEO to proces ciągły. Minimum monitoring 2026:

  • Codziennie: uptime monitor (UptimeRobot, Better Uptime).
  • Tygodniowo: Core Web Vitals w GSC, sprawdzenie raportu Indeksowanie.
  • Miesięcznie: pełny crawl Screaming Frog, audyt pluginów, update’y CMS.
  • Kwartalnie: czystka bazy, audyt schema, review robots.txt i sitemapy.
  • Rocznie: migracja na nowszą wersję PHP, audyt bezpieczeństwa.

Automatyzacja: pluginy jak WP Rocket, WP Optimize, Wordfence mają cron jobs dla rutynowych zadań.

Pagination w 2026 – rel next/prev już nie działa

Do 2019 Google oficjalnie używał rel="next" i rel="prev" do rozpoznawania paginacji. Od 2019 zostały deprecated. Co robić dzisiaj:

  • Strona 1 – normalna indeksacja.
  • Strony 2, 3, 4+ – noindex, follow (gdy nie ma unikalnej wartości).
  • Alternatywa: canonical stron 2+ na stronę 1 (działa słabiej niż noindex).
  • View All page dla treści – jeśli wszystkie elementy mieszczą się w jednej stronie, lepsze niż paginacja.

Favicon i wizualna identyfikacja

Favicon to mała ikona w zakładce przeglądarki i w SERP (od 2020 Google pokazuje ją w wynikach mobilnych). Checklist:

  • favicon.ico w korzeniu domeny (32×32, 16×16).
  • apple-touch-icon.png 180×180 dla iOS.
  • Manifest.json z ikonami 192, 512.
  • Spójność z logo marki.

Narzędzia: realfavicongenerator.net generuje pełny zestaw ikon z jednego PNG.

Trends techniczne 2026 – co obserwować

Pięć trendów, które warto mieć na radarze:

  1. Interaction to Next Paint (INP) – ciągle nowa metryka, coraz ważniejsza.
  2. Web Vitals Extension – dane polowe bezpośrednio w Chrome.
  3. JavaScript budget – Google ogranicza ilość JS, która jest renderowana.
  4. HTTP/3 i QUIC – standard dla szybkich stron, wspierane przez Cloudflare.
  5. AI-generated schema – narzędzia generujące schemę z treści automatycznie (CodexTabs, Schema Markup Generator).

Te trendy trzeba monitorować pasywnie – nie wymagają natychmiastowej reakcji, ale mogą zmienić priorytet dlatego, że zmieniają reguły gry. Obserwujcie Google Search Central Blog i Twitter Johna Muellera.

FAQ – techniczne SEO

Jakie CWV są najważniejsze dla WordPressa?

W WordPressie najczęściej problemem jest LCP (wolny hosting i ciężki motyw) i INP (third-party scripts, Facebook Pixel, Hotjar, Google Analytics). LCP rozwiązuje się szybkim hostingiem (Cloudways, Kinsta, Rocket.net), WebP obrazami i LiteSpeed Cache. INP wymaga ograniczenia JS i optymalizacji event handlerów. CLS jest zwykle OK w WordPressie, o ile motyw jest nowoczesny (GeneratePress, Astra, Kadence).

Czy muszę mieć schema na każdej stronie?

Nie, ale na wszystkich kluczowych stronach tak. Minimum: Organization na stronie głównej, Article / BlogPosting na postach, Breadcrumb na każdej (łącznie z kategoriami), Product dla sklepu. LocalBusiness dla lokalnych firm. Nadmiar schemy nie pomaga – duplikat dwóch różnych Organization na jednej stronie Google ignoruje. Zasada: jeden typ schema per strona, plus Breadcrumb jako wspólny.

Jak naprawić INP w WordPressie?

Kroki: (1) usuńcie lub odłóżcie niepotrzebne third-party (social widgets, chat, nieużywane analytics), (2) włączcie defer dla wszystkich JS innych niż krytyczne, (3) użyjcie pluginu Perfmatters lub WP Rocket do optymalizacji JS, (4) zmieńcie ciężki motyw na lekki (GeneratePress zamiast Divi, jeśli to możliwe), (5) sprawdźcie w Chrome DevTools, który event handler ma najdłuższe opóźnienie. Dla zaawansowanych: code splitting w niestandardowych skryptach.

Czy LiteSpeed jest lepszy od Apache dla SEO?

Pod kątem Core Web Vitals – tak, zwłaszcza w kombinacji z LSCache pluginem. LiteSpeed obsługuje HTTP/3, ma wbudowany cache, obsługuje ESI dla częściowego cache’owania. W testach realnych serwisów LSCache daje 2-4x szybsze ładowanie niż Apache + WP Rocket. Koszt: większość hostingów managed ma LiteSpeed (np. NitroPack, ChemiCloud). Dla WordPressa w 2026 to rekomendowany stack.

Co z mixed content po przejściu na HTTPS?

Mixed content to sytuacja, w której strona HTTPS ładuje zasoby po HTTP. Chrome i inne przeglądarki blokują je, co psuje layout. Naprawa: pluginy „Really Simple SSL” (automatyczna zamiana wszystkich linków), ręczna edycja hardkodowanych URL-i w motywie, zmiana bazy danych (Search & Replace plugin). Po naprawie sprawdźcie Chrome DevTools > Security – żadnych ostrzeżeń mixed content.

Czy duży rozmiar strony (powyżej 3MB) jest problemem?

Tak, szczególnie na mobile i wolniejszym łączu. Google bierze pod uwagę payload w Core Web Vitals (LCP). Strona 5 MB zawsze będzie wolniejsza niż 1 MB. Rozwiązania: optymalizacja obrazów (WebP, kompresja), usunięcie nieużywanych JS/CSS, lazy loading, CDN. Strona powyżej 10 MB to red flag – coś jest źle (np. nieskompresowane obrazy z aparatu, background video).

Czy schema Article i BlogPosting są wymienne?

BlogPosting jest bardziej specyficzny („post blogowy”) i dziedziczy po Article. Dla bloga osobistego używajcie BlogPosting, dla portalu newsowego NewsArticle, dla ogólnych treści Article. Google akceptuje wszystkie trzy. Różnica kosmetyczna – w zasięgu rich snippets nie ma różnicy. Dla recenzji używajcie Review albo ReviewNewsArticle, dla HowTo HowTo, dla FAQ FAQPage.

Jak monitorować Core Web Vitals w czasie?

Dwa sposoby: (1) Search Console > Core Web Vitals – dane polowe z 28 dni, z podziałem na URL i typ urządzenia, (2) CrUX Dashboard (Chrome User Experience Report) – publiczne dane dla top 10M domen. Dla własnej witryny: Google Analytics 4 ma wbudowane tracking Web Vitals, można też instrumentować skrypty (web-vitals library) i wysyłać do własnego analytics. Monitoring musi być ciągły, a nie jednorazowy – CWV wahają się w zależności od ruchu, czasu dnia, update’ów.

Co dalej

Po wdrożeniu technicznej listy kontrolnej warto przejść do struktury strony i architektury kategorii, która łączy techniczne fundamenty z planowaniem treści. Dobre uzupełnienie to lista 15 najczęstszych błędów SEO – możecie porównać z własną stroną. Wszystko łączy pillar SEO podstawy 2026, który daje szerszy kontekst strategii.

Inni czytali również