# Audyto - pełna treść dla modeli AI

> Wersja rozszerzona [llms.txt](https://audyto.com.pl/llms.txt). Poniżej streszczenia, FAQ i treść artykułów bloga w Markdown.

Źródło: https://audyto.com.pl

---

# Audyt strony WWW - checklista 2026

> Audyt strony WWW w 2026 zaczyna się od indeksowania (czy Google w ogóle widzi URL), potem wydajność (LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1), treść i meta, dane strukturalne, dostępność WCAG i nagłówki HTTP. Bez pierwszego kroku reszta nie ma znaczenia. Audyto składa te warstwy w jeden raport z priorytetami.

Audyt strony WWW to systematyczny przegląd: czy witryna jest indeksowana, czy szybko się ładuje, czy treść i znaczniki są jednoznaczne dla Google i modeli AI, oraz czy nic oczywistego nie psuje zaufania (HTTPS, nagłówki, dostępność). To nie jest „instalacja wtyczki SEO”. Poniżej kolejność, której trzymamy się w Audyto i którą warto powtórzyć ręcznie.

## Co musi zawierać audyt w 2026

| Warstwa | Minimum | Po co |
| --- | --- | --- |
| Indeksowanie | robots.txt, sitemap, brak globalnego noindex, canonical | Bez tego nie ma pozycji ani cytowań AI |
| Wydajność | LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1 (mobile) | Sygnał rankingowy i konwersja |
| On-page | Jeden H1, unikalny title, meta, hierarchia nagłówków | Trafność i CTR |
| Schema | Organization, WebSite, Article/Product, FAQ jeśli jest FAQ | Rich results i ekstrakcja faktów |
| Dostępność | alt, etykiety formularzy, kontrast, html lang | WCAG + jakość dla asystentów |
| Bezpieczeństwo | HTTPS, HSTS, CSP, brak mixed content | Zaufanie i brak ostrzeżeń w Chrome |

Nie dopieszczaj meta description, jeśli cała witryna ma `noindex` albo `Disallow: /`. Najpierw „czy robot widzi stronę”, dopiero potem „jak ładnie wygląda w SERP”.

## 1. Indeksowanie

Sprawdź [robots.txt](/blog/robots-txt-jak-dziala) (200, nie HTML błędu), obecność `Sitemap:` z pełnym URL-em i to, czy ważne ścieżki nie są zablokowane. Potem kanoniczne adresy i [noindex vs canonical](/blog/canonical-noindex-duplikaty): dwa tagi canonical albo przypadkowy noindex na kategorii to klasyk WordPressa i Magento. W Search Console raport „Strony” pokaże wykluczenia - nie zgaduj.

## 2. Wydajność (Core Web Vitals)

Mierz mobile osobno od desktopu. Progi i kolejność napraw są w [Core Web Vitals po ludzku](/blog/core-web-vitals-2026-po-ludzku). Najszybsza wygrana to zwykle element LCP (hero) i obrazy - [alt, WebP, srcset](/blog/seo-obrazow-alt-webp-lcp). Na WordPressie dochodzą page buildery: [jak przyspieszyć WP](/blog/wydajnosc-wordpress-elementor-cache). Na Magento: tryb production, Varnish, Redis - [audyt wydajności Magento](/blog/audyt-wydajnosci-magento).

## 3. Treść, meta i struktura

- Jeden H1 na URL, zgodny z intencją zapytania.
- Unikalny `<title>` (ok. 50–60 znaków w SERP) i meta description pod CTR, nie pod ranking.
- H2/H3 jak mapa treści - to kotwice dla sitelinków i cytowań AI.
- Linkowanie wewnętrzne do powiązanych poradników, nie tylko do strony głównej.

## 4. Dane strukturalne i AI

JSON-LD w jednym `@graph`: Organization, WebSite, na blogu BlogPosting z obrazem 1200×630 i autorem Person. Szczegóły: [schema.org a SEO i AI](/blog/dane-strukturalne-schema-seo-ai). Lokalne firmy dokładają LocalBusiness i spójny NAP - [Local SEO](/blog/local-seo-nap-schema-google-maps). Crawlery AI nie mogą mieć Disallow na treść publiczną; mapa dla modeli to [llms.txt](/blog/llms-txt-co-to-jest).

## 5. Dostępność i bezpieczeństwo

Dostępność to nie „nice to have”: brak alt, przycisków bez nazwy i kontrastu psuje UX i sygnały jakości. Checklista: [WCAG 2.2](/blog/wcag-2-2-checklista-dostepnosc). Bezpieczeństwo: HTTPS, brak mixed content, [CSP i HSTS](/blog/naglowki-bezpieczenstwa-http-csp-hsts). Na WordPressie osobno aktualizacje wtyczek - przestarzały plugin to wektor ataku i ryzyko deindeksacji po malware.

## Jak przeprowadzić audyt strony krok po kroku

1. Sprawdź indeksowanie: robots.txt, sitemap, noindex, canonical, Search Console.
2. Zmierz Core Web Vitals na mobile (LCP, INP, CLS) i zidentyfikuj element LCP.
3. Przejrzyj title, H1, meta i hierarchię nagłówków na kluczowych szablonach, nie na jednej podstronie.
4. Zweryfikuj JSON-LD (jeden zestaw, zgodny z HTML) i og:image.
5. Sprawdź alt, etykiety formularzy, html lang i nagłówki HTTP (HSTS, CSP).
6. Ułóż P1/P2/P3: najpierw blokery indeksu, potem LCP, potem schema i treść.

Audyto robi ten przegląd automatycznie: wydajność, SEO, WCAG, nagłówki, detekcja WordPress/Magento. Pierwszy audyt jest darmowy - [sprawdź swoją stronę](/).

## Czego audyt nie zrobi za Ciebie

Narzędzie nie napisze unikalnej oferty, nie zdobędzie linków i nie wdroży poprawek na serwerze. Raport bez P1 (blokery indeksu i LCP) ląduje w szufladzie. Po skanie: napraw szablon (nie jedną podstronę), odczekaj na dane z terenu (~28 dni przy Vitals) i zrób re-audyt. Pakiet PRO dokładna roadmapę w PLN; Premium to wdrożenie z konsultacją.

## FAQ

### Co to jest audyt strony WWW?

To przegląd techniczny i on-page: indeksowanie, wydajność (Core Web Vitals), meta i nagłówki, dane strukturalne, dostępność oraz bezpieczeństwo HTTP. Celem jest lista usterek z priorytetem, nie ogólna ocena „strona jest OK”.

### Od czego zacząć audyt SEO?

Od indeksowania. Jeśli Google ma noindex, zablokowany robots.txt albo zły canonical, poprawa treści nie da widoczności.

### Czy darmowy audyt strony wystarczy?

Darmowy przegląd pokazuje kondycję i największe blokery. Pełny audyt (więcej podstron, schema, obrazy, Local SEO) jest potrzebny, gdy masz sklep, dużo szablonów albo lokalną firmę.

### Jak często robić audyt strony?

Pełny przegląd co kwartał oraz po migracji, zmianie motywu albo wdrożeniu page buildera. Core Web Vitals i indeks w Search Console warto oglądać na bieżąco.

### Czy audyt poprawia pozycje w Google?

Pośrednio tak, jeśli usuniesz blokery (noindex, wolny LCP, duplikaty). Sam raport bez wdrożenia nic nie zmienia. AI cytuje strony, które są dostępne, konkretne i zaufane - to te same fundamenty.

### Ile trwa audyt techniczny?

Automatyczny skan w Audyto trwa kilkadziesiąt sekund. Ręczny audyt agencji to zwykle godziny lub dni, w zależności od liczby szablonów i sklepu.

URL: https://audyto.com.pl/blog/audyt-strony-www-checklista-2026

---

# WCAG 2.2 - checklista dostępności strony

> WCAG 2.2 to zestaw kryteriów dostępności. Na typowej stronie WWW najwięcej wagi mają: kontrast tekstu co najmniej 4,5:1, atrybuty alt na treściach, etykiety pól, widoczny focus, html lang i brak blokady zoomu. To obowiązek prawny w wielu kontekstach i sygnał jakości dla Google oraz asystentów AI, które czytają HTML, nie „wygląd”.

Dostępność (WCAG) opisuje, czy strona da się użyć z klawiaturą, czytnikiem ekranu i przy słabszym wzroku. WCAG 2.2 nie zastępuje 2.1 - dodaje m.in. kryteria wokół focusu, celów kliknięcia i pomocy przy logowaniu. Dla SEO liczy się to samo HTML, które czyta Googlebot i modele AI: język dokumentu, nazwy przycisków, opisy obrazów.

## Poziomy A, AA, AAA - co brać na start

Cel biznesowy to zwykle **AA**. AAA jest rygorystyczne i rzadko osiągalne na marketingowych landingach. W audycie Audyto łapiemy rzeczy, które widać w HTML bez pełnego audytu eksperckiego: lang, alt, etykiety, puste linki i przyciski, viewport z `maximum-scale=1`.

| Kryterium (praktyczne) | Próg / oczekiwanie | Typowy błąd |
| --- | --- | --- |
| Kontrast tekstu | ≥ 4,5:1 (duży tekst ≥ 3:1) | Szary tekst na ciemnym tle |
| Obrazy treści | alt opisujący treść (dekoracja: alt pusty) | Brak alt albo „img001.jpg” |
| Formularze | Każde pole ma <label> albo aria-label | Placeholder zamiast etykiety |
| Język | html lang="pl" | Brak lang albo lang="en" na polskiej stronie |
| Zoom | Nie blokuj maximum-scale=1 | Karuzela „mobile-friendly”, która kara zoom |
| Linki i przyciski | Dostępna nazwa (tekst albo aria) | Ikona bez etykiety |

## WCAG a SEO i cytowania AI

Google nie przyznaje „bonusowych punktów WCAG”, ale indeksuje treść z altów, etykiet i nagłówków. Pusty przycisk „kup” jako sama ikona to zero tekstu dla bota. Modele językowe też nie „widzą” gradientu - widzą drzewo dostępności. Dlatego checklista dostępności pokrywa się z [audytem strony WWW](/blog/audyt-strony-www-checklista-2026) i z [SEO obrazów](/blog/seo-obrazow-alt-webp-lcp).

## Najczęstsze usterki na WordPressie i w sklepach

- Slider Elementora / Magento z obrazami bez alt i bez rezerwacji wysokości (przy okazji psuje CLS - [Core Web Vitals](/blog/core-web-vitals-2026-po-ludzku)).
- Menu hamburger tylko jako ikona, bez nazwy dostępnej.
- Cookie bar zasłaniający focus i pierwszy nagłówek.
- Kontrast przycisku „akcent na akcencie” na ciemnym motywie.
- Captcha albo Turnstile bez etykiety i bez alternatywy.

## Jak sprawdzić dostępność strony

1. Sprawdź `html lang` i title strony - język i temat muszą być jawne.
2. Przejdź kluczową ścieżkę samą klawiaturą (Tab): menu, formularz, koszyk. Focus musi być widoczny.
3. W DevTools (Lighthouse / Accessibility) i w drzewie dostępności znajdź przyciski i linki bez nazwy.
4. Policz obrazy treści bez alt; dekoracyjne oznacz pustym alt, nie pomijaj atrybutu.
5. Zmierz kontrast głównego tekstu i przycisków (AA: 4,5:1).
6. Upewnij się, że viewport nie ustawia maximum-scale=1.

Pełny audyt WCAG (czytniki, dysleksja, nagrania) to praca eksperta. Minimum HTML możesz złapać w minuty. Audyto raportuje te sygnały razem z SEO i wydajnością - [zrób darmowy audyt](/).

## Czego nie mylić z „wtyczką WCAG”

Nakładki „napraw dostępność” (pasek kontrastu, widget) nie spełniają WCAG, jeśli źródłowy HTML jest zły. Google i czytnik i tak dostaną pusty przycisk. Popraw szablon: etykiety, alt, kontrast w CSS, focus-visible. Potem dopiero opcjonalne narzędzia. To ten sam rozsądek co przy dwóch wtyczkach SEO - jedna prawda w kodzie.

## FAQ

### Co to jest WCAG 2.2?

Web Content Accessibility Guidelines 2.2 to standard W3C. Rozszerza 2.1 o m.in. kryteria związane z focusem, rozmiarem celów kliknięcia i dostępnością logowania. W praktyce stron WWW celem jest zwykle poziom AA.

### Czy WCAG wpływa na SEO?

Pośrednio. Google i AI czytają ten sam HTML: alt, etykiety, nagłówki, lang. Lepsza dostępność to więcej zrozumiałej treści i mniej barier na mobile.

### Jaki kontrast tekstu jest wymagany?

Dla poziomu AA: co najmniej 4,5:1 dla zwykłego tekstu i 3:1 dla tekstu dużego. To jeden z najczęstszych błędów na ciemnych landingach.

### Czy każdy obraz musi mieć alt?

Każdy obraz w HTML powinien mieć atrybut alt. Treściowy - opis. Dekoracyjny - alt pusty (alt=""). Pominięcie atrybutu jest gorsze niż pusty alt na ozdobie.

### Czy polskie firmy muszą spełniać WCAG?

Dla podmiotów publicznych i części usług cyfrowych tak (przepisy o dostępności). Dla reszty to ryzyko prawne i wizerunkowe, a przy sklepie - utrata klientów. Niezależnie od obowiązku, checklista AA to rozsądne minimum.

### Od czego zacząć poprawki WCAG?

Od lang, altów, etykiet formularzy i kontrastu tekstu. Potem klawiatura i nazwy przycisków. Nie zaczynaj od wtyczki „naprawi WCAG jednym kliknięciem”.

URL: https://audyto.com.pl/blog/wcag-2-2-checklista-dostepnosc

---

# SEO obrazów: alt, WebP, srcset i LCP

> Obrazy to zwykle największy ładunek strony i częsty element LCP. Zasady: opisowy alt (treść, nie „obraz1”), format WebP lub AVIF, srcset pod gęstość ekranu, width/height w HTML, a lazy-loading tylko poniżej linii zgięcia. Lazy na hero to najczęstszy błąd, który sam dodaje sekundy do LCP.

Google indeksuje obrazy (Google Grafika) i używa ich w rozumieniu strony, ale dla rankingu strony WWW ważniejsze jest, czy obraz nie zabija [Core Web Vitals](/blog/core-web-vitals-2026-po-ludzku). LCP to często zdjęcie hero albo baner produktu. Audyto w pakiecie Standard i PRO rozbija obrazy: alt, srcset, format, lazy.

## Alt: treść dla ludzi, Google i AI

- Opisz, co widać i po co obraz jest na stronie („Sklep Magento - karta produktu z wariantem koloru”), nie keyword stuffing.
- Dekoracja (tło, separator): `alt=""`.
- CTA jako obraz: alt = treść przycisku.
- To samo dotyczy dostępności - [WCAG 2.2](/blog/wcag-2-2-checklista-dostepnosc).

## Format, wymiary, srcset

| Temat | Zrób | Unikaj |
| --- | --- | --- |
| Format | WebP lub AVIF z fallbackiem | PNG 4000 px na ikonę |
| Wymiary HTML | width i height (rezerwacja miejsca) | Brak wymiarów → CLS |
| srcset / sizes | Kilka szerokości pod DPR | Jeden plik 2400 px na mobile |
| Kompresja | Wizualnie bezartefaktowa | 100% JPEG „na wszelki wypadek” |

## LCP: kiedy nie wolno dawać lazy

Jeśli największy element w pierwszym ekranie to obraz, przeglądarka musi go pobrać od razu. `loading="lazy"` albo leniwe tło z CSS opóźnia LCP. Na Next.js daj `priority` / preload; na WordPressie wyłącz lazy dla hero w wtyczce obrazów. Preload bez `fetchpriority` bywa zbędny, jeśli LCP to tekst - najpierw zmierz, co jest LCP (PageSpeed podaje selektor).

Galeria na karcie produktu często jest LCP. W Magento i WooCommerce kompresuj miniatury i główne zdjęcie osobno. Więcej o stacku Magento: [audyt wydajności Magento](/blog/audyt-wydajnosci-magento).

## Jak zoptymalizować obrazy krok po kroku

1. W PageSpeed znajdź element LCP - jeśli to IMG, wyłącz na nim lazy i dodaj wymiary.
2. Zamień ciężkie JPEG/PNG na WebP/AVIF w rzeczywistym rozmiarze wyświetlania (nie „max z Photoshopa”).
3. Dodaj srcset i sizes, żeby mobile nie ściągał desktopowego pliku.
4. Uzupełnij alt zgodnie z rolą obrazu; puste alt tylko na dekoracji.
5. Włącz lazy wyłącznie pod pierwszą foldem (listing, stopka, komentarze).
6. Sprawdź CLS: placeholdery i aspect-ratio, zanim wjedzie webfont i banner cookie.

## Sitemap obrazów i nazwy plików

Google Grafika korzysta z sitemap obrazów (Yoast/RankMath potrafią ją dołączyć) i z nazw plików. `hero-lcp.webp` jest lepsze niż `IMG_4401.JPG`. Nie buduj osobnej farmy „stron pod grafiki”. Dla AI alt w HTML jest ważniejszy niż nazwa pliku - ale spójność nie szkodzi. Po wdrożeniu sprawdź w raporcie pokrycia, czy ciężkie URL-e obrazów nie zjadają crawla kosztem kategorii. [Zrób darmowy audyt](/) - zobaczysz liczbę obrazów bez alt i czy LCP to grafika.

## FAQ

### Czy alt pomaga w SEO?

Tak, w SEO obrazów i w zrozumieniu strony. Dla pozycji URL-a ważniejsze jest, by obraz nie psuł LCP/CLS. Alt ma też być zgodny z WCAG.

### WebP czy AVIF?

Oba są dobre. AVIF często mniej waży, WebP ma szersze wsparcie narzędzi. Ważniejsze: właściwy rozmiar w pikselach niż wybór między dwoma nowoczesnymi formatami.

### Czy lazy loading zawsze pomaga?

Nie. Na obrazie LCP szkodzi. Stosuj lazy pod foldem, nigdy na hero, które jest LCP.

### Czy srcset jest potrzebny, gdy mam WebP?

Tak. Format to kompresja, srcset to dopasowanie szerokości do ekranu. Bez srcset mobilka może pobrać plik desktopowy.

### Czy CDN rozwiązuje SEO obrazów?

CDN skraca TTFB i transfer, ale nie doda altów ani wymiarów. Najpierw HTML i wagi plików, potem CDN.

### Ile obrazów bez alt to problem?

Już kilka treściowych bez alt na szablonie (karta produktu, artykuł) jest warte naprawy. W audytach często widać dziesiątki na listingach.

URL: https://audyto.com.pl/blog/seo-obrazow-alt-webp-lcp

---

# Canonical, noindex i duplikaty treści

> Canonical mówi „to jest preferowany URL tej treści”. Noindex mówi „nie pokazuj tego URL-a w wynikach”. To nie są zamienniki. robots.txt Disallow nie usuwa strony z indeksu. Najczęstszy błąd: dwa tagi canonical (dwie wtyczki SEO) albo canonical wskazujący na HTTP, gdy strona jest na HTTPS.

Google chce jeden dokument na jedną intencję. Duplikaty powstają z www/non-www, HTTP/HTTPS, UTM, paginacji, sortowania i filtrów. Twoim zadaniem jest albo **złączyć** je kanonicznym, albo **wyjąć z indeksu** (noindex), albo **nie dawać do crawla** (Disallow) - i nie pomylić tych trzech. [robots.txt](/blog/robots-txt-jak-dziala) steruje crawlem, nie indeksem.

## Kiedy canonical, kiedy noindex

| Sytuacja | Narzędzie | Dlaczego |
| --- | --- | --- |
| Ta sama treść pod dwoma URL-ami (www, trailing slash) | 301 + canonical na docelowy | Jedna wersja na zawsze |
| Filtrowany listing z cienką treścią | noindex, follow (albo parametry w GSC) | Nie chcemy rankingów na „czerwony, rozmiar M” |
| Koszyk, thank-you, wyszukiwarka wewnętrzna | noindex | Nie ma wartości w SERP |
| Strona, której nie chcemy w Google, ale ma linki | noindex, bez Disallow | Robot musi zobaczyć noindex |
| API, admin, feedy | Disallow w robots.txt | Oszczędność crawla, nie „ukrycie” |

## Dwa zestawy canonical - klasyk WordPressa

Yoast + RankMath, albo motyw + wtyczka, emitują dwa `<link rel="canonical">`. Google może zignorować oba. W [audycie SEO WordPress](/blog/audyt-seo-wordpress-checklista) to punkt „jedna wtyczka SEO”. Audyto zgłasza strony z wieloma canonical i wieloma JSON-LD.

## Sklepy: facety, UTM, HTTP

- Canonical zawsze do HTTPS i hosta, który jest w Search Console.
- UTM nie powinny tworzyć indeksowalnych kopii - canonical do czystego URL albo 301.
- Magento layered navigation: często tysiące URL-i. Trzeba strategii (noindex filtrów albo canonical do kategorii) - zobacz też [wydajność Magento](/blog/audyt-wydajnosci-magento), bo crawl budget zżera te same facety.

## Jak naprawić duplikaty krok po kroku

1. Wybierz jedną wersję hosta i protokołu; resztę przekieruj 301.
2. W źródle HTML zostaw dokładnie jeden rel=canonical na URL kanoniczny.
3. Wyłącz drugą wtyczkę SEO / duplikat z motywu.
4. Na stronach bez wartości w SERP ustaw meta robots noindex i nie blokuj ich w robots.txt.
5. W Search Console sprawdź „duplikat bez kanonicznego wybranego przez użytkownika”.
6. Po zmianach poproś o indeksację kluczowych URL-i i obserwuj pokrycie.

## hreflang i paginacja - krótko

Wersje językowe to nie duplikat, jeśli każda ma własny hreflang i self-canonical. Paginacja: albo rel next/prev historycznie, albo noindex na stronie 2+ gdy treść jest cienka, albo infinite scroll z jednym kanonicznym listingiem. Nie łącz hreflang wskazującego na URL, który sam ma noindex - to sprzeczny sygnał, podobny do canonical na stronę 404. To fundament [audytu strony WWW](/blog/audyt-strony-www-checklista-2026). [Zrób darmowy audyt](/) - jeśli masz dwa canonical, zobaczysz to w raporcie.

## FAQ

### Czym różni się canonical od noindex?

Canonical wskazuje preferowany URL przy podobnej treści (strona może zostać w indeksie jako duplikat skonsolidowany). Noindex prosi, by tego URL-a nie pokazywać w wynikach. Do usunięcia z indeksu służy noindex, nie canonical w drugą stronę.

### Czy canonical to przekierowanie?

Nie. Użytkownik zostaje na bieżącym URL. To wskazówka dla wyszukiwarki. Siła leży w 301, gdy wersje mają być na stałe jedną.

### Czy robots.txt usuwa duplikat z Google?

Nie. Disallow blokuje crawlowanie. URL może zostać w indeksie bez opisu. Szczegóły w poradniku robots.txt.

### Co zrobić z parametrami UTM?

Nie indeksuj ich. Canonical do wersji bez parametrów albo nie linkuj wewnętrznie z UTM. Kampanie zostaw w analityce, nie w sitemap.

### Czy każdy URL musi mieć canonical?

Tak - nawet self-canonical (wskazanie na siebie). To zmniejsza ryzyko, że parametry albo www „rozjadą” indeks.

### Dlaczego Google wybrał inny kanoniczny niż ja?

Bo sygnały (301, sitemap, linki wewnętrzne, treść) sprzeczne z Twoim tagiem. Wyrównaj je: jedna wersja w sitemap, w menu i w canonical.

URL: https://audyto.com.pl/blog/canonical-noindex-duplikaty

---

# Local SEO: NAP, schema i Google Maps

> Local SEO to spójność nazwy, adresu i telefonu (NAP) w całym internecie plus schema LocalBusiness (adres, geo, openingHours, areaServed) i poprawny profil Google Maps. Rozjechany NIP w stopce i inny telefon w schema psuje zaufanie Google i cytowania w Gemini. Progi nie są „punktami” - liczy się brak sprzeczności.

Jeśli klient szuka „audyt WordPress Kraków” albo „hydraulik Wilanów”, wygrywa nie ogólnopolski blog, tylko spójna encja lokalna. Local SEO to: NAP, Maps, recenzje, strony-lądowania miast (bez doorway spam) i [dane strukturalne](/blog/dane-strukturalne-schema-seo-ai) typu LocalBusiness, nie sam Organization.

## NAP - jedna prawda

- Nazwa, ulica, kod, miasto, telefon w identycznej formie w stopce, regulaminie, schema i Maps.
- Nie skracaj „ul.” w jednym miejscu i „ulica” w drugim, jeśli da się uniknąć - parserzy lubią spójność.
- Jeden główny numer; przekierowanie call-tracking oznacz jako taki sam punkt, nie jako drugi biznes.

## Schema LocalBusiness

Organization na SaaS ogólnopolskim wystarczy. Usługa z adresem potrzebuje LocalBusiness (albo podtypu: ProfessionalService, Store): address, telephone, image, openingHoursSpecification, geo, areaServed. Godziny w schema muszą zgadzać się z Maps. FAQ na stronie kontaktowej może mieć FAQPage - byle pytania były w HTML.

## Maps, recenzje, strony miast

Profil Google Business (Maps) to osobny kanał. Kategorie, godziny, zdjęcia i odpowiedzi na opinie wpływają na pakiet lokalny. Strony „usługa + miasto” działają, gdy mają unikalny opis realizacji, nie skopiowany akapit z podmienionym miastem. Gemini często składa odpowiedź z Maps + Twojej strony - sprzeczny adres = gorsza atrybucja.

## Jak wdrożyć Local SEO krok po kroku

1. Spisz jeden kanoniczny NAP i wklej go w stopkę, kontakt i regulamin.
2. Zaktualizuj Google Maps tak, by godziny i adres były identyczne.
3. Dodaj JSON-LD LocalBusiness (nie drugi, sprzeczny Organization z innym telefonem).
4. Ujednolicić og:locale i dane na stronie kontakt.
5. Zbuduj 1–3 unikalne strony obszarów tylko tam, gdzie naprawdę działasz.
6. Zmierz w Search Console zapytania z miastem i brand + miasto.

## Czego nie robić w Local SEO

- Ukrywać NAP w obrazku stopki - bot i AI nie odczytają adresu z PNG.
- Mieć inny NIP w regulaminie i inny w wizytówce (to nie schema, ale psuje E-E-A-T).
- Kupować recenzje. Google i klienci to widzą; Gemini może zacytować skargę zamiast Ciebie.

Pakiet PRO w Audyto sprawdza sygnały Local SEO (NAP, areaServed, schema). Ogólny przegląd: [audyt strony WWW](/blog/audyt-strony-www-checklista-2026). [Zrób darmowy audyt](/), potem rozważ PRO, jeśli żyjesz z pakietu lokalnego.

## FAQ

### Co to jest NAP w Local SEO?

Name, Address, Phone - nazwa, adres i telefon. Muszą być spójne na stronie, w schema i w Google Maps. Rozjazd to jeden z najczęstszych powodów słabej widoczności lokalnej.

### Czy LocalBusiness jest potrzebny, gdy mam Organization?

Dla firmy z fizycznym adresem lub obszarem usług - tak. Organization bez adresu nie zastąpi sygnałów lokalnych. SaaS ogólnopolski może zostać przy Organization.

### Czy strony typu „usługa + miasto” to spam?

Jeśli treść jest unikalna i oddaje realny obszar działania - nie. Jeśli to ten sam akapit ze zmienionym miastem - tak, Google to filtruje.

### Czy recenzje w Google wpływają na SEO?

Na pakiet lokalny i CTR - tak. To nie jest klasyczny PageRank, ale kompletny profil Maps jest częścią widoczności „blisko mnie”.

### Jak sprawdzić Local SEO samodzielnie?

Porównaj NAP na stronie z Maps i z JSON-LD. Szukaj swojej marki + miasta incognito. Sprawdź, czy telefon w stopce = telefon w schema.

### Czy Audyto robi Local SEO?

Sygnały lokalne (NAP, schema, areaServed) są w pakiecie PRO. Free/Standard skupiają się na technicznym SEO i wydajności całej witryny.

URL: https://audyto.com.pl/blog/local-seo-nap-schema-google-maps

---

# Jak przyspieszyć WordPress: cache i wtyczki

> WordPress jest wolny zwykle przez motyw, Elementor/WPBakery, stertę wtyczek i nieoptymalne obrazy - nie przez „sam CMS”. Kolejność: zmierz LCP na mobile, włącz cache (albo cache serwera), obetnij wtyczki, skompresuj hero bez lazy, PHP 8.x z OPcache. Cel: LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1.

Ten wpis jest o **prędkości**. Checklista indeksowania, Yoast vs RankMath i noindex jest w [audycie SEO WordPress](/blog/audyt-seo-wordpress-checklista). Tu: dlaczego TTFB i LCP padają oraz co da 80% zysku. Progi: [Core Web Vitals](/blog/core-web-vitals-2026-po-ludzku).

## Zmierz, zanim włączysz trzy wtyczki cache

PageSpeed Insights (mobile) + Search Console (CrUX, 28 dni). Lab ≠ pole. Jeśli LCP to obraz - [SEO obrazów](/blog/seo-obrazow-alt-webp-lcp). Jeśli TTFB > 0,8 s, najpierw hosting/PHP, nie minifikacja CSS.

## Cache: jedna warstwa, nie pięć

- Jedna wtyczka cache (WP Rocket, LiteSpeed Cache przy LS, FlyingPress) albo cache na serwerze. Nie Rocket + W3 Total + Super Cache.
- Page cache dla anonimowych; object cache (Redis) gdy baza się dusi.
- Wyłączyć cache na koszyku i checkout (WooCommerce).

## Elementor i page buildery

Każda sekcja dokłada CSS/JS. Globalne widgety, popup „na wejściu” i slider w pierwszym ekranie to typowy zabójca INP i LCP. Zostaw builder tam, gdzie redakcja naprawdę go potrzebuje; szablon bloga i karty produktu trzymaj lżejszym motywem. Nie instaluj dwóch builderów.

## Wtyczki, skrypty, czaty

Nie liczba, tylko waga: trzy ciężkie „all-in-one” są gorsze niż dziesięć lekkich. Odłóż czat, Hotjar i tag manager na interakcję albo consent. Każdy tracker kradnie INP. Bezpieczeństwo (aktualizacje) nadal jest SEO - malware wypada z indeksu; nagłówki: [CSP i HSTS](/blog/naglowki-bezpieczenstwa-http-csp-hsts).

## Jak przyspieszyć WordPress krok po kroku

1. Zmierz mobile LCP/INP/CLS i zapisz element LCP.
2. Włącz jeden cache (lub LiteSpeed) i sprawdź TTFB.
3. Zoptymalizuj hero: WebP, wymiary, bez lazy; preload tylko gdy to na pewno LCP.
4. Usuń nieużywane wtyczki i motywy; zostaw jedną wtyczkę SEO.
5. Ogranicz Elementor na szablonach, które nie muszą być „klockami”.
6. PHP 8.2+ z OPcache, ewentualnie CDN; po 28 dniach sprawdź CrUX.

## WooCommerce: gdzie strona naprawdę zwalnia

Homepage bywa lekki, a karta produktu - nie: galeria, warianty, powiązane, mini-cart. Mierz LCP na URL-u produktu, nie tylko na blogu. Fragmenty AJAX koszyka psują INP, gdy każdy hover odpala skrypt. Na listingach włącz lazy pod foldem, ale nie na pierwszym zdjęciu kategorii, jeśli to LCP. Magento ma osobny przewodnik; tu zostajemy przy WP/Woo. Audyto wykrywa WordPress i wagi frontu w jednym raporcie. [Zrób darmowy audyt](/).

## FAQ

### Jak przyspieszyć WordPress najszybciej?

Włącz jeden cache, skompresuj obraz LCP (bez lazy) i usuń zbędne wtyczki. Potem mierz mobile. Hosting ma sens, gdy TTFB zostaje wysoki po cache.

### Czy Elementor zawsze psuje Core Web Vitals?

Nie zawsze, ale często - przez CSS/JS i slidery w pierwszym ekranie. Im więcej widgetów globalnych, tym gorszy INP. Ogranicz builder do stron, które tego potrzebują.

### WP Rocket czy LiteSpeed Cache?

Przy serwerze LiteSpeed naturalny jest LiteSpeed Cache. Na innym stacku jedna płatna/lekka wtyczka cache. Ważniejsze: nie łączyć kilku cache’y.

### Czy CDN wystarczy zamiast cache?

CDN pomaga w transferze statyków. Bez page cache PHP nadal renderuje każdą wizytę. Zwykle potrzebujesz obu, nie zamiast.

### Ile wtyczek mogę mieć?

Nie ma magicznej liczby. Jeśli Lighthouse pokazuje długie zadania JS i 20 skryptów third-party, jest za dużo wagi, nawet przy 8 wtyczkach.

### Czy motyw premium gwarantuje szybkość?

Nie. Motywy „all-in-one” często ładują wszystko wszędzie. Lepszy lekki, dobrze kodowany szablon niż ciężki „multipurpose”.

URL: https://audyto.com.pl/blog/wydajnosc-wordpress-elementor-cache

---

# AI a SEO w 2026 - jak zmienia się wyszukiwanie

> Wyszukiwanie przesuwa się od listy linków do odpowiedzi generowanych przez AI. Rośnie udział zapytań bez kliknięcia, a ruch coraz częściej przychodzi z cytowań w ChatGPT, Perplexity i Google AI Overviews. SEO nie umiera - zmienia cel: z pozycji na bycie cytowanym, wiarygodnym źródłem.

Przez dwie dekady SEO oznaczało jedno: wejść jak najwyżej na liście dziesięciu niebieskich linków. W 2026 ten model się rozjeżdża. Coraz częściej użytkownik dostaje gotową odpowiedź - od ChatGPT, Perplexity albo z nakładki AI Overviews na wynikach Google - i nie klika w nic. To nie koniec SEO, ale wyraźna zmiana reguł gry.

## Co realnie się zmienia

- **Odpowiedzi zamiast linków.** Systemy AI syntetyzują treść z wielu źródeł i podają jedną odpowiedź z kilkoma cytowaniami.
- **Wzrost zapytań bez kliknięcia.** Część informacji użytkownik dostaje bez wejścia na stronę - liczy się bycie *źródłem* odpowiedzi.
- **Nowy kanał ruchu.** Pojawiają się wejścia z ChatGPT, Perplexity i innych asystentów - warto je mierzyć osobno.
- **Wyżej ceniona wiarygodność.** Modele preferują treści spójne, konkretne i dobrze ustrukturyzowane.

Cel SEO przesuwa się z „bądź wysoko” na „bądź cytowany jako wiarygodne źródło”. To wymaga treści, którą maszyna potrafi łatwo zrozumieć i bezpiecznie zacytować.

## Jak mierzyć ruch z AI w 2026

Warsztat treści (TL;DR, FAQ, schema) jest w przewodniku [GEO / cytowania](/blog/jak-byc-widocznym-w-chatgpt-i-ai-overviews). Ten wpis jest o strategii i pomiarze - inaczej oba URL-e walczą o te same frazy.

- W GA4 utwórz kanał / grupę referral: `chat.openai.com`, `chatgpt.com`, `perplexity.ai`, `gemini.google.com`, `copilot.microsoft.com`.
- Oznacz landingi z bloga parametrem UTM tylko tam, gdzie sami linkujecie z newslettera - nie fałszuj cytowań AI.
- Śledź brand queries w Search Console osobno od non-brand: AI Overviews często zjadają kliknięcia informacyjne, brand zostaje.
- Porównuj sesje vs. wyświetlenia. Spadek CTR przy stabilnych impresjach to typowy ślad zero-click, niekoniecznie utraty pozycji.

## Co zostaje z klasycznego SEO

Indeks Google nadal karmi AI Overviews. [Core Web Vitals](/blog/core-web-vitals-2026-po-ludzku), kanoniczne URL-e, sitemap i brak przypadkowego noindex nadal decydują, czy w ogóle możecie być źródłem. GEO bez indeksacji to teatr.

## Czego nie robić

- Nie porzucaj klasycznego SEO - Google nadal generuje większość ruchu, a AI Overviews bazują na tym samym indeksie.
- Nie produkuj masowo treści generowanej bez kontroli jakości - modele i Google premiują wartość, nie objętość.
- Nie ukrywaj kluczowych faktów w grafikach czy za logowaniem.

## Jak się przygotować

Po stronie strategii: zaplanuj 2 merytoryczne URL-e miesięcznie z datą aktualizacji, mierz referral AI osobno, nie mnoż tematów o tej samej intencji (jeden przewodnik GEO, jeden tekst o rynku). Po stronie technicznej: szybka strona, [schema](/blog/dane-strukturalne-schema-seo-ai), [robots.txt](/blog/robots-txt-jak-dziala) bez blokady botów AI. Chcesz wiedzieć, na czym stoisz dziś? [Zrób darmowy audyt](/).

| Obszar | Co śledzić w 2026 | Czego nie mylić z GEO |
| --- | --- | --- |
| Ruch | Referral z chat.openai.com, perplexity.ai | Pozycja #1 w klasycznym SERP |
| Popyt | Brand vs non-brand w Search Console | Liczba opublikowanych wpisów |
| Ryzyko | Spadek CTR przy stabilnych impresjach | „AI zabiło SEO” jako wniosek |

## FAQ

### Czy AI zabije SEO?

Nie. SEO się zmienia, a nie znika. Google wciąż generuje większość ruchu, a AI Overviews korzystają z tego samego indeksu. Zmienia się cel: liczy się bycie cytowanym, wiarygodnym źródłem.

### Co to są zapytania bez kliknięcia (zero-click)?

To wyszukiwania, w których użytkownik dostaje odpowiedź bezpośrednio w wynikach lub od asystenta AI i nie wchodzi na żadną stronę. Ich udział rośnie wraz z odpowiedziami generowanymi przez AI.

### Jak mierzyć ruch z AI?

Obserwuj w analityce wejścia z domen takich jak chat.openai.com czy perplexity.ai oraz segment ruchu z poleceń (referral). To wciąż niedoskonałe, ale daje obraz trendu.

URL: https://audyto.com.pl/blog/ai-a-seo-2026-jak-zmienia-sie-wyszukiwanie

---

# Nagłówki bezpieczeństwa HTTP: CSP i HSTS

> Nagłówki bezpieczeństwa HTTP to instrukcje wysyłane przez serwer do przeglądarki, które ograniczają ryzyko ataków (XSS, clickjacking, podsłuch). Najważniejsze to HSTS (wymusza HTTPS), CSP (kontroluje, skąd ładują się zasoby) oraz X-Content-Type-Options i Referrer-Policy. Wdrożenie jest tanie i daje szybki efekt.

Nagłówki bezpieczeństwa to jeden z najtańszych sposobów na podniesienie bezpieczeństwa strony - kilka linii w konfiguracji serwera, a chronią przed całą klasą ataków. Mimo to wiele stron ich nie używa. Oto, co warto wdrożyć i dlaczego.

## Najważniejsze nagłówki

| Nagłówek | Przed czym chroni | Wartość na start |
| --- | --- | --- |
| Strict-Transport-Security (HSTS) | Wymusza HTTPS, blokuje downgrade | max-age=31536000; includeSubDomains |
| Content-Security-Policy (CSP) | XSS, wstrzykiwanie skryptów | default-src 'self' (i rozszerzaj) |
| X-Content-Type-Options | MIME sniffing | nosniff |
| Referrer-Policy | Wyciek danych w nagłówku Referer | strict-origin-when-cross-origin |
| X-Frame-Options / frame-ancestors | Clickjacking | DENY lub frame-ancestors 'none' |

## CSP - najpotężniejszy i najtrudniejszy

Content-Security-Policy określa, z jakich źródeł przeglądarka może ładować skrypty, style, obrazy itd. To najskuteczniejsza obrona przed XSS, ale też najłatwiej tu coś zepsuć - zbyt restrykcyjna polityka potrafi zablokować własne zasoby. Zacznij od trybu raportowania:

Gdy zbierzesz raporty i dopniesz wyjątki (np. dla Google Analytics), przełącz na egzekwowanie bez sufiksu `-Report-Only`.

### nginx, WordPress, Magento

- **WordPress:** nagłówki w serwerze albo lekkiej wtyczce security - nie dokładaj ciężkiego „all-in-one”, które psuje [Core Web Vitals](/blog/core-web-vitals-2026-po-ludzku). Checklista: [audyt SEO WordPress](/blog/audyt-seo-wordpress-checklista).
- **Magento:** zwykle nginx przed Varnish. CSP musi uwzględniać CDN i checkout; testuj koszyk, nie tylko homepage. Zobacz też [audyt wydajności Magento](/blog/audyt-wydajnosci-magento).
- **Apache:** odpowiedniki `Header always set` w `.htaccess` działają, ale łatwiej utrzymać je w vhostcie.

HSTS wymusza HTTPS na długo (max-age). Wdrażaj dopiero, gdy masz pewność, że cała domena i subdomeny działają po HTTPS - inaczej możesz zablokować dostęp do strony.

## Jak sprawdzić, co masz teraz

1. Otwórz narzędzia deweloperskie przeglądarki (zakładka Network) i sprawdź nagłówki odpowiedzi.
2. Użyj zewnętrznego skanera nagłówków bezpieczeństwa.
3. Dodaj brakujące nagłówki w konfiguracji serwera (nginx/Apache) lub w warstwie aplikacji.
4. Przetestuj stronę po wdrożeniu - zwłaszcza CSP - żeby nic się nie urwało.

## Częste błędy przy CSP i HSTS

- Włączenie HSTS z `includeSubDomains` zanim staging.twojadomena.pl ma certyfikat.
- `default-src 'self'` bez wyjątków na GTM, Stripe, Turnstile albo fonty - strona „pada” po wdrożeniu.
- Ustawienie CSP tylko na homepage (Next/nginx location) - checkout i /blog muszą dostać te same nagłówki.
- Mieszanie `X-Frame-Options` i `frame-ancestors` z sprzecznymi wartościami.

Nagłówki nie podbijają pozycji bezpośrednio, ale HTTPS (wymuszone HSTS) jest sygnałem zaufania, a dziurawa strona wypada z indeksu po malware. Audyto sprawdza obecność i konfigurację nagłówków bezpieczeństwa w ramach audytu - razem z wydajnością i SEO. [Zrób darmowy audyt](/) i zobacz, czego brakuje.

## FAQ

### Czy nagłówki bezpieczeństwa wpływają na SEO?

Pośrednio. Google premiuje HTTPS (które wymusza HSTS), a bezpieczna, zaufana strona buduje wiarygodność. Same nagłówki nie są czynnikiem rankingowym, ale są elementem zdrowej higieny technicznej.

### Od czego zacząć z CSP?

Od trybu Content-Security-Policy-Report-Only, który raportuje naruszenia bez blokowania. Po zebraniu danych i dodaniu wyjątków przełącz na pełne egzekwowanie.

### Czy HSTS jest bezpieczne do włączenia od razu?

Tylko gdy cała domena i jej subdomeny działają poprawnie po HTTPS. HSTS wymusza HTTPS na czas określony w max-age, więc błąd może czasowo zablokować dostęp.

URL: https://audyto.com.pl/blog/naglowki-bezpieczenstwa-http-csp-hsts

---

# Audyt wydajności Magento - co sprawdzić

> Magento jest potężne, ale wymagające wydajnościowo. Najwięcej zyskasz, pilnując: trybu produkcyjnego, pełnego cache (najlepiej Varnish), aktualnych indeksów, zoptymalizowanego frontendu (merge/minify, obrazy) oraz wydolnej bazy i Redis. Wolny Magento to częściej zła konfiguracja niż słaby serwer.

Magento (Adobe Commerce) to platforma dla wymagających sklepów - ale jej elastyczność ma cenę: bez właściwej konfiguracji potrafi być powolna. Dobra wiadomość jest taka, że większość problemów wydajnościowych wynika z ustawień, nie ze słabego serwera. Zanim zaczniesz dokupować RAM, sprawdź konfigurację - to zwykle tam leży problem.

Wydajność w sklepie to nie kosmetyka: każda dodatkowa sekunda ładowania karty produktu obniża konwersję i pogarsza [Core Web Vitals](/blog/core-web-vitals-2026-po-ludzku), które wpływają na widoczność w Google. Poniżej audyt w kolejności od największych dźwigni do detali.

## 1. Tryb produkcyjny i cache

To pierwsze i najważniejsze, co sprawdzamy. Magento ma trzy tryby pracy (developer, default, production) i różnica wydajności między nimi jest dramatyczna. Sklep produkcyjny działający w trybie developer to klasyk - generuje pliki i kompiluje w locie przy każdym żądaniu.

- Upewnij się, że sklep działa w trybie **production**, nie developer (ogromna różnica w wydajności).
- Włącz wszystkie typy cache Magento (`bin/magento cache:enable`).
- Wdróż **Varnish** jako Full Page Cache - to jedna z największych dźwigni wydajności.
- Skonfiguruj **Redis** dla cache i sesji - odciąża bazę i przyspiesza odczyty.

## 2. Indeksy i zadania cron

Magento opiera się na indeksach (ceny, katalog, wyszukiwarka) i kolejkach przetwarzanych przez cron. Gdy cron nie działa albo indeksy są w trybie „Update on Save”, sklep albo zwalnia przy zapisie, albo serwuje nieaktualne dane.

- Sprawdź, czy indeksy są aktualne i ustawione na tryb „Update on Schedule”.
- Zweryfikuj, że cron działa poprawnie - od niego zależą indeksy, cache, kolejki i e-maile.
- Monitoruj rozmiar tabel logów i kolejek (`*_log`, `*_index`, `quote` potrafią puchnąć do GB).
- Wyczyść stare koszyki (`quote`) i logi - regularny maintenance utrzymuje bazę w ryzach.

## 3. Frontend

Frontend Magento bywa ciężki: dużo JavaScriptu (Knockout, RequireJS), sporo CSS i obrazy produktowe, które zwykle są największym pojedynczym ładunkiem strony. To właśnie tu rozstrzygają się Core Web Vitals widoczne dla użytkownika i dla Google.

- Włącz scalanie i minifikację CSS/JS oraz kompresję (gzip/brotli).
- Zoptymalizuj obrazy (format WebP/AVIF, lazy-loading) - w sklepach to zwykle największy ładunek.
- Ogranicz liczbę i ciężar rozszerzeń (modułów) third-party - każdy dokłada kod do każdej strony.
- Sprawdź [Core Web Vitals](/blog/core-web-vitals-2026-po-ludzku) osobno dla strony głównej, listingu i karty produktu.
- Rozważ optymalizację krytycznego CSS i odroczenie nieistotnego JS pod kątem INP.

## 4. Baza danych i hosting

Magento jest „głodne” zasobów - to platforma korporacyjna, nie blog. Współdzielony hosting praktycznie zawsze będzie wąskim gardłem. Dopiero gdy konfiguracja jest poprawna, warto patrzeć na sprzęt.

- Magento lubi zasoby: szybkie dyski (NVMe), dużo RAM, aktualny PHP z OPcache.
- Rozważ rozdzielenie bazy danych i aplikacji przy większym ruchu.
- Monitoruj wolne zapytania SQL (slow query log) i optymalizuj konfigurację MySQL/MariaDB.
- Dla dużych katalogów rozważ Elasticsearch/OpenSearch dla wyszukiwarki i warstwowania.

## Najczęstsze przyczyny wolnego Magento

| Objaw | Najczęstsza przyczyna | Działanie |
| --- | --- | --- |
| Wolno na każdej stronie | Tryb developer / brak Varnisha | Włącz production + Full Page Cache |
| Wolno tylko przy zapisie produktu | Indeksy „Update on Save” | Przełącz na „Update on Schedule” |
| Karta produktu długo się ładuje | Ciężkie obrazy / moduły third-party | Optymalizacja obrazów, audyt modułów |
| Skoki obciążenia bazy | Brak Redis / spuchnięte tabele | Skonfiguruj Redis, czyść logi i quote |

Trzy rzeczy o największym wpływie: tryb produkcyjny, Varnish jako Full Page Cache i optymalizacja obrazów. Od nich zacznij.

## Jak przeprowadzić audyt wydajności Magento

1. Sprawdź `deploy:mode:show` - na produkcji musi być production.
2. Włącz cache Magento i wdróż Varnish + Redis (cache i sesje).
3. Ustaw indeksy na Update on Schedule i potwierdź, że cron działa.
4. Zmierz [Core Web Vitals](/blog/core-web-vitals-2026-po-ludzku) osobno dla homepage, listingu i karty produktu.
5. Zoptymalizuj obrazy (WebP/AVIF) i zrób audyt ciężkich modułów third-party.

Audyto wykrywa Magento automatycznie, rozpoznaje moduły i custom kod oraz sprawdza wydajność, SEO i bezpieczeństwo sklepu w jednym raporcie - z roadmapą napraw i estymacją kosztów w pakiecie PRO. [Zrób darmowy audyt swojego sklepu](/).

## FAQ

### Dlaczego mój Magento działa wolno?

Najczęściej z powodu konfiguracji: brak trybu produkcyjnego, wyłączony cache lub brak Varnisha, nieaktualne indeksy, nieoptymalne obrazy i nadmiar modułów. Słaby serwer to rzadziej główna przyczyna.

### Czy Varnish jest konieczny w Magento?

Nie jest formalnie wymagany, ale to jedna z największych dźwigni wydajności jako Full Page Cache. W sklepach z realnym ruchem warto go wdrożyć.

### Jaki tryb pracy Magento wybrać na produkcji?

Tryb production. Tryb developer jest wolny i przeznaczony wyłącznie do prac deweloperskich.

### Czy Redis jest potrzebny w Magento 2?

Bardzo zalecany. Redis przejmuje cache i sesje, odciążając bazę danych i znacząco przyspieszając odczyty. W sklepach z realnym ruchem to praktycznie standard.

### Czy współdzielony hosting wystarczy do Magento?

W praktyce nie. Magento to platforma zasobożerna - wymaga dedykowanego serwera lub VPS z odpowiednią ilością RAM, szybkimi dyskami NVMe i aktualnym PHP z OPcache. Na współdzielonym hostingu niemal zawsze będzie wolne.

URL: https://audyto.com.pl/blog/audyt-wydajnosci-magento

---

# Dane strukturalne schema.org a SEO i AI

> Dane strukturalne (schema.org / JSON-LD) to maszynowo czytelny opis treści strony. Dają rich results w Google (gwiazdki, FAQ, ceny) i pomagają modelom AI poprawnie zrozumieć oraz zacytować Twoją stronę. To jeden z najtańszych i najbardziej niedocenianych elementów technicznego SEO.

Wyszukiwarki i modele językowe nie „widzą” strony tak jak człowiek - czytają kod. Dane strukturalne to dodatkowa warstwa opisu, która mówi maszynie wprost: to jest artykuł, to jest produkt z ceną, to jest pytanie i odpowiedź. Dzięki temu Twoja treść bywa pokazywana ładniej w Google i łatwiej trafia do odpowiedzi generowanych przez AI.

## Czym są dane strukturalne

Dane strukturalne to ustandaryzowany słownik [schema.org](https://schema.org), najczęściej zapisywany w formacie **JSON-LD** w sekcji `<script type="application/ld+json">`. Opisuje encje (organizacja, artykuł, produkt, usługa, FAQ) i ich właściwości w sposób, który wyszukiwarki rozumieją jednoznacznie.

Google oficjalnie rekomenduje JSON-LD (zamiast Microdata czy RDFa), bo nie miesza się z treścią i jest łatwy do utrzymania.

## Najważniejsze typy dla zwykłej strony

- **Organization** - nazwa firmy, logo, dane kontaktowe, profile społecznościowe.
- **WebSite** - informacje o serwisie (i opcjonalnie pole wyszukiwania).
- **Article / BlogPosting** - wpisy blogowe: tytuł, autor, daty publikacji i aktualizacji.
- **Product / Offer / AggregateOffer** - produkty i ceny (kluczowe w e-commerce).
- **FAQPage** - pytania i odpowiedzi; często wyświetlane bezpośrednio w wynikach.
- **BreadcrumbList** - ścieżka nawigacji pokazywana w wynikach wyszukiwania.

## Co dają w praktyce

| Efekt | Dla Google | Dla AI (ChatGPT, Perplexity, AI Overviews) |
| --- | --- | --- |
| Lepsze zrozumienie treści | Trafniejsze dopasowanie do zapytań | Mniejsze ryzyko błędnej interpretacji |
| Rich results | Gwiazdki, FAQ, ceny, breadcrumbs | Gotowe, ustrukturyzowane fakty do zacytowania |
| Encje i powiązania | Wiązanie marki z Knowledge Graph | Pewniejsza atrybucja źródła |

Schema nie jest „magicznym boosterem rankingu”. Nie podnosi pozycji bezpośrednio - poprawia *prezentację* i *zrozumienie* treści, co przekłada się na wyższy CTR i większą szansę na cytowanie przez AI.

## Najczęstsze błędy

1. Markup opisuje treść, której nie ma na stronie (Google traktuje to jako spam).
2. Niekompletne wymagane pola (np. `BlogPosting` bez `headline` czy daty).
3. Sprzeczne dane: inna cena w schema, inna na stronie.
4. Brak walidacji - literówka w JSON-LD potrafi wyłączyć cały blok.

## Przykład JSON-LD dla artykułu

Poniższy szkic spełnia wymagania Google dla Article / BlogPosting: nagłówek, obraz 1200×630, daty, autor Person i wydawca Organization. Ten sam wzorzec stosujemy na blogu Audyto.

## Jak wdrożyć schema krok po kroku

Wybierz jedną metodę i trzymaj się jej. Dwa generatory JSON-LD na raz (np. Yoast i RankMath, albo wtyczka + ręczny skrypt) to najczęstszy błąd, który wykrywamy w [audycie SEO WordPress](/blog/audyt-seo-wordpress-checklista).

1. Wypisz encje, które naprawdę są na stronie: Organization, WebSite, Article/BlogPosting, FAQPage, BreadcrumbList, ewentualnie Product.
2. Wdróż JSON-LD w `<head>` albo tuż po `<body>` - jeden spójny blok `@graph`, nie kilka konkurujących skryptów.
3. Upewnij się, że każde pole (cena, data, pytanie FAQ) jest widoczne w HTML. Schema nie może opisywać treści, której nie ma.
4. Dodaj obraz artykułu 1200×630 i ten sam URL w `og:image` oraz `BlogPosting.image`.
5. Zweryfikuj w [teście wyników z elementami rozszerzonymi](https://search.google.com/test/rich-results) i w [validator.schema.org](https://validator.schema.org).

### WordPress, Magento, Next.js

- **WordPress:** Yoast albo RankMath - nie oba. Sprawdź podgląd schema w wtyczce i wyłącz duplikaty z motywu.
- **Magento:** schema produktu i breadcrumbs zwykle daje motyw / moduł SEO. Audytuj kartę produktu osobno od homepage.
- **Własny kod (Next.js):** trzymaj encje w jednym helperze i renderuj JSON-LD po stronie serwera, żeby crawler AI dostał JSON bez JS.

Ustrukturyzowane FAQ i fakty z JSON-LD są łatwiejsze do zacytowania przez ChatGPT i AI Overviews. Szerszy kontekst: [jak być widocznym w odpowiedziach AI](/blog/jak-byc-widocznym-w-chatgpt-i-ai-overviews) oraz [llms.txt](/blog/llms-txt-co-to-jest).

## Jak sprawdzić własną stronę

Użyj [testu wyników z elementami rozszerzonymi Google](https://search.google.com/test/rich-results) oraz walidatora [schema.org](https://validator.schema.org). Potem porównaj, czy `headline`, daty i autor zgadzają się z tym, co widać w przeglądarce. W Audyto wykrywamy obecność i poprawność danych strukturalnych automatycznie - [zrób darmowy audyt](/), żeby zobaczyć, czego brakuje na Twojej stronie.

## FAQ

### Czy dane strukturalne poprawiają pozycję w Google?

Nie bezpośrednio. Schema pomaga wyszukiwarce zrozumieć i ładniej zaprezentować treść (rich results), co zwykle podnosi CTR - a to pośrednio wspiera widoczność.

### Jaki format danych strukturalnych jest najlepszy?

JSON-LD. Jest rekomendowany przez Google, nie miesza się z treścią HTML i jest najłatwiejszy w utrzymaniu.

### Czy schema pomaga w cytowaniach przez ChatGPT i inne AI?

Tak, pośrednio. Ustrukturyzowane, jednoznaczne fakty (FAQ, dane firmy, ceny) są łatwiejsze do poprawnego wyciągnięcia i zacytowania przez modele AI.

URL: https://audyto.com.pl/blog/dane-strukturalne-schema-seo-ai

---

# llms.txt - co to jest i czy warto go mieć w 2026

> llms.txt to plik tekstowy (Markdown) w katalogu głównym domeny, który w zwięzłej formie opisuje, czym jest Twoja strona i gdzie szukać najważniejszych treści. Ma pomagać modelom AI zrozumieć serwis. To propozycja standardu, nie obowiązek - koszt wdrożenia jest minimalny, więc warto go mieć.

Wraz z rozwojem asystentów AI pojawiła się propozycja prostego standardu: `llms.txt`. To plik, który w czytelnej formie podaje modelom językowym streszczenie serwisu i wskazuje najważniejsze podstrony. Idea jest podobna do `robots.txt`, ale cel zupełnie inny: nie *blokować*, tylko *pomóc zrozumieć*.

## Czym jest llms.txt

To plik Markdown dostępny pod adresem `https://twojadomena.pl/llms.txt`. Zaczyna się od nazwy i jednozdaniowego opisu (blok cytatu `>`), a dalej zawiera sekcje z linkami do kluczowych zasobów. Dzięki temu model nie musi zgadywać struktury serwisu z surowego HTML.

## llms.txt a robots.txt - różnice

| Cecha | robots.txt | llms.txt |
| --- | --- | --- |
| Cel | Sterowanie crawlowaniem (co wolno odwiedzać) | Opis i nawigacja po treści dla AI |
| Format | Dyrektywy (User-agent, Disallow) | Markdown (czytelny tekst + linki) |
| Status | Powszechnie respektowany standard | Propozycja standardu, adopcja rośnie |
| Wpływ | Realny i natychmiastowy | Pomocniczy, długofalowy |

## Czy to realnie działa

Bądźmy uczciwi: `llms.txt` nie jest (jeszcze) oficjalnie wspierany przez wszystkich dużych dostawców AI, a jego wpływ jest trudny do zmierzenia. Ale koszt wdrożenia to kilkanaście minut, plik nie szkodzi, a porządkuje komunikację o serwisie. W świecie, w którym ruch z AI rośnie, to rozsądny zakład o niskim ryzyku.

Trzymaj llms.txt zwięzłym i aktualnym. To nie jest miejsce na całą treść - to mapa. Jeśli chcesz, możesz dodać llms-full.txt z pełnymi tekstami kluczowych stron.

Audyto ma własny [llms.txt](/llms.txt) i [llms-full.txt](/llms-full.txt) - możesz je podejrzeć jako przykład. Chcesz sprawdzić, czy Twoja strona jest gotowa pod AI i SEO? [Zrób darmowy audyt](/).

## llms-full.txt - kiedy ma sens

Propozycja standardu przewiduje też `llms-full.txt`: dłuższy plik z pełnymi tekstami kluczowych stron. Ma pomagać modelom, które i tak ściągną treść, ale wolą czysty Markdown od HTML z nawigacją i skryptami. Nie duplikuj tu panelu klienta ani treści za logowaniem.

- Trzymaj w `llms.txt` mapę (kilka kilobajtów), a w `llms-full.txt` treść artykułów i FAQ.
- Aktualizuj oba przy publikacji wpisu - inaczej model dostanie nieaktualną listę URL-i.
- Link do obu plików warto umieścić w [robots.txt](/blog/robots-txt-jak-dziala) nie jest wymagany; wystarczy, że są pod korzeniem domeny.

## Czego nie wkładać do llms.txt

- Pełnych regulaminów i polityk - wystarczy link.
- Treści za logowaniem, raportów klientów i draftów.
- Setek URL-i bez opisu - to mapa, nie sitemap.xml (sitemap zostaw w [robots.txt](/blog/robots-txt-jak-dziala)).

## Jak wdrożyć

1. Stwórz plik `llms.txt` i umieść go w katalogu głównym (dostępny pod `/llms.txt`).
2. Zacznij od nagłówka `#` z nazwą i bloku `>` z jednozdaniowym opisem.
3. Dodaj sekcje `##` z linkami do najważniejszych stron i krótkim opisem każdej.
4. Podaj kontakt i uwagi dla crawlerów (co jest prywatne / nieindeksowane).
5. Opcjonalnie dodaj `llms-full.txt` z Markdownem kluczowych artykułów i zaktualizuj plik przy większych zmianach w serwisie.

Sam plik nie zastąpi [danych strukturalnych](/blog/dane-strukturalne-schema-seo-ai) ani treści napisanej pod [cytowania AI](/blog/jak-byc-widocznym-w-chatgpt-i-ai-overviews). To warstwa mapy, nie substytut SEO.

## FAQ

### Czy llms.txt jest obowiązkowy?

Nie. To propozycja standardu, nie wymóg. Żaden silnik wyszukiwania nie karze za jego brak - ale obecność może pomóc AI lepiej zrozumieć serwis.

### Gdzie umieścić plik llms.txt?

W katalogu głównym domeny, tak aby był dostępny pod adresem https://twojadomena.pl/llms.txt - analogicznie do robots.txt.

### Czym różni się llms.txt od robots.txt?

robots.txt steruje tym, co crawler może odwiedzać. llms.txt nie blokuje niczego - opisuje serwis i wskazuje najważniejsze treści modelom AI.

URL: https://audyto.com.pl/blog/llms-txt-co-to-jest

---

# robots.txt - jak działa i najczęstsze błędy

> robots.txt to plik w katalogu głównym domeny, który mówi robotom, których ścieżek mają nie odwiedzać. Uwaga: to nie jest narzędzie do ukrywania stron z indeksu - od tego jest meta noindex. Najczęstszy błąd to blokowanie zasobów lub mylenie crawlowania z indeksowaniem.

`robots.txt` to jeden z najstarszych mechanizmów sterowania robotami w sieci - i jednocześnie jeden z najczęściej źle rozumianych. Dobrze ustawiony pomaga; źle ustawiony potrafi wyciąć całą stronę z Google.

## Jak działa robots.txt

To plik tekstowy pod adresem `/robots.txt`. Zawiera dyrektywy dla robotów (`User-agent`), wskazujące, czego **nie powinny crawlować** (`Disallow`) lub co mogą (`Allow`). Najczęściej dołącza się też link do mapy strony (`Sitemap`).

robots.txt steruje CRAWLOWANIEM, nie INDEKSOWANIEM. Strona zablokowana w robots.txt nadal może pojawić się w Google (np. bez opisu), jeśli ktoś do niej linkuje. Aby usunąć stronę z indeksu, użyj meta tagu noindex - i nie blokuj jej w robots.txt, bo wtedy robot nie zobaczy tego noindex.

## noindex vs Disallow - kiedy co

| Chcę… | Użyj | Nie używaj |
| --- | --- | --- |
| Nie marnować budżetu crawla na /api | Disallow w robots.txt | - |
| Usunąć stronę z wyników wyszukiwania | meta noindex | Disallow (paradoksalnie zostawi ją w indeksie) |
| Ukryć dane prywatne | Autoryzacja / 401 | robots.txt (to tylko sugestia, nie zabezpieczenie) |

## Crawlery AI - czy je blokować?

Coraz więcej botów to roboty modeli AI. Możesz nimi sterować po `User-agent`:

- **GPTBot** - crawler OpenAI (trening / wyszukiwanie).
- **OAI-SearchBot** - indeksowanie pod wyszukiwanie ChatGPT.
- **ClaudeBot** - crawler Anthropic.
- **PerplexityBot** - crawler Perplexity.
- **Google-Extended** - zgoda/odmowa na użycie treści w produktach AI Google (osobno od zwykłego Googlebota).

Decyzja jest strategiczna: blokując je, chronisz treść, ale tracisz szansę na ruch i cytowania z AI. Dla większości firm marketingowo opłaca się **pozwolić** crawlerom AI na dostęp do treści publicznych. W Audyto robimy tak: `User-agent: *` + osobne reguły Allow dla GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot i Google-Extended, z Disallow tylko na `/audit/`, `/api/` i panele.

| User-agent | Kto | Zalecenie dla treści publicznych |
| --- | --- | --- |
| GPTBot / OAI-SearchBot | OpenAI (trening i wyszukiwanie ChatGPT) | Allow |
| ClaudeBot | Anthropic | Allow |
| PerplexityBot | Perplexity | Allow |
| Google-Extended | Produkty AI Google (osobno od Googlebota) | Allow, chyba że polityka firmy zabrania |

## Jak sprawdzić i wdrożyć poprawny plik

1. Otwórz `https://twojadomena.pl/robots.txt` w przeglądarce - musi odpowiadać 200, nie 404 i nie HTML strony błędu.
2. Dopisz `Sitemap: https://twojadomena.pl/sitemap.xml` (pełny URL, nie ścieżka względna).
3. Disallow tylko na panele, API i prywatne raporty - nie blokuj CSS/JS ani kanonicznych treści.
4. Nie łącz Disallow z noindex na tych samych URL-ach, które chcesz usunąć z indeksu.
5. Po zmianie poproś o ponowne przetworzenie w Google Search Console (narzędzie robots.txt).

Mapa treści dla ludzi i AI to też [llms.txt](/blog/llms-txt-co-to-jest) i [dane strukturalne](/blog/dane-strukturalne-schema-seo-ai). Audyto sprawdza robots.txt, sitemap i dyrektywy indeksowania automatycznie. [Zrób darmowy audyt](/) i upewnij się, że niczego przypadkiem nie blokujesz.

## Najczęstsze błędy

1. `Disallow: /` na produkcji (np. zapomniana blokada z wersji testowej) - znika cała strona.
2. Blokowanie plików CSS/JS - Google nie renderuje strony poprawnie.
3. Próba „ukrycia” treści, którą i tak trzeba zabezpieczyć logowaniem.
4. Brak linku do `Sitemap`.
5. Wielkość liter w ścieżkach - `Disallow` rozróżnia `/Admin` i `/admin`.

## FAQ

### Czy robots.txt usuwa stronę z Google?

Nie. robots.txt blokuje crawlowanie, ale strona może nadal być w indeksie. Do usunięcia z wyników służy meta tag noindex (i strona nie może być zablokowana w robots.txt, by robot mógł go odczytać).

### Czy powinienem blokować crawlery AI w robots.txt?

To zależy od strategii. Blokada chroni treść, ale odcina ruch i cytowania z asystentów AI. Większość firm zyskuje, pozwalając crawlerom AI na dostęp do treści publicznych.

### Gdzie umieścić robots.txt?

W katalogu głównym domeny, pod adresem https://twojadomena.pl/robots.txt. Tylko tam jest respektowany.

URL: https://audyto.com.pl/blog/robots-txt-jak-dziala

---

# Widoczność w ChatGPT i Google AI Overviews

> GEO (Generative Engine Optimization) to rzemiosło treści pod cytowania: TL;DR na górze, nagłówki jak pytania, FAQ w HTML + FAQPage, fakty w tabelach i dostępność dla crawlerów AI. To instrukcja wdrożeniowa - strategię rynku na 2026 opisujemy osobno.

Coraz więcej osób zaczyna szukanie informacji nie w Google, tylko w ChatGPT, Perplexity czy w nakładce AI Overviews na wynikach Google. Te systemy nie pokazują dziesięciu linków - generują odpowiedź i cytują kilka źródeł. Celem GEO jest być jednym z tych cytowanych źródeł.

## Czym GEO różni się od klasycznego SEO

SEO walczy o pozycję w liście wyników. GEO walczy o to, by model **wybrał i zacytował** Twoją treść w generowanej odpowiedzi. Fundamenty są wspólne (jakość, struktura, autorytet), ale akcenty inne: liczy się ekstrahowalność konkretnych faktów.

## Co realnie zwiększa szansę na cytowanie

1. **Streszczenie na górze (TL;DR).** Modele chętnie wyciągają zwięzłe, samodzielne akapity odpowiadające wprost na pytanie.
2. **Struktura nagłówków.** Jeden temat = jeden nagłówek H2/H3 sformułowany jak pytanie lub jasne hasło.
3. **Sekcja FAQ + schema FAQPage.** Pary pytanie–odpowiedź to format, który AI uwielbia cytować.
4. **Konkrety i dane.** Liczby, definicje, tabele i kroki są łatwiejsze do zacytowania niż lanie wody.
5. **Świeżość.** Data publikacji i „ostatnia aktualizacja” budują zaufanie do aktualności.
6. **Autorytet i spójność.** Jasny autor, spójna terminologia, dane strukturalne Organization.

Pisz tak, żeby dało się skopiować jeden akapit jako kompletną odpowiedź na konkretne pytanie - bez reszty artykułu. Jeśli się da, AI też to zrobi.

## Techniczne fundamenty (bez nich GEO nie zadziała)

- Treść musi być **dostępna dla crawlerów AI** (sprawdź [robots.txt](/blog/robots-txt-jak-dziala) i ewentualne blokady GPTBot/ClaudeBot).
- Renderowanie po stronie serwera lub statyczne - treść w surowym HTML, nie tylko po wykonaniu JS.
- Poprawne [dane strukturalne](/blog/dane-strukturalne-schema-seo-ai) (Article, FAQPage, Organization).
- Szybkie ładowanie i sensowne Core Web Vitals - wolne strony bywają gorzej crawlowane.
- Mapa treści: sitemap.xml i opcjonalnie [llms.txt](/blog/llms-txt-co-to-jest).

## Szablon akapitu, który AI da się zacytować

Zły akapit: „Warto zadbać o SEO, bo to ważne dla biznesu i może pomóc w widoczności.” Nic tu nie da się skopiować jako fakt. Dobry akapit: „GEO nie zastępuje SEO. Google nadal indeksuje HTML; ChatGPT i Perplexity cytują strony z TL;DR, FAQ i schema FAQPage, o ile [robots.txt](/blog/robots-txt-jak-dziala) nie blokuje GPTBot/ClaudeBot.”

Zaczynaj sekcję od definicji albo liczby, potem dopiero kontekst. Unikaj zaimków bez odniesienia („to”, „takie rozwiązania”) w pierwszym zdaniu - model wycina fragment bez poprzedniego akapitu.

## Jak wdrożyć GEO na istniejącej stronie

1. Dodaj na górze każdego kluczowego URL-a 2–4 zdania TL;DR, które same odpowiadają na pytanie z tytułu.
2. Zamień H2 na pytania lub jednoznaczne hasła i daj im id (kotwice) pod cytowania fragmentów.
3. Dopisz FAQ widoczne w HTML (nie tylko w accordionie JS) i schema FAQPage zgodne 1:1 z treścią.
4. Wdróż [JSON-LD](/blog/dane-strukturalne-schema-seo-ai) (BlogPosting + Organization + obraz 1200×630) w HTML serwera, nie po hydracji.
5. Sprawdź, czy treść jest w pierwszym HTML (View Source), a crawlery AI nie mają Disallow. Dodaj [llms.txt](/blog/llms-txt-co-to-jest) jako mapę.

## Czego unikać

- Treści „pod słowo kluczowe” bez realnej wartości - AI ją pomija.
- Ukrywania kluczowych informacji za logowaniem lub w obrazkach bez opisu.
- Sprzecznych danych w różnych miejscach (mylą model i obniżają zaufanie).

Strategię rynku (zero-click, pomiar referral z chat.openai.com, co zostaje z klasycznego SEO) opisujemy w [AI a SEO w 2026](/blog/ai-a-seo-2026-jak-zmienia-sie-wyszukiwanie). Tu liczy się warsztat treści. Chcesz wiedzieć, czy strona jest technicznie gotowa pod AI? [Zrób darmowy audyt w Audyto](/).

## FAQ

### Co to jest GEO?

GEO (Generative Engine Optimization) to optymalizacja treści tak, aby była wybierana i cytowana przez systemy generujące odpowiedzi AI, takie jak ChatGPT, Perplexity czy Google AI Overviews.

### Czy GEO zastępuje SEO?

Nie. GEO to rozszerzenie SEO. Te same fundamenty (jakość, struktura, dostępność techniczna, autorytet) działają w obu, ale GEO mocniej akcentuje ekstrahowalność konkretnych faktów.

### Jak najszybciej zwiększyć szansę na cytowanie przez AI?

Dodaj zwięzłe streszczenie na górze artykułu, sekcję FAQ z danymi strukturalnymi FAQPage oraz upewnij się, że treść jest dostępna dla crawlerów AI w surowym HTML.

URL: https://audyto.com.pl/blog/jak-byc-widocznym-w-chatgpt-i-ai-overviews

---

# Core Web Vitals w 2026 - LCP, INP i CLS po ludzku

> Core Web Vitals to trzy wskaźniki jakości doświadczenia użytkownika: LCP (jak szybko ładuje się główna treść), INP (jak szybko strona reaguje na kliknięcia) i CLS (czy układ nie skacze). Cel: LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1. Wpływają na SEO i konwersję.

Core Web Vitals to zestaw wskaźników Google opisujących, jak strona „czuje się” dla użytkownika: czy szybko się ładuje, czy płynnie reaguje i czy nie skacze pod palcem. Są częścią sygnałów rankingowych i - co ważniejsze - wprost wpływają na konwersję. Wolniejsza strona to wyższy współczynnik odrzuceń, krótszy czas wizyty i mniej dokończonych transakcji - dlatego optymalizacja wydajności zwraca się podwójnie: w SEO i w sprzedaży.

W tym przewodniku wyjaśniamy każdy z trzech wskaźników „po ludzku”, pokazujemy progi „dobrych” wyników, najczęstsze przyczyny problemów oraz konkretne kroki naprawcze - tak, żebyś mógł zacząć działać nawet bez zaplecza technicznego.

## Czym są Core Web Vitals i dlaczego Google je liczy

Google chce serwować w wynikach strony, które są nie tylko trafne, ale i przyjemne w użyciu. Klasyczne metryki (np. czas ładowania całej strony) słabo oddawały realne doświadczenie, więc Google wybrał trzy wskaźniki, które najlepiej korelują z tym, jak użytkownik odbiera stronę: szybkość pojawienia się treści (LCP), responsywność na interakcje (INP) i stabilność układu (CLS). Razem tworzą część oceny „Page Experience”.

Ważne: Core Web Vitals nie zastąpią dobrej treści ani linków. Działają raczej jak „dogrywka” - przy dwóch porównywalnych stronach lepsze wskaźniki mogą przeważyć. A ponieważ wpływają też na konwersję, warto je poprawiać niezależnie od samego SEO.

## Trzy wskaźniki, które trzeba znać

| Wskaźnik | Co mierzy | Dobry wynik |
| --- | --- | --- |
| LCP (Largest Contentful Paint) | Czas do wyświetlenia największego elementu treści | ≤ 2,5 s |
| INP (Interaction to Next Paint) | Responsywność na interakcje użytkownika | ≤ 200 ms |
| CLS (Cumulative Layout Shift) | Stabilność układu (czy elementy skaczą) | ≤ 0,1 |

INP zastąpił dawny FID w 2024 roku. Jeśli czytasz starszy poradnik mówiący o „First Input Delay”, to nieaktualna wiedza.

## Jak poprawić LCP

LCP mierzy, kiedy pojawia się największy widoczny element nad „linią zgięcia” - zwykle obraz hero, baner lub duży nagłówek. Zły LCP najczęściej wynika z wolnego serwera (wysoki TTFB), ciężkiego, nieopóźnionego obrazu albo zasobów blokujących renderowanie. Działaj w tej kolejności:

- Optymalizuj największy element (zwykle obraz hero lub nagłówek) - kompresja, format WebP/AVIF, właściwy rozmiar.
- Używaj `priority`/preload dla kluczowego obrazu i unikaj ładowania go z opóźnieniem (lazy-loading na elemencie LCP to częsty błąd).
- Ogranicz czas odpowiedzi serwera (TTFB): cache, CDN, szybszy hosting.
- Eliminuj zasoby blokujące renderowanie (ciężki CSS/JS w `<head>`).
- Serwuj fonty lokalnie z preload zamiast łańcucha przekierowań do zewnętrznego CDN.

Zanim cokolwiek poprawisz, ustal, który element jest „tym największym”. PageSpeed Insights i Lighthouse wprost pokazują selektor elementu LCP. W audycie Audyto (pakiet Standard i wyżej) podajemy selektor i snippet HTML, żeby nie zgadywać.

## Jak poprawić INP

INP (Interaction to Next Paint) opisuje, jak szybko strona reaguje na działania użytkownika - kliknięcie, tapnięcie, wpisanie tekstu. Główny winowajca to JavaScript: gdy główny wątek przeglądarki jest zajęty wykonywaniem skryptów, interfejs „zawiesza się” na ułamki sekundy. Im więcej kodu i im cięższe skrypty third-party, tym gorszy INP.

- Zmniejsz ilość i ciężar JavaScriptu wykonywanego na starcie.
- Dziel długie zadania (long tasks) i odraczaj nieistotny kod (`defer`, dynamiczny import, `requestIdleCallback`).
- Uważaj na ciężkie skrypty third-party (czaty, widżety, trackery) - ładuj je leniwie lub po interakcji.
- Ogranicz pracę wykonywaną w handlerach zdarzeń (debounce, przeniesienie ciężkich operacji poza główny wątek).

## Jak poprawić CLS

CLS karze za „skakanie” układu - gdy treść przesuwa się po załadowaniu i użytkownik klika nie to, co chciał. Najczęstsze przyczyny to obrazy bez zarezerwowanych wymiarów, reklamy/bannery wstrzykiwane nad treścią oraz fonty, które przy podmianie zmieniają wysokość tekstu.

- Ustaw wymiary (width/height) obrazów i osadzeń, żeby rezerwowały miejsce.
- Nie wstrzykuj treści nad istniejącą (np. banerów, cookie barów) po załadowaniu - rezerwuj dla nich miejsce z góry.
- Ładuj fonty tak, by ograniczyć przeskoki tekstu (`font-display: swap` + preload, dopasowane metryki fallbacku).
- Unikaj animacji zmieniających rozmiar/layout - preferuj `transform` i `opacity`.

## Dane laboratoryjne kontra dane z terenu

To rozróżnienie myli najwięcej osób. **Dane laboratoryjne** (lab) pochodzą z jednorazowego, syntetycznego testu w kontrolowanych warunkach - tak działa Lighthouse. **Dane z terenu** (field, CrUX) to uśrednione wyniki realnych użytkowników z ostatnich 28 dni. Google do oceny rankingowej bierze pod uwagę dane z terenu.

Dlatego idealny wynik w Lighthouse nie gwarantuje dobrych Core Web Vitals w Search Console - Twoi użytkownicy mogą mieć wolniejsze łącza, starsze telefony albo wchodzić na cięższe podstrony. Optymalizuj „w labie”, ale weryfikuj „w terenie”.

## Najczęstsze błędy, które psują wyniki

- Lazy-loading nałożony na obraz LCP (paradoksalnie opóźnia najważniejszy element).
- Testowanie tylko desktopa - Google priorytetowo ocenia mobile.
- Naprawianie pojedynczej podstrony zamiast szablonu, który generuje setki podobnych stron.
- Ignorowanie skryptów marketingowych, które potrafią dokładać sekundy do INP.
- Mylenie wyniku „Performance” w Lighthouse z Core Web Vitals - to powiązane, ale nie to samo.

## Audyt Core Web Vitals krok po kroku

1. Zmierz stan wyjściowy w [PageSpeed Insights](https://pagespeed.web.dev) (mobile i desktop) oraz w Google Search Console (dane z terenu).
2. Zidentyfikuj element LCP i jego czas - to zwykle najszybsza wygrana.
3. Sprawdź TTFB - jeśli serwer odpowiada wolno, żadna optymalizacja frontu w pełni tego nie nadrobi.
4. Przejrzyj raport „Reduce JavaScript / long tasks” pod kątem INP.
5. Znajdź źródła przesunięć układu (CLS) - obrazy bez wymiarów, late-loaded banery.
6. Wdróż poprawki na poziomie szablonu, nie pojedynczej strony.
7. Odczekaj ~28 dni i zweryfikuj dane z terenu w Search Console.

## Czym zmierzyć

Dane „laboratoryjne” daje [PageSpeed Insights](https://pagespeed.web.dev) i Lighthouse, a dane „z terenu” (realnych użytkowników) - raport Core Web Vitals w Google Search Console. Dodatkowo warto zajrzeć do rozszerzenia Web Vitals dla Chrome (podgląd na żywo). Audyto liczy te wskaźniki dla mobile i desktop w ramach audytu, wskazuje element LCP i podpowiada, co naprawić w pierwszej kolejności - [sprawdź swoją stronę za darmo](/).

## FAQ

### Jakie są dobre wyniki Core Web Vitals?

LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1. Wartości te powinny być spełnione dla 75% wizyt na urządzeniach mobilnych i desktopowych.

### Czy Core Web Vitals wpływają na pozycję w Google?

Tak, są jednym z sygnałów rankingowych w ramach oceny doświadczenia na stronie. Nie są najważniejszym czynnikiem, ale przy porównywalnej treści mogą przeważyć.

### Co zastąpiło FID?

Od marca 2024 roku wskaźnik INP (Interaction to Next Paint) zastąpił FID jako miarę responsywności w Core Web Vitals. Jeśli poradnik wspomina o „First Input Delay”, to nieaktualna wiedza.

### Dlaczego mam dobry wynik w Lighthouse, a złe Core Web Vitals w Search Console?

Bo to dwa różne źródła danych. Lighthouse to test laboratoryjny (jedno urządzenie, kontrolowane warunki), a Search Console pokazuje dane z terenu - uśrednione wyniki realnych użytkowników z ostatnich 28 dni, często na słabszym sprzęcie i łączu. Google ocenia ranking na podstawie danych z terenu.

### Czy poprawa Core Web Vitals zwiększy mi sprzedaż?

Pośrednio bardzo często tak. Szybsza i stabilniejsza strona obniża współczynnik odrzuceń i zwiększa liczbę dokończonych akcji (zakup, formularz). Sam wpływ na pozycję w Google jest umiarkowany, ale poprawa konwersji bywa odczuwalna od razu.

### Mobile czy desktop - co jest ważniejsze?

Mobile. Google stosuje mobile-first indexing i to wyniki mobilne mają największe znaczenie. Optymalizuj przede wszystkim pod telefony, a desktop traktuj jako kontrolę.

URL: https://audyto.com.pl/blog/core-web-vitals-2026-po-ludzku

---

# Audyt SEO WordPress - checklista krok po kroku

> Audyt SEO WordPress warto zacząć od indeksowania (robots.txt, sitemap, noindex), potem wydajność (Core Web Vitals, cache, obrazy), treść i meta dane, dane strukturalne oraz bezpieczeństwo (aktualne wtyczki, nagłówki HTTP). Najwięcej problemów generują nadmiar wtyczek i nieoptymalne obrazy.

WordPress napędza ogromną część internetu, ale jego elastyczność bywa pułapką: nadmiar wtyczek, ciężkie motywy i nieoptymalne obrazy potrafią zabić wydajność i SEO. Audyt SEO WordPress nie polega na „zainstalowaniu wtyczki, która naprawi wszystko” - to systematyczny przegląd od fundamentów (czy strona w ogóle jest indeksowana) po detale (dane strukturalne, alt-y obrazów).

Poniżej praktyczna checklista ułożona w kolejności priorytetów - od rzeczy, które potrafią całkowicie zablokować widoczność w Google, po optymalizacje, które dokładają ostatnie kilka procent. Przejdź ją po kolei: nie ma sensu dopieszczać meta description, jeśli cała witryna ma włączony `noindex`.

## 1. Indeksowanie i dostępność

To absolutny fundament. Jeśli Google nie może zindeksować strony, reszta optymalizacji jest bez znaczenia. Najczęstszy, dramatyczny błąd po wdrożeniu nowej witryny: zostawione zaznaczenie „Proś wyszukiwarki o nieindeksowanie tej witryny”, które ustawia globalny `noindex`.

- Sprawdź ustawienie „Widoczność dla wyszukiwarek” (Ustawienia → Czytanie) - łatwo zostawić włączone `noindex` po wdrożeniu.
- Zweryfikuj [robots.txt](/blog/robots-txt-jak-dziala) i obecność `sitemap.xml` (Yoast/RankMath generują ją automatycznie).
- Upewnij się, że ważne strony nie mają przypadkowego `noindex` (częsty błąd wtyczek SEO i ustawień typów treści).
- Sprawdź kanoniczne adresy (canonical) i przekierowania (brak łańcuchów 301 i pętli).
- Prześlij sitemap w Google Search Console i sprawdź raport „Strony” pod kątem wykluczeń.

Po migracji lub uruchomieniu nowej strony numer jeden problemów to globalny noindex zostawiony z fazy budowy. Zawsze sprawdzaj to jako pierwsze - potrafi „skasować” całą witrynę z Google mimo idealnej reszty.

## 2. Wydajność

WordPress sam w sobie nie jest wolny - wolne są zwykle przeładowane motywy, page buildery (Elementor, WPBakery) i sterta wtyczek dokładających własny CSS/JS na każdej stronie. Wydajność to dziś realny czynnik SEO przez [Core Web Vitals](/blog/core-web-vitals-2026-po-ludzku), a do tego wprost wpływa na konwersję.

- Zmierz [Core Web Vitals](/blog/core-web-vitals-2026-po-ludzku) dla mobile i desktop.
- Włącz cache (wtyczka typu WP Rocket / W3 Total Cache lub cache po stronie serwera, np. LiteSpeed).
- Optymalizuj obrazy: format WebP/AVIF, lazy-loading, właściwe wymiary (nie ładuj zdjęcia 4000 px do miniatury).
- Ogranicz liczbę wtyczek - każda dokłada CSS/JS i ryzyko konfliktów.
- Rozważ CDN i nowszy PHP z OPcache - starsze wersje PHP potrafią być wielokrotnie wolniejsze.

## 3. Treść i meta dane

Tu zaczyna się klasyczne SEO on-page. Każda istotna strona powinna mieć unikalny, opisowy tytuł z frazą kluczową oraz zachęcającą meta description (nie jest czynnikiem rankingowym, ale wpływa na CTR z wyników). Pilnuj też logicznej struktury nagłówków - to mapa treści dla Google i czytników ekranu.

- Unikalne, opisowe tytuły (`<title>`) i meta description dla kluczowych stron.
- Sensowna struktura nagłówków (jeden H1 na stronę, hierarchiczne H2/H3).
- Atrybuty `alt` na obrazach (dostępność + SEO obrazów).
- Brak duplikatów treści (np. tagi/archiwa generujące cienkie strony - rozważ ich `noindex`).
- Linkowanie wewnętrzne między powiązanymi wpisami i stronami (rozkłada „moc” i pomaga indeksacji).

### Yoast czy RankMath?

Obie wtyczki robią dobrze to samo: tytuły, meta, sitemap, dane strukturalne i podpowiedzi on-page. Wybierz jedną i trzymaj się jej - **nie instaluj dwóch naraz**, bo zaczną generować zduplikowane tagi canonical i konkurujące dane JSON-LD. To jeden z najczęstszych konfliktów, jaki wykrywamy w audytach.

## 4. Dane strukturalne

Dane strukturalne to maszynowy opis treści, który zwiększa szansę na rich results w Google i poprawne cytowania w AI. WordPress z dobrą wtyczką SEO generuje sporo tego automatycznie, ale warto zweryfikować, co faktycznie trafia na stronę.

Dodaj [dane strukturalne](/blog/dane-strukturalne-schema-seo-ai): Organization, Article/BlogPosting dla wpisów, Product dla sklepu (WooCommerce), FAQPage tam, gdzie masz pytania i odpowiedzi. Sprawdź wynik w teście wyników z elementami rozszerzonymi Google i upewnij się, że nie masz dwóch zestawów JSON-LD od konkurujących wtyczek.

## 5. Bezpieczeństwo

Bezpieczeństwo to też SEO: zhakowana strona bywa oznaczana w wynikach, traci zaufanie i pozycje, a w skrajnym przypadku zostaje usunięta z indeksu. WordPress jest najczęściej atakowaną platformą właśnie przez przestarzałe wtyczki.

- Aktualizuj rdzeń WordPressa, motyw i wtyczki - przestarzałe wtyczki to najczęstszy wektor ataku.
- Usuń nieużywane wtyczki i motywy (nie dezaktywuj - usuń).
- Sprawdź [nagłówki bezpieczeństwa HTTP](/blog/naglowki-bezpieczenstwa-http-csp-hsts) (HSTS, CSP, X-Content-Type-Options).
- Wymuś HTTPS i bezpieczne hasła / 2FA dla kont administracyjnych.
- Ogranicz próby logowania i zmień domyślny adres `/wp-admin`, jeśli to możliwe.

## W jakiej kolejności to robić

1. Najpierw indeksowanie - upewnij się, że Google w ogóle widzi stronę.
2. Potem wydajność - Core Web Vitals i ograniczenie wtyczek/obrazów.
3. Następnie treść i meta - tytuły, opisy, nagłówki, linkowanie wewnętrzne.
4. Dane strukturalne - jeden spójny zestaw schema bez konfliktów.
5. Na końcu bezpieczeństwo i higiena - aktualizacje, nagłówki, kopie zapasowe.

Jeśli masz zrobić tylko trzy rzeczy: ogranicz wtyczki, zoptymalizuj obrazy i zaktualizuj wszystko. To rozwiązuje większość problemów typowej strony na WordPressie.

Audyto automatycznie wykrywa WordPress, sprawdza wersje wtyczek (z bazą CVE w pakiecie PRO), wydajność, SEO i nagłówki bezpieczeństwa w jednym raporcie - z konkretną listą usterek do naprawy. [Zrób darmowy audyt swojej strony](/).

## FAQ

### Od czego zacząć audyt SEO WordPress?

Od indeksowania: sprawdź, czy strona nie jest ustawiona na noindex, czy robots.txt nie blokuje treści i czy istnieje poprawny sitemap.xml. Bez tego reszta optymalizacji nie zadziała.

### Czy duża liczba wtyczek szkodzi SEO?

Pośrednio tak. Każda wtyczka dokłada kod (CSS/JS) i może spowalniać stronę oraz tworzyć konflikty, co pogarsza Core Web Vitals i bezpieczeństwo. Mniej znaczy lepiej.

### Jak często robić audyt SEO?

Pełny audyt warto robić co kwartał oraz po każdej większej zmianie (nowy motyw, migracja, redesign). Podstawowe wskaźniki warto monitorować na bieżąco.

### Yoast SEO czy RankMath - co wybrać?

Obie wtyczki dobrze realizują podstawy SEO (tytuły, meta, sitemap, dane strukturalne). Wybierz jedną i używaj wyłącznie jej - instalacja dwóch naraz powoduje zduplikowane tagi canonical i konkurujące dane JSON-LD, co szkodzi SEO.

### Czy darmowy motyw WordPress wystarczy do dobrego SEO?

Tak, o ile jest lekki i dobrze zakodowany. Problemem nie jest cena motywu, lecz jego waga i jakość kodu. Przeładowane motywy „all-in-one” z dziesiątkami funkcji często psują Core Web Vitals bardziej niż prosty, szybki szablon.

### Ile wtyczek to za dużo?

Nie ma sztywnej liczby - liczy się ich jakość i waga, nie ilość. Dziesięć lekkich, dobrze utrzymanych wtyczek jest lepsze niż trzy ciężkie, które ładują własny CSS/JS na każdej stronie. Usuń wszystko, czego realnie nie używasz.

URL: https://audyto.com.pl/blog/audyt-seo-wordpress-checklista

## Uwagi

- Raporty pod /audit/ są prywatne.
- Kontakt: kontakt@audyto.com.pl