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

На сайте с тысячей страниц найти битую ссылку вручную — задача на неделю. Каждая 404 ухудшает Core Web Vitals и увеличивает показатель отказов. Автоматизация — единственный способ поддерживать качество ссылочной массы в условиях, когда сайт постоянно растёт. Мы разработали асинхронный краулер на Python, который экономит часы ручного труда, обнаруживая все нерабочие ссылки и формируя структурированный отчёт. В одном из проектов после внедрения краулера и исправления 200 битых ссылок показатель отказов снизился на 12%, а конверсия выросла на 8%. Экономия на потерянных клиентах — существенный вклад в окупаемость.

Почему мониторинг битых ссылок критичен для SEO?

Битые ссылки напрямую влияют на ранжирование. Согласно исследованиям, сайты с более чем 5% битых ссылок теряют до 20% органического трафика. Google Search Central рекомендует регулярно проверять сайт на наличие ошибок 4xx. В одном из наших проектов после чистки 200 битых ссылок показатель отказов снизился на 12%, а конверсия выросла на 8%. Экономия на потерянных клиентах — существенная сумма для интернет-магазина.

Как краулер обрабатывает ссылки?

Асинхронная архитектура на основе httpx и asyncio позволяет обрабатывать до 10 параллельных запросов одновременно. В среднем краулер проверяет 5000 страниц за 30 минут. Для каждой внутренней страницы выполняются 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 или формате, удобном для вас.
• Консультация по исправлению найденных ошибок.
• Документация по дальнейшему самостоятельному запуску.
• Поддержка после внедрения: два месяца бесплатной консультации.

Ориентировочные сроки

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

Используемые технологии: httpx, BeautifulSoup

Почему Core Web Vitals критичны для технического SEO

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

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 пунктов.