Lista kontrolna SEO QA przed publikacją

Kontrola jakości (QA) przed publikacją to ostateczna bramka wydania w procesie SEO . To miejsce, gdzie spotykają się trzy umowy: zgodność z typem wpisu, poprawne użycie elementów oraz ukończenie prac badawczych, dowodowych, implementacyjnych i przeglądowych. Strona, która nie spełnia któregokolwiek z mających zastosowanie kryteriów, wraca do poprawy.

Bramka: końcowe QA przed publikacją. Limit czasu: 60–90 minut dla standardowej strony; dodaj czas specjalisty dla regulowanych, dotyczących bezpieczeństwa, finansów, medycyny lub technicznie istotnych twierdzeń. Właściciel: jeden redaktor, lider treści lub lider SEO, który nie dokonał finalnej implementacji i ma uprawnienia do blokowania wydania.

Miękka lista kontrolna nie jest listą kontrolną, ponieważ „prawie zrobione" nie ma stabilnego znaczenia. Pod presją terminu opcjonalne sformułowania stają się pomocą pamięciową, a trudne kontrole znikają. Wyznacz osobę upoważnioną do wydania przed rozpoczęciem QA. Właściciel QA może zaliczyć lub oblać; tylko wyznaczony szef treści, lider SEO lub odpowiednik może zatwierdzić pisemny wyjątek lub uznać element za niemający zastosowania. Nie mogą oni odstąpić od fałszywego twierdzenia, brakującego wymaganego elementu, podstawowego zasobu, uszkodzonego kanonika ani zablokowanej indeksowalności, aby dotrzymać terminu.

Dlaczego ta bramka istnieje i dlaczego działa tutaj

Ta bramka wykorzystuje zatwierdzoną specyfikację typu wpisu, kontrakty elementów, rejestr źródeł, ostateczną kopię, zaimplementowanego kandydata i zatwierdzenia specjalistów. Działa po zamrożeniu tych danych wejściowych, ponieważ QA nie może weryfikować ruchomego celu, i przed publikacją, ponieważ wada może zostać skopiowana zaraz po udostępnieniu URL-a.

Wcześniejsze QA potwierdza wersję roboczą, która może ulec zmianie. Pominięcie go pozostawia późniejszych audytorów niezdolnych do odróżnienia dryfu strony, zmienionej specyfikacji i strony nigdy nie sprawdzanej. QA po publikacji zamienia tanie poprawki w publiczne wady.

Dane wejściowe i wyjściowe

Wynik to umowa, a nie wiadomość na czacie. Wydawca musi być w stanie na niej działać bez rekonstrukcji przeglądu.

Lista kontrolna

Każdy poniższy element zawiera działanie, powód, metodę, narzędzie i obserwowalny warunek ukończenia. „Sprawdzone SEO" lub „wygląda dobrze" nigdy nie jest akceptowalnym dowodem.

1. Zgodność z typem wpisu

Potwierdź wybrany typ wpisu i zakres. Co: dopasuj kandydata do jednego wpisu w bibliotece typów wpisów i usuń materiał należący do typu pokrewnego. Dlaczego: typ strony określa intencję, strukturę, dowody i zachowanie konwersji. Jak: oznacz każdą sekcję decyzją czytelnika, którą wspiera, i porównaj z celem i wykluczeniami typu. Narzędzie: zatwierdzony brief, mapa tematyczna i strony typów wpisów. Zrobione, gdy: dokładnie jeden typ podstawowy jest odnotowany, wstęp, treść i CTA mu służą, a żadna sekcja nie istnieje wyłącznie dla zadania innego typu.

Prześledź wymaganą strukturę i przedziały słów. Co: zmapuj każdą wymaganą sekcję do wyrenderowanego kandydata i policz słowa względem określonego przedziału. Dlaczego: brakujące sekcje tworzą pytania bez odpowiedzi, a niekontrolowana długość ukrywa luki za objętością. Jak: użyj macierzy wymaganie–nagłówek i zautomatyzowanych liczników, a następnie ręcznie sprawdź przypadki graniczne. Narzędzie: specyfikacja typu wpisu, źródło i wyrenderowana strona. Zrobione, gdy: żadna wymagana sekcja nie brakuje, a każda sekcja mieści się w określonym minimum i maksimum.

2. Zgodność elementów

