Краулер для збору структури сайтів конкурентів: автоматичний аналіз

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

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

Інформаційні сайти або веб-програми
Сайти візитки, landing page, корпоративні сайти, онлайн каталоги, квіз, промо-сайти, блоги, ресурси новин, інформаційні портали, форуми, агрегатори
Сайти або веб-програми електронної комерції
Інтернет-магазини, B2B-портали, маркетплейси, онлайн-обмінники, кешбек-сайти, біржі, дропшиппінг-платформи, парсери товарів
Веб-програми для управління бізнес-процесами
CRM-системи, ERP-системи, корпоративні портали, системи управління виробництвом, парсери інформації
Сайти або веб-програми електронних послуг
Дошки оголошень, онлайн-школи, онлайн-кінотеатри, конструктори сайтів, портали надання електронних послуг, відеохостинги, тематичні портали

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

Послуги, які ми пропонуємо
Показано 1 з 1Усі 2062 послуг
Краулер для збору структури сайтів конкурентів: автоматичний аналіз
Середній
~3-5 днів
Часті запитання

Наші компетенції:

Етапи розробки

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1361
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1252
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    958
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1190
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    931
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Розробка веб-сайту для компанії ФІКСПЕР
    949

Ви витрачаєте дні на ручний збір 200 URL конкурентів, виписуючи заголовки та мета-описи. Через місяць ребрендинг — і все спочатку. Краулер вирішує це за хвилини і відтворюється автоматично. Ми — команда з 7-річним досвідом у веб-скрапінгу: реалізували 15+ таких рішень для різних ніш. Одна з частих проблем — неповний збір через JavaScript-рендеринг. Навіть статичний сайт може містити динамічні елементи, які не видно звичайному HTTP-запиту. Краулер з headless-браузером виявляє реальну структуру, включаючи ліниве завантаження. У результаті ви отримуєте повну карту сайту конкурента: всі URL, заголовки, мета-теги, Schema.org. Такий підхід економить до 20 годин роботи на тиждень і дає перевагу в SEO-аналізі.

Які проблеми вирішує краулер для структури сайту?

Частий біль — неповний збір структури через JavaScript-рендеринг, вкладеність URL або канонічні дублі. Наприклад, інтернет-магазин на Vue.js може видавати однаковий контент на різних URL, що спотворює карту сайту. Краулер з headless-браузером виявляє реальну структуру, включаючи динамічні підвантаження.

Ще одна проблема — аналіз Schema.org. Без structured data неможливо оцінити, як конкурент використовує багаті снипети. Краулер збирає JSON-LD та Microdata, дозволяючи копіювати успішні патерни.

Яку архітектуру використовуємо для краулінгу?

Два робочі варіанти: Python + Scrapy/Playwright для складних SPA з лінивим завантаженням, Node.js + Puppeteer/Cheerio для більшості стандартних сайтів. У задачах, де немає динамічного JS-рендерингу, вистачає HTTP-клієнта з HTML-парсером — швидше в 5–10 разів, простіше в деплої.

Характеристика HTTP-краулер Headless-краулер
Швидкість на сторінку 0.3–0.8 с 2–5 с
Підтримка JS Ні Повна
Навантаження на сервер Низьке Помірне
Складність деплою Мінімальна Середня

Мінімальна Python-реалізація на основі requests + lxml:

import requests
from lxml import html
from urllib.parse import urljoin, urlparse
from collections import deque
import time
from urllib.robotparser import RobotFileParser

