Audyt techniczny SEO: co sprawdzić i jak ustalić priorytety poprawek

Jakich narzędzi i dostępów potrzebujesz?

Zapytaj właściciela witryny, jakie usługi, kategorie lub produkty mają przynosić wejścia i zapytania, jakie wersje językowe są aktywne i co ostatnio się zmieniło. Przy badaniu spadku porównaj datę ostatniego wdrożenia z początkiem problemu. Dzięki temu wiesz, które zmiany sprawdzić, choć sama zbieżność dat nie dowodzi przyczyny.

Do kontroli w przeglądarce otwórz narzędzia deweloperskie Chrome klawiszem F12 albo poleceniem „Zbadaj” z menu kontekstowego. PageSpeed Insights analizuje szybkość ładowania, a Test wyników z elementami rozszerzonymi sprawdza dane strukturalne obsługiwane przez Google. Oba narzędzia przyjmują publiczne adresy URL.

Do przeskanowania linków w witrynie możesz użyć programu Screaming Frog SEO Spider. Wersja darmowa ma limit 500 adresów URL na jedno skanowanie, razem z zasobami, które program zbiera. Po jego osiągnięciu skanowanie się zatrzymuje i część stron może zostać pominięta. Renderowanie JavaScriptu nie jest dostępne w wersji darmowej. Treści ładowane skryptami sprawdzaj więc w przeglądarce i, jeśli masz dostęp, w Narzędziu do sprawdzania adresów URL.

Jak wybrać adresy URL do sprawdzenia?

W witrynie firmy usługowej z blogiem zacznij od poniższych 13 różnych adresów URL. Próba obejmuje różne typy stron i przydatne porównania, w tym adres z przekierowaniem i stronę celowo wyłączoną z indeksu. Każdy adres wybierz tylko raz. Szablon to układ, według którego system CMS generuje strony tego samego typu, na przykład strony usług.

Suma to 1 + 3 + 3 + 1 + 2 + 1 + 1 + 1 = 13. Jeśli jakiegoś typu nie ma, oznacz go jako „nie dotyczy” i zmniejsz sumę. W sklepie internetowym dodaj kategorie, produkty dostępne i niedostępne, warianty oraz paginację. W witrynie wielojęzycznej dołóż pary równoważnych stron. Gdy znajdziesz błąd, sprawdź inne adresy URL wygenerowane z tego samego szablonu, żeby ustalić zasięg problemu i wychwycić wyjątki.

Zacznij od adresów z nawigacji i mapy witryny, a jeśli masz dostęp do Search Console, dodaj przykłady problemów z raportów. Dla każdego zapisz, co ma się dziać: czy może pojawiać się w wyszukiwarce, być duplikatem innej strony, przekierowywać gdzie indziej albo pozostać poza indeksem. Jeśli adres jest w mapie witryny, a nie ma go w skanowaniu, sprawdź, jak dociera do niego odwiedzający. Strony przejrzane przez robota mogą do niego nie linkować.

Zacznij od odpowiedzi HTTP, robots.txt i map witryny

1. Sprawdź odpowiedź i adres docelowy

   W narzędziach deweloperskich otwórz kartę Sieć, włącz „Zachowaj dziennik” i przeładuj stronę. Wybierz żądanie dokumentu i otwórz Nagłówki. Kod stanu pokazuje kod odpowiedzi, a Location podaje cel przekierowania. Zapisz adres wyjściowy, ewentualne przekierowania pośrednie i adres końcowy.

   W terminalu to polecenie zapisuje nagłówki odpowiedzi do pliku headers.txt i końcowy kod HTML do page.html. Zastąp przykładowy adres adresem, który chcesz sprawdzić. W PowerShellu użyj curl.exe zamiast curl.

   curl -sS -L -D headers.txt -o page.html https://example.com/service/

   Działająca strona zwykle zwraca kod 200 i pokazuje oczekiwaną treść. Stary adres przeniesiony na stałe może zwracać 301 lub 308 i prowadzić do równoważnej strony. Nieistniejący adres powinien zwracać 404 lub 410. Jeśli wyświetla komunikat „strona nie została znaleziona”, ale serwer odpowiada kodem 200, zanotuj możliwy soft 404. Przy błędzie 5xx powtórz test i poproś firmę hostingową o sprawdzenie logów, żeby odróżnić jednorazową awarię od problemu, który wraca.

