Broken Link Hunter UA: скрипт пошуку дропів у Google Sheets

Завантажити програму

Broken Link Hunter UA 1.6.1 для Google Таблиць.

Комплект містить BrokenLinkHunter.gs, Core.gs, Sidebar.html та українську інструкцію встановлення. Після завантаження ZIP потрібно розпакувати й перенести код у прив’язаний до Google Таблиці проєкт Apps Script. Ключі платних SEO API для основного сценарію не потрібні.

Broken Link Hunter UA: як я шукаю домени через зовнішні посилання й автоматизую рутину SEO-фахівця

У роботі з доменами мене постійно цікавить одне питання: як знаходити більше вартих уваги кандидатів і менше часу витрачати на повторення однакових дій?

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

Так з’явився Broken Link Hunter UA — наша програма для Google Таблиць, яку я розробляв і доопрацьовував разом із ChatGPT під реальні SEO-завдання. Я вже протестував її в роботі. Ми поверталися до помилок, виправляли логіку й доробляли інтерфейс, щоб із програмою було зручно працювати щодня.

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

Яку задачу вирішує Broken Link Hunter

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

Я додаю адреси донорів у таблицю. Програма читає доступний HTML, дістає посилання, визначає зовнішні домени та перевіряє їхній стан через DNS і RDAP.

На виході я отримую кандидатів із джерелом знахідки: де було посилання, на яку адресу воно вело, який мало анкор і які атрибути rel. Далі можу переходити до перевірки історії та SEO-показників.

Важлива особливість: ця версія шукає доменні можливості через посилання. Вона не виконує повний HTTP-аудит кожної зовнішньої сторінки. Помилка 404 на окремому URL активного сайту сама по собі не означає, що домен вільний.

Чому я зробив програму в Google Таблицях

Google Sheets — звичне середовище для нашої роботи з доменами. Тут можна зберігати списки, фільтрувати результати й передавати кандидатів на наступні перевірки.

Broken Link Hunter працює як прив’язаний до таблиці Google Apps Script у середовищі V8. Окремий сервер, Windows-застосунок чи Ahrefs API для його основного сценарію не потрібні. ШІ під час самого сканування також не використовується.

Код розділено на три частини:

У Core уже зібрані потрібні компоненти для розбору даних. Користувачу не потрібно окремо встановлювати npm-пакети.

Як працює пошук: від донора до кандидата

1. Додаю донорів

Вхідний список розміщується у вкладці «BLH Донори», починаючи з A2. Можна додати головну сторінку сайту або конкретний URL.

Для різних задач передбачено два режими:

«Обхід сайту» — програма переходить за внутрішніми посиланнями й, якщо увімкнено відповідну опцію, шукає сторінки через sitemap.

«Лише вказані сторінки» — читає задані сторінки без подальшого обходу внутрішніх посилань.

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

2. Програма читає HTML і дістає посилання

Парсер працює з тегами <a href>. Він враховує відносні адреси, HTML-сутності та тег <base>, нормалізує URL і прибирає фрагмент після #.

Для зовнішнього посилання зберігаються:

домен цілі;

сторінка донора;

повний цільовий URL;

текстовий анкор — до 500 символів;

атрибут rel;

час знаходження.

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

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

3. Внутрішні адреси формують чергу

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

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

Це допомагає не витрачати чергу на очевидні пастки обходу. Водночас частина справжніх сторінок із нетиповими адресами може залишитися поза скануванням — причини пропусків потрібно враховувати під час оцінки покриття.

Sitemap допомагає знаходити більше сторінок

Не до кожного старого матеріалу легко дістатися з головної сторінки. Тому в програмі є окремий пошук через карти сайту.

Для донора перевіряються robots.txt та стандартні адреси sitemap.xml, sitemap_index.xml і wp-sitemap.xml. Також читаються директиви Sitemap: із robots.txt та вкладені карти.

Підтримуються XML-формати urlset, sitemapindex і gzip-стиснення. Звичайні адреси сторінок із карт додаються в чергу, а вкладені карти — у власну чергу sitemap. Адреси зображень і відео не підміняють адреси сторінок.

Карти обробляються невеликими пакетами. Якщо черга активного донора вже містить щонайменше 50 000 сторінок у стані очікування, додавання через нові sitemap тимчасово стримується. Спочатку програма дає можливість опрацювати накопичену чергу.

Як перевіряється домен: DNS і RDAP

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

DNS-перевірка

Програма запитує NS-записи через Google Public DNS і розрізняє наявність NS, відповідь NXDOMAIN, відсутність NS та помилку запиту.

Самої DNS-відповіді недостатньо для висновку про реєстрацію. Тому за замовчуванням увімкнено «RDAP для всіх доменів». Якщо вимкнути цю опцію, домени з NS-записами можуть завершувати швидку перевірку без RDAP — із відповідним поясненням.

RDAP-перевірка

Для вибору RDAP-сервера використовується довідник IANA. Після цього програма звертається до відповідного сервера з доменним запитом.

У цій версії статус «КАНДИДАТ» формується за поєднання HTTP 404 і стандартного errorCode: 404 у JSON-відповіді RDAP. Якщо сервер повернув просто 404 без потрібної структури, це причина для ручної перевірки.

Так само окремо обробляються непідтримувані зони й неоднозначні відповіді. Вони не повинні автоматично перетворюватися на список нібито вільних доменів.

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

