Audyt techniczny SEO: co obejmuje w 2026 roku?

Na wstępie warto wyjaśnić, że raport wynikający z audytu SEO potrafi zestawić ze sobą zarówno błahostki, jak i poważne błędy krytyczne. Przykładowo, może to być brak tekstu alternatywnego przy obrazku obok blokady całej sekcji w robots.txt. Żeby ustalić sensowną kolejność prac, potrzebujesz kontekstu, czyli np. musisz znać rolę danego obrazu, skalę problemu oraz znaczenie dotkniętych stron dla użytkowników. O ile brak atrybutu alt to drobnostka, która utrudnia dostęp do informacji, o tyle blokada robota całkowicie uniemożliwia pobieranie treści i wyłapywanie jej zmian.

W niniejszym przewodniku układam audyt techniczny SEO w 6 warstw, które pomagają precyzyjnie zdiagnozować problemy i zaplanować ich naprawę. Poszczególne obszary ściśle ze sobą współpracują – linkowanie pomaga Google odkrywać nowe adresy, a wydajność serwera decyduje o tym, czy w ogóle da radę je pobrać. W związku z powyższym priorytet konkretnej poprawki wynika z zebranych dowodów oraz realnego wpływu na serwis.

Szczegóły wdrożenia w aplikacjach znajdziesz w przewodniku po audycie technicznym SEO dla React i Next.js.

Warstwowy model audytu technicznego SEO

Kolejność ma tutaj fundamentalne znaczenie, ponieważ na przykład nie ma sensu optymalizować meta description na stronie, która zwraca 500 co trzecie żądanie.

Zakres audytu zależy od rodzaju serwisu

Od razu zaznaczę, że sześć warstw tworzy wspólny rdzeń audytu, ale nie każda witryna wymaga tych samych szczegółowych testów. Dlatego też przed rozpoczęciem przypisz do zakresu funkcje i typy stron, które rzeczywiście występują w serwisie.

Co zmieniło się w technicznym SEO od 2024 roku

Listę kontrolną należy aktualizować równolegle z dokumentacją narzędzi. Uwzględniając stan na dziś, czyli 7 września 2026 roku, w procedurze audytowej warto wziąć pod uwagę przede wszystkim następujące obszary:

• INP zastąpił FID w Core Web Vitals 12 marca 2024. Raport oceniający dzisiejszą responsywność powinien korzystać z aktualnej metryki.

• FAQ rich results wycofano 7 maja 2026. W czerwcu usunięto ich dokumentację. Zmiany innych typów danych strukturalnych wdrażano etapami, dlatego sprawdzaj wsparcie dla konkretnej funkcji.

• Dostęp dla AI wymaga sprawdzenia kilku zastosowań treści. Dalej opisuję osobno wyszukiwanie, trening modeli i pobieranie na żądanie, wraz z aktualnymi ustawieniami Cloudflare.

• GSC udostępnia osobną kontrolę i raport dla generatywnego AI. Od 31 sierpnia 2026 ustawienie generatywnej AI w wyszukiwarce jest dostępne globalnie, podobnie jak raport wyświetleń w AI Overviews i AI Mode.

Dostępność dla robotów (warstwa 1): czy robot może wejść

Plik robots.txt: reguły dostępu dla crawlerów

Zacznij od weryfikacji pliku robots.txt w katalogu głównym hosta i porównaj zawarte w nim reguły z listą sekcji, które powinny być dostępne dla robotów. W związku z botami AI trzeba wydzielić kwestię wytycznych tworzonych z myślą o tradycyjnych wyszukiwarkach, ponieważ mogą przy okazji odciąć asystentów od dostępu do treści, co nie zawsze jest zamierzonym efektem. Rozkładam to na czynniki w tekście o robots.txt dla agentów AI.

Plik robots.txt steruje pobieraniem strony, czyli zablokowany adres może nadal pojawić się w Google na podstawie informacji z innych miejsc, choć robot nie odczyta jego treści. Trzeba pamiętać, że do wykluczenia dostępnej strony z indeksu służy noindex. Oba ustawienia mogą istnieć jednocześnie, ale Disallow uniemożliwi robotowi odczytanie aktualnego noindex. W audytach sporo pomyłek związanych jest z myleniem ze sobą noindex i Disallow, stosowaniem jednego i drugiego, ale zamianą ich funkcji. Nie popełnij tego błędu.

Co należy sprawdzić:

• Czy nie blokujesz CSS i JS potrzebnych do renderowania (np. regułą Disallow: /wp-content/ w konfiguracji WordPressa).

• Czy na produkcję nie trafiła testowa blokada całej witryny, poprzez Disallow: /.

• Czy sprawdzasz właściwy plik dla danego protokołu, hosta i portu; reguły z https://example.com/robots.txt nie obejmują automatycznie subdomeny.

• Jak działa dopasowanie user-agenta: Google wybiera najbardziej szczegółowe i łączy grupy dotyczące tego samego dopasowania; nie dodaje do nich reguł z ogólnej grupy *.

• Czy plik jest dostępny i nie zwraca 5xx; przy awarii Google wstrzymuje pobieranie, ponawia próby i może korzystać z wcześniejszej kopii, a dalsze zachowanie zależy od czasu awarii i dostępności witryny.

• Czy odpowiedź jest zwykłym plikiem tekstowym w UTF-8 i mieści się w limicie Google wynoszącym 500 KiB; dalsza część większego pliku jest ignorowana.

• Czy konfiguracja nie polega na nieobsługiwanym polu; Google ignoruje m.in. crawl-delay, podczas gdy Bing może je respektować.

• Czy zawiera odwołanie do sitemapy.

Kody odpowiedzi HTTP: 200, 301, 404 i 5xx

Przecrawluj całą witrynę i zbierz rozkład kodów odpowiedzi, by potem przeanalizować następujące rzeczy:

• 200: udane żądanie. Sprawdź jeszcze treść odpowiedzi, ponieważ sam kod nie gwarantuje indeksacji.
• 301 lub 308: trwałe przekierowanie. Dobierz je do trwałej zmiany adresu.
• 302 lub 307: przekierowanie tymczasowe. Jest poprawne, gdy przeniesienie ma taki charakter.
• 404: brak zasobu. Może być zamierzony po usunięciu strony bez odpowiednika. Napraw prowadzące do niej linki wewnętrzne; linki zewnętrzne oceń pod kątem możliwości odzyskania wartościowego ruchu.
• 410: zasób trwale usunięty. Semantyka różni się od 404, ale Google traktuje oba kody tak samo w opisanym mechanizmie usuwania z indeksu.
• 429 i 5xx: przeciążenie lub błędy serwera, które mogą ograniczać tempo pobierania. Długotrwałe problemy wymagają szybkiej diagnozy.

