Audyt SEO: jak robię audyt strony krok po kroku

Audyt SEO to decyzja, co na stronie poprawić najpierw, z dowodem przy każdym zaleceniu i ze sposobem sprawdzenia po wdrożeniu. Lista błędów z narzędzia jest dopiero materiałem do audytu. Audyt techniczny to ta jego część, która sprawdza, czy roboty wyszukiwarek i asystentów AI mogą stronę pobrać i odczytać, a wyszukiwarka zaindeksować.

Audyt robię w ośmiu krokach:

1. Ustalam cel i sytuację strony, zanim uruchomię crawler, czyli program, który przechodzi stronę tak jak robot wyszukiwarki.
2. Sprawdzam, czy roboty w ogóle dostają stronę.
3. Zbieram dane z kilku źródeł i sprawdzam, czego każde z nich nie widzi.
4. Badam frazy i wyniki Google, zanim zajmę się techniką.
5. Przeglądam stronę według katalogu problemów z warunkami priorytetu.
6. Przy każdym zagadnieniu pokazuję dowód.
7. Ustalam kolejność, nakład pracy i warianty.
8. Oddaję wynik do kontroli krzyżowej, a po wdrożeniu sprawdzam każde zagadnienie.

Czym jest audyt SEO i czym różni się audyt techniczny?

Audyt SEO mówi, w jakim stanie jest strona i co ogranicza jej widoczność, a audyt techniczny sprawdza, czy wyszukiwarka może stronę pobrać, wyrenderować i zaindeksować. W pełnym audycie sprawdzam technikę, architekturę i treść na stronach, frazy, linki zewnętrzne i konkurencję, a na końcu układam kolejność działań. Audyt techniczny wystarcza wtedy, gdy pytanie jest techniczne: spadek po wdrożeniu, migracja, strony wypadające z indeksu.

Audyt jest wejściem do strategii, a nie strategią. Strategia mówi, o jaki popyt walczysz i z czego rezygnujesz, a audyt mówi, co dziś stoi temu na przeszkodzie. W tekście o strategii SEO opisałem, jak jedno przechodzi w drugie.

Jak zrobić audyt SEO krok po kroku?

Kolejność kroków ma znaczenie, bo wcześniejsze kroki decydują, czy liczby z późniejszych są wiarygodne. W dwóch miejscach zatrzymuję proces na decyzję: po pierwszym kroku ustalam zakres, a po kontroli krzyżowej, przed wysyłką do klienta, sprawdzam priorytety i tezy.

Krok 1. Cel i sytuacja strony, zanim uruchomię crawler

Pierwsze pytanie brzmi, czy strona traci ruch, czy go nie buduje, bo od odpowiedzi zależy cały audyt. Strona bez widoczności potrzebuje najpierw mapy fraz i stron, które mają na nie odpowiadać. Strona, która ma widoczność, potrzebuje najpierw ochrony tego, co już zajmuje pozycje, zanim ktoś zacznie ją poprawiać.

Przed startem pytam o rzeczy, których nie pokaże żadne narzędzie. Które produkty albo usługi zarabiają, czy planowana jest zmiana systemu zarządzania treścią albo przebudowa, kto wdroży zalecenia i ile ma na to czasu. Z odpowiedzi wynika zakres audytu i lista rzeczy, których nie rozpisuję, bo nikt ich nie wdroży.

Ten etap trzeba przejść samodzielnie, choć wielu specjalistów oddaje go dziś modelowi językowemu. Model językowy bywa pomocny, ale nie zrozumie biznesu klienta. Nie wniesie też kreatywnego, unikalnego spojrzenia, które ma doświadczony specjalista SEO.

Krok 2. Czy roboty w ogóle dostają stronę

Zanim przeczytam jakąkolwiek liczbę z narzędzia, sprawdzam, czy serwer wpuszcza roboty, bo zablokowany robot daje dane, które wyglądają jak problemy SEO. W jednym tygodniu lipca 2026 trzy „problemy SEO” w trzech różnych serwisach okazały się blokadą robotów:

1. Serwis „tracił” ponad 2 200 linków, bo strony, z których prowadziły, stały za zaporą, która odbijała robota narzędzia do analizy linków.
2. Sklep miał w narzędziu wynik zdrowia strony 0 przy prawie 42 tys. błędów, bo zamiast stron robot narzędzia dostawał odpowiedzi zapory Cloudflare.
3. Na trzecim serwisie blokada zatrzymywała crawler na pierwszym adresie i przez trzy tygodnie nikt tego nie odnotował.

Ten sam adres pobieram jako zwykła przeglądarka i jako roboty Google, Bing, OpenAI, Perplexity i Anthropic, a potem porównuję kody odpowiedzi i rozmiar strony. Różnica między przeglądarką a robotem to pierwsza rzecz do wyjaśnienia, zanim zacznę cokolwiek liczyć. Taki test wysyła zapytania z mojego adresu IP pod nazwą robota, a zapory rozpoznają prawdziwe roboty Google i Bing po adresie, z którego przychodzą. Blokada „Googlebota” w teście nie dowodzi więc blokady prawdziwego Googlebota. Search Console, bezpłatny panel Google dla właścicieli stron, pokazuje, jak stronę widzi prawdziwy Googlebot.

Plik robots.txt czytam do końca parserem, czyli programem, który stosuje reguły tak jak robot, a nie wzrokiem. Robot Google stosuje tylko jedną grupę reguł, tę z najbardziej dopasowaną nazwą robota, i pomija pozostałe. Reguła Disallow: bez ścieżki niczego nie blokuje (Google Search Central). W sierpniu 2026 z fragmentu robots.txt jednej ze stron wynikało, że blokuje ona Google. Parser pokazał, że Googlebot miał pełny dostęp, a zablokowane były roboty Bing i asystentów AI. Diagnoza była więc inna: problem dotyczył Bing i robotów AI, a nie Google.

Brak pliku robots.txt nie blokuje Google, ale po każdym wdrożeniu sprawdzam, czy plik nie zniknął. Google traktuje błąd 4xx przy robots.txt (poza 429) tak, jakby pliku nie było, czyli bez ograniczeń (Google Search Central). Moja strona zwracała w sierpniu 2026 błąd 404 na robots.txt, zanim to poprawiłem.

Krok 3. Dane z kilku źródeł i to, czego każde nie widzi

Każda liczba z crawlera jest hipotezą, dopóki nie potwierdzi jej drugie źródło. Zbieram crawl z wykonaniem JavaScriptu i bez niego oraz dane o szybkości od prawdziwych użytkowników z raportu CrUX. Dodaję do tego profil linków i wyniki Google dla ważnych fraz z dnia pomiaru. W tekście o link buildingu opisałem, jak sprawdzam profil linków przed planem kampanii. Przy każdym pliku zapisuję źródło, datę i zakres, żeby po miesiącu dało się odtworzyć każdą liczbę.

Dane z Search Console pobieram przez API, czyli interfejs do automatycznego pobierania danych, bo eksport z panelu ucina listę do 1 000 wierszy. API oddaje do 50 tys. wierszy dziennie na każdy typ wyników, na przykład osobno dla wyników stron, grafik i wideo (Google, Pomoc Search Console). W tekście o narzędziach AI w SEO pokazałem, jak obcięty eksport zawyżył CTR w jednym serwisie.

Crawler potrafi zaniżyć wielkość serwisu, więc liczby stron i produktów sprawdzam w drugim źródle. W dwóch sklepach crawler doszedł do pierwszej strony listy produktów w kategorii i dalej nie poszedł, choć kolejne strony listy działały i nie były zablokowane. W jednym sklepie znalazł mniej niż połowę produktów, w drugim mniej niż jedną trzecią. Gdybym podał te liczby jako stan sklepów, audyt opisywałby braki w ofercie, których nie było.

