Pemeriksa tautan buruk: membandingkan snapshot di SQLite
Tidak ada skrip yang bisa menyatakan tautan beracun bagi Anda. Skrip hanya bisa memberi tahu domain pengacu mana yang baru, mana yang hilang, dan mana yang terlihat aneh sehingga perlu dibaca secara manual.
Tim editorial Linkzoid ·
Tabel tingkat keparahan untuk domain pengacu baru
Aturan praktis kami untuk triase, bukan definisi Google
Tingkat
Sinyal
Tindakan
Abaikan
Domain baru, DR di atas 30, anchor adalah merek Anda atau URL telanjang
Catat, lanjutkan
Periksa
50 atau lebih domain baru dalam seminggu dari satu TLD yang tidak pernah Anda targetkan
Buka sepuluh di antaranya
Periksa dengan cermat
Anchor exact-match yang sama pada 20 atau lebih domain baru
Periksa awan anchor, temukan sumbernya
Aksi
Jaringan yang terlihat berbayar atau halaman yang diretas mengarah ke Anda
Dokumentasikan; pertimbangkan file disavow hanya jika Anda juga memiliki tindakan manual
Tunggu
Domain hilang bulan ini
Periksa ulang setelah pembaruan bulanan berikutnya
Mengapa melakukan diff daripada pemindaian sekali
Satu snapshot memberi tahu Anda apa yang ada. Diff memberi tahu Anda apa yang berubah, dan di situlah masalah muncul.
Google telah mengatakan selama bertahun-tahun, sejak rilis Penguin 4.0 pada September 2016 dan lagi dalam pembaruan spam tautan Desember 2022, bahwa mereka sebagian besar mengabaikan tautan spam daripada menghukumnya. SpamBrain melakukan pekerjaan itu. Jadi, banjir sampah lebih sering menjadi gangguan daripada ancaman, dan diff terutama menyelamatkan Anda dari bereaksi terhadap gangguan.
Jaga riwayat Anda sendiri. Suite menimpa milik mereka.
Buat tabel riwayat dalam empat langkah
Diff hanya berfungsi jika setiap hasil masuk ke tabel yang sama, dengan bentuk yang sama. Langkah-langkah ini menjaganya tetap demikian.
01
Buat tabel sekali
Jalankan pernyataan create-if-not-exists dengan kolom yang Anda butuhkan: hari, domain, dan skor. Simpan di dalam skrip, agar mesin baru dapat membangun ulang tabel yang sama tanpa langkah manual.
02
Sisipkan satu baris per domain per hari
Gunakan sisipan terparameterisasi dan commit sekali per hasil. Satu commit mencegah crash meninggalkan setengah hari di file.
03
Lindungi terhadap hasil kedua
Hapus baris hari tersebut sebelum menyisipkan, atau tambahkan kunci unik pada hari dan domain. Hasil ulang pada hari yang sama kemudian akan menggantikan baris tersebut daripada menggandakannya.
04
Bandingkan dengan hari sebelumnya di file
Pilih tanggal sebelumnya terbaru dengan filter max(day), bukan tanggal kemarin. Perbandingan tetap benar ketika seminggu dilewati.
diff.py
Dua tabel akan lebih rapi. Satu cukup untuk pengaturan hobi: satu baris per domain per tanggal snapshot.
python
import json, sqlite3, sys, datetime
db = sqlite3.connect('links.db')
db.execute('create table if not exists snap(day text, dom text, dr int)')
rows = json.load(open(sys.argv[1]))
day = datetime.date.today().isoformat()
db.executemany('insert into snap values (?,?,?)',
[(day, r.get('domain'), r.get('dr')) for r in rows])
db.commit()
prev = db.execute('select max(day) from snap where day < ?', (day,)).fetchone()[0]
if prev:
new = db.execute('select dom from snap where day=? except select dom from snap where day=?', (day, prev)).fetchall()
gone = db.execute('select dom from snap where day=? except select dom from snap where day=?', (prev, day)).fetchall()
print(len(new), 'new,', len(gone), 'gone')
Pemecahan masalah diff
Gejala
Penyebab yang mungkin
Perbaikan
Ratusan 'hilang' semalam
Pembaruan indeks menukar sampel
Bandingkan bulanan, bukan harian
Setiap domain terlihat baru
Tabel kosong atau format day berubah
Periksa select distinct day
Kolom DR semua NULL
Nama bidang baris berbeda dari dr
Cetak satu baris mentah dan sesuaikan
Duplikat setelah hasil ulang
Hari yang sama disisipkan dua kali
Hapus hari itu terlebih dahulu, atau tambahkan kunci unik
Ambang batas yang disalin dari postingan blog adalah tebakan tentang situs orang lain. Pemeriksa tautan buruk hanya seefektif batasnya, dan riwayat Anda sendiri memberi tahu Anda apa yang normal untuk domain Anda.
Mulailah dengan mencatat beberapa bulan tanpa melakukan tindakan apa pun. Biarkan stabil. Kemudian tuliskan fluktuasi mingguan yang khas. Hanya setelah itu Anda menetapkan batas dalam tabel tingkat keparahan.
Mulai dengan garis dasar
Catat jumlah baru dan hilang untuk setiap hasil tanpa bereaksi terhadapnya. Beberapa bulan pencatatan tenang memberi Anda rentang yang milik domain Anda dan bukan milik orang lain.
Setelah garis dasar ada, satu minggu buruk menonjol melawannya, dan Anda dapat menjelaskan perbedaannya tanpa menebak. Itulah tujuan keseluruhan dari garis dasar.
Pilih satu alarm per sinyal
Setiap sinyal dalam tabel memiliki satu ambang batas, satu pemilik, dan satu tindakan. Sinyal dengan tiga alarm adalah sinyal yang tidak dibaca siapa pun, dan alarm-alarm tersebut akhirnya diabaikan bersama-sama.
Tulis alarm di samping sinyalnya dalam kode, agar tabel di halaman ini dan skrip tidak pernah berbeda.
Tinjau ulang batas setiap kuartal
Situs Anda berkembang, begitu pula normalnya. Periksa ulang batas setiap tiga bulan, dan tuliskan alasannya di samping setiap perubahan, agar riwayat menjelaskan dirinya sendiri nanti.
Membaca tabel tingkat keparahan dalam praktik
Tabel adalah alat bantu triase, bukan penghakiman. Setiap baris memberi tahu Anda di mana harus melihat, dan kolom tindakan menjaga Anda dari mengambil file disavow dalam keadaan panik.
Kerjakan dari atas. Sebagian besar minggu berakhir di Abaikan atau Periksa. Baris Periksa memulai beberapa menit membaca, dan baris Periksa dengan cermat memulai tinjauan yang lebih lama terhadap anchor. Jangan melewatkan baris karena minggu sibuk. Baris yang dilewati adalah minggu di mana banjir tidak terdeteksi.
Ambil sampel sebelum memutuskan
Buka sepuluh domain yang ditandai dan baca halamannya. Banjir yang ternyata menjadi satu pengikis direktori adalah masalah yang berbeda dari banjir blog tidak terkait, dan hanya halaman yang membedakan mereka.
Catat apa yang Anda putuskan
Simpan satu baris per keputusan: domain, tingkat, apa yang Anda periksa dan apa yang Anda lakukan. Orang berikutnya yang membaca log, termasuk Anda di masa depan, mendapatkan alasan tanpa rapat.
Ringkasan bulanan dari baris-baris itu membutuhkan sedikit waktu, dan itu menjadi draf tinjauan yang baik.
Apa yang tidak bisa diberitahu ini
Ini tidak bisa membuktikan tautan merugikan Anda. Tidak ada orang di luar Google yang bisa, dan laporan tindakan manual Search Console adalah satu-satunya tempat penalti dinyatakan.
Ini juga tidak bisa melihat tautan yang lebih muda dari pembaruan terakhir. Untuk bukti yang lebih segar, mintalah kepada orang yang menjalankan situs penghubung, atau baca log server Anda untuk perujuk. Catatan kami tentang waktu membahas lebih dalam.
Jika Anda ingin sisi anchor, anchor_cloud berharga 2 kredit dan mengelompokkan teks berdasarkan frekuensi, yang merupakan cara tercepat untuk menumpuk exact-match.
Tautan yang tiba di antara pembaruan
Apa pun yang lebih muda dari pembaruan terakhir hilang dari kedua sisi diff. Tautan yang muncul dan menghilang di dalam satu jendela pembaruan tidak pernah ditampilkan sama sekali, itulah mengapa perbandingan harus berjalan bulanan.
Anchor yang terlihat salah bagi Anda
Diff melihat domain, bukan kalimat di sekitar tautan. Dua anchor identik di dua halaman berbeda bisa berarti hal yang sangat berbeda, jadi pertahankan pemeriksaan anchor sebagai langkah manual terpisah.
Pilihan penyimpanan untuk pengaturan hobi
SQLite adalah basis data paling sederhana yang masih menjawab pertanyaan diff dengan satu kueri. Ini hidup dalam satu file, jadi cocok di repo atau folder cadangan tanpa server.
File JSON bertanggal juga berfungsi. Lebih lambat untuk dikueri, tetapi lebih mudah dibuka di editor teks ketika ada yang terlihat salah. Bagaimanapun, salin penyimpanan ke tempat kedua sebelum pembersihan apa pun, dan simpan salinan selama satu kuartal penuh sebelum Anda menghapus apa pun.
Kapan satu file sudah cukup
Satu tabel dengan kolom hari mencakup satu situs selama bertahun-tahun. File tetap kecil, dan kueri di halaman ini tidak perlu penyetelan.
Kapan harus pindah ke server
Setelah beberapa orang menulis ke riwayat yang sama, file di satu mesin menjadi hambatan. Pada titik itu, basis data terkelola adalah pilihan yang jujur, dan skema tetap sama.
Sampai saat itu, file di repo adalah hal paling sederhana yang bertahan dari perubahan laptop.
Menghubungkan diff ke pekerjaan mingguan
Jalankan diff.py tepat setelah langkah snapshot. Cetak hitungan, dan keluar dengan kode non-nol ketika new melewati batas yang Anda pilih, katakanlah 200 dalam seminggu untuk situs kecil. Pekerjaan berubah menjadi merah, dan GitHub mengirim email kepada Anda. Sederhana.
Pilih batas dari riwayat Anda sendiri. Setelah dua bulan Anda tahu apakah 15 domain baru seminggu itu normal atau lonjakan, dan angka tetap yang disalin dari postingan blog adalah tebakan.
Minggu tenang adalah norma.
Pertanyaan tautan buruk, dijawab secara langsung
Apakah ada pemeriksa tautan masuk buruk yang andal?
Tidak ada alat yang bisa menandai tautan berbahaya dengan pasti, karena hanya Google yang tahu bagaimana ia memperlakukan masing-masing. Skrip dapat menyoroti pola yang layak dibaca: banjir tiba-tiba, anchor exact yang berulang, TLD aneh. Anda membuat panggilan setelah membuka halaman.
Haruskah saya disavow apa yang ditandai diff?
Jarang. Google telah mengatakan bahwa mereka sebagian besar mengabaikan tautan spam, dan file disavow dimaksudkan untuk kasus seperti tindakan manual atau kekacauan tautan berbayar yang Anda buat sendiri. Dokumentasikan terlebih dahulu, dan periksa Search Console sebelum Anda menyerahkan apa pun.
Seberapa sering saya harus menjalankannya?
Snapshot mingguan, tinjauan bulanan. Pembaruan indeks terjadi sekitar sebulan sekali, jadi diff harian sebagian besar membandingkan tabel dengan dirinya sendiri. Tinjauan bulanan cocok dengan data dan mengurangi gangguan.
Kolom mana yang harus disimpan tabel?
Simpan hari, domain, DR, dan kolom sumber. Tambahkan anchor hanya jika Anda juga menarik anchor. Lebih banyak kolom terasa menyeluruh, tetapi setiap bidang tambahan adalah bidang lain yang bisa menyimpang di antara hasil.
Bisakah saya melakukan diff dua suite terhadap satu sama lain?
Anda dapat membandingkan hitungan mereka untuk situs yang sama, tetapi dua hasil tidak akan cocok. Jalankan diff di dalam satu sumber, dan bandingkan arah perubahan di seluruh sumber, aturan yang sama yang berlaku di mana saja di situs ini.
Bagaimana jika domain pergi dan kemudian kembali bulan berikutnya?
Itu ditampilkan sebagai hilang dan kemudian sebagai baru, yang merupakan gangguan. Hitung kembali secara terpisah, atau bandingkan tiga bulan sekaligus, sehingga domain yang hilang untuk satu pembaruan tidak memicu tinjauan.