Google opisuje wspólną obsługę kodów 4xx z wyjątkiem 429 oraz skutki błędów serwera w dokumentacji HTTP. Na czas krótkiej przerwy serwisowej użyj 503 i monitoruj powrót do poprawnej odpowiedzi. Nagłówek Retry-After może wskazać czas ponowienia, ale nie jest warunkiem poprawności samego statusu.

Przekierowania: łańcuchy, pętle i linkowanie wewnętrzne

Sprawdź trzy rzeczy: łańcuchy, pętle i przekierowania w linkowaniu wewnętrznym.

Łańcuchy (A → B → C → D) wymagają kolejnych żądań, więc należy je skracać do adresu docelowego, czyli np. A → D. Z kolei pętle uniemożliwiają zakończenie przekierowania, więc trzymaj się zasady, by w linkach wewnętrznych stosować zawsze docelowe URL-e, żeby użytkownik i robot mogli od razu pobrać właściwą stronę.

Sprawdź też przekierowania wielu usuniętych podstron na stronę główną, ponieważ w sytuacji, kiedy cel nie odpowiada starej treści, Google może potraktować takie adresy jako soft 404.

Soft 404: strona bez treści z kodem 200

To sytuacja, w której Google wykrywa brak właściwej treści lub komunikat błędu, mimo że serwer zwraca poprawny kod – najczęściej 200 OK. Warto sprawdzić puste szablony po awarii API, komunikaty typu nie znaleziono oraz aplikacje renderowane przez JavaScript, które wyświetlają błąd dopiero po stronie klienta. Co istotne, samo wycofanie produktu ze sprzedaży nie oznacza automatycznie błędu soft 404, o ile strona nadal oferuje użytkownikowi wartościową treść.

Stabilność serwera i statystyki indeksowania

W Search Console otwórz Ustawienia → Statystyki indeksowania. Znajdziesz tam średni czas odpowiedzi, rozkład kodów i typów pobieranych plików. Rosnący czas odpowiedzi przy stałej liczbie żądań to sygnał, że serwer zaczyna być wąskim gardłem, a Google zmniejsza tempo crawlowania witryn, które wolno odpowiadają.

Renderowanie (warstwa 2): czy robot widzi treść strony

To, że strona działa płynnie u Ciebie w przeglądarce, o niczym jeszcze nie świadczy, ponieważ robot Google może widzieć i pobierać coś zupełnie innego. Dlatego przy diagnozie musisz sprawdzić oba te widoki. Google wrzuca strony do osobnej kolejki renderowania, przez co kod JavaScript może wykonać się dopiero chwilę po samym pobraniu HTML-u. I co ważne, nie ma żadnego oficjalnego przelicznika, który mówiłby, że domena z wyższym autorytetem czeka na to krócej.

Udostępnienie głównej treści w odpowiedzi serwera zmniejsza zależność od wykonania skryptów i pomaga odbiorcom bez ich obsługi. W aplikacjach React różnice między tym, co widzi przeglądarka, a tym, co dostaje robot, opisuję osobno w tekstach o wpływie React Server Components na SEO oraz o hydration mismatch pod lupą Googlebota. Dlaczego framework z prerenderingiem daje tu przewagę nad aplikacją renderowaną wyłącznie w przeglądarce, wyjaśniam w przewodniku o SEO w Next.js.

Co sprawdzić:

• Czy treść jest w źródłowym HTML-u? Najprostszy test polega na wyłączeniu JS w przeglądarce albo pobraniu strony przez curl i sprawdzeniu, czy widzisz nagłówki, treść i linki. Drugi test jest w Search Console i to opcja Sprawdzenia adresu URL → Testuj adres URL na żywo → zakładka HTML i porównaj, co widzi Googlebot po renderowaniu.
• Czy metadane są zgodne przed renderowaniem i po nim? Google potrafi odczytać title, opis i link kanoniczny ustawione przez JS. Szukaj sprzecznych wartości, braków po błędzie skryptu i wielu deklaracji kanonicznych; preferuj poprawną deklarację już w HTML-u.
• Czy linki mają <a href> z docelowym URL-em? Sama obsługa onclick na elemencie <div> nie zapewnia robotowi zwykłego odnośnika do odkrycia.
• Czy treść nie jest ukryta pod interakcją? Zawartość ładowana dopiero po kliknięciu „pokaż więcej”, po przewinięciu albo w zakładkach doładowywanych asynchronicznie może nie zostać zindeksowana. Treść w akordeonie obecna w HTML-u od początku jest w porządku, problem dotyczy treści, której w HTML-u nie ma.
• Czy dalsze strony listy mają własne URL-e i linki? Sam przycisk „załaduj więcej” nie zapewnia przejścia dla robota. Produkty mogą zostać odkryte inną drogą, np. przez sitemapę, ale paginacja powinna umożliwiać ich przeglądanie przez zwykłe odnośniki.

Indeksacja (warstwa 3): czy wyszukiwarka chce zaindeksować stronę

Raport indeksowania stron w Google Search Console

Do analizy ogólnych trendów wykorzystaj raport o indeksowaniu, a w celu szczegółowej weryfikacji konkretnego URL-a użyj narzędzia inspekcji adresów. Operator site: przydaje się w zasadzie tylko do szybkiego sprawdzenia, czy pojedynczy adres w ogóle znajduje się w indeksie i nie odzwierciedla pełnej struktury ani skali serwisu. Pamiętaj też o wyraźnych ograniczeniach samego Google Search Console: raporty prezentują jedynie reprezentatywną próbkę adresów, a nie ich kompletną listę z danej kategorii.

W raporcie stron najważniejsze są przyczyny wykluczenia i jest kilka, które warto umieć czytać:

• Wykryta, obecnie niezaindeksowana. Google zna adres, ale jeszcze go nie pobrał. Sprawdź dostępność serwera, skalę kolejki i sposób odkrywania stron; pobranie mogło zostać odłożone.

• Strona zeskanowana, ale jeszcze niezindeksowana. Strona została pobrana i obecnie nie jest indeksowana. Może trafić do indeksu później. Porównaj treść po renderowaniu, duplikację, linkowanie i wartość strony, bo sam status nie wskazuje jednej przyczyny.

• Duplikat, Google wybrał inny kanoniczny niż użytkownik. Porównaj wskazany i wybrany URL, ich treść oraz sygnały z linków, przekierowań i sitemapy.