Nagłe zmiany w danych dziennych opisuję, zanim przypiszę im przyczynę. Robię to dla kliknięć, wyświetleń, pozycji, sesji i żądań robota Google. Szukam dni, od których mediana z siedmiu kolejnych dni różni się o co najmniej 25% od mediany z czternastu dni przed nimi. Przy każdej takiej dacie zapisuję wyjaśnienie: wdrożenie, aktualizacja Google, awaria, zmiana pomiaru albo „przyczyna nieznana”. Opis dat daje hipotezy, a przyczynę wskazuję dopiero po sprawdzeniu innych możliwych wyjaśnień.

Krok 4. Frazy i wyniki Google przed techniką

Najpierw szukam szans, potem naprawiam błędy. Część problemów technicznych da się ocenić tylko na tle fraz: czy filtr w sklepie powinien się indeksować, czy tag zasługuje na osobną stronę, czy dwie strony naprawdę konkurują o to samo. W katalogu 32 typy problemów mają oznaczenie, że bez analizy fraz i wyników Google nie da się ich ocenić.

Brak strony pod ważną frazę to jeden z częstszych problemów w moich audytach: 15 z 63 audytów, w 14 z 50 serwisów. Crawler sam tego nie zgłosi, bo pobiera tylko strony, które istnieją. Widać to dopiero wtedy, gdy zestawię popyt z listą adresów i z tym, które strony konkurencji pojawiają się w wynikach.

Krok 5. Przegląd według katalogu z warunkami priorytetu

Ten sam błąd ma wysoki albo niski priorytet zależnie od tego, gdzie występuje. Link wewnętrzny do adresu z przekierowaniem w szablonie, który powtarza się na tysiącach stron, ma priorytet wysoki. Ten sam link w treści jednego wpisu ma priorytet średni, a w archiwalnych wpisach niski.

Każdy typ problemu w katalogu ma regułę wykrycia, warunek zgłoszenia, wymagany dowód, priorytet z warunkami i sposób sprawdzenia po wdrożeniu. Z 256 typów 86 zaczyna regułę priorytetu od „wysoki”, ale prawie zawsze z warunkiem: gdy fraza ma popyt, gdy strona ma ruch, gdy błąd jest w szablonie.

Dlatego wynik zdrowia strony z narzędzia nie wyznacza priorytetów. Narzędzie liczy błędy, a nie ruch, który od nich zależy. Zalecenie dotyczące stron o nieznanym ruchu nie dostaje wysokiego priorytetu, dopóki nie sprawdzę danych.

Krok 6. Dowód przy każdym zagadnieniu

Zagadnienie bez dowodu zostaje w audycie jako „do sprawdzenia”, a nie jako zalecenie. Dowodem jest zrzut miejsca w kodzie albo HTML z serwera obok wersji po wykonaniu JavaScriptu. Może nim być też wykres z Search Console albo pomiar szybkości z nazwą elementu, który ją psuje. Element, który pogarsza wczytywanie albo przesuwa układ strony, nazywam tak, jak wskazuje pomiar, a nie tak, jak pasuje do mojej hipotezy.

Każde zagadnienie opisuję w czterech częściach, od problemu do sprawdzenia naprawy. Piszę, na czym polega problem, dlaczego szkodzi i na co wpływa, jak go naprawić krok po kroku i jak sprawdzimy, że naprawa zadziałała. Kod do poprawy kopiuję ze strony dosłownie, żeby programista widział dokładnie to miejsce, które ma zmienić.

Tak wygląda w skrócie jedno zgłoszenie o linkach do przekierowań:

