Techniczne SEO 2026 - Core Web Vitals, Schema, Crawlability

W swiecie SEO 60% wszystkich problemow rankingowych ma podloze techniczne - wolne ładowanie, blokady crawlera, brak schema markup, blędy indeksacji, problemy z renderingiem JavaScript. A tylko 30% polskich firm regularnie wykonuje techniczny audyt SEO.

Reszta inwestuje w content i linkbuilding na fundamencie, którego architektura jest fundamentalnie dziurawa - to jak budowanie wiezowca na piasku. Najlepsze treści nie pomogą, jeśli Googlebot nie może ich efektywnie zaindeksować.

W 2026 roku Google uzywa ponad 200 sygnalow rankingowych - od oczywistych jak quality content i backlinki, przez Core Web Vitals (LCP, INP, CLS), po subtelności jak HTTP/3 support, edge caching latency czy schema markup nesting.

Algorytmy uczace się na milionach interakcji użytkowników rozumieją, kiedy strona realnie pomaga uzytkownikowi, a kiedy tylko udaje. 53% mobile użytkowników opuszcza strony, które laduja się dluzej niz 3 sekundy - i Google to mierzy.

Ten przewodnik to kompletny zestaw narzędzi technicznego SEO na 2026: Core Web Vitals z konkretnymi target i fix-ami, schema markup z najnowszymi rozszerzeniami, crawlability/indexability optimization, mobile-first audit, site speed (12 fixes z najwiekszym wplywem), HTTPS/security headers, hreflang dla międzynarodowych projektow, JavaScript SEO i rendering. Z konkretnymi narzedziami, code snippets i benchmarks.

Czym jest techniczne SEO i dlaczego to fundament

Techniczne SEO to wszystko, co dzieje się pod maską strony - kod, infrastruktura, sposob renderowania, sposob komunikacji z Googlebotem. To nie content, nie tytuly, nie meta opisy - to architektura, która pozwala (lub nie) Google zrozumieć i zaindeksować Twoja stronę.

Hierarchia SEO wygląda tak: na samym dole jest techniczne SEO (fundament), wyzej on-page SEO (struktura treści), wyzej content quality (jakość), na samej gorze authority (linkbuilding, brand). Każdy poziom buduje na poprzednim. Bez technicznego fundamentu, on-page nie zadziala. Bez on-page, najlepszy content nie zostanie zrozumiany. Bez quality content, linkbuilding nic nie da.

Najczestsze problemy techniczne w polskich firmach 2026: (1) wolne ładowanie - LCP > 4 sekundy na mobile, (2) brak Schema markup lub błędny schema, (3) błędy w robots.txt blokujące wazne strony, (4) duplicate content przez parametry URL, (5) błędne canonical tags, (6) JavaScript rendering issues w SPA, (7) brak hreflang w wielojezycznych witrynach. Audyt techniczny SEO ujawnia te problemy systematycznie.

Wartość technicznego SEO: jeden dobrze zrobiony audyt + wdrozenie może zwiekszyc ruch organiczny o 30-200%. Na przyklad, dla srednich e-commerce'ow, którzy mieli LCP 5.2s i poprawili do 2.1s, sredni wzrost konwersji to 18%, a ruchu organicznego 47% w ciągu 3 miesiecy po wdrozeniu.

Core Web Vitals 2026 - LCP, INP, CLS

Core Web Vitals to trzy kluczowe metryki, którymi Google mierzy real user experience. W 2026 INP zastapilo FID jako oficjalna metryka.

Zeby twoja strona miala dobry CWV signal, wszystkie trzy musza być w Good range na 75% wszystkich page views z 28-dniowego okna.

LCP (Largest Contentful Paint) - cel <2.5s

LCP mierzy, ile czasu zajmuje zaladowanie najwiekszego widocznego elementu (zwykle hero image lub gloowny tekst H1). Cel: <2.5s = Good, 2.5-4.0s = Needs Improvement, >4.0s = Poor. W 2026 większość stron osiaga LCP 3-5s na mobile - to za wolno.