Zweryfikuj elementy, pozycje i parametry. Co: porównaj mapę elementów ze źródłem i renderem. Dlaczego: pozycja i pola są częścią funkcji; zakopana bezpośrednia odpowiedź już nie odpowiada pierwsza, a źle sformowane parametry mogą zepsuć wynik. Jak: sprawdzaj od góry do dołu i waliduj dozwolone pola, wartości, zagnieżdżenie i składnię. Narzędzie: specyfikacje elementów, walidator i przeglądarka. Zrobione, gdy: każdy obowiązkowy element jest na swojej wymaganej pozycji, każdy parametr jest prawidłowy i nie ma niewyjaśnionych duplikatów.

Wymuszaj pierwszeństwo typowanych elementów. Co: zastosuj zasady pisania elementów wszędzie tam, gdzie fragment ma zarejestrowany cel. Dlaczego: wolny tekst może wyglądać podobnie, ale nie niesie tożsamości komponentu, pól, zachowania dostępności ani ustrukturyzowanego wyniku. Jak: określ zadanie każdego bloku jako czasownik — definiuj, ostrzegaj, porównuj, instruuj, podsumowuj — i sprawdź, czy istnieje pasujący element. Narzędzie: biblioteka elementów i inspektor źródła. Zrobione, gdy: żaden fragment nie używa wolnego tekstu tam, gdzie typowany element jest obowiązkowy.

3. Jakość treści

Przetestuj odpowiedź w izolacji. Co: przeczytaj blok bezpośredniej odpowiedzi bez nagłówka i otaczających akapitów. Dlaczego: systemy wyszukiwania i ekstrakcji AI mogą wyodrębnić tylko ten fragment. Jak: sprawdź, czy nazywa temat, odpowiada na pytanie, zawiera niezbędne zastrzeżenia i nie polega na „to", „ono" lub „jak wyżej". Narzędzie: widok izolowanego tekstu i ludzki recenzent. Zrobione, gdy: odpowiedź jest samodzielna, dokładna i mieści się w określonym przedziale 40–60 słów, gdy ten element jest wymagany.

Zweryfikuj twierdzenia, język i unikalność. Co: prześledź istotne twierdzenia do dowodów, wyjaśnij żargon przy pierwszym użyciu i porównaj kandydata ze stronami służącymi tej samej intencji. Dlaczego: niepoparte twierdzenia niszczą zaufanie, a prawie-duplikaty konkurują i dryfują. Jak: oznacz nazwy, daty, liczby, twierdzenia przyczynowe, zachowanie produktu i podobne kandydatury; wspieraj, kwalifikuj, konsoliduj lub usuwaj je. Narzędzie: rejestr dowodów, źródła pierwotne, wyszukiwanie w witrynie i raport podobieństwa. Zrobione, gdy: żadne istotne twierdzenie nie jest pozbawione wsparcia, żaden termin specjalistyczny nie pozostaje niewyjaśniony, a żadna istniejąca strona nie odpowiada na tę samą intencję i zakres bez planu konsolidacji.

4. Frontmatter

Waliduj pola tożsamości i podglądu. Co: zastosuj specyfikację frontmatter do tytułu, opisu, słów kluczowych, entity i powiązań typu wpisu. Dlaczego: te pola sterują routingiem, podglądami, schematami i relacjami bez czytania treści. Jak: uruchom walidację pól i długości, a następnie porównaj znaczenie z widoczną stroną. Narzędzie: linter frontmatter i ludzki podgląd. Zrobione, gdy: tytuł jest unikalny i dokładny, opis ma 150–160 znaków, słowa kluczowe zawierają 6–8 odpowiednich pozycji, a entity pasuje do kontraktu typu wpisu.

Zweryfikuj pola zarządzania i FAQ. Co: sprawdź daty, autora, recenzenta, własność i widoczną strukturę FAQ względem frontmatter. Dlaczego: anonimowe rekordy uniemożliwiają odpowiedzialność, a dryf FAQ powoduje rozbieżność między widocznymi a ustrukturyzowanymi odpowiedziami. Jak: porównaj pola ze śladem wydania i znormalizowanym widocznym tekstem. Narzędzie: parser źródła, tracker i wyrenderowana strona. Zrobione, gdy: wymagane daty i właściciele są prawidłowe, recenzent jest wymieniony tam, gdzie wymagane, liczba FAQ spełnia minimalne wymagania typu, każda para jest zgodna i nie ma ukrytych ani pustych wpisów.

5. Dane strukturalne

Wymagaj prawidłowego schematu. Co: potwierdź, że istnieje odpowiednie oznaczenie schematu dla strony i jej widocznych elementów. Dlaczego: brakujące lub ogólne oznaczenia odrzucają czytelne maszynowo znaczenie, które model treści już zapewnia. Jak: porównaj emitowane typy i właściwości z kontraktami typu wpisu i elementów. Narzędzie: wyrenderowany HTML i walidator schematów. Zrobione, gdy: każdy wymagany typ schematu występuje raz, wymagane właściwości są wypełnione, a żaden niemający zastosowania typ nie jest emitowany.