• Problem: linki w menu prowadzą do adresów bez ukośnika na końcu, które przekierowują na wersję z ukośnikiem.
• Dlaczego szkodzi: menu jest na każdej stronie, więc każde kliknięcie i każde pobranie przez robota przechodzi przez dodatkowe przekierowanie. W raportach narzędzi tysiące takich linków utrudniają znalezienie ważniejszych błędów.
• Naprawa: w szablonie menu podmienić adresy na docelowe, z fragmentem kodu przed i po zmianie.
• Sprawdzenie: po wdrożeniu crawl nie pokazuje w szablonie linków do adresów z przekierowaniem.

Krok 7. Kolejność, nakład pracy i warianty

Wynikiem audytu jest kolejność, a nie liczba znalezisk. Na początku dokumentu stoi tabela wszystkich zagadnień z priorytetem i nakładem pracy. Nakład opisuję w czterech kategoriach: kilka godzin, dzień lub dwa, tydzień albo cały projekt. Zespół z mniejszymi możliwościami dostaje wariant minimalny obok pełnego, z wyraźnym opisem, co traci, wybierając krótszą drogę.

Wdrożenie idzie dokładnie według audytu. Jeśli przy wycenie wdrożenia pojawia się tańszy wariant, wybiera go klient i zapisuję to wprost, a nie podmieniam zalecenia bez jego wiedzy.

Krok 8. Kontrola krzyżowa i sprawdzenie po wdrożeniu

Zanim audyt trafi do klienta, sprawdza go ktoś, kto go nie pisał. Robię dwie rundy kontroli: pierwszą na całym dokumencie, drugą tylko na tym, co zmieniło się po pierwszej. Kontrola przelicza liczby od zera i szuka tez, których nie da się obronić dowodem. Na końcu sam sprawdzam priorytety i tezy, które zależą od sytuacji klienta.

Po wdrożeniu każde zagadnienie sprawdzam na działającej stronie i oznaczam jako wdrożone poprawnie, w części albo niewdrożone. To sprawdzenie jest w cenie audytu. Bez tego kroku audyt kończy się na dokumencie, a nie na zmianie na stronie.

Co sprawdzam w audycie technicznym?

W audycie technicznym przechodzę przez kilkanaście obszarów, a problemy najczęściej zgłaszam w przekierowaniach, architekturze strony i treści. Ostatnia kolumna pokazuje, w ilu z 63 audytów z archiwum autor zgłosił co najmniej jeden problem z danego obszaru. Kolumna „Co sprawdzam” podaje przykłady, a nie pełny zakres obszaru. Tabela pokazuje wybrane obszary, a katalog dzieli problemy na 22.

Problem rzadko zgłaszany nie musi rzadko występować. Szybkość i JavaScript mają w tej tabeli mało zgłoszeń, ale audyty z archiwum miały różny zakres. Niska liczba zgłoszeń nie mówi więc, jak często te problemy występują na stronach.

Jak sprawdzam indeksowanie strony?

Indeksowanie sprawdzam na trzech listach: co jest w mapie witryny, co Google zaindeksował i co crawler znajduje przez linki. Rozbieżność między tymi trzema listami pokazuje problem lepiej niż każda z osobna. Mapa witryny z adresami, które zwracają przekierowanie, błąd albo są wyłączone z indeksu, była zgłoszona w 20 z 63 audytów, w 18 z 50 serwisów. Dla pojedynczych adresów korzystam z inspekcji adresu w Search Console, która pokazuje także stronę po wykonaniu JavaScriptu.

Czy Core Web Vitals wpływają na pozycje?

Core Web Vitals są częścią systemów rankingowych Google, ale nie wygrywają z trafnością treści. Google pisze wprost, że systemy rankingowe korzystają z Core Web Vitals. Pisze też, że zawsze stara się pokazać najbardziej trafną treść, nawet przy słabym doświadczeniu na stronie (Google Search Central). W audycie korzystam z danych od prawdziwych użytkowników z raportu CrUX, a nie z jednego testu w narzędziu laboratoryjnym. Tam, gdzie Google ma takie dane dla poszczególnych typów stron, podaję je osobno. Braki tych danych opisuję w audycie. Od 12 marca 2024 miarą reakcji strony jest INP, który zastąpił FID (web.dev).

