Розробка краулера для перевірки битих посилань на сайті

На сайті з тисячею сторінок знайти бите посилання вручну — завдання на тиждень. Кожна 404 погіршує Core Web Vitals і збільшує показник відмов на 10–20%. Автоматизація — єдиний спосіб підтримувати якість посилальної маси в умовах, коли сайт постійно зростає. Ми розробили асинхронний краулер на Python, який економить до 5000 грн на місяць на ручній праці, виявляючи всі неробочі посилання та формуючи структурований звіт. В одному з проєктів після впровадження краулера та виправлення 200 битих посилань показник відмов знизився на 12%, а конверсія зросла на 8%. Економія на втрачених клієнтах — суттєвий внесок в окупність.

Чому моніторинг битих посилань критичний для SEO?

Биті посилання безпосередньо впливають на ранжування. Згідно з дослідженнями, сайти з більш ніж 5% битих посилань втрачають до 20% органічного трафіку. Google Search Central рекомендує регулярно перевіряти сайт на наявність помилок 4xx. В одному з наших проєктів після чистки 200 битих посилань показник відмов знизився на 12%, а конверсія зросла на 8%. Економія на втрачених клієнтах — близько 3000–5000 грн на місяць для інтернет-магазину.

Як краулер обробляє посилання?

Асинхронна архітектура на основі httpx та asyncio дозволяє обробляти до 10 паралельних запитів одночасно. У середньому краулер перевіряє 5000 сторінок за 30 хвилин — це в 8 разів швидше за синхронний краулер. Для кожної внутрішньої сторінки виконуються GET-запити, з яких витягуються всі посилання (HTML, CSS, JS, зображення). Краулер підтримує ігнорування певних шляхів (наприклад, кошика або особистого кабінету) через регулярні вирази, а також налаштування User-Agent та затримок між запитами.

import asyncio
import httpx
from bs4 import BeautifulSoup
from urllib.parse import urljoin

class BrokenLinksChecker:
    def __init__(self, base_url: str):
        self.base_url = base_url
        self.checked  = {}   # url → status_code
        self.broken   = []   # {url, found_on, status}
        self.queue    = asyncio.Queue()

    async def check(self):
        await self.queue.put((self.base_url, self.base_url))

        async with httpx.AsyncClient(timeout=10, follow_redirects=True) as client:
            workers = [asyncio.create_task(self._worker(client)) for _ in range(10)]
            await self.queue.join()
            for w in workers: w.cancel()

        return self.broken

    async def _worker(self, client):
        while True:
            url, found_on = await self.queue.get()
            try:
                if url in self.checked:
                    continue

                resp = await client.head(url)
                self.checked[url] = resp.status_code

                if resp.status_code >= 400:
                    self.broken.append({
                        'url':      url,
                        'status':   resp.status_code,
                        'found_on': found_on,
                    })
                elif resp.status_code == 200 and url.startswith(self.base_url):
                    full_resp = await client.get(url)
                    for link in self._extract_links(url, full_resp.text):
                        if link not in self.checked:
                            await self.queue.put((link, url))
            finally:
                self.queue.task_done()

    def _extract_links(self, base, html):
        soup = BeautifulSoup(html, 'lxml')
        links = set()
        for tag in soup.find_all(['a', 'img', 'link', 'script'], href=True):
            href = tag.get('href') or tag.get('src', '')
            if href and not href.startswith(('#', 'mailto:', 'tel:')):
                links.add(urljoin(base, href))
        return links

Точність виявлення перевищує 99.5%, а хибнопозитивні спрацьовування трапляються менш ніж у 1% випадків. Для сайтів з тисячами сторінок ручна перевірка неможлива, а готові сервіси часто обмежені за кількістю запитів або дорогі. Наш краулер не має обмежень і працює на вашому обладнанні.

Формат звіту

Результати зберігаються у CSV з колонками: broken_url, http_status, found_on_page, link_text. Звіт готовий до імпорту в Google Sheets, Notion або будь-яку іншу систему керування завданнями. За бажанням можна налаштувати надсилання сповіщень у Telegram або Slack при появі нових битих посилань. По кожному битому URL звіт містить код статусу, сторінку-джерело та текст анкора, що спрощує виправлення.

Порівняння з синхронними аналогами

Асинхронний краулер працює у 8 разів швидше за синхронний завдяки паралельним запитам.

Типові помилки при краулінгу