2. Sprawdź reguły skanowania

   Otwórz https://example.com/robots.txt, zastępując przykładową domenę prawdziwą i zachowując protokół witryny. Znajdź grupę reguł dla Googlebota i sprawdź, czy któraś reguła Allow lub Disallow pasuje do ścieżki strony. Zapisz regułę i sprawdź dostęp do plików CSS i skryptów potrzebnych do załadowania treści. Jeśli masz Search Console, porównaj wyniki z polem „Czy skanowanie jest dozwolone” w Narzędziu do sprawdzania adresów URL.

   Jeśli ważna strona publiczna jest zablokowana przez pomyłkę, przekaż regułę osobie zarządzającej konfiguracją. Disallow ogranicza skanowanie. Żeby noindex wykluczył stronę z indeksu, Google musi móc odczytać tę dyrektywę. Zablokowanie tej samej strony w robots.txt może to uniemożliwić, co wyjaśnia dokumentacja Google o noindex. Treści prywatne chroń uwierzytelnianiem, bo robots.txt nie przeszkadza nikomu w ich otwarciu.

3. Porównaj mapę witryny z rzeczywistymi stronami

   Poszukaj w robots.txt linii Sitemap albo zapytaj administratora witryny o lokalizację pliku. Jeśli plik wskazuje kolejne mapy, otwórz je także. Dla przykładowych adresów, które mają być zindeksowane, sprawdź, czy mapa podaje preferowany adres, strona zwraca 200 i nie ma dyrektywy noindex. Przekierowania, błędy i niepreferowane duplikaty oznacz do usunięcia z pliku. Sprawdź też lastmod: data powinna odzwierciedlać istotne zmiany strony, a nie aktualizować się dla wszystkich stron przy każdym wdrożeniu.

   W Search Console, w sekcji Mapy witryn, sprawdź, czy Google odczytał plik, i otwórz zgłoszone błędy. Mapa witryny pomaga Google odkrywać adresy, ale to, czy są zindeksowane, musisz sprawdzić osobno. Wskazówki Google dotyczące map witryn wyjaśniają, jakie adresy i daty podawać.

Czy stronę można zindeksować i który adres wybiera Google?

Jeśli po wpisaniu docelowego zapytania nie możesz znaleźć strony, najpierw sprawdź, czy jest zindeksowana. Wklej pełny adres URL do Narzędzia do sprawdzania adresów URL w Search Console. Odczytaj status i ewentualną przyczynę wykluczenia. Zapisz datę ostatniego skanowania, adres kanoniczny określony przez użytkownika i, jeśli jest dostępny, adres kanoniczny wybrany przez Google. Następnie wybierz „Sprawdź URL wersji opublikowanej”, żeby sprawdzić aktualną wersję. Zapisz oba wyniki z datą: Google mógł jeszcze nie zobaczyć ostatniej zmiany.

Test wersji opublikowanej nie sprawdza wszystkich wymogów indeksowania, nie potwierdza, że strona jest zindeksowana, i nie przewiduje, który adres kanoniczny wybierze Google. Status indeksu i wybrany adres kanoniczny odczytaj z danych o indeksie, jak wyjaśnia instrukcja Narzędzia do sprawdzania adresów URL. Bez dostępu zostaw te kontrole jako oczekujące i zapisz to, co widać w witrynie publicznej.

Niezindeksowana czy zindeksowana, ale bez pozycji?

Raport Indeksowanie stron wyjaśnia przyczyny wykluczeń. Widoczność w wyszukiwarce badaj w raporcie skuteczności. Jeśli brakuje jakiegoś zapytania, pamiętaj, że część zapytań jest pomijana ze względu na prywatność lub limity danych. To nie dowodzi, że strona wypadła z indeksu. Jeśli jest zindeksowana, z pomocą poradnika o analizie słów kluczowych oceń, czy odpowiada na zapytanie, na którym Ci zależy.

Sprawdź dyrektywy i adres kanoniczny

Otwórz zapisany plik HTML lub widok źródła strony i wyszukaj name="robots", dyrektywy googlebot oraz rel="canonical". Sprawdź także w nagłówkach HTTP, czy występuje X-Robots-Tag. Canonical wskazuje adres, który witryna proponuje jako wersję główną. Zapisz go i otwórz, żeby sprawdzić, czy istnieje i pokazuje oczekiwaną treść.