Jakie błędy najczęściej znajduję w audytach SEO?

Najczęściej powtarzają się błędy porządkowe, czyli takie, które narzędzia łatwo wykrywają: linki do przekierowań i do błędów 404, mapy witryny z niewłaściwymi adresami i zduplikowane tytuły i opisy stron. Linki wewnętrzne do adresów z przekierowaniem pojawiły się w 24 z 63 audytów, w 20 z 50 serwisów. Narzędzia wykrywają je dobrze, a koszt naprawy zależy od szablonu i systemu strony.

Rzadziej zgłaszane problemy struktury potrafią mieć większy wpływ na ruch niż błędy porządkowe. Brak stron pod ważne frazy zgłoszono w 15 z 63 audytów i tyle samo razy blog, który nie linkuje do stron oferty i kategorii. Katalog daje brakującej stronie wysoki priorytet, gdy fraza ma popyt, a konkurencja zajmuje pozycje osobnymi stronami. Blog bez linków dostaje wysoki priorytet, gdy strony docelowe mają ruch lub przychód, a blog ma autorytet. Te warunki sprawdzam na danych, zanim nadam priorytet.

• 938znalezisk w 63 audytach w 50 serwisach, z których zbudowałem katalog 256 typów problemówArchiwum audytów 2020-2026, katalog z 11.10.2026
• 38%audytów z linkami wewnętrznymi do adresów z przekierowaniem, najczęściej zgłaszanym problemem w archiwum (24 z 63)Katalog z 11.10.2026
• 15 z 63audytów z brakiem stron pod ważne frazy, czego crawler sam nie zgłosiKatalog z 11.10.2026
• 14typów zaleceń, które katalog oznacza dziś jako przestarzałe, a 30 kolejnych jako zmienioną praktykęKatalog z 11.10.2026

Co zmieniło się w audytach SEO od 2020 roku?

W audytach z lat 2023-2026 dane strukturalne i paginacja pojawiają się częściej niż w latach 2020-2022, a przekierowania, adresy kanoniczne i indeksowanie rzadziej. Problemy z danymi strukturalnymi zgłoszono w 23 z 33 nowszych audytów wobec 16 z 30 starszych. Przekierowania i kody odpowiedzi: 23 z 33 wobec 27 z 30. Blokady robotów AI pojawiają się dopiero w audytach z 2026 roku. Rok audytu to data pliku w archiwum, więc nie zawsze rok wykonania pracy.

Spadek nie dowodzi, że problemy z przekierowaniami zniknęły. Zmienił się skład audytów: nowsze częściej dotyczyły danych strukturalnych, treści i widoczności w AI, a zmienił się też sposób pracy. Z tego wykresu wynika, czym zajmowały się audyty, a nie to, jak zmieniły się strony w Polsce.

Jakie zalecenia SEO są dziś nieaktualne?

Niektóre zalecenia wciąż pojawiają się w audytach i poradnikach, choć dziś nie warto ich wdrażać. Część z nich działała kilka lat temu, a część Google odradzał albo pomijał od dawna. W tabeli przy każdej praktyce podaję powód i to, co robić zamiast niej.

Źródła do tabeli: Google o paginacji, Google o pięciu błędach z rel=canonical, Google o wynikach FAQ i HowTo, Matt Cutts o nofollow i rozdziale mocy linków, John Mueller o przekierowaniach na stronę główną, za Search Engine Roundtable, Google o robots.txt, Google o nieobsługiwanych regułach w robots.txt, Google o mapach witryny, Google o polach lastmod, changefreq i priority, web.dev o INP, Google o polu wyszukiwania w wynikach.