• Zaindeksowana, choć zablokowana przez robots.txt. Dokładnie sytuacja opisana wyżej.

• Alternatywna strona zawierająca prawidłowy tag kanoniczny. To stan poprawny, nie błąd.

Znaczenie tych statusów opisuje pomoc Search Console. W raporcie audytowym obok statusu powinna znaleźć się diagnoza oparta na sprawdzonym przykładzie. Jak czytać te raporty w projekcie na Next.js i co robić z konkretnymi błędami, rozpisuję w tekście o Search Console dla Next.js.

W przeglądzie Search Console sprawdź także Ręczne działania i Problemy dotyczące bezpieczeństwa. Pierwszy raport pokazuje naruszenia zasad spamu stwierdzone przez weryfikatora Google, a drugi m.in. treści dodane po włamaniu, malware i socjotechnikę. Lista przykładowych adresów w raporcie bezpieczeństwa może nie obejmować wszystkich dotkniętych stron, dlatego naprawę weryfikuj w całym szablonie lub serwisie. Dodam jeszcze, że tego typu kary zdarzają się jednak bardzo rzadko i dotyczą rzeczywiście poważnych naruszeń zasad Google.

Bing Webmaster Tools i protokół IndexNow

Bardziej jako ciekawostkę dodam jeszcze parę słów o Bing Webmaster Tools, który może się przydać jako porównanie, jeśli audyt nie jest świadomie ograniczony do Google. Zobaczysz tam URL Inspection, która pokazuje stan indeksowania, odpowiedź HTTP, kod HTML widziany przez Bingbota, błędy SEO oraz rozpoznane dane strukturalne. Z kolei Site Explorer ułatwia szybki przegląd adresów z błędami, przekierowaniami, blokadą w robots.txt czy tagiem noindex.

W serwisach, które często publikują, aktualizują lub usuwają treści, warto wdrożyć IndexNow. Protokół ten natychmiast powiadamia Bing oraz pozostałe wspierające go wyszukiwarki o zmianach na stronie, dzięki czemu nie musisz czekać na ich standardowe wykrycie przez robota.

Index bloat: dlaczego „wszystko w indeksie” to zła rada

Celem jest indeksowanie wartościowych stron kanonicznych, a nie ich maksymalnej liczby. Odwrotny stan, czyli index bloat, to indeks wypełniony adresami o niskiej wartości. Strony takie jak koszyk, wewnętrzne wyniki wyszukiwania czy warianty sortowania z reguły nie wymagają obecności w indeksie. Z drugiej strony, archiwum tagu lub precyzyjna kombinacja filtrów mogą doskonale odpowiadać na konkretne zapytanie i dostarczać użytkownikowi wartościową listę treści. Ostatecznie, zanim zdecydujesz o wykluczeniu całego typu URL-i, przeanalizuj realną funkcję, jaką pełnią w serwisie. W innym wypadku możesz niepotrzebnie zaszkodzić projektowi.

Przygotuj inwentaryzację szablonów i parametrów, a przy każdym z nich zdefiniuj docelowe zachowanie. W przypadku powielonych treści rozważ ich konsolidację, dla stron celowo wykluczanych z wyszukiwarki zastosuj noindex, a przy zbędnych kombinacjach parametrów ogranicz ich generowanie i odkrywanie przez roboty. Pamiętaj, że strony z prywatnymi danymi bezwzględnie wymagają kontroli dostępu.

Crawl budget: kiedy naprawdę Cię dotyczy

Od razu muszę napisać, że w niewielkim, stabilnym serwisie nie ma sensu o tym myśleć. Analiza budżetu crawlowania nabiera znaczenia przy dużej liczbie URL-i, częstych zmianach i rosnącej kolejce stron do pobrania. Masz mały projekt? Zacznij od dostępności, linków i treści.

Porównaj tempo publikacji nowych treści z rzeczywistą częstotliwością wizyt robota w logach serwera i szukaj w nich przede wszystkim nadmiernej liczby żądań kierowanych do adresów z parametrami oraz objawów przeciążenia infrastruktury. Pamiętaj też, że wdrożenie tagu noindex nie ogranicza budżetu indeksowania — robot i tak musi pobrać stronę, aby odczytać zawartą w niej dyrektywę.

Mapa witryny XML: zgodność z zakresem indeksacji

Pobierz mapę witryny i porównaj ją z crawlem oraz listą stron z CMS-a. W mapie witryny umieszczaj tylko bezwzględne, kanoniczne URL-e, które faktycznie mają trafiać do wyszukiwarki. W raporcie wypisz za to wszystkie przekierowania, błędy HTTP, adresy z tagiem noindex oraz te brakujące podstrony, które docelowo chcesz pokazywać w Google. Poza tym, sprawdź techniczną poprawność XML, dostępność map wskazanych w indeksie sitemap i daty lastmod, która powinna odpowiadać ostatniej znaczącej zmianie strony, np. treści, a nie każdemu buildowi lub zmianie stopki. Dodam jeszcze, że Google ignoruje priority i changefreq.

Pojedyncza mapa mieści do 50 000 URL-i i 50 MB po rozpakowaniu. Większy zbiór podziel na pliki. Po zgłoszeniu w GSC sprawdź odczyt i błędy przetwarzania. Zgłoszenie sitemapy pomaga odkrywać adresy, lecz nie gwarantuje indeksacji. Generowanie mapy z poziomu frameworka pokazuję osobno dla App Routera w Next.js i dla dużych serwisów w Astro zasilanych z API.

Analiza logów serwera i weryfikacja robotów

Logi pokazują żądania z wybranego okresu: odwiedzane URL-e, kody odpowiedzi i częstotliwość powrotów. Jeśli CDN obsługuje żądanie z cache, może ono nie dotrzeć do serwera źródłowego. Zbieraj dane w miejscu, które widzi ruch robota, i zapisz zakres czasowy oraz ewentualne próbkowanie. Praktyczny setup na Cloudflare, razem z szukaniem wąskich gardeł indeksacji, rozpisuję w tekście o śledzeniu Googlebota w logach Cloudflare.

Zweryfikuj tożsamość robota przed wyciąganiem wniosków. User-Agent można podrobić. Google opisuje weryfikację przez oficjalne zakresy IP albo odwrotny DNS z ponownym sprawdzeniem adresu. Test z podmienionym user-agentem pokazuje reakcję na nagłówek, ale nie odtwarza zaufania przypisywanego przez WAF prawdziwemu robotowi.