Nieoczekiwany noindex na odrębnej stronie, która ma być w Google, trzeba usunąć. Jeśli wariant jest duplikatem, canonical wskazujący wersję główną może być prawidłowy. Porównaj ustalenia z oczekiwanym zachowaniem zapisanym w dzienniku audytu. Canonical wyraża preferencję: przekierowania, linki wewnętrzne i mapy witryn powinny wspierać ten sam wybór. Wskazówki Google o adresach kanonicznych wyjaśniają, jak te sygnały działają razem.

Przykład hipotetyczny: canonical wskazuje inną usługę

Weźmy dwie odrębne strony: /konserwacja-kotlow/ i /montaz-kotlow/. Strona o konserwacji jest wykluczona jako duplikat, a Narzędzie do sprawdzania adresów URL pokazuje stronę o montażu jako adres kanoniczny wybrany przez Google. W kodzie HTML strony o konserwacji znajdujesz canonical wskazujący na stronę o montażu. Test wersji opublikowanej może w takiej sytuacji nadal przejść.

Jeśli obie strony mają pojawiać się w wyszukiwarce i opisują różne usługi, przekaż programiście oba adresy i znaleziony tag. Poproś o sprawdzenie szablonu i poprawienie canonicala tak, żeby wskazywał stronę o konserwacji, a potem o kontrolę linków wewnętrznych i mapy witryny. Po wdrożeniu sprawdź tag w HTML i w DOM. Później w Search Console ponownie sprawdź datę skanowania, status indeksu i wybór adresu kanonicznego. Jeśli strona zostanie zindeksowana, ale na zapytanie „konserwacja kotła” nadal będzie mało widoczna, zbadaj to zapytanie w raporcie skuteczności.

Czy treść da się odczytać po wyrenderowaniu JavaScriptu?

Porównaj page.html ze stroną załadowaną w przeglądarce. W karcie Elementy, która pokazuje DOM zbudowany przez przeglądarkę, poszukaj fragmentu tekstu głównego, nagłówka H1, adresu canonical i ważnego linku. Jeśli coś tam jest, a brakuje tego w kodzie źródłowym, zapisz, jaką treść lub jaki tag dodaje JavaScript. W kartach Sieć i Konsola sprawdź nieudane żądania i błędy, przez które strona jest pusta albo nie działa nawigacja.

Poniższe polecenie nic nie zmienia. Wpisz je w konsoli narzędzi deweloperskich, żeby sprawdzić tytuł, adresy canonical i dyrektywy w DOM. Pomaga porównać końcowe tagi ze źródłem i nie odpytuje indeksu Google.

({
  title: document.title,
  canonical: [...document.querySelectorAll('link[rel="canonical"]')].map(e => e.href),
  robots: [...document.querySelectorAll('meta[name="robots"], meta[name="googlebot"]')].map(e => e.content)
})

Jeśli masz Search Console, po teście wersji opublikowanej otwórz „Wyświetl przetestowaną stronę” i porównaj jej HTML, zrzut ekranu i zasoby z przeglądarką. Gdy na przykład cena i opis produktu pojawiają się dopiero po kliknięciu, sprawdź, czy są w HTML przetestowanym przez Google. Poradnik Google o JavaScripcie i SEO wyjaśnia też, że Google może pominąć renderowanie, jeśli początkowy HTML zawiera noindex. Usunięcie go wyłącznie skryptem jest zawodne.

Sprawdź, czy główna treść jest dostępna, tagi nie są ze sobą sprzeczne, a ważne linki używają <a href="…"> ze stałymi adresami. Jeśli w przeglądarce wszystko się ładuje, a test Google kończy się niepowodzeniem, zapisz komunikat o błędzie i adres URL zasobu, którego dotyczy. Programista dostaje wtedy konkretny punkt wyjścia.

Czy do ważnych stron da się dotrzeć przez linki wewnętrzne?

W Screaming Frog uruchom skanowanie w trybie Spider od adresu strony głównej, z uwzględnieniem robots.txt. Zapisz datę i ustawienia oraz sprawdź, czy limit wersji darmowej nie zatrzymał skanowania. Wybierz adres na karcie Internal i otwórz u dołu Inlinks, żeby zobaczyć, które strony do niego linkują. Wyeksportuj źródło, cel i tekst linku. Jeśli strona jest w mapie witryny, a brakuje jej w skanowaniu, najpierw sprawdź, czy skanowanie jest kompletne i czy linki nie zależą od JavaScriptu.

