Audyt linków po publikacji z GitHub Actions lub zwykłym cronem

Dlaczego w ogóle audytować po publikacji

Bramka widzi wersję roboczą. Audyt widzi to, co faktycznie dzieje się na żywej stronie. Wtyczki przepisują linki, edytorzy wklejają przekierowania afiliacyjne zamiast czystych adresów URL, a migracja CDN może zamienić jeden host na inny. Nic z tego nie istnieje na etapie wersji roboczej, dlatego uruchomienie audytu po publikacji jest pierwszym miejscem, w którym te problemy mogą się pojawić.

Użyteczny audyt jest nudny z założenia. Uruchamia się zgodnie z harmonogramem, zapisuje jedną linię i milczy, chyba że wystąpi wyjątek. Cisza jest celem. Miesiąc cichych logów oznacza, że zadanie działa, a nie że jest bezczynne.

Nie ma oficjalnego API sprawdzania backlinków Google do ogólnego użytku, dlatego zespoły korzystają zamiast tego z zewnętrznych indeksów linków. To nasz własny crawler. Google Search Console pokazuje widok Google na Twoje własne linki, a audyt uzupełnia go, a nie zastępuje.

Gdzie uruchamia się zadanie

Zapisz wyzwalacz. Trzy konfiguracje pokrywają potrzeby większości zespołów, a każde z nich wykonuje te same wywołania. Log jest ważniejszy niż wyzwalacz, ponieważ data, URL i zużyte kredyty muszą tam trafiać za każdym razem.

GitHub Actions dla repozytorium

Jeśli strona jest budowana z repozytorium, zaplanowany workflow wprowadza najmniejsze tarcie. Zadanie znajduje się obok kodu, a klucz znajduje się w magazynie sekretów repozytorium. Plik workflow poniżej to minimum, którego potrzebujesz. Trzymaj go w repozytorium, przeglądaj go jak każdy inny kod i zablokuj (pin) wersje akcji, na których polegasz.

Zwykły serwer z cronem

Zespoły, które już utrzymują maszynę do swoich buildów, mogą zaplanować te same polecenia tam. Narzędzie takie jak n8n może je uruchomić przez krok Execute Command, albo linia crontab może je uruchomić bezpośrednio. W każdym razie zadanie powinno uruchamiać się jako użytkownik, który może odczytać klucz i nic więcej.

Webhook z Twojego CMS

Niektóre konfiguracje CMS wysyłają webhook, gdy post jest publikowany, a to zdarzenie może uruchomić audyt. Sprawdzenie odbywa się w momencie, gdy post staje się publiczny. Zachowaj również zaplanowane uruchomienie, ponieważ pojedynczy pominięty webhook pozostawi post bez sprawdzenia.

Które witryny audytować

Zacznij od domeny, która hostuje posta. Następnie przeprowadź ten sam audyt wobec dwóch lub trzech konkurentów, których chcesz porównać. Użyj compare. Przyjmuje do 20 domen za 1 kredyt, więc sprawdzenie konkurencji kosztuje prawie nic.

Pomiń długie ogony. Każda dodatkowa witryna dodaje szum do logu, który osoba musi przeczytać. Benchmark dwudziestu niepowiązanych domen mówi Ci bardzo mało o Twojej własnej.

Utrzymanie klucza poza logami

Zadanie zaplanowane odczytuje swój klucz przy każdym uruchomieniu, więc nie potrzebuje kroku logowania. Jedyną rzeczą do ochrony jest sam klucz. Ma trzy oczywiste ujścia: commit, wydrukowane środowisko i URL, który zapisuje proxy. Zamknij każde z nich.

Użyj magazynu sekretów, a nie pliku w repozytorium

Wklej klucz do magazynu sekretów swojego dostawcy CI lub do pliku środowiskowego, który może odczytać tylko użytkownik zadania. Nigdy go nie commituj. Krok, który echo-uje swoje środowisko, go wydrukuje, więc nie twórz takiego.

Wyślij klucz w nagłówku

Nagłówek Bearer trzyma klucz z dala od większości logów dostępu, ponieważ URL-y są zapisywane, a nagłówki zwykle nie. Forma z parametrem query-string również działa, ale zostawia kopię w każdym proxy, które widzi żądanie.

Ogranicz dostęp do odczytu magazynu

Daj dostęp do odczytu ludziom, którzy utrzymują zadanie, i nikomu innemu. Przeglądaj tę listę, gdy zadanie zmienia właściciela.

Klucz, który wielu ludzi może odczytać, to klucz, który pewnego dnia trafi wklejony do okna czatu.