Zrozumienie treści (warstwa 4): o czym jest Twoja strona

Wersja docelowa domeny: www, HTTPS i ukośnik

Ta sama strona może odpowiadać pod różnymi adresami (z www i bez, HTTP/HTTPS, z ukośnikiem lub bez) i dlatego trzeba wyznaczyć docelowy wariant URL-a i zweryfikować, czy pozostałe wersje spójnie na niego przekierowują. Pamiętaj też o wielkości liter i przed automatyczną ich normalizacją trzeba sprawdzić, czy architektura aplikacji nie rozróżnia adresów po wielkich znakach.

Środowiska stagingowe wymagają osobnej weryfikacji. W sytuacji, kiedy testowa wersja ma być prywatna, konieczne jest uwierzytelnienie, ponieważ reguły w robots.txt i meta tag noindex nie stanowią żadnej bariery ochronnej dla danych.

Tagi kanoniczne (rel=canonical) i typowe sprzeczności

rel=canonical jest sygnałem wyboru preferowanego URL-a spośród tej samej lub bardzo podobnej treści. Google może wybrać jako kanoniczny zupełnie inny adres, niż mu wskazujesz. Szukaj sprzeczności: linku kanonicznego po prostu usilnie kierującego na stronę główną, celu z tagiem noindex lub błędem HTTP, kilku wykluczających się deklaracji naraz czy rozjazdu między sitemapą a linkowaniem wewnętrznym.

Google radzi sobie z adresami względnymi, ale zdecydowanie woli bezwzględne. Ogarnie też kanonik wrzucony przez JS, o ile strona renderuje się bez problemu, a deklaracje są spójne. Najlepiej jednak po prostu wstawić gotowy tag prosto w kod HTML. W sytuacji, kiedy nie masz takiej możliwości, dodaj go przez JS, pilnując, by w źródle strony nie było innej, wykluczającej się wartości. Na samej stronie kanonicznej zawsze stosuj link kanoniczny do niej samej.

Duplikacja wewnętrzna treści i sposoby jej rozwiązania

Sprawdź parametry sortowania i śledzenia, wersje do druku, warianty produktów oraz strony o powielonej zawartości. Sam mechanizm powstawania duplikatów z parametrów, razem z nawigacją fasetową, omawiam w tekście o parametrach w URL i duplikacji treści. Podobny tytuł czy powtarzalny fragment tekstu nie przesądzają jeszcze o duplikacji. O kwalifikacji adresu decyduje jego główna treść oraz to, czy realizuje on odrębną potrzebę informacyjną.

Dobierz działanie do celu:

• Trwałe przeniesienie lub połączenie stron: przekierowanie na odpowiadającą im stronę docelową.
• Warianty tej samej treści, które muszą pozostać dostępne: spójny link kanoniczny wskazujący preferowany URL.
• Strona, którą świadomie wykluczasz z wyników: noindex dostępne do odczytu dla robota.
• Zbędne kombinacje parametrów: ograniczenie ich generowania i odkrywania; politykę crawlowania ustal osobno od usuwania z indeksu.

noindex wyklucza stronę z wyszukiwania i nie zastępuje konsolidacji sygnałów przez link kanoniczny. Tłumaczenie głównej treści na inny język również nie staje się automatycznie duplikatem z powodu braku hreflang.

Wersje językowe i atrybut hreflang

hreflang pomaga wskazać odpowiadające sobie wersje językowe i regionalne. Jego brak nie uniemożliwia indeksacji wielojęzycznej witryny. Jeśli go wdrażasz, sprawdź spójność całego zestawu:

• pl oznacza język polski niezależnie od regionu, a pl-PL język polski dla odbiorców w Polsce. Obie wartości są poprawne; region jest opcjonalny i nie zastępuje języka.
• Każda strona zestawu powinna wskazywać siebie i pozostałe wersje. Sprawdź odwołania zwrotne.
• Kieruj do odpowiednich, dostępnych URL-i i sprawdź zgodność z ich linkami kanonicznymi. Adres wykluczony przez noindex nie zrealizuje zamierzonej roli w wynikach.
• x-default służy jako wariant zapasowy, np. selektor języka. Jego brak nie jest sam w sobie błędem.

Zasady i przykłady znajdziesz w dokumentacji hreflang. Wdrożenie razem z linkami kanonicznymi, bez duplikacji między wersjami, rozkładam na czynniki w tekście o hreflang i link kanoniczny w Next.js, a pełny setup routingu i tłumaczeń w przewodniku po i18n w App Routerze.

Struktura adresów URL i stabilność linków

Tworząc nowe adresy, stawiaj na czytelne nazwy, spójną wielkość liter i parametry, które naprawdę mają sens. Potraktuj to po prostu jako dobrą praktykę i sposób na porządek w projekcie. Warto też zaznaczyć, że sama końcówka pliku czy to, z ilu części składa się link, wcale nie oznacza od razu błędu pod kątem SEO.

Zachowuj stabilne URL-e, dopóki ich zmiana nie rozwiązuje konkretnego problemu. Migracja wymaga mapowania, przekierowań i aktualizacji linków; może też powodować przejściowe wahania widoczności. Gdy zmiana adresów jest jednak konieczna, kolejność prac i sposób zabezpieczenia pozycji opisuję w przewodniku po przekierowaniach 301 przy migracji oraz w planie bezpiecznego uruchomienia strony. Google podaje, że przekierowania serwerowe nie powodują utraty PageRank. Ryzyko wiąże się z przebiegiem migracji, a nie z nieuniknionym „ubytkiem mocy” przy każdym przekierowaniu.

Nagłówki H1–H6 i hierarchia treści

Stosowanie jednego głównego nagłówka h1 dla określenia tematu oraz zachowanie logicznej hierarchii kolejnych nagłówków to absolutny standard i to od wielu lat. Zarówno pod kątem redakcyjnym, jak i dostępnościowym. Taka struktura ułatwia czytelnikowi sprawne skanowanie tekstu, a użytkownikom czytników ekranu pozwala na wygodną nawigację po treści.

Warto jednak pamiętać, że Google nie narzuca sztywnej liczby nagłówków ani nie traktuje każdego przeskoku w ich hierarchii jako błędu rankingowego. Ostrzeżenie w raporcie o obecności kilku h1 powinno być więc sygnałem do weryfikacji szablonu, ale bez paniki, bo nie oznacza to, że strona straciła pozycje.

Meta tagi: title, description i meta robots