Waliduj parytet, nie tylko składnię. Co: porównaj nazwy, daty, autora, encję, FAQ, kroki i twierdzenia ze schematu z widoczną treścią. Dlaczego: prawidłowa składnia może nadal opisywać niewidoczne lub sprzeczne informacje. Jak: waliduj JSON-LD, a następnie porównaj wartości ze stroną. Narzędzie: test danych strukturalnych i ludzki przegląd. Zrobione, gdy: nie ma żadnych błędów ani żadnych faktów w schemacie, które zaprzeczają lub wykraczają poza widoczną treść.

6. Linkowanie wewnętrzne

Linkuj w górę i na zewnątrz. Co: zapewnij ścieżkę do odpowiedniego filaru i kontekstowe ścieżki do powiązanych węzłów. Dlaczego: hierarchia pomaga czytelnikom i przeszukiwaczom zrozumieć, gdzie strona się znajduje, podczas gdy linki boczne kontynuują zadanie czytelnika. Jak: zmapuj każdy link wewnętrzny na autentyczne następne pytanie, zamiast wypełniać limit. Narzędzie: graf linków i wyrenderowana strona. Zrobione, gdy: strona ma co najmniej jeden link do swojego filaru, co najmniej jeden istotny link boczny, gdy istnieje powiązany węzeł, i co najmniej jedna istniejąca strona linkuje do niej przed lub w czasie publikacji, aby nie była osierocona.

Sprawdź miejsca docelowe i kotwice. Co: otwórz każde miejsce docelowe i przejrzyj jego tekst kotwicy . Dlaczego: pozornie prawdopodobny URL może być nieobecny, przekierowany lub niepowiązany, a ogólne etykiety ukrywają cel miejsca docelowego. Jak: uruchom narzędzie do sprawdzania linków wewnętrznych, a następnie ręcznie sprawdź kotwice w kontekście zdania. Narzędzie: przeszukiwacz i przeglądarka. Zrobione, gdy: żaden link wewnętrzny nie zwraca błędu, każde miejsce docelowe wspiera otaczające twierdzenie, a żaden samodzielny „kliknij tutaj", surowy URL ani myląca kotwica dokładnie dopasowana nie pozostają.

7. Multimedia

Zweryfikuj zasoby, alternatywy i aktualność. Co: potwierdź, że każdy obraz istnieje, ma znaczący tekst alternatywny lub uzasadnioną pustą alternatywę i odzwierciedla aktualny interfejs. Dlaczego: uszkodzone, niejasne, zastępcze lub nieaktualne multimedia usuwają informacje i mogą uczynić instrukcje bezużytecznymi. Jak: wyłącz obrazy, sprawdź ścieżki, odtwórz kroki produktu i porównaj etykiety, wartości, przycięcie i redakcję. Narzędzie: narzędzie do sprawdzania zasobów, audyt dostępności, żywy produkt i przeglądarka. Zrobione, gdy: żaden zasób nie jest brakujący ani zastępczy, alternatywy są dokładne, a każdy zrzut ekranu przedstawia bieżący krok.

8. Wydanie techniczne

Zweryfikuj routing, indeksowalność i zastąpienie. Co: sprawdź slug, jeden samoodnoszący się kanoniczny URL , status, zachowanie robots, indeksowalność i przekierowania. Dlaczego: treść nie może działać na złej ścieżce, za noindex ani po pozostawieniu starych URL-i. Jak: sprawdź wyrenderowaną sekcję head i odpowiedź, porównaj rejestr i podążaj za każdą zastąpioną ścieżką. Narzędzie: narzędzie do sprawdzania nagłówków, mapa przekierowań, inspektor źródła i inspekcja URL. Zrobione, gdy: zatwierdzony URL zwraca 200 z jednym zamierzonym kanonikiem i bez blokady; każdy zastąpiony URL wykonuje jeden stały skok do najbliższego prawidłowego zamiennika.

Przetestuj stabilność na urządzeniach mobilnych. Co: sprawdź czytanie na wąskiej szerokości, interakcję, przepełnienie i Cumulative Layout Shift . Dlaczego: komponenty działające na komputerze mogą ukrywać elementy sterujące, przycinać tabele lub przesuwać treść podczas ładowania multimediów. Jak: przetestuj reprezentatywne szerokości mobilne i załaduj stronę z ograniczeniem przepustowości. Narzędzie: tryb urządzenia w przeglądarce i raport wydajności. Zrobione, gdy: cała treść i elementy sterujące pozostają użyteczne bez poziomego przepełnienia strony, a zmierzony CLS wynosi 0,1 lub mniej.