Zweryfikuj odpowiedź przed jej zapisaniem

Odpowiedź, która dotarła, to jeszcze nie odpowiedź, której możesz użyć. Używaj jednej kolejności za każdym razem. Zapisuj tylko to, co przejdzie, i loguj resztę. Odrzucona odpowiedź to dowód, a kolejna osoba debugująca zadanie będzie chciała ją zobaczyć.

Najpierw sprawdź status i ok

Odczytaj kod statusu HTTP, a następnie pole ok w ciele. 200 z ok ustawionym na false to nadal nieudane wywołanie, a log powinien to odzwierciedlać.

Sparsuj JSON przed jakimkolwiek zapisem

Potwierdź, że ciało jest poprawnym JSON-em przed rozpakowaniem, sparsowaniem lub dołączeniem czegokolwiek. Ucięte pobranie może się zdarzyć na niestabilnym runnerze. Uszkodzony plik zapisany do logu wygląda OK, dopóki ktoś go nie otworzy.

Traktuj pustą listę jako pytanie

Pusty wynik dla witryny, która miała wiersze w zeszłym miesiącu, to pytanie, nie fakt. Sprawdź pisownię domeny, w tym wiodące www., zanim ktokolwiek otrzyma alert.

Koszty i gdzie je odczytać

Miesięczny audyt jednej witryny kosztuje 4 kredyty, gdy pobierzesz obie listy, co daje $0.0004. Wywołanie overview jest darmowe. Miesiąc bez zmian kosztuje więc nic ponad to.

Jeśli Twój zespół publikuje dziesięć postów dziennie na kilku witrynach, audyt to nadal jedno miesięczne zadanie na witrynę, a nie jedno zadanie na posta. To utrzymuje liczbę małą, a log czytelny.

Gdy dodajesz drugą witrynę, skopiuj zadanie, zamiast je rozszerzać. Jeden workflow na domenę utrzymuje log na witrynę i ułatwia śledzenie błędu do jego właściciela.

Większy koszt to zwykle minuty Twojego dostawcy CI, a nie nasze kredyty. Tabela kosztów umieszcza obie linie obok siebie, więc możesz zdecydować, którą z nich dostosować jako pierwszą.

Poproś o wydrukowanie _credits w pierwszym uruchomieniu. Ufaj odpowiedzi bardziej niż jakiejkolwiek tabeli. Przewodnik bramki obejmuje sprawdzenie po stronie wersji roboczej, które poprzedza to.

Harmonogram GitHub działa w UTC, więc start o 06:00 przypada na inną godzinę lokalną dla każdego zespołu. Zapisz strefę czasową w instrukcji obsługi, aby nikt nie był zaskoczony logiem.

Pytania dotyczące uruchomienia audytu

Większość tych pytań pochodzi od zespołów, które właśnie po raz pierwszy zaplanowały zadanie.

Czy to jest google backlink checker API?

To audyt zbudowany na naszym własnym API, a nie produkt Google. Google nie publikuje ogólnego API backlinków, więc liczby pochodzą z naszego własnego crawlera i naszego własnego indeksu.

Czy audyt może uruchamiać się przy każdym buildzie?

Może, ale miesięczne pobranie refdomains nie musi uruchamiać się przy każdym buildzie. Uruchamiaj darmowy overview przy każdym publikowaniu, a płatne pobrania raz w miesiącu.

Czy nadal potrzebuję audytu, jeśli mam bramkę?

Tak, jeśli publikujesz przez wtyczki lub CDN. Bramka widzi Twoją wersję roboczą, a audyt widzi żywą stronę. Każde z nich łapie błędy, których drugie nie widzi.

Co jeśli zadanie zawiedzie w połowie?

Zapisz wynik każdego kroku do osobnego pliku, więc nieudane pobranie pozostawi overview nienaruszone. Uruchom ponownie od nieudanego kroku, a nie od początku, co unika płacenia za to samo pobranie dwa razy.

Ile kredytów powinienem przewidzieć na każdą witrynę?

Przewidz 4 kredyty na witrynę na miesiąc za dwa płatne pobrania, plus wszystko, co wyda Twoja bramka na wersje robocze. Darmowy overview nie dodaje nic do tej kwoty, a log pokazuje rzeczywisty całkowity koszt.

Dlaczego dwa uruchomienia kilka dni od siebie się różnią?

Indeks odświeża się mniej więcej raz w miesiącu, więc zmiany dzień po dniu to zwykle szum. Porównaj ten miesięczny snapshot z zeszłomiesięcznym przed otwarciem zgłoszenia.