Title powinien zwięźle i trafnie opisywać konkretną stronę. Około 55 do 60 znaków można przyjąć jako pomoc redakcyjną, ale nie jest to limit indeksowania ani gwarancja wyświetlenia całości. Google tworzy tytuł w wynikach wyszukiwania na podstawie kilku źródeł, więc jego modyfikacja przez robota nie oznacza automatycznie błędu po Twojej stronie. Zanim zaczniesz poprawiać kod, porównaj wygenerowany nagłówek z rzeczywistą treścią oraz strukturą h1 na stronie.

Meta description to proponowany opis strony, który Google może wykorzystać we fragmencie wyniku. Napisz go tak, żeby pomagał ocenić przydatność strony i podjąć decyzję o kliknięciu przez użytkownika. Google może też wybrać fragment treści lepiej odpowiadający zapytaniu, pobierając treść dostępną w samym artykule.

Wyższy CTR oznacza więcej kliknięć przy tej samej liczbie wyświetleń. Zmiana CTR z GSC nie pozwala jednak przewidzieć zmiany pozycji: zależy on również od zapytań, układu wyników i samej pozycji. Google deklaruje używanie zagregowanych, anonimowych danych o interakcjach do oceny trafności, więc nie piszę nic konkretnego tak naprawdę.

Meta robots obejmuje m.in. noindex, nofollow, nosnippet, max-snippet i max-image-preview. X-Robots-Tag pozwala przekazać reguły także dla plików innych niż HTML, na przykład PDF-ów. Warto kontrolować zarówno nagłówki HTTP, jak i meta tagi w kodzie, ponieważ sprzeczne wytyczne mogą ograniczać indeksowanie lub sposób prezentacji treści. Z kolei dyrektywa noarchive stała się bezużyteczna — po usunięciu z Google Search funkcji kopii zapasowej jest ona przez wyszukiwarkę ignorowana.

Linkowanie wewnętrzne i architektura informacji

• Głębokość kliknięć: zadbaj o łatwy dostęp do ważnych stron z nawigacji i powiązanych treści. Trzy kliknięcia mogą być celem projektowym, ale nie muszą oznaczać poprawnego SEO.

• Strony osierocone: nie prowadzą do nich linki wewnętrzne, choć mogą być znane z sitemapy, CMS-a lub analityki. Musisz porównać te zbiory z crawlem i sprawdzić, gdzie brakuje naturalnego odnośnika.

• Anchor texty: opisuj temat lub cel strony docelowej. Odbiorca powinien rozumieć, co znajdzie po przejściu.

• Breadcrumbs: sprawdź widoczną ścieżkę nawigacji i spójność BreadcrumbList. Poprawne dane mogą kwalifikować stronę do odpowiedniej prezentacji wyniku, bez gwarancji wyświetlenia.

• Paginacja: kolejne części listy powinny mieć własne URL-e połączone odnośnikami. Gdy zawierają inne elementy, nie wskazuj mechanicznie pierwszej strony jako kanonicznej. Google nie używa rel=next/prev do indeksowania.

• Nawigacja fasetowa: wyodrębnij kombinacje filtrów odpowiadające na realne potrzeby wyszukiwania. Dla pozostałych ustal zasady generowania, linkowania i dostępu robotów – jak trzeba, należy użyć punktowo noindex.

• Nakładanie się intencji stron: zbadaj intencję zapytań, dedykowane URL-e oraz ich funkcje w serwisie. Widoczność kilku podstron na tę samą frazę nie oznacza jeszcze szkodliwej kanibalizacji. W zależności od danych rozwiązaniem może być precyzyjne rozdzielenie intencji, zmiana architektury linkowania lub pełna konsolidacja treści.

Dane strukturalne Schema.org w 2026 roku

Audyt danych strukturalnych powinien rozróżniać poprawność schematu i aktualne funkcje Google, do których dany typ kwalifikuje stronę. FAQ rich results przestały pojawiać się w Google 7 maja 2026, a w czerwcu usunięto dokumentację tej funkcji. Zapisany w Schema.org typ FAQPage nadal istnieje. Możesz utrzymywać użyteczne FAQ i odpowiadający mu schemat, ale nie oczekuj dodatkowej ekspozycji FAQ w Google. Jeżeli raportowanie opiera się na dawnym typie wyniku, sprawdź aktualne wsparcie w narzędziu i zachowanie używanego zapytania API.

Dla produktów, przepisów, wydarzeń, artykułów czy danych organizacji dobieraj typ i właściwości do faktycznej treści oraz dokumentacji danej funkcji. Organization może pomóc opisać firmę, a sameAs powiązać ją z jej oficjalnymi profilami; nie należy obiecywać z tego tytułu cytowań przez asystentów. Gotowe wzorce dla typów najczęściej spotykanych na stronach usługowych zebrałem w tekście o Schema.org w Next.js. Stosuj JSON-LD zgodny z treścią udostępnianą użytkownikowi. Rich Results Test sprawdza wymagania obsługiwanych funkcji Google, a Schema Markup Validator poprawność schematu. Poprawne oznaczenie daje kwalifikację, nie gwarancję wyświetlenia. Ręczne działanie dotyczące danych strukturalnych może odebrać kwalifikację do rich results; samo w sobie nie zmienia rankingu w zwykłych wynikach.

Doświadczenie użytkownika (warstwa 5): Core Web Vitals i mobile

Core Web Vitals: LCP, INP i CLS

Aktualny zestaw Core Web Vitals obejmuje trzy metryki:

Oceniaj 75. percentyl danych polowych osobno dla mobile i desktopu. Przy wystarczającej próbie dla całego zestawu dobry wynik wymaga spełnienia progów trzech metryk. Wynik Lighthouse opisuje konkretny pomiar laboratoryjny, więc 100 punktów nie dowodzi zaliczenia CWV u użytkowników.

INP uwzględnia opóźnienie od interakcji do następnego odmalowania, w tym pracę obsługi zdarzeń. Dotyczy kliknięć, dotknięć i klawiatury, a nie np. samego przewijania. Wskaźnik ten reprezentuje z reguły najwolniejszą interakcję na stronie, przy czym przy większej ich liczbie pojedyncze, skrajne wyniki są pomijane. Z tego względu sam pomiar początkowego ładowania nie wystarczy do oceny responsywności serwisu podczas całej wizyty użytkownika.

W PageSpeed Insights sprawdź, czy CrUX pokazuje dane konkretnego URL-a, czy całego originu, czyli adresu obejmującego protokół, host i port. Przy małej próbie dane strony mogą być niedostępne. PSI dopuszcza też ocenę na podstawie LCP i CLS, gdy brakuje wystarczających danych INP; zanotuj ten brak zamiast zakładać, że zmierzono responsywność. Dane polowe w PSI obejmują ruchome okno 28 dni.

