Проверка обратных ссылок: pagerank или DR: что хранить в поле

Почему PageRank не подходит в качестве поля

Люди по-прежнему ищут инструмент проверки обратных ссылок PageRank, но публичное число исчезло. Google убрал отображение PageRank в панели инструментов в 2016 году, и официального заменителя от Google так и не появилось.

Остались только оценки вендоров. У Ahrefs есть DR, у Moz — DA, а мы публикуем нашу собственную Domain Rating с открытой формулой. Выберите одну и придерживайтесь её. Смешивание двух в одном столбце делает все последующие сравнения бессмысленными.

Практическое правило для команд, использующих headless-подход: храните то, что будете отображать или фильтровать, и ничего лишнего. Каждое дополнительное поле — это еще одна возможность для редактора ошибиться, еще один столбец в экспорте и еще одно поле, которое сломается при миграции с одной CMS на другую.

Название имеет значение. Назовите поле link_dr, а не authority. Первое говорит о том, чье это число. Второе побуждает кого-то заменить его оценкой другого вендора через год.

Название поля должно отражать его источник

Всегда называйте поле по имени вендора, который предоставил число. Поле с названием link_dr подскажет следующему читателю, откуда взялась цифра, и предотвратит тихую замену на оценку другого вендора в будущем.

Переносится только метка, а не число. DR от Ahrefs, DA от Moz и наша собственная Domain Rating — это разные измерения, поэтому значение, скопированное из одного источника в поле, названное в честь другого, введет следующего читателя в заблуждение.

Можно ли хранить оценки двух вендоров?

Можно, в двух полях с двумя названиями. Большинству команд это не нужно, потому что два числа провоцируют сравнение, а именно на этом этапе чаще всего возникает ошибка.

Если стейкхолдер запросит оба показателя, покажите им две формулы рядом. Шкалы устроены по-разному, и эта разница объясняет большинство недоумений.

Одинаковы ли оценки в разных инструментах?

Нет. DR из одного инструмента и DA из другого основаны на разных графах ссылок и разных формулах, поэтому они могут указывать в одном направлении, но расходиться в числах.

Наша формула публичная. Логарифмическая шкала — причина, по которой скачок с 1,000 до 100,000 ссылающихся доменов влияет на оценку меньше, чем можно было бы ожидать по сырым счетам.

Что таблица говорит о дизайне полей

Шкала логарифмическая. Разница между 10 и 1,000 доменами составляет 27 баллов, а между 1,000 и 100,000 — такая же. Поэтому храните целое число, но воспринимайте его в виде диапазонов.

Поле с диапазоном часто помогает редактору больше, чем сырое число. Никто не может принять решение, ориентируясь на 41 против 43. Но он может действовать по метке «средний». Держите всё просто.

Даты важны не меньше оценок. Сохраненная оценка без даты выглядит как актуальные данные, и через год кто-то может процитировать её на совещании как факт. Поставьте отметку и обновляйте её по графику, который можно назвать, например, по ночному bulk_dr сканированию из таблицы стоимости.

Поле заметки должно оставаться простым, потому что его задача невелика. Одного предложения достаточно. Его задача — напомнить читателю, что индекс обновляется примерно раз в месяц, а Google Search Console содержит собственную оценку Google.

Поддержание честности поля с течением времени

Поле, которое заполняется один раз и больше не обновляется, незаметно превращается в факт о прошлом. Задача обновления — сохранять статус данных как текущего показания, и она должна выполняться по графику, который можно описать одним предложением.

Начинайте с графика, потому что он определяет всё остальное. Ежемесячное обновление соответствует ритму индекса, а ночные запуски добавляют затраты без добавления информации, так как индекс обновляется примерно раз в месяц.

Как часто следует обновлять оценку?

Ежемесячно в большинстве случаев, так как это ритм, которому следует индекс. Ночные сканирования всё ещё имеют смысл для команд, которым нужна свежая дата в каждой записи, даже если число не изменилось.

Стоимость — не причина для сдерживания. Ночной вызов bulk_dr для до 2,000 доменов стоит один кредит, а остальное указано в таблице стоимости.

Что должна делать задача при отсутствии значения?

Оставьте старую оценку и старую дату на месте, а попытку отметьте как неудачную в своем журнале. Запись пустого значения поверх хорошего показания выглядит аккуратно, но стирает единственную историю, которая у вас есть.

Отсутствие значения и ноль — это разные факты. Ваш тип поля должен разделять их, чтобы редактор никогда не воспринимал пробел как плохую оценку.

Как удерживать каждую партию в пределах лимита?

Разбейте список на части не более чем по 2,000 доменов и отправляйте один вызов на каждую часть. Храните размер части в одной константе, чтобы изменение лимита затронуло одну строку.

Логгируйте количество отправленных доменов и количество сохраненных показаний. Расхождение между ними — первый признак того, что партия дала сбой.

Что редактор должен видеть рядом с оценкой

Редактор читает поле за несколько секунд, поэтому поле должно отвечать за несколько секунд. Сначала показывайте диапазон, затем дату и в конце целое число, так как это порядок, в котором они нужны занятому читателю.

Название имеет такое же значение, как и макет. Поле с названием link_dr_band, которое показывает «средний», ничего не говорит об индексе, поэтому рядом должна быть заметка с этим уточнением.

Должен ли диапазон окрашивать запись?

Цветной бейдж может помочь занятому редактору, но он также может заставить воспринимать среднее показание как провал. Ограничьте цвета названиями диапазонов и избегайте красного для всего, кроме серьезных проблем.

Диагноз — это совет для проверки, а не правило для публикации. Укажите это в метке рядом, чтобы зеленый или янтарный бейдж никогда не воспринимался как прохождение.

Когда один и тот же диапазон встречается на многих записях, сначала проверьте правило, а затем записи. Диапазон, который отмечает половину сайта, обычно говорит вам о пороге, а не о контенте.

Что писать в заметке, если дата устарела?

Устаревшая дата должна менять заметку, а не скрывать оценку. Строка, которая говорит, что показание старше последнего обновления, подскажет редактору, что делать, а именно — проверить снова, прежде чем полагаться на него.

Генерируйте эту строку в коде, чтобы каждая запись содержала её одинаково. Рукописные заметки со временем размываются, и через несколько месяцев никто не помнит, что они должны были означать.