Verifica dei link post-pubblicazione con GitHub Actions o cron standard

Perché effettuare una verifica dopo la pubblicazione

Un gate vede una bozza. Una verifica vede cosa fa effettivamente il sito live. I plugin riscrivono i link, gli editor incollano redirect affiliati su URL puliti e una migrazione CDN può trasformare un host in un altro. Nulla di tutto ciò esiste nello stadio di bozza, motivo per cui un'attività post-pubblicazione è il primo punto in cui questi problemi possono manifestarsi.

Una verifica utile è noiosa per progettazione. Viene eseguita su un programma, scrive una riga e rimane in silenzio a meno che non scatti un'eccezione. La quiete è l'obiettivo. Un mese di log silenziosi significa che il lavoro funziona, non che è inattivo.

Non esiste un'API ufficiale di controllo dei backlink di Google per uso generale, motivo per cui i team si affidano a un indicizzatore di link di terze parti. È il nostro crawler. Search Console mostra la visione di Google dei tuoi link, e la verifica la integra piuttosto che sostituirla.

Dove viene eseguita l'attività

Annota il trigger. Tre configurazioni coprono la maggior parte dei team e ognuna esegue le stesse chiamate. Il log è più importante del trigger, perché la data, l'URL e i crediti utilizzati devono esserci ogni volta.

GitHub Actions per un repository

Se il sito viene costruito da un repository, un workflow pianificato aggiunge il minimo attrito. Il lavoro vive accanto al codice e la chiave è archiviata nel gestore dei segreti del repository. Il file di workflow qui sotto è il minimo necessario. Tienilo nel repository, revisionato come qualsiasi altro codice, e blocca le versioni delle azioni su cui fai affidamento.

Un server semplice con cron

I team che mantengono già una macchina per la loro build possono programmare gli stessi comandi lì. Uno strumento come n8n può eseguirli tramite un passaggio Execute Command, oppure una riga crontab può eseguirli direttamente. In ogni caso, il lavoro dovrebbe essere eseguito da un utente che può leggere la chiave e nient'altro.

Un webhook dal tuo CMS

Alcune configurazioni CMS attivano un webhook quando un articolo diventa live, e quell'evento può avviare la verifica. Il controllo viene quindi eseguito nel momento in cui l'articolo è pubblico. Mantieni comunque una esecuzione programmata, perché un singolo webhook perso lascia un articolo senza verifica.

Quali siti verificare

Inizia con il dominio che ospita l'articolo. Poi esegui la stessa verifica contro due o tre peer che vuoi confrontare. Usa compare per farlo. Richiede fino a 20 domini per 1 credito, quindi il controllo dei peer costa quasi nulla.

Salta la coda lunga. Ogni sito extra aggiunge rumore a un log che una persona deve leggere. Un benchmark di venti domini non correlati ti dice molto poco sul tuo.

Mantenere la chiave fuori dai log

Un lavoro programmato legge la sua chiave ad ogni esecuzione, quindi non ha bisogno di un passaggio di accesso. L'unica cosa da proteggere è la chiave stessa. Ha tre evidenti punti di fuga: un commit, un ambiente stampato e un URL che un proxy registra. Chiudili tutti.

Usa il gestore dei segreti, non un file nel repo

Incolla la chiave nel gestore dei segreti del tuo provider CI, o in un file di ambiente che solo l'utente del lavoro può leggere. Non commitarlo mai. Un passaggio che stampa il suo ambiente lo stamperà, quindi non scriverne uno.

Invia la chiave in un header

L'header Bearer tiene la chiave fuori dalla maggior parte dei log di accesso, perché gli URL vengono registrati e gli header di solito no. La forma query-string funziona anche, ma lascia una copia in ogni proxy che vede la richiesta.

Limita chi può leggere il gestore

Concedi l'accesso in lettura alle persone che mantengono il lavoro e a nessun altro. Rivedi quell'elenco quando il lavoro cambia proprietario.

Una chiave che molte persone possono leggere è una chiave che un giorno finirà incollata in una finestra di chat.