Dlatego każde zalecenie w moim katalogu ma pole aktualności z uzasadnieniem. Katalog oznacza dziś 14 typów zaleceń jako przestarzałe i 30 jako zmienioną praktykę. Zalecenie, które było poprawne kilka lat temu, nie trafi do audytu tylko dlatego, że kiedyś działało.

Jak sprawdzić dostęp robotów AI w audycie?

Dostęp robotów AI sprawdzam w tym samym kroku co dostęp Googlebota, bo zablokować je potrafi to samo ustawienie zapory albo CDN. CDN to sieć serwerów pośredniczących, na przykład Cloudflare. We wrześniu 2026 sprawdziłem 12 domen moich klientów, które działają za Cloudflare. Sam plik robots.txt pokazał:

• 3 domeny blokowały ten sam zestaw siedmiu robotów zbierających dane do trenowania modeli, z identyczną listą nazw. Identyczna lista sugeruje wspólne źródło, na przykład gotowe ustawienie w panelu Cloudflare. Z zewnątrz tego ustawienia nie widać, więc trzeba je potwierdzić w samym panelu.
• 1 domena blokowała roboty, które pobierają strony do odpowiedzi ChatGPT, Perplexity i Claude. Nie robiła tego wprost, tylko ogólną regułą dla wszystkich robotów niewymienionych z nazwy. Ta sama domena pokazywała GPTBotowi stronę zabezpieczenia bez znacznika noindex, który wyłącza stronę z indeksu. Gdyby taką stronę dostał robot indeksujący, do indeksu mogłaby trafić strona blokady zamiast treści.
• 8 domen nie miało blokad w robots.txt.

O robotach, które pobierają strony do odpowiedzi, i o robotach, które zbierają dane do trenowania, decydujesz osobno. W tekście o pozycjonowaniu w AI opisałem, jak je rozróżnić. Od 31 sierpnia 2026 jest też osobne ustawienie w Search Console, które wyklucza stronę z AI Overview, trybu AI i funkcji generatywnych w Discover. Według Google nie wpływa ono na resztę wyników wyszukiwania (Pomoc Search Console). Takie ustawienie sprawdzam w audycie tak samo jak robots.txt, bo ktoś mógł je włączyć bez wiedzy osoby odpowiedzialnej za SEO. Czy po otwarciu dostępu marka pojawia się w odpowiedziach, to już osobny pomiar, który opisałem w tekście o widoczności marki w AI.

Test z jednego adresu IP pokazuje tylko część sytuacji, a sam potrafi dać fałszywy alarm. W tym samym przeglądzie seria zapytań zgłosiła na dwóch domenach blokadę po przekroczeniu limitu. Tę blokadę wywołały moje własne wcześniejsze zapytania. Kontrola kilka minut później, z jednym identyfikatorem robota i pojedynczymi zapytaniami, dała pięć i siedem poprawnych odpowiedzi z rzędu. Gdyby nie ta kontrola, dwóch klientów dostałoby informację o blokadzie, której nie było. Dopiero logi serwera pokazują, czy ChatGPT faktycznie pobiera stronę. W tekście o pliku llms.txt pokazuję, co widać w logach mojej strony.

Kod 200 nie znaczy, że robot dostał treść. U jednego klienta z aplikacją w JavaScripcie Googlebot i Bingbot dostawały gotowy HTML z usługi prerenderu, a roboty asystentów AI pustą stronę. Usługa rozpoznawała roboty po nazwie i nie miała robotów AI na liście. Mój test dał wynik „w porządku”, bo mierzył kod odpowiedzi, a nie treść. Od tego czasu porównuję treść, którą dostaje robot, z treścią po wykonaniu JavaScriptu w przeglądarce.

Czy darmowy audyt SEO wystarczy?