Następnie przejdź po witrynie w przeglądarce, na komputerze i smartfonie. Zacznij od strony głównej, otwórz kategorię i dotrzyj do strony z próby. Zapisz ścieżkę i miejsce, w którym brakuje przydatnego linku. W archiwach i katalogach wyjdź poza pierwszą stronę i sprawdź, czy dalsze pozycje są osiągalne. Zanim nazwiesz stronę „osieroconą”, czyli taką, do której nie prowadzą żadne linki wewnętrzne, porównaj skanowanie z nawigacją witryny i inwentarzem CMS.

Przy filtrach i wariantach porównaj zawartość stron i sprawdź adresy tworzone przez linki. Jeśli każda kombinacja daje nowy adres, ustal z administratorem witryny, które wersje mają pojawiać się w Google. W witrynach wielojęzycznych sprawdź, czy canonical każdej strony prowadzi do niej samej, a wzajemne linki alternatywne wskazują równoważne wersje językowe. Nasza usługa pozycjonowania sklepów internetowych obejmuje produkty i filtry, a checklista SEO międzynarodowego wyjaśnia, jak sprawdzać wersje językowe.

Jak sprawdzić szybkość, wersję mobilną i dane strukturalne?

Wpisz do PageSpeed Insights po jednym adresie z każdego ważnego szablonu i porównaj wyniki dla urządzeń mobilnych i komputerów. Dane od prawdziwych użytkowników i test laboratoryjny narzędzia traktuj osobno. Jeśli brakuje danych dla pojedynczego adresu, sprawdź, czy raport pokazuje dane dla źródła (origin): stron z tym samym protokołem, domeną i portem. Za dobre Core Web Vitals uznaje się LCP do 2,5 sekundy włącznie, INP do 200 milisekund włącznie i CLS do 0,1 włącznie, oceniane na 75. percentylu wizyt. TBT w teście laboratoryjnym nie jest pomiarem INP.

Jeśli strona ładuje się wolno, znajdź w raporcie element LCP i oznaczone zasoby, a problem przekaż programiście do zbadania. Może chodzić o obraz, czcionki albo czas odpowiedzi serwera. Szacowane oszczędności opisują poprawę, którą narzędzie uznaje za możliwą, a nie wynik już osiągnięty. Po zmianie powtórz test w tych samych warunkach, a dane od prawdziwych użytkowników sprawdź później. Dokumentacja Core Web Vitals wyjaśnia te wskaźniki.

Na telefonie albo w trybie urządzenia w narzędziach deweloperskich otwórz menu, kliknij linki i wypróbuj formularze. Sprawdź, czy treść jest czytelna, a przyciski, etykiety i przewijanie działają. Przetestuj też obsługę klawiaturą.

W Teście wyników z elementami rozszerzonymi otwórz błędy wykrytych typów i porównaj wartości, takie jak cena, dostępność i autor, z widoczną stroną. Popraw nieprawidłowe wartości i brakujące pola wymagane. Test nie obejmuje wszystkich wymogów, więc sprawdź też wytyczne dotyczące danych strukturalnych i zasady dla konkretnego typu wyniku. Nawet poprawne dane nie gwarantują, że Google pokaże wynik rozszerzony.

Które problemy naprawiać najpierw?

Połącz ustalenia, które powoduje ten sam szablon lub ta sama reguła. Ustalając priorytety, weź pod uwagę, jakich stron dotyczy problem, co przestaje działać i jak pewna jest diagnoza. Potem uzgodnij z programistą termin, potrzebne zmiany i możliwe skutki dla innych stron. Błąd, który trzyma ważną stronę usługi poza Google, może mieć pierwszeństwo przed licznymi ostrzeżeniami o duplikatach, które witryna już prawidłowo obsługuje.

Przykład praktyczny: noindex na stronach usług

Załóżmy, że w próbie 13 adresów dwie z trzech stron usług zwracają kod 200, ale zawierają <meta name="robots" content="noindex">. Trzecia nie ma tej dyrektywy, a wszystkie trzy powinny móc pojawiać się w Google.

Zapisz w dzienniku audytu oba adresy, wiersz HTML i datę kontroli. Poproś programistę o porównanie ich szablonów i ustawień z trzecią stroną usługi. Problem występuje na dwóch z trzech sprawdzonych stron usług. Żeby ustalić, których jeszcze adresów dotyczy, sprawdź strony generowane przez tę samą regułę, także te, które mają pozostać wykluczone.