Progi łatwiej utrzymać, gdy regresję zatrzymuje pipeline, a nie kolejny audyt; budżety wydajności w CI opisuję w tekście o blokowaniu kodu psującego LCP i INP, a pełną ścieżkę optymalizacji na realnym wdrożeniu w case study PageSpeed 100/100. Rozbieżności między polem a laboratorium mogą wynikać z urządzeń, sieci, cache, sposobu interakcji, próby użytkowników lub terminu wdrożenia. Nie przypisuj przyczyny samym wynikom: odtwórz wolny scenariusz i sprawdź przebieg ładowania lub interakcji.

Google oficjalnie przyznaje, że używa wskaźników Core Web Vitals w swoich algorytmach, ale nigdzie nie podaje ich dokładnego wpływu na ranking. Generalnie, dobrze jest mieć je na „zielono”, ale też staraj się nie gonić cyferek dla samych cyferek. Kieruj się realną wygodą użytkownika i wprowadzaj takie poprawki, by jego doświadczenie na stronie było możliwie jak najlepsze, np. żeby nie musiał czekać w nieskończoność na załadowanie formularza albo uciekający spod palca przycisk.

Sprawdź obrazy na pierwszym ekranie, czas odpowiedzi serwera, skrypty zewnętrzne, obciążenie głównego wątku, miejsce na reklamy i zachowanie fontów. Konkretne techniki poprawy zebrałem w przewodniku po przyspieszaniu strony pod Core Web Vitals, a wzorce psujące responsywność w Reakcie w tekście o pięciu antywzorcach INP. To obszary diagnozy; ich kolejność powinna wynikać z pomiaru danej strony.

Optymalizacja grafik i formaty obrazów

• Format. Porównaj WebP lub AVIF z obecnymi plikami przy akceptowanej jakości obrazu.

• Rozmiar. Obraz nie powinien być większy niż kontener, w którym się wyświetla, plus zapas na ekrany o wysokiej gęstości.

• Warianty dla urządzeń. Atrybuty srcset i sizes pozwalają podać inny plik dla telefonu, a inny dla desktopu.

• Rezerwacja miejsca. Jawne width i height lub właściwe aspect-ratio ograniczają przesunięcia układu.

• Priorytet ładowania. Stosuj loading="lazy" dla obrazów poza pierwszym ekranem. Obraz LCP ładuj bez opóźniania; rozważ fetchpriority="high" i sprawdź efekt w pomiarze.

• Nazwy plików i alt. Pisz je opisowo, z myślą o dostępności i wyszukiwarce grafik, bez upychania fraz.

• Sitemapa obrazów. Rozszerz ją o grafiki, jeśli ich odkrywanie wymaga wsparcia, a wyszukiwanie grafik jest ważnym kanałem.

Widoczność obrazów i ich dostępność dla robota sprawdzisz według zaleceń Google Image SEO. Wybór między next/image, ręcznym srcset a CDN-em obrazów rozstrzygam w porównaniu metod optymalizacji grafik.

Wersja mobilna i mobile-first indexing

Google stosuje podejście Mobile-First Indexing, co oznacza, że do indeksowania, oceny jakości i rankingu witryny wykorzystuje wyłącznie treść pobraną przez agenta smartfonowego (Googlebot Smartphone). Z tego powodu wersja mobilna nie może być okrojoną odmianą serwisu, dlatego dobrze przeanalizuj i porównaj oba warianty, upewniając się, że wersja mobilna zapewnia pełną równoważność technologiczną i merytoryczną:

• Treść dostępna dla bota. Tekst umieszczony w akordeonach czy zakładkach jest bez problemu indeksowany, o ile znajduje się bezpośrednio w kodzie HTML (nadmienię tylko, że styl CSS typu display: none nie blokuje robotowi dostępu do treści). Problem pojawia się wtedy, gdy zawartość nie renderuje się w wersji mobilnej lub jest dociągana dynamicznie dopiero po akcji użytkownika (np. po kliknięciu).
• Porównaj metadane, dyrektywy dla robotów, dane strukturalne oraz strukturę linkowania wewnętrznego. Choć układ graficzny na smartfonie może być inny, użytkownik mobilny oraz robot nie mogą stracić dostępu do żadnych kluczowych informacji.
• Użyteczność mobilna. Zweryfikuj rozmiar i odstępy obszarów klikalnych, czytelność fontów bez konieczności przybliżania oraz brak poziomego paska przewijania. Upewnij się też, że banery ze zgodami prywatności (CMP) nie zasłaniają całkowicie głównej treści.

Dialogi, interstitiale i zgody na cookies

Sprawdź stronę po wejściu z wyników wyszukiwania na telefonie. Pełnoekranowy pop-up, ekran instalacji aplikacji lub przekierowanie na osobną stronę zgody mogą zasłonić główną treść i utrudnić jej zrozumienie użytkownikowi oraz wyszukiwarce. Zamiast nich stosuj niewielkie banery i dialogi, które nie blokują całej strony. Pamiętaj, że komunikaty wymagane prawem, np. dotyczące wieku lub zgody na pliki cookie, są konieczne, dlatego, jeśli to możliwe, wyświetl je jako warstwę nad właściwą stroną. Zachowaj przy tym jej treść w odpowiedzi, zamiast kierować wszystkie URL-e do jednego ekranu zgody.

Bezpieczeństwo, HTTPS i infrastruktura

1. Szyfrowanie i spójność: HTTPS wdrożony na całej witrynie, ważny certyfikat SSL oraz brak problemu z mixed content.
2. Polityki bezpieczeństwa: Nagłówki HSTS i CSP precyzyjnie dopasowane do aplikacji. Warto upewnić się, że ochrona nie blokuje kluczowych zasobów ani prawidłowego działania strony.
3. Wydajność serwera: Obsługa protokołu HTTP/2 lub HTTP/3, aktywna kompresja oraz optymalnie skonfigurowane nagłówki pamięci podręcznej (cache).
4. Ochrona CMS: Regularne aktualizacje systemu oraz wtyczek, a także stała kontrola pod kątem niepożądanych przekierowań czy wstrzykniętego kodu po ewentualnym przejęciu witryny.

Elementy te stanowią fundament jakości i bezpieczeństwa serwisu, ale nie należy z drugiej strony oczekiwać, że każdy nagłówek zabezpieczeń czy nowsza wersja protokołu przełożą się na bezpośredni wzrost pozycji w wynikach wyszukiwania.