class SiteStructureCrawler:
    def __init__(self, base_url: str, max_depth: int = 4, delay: float = 1.0):
        self.base_url = base_url
        self.domain = urlparse(base_url).netloc
        self.max_depth = max_depth
        self.delay = delay
        self.visited: dict[str, dict] = {}
        self.queue: deque = deque([(base_url, 0)])
        # Перевірка robots.txt
        rp = RobotFileParser()
        rp.set_url(f'{base_url}/robots.txt')
        rp.read()
        self.rp = rp

    def crawl(self):
        session = requests.Session()
        session.headers['User-Agent'] = (
            'Mozilla/5.0 (compatible; SiteAnalyzer/1.0; +https://example.com/bot)'
        )

        while self.queue:
            url, depth = self.queue.popleft()
            if url in self.visited or depth > self.max_depth:
                continue
            if not self.rp.can_fetch('*', url):
                continue  # пропускаємо заборонені шляхи

            try:
                resp = session.get(url, timeout=10, allow_redirects=True)
                resp.raise_for_status()
            except requests.RequestException as e:
                self.visited[url] = {'error': str(e), 'depth': depth}
                continue

            doc = html.fromstring(resp.content)
            doc.make_links_absolute(url)

            title = doc.findtext('.//title') or ''
            h1 = [h.text_content().strip() for h in doc.cssselect('h1')]
            meta_desc_el = doc.cssselect('meta[name="description"]')
            meta_desc = meta_desc_el[0].get('content', '') if meta_desc_el else ''
            canonical_el = doc.cssselect('link[rel="canonical"]')
            canonical = canonical_el[0].get('href', '') if canonical_el else ''
            noindex = bool(doc.cssselect('meta[name="robots"][content*="noindex"]'))

            # Збір Schema.org та заголовків
            schemas = []
            for script in doc.cssselect('script[type="application/ld+json"]'):
                try:
                    import json
                    data = json.loads(script.text_content())
                    schemas.append(data)
                except json.JSONDecodeError:
                    pass
            headings = []
            for tag in ['h1', 'h2', 'h3', 'h4']:
                for el in doc.cssselect(tag):
                    headings.append({'tag': tag, 'text': el.text_content().strip()})

            links = []
            for a in doc.cssselect('a[href]'):
                href = a.get('href', '').strip()
                parsed = urlparse(href)
                if parsed.netloc == self.domain and href not in self.visited:
                    links.append(href)
                    if depth + 1 <= self.max_depth:
                        self.queue.append((href, depth + 1))

            self.visited[url] = {
                'depth': depth,
                'status': resp.status_code,
                'title': title.strip(),
                'h1': h1,
                'meta_description': meta_desc,
                'canonical': canonical,
                'noindex': noindex,
                'internal_links': links,
                'content_type': resp.headers.get('Content-Type', ''),
                'schema': schemas,
                'headings': headings,
            }

            time.sleep(self.delay)

        return self.visited

Робота з JavaScript-рендерингом

Якщо сайт конкурента — SPA (React/Vue/Angular) або використовує lazy-load для основного контенту, звичайний HTTP-краулер поверне порожні сторінки. Тут потрібен headless-браузер:

from playwright.sync_api import sync_playwright

def crawl_spa_page(url: str) -> dict:
    with sync_playwright() as p:
        browser = p.chromium.launch(headless=True)
        page = browser.new_page()
        page.goto(url, wait_until='networkidle', timeout=30000)

        title = page.title()
        h1_elements = page.query_selector_all('h1')
        h1_texts = [el.inner_text() for el in h1_elements]

        # Збір всіх посилань після рендерингу
        links = page.eval_on_selector_all(
            'a[href]',
            'els => els.map(e => e.href)'
        )

        browser.close()
        return {'title': title, 'h1': h1_texts, 'links': links}

Playwright додає ~2–5 секунд на сторінку проти 0.3–0.8 секунди для звичайного HTTP. При краулінгу 500+ сторінок це відчутно — використовується лише там, де без нього не обійтися.

Як автоматизувати регулярний краулінг?

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

def diff_structures(old: dict, new: dict) -> dict:
    added = {url: data for url, data in new.items() if url not in old}
    removed = {url: data for url, data in old.items() if url not in new}
    changed = {}
    for url in old:
        if url in new:
            if old[url].get('title') != new[url].get('title'):
                changed[url] = {
                    'old_title': old[url].get('title'),
                    'new_title': new[url].get('title'),
                }
    return {'added': added, 'removed': removed, 'changed': changed}

Чому важливий збір Schema.org?

Structured data — прямий індикатор того, наскільки конкурент вкладається в SEO. Наявність Article, Product, BreadcrumbList, FAQPage дає перевагу у видачі. Краулер фіксує всі типи розмітки, дозволяючи вам перейняти успішні схеми.

Налаштування та запуск краулера

Щоб розпочати збір, виконайте кілька кроків:

  1. Клонуйте репозиторій з готовим краулером.
  2. Встановіть залежності: pip install requests lxml (або playwright для SPA).
  3. Вкажіть стартовий URL та максимальну глибину обходу.
  4. Запустіть скрипт: python crawler.py.
  5. Після завершення отримайте звіт — файл у форматі JSON або CSV.

