Маппінг полів

Перевірка зворотних посилань: PageRank чи DR: що зберігати в полі

Ваша модель контенту потребує одного числа, однієї дати та одного примітки. Ця сторінка показує дизайн поля та робочий приклад із формулою DR.

Дослідницька команда Contentin · Оновлено 2026-10-29

Мініатюрні латунні терези, що порівнюють дві різні ваги з металу, що представляють метрики ранжування

Чому PageRank не є варіантом поля

Люди досі шукають інструмент перевірки зворотних посилань PageRank, але публічне число зникло. Google видалив відображення PageRank у панелі інструментів у 2016 році, і жодної заміни від самого Google так і не з'явилося.

Що залишилося — це оцінки постачальників. Ahrefs має DR, Moz має DA, а ми публікуємо власний Domain Rating із відкритою формулою. Оберіть один і дотримуйтесь його. Поєднання двох у стовпці робить будь-яке подальше порівняння безглуздим.

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

Найменування має значення. Назвіть поле link_dr, а не authority. Перше вказує, чиє це число. Друге спонукає когось замінити його оцінкою іншого постачальника через рік.

Найменування поля після його джерела

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

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

Чи можна зберігати оцінки двох постачальників?

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

Якщо зацікавлена сторона просить обидва, покажіть їм дві формули поруч. Шкали побудовані по-різному, і ця різниця пояснює більшість здивувань.

Чи однакова оцінка в різних інструментах?

Ні. DR з одного інструмента та DA з іншого походять з різних графів посилань і різних формул, тому вони можуть вказувати в одному напрямку, але все одно розходитися в цифрах.

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

Практичний приклад: формула на п'яти вигаданих доменах

Кількості посилальних доменів вигадані для ілюстрації. Формула: round(100 · log(ref_domains+1) / log(2·10^7)).
Вигаданий домен	Посилальні домени	DR	Запропонована смуга
tiny-docs.example	10	14	Низький
small-saas.example	50	23	Низький
mid-blog.example	1,000	41	Середній
big-publisher.example	100,000	68	Високий
theoretical-top.example	20,000,000	100	Високий

Крокова кам'яна сходища з кольоровими блоками, що ілюструють логарифмічне зростання смуг

Що таблиця каже про дизайн поля

Шкала є логарифмічною. Десять доменів і 1 000 доменів розділені на 27 балів, тоді як 1 000 і 100 000 мають таку ж відстань знову. Тому зберігайте ціле число, але читайте його смугами.

Поле смуги часто допомагає редактору більше, ніж сире число. Ніхто не може діяти на основі 41 проти 43. Вони можуть діяти на основі мітки, яка каже «середній». Залишайте його простим.

Дати мають таке ж значення, як і оцінки. Збережена оцінка без дати виглядає як поточне показання, і через рік хтось цитуватиме її на зустрічі, ніби це так і є. Поставте штамп і оновлюйте її за графіком, який ви можете назвати, наприклад, нічним запуском bulk_dr з таблиці витрат.

Поле примітки має залишатися простим, оскільки його завдання невелике. Однієї достатньо. Його завдання — нагадати читачеві, що індекс оновлюється приблизно щомісяця, а Google Search Console містить власне бачення Google.

Збереження поля в чесному стані з часом

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

Почніть з графіка, оскільки він визначає все інше. Щомісячне оновлення відповідає індексу, а нічні запуски додають витрати без додавання інформації, оскільки індекс оновлюється приблизно раз на місяць.

Як часто має оновлюватися оцінка?

Щомісяця, у більшості випадків, оскільки це ритм, якому слідує індекс. Нічні запуски все ще мають сенс для команди, яка хоче свіжу дату в кожному записі, навіть коли число не змінилося.

Витрати — не причина, щоб стримуватися. Нічний виклик bulk_dr до 2 000 доменів коштує один кредит, а таблиця витрат перелічує решту.

Що має робити завдання з відсутнім значенням?

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

Відсутнє значення та нуль — це різні факти. Ваш тип поля має розрізняти їх, щоб редактор ніколи не сприймав прогалину як погану оцінку.

Як утримати кожну партію в межах ліміту?

Розділіть список на частини не більше ніж по 2 000 доменів і надсилайте один виклик на частину. Зберігайте розмір частини в одній константі, щоб зміна ліміту торкнулася одного рядка.

