Audyt bazowy techniczny

Faza P2 · Etap A — Zrozumienie
Ramka czasowa: 2–4 godzin na lekki przegląd, 1–2 dni robocze na standardowy przegląd lub 3–8 dni roboczych na dogłębny przegląd.
Właściciel: lider techniczny SEO. Działy inżynierii, analityki, treści i lokalizacji dostarczają dowody i akceptują poprawki w swoich obszarach.

Audyt bazowy techniczny określa, czy wyszukiwarki mogą dotrzeć do adresów URL, które firma oczekuje, że będą wyświetlane, zinterpretować je i wybrać. Jego zakres obejmuje kontrole crawlowania, odpowiedzi HTTP, indeksację, kanonikale, linki, renderowanie, targetowanie międzynarodowe i bezpieczne dostarczanie. Wynikiem jest priorytetyzowany rejestr ustaleń z nazwanymi właścicielami i testami akceptacyjnymi, a nie ocena punktowa.

Dlaczego ta faza pojawia się tutaj

Publikowanie treści na stronie z problemami crawlowania lub indeksacji pogłębia szkody. Wyszukiwarki często szybciej wykrywają powtarzający się defekt w nowych adresach URL, niż oceniają i nagradzają treść. Uszkodzony szablon kanoniczny może kierować każdy artykuł gdzie indziej; reguła robots.txt może ukryć katalog; nawigacja renderowana po stronie klienta może tworzyć sieroty dla klienta bez JavaScript. Każda nowa strona powiększa zestaw dotkniętych problemem i utrudnia naprawę.

Najpierw napraw fundamenty. Kolejność to crawlability → indeksowalność → jakość treści → wydajność, ponieważ każda warstwa jest bramą. Crawlability oznacza, że crawler może odkryć i zażądać adresu URL; indeksowalność oznacza, że osiągalny adres URL kwalifikuje się do włączenia. Dopiero wtedy należy oceniać jakość treści i wydajność. Szybka strona zablokowana przez robots.txt nie może konkurować, a tagi tytułowe nie mają znaczenia na stronach nieosiągalnych.

Ta faza wykorzystuje zakres, priorytetowe ścieżki, rynki i ryzyka z fazy Odkrywanie i cele . Wcześniejsze jej uruchomienie daje crawling bez kontekstu biznesowego. Pominięcie jej powoduje, że badania i produkcja celują w szablony, które nie mogą niezawodnie trafić do indeksu.

Wejścia i wyjścia

Wejścia definiują zamierzoną witrynę, a nie tylko to, co znajdzie crawler. Wyjścia informują kolejnego właściciela, które adresy URL są bezpieczne do testowania, a które pozostają zablokowane.

Wybierz głębokość audytu

Wybierz głębokość przed crawlowaniem. Szacunki zakładają gotowy dostęp i wykluczają implementację.

Lista kontrolna

Pracuj w kolejności. Nieudana brama może unieważnić późniejsze próbki, więc zapisz niepowodzenie i jego zakres przed kontynuowaniem.

1. Potwierdź, że cel to środowisko produkcyjne

Co robić: zweryfikuj schemat, host, plik robots, właściwość analityki, właściwość Search Console i host mapy witryny. Dlaczego to ważne: środowisko staging może wyglądać czysto, podczas gdy produkcja pozostaje uszkodzona. Jak to zrobić: rozpoznaj uzgodniony host kanoniczny, porównaj priorytetowe strony i nagłówki odpowiedzi oraz zapisz źródło crawlowania. Narzędzie: przeglądarka, konfiguracja crawlera, selektor Search Console. Gotowe, gdy: rejestr wymienia potwierdzone źródło produkcyjne i właściwość, bez hosta staging w seedach lub eksportach.

2. Przetestuj robots.txt przed crawlowaniem

Co robić: sprawdź /robots.txt każdego hosta produkcyjnego i wskazane w nim mapy witryny. Dlaczego to ważne: reguła Disallow uniemożliwia crawlowanie, zanim treść może zostać oceniona. Jak to zrobić: porównaj wzorce Disallow z zamierzonym spisem URL, przetestuj pasujące i niepasujące adresy URL oraz odróżnij blokadę crawlowania od noindex. Narzędzie: surowa odpowiedź i tester robots. Gotowe, gdy: robots zwraca 200, zamierzone blokady mają powody, indeksowalne próbki są dozwolone, a jedna niezamierzona blokada wyzwala krytyczne ustalenie.

3. Uzgodnij mapy witryny z rzeczywistymi adresami URL