Po poprawce sprawdź, czy obie strony zwracają 200, pokazują oczekiwaną treść i mają właściwy canonical. Noindex nie może występować ani w początkowym HTML, ani w DOM, ani w nagłówkach. Powtórz test na trzeciej stronie usługi i na stronie celowo wykluczonej, żeby upewnić się, że ich zachowanie się nie zmieniło. Status w indeksie Google sprawdź osobno w Search Console.

Jak przekazać wnioski programiście?

Dla każdego problemu załóż wpis z listą adresów URL, których dotyczy, i szablonem lub regułą, którą mają wspólną. Dołącz nagłówki, HTML albo zrzuty ekranu z datą i użytym narzędziem. Opisz najpierw to, co zaobserwowano, a dopiero potem podejrzewaną przyczynę do zbadania. Dodaj oczekiwany wynik, osobę, która ma działać, i test do powtórzenia po zmianie. Zachowaj też kilka kontroli zakończonych powodzeniem, żeby zauważyć, czy poprawka nie wprowadza nowych błędów.

Szablon CSV dziennika audytu ma 13 wierszy, po jednym dla każdego adresu proponowanej próby, z pustymi polami URL do uzupełnienia. Zduplikuj wiersz, jeśli chcesz zapisać kolejną kontrolę tego samego adresu. Dane z indeksu i wyniki testu wersji opublikowanej zapisuj osobno, każde ze źródłem i datą.

Wypełniony przykład CSV opisuje hipotetyczną stronę o konserwacji kotłów. W trzech wierszach zapisano dane z indeksu, canonical w HTML i test wersji opublikowanej tego samego adresu. Kontrole po poprawce pozostają otwarte.

Zaimportuj plik CSV do arkusza z kodowaniem UTF-8, średnikiem jako separatorem i kolumnami w formacie tekstowym. Najpierw wpisz adres URL i oczekiwane zachowanie, potem kontrolę, dowód i następne działanie. Wpisz „nie zweryfikowano”, jeśli kontroli nie dało się wykonać, na przykład z braku dostępu, i „nie dotyczy”, jeśli takiego przypadku w witrynie nie ma.

Jeśli poprawka wymaga czytania logów, zmian w CMS albo prowadzenia wdrożenia, włącz do pracy kogoś z dostępem do tych systemów. Usługa technicznego SEO w Qreativa obejmuje analizę i koordynację poprawek. Jeśli zmieniasz domenę lub platformę witryny, przygotuj z pomocą checklisty migracji SEO mapowanie adresów URL, przekierowania i kontrole przy starcie.

Jak sprawdzić poprawkę po wdrożeniu?

1. Powtórz test na działającej witrynie

   Zapisz, kiedy zmiana weszła na produkcję, i wykonaj to samo polecenie lub te same kroki na adresach sprawdzanych wcześniej. Porównaj wyniki z oczekiwanym efektem. Poprawka musi działać w witrynie publicznej, nawet jeśli przeszła już test w środowisku testowym.

2. Sprawdź też inne strony

   Powtórz test na stronie, która działała prawidłowo, i na stronach celowo wykluczonych, żeby upewnić się, że zmiana na nie nie wpłynęła. Jeśli zmieniły się adresy docelowe, zaktualizuj mapę witryny i linki. Jeśli wspólna reguła może znów wywołać błąd, poproś programistę o dodanie automatycznej kontroli przed kolejnymi wdrożeniami.

3. Sprawdź, kiedy Google widzi zmianę

   W Search Console sprawdź adres URL wersji opublikowanej i poproś o zindeksowanie poprawionych stron, które mają pojawiać się w wyszukiwarce. Później sprawdź datę ostatniego skanowania, status indeksu i adres kanoniczny wybrany przez Google. Prośba nie gwarantuje ani terminu, ani włączenia do indeksu. Nasz poradnik Ile trwa pozycjonowanie? wyjaśnia, czym te kroki różnią się od wzrostu liczby wejść.

Gdy testy w witrynie publicznej potwierdzą poprawkę, oznacz pracę techniczną w dzienniku audytu jako zakończoną. Jeśli Google jeszcze nie odwiedził strony ponownie, zostaw otwartą tylko tę kontrolę. Jeśli problem wróci, zaktualizuj ten sam wpis o nowe dowody i datę zmiany, po której go zauważono.