9. Gotowość na AI

Przetestuj ekstrakcję i początkowy HTML. Co: sprawdź odpowiedzi, definicje, kluczowe fakty, porównania i wnioski jako niezależne fragmenty w HTML-u dostarczonym przez serwer. Dlaczego: systemy wyszukiwania mogą wybrać jeden fragment i mogą nie wykonywać kodu po stronie klienta. Jak: pobierz początkowy HTML, usuń otaczający kontekst i sprawdź nazwy encji, kwalifikatory, jednostki i zaimki. Narzędzie: pobieranie HTML, ekstraktor fragmentów, przeglądarka i audyt AmICited. Zrobione, gdy: każdy priorytetowy fakt jest obecny bez JavaScript i samodzielnie zachowuje swój podmiot, znaczenie i ograniczenia.

Udostępnij strukturę proceduralną. Co: zweryfikuj, że pary FAQ i uporządkowane kroki są zakodowane jako rozpoznawalne pola i pozostają widoczne. Dlaczego: nagłówki i stylizowane bloki mogą wyglądać poprawnie, podczas gdy maszyny otrzymują nieustrukturyzowaną prozę. Jak: porównaj wynik elementów, dostępną strukturę i schemat z widoczną sekwencją. Narzędzie: drzewo dostępności i walidator danych strukturalnych. Zrobione, gdy: każde wymagane FAQ jest czytelne maszynowo jako para pytanie–odpowiedź, a każda wymagana procedura zachowuje uporządkowane kroki w widocznym i ustrukturyzowanym wyniku.

Narzędzia w AmICited

Użyj produktu do sprawdzenia kandydata i ustalenia dowodów przekazania; nie zastępuje on ludzkiego osądu.

1. Otwórz audyt gotowości agenta wraz z Dostępnością AI i gotowością agentów , aby sprawdzić dostępność, osiągalność przez przeszukiwacze, pokrycie mapą witryny i treść czytelną dla agentów.
2. Sprawdź URL kandydata za pomocą Inspekcji URL , aby zweryfikować status indeksu, użyteczność mobilną i werdykt dotyczący bogatych wyników. Przypisz inspekcję na żywo w przekazaniu dla nowego URL-a.
3. Otwórz audyt świeżości z Świeżością treści , aby nadać stronom wrażliwym czasowo sygnał konserwacji i datę następnego przeglądu. Historia zaczyna się, gdy śledzenie się rozpoczyna; brak historii nie oznacza braku zmian.
4. Użyj SEO MCP przez połączenie z przestrzenią roboczą do powtarzalnych kontroli URL-a, świeżości, Web Vitals i dostępności w trybie tylko do odczytu. Zapisz wynik lub identyfikator uruchomienia.

Automatyzacja: zaskryptuj kontrole deterministyczne, zachowaj ludzkie decyzje

Kontrola, którą można zaskryptować, ale pozostaje ręczna, zostanie pominięta pod presją. Automatyzuj stabilne, obserwowalne maszynowo wyniki; wymagaj człowieka dla celu, prawdy i kontekstu.

Automatyzacja zapisuje dowody, a nie zgodę. Porażka blokuje bramkę; przejście skryptu nie oznacza przejścia kolumn ludzkich.

Zasady decyzyjne

„Źle" musi być obserwowalne. Używaj tych progów, chyba że wybrany typ wpisu lub element definiuje ostrzejszy; bardziej szczegółowa umowa wygrywa.

N/A nie jest łagodniejszym zaliczeniem. Jest ważne tylko wtedy, gdy element naprawdę nie ma zastosowania — na przykład nie jest potrzebne przekierowanie, ponieważ żaden URL nie jest zastępowany — a zapis podaje dlaczego. Wyjątek musi określać zmienioną zasadę, powód biznesowy, ryzyko, osobę zatwierdzającą, właściciela poprawki i termin ważności. Osoba upoważniona do wydania podpisuje go; recenzent QA nie może go samozatwierdzić.

Produkt finalny: zapis przejścia

Dołącz jeden niezmienny zapis do dokładnego kandydata. Późniejszy audyt musi być w stanie odróżnić „nigdy nie sprawdzane" od „sprawdzone i zaliczone zgodnie z wersją specyfikacji 1". Przechowuj ustrukturyzowane pola, a nie zrzut ekranu z zielonymi znacznikami.

Ścieżka strony / kanonik:
Identyfikator kandydata do wydania lub hash treści:
Typ wpisu i encja:
Wersja specyfikacji:
Właściciel QA:
Osoba upoważniona do wydania:
Rozpoczęto / zakończono (znacznik czasu):