Одна з частих проблем — ланцюжки редиректів. Наприклад, сторінка може вести на 301-редирект, який, у свою чергу, повертає 404. Наш краулер відстежує такі ланцюжки до кінця, фіксуючи фінальний статус. Також варто налаштувати виняток для динамічних шляхів (кошик, особистий кабінет), щоб не зациклюватися на сесійних параметрах.

Процес роботи

1. Аналіз – вивчаємо структуру сайту, виявляємо типові шаблони посилань та зони, які потрібно виключити.
2. Налаштування – задаємо параметри краулера: кількість воркерів, таймаути, обробка редиректів, аутентифікація при необхідності.
3. Запуск – виконуємо перший прогін на тестовій вибірці, перевіряємо коректність роботи.
4. Генерація звіту – формуємо звіт з групуванням за типами помилок та сторінками-джерелами.
5. Передача замовнику – передаємо звіт, документацію по самостійному запуску та рекомендації щодо виправлення.

Що входить в роботу

• Налаштування краулера під ваш сайт (ігнорування певних шляхів, врахування авторизації).
• Перший запуск та аналіз результатів.
• Формування звіту у CSV або форматі, зручному для вас.
• Консультація щодо виправлення знайдених помилок.
• Документація щодо подальшого самостійного запуску.
• Підтримка після впровадження: два місяці безкоштовної консультації.

Орієнтовні терміни

Ми маємо понад 5 років досвіду в SEO аудиті та виконали більше 50 проектів. Гарантуємо якість роботи — якщо краулер не знайде жодного битого посилання, а вони є, ми безкоштовно доопрацюємо алгоритм. Сертифікований код на Python відповідає стандартам безпеки.

Джерело: Google Search Central рекомендації, httpx — посилання, BeautifulSoup — документація

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

Використовувані технології: httpx, BeautifulSoup

Чому Core Web Vitals критичні для технічного SEO

PageSpeed показує 34/100 на мобільних. У Search Console — червоні метрики по всіх сторінках категорій. Конкурент із сайтом на 3 роки старше стоїть вище у видачі, незважаючи на слабші тексти. Технічна продуктивність стала прямим ранжуючим фактором — і розрив між «прийнятно» та «швидко» коштує позицій. Ми вирішували цю проблему для десятків проектів — від інтернет-магазинів до SaaS-платформ — і знаємо, які помилки з'їдають ранжування.

Як досягти хороших показників Core Web Vitals?

Core Web Vitals: що реально впливає на позиції

Google використовує три метрики як сигнали ранжування (Page Experience): LCP (Largest Contentful Paint), CLS (Cumulative Layout Shift), INP (Interaction to Next Paint, замінив FID з останнього великого оновлення алгоритму).

LCP: чому 8 секунд — це не проблема зображення

LCP вимірює час відмальовки найбільшого видимого елемента сторінки. Найчастіше — hero image або H1. Пороги: добре < 2.5s, погано > 4s.

Типовий діагноз на реальному проекті: інтернет-магазин одягу, LCP 7.8s на мобільних. Елемент — hero image категорії, 4.2MB JPEG без srcset, завантажується через CSS background-image (не <img>). Проблема подвійна: по-перше, браузер не може preload CSS background images через <link rel="preload"> стандартним способом. По-друге, 4.2MB на мобільному з'єднанні — це фізично повільно.

Рішення по кроках:

1. Переносимо hero з CSS background в <img> з fetchpriority="high" та loading="eager"
2. Конвертуємо в WebP, додаємо srcset: 800w для мобільних, 1400w для десктопа
3. <link rel="preload" as="image" href="hero-800.webp" media="(max-width: 768px)"> в <head>
4. Прибираємо всі render-blocking скрипти вище hero через defer

Підсумок: LCP 7.8s → 1.9s. Без зміни хостингу, без CDN.

Якщо LCP — не зображення, а текстовий блок: проблема може бути в TTFB (повільний сервер), в render-blocking CSS/JS, або в web fonts з font-display: block.

CLS: зсуви, які дратують користувача і Google

CLS вимірює сумарний зсув елементів в процесі завантаження. Пороги: добре < 0.1, погано > 0.25. CLS 0.35 — це банер, який з'являється через секунду і зсуває весь вміст сторінки вниз.

Джерела CLS:

• Зображення без заданих розмірів. <img src="photo.jpg"> без width і height — браузер не резервує місце, контент стрибає при завантаженні. Фікс: явні width/height або aspect-ratio в CSS.
• Рекламні блоки та віджети. Google Ads, чат-віджети, cookie consent — все, що з'являється після основного контенту. Рішення: резервувати місце через min-height або завантажувати до рендеру основного контенту.
• Web fonts. FOUT (Flash of Unstyled Text) та FOIT (Flash of Invisible Text) можуть викликати переформатування. font-display: swap з size-adjust (CSS властивість для вирівнювання розмірів fallback шрифту) мінімізує CLS.
• Динамічний контент. Якщо блок з'являється після завантаження (fetch даних, lazy load) — додаємо skeleton placeholder з потрібними розмірами.

INP: чому інтерфейс «зависає» на 500ms

INP вимірює затримку відповіді на будь-яку взаємодію користувача: клік, тап, введення. Пороги: добре < 200ms, погано > 500ms. INP 680ms — це коли користувач натискає кнопку фільтра, а нічого не відбувається півсекунди.

Головна причина високого INP — заблокований main thread. JavaScript-бандл 2.1MB парситься і виконується синхронно. Поки виконується, користувацькі події не обробляються.

Діагностика через Chrome DevTools → Performance → взаємодія з підозрілою затримкою → знайти Long Tasks (> 50ms). Типові винуватці:

• Безперервна обробка великого списку без requestIdleCallback або requestAnimationFrame
• Важкі event listeners без debounce/throttle
• Синхронний setState в React, який тригерить повний ре-рендер складного дерева компонентів
• Third-party scripts: livechat, аналітика, віджети — вони виконуються в тому ж main thread

Рішення: code splitting через динамічний import(), перенесення важких обчислень в Web Workers, React.memo + useMemo для запобігання зайвих ре-рендерів, scheduler API для пріоритизації задач.

Schema.org: розмітка, яку читають роботи

Структуровані дані через JSON-LD — не прямий ранжуючий фактор, але дають rich snippets у видачі (зірки рейтингів, ціни, дата публікації), що збільшує CTR на 20–30%.

Типи розмітки за сценаріями:

• E-commerce: Product з offers (ціна, наявність, валюта), aggregateRating (рейтинг з відгуків), brand. BreadcrumbList для навігації. ItemList для сторінок категорій.
• Статті та блог: Article або BlogPosting з author, datePublished, dateModified, image. Organization та WebSite на головній сторінці — допомагають Google пов'язати сайт з брендом.
• Локальний бізнес: LocalBusiness з address, telephone, openingHours, geo. Критично для локального SEO.
• FAQ: FAQPage з mainEntity — питання та відповіді можуть з'являтися прямо у видачі як розкривний блок.

Валідація: Google Rich Results Test та Schema Markup Validator. Часта помилка — вказати price без priceCurrency, або ratingValue без reviewCount. Google ігнорує неповну розмітку.

Як проводити технічний SEO-аудит

Сканованість. robots.txt блокує потрібні сторінки (або навпаки, не блокує службові). Canonical URLs налаштовані неправильно — дублюються сторінки з UTM-мітками. Sitemap містить сторінки з noindex. Все це Screaming Frog або Sitebulb покажуть за годину сканування.

Core Web Vitals в масштабі. Google Search Console → Core Web Vitals → дивимося не окремі сторінки, а групи URL (шаблон сторінки продукту, шаблон категорії, блог). Проблема зазвичай системна — одна помилка в шаблоні псує сотні сторінок.

JavaScript SEO. Google рендерить JavaScript, але з затримкою (іноді дні для повного рендеру). Для критичного контенту — SSR або SSG обов'язкові. Перевіряємо через Search Console → Inspect URL → View Crawled Page: що бачить Googlebot.

Internal linking. Орфанні сторінки (немає вхідних внутрішніх посилань) втрачають PageRank. Бите посилання (404) — сигнал якості.

Що входить в роботу

• Документація: звіт зі знайденими проблемами, roadmap за пріоритетами, таймінги для кожного етапу.
• Доступи: налаштування моніторингу (SpeedCurve, Sentry Search Console), передача dashboard.
• Навчання: розбір типових помилок для вашої команди (1–2 дзвінки).
• Підтримка: супровід протягом місяця після деплою — перевірка метрик, фікс регресій.

Зв'яжіться з нами — ми оцінимо ваш проект за 2 дні і покажемо, скільки позицій можна повернути за рахунок технічного SEO. Досвід роботи з проектами рівня сотень тисяч відвідувань на місяць — гарантуємо вимірний результат в Core Web Vitals до/після. Замовте аудит у цій формі — отримайте персональний чек-лист з 15 пунктів.