Widoczność w AI (warstwa 6): crawlery, CDN i cytowania

W audycie wyraźnie rozdziel to, kto pobiera treść, od tego, do czego ma ona posłużyć. Osobno przeanalizuj funkcje AI w samej wyszukiwarce Google, a osobno usługi zewnętrznych dostawców – ich boty, mechanizmy dostępu i sposoby raportowania mocno się od siebie różnią.

Crawlery AI: kto odwiedza Twoją stronę

Rozdziel trzy zastosowania:

OpenAI umożliwia zablokowanie bota treningowego GPTBot przy jednoczesnym pozostawieniu dostępu dla OAI-SearchBot. Warto pamiętać, że wykluczenie OAI-SearchBot skutkuje brakiem witryny w bezpośrednich odpowiedziach wyszukiwania ChatGPT, choć odnośniki nawigacyjne nadal mogą się pojawiać. Z kolei ChatGPT-User pełni zupełnie inną rolę — reguły zawarte w robots.txt nie zawsze mają zastosowanie do akcji inicjowanych bezpośrednio przez użytkownika.

Różnice w podejściu widać też u konkurencji, ponieważ Anthropic (twórca Claude) deklaruje pełne respektowanie robots.txt przez swoje roboty, w tym Claude-User. Z kolei Perplexity definiuje Perplexity-User jako narzędzie do pobierania danych na żądanie użytkownika (fetcher), które z zasady ignoruje te wytyczne. W związku z powyższym nie należy bezrefleksyjnie przekładać polityki jednego dostawcy na pozostałe systemy.

Osobną pozycją jest Google-Extended, token w robots.txt bez własnego user-agenta HTTP. Steruje wykorzystaniem treści do treningu i części zastosowań grounding, czyli dostarczania modelowi informacji przy tworzeniu odpowiedzi, w Gemini. Od razu wyjaśnię, że dyrektywa ta nie wpływa na obecność witryny w tradycyjnych wynikach Google Search. Dostęp do funkcji opartych na sztucznej inteligencji w samej wyszukiwarce zależy od zwykłego Googlebota oraz od konfiguracji generatywnej AI w panelu Google Search Console.

Kontrola udziału w generatywnym Google Search

Od 31 sierpnia 2026 w Search Console globalnie dostępna jest opcja Ustawienia → Ustawienia generatywnej AI w wyszukiwarce. Domyślnie zezwala ona na użycie linków i treści witryny w AI Overviews, AI Mode oraz generatywnych funkcjach Discover. Sprawdź jej wartość dla właściwości i to, czy nie dziedziczy ona konfiguracji po właściwości nadrzędnej.

Wykluczenie blokuje prezentowanie linków i użycie treści do groundingu w tych funkcjach, dlatego może wyjaśniać brak wyświetleń mimo prawidłowego crawlowania i indeksowania. Nie wyłącza pozostałych części Google Search i nie steruje treningiem modeli. Politykę treningu dla Gemini ustawiasz osobno przez Google-Extended.

Ustawienia CDN a blokowanie robotów AI

W panelu Cloudflare zweryfikuj sekcje Search, Agent i Training, reguły zapory WAF oraz dziennik zdarzeń blokowania. Sama deklaracja w pliku robots.txt nie gwarantuje sukcesu — jeśli zapora na poziomie CDN-a odrzuci ruch bota, żądanie w ogóle nie dotrze do serwera i plik wytycznych nie zostanie nawet pobrany.

Według dokumentacji dostępnej 5 września 2026 nowe ustawienia domyślne dla nowych domen mają wejść 15 września 2026: blokowanie Training i Agent na stronach z reklamami przy pozostawieniu Search. Ta zmiana jest jeszcze zapowiedzią. Reguły dotyczą również wskazanych przez Cloudflare robotów o mieszanym zastosowaniu; bieżącą konfigurację odczytaj bezpośrednio ze swojej strefy.

Content Signals pozwalają deklarować sposoby wykorzystania treści, m.in. search, ai-input i ai-train. Zapis preferencji i techniczne przepuszczenie żądania to dwa osobne elementy kontroli. Porównaj deklarację z logami zweryfikowanych robotów i zdarzeniami zabezpieczeń.

Plik llms.txt: jaki ma status i czym jest?

Najkrócej rzecz ujmując, llms.txt to konwencja udostępniania skrótu i odnośników do treści dla narzędzi korzystających z modeli językowych. Google Search informuje, że nie używa go jako specjalnego mechanizmu wyszukiwania: jego utrzymywanie nie pomaga ani nie szkodzi widoczności w Google. Plik może służyć innym systemom, jeśli go wykorzystują.

Lighthouse ma audyt llms.txt w kategorii przeglądania agentowego i zwraca uwagę na błąd serwera podczas pobierania pliku; brak pliku z odpowiedzią 404 daje N/A, ponieważ jest on opcjonalny. Trzeba tutaj zaznaczyć, że nie jest to test pozycji ani cytowalności strony.

Samo wdrożenie i formatowanie pliku, razem z przykładami dla Next.js i Astro, opisuję w tekście o llms.txt w praktyce. W mojej kolejności prac llms.txt ma sens po wskazaniu konkretnego odbiorcy lub integracji, dla których będziesz go utrzymywać. W pierwszej kolejności sprawdź dostępność treści, jakość odpowiedzi i działanie linków, bez obiecywania określonej liczby cytowań.

Nowe metryki widoczności w odpowiedziach AI

Google udokumentowało raport Generative AI performance report, który prezentuje dane o widoczności witryny w funkcjach AI Overviews oraz AI Mode. Globalne udostępnienie narzędzia nastąpiło 31 sierpnia 2026 roku. Warto jednak pamiętać, że przy zbyt małej liczbie wyświetleń raport może nie być jeszcze dostępny dla danej witryny. Co istotne, zebrane w nim dane dotyczą samych wyświetleń linków w odpowiedziach AI, dlatego nie należy utożsamiać ich bezpośrednio z ruchem i przejściami do serwisu.

W raporcie audytowym rozdziel:

• Wyświetlenia w funkcjach AI Google: źródło GSC, ze wskazaniem okresu, stron i dostępnych wymiarów.
• Rozpoznane odesłania od asystentów: dane analityczne o wejściach z przypisanym źródłem; nie obejmują odpowiedzi, po których nikt nie odwiedził witryny.
• Próbę cytowań: zestaw ustalonych pytań, nazwa usługi, data i zapis uzyskanych odpowiedzi. Traktuj ją jako obserwację wybranych scenariuszy.