Co robić: porównaj przesłane mapy witryny z kanonicznym, indeksowalnym spisem URL. Dlaczego to ważne: mapa witryny powinna wymieniać adresy URL, które witryna chce wybrać, a nie przekierowania, błędy lub duplikaty. Jak to zrobić: znormalizuj wpisy, porównaj liczby według szablonu, a następnie próbkuj dodania i pominięcia w Mapy witryny i indeksowanie . Narzędzie: https://app.amicited.com/reports/google-search/sitemaps-indexing i eksporty crawl. Gotowe, gdy: pokrycie wynosi co najmniej 95%, 0 wpisów przekierowuje lub błędów, a każda luka ma powód lub właściciela.

4. Zmierz rozkład kodów statusu

Co robić: sklasyfikuj odpowiedzi jako 2xx, 3xx, 4xx lub 5xx. Dlaczego to ważne: błędy zatrzymują pobieranie, a przekierowania dodają skoki. Jak to zrobić: śledź i raportuj przekierowania, segmentuj według szablonu i porównuj z Crawling Bing . Narzędzie: https://app.amicited.com/reports/bing-webmasters/crawl, crawler i monitoring. Gotowe, gdy: indeksowalne adresy URL zwracają 200; wewnętrzne błędy, pętle i łańcuchy wynoszą zero; a zamierzone przekierowania są udokumentowane.

5. Usuń łańcuchy i pętle przekierowań

Co robić: prześledź przekierowania do ich końcowej odpowiedzi. Dlaczego to ważne: skoki spowalniają odkrywanie; pętla nigdy nie dociera do treści. Jak to zrobić: wyeksportuj ścieżki, zaktualizuj linki wewnętrzne do końcowych kanonikali i skonsoliduj reguły. Narzędzie: raport przekierowań i sprawdzanie nagłówków. Gotowe, gdy: linki wewnętrzne prowadzą bezpośrednio, starsze przekierowania wykonują jeden skok, a żadna pętla ani łańcuch nie pozostaje.

6. Ustal kwalifikowany wskaźnik indeksacji

Co robić: porównaj stan indeksu Google z celowo kwalifikującymi się adresami URL. Dlaczego to ważne: uwzględnienie przekierowań, filtrów, duplikatów lub stron noindex powoduje, że wskaźnik traci znaczenie. Jak to zrobić: zbuduj kwalifikowany mianownik, sprawdź priorytetowe próbki w Inspekcja URL , pogrupuj wykluczenia według szablonu. Narzędzie: https://app.amicited.com/reports/google-search/url-inspection, Search Console i spis URL. Gotowe, gdy: co najmniej 90% jest zindeksowanych lub każda luka ma właściciela przyczyny źródłowej; poniżej 80% to poważne ustalenie.

7. Zweryfikuj poprawność kanonikali

Co robić: porównaj zadeklarowane, końcowe i wybrane przez Google kanonikale. Kanonikal to preferowana wersja spośród podobnych adresów URL. Dlaczego to ważne: błędny kanonikal konsoliduje sygnały poza zamierzoną stronę. Jak to zrobić: przetestuj samoodniesienia unikalnych stron, celowe krzyżowe kanonikale i spójność w HTML, mapach witryny, przekierowaniach i linkach. Narzędzie: raport kanonikali i https://app.amicited.com/reports/google-search/url-inspection. Gotowe, gdy: 100% unikalnych indeksowalnych stron wskazuje jeden bezwzględny, 200, indeksowalny kanonikal, a każda wybrana niezgodność jest wyjaśniona.

8. Znajdź klastry duplikatów i prawie duplikatów

Co robić: grupuj adresy URL z identyczną lub znacząco pokrywającą się główną treścią i tym samym celem wyszukiwania. Dlaczego to ważne: duplikaty rozdzielają sygnały wewnętrzne i zmuszają wyszukiwarki do wyboru wersji, której firma może nie preferować. Jak to zrobić: porównaj dokładne skróty, znormalizowane podobieństwo tekstu, tytuły, kanonikale, parametry i cel szablonu; następnie wybierz konsolidację, zróżnicowanie, noindex lub usunięcie. Narzędzie: raporty duplikatów crawlera, spis stron i Strony Google Search . Gotowe, gdy: żaden klaster nie zawiera więcej niż jednego niewyjaśnionego kanonicznego indeksowalnego URL służącego temu samemu zamiarowi, a każda zaakceptowana wariant ma zapisany odrębny cel.

9. Znajdź sieroty i zmierz głębokość linkowania

