Жоден скрипт не може назвати посилання токсичним саме для вас. Він може показати, які реферуючі домени з’явилися, які зникли та які виглядають дивно і потребують ручного огляду.
Редакція Linkzoid ·
Таблиця серйозності для нових реферуючих доменів
Наші власні евристичні правила для тріажу, а не визначення від Google
Рівень
Сигнал
Дія
Ігнорувати
Новий домен, DR вище 30, якір — ваш бренд або чистий URL
Зафіксувати та рухатися далі
Перевірити
50 або більше нових доменів за тиждень з одного TLD, на який ви ніколи не цільовали
Відкрити десять з них
Уважно перевірити
Однаковий точний якір на 20 або більше нових доменах
Перевірити хмару якірів, знайти джерело
Діяти
Схожа на платну мережа або зламаний сторінки, що посилаються на вас
Задокументувати; розглянути файл disavow лише якщо у вас також є ручна дія
Зачекати
Домен зник цього місяця
Перевірити знову після наступного щомісячного оновлення
Чому diff замість одноразового сканування
Один знімок показує, що є. Diff показує, що змінилося, і саме там виявляються проблеми.
Google каже вже багато років, з моменту виходу Penguin 4.0 у вересні 2016 року та знову під час оновлення спаму посилань у грудні 2022 року, що він переважно ігнорує спамні посилання, а не карає за них. Цим займається SpamBrain. Тому потік сміття частіше є шумом, ніж загрозою, а diff головним чином захищає вас від реакції на шум.
Ведіть власну історію. Пакети перезаписують свої дані.
Побудова таблиці історії за чотири кроки
Diff працює лише тоді, коли кожен запуск потрапляє в одну й ту саму таблицю в однаковій формі. Ці кроки забезпечують це.
01
Створити таблицю один раз
Запустіть оператор create-if-not-exists з потрібними стовпцями: день, домен та рейтинг. Залиште його в скрипті, щоб нова машина могла відновити ту саму таблицю без ручних дій.
02
Вставити один рядок на домен на день
Використовуйте параметризовану вставку та фіксуйте транзакцію один раз за запуск. Одна фіксація запобігає залишенню частини дня у файлі у разі збою.
03
Захист від повторного запуску
Видаліть рядки за день перед вставкою або додайте унікальний ключ за днем і доменом. Повторний запуск в той самий день замінить рядки, а не подвоїть їх.
04
Порівняти з попереднім днем у файлі
Оберіть найдавнішу попередню дату з фільтром max(day), а не вчорашню дату. Порівняння залишиться коректним, якщо тиждень було пропущено.
diff.py
Дві таблиці були б акуратнішими. Однієї достатньо для домашнього налаштування: рядок на домен на дату знімку.
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')
Усунення несправностей diff
Симптом
Ймовірна причина
Виправлення
Сотні «зниклих» за ніч
Оновлення індексу змінило вибірку
Порівнюйте щомісячно, а не щодня
Кожен домен виглядає новим
Таблиця була порожньою або формат day змінився
Перевірте select distinct day
Стовпець DR повністю NULL
Ім’я поля рядка відрізняється від dr
Виведіть один сирій рядок та відрегулюйте
Дублікати після повторного запуску
Один і той самий день вставлено двічі
Спочатку видаліть той день або додайте унікальний ключ
Порог, скопійований з блогу, — це припущення щодо чужого сайту. Перевірка поганих посилань корисна лише настільки, наскільки корисні її ліміти, а ваша власна історія показує, що є нормою для вашого домену.
Почніть із логування кілька місяців без дій. Дайте системі встановитися. Потім запишіть типові тижневі коливання. Тільки після цього встановлюйте ліміти в таблиці серйозності.
Почніть з базового рівня
Записуйте кількість нових і зниклих доменів для кожного запуску без реакції на них. Кілька місяців тихого логування дають вам діапазон, який належить саме вашому домену, а не чиємусь іншому.
Коли базовий рівень існує, одна погана тиждень виділяється на його тлі, і ви можете пояснити різницю без припущень. Це і є вся суть базового рівня.
Оберіть один сигнал тривоги на сигнал
Кожен сигнал у таблиці отримує один поріг, одного власника та одну дію. Сигнал з трьома сигналами тривоги — це сигнал, який ніхто не читає, і всі тривоги ігноруються разом.
Запишіть сигнал тривоги поруч із його сигналом у коді, щоб таблиця на цій сторінці та скрипт ніколи не суперечили один одному.
Переглядайте ліміти щокварталу
Ваш сайт росте, і зростає його норма. Перевіряйте ліміти кожні три місяці та записуйте причину поруч із будь-якою зміною, щоб історія пояснювала сама себе пізніше.
Читання таблиці серйозності на практиці
Таблиця — це помічник для тріажу, а не вирок. Кожен рядок показує, куди дивитися, а стовпець «Дія» не дає вам у паніці витягнути файл disavow.
Робіть від верху. Більшість тижнів закінчуються на «Ігнорувати» або «Перевірити». Рядок «Перевірити» починає кілька хвилин читання, а рядок «Уважно перевірити» — довший огляд якірів. Не пропускайте рядки, якщо тиждень був зайнятим. Пропущений рядок — це тиждень, коли потік залишився непоміченим.
Вибірка перед рішенням
Відкрийте десять позначених доменів і прочитайте сторінки. Потік, який виявляється одним скрейпером каталогу, — це інша проблема, ніж потік незалежних блогів, і лише сторінки дозволяють їх розрізнити.
Зафіксуйте своє рішення
Зберігайте один рядок на рішення: домен, рівень, що ви перевірили і що зробили. Наступна людина, яка прочитає лог, включаючи майбутнього вас, отримає обґрунтування без зустрічі.
Щомісячний звіт із цих рядків займає мало часу і є гарною першою чергою для огляду.
Що це не може показати
Воно не може довести, що посилання шкодить вам. Ніхто, крім Google, не може, а звіт про ручні дії в Search Console — єдине місце, де вказано штраф.
Воно також не бачить посилань молодших за останнє оновлення. Для свіжіших доказів запитайте людей, які керують сайтом-джерелом, або прочитайте логи сервера щодо реферерів. Наш запис про таймінг йде глибше.
Якщо вам потрібна сторона якірів, anchor_cloud коштує 2 кредити і групує текст за частотою, що є найшвидшим способом виявити скупчення точних збігів.
Посилання, що з’являються між оновленнями
Все, що молодше за останнє оновлення, відсутнє в обох частинах diff. Посилання, яке з’являється і зникає всередині одного вікна оновлення, взагалі не показується, чому порівняння слід запускати щомісяця.
Якорі, які виглядають неправильно для вас
Diff бачить домен, а не речення навколо посилання. Два однакових якорі на двох різних сторінках можуть означати дуже різні речі, тому тримайте перевірку якоря як окремий ручний крок.
Вибір сховища для домашнього налаштування
SQLite — найпростіша база даних, яка все ще відповідає на питання diff одним запитом. Вона живе в одному файлі, тому вміщується в репозиторій або папку резервного копіювання без сервера.
Файли JSON з датою також працюють. Їх повільніше запитувати, але легше відкрити в текстовому редакторі, коли щось виглядає неправильно. В будь-якому випадку, скопіюйте сховище в друге місце перед будь-яким очищенням і зберігайте копію повний квартал, перш ніж видаляти щось.
Коли одного файлу достатньо
Одна таблиця зі стовпцем дня покриває один сайт на роки. Файл залишається невеликим, а запити на цій сторінці не потребують налаштування.
Коли перейти на сервер
Коли кілька людей пишуть в одну історію, файл на одній машині стає вузьким місцем. У цей момент керована база даних — чесний вибір, а схема залишається тією ж.
До цього часу файл у репозиторії — найпростіша річ, яка переживе зміну ноутбука.
Підключення diff до тижневого завдання
Запустіть diff.py одразу після кроку знімка. Виведіть кількості та вийдіть з ненульовим кодом, коли new перевищує ліміт, який ви обрали, скажімо, 200 за тиждень для малого сайту. Завдання стане червоним, і GitHub надішле вам лист. Просто.
Оберіть ліміт на основі власної історії. Після двох місяців ви будете знати, чи є 15 нових доменів на тиждень нормою або спайком, і будь-яке фіксоване число, скопійоване з блогу, — це припущення.
Тихі тижні — це норма.
Питання про погані посилання, відповіді просто
Чи існує надійний перевірювач поганих посилань?
Жоден інструмент не може з упевненістю позначити посилання шкідливим, бо лише Google знає, як він ставиться до кожного з них. Скрипт може виявити патерни, варті читання: раптові потоки, повторення точних якірів, дивні TLD. Ви приймаєте рішення після відкриття сторінок.
Чи варто disavow те, що позначає diff?
Рідко. Google казав, що він переважно ігнорує спамні посилання, а файл disavow призначений для випадків, таких як ручна дія або безлад з платними посиланнями, який ви створили самі. Спочатку задокументуйте, а потім перевірте Search Console, перш ніж надсилати щось.
Як часто я повинен його запускати?
Знімок щотижня, огляд щомісяця. Індекс оновлюється приблизно раз на місяць, тому щоденний diff переважно порівнює таблицю саму з собою. Щомісячний огляд відповідає даним і зменшує шум.
Які стовпці повинна зберігати таблиця?
Зберігайте день, домен, DR та стовпець джерела. Додайте якір лише якщо ви також витягуєте якорі. Більше стовпців здається ретельним, але кожне додаткове поле — це ще одне, яке може змінюватися між запусками.
Чи можу я diff двох пакетів один проти одного?
Ви можете порівняти їхні кількості для одного сайту, але два результати не збігатимуться. Запустіть diff всередині одного джерела та порівнюйте напрямок змін між джерелами, те саме правило, яке застосовується всюди на цьому сайті.
Що, якщо домен залишає і повертається наступного місяця?
Він показується як зниклий, а потім як новий, що є шумом. Рахуйте повернення окремо або порівнюйте три місяці одночасно, щоб домен, який випав на одне оновлення, не запускав огляд.