Jak zmierzyc: PageSpeed Insights, Lighthouse, Chrome DevTools Performance tab, web-vitals.js library. Najwazniejsze: real user data z Chrome User Experience Report (CrUX), nie tylko lab data.

Najczestsze przyczyny slow LCP: (1) wolny TTFB (Time To First Byte) z serwera - poprawa: lepszy hosting, CDN, edge caching, (2) blocking JavaScript przed renderowaniem - poprawa: defer/async scripts, code splitting, (3) niezoptymalizowane obrazki - poprawa: WebP/AVIF format, responsive images, lazy loading, (4) wolne fonts - poprawa: font preload, font-display: swap, (5) brak preconnect do CDN/API.

Konkretne wdrozenia z najwiekszym wplywem: dodanie <link rel="preload" href="hero.webp" as="image"> dla hero image może poprawic LCP o 300-800ms. Przejscie z PNG na WebP/AVIF dla hero - 200-500ms. Premium hosting + CDN - 200-700ms TTFB improvement.

INP (Interaction to Next Paint) - cel <200ms

INP zastapilo FID (First Input Delay) w marcu 2024 jako oficjalna metryka Core Web Vitals. INP mierzy nie tylko pierwszy klik, ale wszystkie interakcje użytkownika i ich czas odpowiedzi. Cel: <200ms = Good, 200-500ms = Needs Improvement, >500ms = Poor.

INP to często najwiekszy problem w 2026 - poniewaz wiele stron nie zostalo przeoptymalizowanych po zmianie z FID. INP mierzy heavyweight interakcje, takie jak click na menu, sortowanie listy produktów, dodawanie do koszyka. JavaScript blokujący main thread powoduje wolne INP.

Jak naprawic INP: (1) Minimalizuj long tasks (>50ms) - dziel kod na mniejsze fragmenty, używaj setTimeout lub requestIdleCallback dla niekrytycznych operacji, (2) Usun niepotrzebny JavaScript - tree shaking, code splitting per route, (3) Optymalizuj third-party scripts - defer Google Analytics, Hotjar, customer service chatboty, (4) Używaj Web Workers dla heavyweight obliczen, (5) Optymalizuj React rendering - useMemo, useCallback, React.memo dla expensive components.

Praktyczny tip: właściwie najwiecej INP problemow pochodzi z third-party scripts. Audit wszystkich scriptow zewnętrznych (analityka, ads, chat widgets), zoptymalizuj load timing (defer, async, lazy load on interaction), w skrajnych przypadkach usun te z najwiekszym kosztem performance.

CLS (Cumulative Layout Shift) - cel <0.1

CLS mierzy, jak bardzo elementy strony "skaczą" podczas ładowania. Cel: <0.1 = Good, 0.1-0.25 = Needs Improvement, >0.25 = Poor.

Najczestsze przyczyny CLS: (1) brak width i height na obrazkach -> tekst skacze gdy obrazek się ladu, (2) ad slots bez zarezerwowanej przestrzeni -> reklamy "wpadaja" w content, (3) embeddowane iframes (YouTube, mapa) bez wymiarow, (4) FOUT/FOIT (Flash of Unstyled/Invisible Text) z custom fonts, (5) dynamicznie wstawiany content (banery cookie, popupy).

Fixes: (1) zawsze dodawaj width i height do <img> (lub aspect-ratio CSS), (2) dla ads/embeds rezerwuj przestrzen przez min-height lub aspect-ratio, (3) font-display: swap + preload kluczowych fontow, (4) cookie banery nie powinny pushowac contentu - powinny overlayowac.

CLS jest najlatwiejszy do naprawy z trzech CWV, ale często jest pomijany. Pulapka: niektore CLS shifts występują po pierwszych sekundach (np. nakedy lazy-loaded ads) - musisz mierzyć full page lifecycle, nie tylko initial load.