Домени на спостереженні

Для зареєстрованих доменів програма також розпізнає окремі RDAP-статуси: redemptionPeriod, pendingDelete та autoRenewPeriod. Такі записи потрапляють у спостереження.

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

Доменні зони й робота з різними країнами

Одне з доопрацювань, яке мені було потрібне в роботі, — зручний вибір зон. Для пошуку по Португалії я можу залишити com, net, org і додати pt. Для Нідерландів — додати nl.

У панелі є групи міжнародних і національних зон, швидкі набори «Базові + PT», «Базові + NL», поле для власних значень та режим без фільтра зон. Можна вказати, наприклад, co.uk чи com.au.

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

Технічні параметри версії 1.6.1

Розмір пакета не дорівнює кількості всіх HTTP-запитів: читання сторінок, DNS, RDAP, robots.txt і sitemap потребують окремих звернень. У фоновому запуску є часові бюджети, тому пакет може завершитися раніше.

При увімкненому «Повному обході» числові обмеження глибини й кількості сторінок не застосовуються. Але зберігаються фільтри URL, robots.txt, квоти, технічні обмеження та місткість таблиці. Назва режиму не гарантує прочитання кожної сторінки сайту.

Якщо обмеження вимкнені не були й частина URL залишилася відкладеною, програма не видає такого донора за повністю завершеного: потрібно розширити охоплення. Це захищає від непомітного пропуску збережених адрес.

Чому ми перейшли до послідовної роботи з донорами

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

Тому ми доопрацювали сценарій так: один активний донор → завершення доступних завдань → збереження кандидатів і ручної перевірки → очищення робочих даних → наступний донор.

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

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

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

Що ми виправляли під час роботи

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

У версії 1.6.1 ми виправляли ситуацію з видаленням останнього незакріпленого рядка. На практиці навіть така деталь може зупинити довгий процес. У поточному коді перед видаленням передбачено резервний порожній рядок, щоб очищення не впиралося в цю умову Google Таблиць.

Саме так я й люблю розвивати робочі інструменти: запускаємо на реальній задачі, дивимося, що незручно або ламається, виправляємо й перевіряємо знову. ChatGPT допомагає з реалізацією, а робочий сценарій і перевірку результату я беру з власної SEO-практики.

Які результати я отримую

Для роботи мені найважливіші дві вкладки:

«BLH Результати» — домени зі статусом кандидата.

«BLH Ручна перевірка» — непідтримувані зони, неоднозначні відповіді RDAP і помилки, які потребують уваги.

У записі є домен, DNS-стан, час і джерело RDAP-перевірки, приклад сторінки донора, цільовий URL, анкор, rel, кількість знайдених записів посилань та унікальних сторінок-донорів на момент збереження.

Відсутність nofollow, ugc чи sponsored показується окремо, але сама по собі не доводить якість посилання. Так само лічильник знахідок не є повним посилальним профілем домену.

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

Інші вкладки допомагають контролювати поточну роботу:

Прогрес, час і робота у фоні

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

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

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

Після запуску процес працює через фонові тригери Apps Script. Можна закрити браузер або вимкнути комп’ютер — це саме по собі не зупиняє чергу. За квотних, системних чи критичних помилок збереження програма переходить на паузу з повідомленням. Після усунення причини потрібно натиснути «Продовжити».

Як програма ставиться до сайтів і ресурсів таблиці

Перед читанням сторінки враховується robots.txt для робота BrokenLinkHunter. Заборонені адреси позначаються як заблоковані. Передбачено паузу щонайменше одну секунду, а заявлений crawl-delay враховується в межах можливостей цієї версії. Значення понад 15 секунд не обслуговується стандартним обходом.

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

Окремо контролюється місткість таблиці: прибираються невикористані хвости службових вкладок, завершені завдання ущільнюються, а перед великими записами перевіряється потреба в клітинках. У коді закладено поріг зупинки 9,5 млн виділених клітинок. Це захисний поріг програми, а не обіцянка необмеженого сканування.

Як встановити Broken Link Hunter UA

Для встановлення потрібні Google-акаунт і окрема Google Таблиця. У комплекті для завантаження підготовлені три файли та інструкція.

Створіть Google Таблицю й відкрийте «Розширення → Apps Script».

Створіть скриптовий файл BrokenLinkHunter та вставте код із BrokenLinkHunter.gs.

Створіть скриптовий файл Core та вставте код із Core.gs.

Створіть HTML-файл Sidebar та вставте вміст Sidebar.html.

Збережіть проєкт і виконайте функцію bhSetup, надавши потрібні дозволи.

Оновіть таблицю й відкрийте меню «🔎 Broken Link Hunter → Відкрити панель».

Додайте донорів у «BLH Донори» з A2, виберіть параметри, збережіть їх і натисніть «Продовжити».

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

Що цей інструмент дає мені як SEO-фахівцю

Для мене найцінніше — зв’язок між знайденим доменом і реальною сторінкою, де на нього посилаються. Я можу починати подальшу перевірку з конкретного джерела, анкора та збереженої відповіді RDAP.

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

Сам факт кандидата ще не робить домен хорошою покупкою. Але тепер у мене є власний робочий спосіб знаходити таких кандидатів, зберігати джерела й поступово обробляти список донорів. І є зрозумілий шлях розвитку інструмента: перевіряти його на своїх задачах та вдосконалювати те, що справді впливає на роботу.