Convalida la risposta prima di scriverla

Una risposta arrivata non è ancora una risposta che puoi usare. Usa un ordine ogni volta. Scrivi solo ciò che passa e registra il resto. Una risposta rifiutata è una prova, e la prossima persona che debuggerà il lavoro vorrà vederla.

Controlla prima lo stato e ok

Leggi il codice di stato HTTP, poi il campo ok nel corpo. Un 200 con ok impostato su false è ancora una chiamata fallita, e il log dovrebbe dirlo.

Analizza il JSON prima di qualsiasi scrittura

Conferma che il corpo sia JSON valido prima di decomprimere, analizzare o aggiungere qualsiasi cosa. Un download troncato può verificarsi su un runner instabile. Un file rotto scritto nel log sembra a posto finché qualcuno non lo apre.

Tratta una lista vuota come una domanda

Un risultato vuoto per un sito che aveva righe il mese scorso è una domanda, non un fatto. Controlla l'ortografia del dominio, incluso un www. iniziale, prima che qualcuno riceva un'alert.

Costi e dove leggerli

Una verifica mensile per un sito costa 4 crediti quando recuperi entrambi gli elenchi, che sono $0.0004. La chiamata panoramica è gratuita. Un mese senza variazioni quindi non costa nulla oltre a quello.

Se il tuo team pubblica dieci articoli al giorno su diversi siti, la verifica è comunque un lavoro mensile per sito, non un lavoro per articolo. Questo mantiene il conteggio piccolo e il log leggibile.

Quando aggiungi un secondo sito, copia il lavoro invece di allargarlo. Un workflow per dominio mantiene il log per sito e rende facile tracciare un errore fino al suo proprietario.

Il costo maggiore è solitamente quello dei minuti del tuo provider CI, non i nostri crediti. La tabella dei costi mette entrambe le righe fianco a fianco, così puoi decidere quale ottimizzare per prima.

Chiedi alla prima esecuzione di stampare _credits. Fidati della risposta rispetto a qualsiasi tabella. La guida del gate copre il controllo lato bozza che precede questo.

La pianificazione di GitHub esegue in UTC, quindi un inizio alle 06:00 atterra a un'ora locale diversa per ogni team. Scrivi il fuso orario nel runbook così nessuno si sorprende dal log.

Domande sull'esecuzione della verifica

La maggior parte di queste domande proviene da team che hanno appena programmato il lavoro per la prima volta.

È un'API di controllo dei backlink di Google?

È una verifica basata sulla nostra API, non un prodotto Google. Google non pubblica un'API backlink generale, quindi i numeri provengono dal nostro crawler e dal nostro indicizzatore.

La verifica può essere eseguita con ogni build?

Può, ma un recupero mensile di refdomains non deve essere eseguito ad ogni build. Esegui la panoramica gratuita su ogni pubblicazione e i recuperi a pagamento una volta al mese.

Ho ancora bisogno della verifica se ho un gate?

Sì, se pubblichi attraverso plugin o una CDN. Il gate vede la tua bozza e la verifica vede la pagina live. Ognuno cattura i fallimenti che l'altro non può vedere.

Cosa succede se il lavoro fallisce a metà?

Scrivi il risultato di ogni passaggio nel suo file, così un recupero fallito lascia la panoramica intatta. Ri-esegui dallo step fallito piuttosto che dall'inizio, evitando di pagare lo stesso recupero due volte.

Quanti crediti dovrei preventivare per ogni sito?

Preventiva 4 crediti per sito al mese per i due recuperi a pagamento, più quello che spende il tuo gate sulle bozze. La panoramica gratuita non aggiunge nulla a quella cifra, e il log ti dice il totale reale.

Perché due esecuzioni a pochi giorni di distanza discordano?

L'indicizzatore si aggiorna circa una volta al mese, quindi le variazioni giorno per giorno sono solitamente rumore. Confronta la snapshot di questo mese con quella del mese scorso prima di aprire un incidente.