Биті посилання — це одна з тих помилок, які довго не кричать про себе, але повільно отруюють SEO. Користувач бачить 404, дратується і йде. Робот бачить зайві переходи, помилки, редиректи або порожні сторінки й витрачає на це краулінговий бюджет. Якщо таких URL назбирується багато, сайт починає гірше індексуватися, а технічний аудит сайту з “потім подивимось” перетворюється на термінову операцію.

Лупа над вебсторінкою показує розірване посилання і таймер на 5 хвилин
Лупа над вебсторінкою показує розірване посилання і таймер на 5 хвилин

Добра новина в тому, що для пошуку проблем не обов’язково одразу купувати важкі інструменти. Базовий безкоштовний SEO аудит можна провести значно швидше, якщо поєднати три речі: браузерне розширення для швидкої перевірки сторінки, звіт у Google Search Console і простий хмарний скрипт, який перевіряє статус-коди списку URL.

Інструменти швидкого реагування

Перший рівень — ручна перевірка сторінки. Тут добре працюють безкоштовні плагіни на кшталт Check My Links: відкрили сторінку, натиснули і одразу бачите, де є 404, де редирект, а де все працює. Це особливо корисно для головної, меню, сторінок категорій, статей і футера — тобто для місць, де внутрішні лінки множаться швидше за все.

Другий рівень — Page indexing report у Google Search Console. Саме там Google вже показує частину проблем, які бачить під час обходу сайту. Якщо у звіті ростуть “Not found (404)”, “Soft 404” або сторінки з редиректами, це не просто технічний шум. Це сигнал, що частина URL або вже померла, або повертає не те, що очікує робот.

Ракетний метод: скрипт, який перевіряє URL за вас

Автоматична перевірка URL в дії
Автоматична перевірка URL в дії

Тепер переходимо до найпрактичнішої частини. Якщо у вас є список сторінок у Google Таблиці, їх можна перевірити автоматично через Apps Script. Перевага такого підходу в тому, що скрипт працює у хмарі й не тримає відкритим ваш ноутбук. Ви просто вставляєте список URL, запускаєте функцію і бачите, які сторінки повертають 200, які дають помилка 404 SEO, а які ведуть через 301 редирект.

Базова логіка така:

  • колонка A — URL;
  • колонка B — статус-код;
  • колонка C — примітка;
  • колонка D — пріоритет виправлення.

Ось мінімальна функція, з якої можна почати:

function checkUrlStatus() {
  const sheet = SpreadsheetApp.getActiveSpreadsheet().getActiveSheet();
  const lastRow = sheet.getLastRow();

  for (let i = 2; i <= lastRow; i++) {
        const url = sheet.getRange(i, 1).getValue();
        if (!url) continue;

        try {
          const response = UrlFetchApp.fetch(url, {
                followRedirects: false,
                muteHttpExceptions: true
          });

          const code = response.getResponseCode();
          sheet.getRange(i, 2).setValue(code);

          if (code === 404) {
                sheet.getRange(i, 3).setValue('Бита сторінка');
          } else if (code >= 300 && code < 400) {
                sheet.getRange(i, 3).setValue('Редирект');
          } else if (code >= 200 && code < 300) {
                sheet.getRange(i, 3).setValue('OK');
          } else {
                sheet.getRange(i, 3).setValue('Перевірити вручну');
          }
        } catch (e) {
          sheet.getRange(i, 2).setValue('ERROR');
          sheet.getRange(i, 3).setValue('Не вдалося отримати відповідь');
        }
  }
}

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

Що бачить користувач vs що бачить робот

СитуаціяЩо бачить користувачЩо бачить робот
URL веде на неіснуючу сторінкуПомилку або порожній екран404 або soft 404
URL відкривається через кілька переходівСторінка ніби працюєЛанцюжок редиректів і зайва витрата краулінгу
Зображення не завантажується“Битий” візуал на сторінціДодатковий збій ресурсу
Посилання в меню веде не тудиНезручність і втрата довіриНекоректний внутрішній сигнал
Видалена сторінка повертає 200“Ніби щось є, але незрозуміло що”Soft 404 і плутанина для індексації

Як виправляти помилки без хаосу

Перший пріоритет — 404, на які ведуть внутрішні лінки. Якщо на биту сторінку посилається меню, хлібні крихти, стаття або категорія, ви втрачаєте і користувача, і вагу внутрішньої перелінковки. Такі URL лікуються першими.

Другий пріоритет — сторінки, які мають зовнішні посилання або трафік. Якщо сторінка вже накопичила сигнали, її не варто просто вбивати. Краще налаштувати 301 редирект на найближчу релевантну сторінку. Але без циклів: один старий URL має вести одразу на фінальний, а не через два-три проміжних кроки.

Третій пріоритет — биті картинки. Вони рідше валять SEO самі по собі, але створюють відчуття занедбаності й псують якість сторінки. Для e-commerce, блогу чи послуг це б’є по конверсії швидше, ніж здається.

Як зрозуміти, що Google побачив виправлення

Як Google бачить виправлення сайту
Як Google бачить виправлення сайту

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

Саме так і працює технічний аудит сайту “на стероїдах”: не тонна абстрактних графіків, а точна діагностика й швидке лікування. Якщо хочете побудувати поруч і власний контроль видимості, подивіться статтю про автоматизацію SEO-позицій через Google Apps Script. Разом ці два підходи дають хорошу базу для росту без зайвого технічного шуму.

Пошук битих посилань — це не косметика, а фундамент. Коли сторінки повертають правильні коди, редиректи не ламають маршрут, а Google Search Console помилки не накопичуються місяцями, сайт дихає вільніше. І вже на такій чистій технічній основі можна нарощувати контент, посилання й трафік без прихованих втрат.