Kontrole:
- Grupa / element:
- Wynik: PASS | FAIL | N/A
- Dowód: wynik walidatora, lokalizacja źródła, miejsce docelowe lub obserwacja
- Sprawdzone przez / o godzinie:

Wyjątki:
- Zasada i zakres:
- Powód i ryzyko:
- Osoba zatwierdzająca:
- Właściciel poprawki / termin ważności:

Decyzja: PASS — PUBLIKUJ | FAIL — WSTRZYMAJ
Właściciel weryfikacji na żywo i termin:
Data następnego przeglądu konserwacyjnego:

Zapis przejścia jest tylko do dopisywania. Zmieniona specyfikacja lub kandydat otrzymują nowy audyt, nie przepisaną historię.

Co się dzieje w przypadku porażki

Porażka rozpoczyna pętlę korekcyjną, a nie negocjacje w wątku przeglądu.

1. Właściciel QA oznacza kandydata jako FAIL — WSTRZYMAJ, rejestruje dowody i zatrzymuje się w punkcie, w którym kontynuacja testowałaby wersję, która na pewno się zmieni.
2. Właściciel treści naprawia błędy typu wpisu, elementów, kopii, metadanych i dowodów. Właściciel implementacji naprawia błędy schematów, linków, multimediów, routingu, renderowania i automatyzacji. Specjalista ponownie sprawdza twierdzenia w swojej dziedzinie.
3. Osoba naprawiająca identyfikuje każdą zmienioną powierzchnię. Właściciel QA uruchamia ponownie nieudany element, elementy od niego zależne oraz wszystkie grupy, na które zmiana ma wpływ. Na przykład przepisana odpowiedź otwiera ponownie twierdzenia, zgodność elementów, parytet schematu i ekstrakcję AI.
4. Właściciel QA tworzy nowy wynik z oznaczeniem czasu. Publikacja pozostaje zablokowana, dopóki każdy mający zastosowanie element nie przejdzie, a każdy N/A lub wyjątek nie ma ważnego upoważnienia.

Autor nie certyfikuje swojej poprawki. QA jest właścicielem zapisu, produkcja jest właścicielem poprawek, specjaliści są właścicielami zatwierdzeń domenowych, a osoba upoważniona do wydania jest właścicielem wyjątków.

Co może pójść źle

• Traktowanie bramki jako korekty. Gramatyka może być nienaganna, podczas gdy strona używa złego typu wpisu, zaprzecza własnemu schematowi lub nie może być indeksowana.
• Testowanie źródła zamiast kandydata do wydania. Prawidłowy Markdown nie dowodzi, że szablony wyemitowały zamierzony kanonik, dostępną strukturę ani responsywny układ.
• Ręczne wykonywanie każdego elementu. Recenzenci wielokrotnie klikają deterministyczne kontrole, aż deadline nauczy ich pomijać listę.
• Automatyzowanie każdego elementu. Zielony walidator nie może zdecydować, czy dowody wspierają twierdzenie przyczynowe, ani czy porównanie odpowiada na decyzję czytelnika.
• Akceptowanie „naprawię po uruchomieniu". To zamienia bramkę przedpublikacyjną w nieudokumentowane zaległości i wymazuje znaczenie PASS.
• Pozwalanie tej samej osobie na implementację i zatwierdzanie. Samoprzegląd pomija założenia, ponieważ recenzent pamięta zamierzone zachowanie zamiast obserwować rzeczywisty wynik.

Przekazanie

Następny stan to publikacja i weryfikacja na żywo. QA przekazuje zatwierdzonego kandydata, zapis PASS, kanoniczną ścieżkę, mapę przekierowań, okno wydania i zatwierdzone wyjątki. Wydawca zwraca żywy URL i czas wdrożenia; właściciel weryfikacji na żywo powtarza kontrole statusu, kanonika, indeksowalności, przekierowań, schematów, linków, multimediów, urządzeń mobilnych i CTA.

Jeśli produkcja się różni, odpowiednie kontrole otwierają się ponownie. Jeśli jest zgodna, dodaj żywy URL i dowody bez nadpisywania wyniku kandydata. Późniejsze audyty używają przechowywanej wersji specyfikacji, aby odróżnić dryf od zmienionego standardu.

FAQ

Często zadawane pytania

Pass oznacza, że kandydat jest zgodny z bieżącą umową, co poparte jest sprawdzalnymi dowodami. Wszystko inne to wstrzymanie. Układ academy zamyka to FAQ wezwaniem do działania.