Quaranta articoli programmati, una singola fonte di link difettosa: un'analisi post-mortem
Questa storia è inventata per mostrare un modello di errore, non riguarda un cliente reale. Nomi, conteggi e date sono un esempio fittizio. Gli errori in essa contenuti sono molto reali e ogni pipeline che abbiamo visto li commette almeno una volta.
Team di ricerca SEOBlogBot ·
Leggi questo come un racconto
Tutto quanto segue è un esempio costruito con numeri inventati. Mostra come si sviluppa il fallimento, in modo che il tuo team possa riconoscere lo stesso schema nei propri log.
Cosa è successo, ora per ora
La coda si riempie
Uno script di contenuto carica quaranta bozze in un scheduler di WordPress, due al giorno per venti giorni. Ogni bozza cita da tre a sei fonti esterne.
L'unico controllo è manuale
L'editor ha incollato cinque domini nella casella del backlink checker gratuito di Semrush in precedenza e non ha visto nulla di strano. Trentacinque domini non sono mai stati controllati.
La prima segnalazione
Un lettore invia un'email segnalando che uno "studio" citato porta a una pagina parcheggiata. L'editor corregge manualmente un articolo.
Lo schema emerge
Undici delle quaranta bozze citano fonti ospitate su domini con quasi zero domini che linkano. Sono provenute da una scaletta generata dall'IA.
Pulizia
Il team rimuove la coda rimanente, riscrive nove citazioni e ripubblica. Sei articoli erano già andati online con fonti deboli.
Cause radice, in ordine di peso
Nulla ha bloccato la coda, ed è stato questo il primo errore. Una persona con un browser può controllare cinque domini, non trentacinque, quindi il controllo non avrebbe mai coperto l'intero batch.
La seconda causa è stata la mancanza di una regola. Nessuno aveva scritto come appare una fonte scadente, quindi ogni editor ha giudicato istintivamente, e l'istinto era esausto giovedì.
La terza causa si nasconde dietro le altre due. Nessuno era responsabile del risultato dopo la programmazione. Gli articoli rimanevano in uno stato che sembrava finito, ed è questo il tipo di coda più pericoloso.
Nessuna delle tre cause era di per sé un problema umano. Ognuna era una regola mancante che nessuno poteva vedere. Funzionava sulla memoria. È il tipo di errore più difficile da risolvere, perché nessuno ha fatto nulla di sbagliato appositamente.
Una quarta causa minore era il modo in cui il batch è entrato nel sistema. Quaranta articoli caricati in una sola sessione non hanno dato a nessuno una pausa naturale per guardare, quindi la coda è semplicemente cresciuta. La soluzione è semplice. Carica il batch in porzioni più piccole e lascia che ogni porzione completi i suoi controlli prima che carichi la successiva.
Come sarebbero stati i numeri
Ogni numero in questa storia è inventato, ma la matematica è reale. Quaranta bozze con una singola chiamata bulk_dr ciascuna sarebbero 40 crediti, o $0.004.
Il controllo manuale dell'editor su cinque domini ha richiesto dieci minuti. Uno script avrebbe coperto gli altri trentacinque in una frazione di quel tempo.
Il denaro è la parte più piccola della storia. Il vero costo sono stati i sei articoli che un lettore poteva già vedere, e le ore spese a correggere ciò che un controllo avrebbe individuato in pochi secondi. Le ore raramente arrivano in fattura.
Nulla qui prevede come Google avrebbe trattato gli articoli. Non facciamo alcuna affermazione sui ranking, solo sulla qualità delle citazioni che un lettore incontra. Mantieni questo confine.
Cosa ha cambiato il team in seguito
Quattro cambiamenti, ognuno abbastanza piccolo da essere completato in una settimana.
01
Una chiamata per bozza
Ogni host in uscita passa attraverso bulk_dr prima che l'articolo possa essere programmato. Il costo è 1 credito per bozza.
02
Regole scritte
Tre o più host al di sotto del minimo del team inviano l'articolo in HOLD. L'albero decisionale contiene le regole esatte.
03
Un secondo controllo dopo la pubblicazione
Un audit mensile registra i numeri del sito e segnala i cali.
04
Un responsabile
Una persona nominata riceve gli alert HOLD. Gli alert inviati a un canale di cui nessuno è responsabile vengono ignorati entro una settimana.
Come la coda avrebbe dovuto essere controllata
La soluzione inizia prima che la coda si riempia. Tre decisioni avrebbero individuato la maggior parte di questi articoli prima che qualsiasi lettore li vedesse. Nessuno di essi richiede nuovo software. Serve un elenco, una frase e un nome, e un team può scrivere tutti e tre nel pomeriggio.
Conta gli host per bozza
Conta gli host in uscita per ogni bozza prima che qualcuno decida chi deve controllarli. Una bozza con sei host richiede uno script, mentre una bozza con un host può essere controllata rapidamente a mano.
Una scheda del backlink checker gratuito di Semrush va bene per il caso di un solo host. Non può gestire le altre quaranta bozze.
Scrivi la regola come una frase
Una regola come "tre o più host bassi inviano l'articolo in HOLD" può essere testata. Una guida vaga come "controlla attentamente le fonti" non può, e un editor stanco non può applicarla.
Scrivi ogni regola con lo stato che imposta, come HOLD o PASS, e la persona che lo vede. Una regola senza uscita lascia l'editor indovinare.
Nomina il responsabile prima del lancio
Qualcuno deve essere responsabile della coda HOLD il giorno in cui viene caricato il primo articolo. Senza quel nome, il primo alert atterra in un canale condiviso e rimane lì in attesa.
Il responsabile non deve leggere ogni bozza. Deve vedere l'elenco HOLD ogni giorno e decidere cosa fare con ogni voce.
Segnali arrivati troppo tardi
Il team aveva tre segnali prima della pulizia, e ognuno è arrivato più tardi del dovuto. I segnali non erano nascosti. Erano nella casella di posta, nella vista della coda e nelle note dell'editor, e nessuno li aveva messi in un unico posto.
Una segnalazione di un lettore è un segnale tardivo
Un lettore che trova una citazione morta l'ha già vista. Quel messaggio è utile, ma arriva dopo il danno, quindi non può essere l'allarme principale.
Un cluster di fonti simili è un segnale più precoce
Undici bozze che citano domini sparsi dalla stessa scaletta sono un modello che un singolo controllo avrebbe mostrato. Raggruppare per host è economico e individua il modello prima che lo faccia un lettore.
Una coda silenziosa non è una coda sana
Quando lo scheduler mostra quaranta articoli e nessun alert, nessuno ha controllato nulla. Il silenzio viene letto come successo, ed è così che una coda che sembra finita nasconde fonti deboli.
Un semplice contatore aiuta. Conta gli articoli programmati oggi e gli articoli controllati oggi. Quando questi due numeri differiscono, la coda non è sana.
Cosa ha fatto l'editor in seguito
La prima mossa dell'editor è stata rimuovere la coda rimanente e fermare lo scheduler. Questo ha richiesto minuti. È stata l'unica parte della settimana andata secondo i piani. Lo scheduler è rimasto chiuso per le nuove bozze finché non era stata scritta una regola e nominato un responsabile. Nessuno lo ha riaperto prima.
La riscrittura è venuta dopo. Ogni citazione interessata è stata sostituita con una fonte che l'editor poteva aprire e leggere, e l'articolo è tornato in coda solo dopo che una seconda persona lo aveva controllato. La velocità non era l'obiettivo, perché una correzione veloce che ripete lo stesso errore non aiuta nessuno.
In seguito il team ha scritto una breve nota per sé stesso. Elencava la regola, il responsabile e il controllo, in quell'ordine. Nient'altro. La nota non era un esercizio di colpevolizzazione e non è stato chiesto a nessuno di spiegare perché aveva fidato dello strumento gratuito.
Alla fine della settimana il team aveva due nuove abitudini e una vecchia. Le nuove abitudini erano il conteggio degli host e l'elenco HOLD. Quella vecchia era l'editor che leggeva ogni citazione prima che venisse pubblicata. Questa parte si è rivelata funzionare.
Domande per la prossima revisione
Quale passaggio può programmare un articolo senza un controllo del link?
Chi ha controllato la coda tra la programmazione e la pubblicazione?
Quanti host conteneva l'ultimo batch e quanti ne ha controllati una persona?
Quale alert non ha un responsabile nominato oggi?
Qual è la regola in una frase per un HOLD?
La lezione
Un controllo manuale scala a cinque domini, uno script scala a cinque mila
Strumenti gratuiti di Semrush, Ahrefs o Moz vanno bene per un'occhiata umana. Tutto ciò che si ripete su un programma appartiene al codice, con un prezzo per chiamata e una riga di log per ogni esecuzione.
Conta gli host in una bozza prima di decidere chi deve controllarli.
Chi ha controllato la coda tra la programmazione e la pubblicazione? Cosa ha effettivamente visto? Quale regola sarebbe scattata, scritta come una frase che un collega potrebbe testare? Una spallata in risposta significa che i prossimi quaranta articoli finiranno allo stesso modo. Scrivi le risposte nel tuo runbook questa settimana.
Domande che i lettori pongono su questo errore
Questa storia riguarda un cliente reale?
No. È un esempio inventato che mostra un modello di errore. Gli errori in essa contenuti sono comuni, ma i nomi, i conteggi e le date sono fittizi.
Perché il team non se n'è accorto prima?
Il controllo viveva nella testa di una persona e l'alert non andava da nessuna parte. Una volta che una regola è scritta e instradata a un responsabile nominato, lo stesso errore è molto più difficile da perdere. La soluzione era una regola e un nome, non uno sforzo eroico.
Un gate avrebbe bloccato tutti e sei gli articoli online?
Un gate avrebbe bloccato le bozze prima della programmazione. I sei articoli che erano già andati online avrebbero comunque bisogno della pulizia, motivo per cui la storia finisce con una riscrittura piuttosto che con un rollback.
Qual è il cambiamento più piccolo che un team può fare?
Aggiungi una chiamata bulk_dr al passaggio di programmazione e scrivi la regola HOLD. Questa coppia da sola avrebbe segnalato le citazioni deboli in questa storia.