Techniczną stronę przygotowania serwisu pod asystentów, od struktury treści po dostęp do danych, rozpisuję w tekście o GEO i AEO w Next.js.

Każda metryka powinna mieć opis źródła i zakresu, ponieważ bez tego porównanie wyświetleń, sesji i cytowań daje pozorną precyzję, mimo że są to różne zdarzenia. Sama optymalizacja treści pod odpowiedzi generatywne to osobny temat, który rozwijam w tekstach o generative engine optimization, budowaniu grafu encji przez schema.org i przygotowaniu strony na agentów AI.

Od raportu audytowego do wdrożenia poprawek

Nawet najlepsza diagnoza nic nie da, jeśli nie ma kogoś, kto to po prostu wdroży i sprawdzi, czy to w ogóle zadziałało. Kiedy czytasz audyt, szukaj konkretu, czyli mocnego dowodu, jasnego zalecenia i zwięzłego zadania (które adresuje problem) do zrobienia dla zespołu.

Priorytetyzacja poprawek według wpływu

Proponuję oceniać wpływ i koszt wdrożenia, uzupełnione o zasięg problemu, pilność i pewność diagnozy. Jedna błędna reguła może dotyczyć całego serwisu, a pozornie prosta zmiana linków kanonicznych może wymagać sprawdzenia wielu szablonów.

1. Duży wpływ, niski koszt: naprawić w pierwszej kolejności. Przykładem jest potwierdzona, niezamierzona blokada indeksowania ważnej sekcji.
2. Duży wpływ, wysoki koszt: zaplanować zakres i zależności, np. przebudowę sposobu renderowania lub nawigacji fasetowej.
3. Mały wpływ, niski koszt: robić przy okazji.
4. Mały wpływ, wysoki koszt: świadomie odpuścić i zapisać, że to była decyzja.

Gdy poprawka wymaga budżetu, sam wskaźnik rzadko wystarcza jako uzasadnienie. Jak przeliczyć opóźnienie ładowania na pieniądze i rozmawiać o priorytetach językiem biznesu, pokazuję w tekście o koszcie sekundy opóźnienia strony.

Format raportu, który da się wdrożyć

Każde zadanie powinno zawierać przykładowy adres, obserwowane zachowanie, oczekiwany wynik oraz sposób weryfikacji. Osoba odpowiedzialna za wdrożenie musi precyzyjnie wiedzieć, po czym rozpoznać prawidłowo wykonaną poprawkę.

Równie ważne jest jednoznaczne przypisanie odpowiedzialności, ponieważ część zadań trafia do dewelopera, część do zespołu redakcyjnego (tytuły, treści, struktura nagłówków), a inne do administratora serwera. Profesjonalny audyt SEO musi o tym mówić.

Poniżej znajduje się fikcyjny przykład zadania dotyczącego poradnika, który zgodnie z założeniem właściciela serwisu powinien być indeksowany:

Rozdziel odbiór poprawki od późniejszego zachowania wyszukiwarki. Zespół może potwierdzić usunięcie noindex, zanim Google ponownie odwiedzi stronę.

Diagram

Mierzenie efektu wdrożonych poprawek

• Powtórz crawl w porównywalnej konfiguracji i sprawdź kryteria odbioru dla naprawianych szablonów.
• W Search Console obserwuj objęte zmianą URL-e i powody braku indeksacji. Uwzględnij czas ponownego pobrania i przetworzenia.
• Porównaj błędy HTTP i czas odpowiedzi w statystykach crawlowania oraz logach.
• W PSI sprawdzaj dane polowe z tego samego poziomu agregacji. Okno 28 dni początkowo obejmuje wizyty sprzed poprawki i po niej.
• Zmiany widoczności i ruchu analizuj z uwzględnieniem sezonowości, zapytań i pozostałych wdrożeń. Sama zbieżność dat nie dowodzi przyczyny.

Ręczne zaglądanie do raportów wyłapuje problem dopiero wtedy, gdy ktoś akurat patrzy. Automatyczne wykrywanie odchyleń na danych Search Console rozpisuję w tekście o wykrywaniu anomalii SEO w BigQuery.

Zaplanuj też zabezpieczenie przed regresją: crawl w harmonogramie, alerty na 5xx i niezamierzone noindex oraz kontrole wydajności w procesie wdrożeniowym. Gotowy zestaw testów pilnujących noindex, linków kanonicznych i przekierowań przy każdym wdrożeniu pokazuję w tekście o automatycznych testach regresji SEO w GitHub Actions, a koszt wykrycia błędu indeksacji dopiero na produkcji liczę w analizie bug debt w SEO. Częstotliwość dobierz do tempa zmian w aplikacji. Sposób przekładania takich zaleceń na kod rozwijam w tekście o wdrażaniu poprawek z audytu SEO.

Narzędzia do audytu technicznego SEO

Poniższe zestawienie pokazuje, po co sięgać na danym etapie audytu. Samą pracę z tymi panelami, wraz z konfiguracją i pułapkami w porównywaniu ich danych, opisuję w przewodniku Jak pracować z narzędziami SEO?.

Taki zestaw testów doskonale uzupełnia wewnętrzne procedury QA uruchamiane przed każdym wdrożeniem. Elementy takie jak linki kanoniczne, tagi hreflang, metadane czy przekierowania można łatwo zweryfikować automatycznie — zamiast marnować czas i wracać do nich dopiero przy kolejnym audycie. Jak zbudować taki zestaw testów, opisuję w tekście o QA w technicznym SEO.

Narzędzia automatyczne znacząco przyspieszają zbieranie danych i wstępną ocenę nieprawidłowości, ale sam raport wymaga jednak głębszej analizy. Musisz wyjaśnić, czy dany alert wynika z celowego działania systemu, jakiego zakresu stron dotyczy i dlaczego proponowana zmiana rzeczywiście rozwiąże problem. Zawsze weryfikuj przy tym konfigurację crawlera, dokładną datę pomiaru oraz dostępność danych źródłowych. Jeśli interesuje Cię temat, jak łączyć dane z tych źródeł w jedną diagnozę i nie mylić przy tym korelacji z przyczyną, rozkładam na czynniki w przewodniku o tym, jak pracować z narzędziami SEO.

Mity w audycie SEO, które warto wyrzucić z listy kontrolnej

Audyt techniczny i optymalizacja pod kątem SEO i GEO.

Audyt techniczny SEO