Co robić: połącz adresy URL z crawlera z mapami witryny, analityką, Search Console, eksportami CMS i linkami zwrotnymi, aby znaleźć strony bez crawlowalnego linku wewnętrznego. Zmierz najkrótszą ścieżkę kliknięć ze strony głównej. Dlaczego to ważne: sierota może pojawić się w mapie witryny, a mimo to otrzymywać mało kontekstu wewnętrznego i autorytetu; nadmierna głębokość sprawia, że odkrywanie jest kruche. Jak to zrobić: porównaj źródła, sprawdź wzorce katalogów w Widok katalogu , prześledź nawigację, breadcrumbs, huby i linki kontekstowe. Narzędzie: https://app.amicited.com/reports/directory i wieloźródłowe crawlowanie. Gotowe, gdy: zamierzona liczba sierot wynosi zero, priorytetowe strony są w zasięgu trzech kliknięć ze strony głównej, inne zamierzone indeksowalne strony w zasięgu pięciu, a każdy wyjątek ma celową ścieżkę odkrycia.

10. Porównaj HTML renderowany i bez JavaScript

Co robić: porównaj początkową odpowiedź serwera ze stroną po wykonaniu JavaScript. Dlaczego to ważne: przeglądarka może wyświetlić treść i linki, których klient bez JavaScript nigdy nie otrzymuje. Jak to zrobić: pobierz reprezentatywne strony z wyłączonymi skryptami, sprawdź surowy HTML, a następnie porównaj nagłówki, główną treść, linki, kanonikal, dyrektywy robots, dane strukturalne i status po renderowaniu. Narzędzie: crawler w trybie HTML i renderowanym oraz narzędzia deweloperskie przeglądarki. Gotowe, gdy: początkowa odpowiedź zawiera podstawową treść, kanonikal, dyrektywy indeksowania i crawlowalną nawigację niezbędną do odkrycia priorytetowych stron; każda zależność wyłącznie od JavaScript jest wyraźnie zaakceptowana i przetestowana we wszystkich szablonach.

11. Zweryfikuj hreflang tam, gdzie ma zastosowanie

Co robić: zweryfikuj adnotacje łączące odpowiedniki językowe lub regionalne. Dlaczego to ważne: niekompletne lub sprzeczne klastry mogą sprawić, że wyszukiwarki zignorują targetowanie i pokażą niewłaściwą wersję rynkową. Jak to zrobić: przetestuj prawidłowe kody język-region, bezwzględne kanoniczne adresy URL, samoodniesienia, wzajemne linki zwrotne, x-default tam, gdzie pełni rzeczywistą rolę fallbacka, oraz indeksowalność każdego celu. Narzędzie: raport hreflang crawlera i próbki URL. Gotowe, gdy: nieprawidłowe kody, brakujące samoodniesienia, brakujące zwroty, niekanoniczne cele, przekierowania i błędy wynoszą zero. Jeśli witryna nie ma zlokalizowanych odpowiedników, zapisz „nie dotyczy” zamiast wymyślać adnotacje.

12. Przetestuj paginację i ścieżki crawlowania

Co robić: zweryfikuj, że wielostronicowe sekcje kategorii lub archiwów udostępniają crawlowalne linki i użyteczne unikalne adresy URL. Dlaczego to ważne: nieskończone przewijanie lub ładowanie tylko przyciskiem może ukryć głębsze elementy, podczas gdy kanonikalizowanie każdej strony do pierwszej może usunąć odrębny asortyment z odkrywania. Jak to zrobić: wyłącz JavaScript, podążaj za linkami „następna” i numerowanymi, sprawdź status, kanonikal i dyrektywy robots oraz przetestuj ostatnią stronę i parametry poza zakresem. Narzędzie: crawlowanie bez renderowania i przeglądarka. Gotowe, gdy: każdy zamierzony element jest osiągalny przez linki kotwiczące, każda użyteczna strona samokanonikalizuje się, nieprawidłowe numery stron zwracają odpowiedni błąd zamiast miękkiego 200, a żadna sekwencja nie tworzy nieograniczonej przestrzeni URL.

13. Sprawdź parytet mobilny