Darmowe narzędzie pokaże listę błędów, ale z samego raportu nie wynika, które z nich kosztują Cię ruch. Na frazę „audyt seo” 7 z 9 wyników organicznych na pierwszej stronie Google to narzędzia albo oferty darmowego audytu (wyniki z 17 października 2026). Taki raport liczy błędy według reguł narzędzia, a nie według tego, ile ruchu i przychodu od nich zależy. Trzeba też sprawdzić, czy wynik nie pochodzi z blokady robota, jak w przypadku sklepu z wynikiem zdrowia 0.

Dużo zrobisz bezpłatnie, jeśli wiesz, gdzie patrzeć. Search Console pokazuje dane Google o indeksowaniu, Core Web Vitals i stronę po wykonaniu JavaScriptu. Darmowa wersja Screaming Frog przechodzi do 500 adresów w jednym crawlu (Screaming Frog), co wystarcza na małą stronę firmową. Audyt z konsultantem ma sens wtedy, gdy błąd dużo kosztuje (migracja, spadek ruchu, duży sklep) albo gdy nie masz czasu, żeby dane zestawić i ocenić.

Czy ChatGPT zrobi audyt SEO?

ChatGPT ani inny model AI nie zrobi pełnego audytu sam, bo nie widzi strony tak jak robot wyszukiwarki. Zwykle widzi ją przez narzędzie, które ją pobiera i zamienia na tekst. Model przeczyta dane, które mu dasz, i zaproponuje, co sprawdzić. Narzędzie pobierania potrafi jednak zgubić część strony: we wrześniu 2026 sprawdziłem, że narzędzie do pobierania stron w Claude Code wycina dane strukturalne przy zamianie strony na tekst. Model odpowiedział, że informacji nie ma, choć była w znaczniku na tej samej stronie. Audyt zrobiony w ten sposób zgłosiłby brak danych strukturalnych, których nie brakuje. W moim procesie AI jest narzędziem, przede wszystkim do agregacji danych z crawla, Search Console i innych źródeł. Zakres, ocenę i priorytety ustalam sam.

Ile kosztuje audyt SEO?

Audyt rozliczam tak jak konsultację: 300 zł netto za godzinę pracy, z górną granicą godzin ustaloną przed startem. Liczba godzin zależy od tego, co trzeba sprawdzić:

• audyt diagnostyczny, czyli jeden albo dwa konkretne problemy (spadek, migracja, indeksowanie), to zwykle 10-16 godzin, czyli 3 000-4 800 zł netto;
• pełny audyt z kolejnością działań to zwykle 32-50 godzin, czyli 9 600-15 000 zł netto;
• mała strona do 500 adresów jest bliżej dolnej granicy, a sklep z tysiącami adresów i filtrami bliżej górnej;
• wersje językowe dodają zwykle 3-5 godzin, a trwający kryzys, który trzeba zdiagnozować, 4-8 godzin.

W cenie jest analiza, raport z zaleceniami, spotkanie, na którym go omawiamy, i sprawdzenie po wdrożeniu. Samo wdrożenie robi Twój zespół albo wyceniam je osobno.

Bez dostępu do Search Console, panelu CDN i hostingu części technicznej nie sprawdzę w pełni i mówię o tym przed wyceną. Wskazuję wtedy, czego bez tych dostępów nie zweryfikuję, i odpowiednio zawężam zakres. W tekście o konsultacji SEO opisałem, kiedy zamiast audytu wystarczy rozmowa o jednej decyzji.

Najczęstsze pytania o audyt SEO

Od czego zacząć?

Zacznij od jednego pytania: czy strona traci ruch, czy go nie buduje. Od odpowiedzi zależy, czy najpierw chronisz strony, które mają pozycje, czy szukasz fraz, pod które brakuje stron. Potem zrób trzy darmowe sprawdzenia z odpowiedzi o samodzielnym audycie: robots.txt, raport indeksowania w Search Console i crawl darmową wersją Screaming Frog. Jeśli wynik Cię zaskoczy albo nie wiesz, co naprawić najpierw, to dobry temat na konsultację.