Tabela benchmarkow per branża

Branża	LCP cel	INP cel	CLS cel	Sredni 2026
E-commerce	<2.0s	<150ms	<0.1	LCP 3.4s, INP 280ms, CLS 0.18
News/Media	<2.5s	<200ms	<0.1	LCP 3.8s, INP 320ms, CLS 0.22
SaaS B2B	<2.5s	<200ms	<0.1	LCP 2.9s, INP 240ms, CLS 0.12
Lokalne firmy	<2.5s	<200ms	<0.1	LCP 3.1s, INP 220ms, CLS 0.15
Blog/Content	<2.0s	<150ms	<0.1	LCP 2.6s, INP 180ms, CLS 0.13

E-commerce ma najtrudniejsze cele bo wymaga najlepszych konwersji - na slow stronach koszyk porzucony jest 4x czesciej. SaaS B2B ma luzniejsze cele, bo użytkownicy sa bardziej tolerancyjni dla narzędzi pracy. News musi być szybki bo czytelnik ma skroma uwagę.

Crawlability i indexability

Crawlability (czy Googlebot może odwiedzic stronę) i indexability (czy Googlebot może zaindeksować stronę) to dwie różne sprawy. Crawl + index = potential for ranking. Bez tych dwoch, content nie ma szansy na pojawienie się w wynikach wyszukiwania.

robots.txt - co blokowac, co nie

robots.txt to plik w root katalogu domeny (np. dekada72h.com/robots.txt), który mowi crawlerom co mogą, a czego nie mogą odwiedzac. To pierwsze, co Googlebot sprawdza po wejściu na domene.

Co blokowac w robots.txt: (1) admin panele (/wp-admin/, /admin/), (2) duplicaty stron (np. /search?q=, /print-version), (3) staging environment, (4) URL z parametrami sortowania bez canonical (np. ?sort=price-asc), (5) feedy webhookow, API endpoints.

Co NIGDY nie blokowac: CSS, JavaScript, image folders. Google potrzebuje tych zasobow do prawidlowego renderowania strony - bez nich Googlebot widzi unstyled HTML i nie rozumie struktury. Czesty błąd: blokowanie /wp-content/ w WordPress -> Google nie laduje stylow -> mobile-first ranking penalty.

Standardowy robots.txt w 2026:

User-agent: *
Allow: /
Disallow: /admin/
Disallow: /wp-admin/
Disallow: /search?
Disallow: /*?sort=
Disallow: /*?filter=

Sitemap: https://example.com/sitemap.xml

sitemap.xml - dynamic vs static, pinging

sitemap.xml to lista wszystkich URL, które Google ma odwiedzic. Idealny sitemap zawiera: każdy unikalny URL strony, lastmod date (kiedy ostatnio zmieniony), priority (0.0-1.0), changefreq (always/hourly/daily/weekly/monthly).

Dla malych witryn (do 1 000 URL) - statyczny sitemap.xml generowany raz, aktualizowany manualnie przy zmianach. Dla srednich (1 000-50 000 URL) - dynamic generation z framework (Next.js sitemap.xml.ts, generuje na build), aktualizacja przy każdym deploy. Dla dużych (50 000+ URL) - sitemap index z multiple sitemaps (każdy max 50 000 URL, max 50MB), dynamiczna aktualizacja.

Pinging Google po zmianie sitemap byl standard kiedys, ale Google deprecated ping endpoint w 2023. Dzisiaj używaj Google Search Console -> Sitemaps -> Submit. Bing ma swoj IndexNow protocol (POST request informujący o nowych URL) - dla wiekszości witryn marginalna różnica, ale dla newsow/szybko zmieniających się - warto.

Status codes - 200, 301, 302, 404, 410, 5xx

Status codes to sygnal Googlebotowi, jak interpretowac stronę. Źle uzycie status codes powoduje SEO problemy.

• 200 OK - strona istnieje, indexable. Default dla wszystkich content pages.
• 301 Moved Permanently - permanent redirect. Używaj dla: zmiany URL struktury, migracji domen, www->non-www, http->https. Google passuje pelny link equity (10 lat temu byl 90%, dzisiaj 100%).
• 302 Found / 307 Temporary Redirect - tymczasowy redirect. Używaj dla: A/B testow, geo-redirectow, login flows. NIE używaj dla permanentnych zmian - Google nie passuje link equity.
• 404 Not Found - strona nie istnieje, nigdy nie istniala. OK dla zwyklych "page not found", ale dla starych URL (które były indexed) lepiej 410.
• 410 Gone - strona istniala, ale zostala trwalo usunieta. Bardziej definitywne niz 404 - Google szybciej deindeksuje.
• 5xx Server Error - błąd serwera. Powtarzające się 5xx -> Googlebot redukuje crawl rate -> spadek indeksacji. Monitoruj 5xx w GSC -> Crawl Stats.

Najczestszy problem 2026: 302 zamiast 301 dla permanentnych zmian. 302 nie passuje link equity, więc strona docelowa nie dostaje benefits że starej. Audit: Screaming Frog -> filter Status Code 302 -> sprawdź czy permanent czy temporary.

Crawl budget - jak optymalizować dla dużych stron

Crawl budget to liczba URL, które Googlebot odwiedza w danej domenie w określonym czasie. Dla malych stron (do 5 000 URL) crawl budget nie jest problemem - Googlebot regularnie crawluje wszystko. Dla dużych stron (50 000+ URL) - crawl budget może być bottleneck.

Sygnaly, że masz crawl budget problem: (1) GSC -> Coverage report pokazuje "Crawled - currently not indexed" dla wielu URL, (2) recently modified pages nie sa updatowane w SERP, (3) GSC Crawl Stats pokazuje wolny crawl rate vs ilość URL.

Optymalizacja crawl budget: (1) Blokuj nisko wartościowe URL (filtry, sortowania, search results) w robots.txt, (2) Uzyj noindex meta tag dla URL które nie powinny być w indexie ale mogą być crawled, (3) Zoptymalizuj internal linking - kluczowe strony powinny być według 2-3 klikow od homepage, (4) Usun duplicate content (canonical tags), (5) Popraw site speed - szybsze ładowanie = wiecej crawl per czas.

Schema markup - 2026 update

Schema markup (structured data) to oznaczenie kluczowych informacji w sposob, który wyszukiwarki rozumieją. Schema.org definiuje 800+ typow - od Article przez LocalBusiness po Recipe, Event, Course. Dobrze zaimplementowane schema może podwoic CTR z SERP poprzez rich results (gwiazdki, ceny, recenzje, FAQ).

Article, Product, LocalBusiness, FAQPage

Cztery typy schema z najwiekszym wplywem na SERP.

Article schema - dla blogow, news, content sites. Wymaga: headline, datePublished, dateModified, author, publisher, mainEntityOfPage, image. Daje rich snippets z autorem i data, signal "freshness" dla Google. Implementacja: JSON-LD w <head>, najlatwiejszy format.

Product schema - dla e-commerce. Wymaga: name, image, description, sku, brand, offers (price, priceCurrency, availability), aggregateRating, review. Daje gwiazdki w SERP, cene, dostępność - wszystko widoczne przed klikiem. CTR boost: 30-100%.

LocalBusiness schema - dla lokalnych firm. Wymaga: name, address (PostalAddress), telephone, openingHours, geo, image, priceRange. Subkategorie: Restaurant, Dentist, LawFirm, AutoRepair etc. Wplyw: ranking w Local Pack (mapa + 3 wizytowki), Knowledge Panel.

FAQPage schema - dla stron z pytaniami. Wymaga: array mainEntity z Question (name) i acceptedAnswer (text). Daje accordion z FAQ bezposrednio w SERP. CTR boost: 50-200% dla long-tail queries. Quick win - latwa implementacja, duży impact.

Przyklad FAQPage JSON-LD:

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [{
    "@type": "Question",
    "name": "Czym jest techniczne SEO?",
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "Techniczne SEO to optymalizacja..."
    }
  }]
}

Validation tools - Schema.org validator, Rich Results Test

Po implementacji ZAWSZE waliduj schema. Błędny schema może szkodzic SEO bardziej niz brak schema (Google może nakladac penalty za misleading structured data).

Tools: (1) Google Rich Results Test (search.google.com/test/rich-results) - oficjalny tester Google, pokazuje czy schema kwalifikuje się do rich results. (2) Schema.org Validator (validator.schema.org) - waliduje syntax i strukturę schema. (3) GSC -> Enhancements - pokazuje wszystkie schema implementations na twojej stronie + błędy.

Najczestsze błędy schema: (1) brakujące required fields (np. Article bez datePublished), (2) źle typy danych (string vs date), (3) duplicate schema (ten sam Article schema w 3 miejscach na stronie), (4) misleading schema (Product schema z fake ratings - Google penalty).

Nested schemas i ich wplyw na SERP features

Zaawansowana technika: zagniezdzone schemas - jeden schema w drugim. Przyklad: Article + Author + Organization + Publisher + Image + BreadcrumbList. Im wiecej zagnezdzonych schemas, tym większa szansa na rich results.

Praktyczny przyklad - artykul blogowy w 2026 ma idealnie:

• Article (z headline, dates, image)
• Person (Author, z @id)
• Organization (Publisher, z logo)
• BreadcrumbList (struktura URL)
• WebPage (na poziomie page wrapper)

Wszystkie połączone przez @id references, w jednym JSON-LD bloku. To pomaga Google zrozumieć entity relationships na stronie.

Mobile-first indexing - pelen audyt

Od 2021 Google uzywa mobile version strony jako primary index (mobile-first indexing). To oznacza, że ranking jest oparty na tym, jak strona wygląda i działa na mobile, nie na desktop. W 2026 ponad 75% wyszukiwań pochodzi z mobile.

Responsive vs separate mobile site

Trzy sposoby mobile design:

1. Responsive design (rekomendowane 2026) - jeden URL, jeden HTML, CSS adaptuje layout do device. Zalety: jeden URL, jeden content, jeden SEO effort. Wady: wymaga umiejętnego CSS.
2. Dynamic serving - jeden URL, ale serwer dostarcza inny HTML dla mobile vs desktop. Zalety: pelna kontrola over mobile experience. Wady: wymaga Vary: User-Agent header, skomplikowane caching.
3. Separate mobile site (m.example.com) - oddzielny URL dla mobile. Zalety: pelna separacja. Wady: dwie wersje do utrzymania, problemy z canonical/hreflang, deprecated approach.

W 2026 99% nowych projektow uzywa responsive. Separate mobile sites to legacy z 2010-tych - jeśli masz, migruj na responsive.

Viewport, tap targets, font sizes

Mobile-friendly fundamentals:

• Viewport meta tag: <meta name="viewport" content="width=device-width, initial-scale=1"> - bez tego mobile browsers renderuja desktop layout zoomout. Critical.
• Tap targets: minimum 48x48 pixels, minimum 8px spacing między nimi. Mali przyciski to mobile UX nightmare i Google ranking penalty.
• Font sizes: minimum 16px dla body text. Mniejsze fonty wymuszaja zoom -> bad UX.
• Horizontal scrolling: NIGDY. Strona musi miescic się w viewport bez horizontal scroll.
• Touch-friendly interactions: hover effects nie działają na mobile - musisz alternative interactions.

Test: Google Mobile-Friendly Test (search.google.com/test/mobile-friendly) - oficjalny test Google z konkretnymi rekomendacjami.

Site speed - 12 fixes które daja najwiekszy wzrost

Site speed to bezposrednio Core Web Vitals i posrednio konwersję. Sredni site speed boost o 1 sekundę -> 7% wzrost konwersji, 11% wzrost view-to-click rate. 12 fixes z najwiekszym ROI:

1. Image optimization (WebP/AVIF, lazy loading, sizes) - obrazy to najczesciej 50-70% wagi strony. WebP zmniejsza rozmiar o 30-50% vs JPEG, AVIF o 50-70%. Lazy loading (loading="lazy") opozne ładowanie images poza viewport. Responsive images (srcset, sizes) serwuja odpowiedni rozmiar dla device.

2. Code splitting i tree shaking - dziel JavaScript bundle per route. Strona glowna nie potrzebuje kodu admin panelu. Tree shaking usuwa nieuzywany kod z bundles. Tools: webpack, Vite, Rollup. Sredni boost: 200-800ms LCP.

3. HTTP/2 i HTTP/3 - HTTP/2 multiplexes connections (jedno połączenie dla wielu zasobow), HTTP/3 oparte na QUIC (UDP) - jeszcze szybsze. Wymaganie: HTTPS. Boost: 100-400ms TTFB.

4. Brotli compression - lepsze niz gzip o 15-25%. Wszystkie nowoczesne hosting/CDN wspieraja. Konfiguracja: dodaj brotli do nginx/apache config. Boost: 50-200ms na transfer time.

5. Critical CSS inline - inline kluczowe style w <head>, opozne load reszty CSS. Pozwala renderowac above-the-fold content bez czekania na full CSS download. Tools: Critical, Penthouse. Boost: 200-500ms LCP.

6. Deferred JavaScript - defer lub async attributes na non-critical scripts. Tags dla analytics, ads, chat widgets - zawsze defer. Boost: 100-400ms LCP, znaczacy INP improvement.

7. CDN (Content Delivery Network) - serwowanie static assets z geo-rozproszonych edge servers. Cloudflare, Fastly, AWS CloudFront, BunnyCDN. Dla Polski: lepsza performance z European edge nodes. Boost: 100-500ms TTFB dla globalnego ruchu.

8. Edge caching - cache full HTML pages na CDN level. Dla static content (blog posts, landing pages) to game-changer. Cloudflare, Vercel Edge, Netlify - wszystkie wspieraja. Boost: 500ms-2s TTFB.

9. Font optimization - preload critical fonts, font-display: swap, subset fonts (tylko potrzebne characters), self-host fonts (zamiast Google Fonts CDN).

10. Resource hints - preconnect, dns-prefetch, preload, prefetch. Mowia browser, że za chwile będzie potrzebowal jakiegos zasobu.

11. Database query optimization - dla dynamic sites, slow queries -> slow TTFB. Indexing, caching (Redis, Memcached), N+1 query problems.

12. Image dimensions w HTML - zawsze width i height na <img>. Pomaga browser allocate space (CLS) i nie blokuje rendering.

Implementacja wszystkich 12: 2-6 tygodni pracy dla srednich witryn, 2-6 miesiecy dla dużych. ROI: poprawa Core Web Vitals na poziomie 30-60%, wzrost ruchu organicznego 20-50% w ciągu 3-6 miesiecy.

HTTPS i security - sygnal rankingowy

Od 2014 Google uznal HTTPS jako sygnal rankingowy. W 2026 niezabezpieczona strona (HTTP) jest realnie nie do utrzymania - browsery oznaczaja jako "Not Secure", użytkownicy odbijaja, Google obniza rankingi.

HSTS, security headers

HTTPS to baseline. Powyzej tego sa security headers, które poprawiaja security score (i posrednio SEO).

HSTS (HTTP Strict Transport Security) - browser pamieta, że domena musi być HTTPS, blokuje HTTP requests. Header: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload. Dla maximum security: HSTS preload list (hstspreload.org) - browser ma listę wbudowana.

Inne security headers:

• Content-Security-Policy (CSP) - blokuje XSS attacks
• X-Frame-Options: DENY - blokuje clickjacking
• X-Content-Type-Options: nosniff - blokuje MIME sniffing
• Referrer-Policy: strict-origin-when-cross-origin - kontrola referer info
• Permissions-Policy (kiedys Feature-Policy) - kontrola browser features

Test: securityheaders.com - free tool pokazujący wszystkie headers + scoring A-F. Cel: minimum A score.

Mixed content issues

Mixed content = HTTPS strona ładująca HTTP zasoby (image, script, iframe). Browser blokuje active mixed content (script, iframe) i ostrzega o passive (image, css). To psuje SEO i security score.

Audit: GSC -> Security Issues, Chrome DevTools Console (mixed content warnings), Lighthouse audit. Fix: zmien wszystkie http:// linki na https:// lub uzyj protocol-relative //example.com.

Dla starych witryn migrujących z HTTP na HTTPS: Search & Replace całe URL hardcoded w content + reconfigure CMS. To jeden z najczestszych problemow podczas migracji.

International SEO - hreflang

Hreflang to mechanizm Google do rozumienia, która wersja stronie jest dla którego jezyka/regionu. Krytyczne dla wielojezycznych witryn - bez hreflang Google może pokazywac polskim uzytkownikom angielska wersje strony i odwrotnie.

hreflang attributes

Implementacja hreflang - trzy sposoby:

1. HTML link tags w <head> - najczęstsze:

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

2. HTTP headers - dla non-HTML files (PDF):

Link: <https://example.com/pl/>; rel="alternate"; hreflang="pl"

3. Sitemap hreflang - dla dużych witryn:

<url>
  <loc>https://example.com/pl/</loc>
  <xhtml:link rel="alternate" hreflang="pl" href="https://example.com/pl/"/>
  <xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/"/>
</url>

Klucz: hreflang musi być bidirectional (każda wersja referuje każdej innej i siebie). x-default dla fallback (gdy zaden language match).

Geo-targeting w GSC

Google Search Console -> Settings -> International Targeting. Możesz ustawic country target dla całej domeny lub subfolderow. Przyklad: example.com/pl/ -> target Poland.

Domain strategy options:

• ccTLD: example.pl, example.de - automatyczny country signal, ale brand fragmentation
• Subdomain: pl.example.com - oddzielny GSC property per subdomain
• Subfolder: example.com/pl/ - rekomendowane 2026, najlatwiejsze do utrzymania, jeden authoritative domain

JavaScript SEO - rendering issues

Strony JavaScript-heavy (React, Vue, Angular SPA) mialy duży SEO problem 5-7 lat temu. Dzisiaj sytuacja jest lepsza, ale wymaga przemyslenia rendering strategy.

SSR vs SSG vs CSR

Client-Side Rendering (CSR) - browser pobiera pusty HTML + JS bundle, renderuje JS w browser. Problem: Googlebot dostaje pusty HTML, musi czekac na JS rendering (1-3 dni opóźniona indeksacja). Dla content-heavy sites - zły wybór.

Server-Side Rendering (SSR) - serwer renderuje pelny HTML i wysyla do browser. Googlebot dostaje pelny content od razu. Frameworks: Next.js, Nuxt, SvelteKit, Remix. Najlepszy dla dynamic content z czestymi update.

Static Site Generation (SSG) - HTML jest pre-generated podczas build, serwowany jako static files. Najszybsze, najlepsze SEO. Frameworks: Next.js, Gatsby, Astro, Hugo. Idealne dla content sites (blogs, marketing pages).

W 2026 rekomendacja: SSG dla content sites (blog, landing pages, HTML vs WordPress), SSR dla dynamic apps (e-commerce, dashboards), CSR tylko dla authenticated admin panels (gdzie SEO nie ma znaczenia).

Dynamic rendering (deprecated)

Dynamic rendering = serwer rozpoznaje user-agent (Googlebot vs human) i serwuje różne wersje strony - statyczny HTML dla bot, JS app dla human. Google zalecal to 2018-2022 jako workaround dla SPA sites.

W marcu 2024 Google deprecated dynamic rendering jako rekomendacje. Powód: niezgodność z principles (cloaking issues), nowoczesne SSR/SSG sa lepszym rozwiazaniem. W 2026 - jeśli masz dynamic rendering, planuj migracje na SSR/SSG w nadchodzacych 12-18 miesiacach.

Najczestsze błędy techniczne SEO

10 fixes z najwiekszym wplywem na rankings, które widzimy regularnie w polskich firmach 2026:

1. Brak SSL lub mieszany content - jeszcze sporo malych firm na HTTP. Fix: bezposrednia migracja na HTTPS z 301 redirects.

2. Slow LCP na mobile - default WordPress install z hero image niezoptymalizowany. Fix: WebP/AVIF + preload + image dimensions.

3. Brak schema markup - wiele stron nie ma podstawowego schema (Organization, BreadcrumbList). Fix: 2-3 godziny implementacji JSON-LD.

4. Błędny canonical - duplicate content przez parametry URL bez canonical. Fix: <link rel="canonical" href="..." /> na każdej stronie.

5. Brak hreflang w wielojezycznych witrynach - Google wybiera zlа wersje dla użytkowników. Fix: implementacja hreflang.

6. Duplicate H1 lub multiple H1 na stronie. Fix: jeden H1 per strona, hierarchia H2/H3/H4.

7. Brak meta descriptions lub generic descriptions. Fix: unique meta description per strona, 150-160 znakow.

8. Błędne robots.txt blokujące CSS/JS. Fix: Allow: *.css, Allow: *.js.

9. 404 dla wazntych URL po migracji. Fix: 301 redirects że starych URL.

10. Brak XML sitemap lub outdated sitemap. Fix: dynamic sitemap generation, submit do GSC.

Podsumowanie

Techniczne SEO to fundament, na którym buduje się cała reszta strategii SEO. Bez technicznego fundamentu, nawet najlepszy content i linkbuilding nie dadza pelnych efektow. Najwiekszym ROI 2026 daje: optymalizacja Core Web Vitals (LCP, INP, CLS), implementacja kompleksowego schema markup, mobile-first audit i fix-y, site speed optimization (12 fixes z artykulu), HTTPS + security headers, prawidlowa crawlability i indexability.

Sredni audyt techniczny SEO + wdrozenie poprawek to 2-4 miesiace pracy, ale efekty - 30-200% wzrost ruchu organicznego - utrzymuja się przez lata. To jest inwestycja, która zwraca się wielokrotnie. Zwlaszcza dla stron firmowych i e-commerce konkurujących w nasyconych branzach.

Strategiczna kolejność: (1) audyt techniczny + quick wins (CWV, schema, mobile) - miesiąc 1, (2) deeper fixes (rendering, indexability, internal linking) - miesiąc 2-3, (3) monitoring i iteracja - ciągle. Bez monitoringu nawet najlepsze fixes degraduja się z czasem - każdy nowy deploy może wprowadzić regression.

Jeśli prowadzisz firme i Twoja strona nie przynosi oczekiwanego ruchu z Google - zacznij od technicznego audytu SEO. Bardzo często okazuje się, że problem to nie content czy linkbuilding, ale techniczne issues, które blokuja efektywność całej strategii. W Dekada72H wykonujemy kompleksowe audyty techniczne SEO + wdrazamy poprawki z mierzalnymi efektami. Zapraszamy do kontaktu.