Co robić: porównaj dostarczanie treści mobilnej i desktopowej pod kątem treści, linków, metadanych, dyrektyw, danych strukturalnych i statusu odpowiedzi. Dlaczego to ważne: Google ocenia przede wszystkim reprezentację mobilną; ukrywanie znaczących treści lub linków tylko na urządzeniach mobilnych zmienia to, co może zrozumieć. Jak to zrobić: crawlowanie z agentami użytkownika desktop i smartphone oraz porównanie reprezentatywnych szablonów, nie tylko wizualnych zrzutów ekranu. Narzędzie: sparowane crawlowa, mobilna inspekcja URL i tryb responsywny przeglądarki. Gotowe, gdy: wszystkie indeksowalne treści i crawlowalne linki wymagane do znaczenia i odkrywania są równoważne, z zerową liczbą blokad tylko mobilnych, różnic kanonicznych lub odpowiedzi błędów.

14. Wymuś HTTPS i usuń mieszaną treść

Co robić: zweryfikuj bezpieczne dostarczanie, przekierowania hosta, certyfikaty, schemat kanoniczny, wewnętrzne adresy URL i zasoby ładowane przez HTTP. Mieszana treść oznacza, że strona HTTPS żąda niezabezpieczonego zasobu. Dlaczego to ważne: niezabezpieczone żądania mogą być blokowane, narażać użytkowników i tworzyć niespójne sygnały URL. Jak to zrobić: scrawlowanie wszystkich wariantów HTTP, sprawdzenie pokrycia certyfikatów i błędów bezpieczeństwa przeglądarki oraz przeszukanie żądań zasobów po renderowaniu. Narzędzie: crawler, panel bezpieczeństwa przeglądarki i konfiguracja serwera. Gotowe, gdy: każda strona HTTP przekierowuje raz do pasującego adresu HTTPS, wszystkie kanonikale i linki wewnętrzne używają HTTPS, certyfikaty są ważne dla każdego działającego hosta, a żądania mieszanej treści aktywnej lub pasywnej wynoszą zero.

Narzędzia w AmICited

Używaj raportów produktowych jako dowodu na liście kontrolnej, a nie jako zamiennika crawlowania.

• Mapy witryny i indeksowanie pod adresem https://app.amicited.com/reports/google-search/sitemaps-indexing pokazuje stan przesłanych map witryny, ostrzeżenia, błędy i działania indeksujące.
• Inspekcja URL pod adresem https://app.amicited.com/reports/google-search/url-inspection przedstawia na żywo werdykt Google dla próbkowanych adresów URL i wybrany kanonikal.
• Crawling Bing pod adresem https://app.amicited.com/reports/bing-webmasters/crawl ujawnia aktywność crawlera Bing i problemy na poziomie URL.
• Strony Google Search pod adresem https://app.amicited.com/reports/pages pomaga wybrać wartościowe strony docelowe i oddziela strony z widocznością od stron nieobecnych w danych wyszukiwania.
• Widok katalogu pod adresem https://app.amicited.com/reports/directory ujawnia wzorce na poziomie sekcji i wspiera badanie głębokości oraz sierot.
• Jakość danych pod adresem https://app.amicited.com/features/data-health/ rejestruje, czy podłączone dowody są wystarczająco kompletne, aby wspierać pewne decyzje.

Zasady decyzyjne

Progi tworzą ustalenia; nie zastępują osądu. Segmentuj według szablonu i ważności biznesowej: dziesięć awarii kategorii koszyka może mieć większe znaczenie niż tysiąc uszkodzonych tagów archiwum.

Priorytetyzuj za pomocą wpływ × nakład × pewność. Oceń wpływ od 1–5 na podstawie dotkniętych kwalifikujących się adresów URL i ścieżek biznesowych. Oceń nakład od 1–5 jako czynnik łatwości, gdzie 5 oznacza małą, odwracalną zmianę, a 1 duży ryzykowny program; zapisz też uczciwe oszacowanie w godzinach lub dniach. Oceń pewność jako 0,5 dla prawdopodobnej hipotezy, 0,75 dla powtarzających się dowodów lub 1,0 dla odtworzonej przyczyny źródłowej. Iloczyn daje pomoc w ustalaniu kolejności, a nie fałszywą precyzję.

Zastosuj nadrzędność zależności: poprawka, która odblokowuje inną pracę, ma priorytet nad wyższym wynikiem, który tego nie robi. Usunięcie blokady robots przed uruchomieniem jest ważniejsze niż polerowanie zindeksowanych tagów tytułowych. Na tym samym poziomie zależności rozwiązuj przyczyny na poziomie szablonu przed objawami.

Produkt końcowy: priorytetyzowany rejestr ustaleń

Przekaż jeden wspólny rejestr, a nie eksport crawlera. Użyj jednego wiersza na przyczynę źródłową i dołącz próbki URL osobno.

