Scorri un verificatore di backlink URL senza lacune o cicli infiniti
Righe per chiamata, pagine per query e un tetto rigido a 50.000. Ecco un ciclo che rispetta tutti e tre i parametri e ti indica quando fermarsi.
Ogni chiamata restituisce fino a 1.000 righe. Ogni chiamata viene fatturata una volta, indipendentemente dal numero di righe. La paginazione profonda è limitata a 50.000 righe, ovvero 50 chiamate da 1.000 righe ciascuna.
Perché l'ordinamento precede la paginazione
La paginazione su un elenco non ordinato è la causa dei duplicati. Invia sempre sort e order insieme a page e per, in modo che la pagina 3 significhi la stessa cosa in ogni richiesta dell'esecuzione.
Un'operazione refdomains costa 2 crediti per chiamata, quindi 50 chiamate equivalgono a 100 crediti, ovvero un centesimo. Anche nel caso peggiore il costo è contenuto; il vero costo è un ciclo che non termina.
Scegliere la colonna di ordinamento
La colonna su cui ordinare dipende dalla domanda. L'ordinamento decrescente è la scelta più comune per i audit, perché il tetto taglia la coda lunga invece della parte che ti interessa.
Ordina per un campo che non ha significato per la tua domanda e il taglio potrebbe rimuovere le righe che volevi. Estrai dieci righe per ogni ordinamento candidato e verifica quale fetta sopravvive al tetto.
Scrivi la scelta nel report, così la persona successiva saprà perché il taglio è avvenuto in quel punto.
Record che si spostano durante un'esecuzione
I dati non si spostano durante un'esecuzione a meno che il rebuild mensile non avvenga nel mezzo. È raro, ma reale. Un job notturno che si sovrappone al primo del mese può restituire una pagina dal vecchio indice e la successiva dal nuovo, quindi registra l'ora di inizio nel log e confronta.
Scrivi l'ora di inizio in cima al log e il numero di pagina su ogni riga. Poi una discrepanza nell'output indica un problema di timing, non un bug di parsing.
Se il job è programmato, evita un'ora di inizio subito prima di un rebuild probabile. I tuoi log mostrano un rebuild come uno spostamento nei totali tra due esecuzioni che altrimenti coincidono, quindi mantieni i totali in ogni riga di log.
Un'esecuzione che copre un rebuild non è errata di default. È solo inconsistente, quindi marca quelle esecuzioni nel log e riesegui la fetta interessata quando è rilevante per un report.
Un ciclo di paginazione che termina
TypeScript per un worker Node 20. Si ferma alla prima pagina corta, al tetto o a qualsiasi ok che non sia true.
const BASE = "https://seomasters.dev/api.php";
const CAP = 50_000;
const PER = 1000;
export async function pullAll(domain: string, key: string) {
const rows: unknown[] = [];
for (let page = 1; rows.length < CAP; page++) {
const u = new URL(BASE);
u.search = new URLSearchParams({
action: "refdomains", q: domain,
page: String(page), per: String(PER),
sort: "dr", order: "desc",
}).toString();
const res = await fetch(u, { headers: { Authorization: `Bearer ${key}` } });
if (res.status === 401 || res.status === 402) throw new Error(`stop: HTTP ${res.status}`);
const body = await res.json();
if (!body.ok) throw new Error(JSON.stringify(body).slice(0, 300));
const chunk = findRows(body); // see note below
rows.push(...chunk);
if (chunk.length < PER) break; // short page means we are done
}
return rows;
}Risoluzione dei problemi di un'esecuzione di paginazione
| Cosa vedi | Motivo probabile | Cosa fare |
|---|---|---|
| La pagina 51 torna vuota o con errore | Hai raggiunto il tetto di 50.000 | Riduci con un'altra azione o un sort diverso, poi unisci per id |
| Lo stesso dominio su due pagine | Query non ordinata o rebuild dell'indice nel mezzo dell'esecuzione | Invia sort e order; deduplica sulla chiave del dominio |
| Meno righe del totale nella dashboard | Il totale è per l'intero grafico, l'estrazione è limitata | Mostra "top 50.000" nell'interfaccia |
| Il ciclo non termina mai | Il controllo della condizione verifica solo rows.length | Interrompi su una pagina corta, come sopra |
| Fattura più alta del previsto | Riprova su ogni codice non 200 | Riprova solo per errori di rete, vedi errori |
Lettura delle righe senza indovinare i nomi dei campi
Il helper findRows sopra è volutamente lasciato aperto. Fai una chiamata reale, guarda il JSON e scrivi l'accessore in base a ciò che vedi piuttosto che a ciò che prometteva un tutorial.
Per il cugino più economico di questo lavoro, che valuta molti domini in una volta senza paginazione, leggi lo script bulk DR.
Congela una risposta come fixture
Poi congela con un test. Salva una risposta come file fixture e verifica il conteggio delle righe e le chiavi della prima riga, così un cambiamento futuro fallirà in CI e non nel grafico di un cliente.
Mantieni la fixture nel controllo versione accanto al test, così un revisore vede la struttura che il codice si aspetta senza dover eseguire nulla.
Quando l'API aggiunge un campo in seguito, la differenza della fixture ti dice se il tuo accessor l'ha notata o l'ha ignorata silenziosamente.
Nomina la fixture in base alla query da cui proviene, come l'azione, il dominio e l'ordinamento. Un file chiamato response1.json non dice nulla al lettore successivo su cosa dimostri.
Conta le righe che hai memorizzato
Confronta le righe che hai salvato con il totale segnalato dal ciclo. Una differenza significa che una pagina è stata saltata, e una ripetizione significa che una pagina è stata estratta due volte e inserita in una sola riga.
Esegui questo controllo dopo ogni estrazione di test, non solo dopo la prima. Una deriva nel conteggio è solitamente il primo sintomo di un ordinamento cambiato o di un rebuild nel mezzo dell'esecuzione.
Mantieni il conteggio nella stessa riga di log del numero di pagina, così i due possono essere letti insieme a colpo d'occhio.
Divisione del lavoro oltre il tetto
Alcune domande superano il tetto. Per gli elenchi oltre il tetto, dividi il problema invece di paginare più a fondo. Estrai i top 50.000 con un ordinamento, poi chiedi ad altre azioni sui dominanti, poiché anche quelli costano 2 crediti e rispondono a domande diverse. Paginare più a fondo non supera mai il taglio.
Estrai i top 50.000 con un ordinamento
Prendi il tetto come un fatto dell'API. Estrai i top 50.000 righe con un ordinamento, memorizzale ed etichetta il risultato come la fetta superiore in qualsiasi report.
Una dashboard che mostra un conteggio limitato come se fosse il totale totale inganna chi la legge. L'etichetta non costa nulla, e un report del verificatore di backlink URL è più onesto con essa.
Decidi la dimensione della fetta prima dell'esecuzione e scrivila nell'intestazione del report, così il numero non sembrerà mai più grande di quanto sia. Una riga di intestazione non costa nulla, e un lettore che troverà una riga mancante in seguito te ne sarà grato.
Fai una domanda diversa ai dominanti
anchors e toppages rispondono ad altre domande, come quale anchor text domina o quali pagine attraggono i link. Per un dominio oltre il tetto, queste risposte possono essere più importanti della pagina successiva della stessa lista.
Mantieni i loro risultati nelle loro tabelle, indicizzati per dominio, così una successiva estrazione dello stesso dominio può sostituirli senza toccare le righe della fetta superiore.
Ogni azione extra costa i suoi crediti, quindi valuta il costo prima dell'esecuzione, non dopo che arriva la fattura.
Un elenco breve dei domini più pesanti, estratto una volta al mese, spesso dà un contesto più utile di un elenco più lungo estratto ogni notte.
Unione sulla chiave del dominio
Quando due estrazioni si sovrappongono, uniscile sulla chiave del dominio e mantieni il timestamp più recente. L'unione non dipenderà mai da quale estrazione è terminata per prima.
Logga quale estrazione ha vinto per ogni riga. Se un numero si sposta tra due report, quel log ti dice se è cambiato l'indice o l'unione.
Mantieni l'unione in una singola funzione con un test, poiché è l'unico punto in cui si incontrano due estrazioni.
Ripresa dopo un crash
I crash avvengono. Un deploy riavvia il worker, un laptop va in sospensione, una VPN si disconnette e il ciclo muore alla pagina 31 di 50.
Salva la pagina dopo ogni chiamata
Persisti l'ultimo numero di pagina completato dopo ogni chiamata. Riavvia da quel numero più uno, non dall'inizio, e pagherai 2 crediti per pagina invece di riacquistare l'intera estrazione.
Salvala dopo che la risposta è stata analizzata, non prima. Una pagina che non hai letto con successo dovrebbe essere estratta di nuovo, e un numero di pagina salvato deve sempre significare righe che hai già.
Un salvataggio che avviene una volta al minuto invece che per ogni chiamata lascia una finestra in cui un crash può ripetere la spesa dei crediti. Mantieni la scrittura piccola, così è economica da fare ogni volta.
Logga anche quanto tempo impiega ogni salvataggio e quanto tempo impiega ogni chiamata. Un salvataggio che compete con la chiamata stessa indica lo strato di storage, ed è vale la pena sistemarlo prima che il ciclo cresca.
Upsert sulla chiave del dominio
Mantieni una scrittura idempotente. Esegui l'upsert di ogni riga sulla sua chiave di dominio, così una pagina estratta due volte lascia una riga, non due.
Usa la stessa chiave su ogni percorso di scrittura, incluso lo script di riparazione manuale. Due percorsi di scrittura con due chiavi sono il motivo per cui i duplicati sopravvivono a una ripresa.
Uno script di riparazione è spesso scritto in fretta, dopo un'esecuzione fallita. È allora che si insinua una seconda chiave, quindi revisionalo con la stessa cura del ciclo principale.
Rifiuta una ripresa quando l'ordinamento è cambiato
Logga l'ordinamento e l'ordine insieme al numero di pagina. Se qualcuno cambia sort tra un crash e il riavvio, il numero di pagina salvato non significa più la stessa fetta. Rifiuta la ripresa e ricomincia da zero.
Memorizza un piccolo record di ripresa con l'ordinamento, l'ordine, la pagina e l'ora. Il ciclo legge prima quel record e rifiuta di continuare se qualsiasi campo non corrisponde più alla richiesta che sta per fare.
Una ripresa rifiutata non è un fallimento. È il ciclo che dice che la pagina salvata non significa più le stesse righe, e ricominciare da zero è l'errore più economico.
Esecuzione del ciclo in produzione
- 1
Inizia con un dominio piccolo
Esegui il ciclo contro un dominio con poche centinaia di righe, così la stop su pagina corta si attiva e puoi osservare il percorso di uscita.
- 2
Controlla una pagina a occhio
Apri una risposta memorizzata e conferma che l'accessore legge ancora le righe. Non fidarti di un parsing che non hai esaminato.
- 3
Mantieni i limiti in configurazione
Metti il tetto e la dimensione della pagina in un file di configurazione, così un cambiamento appare nella revisione e non si nasconde dentro una funzione.
- 4
Logga il motivo per cui il ciclo è terminato
Registra se l'esecuzione è terminata su una pagina corta, sul tetto o su un errore. Quelle tre terminazioni significano cose diverse per chi legge il log.
