Le verifiche DR gratuite non richiedono una chiave. Accedi per ottenere $100 di credito.
Ipotesi
Ogni cifra qui è inventata per mostrare il metodo. Non viene descritto alcun cliente, fornitore o risultato reale.
L'agenzia, il fornitore, i domini e ogni numero qui sotto sono fittizi. Servono a mostrare aritmetica e struttura. Il tuo lotto sarà diverso.
Immagina un'agenzia che ha acquistato 40 posizionamenti per un sito client, a un prezzo fisso per link, con un DR minimo promesso di 30 e una finestra di sostituzione di 60 giorni. Il foglio del fornitore elenca 40 URL di origine e 40 anchor text.
Nulla di insolito qui. La domanda è come trasformare quel foglio in una tabella di verifica. Utilizziamo tre checkpoint: giorno 0, giorno 30 e giorno 60.
| Checkpoint | Pagina live recuperata | Host presente nell'elenco refdomains | Attributo rel come ordinato | Note |
|---|---|---|---|---|
| Giorno 0 | 38 su 40 | 0 su 40 (non ancora indicizzato) | 36 su 38 | 2 URL 404, 2 rel=sponsored aggiunti |
| Giorno 30 | 37 su 40 | 29 su 40 | 35 su 37 | 1 rimosso in più, indicizzazione aggiornata al giorno 22 |
| Giorno 60 | 36 su 40 | 34 su 40 | 35 su 36 | Sostituzioni in corso per 4 |
Il giorno 0 mostra zero host nell'indice. È normale. Zero al momento della consegna non è un difetto; zero dopo due aggiornamenti sì.
Al giorno 60 quattro link sono scomparsi. Altri due sono cambiati perché presentano un'etichetta sponsored che l'ordine non menzionava. Nota la differenza. Se l'etichetta conta come difetto dipende dal contratto, quindi il foglio dovrebbe indicare cosa è stato ordinato in parole chiare. Il glossario elenca i valori rel che puoi citare.
Il limite minimo di rating viene verificato una volta con bulk_dr. Una chiamata. Nell'esempio, 40 domini in una chiamata costano 1 credito, e 3 domini ottengono un punteggio inferiore a 30 secondo la nostra formula. Questi tre vanno in ticket per primi perché sono oggettivi e facili da provare.
Un rating inferiore al limite non è una questione di gusto. Una regola che si risolve con un numero guadagna fiducia per le righe soggettive che seguono.
Al giorno 60 il lotto inventato mostra 4 pagine mancanti e 2 etichette sponsored. I due gruppi richiedono gestioni diverse e l'ordinamento è il passaggio che trasforma un elenco di difetti in un ticket.
Delle 4 pagine mancanti, supponi che 3 siano state rimosse dal publisher e 1 sia stata spostata su un nuovo URL. Lo spostamento è facile da non notare. Un redirect dall'indirizzo vecchio mostrerebbe un 301 nel dump delle intestazioni salvato, motivo per cui le intestazioni vengono archiviate insieme all'HTML.
Le 2 etichette sponsored sono una classe diversa di problemi. I link funzionano. Il fornitore potrebbe benissimo dire che l'etichetta è l'opzione onesta. Decidi in anticipo se un'etichetta conta, perché una disputa risolta per gusto spreca una settimana.
| Fase | Chiamate | Crediti | Dollari |
|---|---|---|---|
| bulk_dr su 40 domini | 1 | 1 | $0.0001 |
| refdomains al giorno 0, 30 e 60 | 3 | 6 | $0.0006 |
| anchor al giorno 60 | 1 | 2 | $0.0002 |
| Totale | 5 | 9 | $0.0009 |
La colonna pagina live proviene da curl sulla macchina del tester, non dalla nostra API. Non offriamo questo controllo e pretendere che lo facessimo nasconderebbe la parte più laboriosa del lavoro.
I crediti sono quasi irrilevanti. Il lavoro è leggere 40 pagine. Se vuoi ridurlo, scripta il grep dall'elenco degli errori e tieni d'occhio le 4 o 5 righe che falliscono.
Per una visione mese per mese di un intero portfolio client, passa alla tabella dei costi. Se le classifiche sono cambiate dopo il lotto, il manuale per i cali di traffico è la prossima fermata.
Le stesse quattro azioni sono state eseguite al giorno 0, giorno 30 e giorno 60, così ogni checkpoint poteva essere confrontato con quello precedente.
Tutte le 40 pagine sono state recuperate una volta per checkpoint, con HTML e intestazioni salvati e datati. Un recupero fallito è una riga nella tabella, mai una cella vuota.
Una chiamata refdomains per checkpoint ha restituito l'elenco degli host per il client. Un elenco sottile al giorno 0 era previsto, quindi la riga è stata segnata e lasciata per il checkpoint successivo.
Ogni host e ogni valore rel è stato confrontato con il checkpoint precedente nonché con l'ordine. Un cambiamento si manifesta quindi come un cambiamento, con una data associata.
Le regole alla fine di questa pagina sono state applicate riga per riga. Le prove sono rimaste accanto a ciascuna riga, così un verdetto contestato poteva essere riesaminato.
Ogni checkpoint poneva una domanda principale. Mescolarle è la solita ragione per cui un risultato del giorno 0 viene discusso al giorno 60.
Al giorno 0 la domanda è stretta. La pagina è live e l'anchor esiste nell'HTML salvato? L'indice non dovrebbe ancora saperlo, quindi un conteggio host zero non risponde a nulla. Scrivilo e lascia la domanda sull'indice per dopo.
Un utile test del giorno 0 è se l'HTML recuperato contiene la stringa esatta dell'anchor dall'ordine. Se sì, la riga è pass-pending. Se no, la riga fallisce prima ancora che arrivi la domanda sull'indice.
Nel lotto inventato l'indice si è aggiornato al giorno 22, quindi il giorno 30 è il primo sguardo onesto sull'elenco degli host. Gli host che appaiono ora confermano il posizionamento. Gli host che ancora non appaiono sono candidati per la colonna in attesa, e il checkpoint successivo li decide.
L'ultimo checkpoint cerca derive: un valore rel cambiato, un anchor spostato o una pagina che ora fa redirect. Confronta ogni riga con il giorno 30, non solo con l'ordine, così un cambiamento si manifesta come un cambiamento.
Il giorno 60 è anche il punto naturale per verificare se le sostituzioni sono ancora entro la finestra, poiché è quando una scadenza non notata tende a scadere.
Un esempio pratico è ordinato. I lotti reali sono più disordinati in modi che una tabella inventata non può mostrare, ed è utile nominare questi aspetti prima di copiare il layout.
Un host può cambiare proprietario tra i checkpoint, con nuovi contenuti e un nuovo template. Il link potrebbe essere ancora live, ma non trovarsi più su un tipo di sito descritto nell'ordine. Confronta il titolo della pagina e il blocco autore, non solo l'URL.
Un cambio di proprietario non fa fallire automaticamente la riga, ma cambia ciò che la riga dimostra.
Aggiungi il controllo della proprietà alle regole del verdetto se il tuo lotto è abbastanza lungo da renderlo rilevante.
Alcune pagine mostrano un link solo in un modulo rotante, una sidebar che cambia per visita o un elenco tagliato agli elementi più recenti. Il recupero può non catturare l'anchor in un'esecuzione e catturarlo nella successiva. Quando una riga fallisce una volta, recuperala due volte lo stesso giorno e registra entrambi i risultati. Tieni una nota della rotazione nella riga, poiché un risultato in attesa da un modulo rotante non è lo stesso di un link mancante.
Un lotto che mescola lingue rende più difficile il controllo dell'anchor, perché l'anchor potrebbe essere tradotto o flesso nella pagina donatrice. Confrontalo con la formulazione concordata nell'ordine e segna la lingua accanto alla riga così un revisore sappia perché differisce.
Questo esempio di audit backlink è un modello, non un risultato. La sua struttura si trasferisce a qualsiasi ordine. I suoi numeri no, e nessuno dovrebbe leggerli come un benchmark.
La tabella dei checkpoint, l'elenco dei crediti e le regole del verdetto si trasferiscono a un nuovo lotto. I conteggi no. Sostituisci ogni cifra inventata con la tua prima che qualcuno legga il risultato. Mantieni le date dei checkpoint nella forma giorno 0, giorno 30 e giorno 60, così un revisore può abbinare il tuo foglio a questa pagina a colpo d'occhio.
Scrivi le regole del verdetto prima del primo recupero e non modificarle quando una riga delude. Una regola cambiata dopo il risultato è una disputa in attesa di accadere.
Se il contratto del fornitore fa riferimento alle stesse regole, entrambe le parti leggono lo stesso testo. Una riga in attesa significa allora ciò che dice il contratto e l'argomento passa dall'interpretazione all'evidenza.
Un ordine di 40 righe ha costato 9 crediti nell'esempio. Un ordine più grande cambia il numero di chiamate, non il metodo. Conta le chiamate per checkpoint, moltiplica e verifica che il totale si adatti ancora al budget che hai impostato. Il recupero è ancora per link, quindi il tempo di lettura cresce con le righe mentre la linea dei crediti si muove appena.