Rejestr jest kompletny, gdy krytyczne i poważne ustalenia mają właścicieli i oszacowania, blokery mają sekwencję, hipotezy są oznaczone, a decyzja o publikowaniu jest jednoznaczna.

Co idzie nie tak

Raport 200 elementów, na który nikt nie może zareagować

Eksporty crawlera mylą obserwacje z decyzjami. Grupuj powtarzające się adresy URL pod szablonem lub regułą, która je powoduje, podaj reprezentatywną próbkę i przypisz jednego właściciela. Dwieście uszkodzonych adresów URL wygenerowanych przez jeden komponent nawigacji to jedno ustalenie przyczyny źródłowej z mierzalnym zakresem, a nie dwieście zadań.

Raportowanie objawów zamiast przyczyn

„Strona nie jest indeksowana” to objaw. Przyczyną może być niezamierzony kanonikal, osierocony szablon, cienkie warianty parametrów, błąd mobilny lub link dostępny tylko przez JavaScript. Ustalenie nie jest gotowe do priorytetyzacji, dopóki nie zidentyfikuje kontrolowanej przyczyny lub wyraźnie nie oznaczy następnego testu diagnostycznego.

Audytowanie stagingu przez przypadek

Staging może mieć inne reguły robots, uwierzytelnianie, dane, szablony, flagi funkcji i zachowanie hosta. Zapisz źródło produkcyjne i właściwość Search Console na górze każdego eksportu. Jeśli crawlowanie musi być uruchomione na stagingu w celu zapewnienia jakości wydania, oznacz je jako osobne porównanie i nigdy nie łącz jego metryk z bazą produkcyjną.

Unikaj także liczenia celowych wykluczeń jako strat, traktowania obecności w mapie witryny jako dowodu indeksowania, testowania tylko strony głównej lub priorytetyzacji tylko według liczby URL. Zdefiniuj kwalifikujący się zbiór, segmentuj według szablonu i zachowaj dowody akceptacji.

Następna faza

Następna faza, Dostępność AI i gotowość dla agentów , potrzebuje technicznie stabilnej próbki. Przekaż zamierzony indeksowalny spis URL, czyste reprezentatywne adresy URL dla każdego priorytetowego szablonu, porównania surowego i renderowanego HTML, dowody robots i odpowiedzi, decyzje kanoniczne, znane wykluczenia i rejestr otwartych ustaleń.

Nie twierdź, że witryna jest „technicznie zdrowa”. Określ, które szablony przeszły bramy crawlowania i indeksu, które pozostają zablokowane i czy publikowanie może być kontynuowane. Następny właściciel akceptuje, gdy może testować agentów użytkownika AI i ekstrakcję bez ponownego odkrywania nierozwiązanych defektów crawlowania w wyszukiwarkach.

FAQ

Jak często należy powtarzać audyt bazowy techniczny?

Przeprowadź go przed migracją, przeprojektowaniem, zmianą domeny lub dużym programem publikacyjnym, a następnie powtórz odpowiednie kontrole po wdrożeniu. Monitoruj stale i powtórz standardowy przegląd, gdy zmienią się szablony, nawigacja, renderowanie lub reguły kanoniczne.

Jaki wskaźnik indeksacji powinna mieć zdrowa witryna?

Dla celowo kwalifikujących się adresów URL 90% lub więcej to wyjściowe oczekiwanie, 80–90% wymaga wyjaśnienia, a poniżej 80% stanowi ustalenie. Wyklucz z mianownika przekierowania, duplikaty, filtry i celowe strony noindex.

Czy możemy publikować treści, gdy trwają poprawki techniczne?

Tylko wtedy, gdy nowe adresy URL są crawlowalne, indeksowalne, skanonikalizowane, wewnętrznie linkowane i nienaruszone przez defekt. Jeśli odkrywanie lub selekcja jest zablokowana, wstrzymaj; nowe adresy URL tylko powiększają obszar do posprzątania.

Czy potrzebujemy crawlera, jeśli podłączyliśmy Search Console?

Tak. Search Console raportuje to, co zaobserwował Google; crawler testuje bieżącą witrynę i ujawnia linki, odpowiedzi, głębokość, kanonikale i duplikaty. Żaden nie zastępuje drugiego.

Kto jest właścicielem poprawek znalezionych w audycie?

Lider SEO jest właścicielem rejestru i kryteriów akceptacji. Dział inżynierii zwykle odpowiada za poprawki serwera, renderowania, przekierowań, kanonikali i HTTPS; zespół treści może odpowiadać za duplikację i linkowanie. Każda pozycja potrzebuje jednej wskazanej osoby.