Результати та автоматизація

Зібрана структура експортується в кілька форматів залежно від задачі:

Формат Коли використовувати Переваги
JSON Програмна обробка, інтеграція з API Повнота даних, вкладеність
CSV Аналіз в Excel/Google Sheets Простота, сортування
SQLite Регулярний краулінг, історія змін Швидкі запити, підтримка diff
import json
import csv

# JSON — для програмної обробки
with open('competitor_structure.json', 'w', encoding='utf-8') as f:
    json.dump(crawler.visited, f, ensure_ascii=False, indent=2)

# CSV — для аналізу в Excel/Google Sheets
fieldnames = ['url', 'depth', 'status', 'title', 'meta_description', 'h1', 'noindex', 'canonical']
with open('competitor_structure.csv', 'w', newline='', encoding='utf-8') as f:
    writer = csv.DictWriter(f, fieldnames=fieldnames, extrasaction='ignore')
    writer.writeheader()
    for url, data in crawler.visited.items():
        row = {'url': url, **data}
        if isinstance(row.get('h1'), list):
            row['h1'] = ' | '.join(row['h1'])
        writer.writerow(row)

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

  • Розробка краулера з урахуванням специфіки вашої ніші: вибір стеку (Python або Node.js), налаштування depth, затримок, robots.txt.
  • Інтеграція з headless-браузером для SPA-сайтів.
  • Збір всіх URL, заголовків H1-H6, meta-тегів, canonical, noindex, Schema.org.
  • Експорт в JSON, CSV або SQLite на ваш вибір.
  • Автоматизація запуску через cron/Airflow зі збереженням історії змін.
  • Документація з експлуатації та консультація з аналізу результатів.

Строки та гарантії

Базовий краулер (HTTP, без SPA) з експортом в CSV/JSON — від 1 до 2 робочих днів. З підтримкою JavaScript-рендерингу, збором Schema.org, diff-порівнянням та SQLite-сховищем — від 3 до 4 днів. Інтеграція з планувальником та повідомленнями при змінах — ще від 1 до 2 днів.

Ми гарантуємо, що краулер поважає robots.txt (Robots.txt) — обов'язкова перевірка перед кожним запитом. Затримка між запитами (мінімум 1 секунда) запобігає блокуванню по IP. Для регулярного краулінгу використовуємо ротацію User-Agent та проксі.

Типові помилки при розробці краулера:

  • Ігнорування robots.txt — ризик блокування IP.
  • Занадто швидкий краулінг (delay < 1 сек) — бан від сервера.
  • Пропуск перевірки canonical — дублі роздувають структуру.
  • Відсутність обробки циклічних посилань — нескінченний обхід.
  • Неврахування пагінації (page/2, page/3) — неповний збір.

Зв'яжіться з нами для консультації. Замовте розробку краулера під вашу нішу. Отримайте безкоштовний аналіз ваших конкурентів та рекомендації з краулінгу.

Чому 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 з потрібними розмірами.
Типовий сценарій CLS до CLS після Основний фікс
Банер знижок без min-height 0.42 0.02 min-height: 300px
Картинки в статтях без атрибутів 0.18 0.01 width/height + aspect-ratio
Віджет чату, що завантажується через 3с 0.35 0.05 position: fixed із зарезервованим відступом

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) — сигнал якості.

Типові помилки при впровадженні Schema.org
  • Вказано price без priceCurrency — розмітка ігнорується.
  • ratingValue без reviewCount — у видачі не показується.
  • Кілька Product на одній сторінці без @type: ItemList — Google бере тільки перший.
  • JSON-LD в GTM — Google не завжди бачить динамічну розмітку, краще серверний рендеринг.
Етап роботи Що входить Термін
Аудит Сканування, аналіз Core Web Vitals, аудит Schema, звіт з пріоритетами 1–2 тижні
Оптимізація одного шаблону LCP, CLS, INP, впровадження SSR/SSG, налаштування preload 2–4 тижні
Повна технічна оптимізація Всі шаблони, code splitting, Web Workers, моніторинг в CI 4–10 тижнів
Впровадження Schema.org JSON-LD генерація, валідація, тестування rich snippets 1–3 тижні

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

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

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