Verifica i backlink di una pagina tramite API e memorizzali in modo corretto
Il nostro indice viene aggiornato una volta al mese, quindi la maggior parte delle ricerche può essere servita dalla memoria. Una ricetta per cache che fanno risparmiare crediti senza mostrare agli utenti dati obsoleti.
Team editoriale AlfaLinks ·
La regola
Memorizza nella cache fino al prossimo aggiornamento dell'indice, non per un'ora fissa
Poiché i dati cambiano approssimativamente una volta al mese, un TTL orario non ti offre nulla se non un costo maggiore. Una chiave con scadenza mensile fornisce la stessa risposta per tutto il mese e si invalida con un unico aggiornamento.
TTL: fino alla fine del mese, più un giorno di grazia
Non memorizzare mai una risposta di errore nella cache
Perché un TTL breve è solo una donazione al tuo saldo di crediti
I team alle prime armi con i dati sui link copiano le abitudini dei tracker di posizione. Prima abitudine: una cache oraria, perché le posizioni cambiano. I grafi dei link si muovono molto lentamente.
Una chiamata backlinks da 2 crediti costa $0.0002. Può sembrare una cifra irrisoria finché non consideri che una visualizzazione di elenco avvia 50 chiamate per caricamento pagina su 400 workspace attivi, ripetute ogni ora per risposte identiche.
I numeri calcolati di seguito sono un esempio, non una misurazione del traffico effettivo. Supponi 400 workspace, 20 visualizzazioni di dominio ciascuna al giorno, 2 crediti per visualizzazione e una cache di 1 ora che ha successo forse una volta su cinque. La maggior parte delle visualizzazioni colpisce ancora l'API. Con una chiave mensile, lo stesso traffico la colpirebbe solo una volta per dominio e mese, quindi il divario è il punto centrale della ricetta.
Gli strumenti di keyword research necessitano di dati più freschi e, per quelli, le suite complete rimangono la scelta migliore. Per il contesto dei link, il mensile è il prodotto.
TTL per azione
Suggerito, non obbligatorio. Tutte le azioni leggono lo stesso indice mensile.
Azione
Crediti
TTL suggerito
Motivazione
panoramica, statistiche
0
Fino alla fine del mese
Gratuito, ma il tuo server risparmia comunque latenza
bulk_dr
1
Fino alla fine del mese
Intera tabella clienti in una sola chiamata
refdomains, backlinks
2
Fino alla fine del mese, per parametro pagina
Includi page, per, sort nella chiave
anchors, toppages
2
Fino alla fine del mese
Stabile tra un aggiornamento e l'altro
search, keyword
3
7 giorni
Raramente ripetuto, è conveniente saltare la cache
Esempio di richiesta: scalda la cache per una tabella clienti
Chiama bulk_dr una volta per cliente, non una volta per riga. Fino a 2.000 domini possono essere inseriti in un singolo corpo POST e costano un solo credito.
bash
curl -X POST "https://alfalinks.net/api.php?action=bulk_dr&key=sk_live_..." \
-d "domains=stripe.com,notion.so,linear.app,figma.com,vercel.com"
# billed once, whatever the row count
Costruisci la cache in cinque passaggi
Ogni passaggio ha un unico compito. Saltane uno e il guasto si manifesterà più tardi, solitamente sotto forma di fattura.
01
Scegli la chiave
Usa l'azione, il dominio, i parametri di paginazione e ordinamento e il mese dell'indice. Escludi tutto ciò che un utente può modificare senza cambiare la risposta, come un colore di visualizzazione o il nome di una scheda.
02
Memorizza la risposta analizzata
Conserva il JSON decodificato con il suo flag ok e i dati, non i byte grezzi. Una visualizzazione successiva può quindi ricostruire l'intera tabella dalla memoria senza una seconda chiamata.
03
Scadenza alla fine del mese
Imposta la scadenza alla fine del mese dell'indice, più il giorno di grazia della regola sopra. Usa la stessa regola per ogni azione, in modo che la logica risieda in una sola funzione e non in cinque punti diversi.
04
Registra il saldo su ogni chiamata
Leggi l'oggetto _credits su ogni risposta autenticata e scrivi il saldo rimanente nel tuo log. Un calo lento in questa riga è spesso il primo segno che una chiave di cache è errata.
05
Monitora il tasso di hit
Traccia con quale frequenza una visualizzazione viene servita dalla cache. Un tasso basso significa che la chiave è troppo specifica o che gli utenti aprono un nuovo dominio ad ogni visita. Entrambe le scoperte sono utili quando pianifichi il budget.
I dati obsoleti sono una scelta di prodotto o un bug?
Un dato sui link può avere un mese di età ed essere comunque corretto per l'indice da cui proviene. La vera domanda è se il tuo schermo lo indica. La maggior parte dei ticket di supporto relativi a numeri vecchi riguarda problemi di etichettatura. Le etichette li risolvono solitamente.
Assegna a ogni dato il mese dell'indice. Mostralo agli utenti. Una volta che possono vedere la data, il numero smette di sembrare un feed rotto e questa piccola riga fa più di quanto potrebbe mai fare un TTL più breve.
Quanto vecchio è troppo vecchio per un dato sui link?
Il nostro indice viene aggiornato approssimativamente una volta al mese, quindi un dato memorizzato nella cache il primo giorno descrive lo stesso indice di uno memorizzato l'ultimo giorno. Nulla nella risposta cambia all'interno del mese. I problemi iniziano quando un utente si aspetta un link di ieri, e poi la soluzione è un'etichetta chiara, come trattato in etichette del punteggio.
Le chiamate overview gratuite hanno davvero bisogno di una cache?
L'azione overview non costa crediti, quindi la cache qui protegge la velocità piuttosto che il saldo. Il tuo server paga comunque per ogni andata e ritorno, e una pagina che si apre cinquanta volte al minuto se ne accorgerà. Memorizza anche le risposte gratuite, con la stessa chiave mensile, e la pagina rimarrà veloce mentre il tuo proxy rimarrà silenzioso. Le note sulla ricerca pubblica spiegano la stessa idea per i visitatori.
Un link fresco dovrebbe mai bypassare la cache?
Di solito no. Un bypass costa crediti per una risposta che è probabilmente identica a quella in cache. Se un cliente insiste, spiega il mese dell'indice e offri un aggiornamento manuale per workspace al mese, anziché un pulsante aperto che chiunque può premere in un loop.
Protezione dallo stampede e altre piccole cose
Single-flight: se dieci utenti aprono lo stesso dominio, effettua una chiamata upstream e condividi la promessa.
Riscalda il primo del mese con un job in background, non alle 9 del mattino quando arrivano gli utenti.
Memorizza la risposta _credits.remaining e attiva un avviso al di sotto di una soglia scelta da te.
Memorizza nella cache il risultato negativo 'dominio non trovato' per un giorno, non per un mese.
Espone l'età della cache nell'UI in modo che il supporto possa rispondere a 'quando è stato recuperato questo dato?'.
Perché una cache batte lo scraping per i controlli sui link
I team che devono verificare i backlink delle pagine su larga scala spesso iniziano con script che interrogano direttamente i motori di ricerca. Questi script vanno in stallo. Sembra che costino poco il primo giorno, motivo per cui i team li mantengono molto più a lungo del necessario. Una cache davanti a un'API stabile è solitamente il design più economico, con meno componenti mobili da gestire.
La differenza si fa notare nelle ore di ingegneria più che nella prima fattura. Tieni la cache semplice e la maggior parte di quelle ore non si verificheranno.
Perché i controllori di link fatti in casa continuano a andare in stallo?
I motori di ricerca limitano le query automatizzate, quindi uno script che funziona bene per cinquanta URL può andare in stallo a cinquanta mila. I ritentativi, i pool di proxy e i ritardi casuali aggiungono tutti costi che non appaiono mai su una riga di crediti, e si rompono senza preavviso quando il target cambia le sue risposte.
Come si rende riavviabile un lavoro con un lungo elenco?
Scrivi ogni dominio completato nella cache man mano che procedi. Se il lavoro si interrompe a metà, un riavvio salta ogni dominio che ha già una risposta memorizzata e riprende da dove si era interrotto. Nulla viene addebitato due volte per lo stesso mese, perché la chiave contiene già la risposta.
Esegui il lavoro a un ritmo costante piuttosto che in un'unica raffica. Spaziare le chiamate mantiene i log leggibili e rende facile spiegare qualsiasi cambiamento nell'utilizzo dei crediti.
Quanto costa un elenco di 22.000 URL con una cache?
Supponi di dover verificare 22.000 URL in entrata per un cliente. Molti di loro condividono un dominio, quindi deduplica prima ai domini. Quei 22.000 link potrebbero ridursi a poche migliaia di domini unici, e una chiamata bulk_dr gestisce fino a 2.000 di essi per un solo credito. Memorizza ogni risultato per dominio e mese, e l'elenco smette di essere un lavoro per URL. Tieni l'aritmetica in una breve nota accanto al lavoro, in modo che la persona successiva possa rieseguirlo con una dimensione di elenco diversa. Un numero con il suo calcolo mostrato è più facile da fidarsi rispetto a un totale da solo.
Dove si collega
La cache è lo strato intermedio nel setup del contatore. Una volta che funziona, il costo per utente diventa prevedibile e puoi tariffare un piano in base ad esso con il confronto per utente. Le pagine brevi meritano una fine chiara. Questa l'ha.
Domande sulla cache che vediamo nelle revisioni del codice
La cache dovrebbe vivere anche nel browser?
Una cache breve nel browser aiuta la navigazione con il pulsante Indietro, ma la cache condivisa sul tuo server fa il vero risparmio. Mantieni lo storage lato client per minuti, poiché gli utenti su macchine diverse altrimenti vedrebbero numeri diversi per lo stesso dominio lo stesso giorno.
Cosa succede se un cliente dice che manca un nuovo link?
Controlla il mese dell'indice mostrato nella tua UI. Se il link è stato aggiunto dopo l'ultimo aggiornamento, apparirà dopo il prossimo. Offri una nota, non un rimborso, perché nulla è rotto.
Posso bypassare la cache su richiesta?
Puoi, ma ogni bypass costa crediti per una risposta che è probabilmente identica. Offrilo solo agli amministratori e limita la frequenza per workspace per evitare loop accidentali.
Paginazione e chiave di cache
La paginazione colpisce tutti una volta. Includila nella chiave.
Le azioni backlinks e refdomains restituiscono fino a 1.000 righe per chiamata, con page e per tra 10 e 5000, e la paginazione profonda è limitata a 50.000 righe, quindi una chiave senza quei parametri servirà la pagina uno per ogni richiesta.
L'ordinamento appartiene alla chiave anche esso. Un utente che passa da DR decrescente ad alfabetico si aspetta un elenco diverso, e la cache deve accontentarlo senza una nuova chiamata upstream quando l'insieme completo è già memorizzato.
Un test rapido cattura la maggior parte degli errori di chiave. Richiedi la pagina due, cambia l'ordinamento, quindi verifica che la pagina due in cache sia diversa dalla pagina uno in cache. Se non lo è, alla chiave manca un parametro. Trovato presto, costa minuti. Un cliente non lo vede. Esegui di nuovo il test prima di ogni rilascio, perché una nuova opzione di ordinamento è solitamente la ragione per cui la chiave si rompe. Scrivilo nella tua checklist di rilascio.
Pianifica il pulsante di esportazione separatamente: un job in background, un file memorizzato e una notifica quando è pronto.
