Co będzie gotowe po zakończeniu
Ten proces jest dla właścicieli treści, specjalistów SEO i developerów, którzy chcą poprawić jedną istniejącą stronę publiczną bez przepisywania jej na oślep. W ciągu około 20-45 minut przygotujesz krótki brief naprawczy dla konkretnej strony: jeden docelowy zamiar wyszukiwania, listę zmian opartych na dowodach, właściciela każdej zmiany i sposób ponownego uruchomienia audytu po wdrożeniu.
Traktuj go jako checklistę on-page SEO dla jednego URL, a nie jako zamiennik technicznego crawla całej witryny. Sprawdź sygnały tematyczne strony, treść i linki, kontekst istotnych obrazów, dane strukturalne oraz kondycję crawlowania. Następnie popraw to, co wpływa na jasność, dokładność, dostępność albo preferowaną ścieżkę crawlowania.
Potrzebujesz działającego, publicznego URL i jednej głównej frazy wyszukiwania. Możesz dodać do czterech bliskich fraz, ale wyłącznie wtedy, gdy strona rzeczywiście na nie odpowiada. Gotowym rezultatem nie jest wyższy wynik sam w sobie. Jest nim strona, na której title, nagłówki, tekst, linki, obrazy, dane strukturalne i sygnały crawl opowiadają spójną historię o zadaniu osoby szukającej.
Auspia On-Page SEO Audit analizuje widoczne dowody ze strony i HTML. Pomaga znaleźć słabe sygnały tematyczne oraz luki techniczne. Nie przewidzi jednak pozycji, nie zmierzy autorytetu backlinków, nie oceni konkurencji w SERP, nie potwierdzi pokrycia indeksu ani nie wyjaśni zachowania użytkowników po wejściu na stronę.
Dobry przegląd on-page zamienia jasne dowody ze strony w mały brief naprawczy i krok weryfikacji strony publicznej.
Przygotuj jedną stronę i jedno zadanie
Zacznij od strony o jasnym celu. Może to być strona funkcji produktu, usługi, poradnik, kategoria lub starszy artykuł. Na początku nie audytuj strony głównej ani szerokiego huba, chyba że ta strona ma odpowiedzieć na jedno oczywiste zapytanie.
Zanim otworzysz narzędzie, zapisz proste zdanie:
Ta strona ma pomóc [odbiorcom] rozwiązać lub wybrać [konkretne zadanie], gdy szukają [głównej frazy].
Przykładowo strona celująca w "on-page SEO audit" może obiecywać bezpłatne sprawdzenie metadanych, struktury treści, schema, linków i sygnałów crawl dla publicznego URL. Strona, która równocześnie próbuje rankować na "SEO audit", "technical SEO", "SEO tools" i "website optimization", nie ma użytecznego celu audytu. Raport może pokazać to rozproszenie jako słabe pokrycie, ale prawdziwy problem leży w briefie.
Dane wejściowe | Dobry punkt startowy | Kontrola jakości | Gdy nie jest jasne |
|---|---|---|---|
URL strony | Kanoniczna, publiczna wersja jednej strony | Ładuje się bez logowania i tokenu podglądu | Użyj URL, do którego powinni trafić użytkownicy i crawlery; rozwiąż przekierowania przed audytem |
Główne słowo kluczowe | Jedna fraza opisująca centralne zadanie strony | Czytelnik oczekuje, że strona na nią odpowie | Zawęź frazę lub wybierz lepiej dopasowaną stronę |
Wspierające słowa kluczowe | Do czterech bliskich wariantów lub podtematów | Każde może naturalnie wystąpić w tym samym planie strony | Usuń niepowiązane frazy zamiast dodawać nowe sekcje, aby je ścigać |
Cel strony | Informować, porównywać, konwertować, rejestrować lub rozwiązywać zadanie | CTA pasuje do intencji wyszukiwania | Przepisz brief strony przed zmianą metadanych |
To przygotowanie zapobiega częstemu błędowi: uznawaniu każdego brakującego użycia frazy za wadę. Jeżeli fraza oznacza inną intencję, należy do innej strony, nowej sekcji o innym celu albo nigdzie.
Ustal brief strony przed uruchomieniem narzędzia. Raport może ujawnić dowody, ale nie zdecyduje, jakie zadanie wyszukiwania ma należeć do URL.
Uruchom audyt z ograniczonym zestawem słów kluczowych
Otwórz narzędzie, wklej publiczny URL i podaj główną frazę wraz z wyłącznie naprawdę powiązanymi frazami. Narzędzie przyjmuje do pięciu słów kluczowych oddzielonych przecinkami. Uruchom audyt i zapisz URL raportu, eksport albo notatki w systemie zadań, dopóki stan strony jest aktualny.
Oczekiwany wynik to raport na poziomie strony, uporządkowany według sygnałów tematycznych, pokrycia słów kluczowych, treści i linków, obrazów, schema oraz metadanych społecznościowych, a także kondycji technicznej i crawl. Sprawdź, czy raport dotyczy dokładnie wybranego URL i fraz.
Jeśli strona przekierowuje, zwraca błąd albo pokazuje inną treść niezalogowanym odwiedzającym, zatrzymaj się. Nie audytujesz strony, którą chcesz zmienić. Przetestuj publiczny URL w oknie prywatnym, napraw uszkodzone przekierowanie, wybierz docelowy canonical albo opublikuj stronę przed audytem. Nie zastępuj strony live podglądem chronionym hasłem.
Audyt zaczyna się od publicznego URL i małego zestawu fraz, a następnie sprawdza dowody treściowe i techniczne na poziomie strony.
Czytaj raport jako dowód, a nie listę zadań
Wynik audytu jest skróconym podsumowaniem, nie prawdopodobieństwem rankingu. Czytaj raport kategoriami i zadawaj węższe pytanie: co pokazuje pobrana strona oraz czy ten dowód wspiera zadanie strony?
Obszar kontroli | Pytanie | Najpierw warto poprawić, gdy | Nie spiesz się z |
|---|---|---|---|
Sygnały tematyczne | Czy title, description, URL, nagłówki i tekst zgadzają się co do tematu strony? | Cel strony trudno rozpoznać z pierwszego ekranu i głównego nagłówka | Powtarzaniem dokładnej frazy w każdym elemencie |
Treść i linki | Czy strona odpowiada na zadanie i prowadzi do kolejnego właściwego zasobu? | Brakuje ważnych pytań lub nawigacja ukrywa użyteczną stronę | Dodawaniem linków wewnętrznych z ogólnym anchorem tylko dla liczby |
Obrazy i zrozumienie | Czy czytelnik rozumie pomocnicze wizuale, łącznie z alt textem? | Istotnemu obrazowi produktu, wykresowi lub grafice instruktażowej brakuje kontekstu | Wpisywaniem list słów kluczowych do altu dekoracyjnej grafiki |
Schema i metadane społecznościowe | Czy dane strukturalne opisują treść, która jest faktycznie widoczna? | Obecny markup jest nieprawidłowy, niedopasowany lub niepełny dla realnego elementu | Dodawaniem FAQ, review lub Product markup dla treści, której nie ma |
Crawl i kondycja techniczna | Czy crawlery mogą dotrzeć do preferowanej strony i odczytać canonical oraz robots? | Dowody canonical, robots, HTTPS lub sitemap są sprzeczne z zamierzoną stroną | Traktowaniem brakującego lub niezweryfikowanego sygnału jako dowodu problemu z indeksem |
Raport powinien oznaczać sygnały, których nie potrafi sprawdzić, zamiast zgadywać. Zachowaj to rozróżnienie w briefie. "Nie znaleziono w pobranym HTML" to trop do poprawy, a nie to samo co "Google nie może crawlować tej strony".
Pracuj z ustaleniami po kolei: zapisz dowód, potwierdź go na stronie live, wprowadź najmniejszą bezpieczną poprawkę i przetestuj wydanie.
Najpierw popraw historię strony, potem szczegóły wyniku
W przypadku większości stron pierwsza przydatna poprawka jest redakcyjna: obietnica i odpowiedź muszą być zgodne. Przeczytaj kolejno title tag, główny nagłówek, pierwszy akapit, główne CTA i dwa pierwsze podnagłówki. Czy nowy odwiedzający potrafi powiedzieć, w czym pomaga strona, bez samodzielnego wypełniania luk?
Wprowadź najmniejszą zmianę, która usuwa niejasność:
- Zastąp niejasny title, taki jak "Lepsze wyniki marketingowe", tytułem wskazującym zadanie i odbiorców.
- Przepisz pierwszy akapit tak, aby zawierał odpowiedź, granicę zakresu i następne działanie.
- Przenieś ważny podtemat pod opisowy nagłówek zamiast zostawiać go w długim bloku tekstu.
- Usuń frazę docelową z audytu, jeśli strona wspomina ją tylko mimochodem.
Rezultatem powinien być plan strony i zestaw metadanych używający tego samego języka intencji bez identycznego powtarzania słów. Dla kontroli jakości przeczytaj tylko title, H1, pierwsze 100-150 słów i CTA. Wszystkie powinny wskazywać to samo zadanie użytkownika. Poproś osobę, która nie pracowała nad stroną, o nazwanie tego zadania. Jeśli odpowie inaczej, problem tematyczny pozostaje.
Nie przepisuj całej strony. Wróć do zdania zapisanego na początku, wybierz jedno zadanie, które powinien posiadać obecny URL, i zacznij od najbardziej widocznych elementów. Dla każdego dodatkowego zamiaru zasługującego na własną stronę przygotuj osobny brief.
Oddziel poprawki treści od poprawek wdrożeniowych
Gdy historia strony jest jasna, podziel resztę raportu według właściciela. Pozwala to uniknąć znanego błędu: zespół SEO prosi engineering o dodanie markupu, zanim ktokolwiek potwierdzi, że widoczna strona zawiera fakty, które markup ma opisywać.
Właściciel | Praca z raportu | Definicja gotowości |
|---|---|---|
Właściciel treści lub SEO | Title i description, nagłówki, pokrycie treści, kontekst linków wewnętrznych, alt istotnych obrazów | Zmieniony tekst odpowiada wybranej intencji, a każde twierdzenie można poprzeć na stronie |
Developer | Canonical, dyrektywy robots, HTTPS, poprawność schema, dowody renderowania lub crawl | Wdrożenie pasuje do opublikowanej strony i zostało przetestowane na produkcji |
Wspólny recenzent | Metadane społecznościowe, fakty o produkcie, twierdzenia prawne, język konwersji, notatki wydania | Podgląd odpowiada stronie publicznej i żadna zmiana nie tworzy sprzecznej obietnicy |
Traktuj dane strukturalne jako warstwę opisu, a nie łatę na ubogą treść. Jeśli raport wykryje problem ze schema, najpierw poszukaj odpowiadającego mu widocznego dowodu. Typ Product potrzebuje faktów o produkcie, a FAQ markup - prawdziwych, widocznych pytań i odpowiedzi. Jeśli dowodów nie ma, popraw stronę albo usuń nieodpowiedni markup. Nie twórz treści tylko po to, aby zaliczyć kontrolę.
Zamień ustalenia w brief pięciu poprawek
Długie raporty potrafią sprawić, że małe zadania wyglądają na pilne. Ogranicz pierwsze podejście do pięciu zmian. Każdej przypisz powód, właściciela i metodę weryfikacji.
Priorytet | Ustalenie | Proponowana zmiana | Właściciel | Weryfikacja po wydaniu |
|---|---|---|---|---|
1 | H1 nie nazywa głównego zadania strony | Przepisz H1 i odpowiedź otwierającą | Treść | Przeczytaj wyrenderowaną stronę; uruchom audyt ponownie |
2 | Canonical wskazuje przestarzały URL | Zaktualizuj canonical do preferowanego URL live | Developer | Sprawdź wyrenderowany source i dowód z audytu |
3 | Wykres porównawczy nie ma alt textu | Dodaj zwięzły alt wyjaśniający decyzję z wykresu | Treść | Przetestuj stronę narzędziem dostępności i audytem |
4 | Schema opisuje fakty, których już nie widać | Zaktualizuj lub usuń przestarzałą schema | Developer | Zweryfikuj markup względem opublikowanej strony |
5 | Użyteczny poradnik wspierający jest trudny do znalezienia | Dodaj jeden kontekstowy link wewnętrzny przy właściwej decyzji | Treść | Sprawdź cel linku, anchor text i podgląd strony |
Dokładne ustalenia będą różne dla każdej strony. Chodzi o uporządkowanie poprawek według tego, jak bezpośrednio poprawiają jasność, dostęp lub dokładność tej strony. Zmiany spekulatywne zostaw na kolejny backlog. Nie musisz wyczyścić wszystkich kategorii ostrzeżeń w jednym wydaniu.
Publikuj bezpiecznie, potem uruchom ten sam audyt ponownie
Opublikuj uzgodnione zmiany zwykłym procesem review. Sprawdź stronę live, nie tylko podgląd CMS. Obejrzyj source lub użyj narzędzi walidacji technicznej, gdy zmiana zależy od HTML, nagłówków albo danych strukturalnych.
Następnie uruchom ponownie ten sam URL i zestaw słów kluczowych. Porównuj dowody, nie tylko wynik podsumowania:
- Czy title, H1 i otwarcie jasno komunikują teraz zadanie strony?
- Czy canonical, robots, schema, linki i atrybuty obrazów zaktualizowały się w wersji live?
- Czy przepisanie nie usunęło faktów, zastrzeżeń lub ścieżek konwersji, których strona nadal potrzebuje?
- Czy pozostałe ostrzeżenia są zamierzone, poza zakresem dowodów narzędzia albo należą do kolejnego cyklu napraw?
Definicja ukończenia: strona publiczna odzwierciedla zaakceptowany brief, naprawione sygnały są widoczne w dowodach pobranej strony, a każdy nierozwiązany punkt ma nazwany powód albo kolejnego właściciela. Nie uznawaj zadania za gotowe tylko dlatego, że wynik się zmienił, jeśli podstawowa strona nadal wprowadza w błąd.
Zachowaj przydatność raportu po publikacji
Uruchamiaj audyt on-page po dużym przepisaniu strony, zmianie szablonu, migracji, redesignie lub raporcie pokazującym wyraźną niezgodność między aktualną intencją strony a widocznymi sygnałami. W przypadku stabilnej strony używaj raportu w rutynowym przeglądzie treści, a nie codziennie.
Łącz go ze źródłami odpowiadającymi na inne pytania. Search Console pomaga zobaczyć skuteczność w wyszukiwarce i wzorce zapytań. Techniczny crawl może ujawnić wzorce wdrożeniowe w skali witryny. Badanie SERP sprawdza, czy strona odpowiada bieżącym oczekiwaniom szukających. Audyt Auspia dodaje skupiony widok tego, co jedna strona publiczna naprawdę komunikuje przez dostępny HTML i treść.
Najczęstsze pytania
Czy wysoki wynik audytu on-page SEO gwarantuje pozycje?
Nie. Wynik odzwierciedla sygnały gotowości na poziomie strony, a nie prawdopodobieństwo rankingu. Backlinki, konkurencja, popyt na wyszukiwanie, pokrycie indeksu, satysfakcja użytkownika i systemy wyszukiwarek są poza zakresem raportu.
Ile słów kluczowych należy wpisać?
Zacznij od jednej głównej frazy. Dodawaj tylko bliskie warianty lub podtematy, na które strona ma uzasadniony powód odpowiadać. Narzędzie przyjmuje do pięciu słów kluczowych, ale większa liczba danych wejściowych nie czyni audytu dokładniejszym.
Czy należy naprawić każdy problem z raportu?
Nie. Zacznij od dowodów wpływających na jasność strony, dostępność, dokładność lub crawlability. Elementy celowe albo o małym wpływie zostaw w udokumentowanym backlogu. Wymuszona poprawka może pogorszyć stronę.
Czy mogę użyć audytu dla strony, która nie jest jeszcze publiczna?
Nie. Narzędzie audytuje URL strony publicznej. Opublikuj bezpieczną wersję albo korzystaj ze stagingu i kontroli przed wydaniem dla stron wymagających uwierzytelnienia.
Autor: Julian Mercer, praktyk Technical SEO w Auspia z 14-letnim doświadczeniem. Julian pisze o crawlability, danych strukturalnych i praktycznych poprawkach na poziomie strony, które zespoły mogą zweryfikować.