Журналізуйте кількість надісланих доменів та кількість збережених показань. Нерівність між ними — перша ознака того, що партія дала збій.

Що має бачити редактор поруч із оцінкою

Редактор читає поле за кілька секунд, тому поле має відповідати за кілька секунд. Показуйте смугу першою, дату другою та ціле число останнім, оскільки це порядок, у якому потрібні вони зайнятому читачеві.

Мітка має таке ж значення, як і макет. Поле з назвою link_dr_band, яке каже «середній», нічого не повідомляє читачеві про індекс, тому примітка поруч із ним має містити це застереження.

Чи має смуга фарбувати запис?

Кольоровий бейдж може допомогти зайнятому редактору, але він також може змусити середнє показання виглядати як невдача. Залишайте кольори для назв смуг і уникайте червоного для будь-чого, крім серйозної проблеми.

Смуга — це порада для огляду, а не правило для публікації. Скажіть це в мітці поруч із нею, щоб зелений або янтарний бейдж ніколи не сприймався як успіх.

Коли одна й та сама смуга з'являється на багатьох записах, перевірте правило перед тим, як перевіряти записи. Смуга, яка позначає половину сайту, зазвичай повідомляє вам про поріг, а не про контент.

Що писати в примітці, якщо дата стара?

Стара дата має змінити примітку, а не приховати оцінку. Рядок, який каже, що показання старіше за останнє оновлення, повідомляє редактору, що робити, а саме — перевірити знову перед довірою до нього.

Генеруйте цей рядок у своєму коді, щоб кожен запис говорив це однаково. Вручну написані примітки розходяться, і через кілька місяців ніхто не пам'ятає, що вони мали означати.

Ескіз моделі контенту

Назви полів наведені нами для ілюстрації. Contentful, Sanity, Strapi та Payload оголошують поля по-своєму, тому перекладіть.

json

{
  "link_dr": 41,
  "link_dr_band": "middle",
  "link_checked_on": "2026-10-29",
  "link_check_note": "Index refreshes monthly. Verify in Search Console."
}

Дерев'яна лоток для сортування з чотирма відсіками, що приймають насипані дорогоцінні камені

Маппінг відповіді в ці чотири поля

1
Викличте безкоштовну дію один раз
Запустіть overview на відомому домені та прочитайте JSON візуально. Перевірте реальні назви полів у відповіді, оскільки ця сторінка не перелічує їх для вас.
2
Оберіть значення DR
Скопіюйте оцінку від 0 до 100 у поле цілого числа. Відкидайте все поза цим діапазоном, щоб несправна відповідь не могла потрапити в запис.
3
Виведіть смугу у своєму коді
Менше 20 — низький, від 20 до 50 — середній, вище 50 — високий. Пороги є пропозицією і належать вашій команді, а не API.
4
Поставте дату
Запишіть сьогоднішню дату поруч із оцінкою. Індекс оновлюється приблизно щомісяця, тому дата є частиною даних.

Чотири поля та питання, на яке відповідає кожне

Кожне поле відповідає на одне питання, яке запитає редактор.

link_dr

Ціле число від 0 до 100. Воно відповідає на питання, наскільки сильним виглядає домен на шкалі.

link_dr_band

Проста мітка, така як низький, середній або високий. Вона відповідає на питання, чи варто людині подивитися ближче, не змушуючи когось читати число.

link_checked_on

Дата показання. Вона відповідає на питання, наскільки старе число, що важливіше, ніж очікує більшість команд.

link_check_note

Одне речення про індекс. Вона відповідає на те, що не може показати оцінка, наприклад, щомісячне оновлення та затримку для нових посилань.

Поля, які варто пропустити

Сирі рядки зворотних посилань: вони швидко старіють і роздувають запис
Списки якірних текстів, якщо їх не переглядає людина (див. runbook)
Булеве значення pass/fail: воно спонукає до жорсткої блокування
Оцінки постачальників з двох інструментів в одному стовпці

Одне застереження до прикладу

П'ять доменів вище не існують, а кількості обрані лише для того, щоб зробити арифметику видимою. Для реальних чисел запустіть безкоштовний перевірку DR на своєму сайті.