Налаштування сканування сайту через Screaming Frog

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

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

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

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

Послуги, які ми пропонуємо
Показано 1 з 1Усі 2062 послуг
Налаштування сканування сайту через Screaming Frog
Середній
від 1 дня до 3 днів
Часті запитання

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

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

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

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

Ми пропонуємо професійне налаштування сканування сайту через Screaming Frog. Биті посилання — не єдина головна біль техліда. Криві canonical, дублі title, N+1 редиректів — кожен з цих багів знижує позиції у видачі. Screaming Frog SEO Spider — де-факто стандарт технічного аудиту. Ми використовуємо його в кожному проекті та налаштовуємо автоматичний краулінг для регулярного моніторингу. Багаторічний досвід нашої команди (7+ років, 300+ проектів) підтверджує: жодна проблема не залишиться непоміченою. Економія на ручному аудиті сягає 70–90% за рахунок автоматизації (від 15 000 грн на місяць). Вартість налаштування визначається після аналізу обсягу робіт. Зв'яжіться з нами — підберемо конфігурацію під ваш стек. Наша команда має сертифікацію Screaming Frog та гарантує якість налаштування.

Які проблеми вирішує Screaming Frog?

  • Биті посилання та редиректи: знаходимо 4xx та 5xx помилки, ланцюжки редиректів, циклічні перенаправлення. На одному проекті з каталогом у 20 000 товарів виявили 12-ланковий ланцюжок редиректів — ранжування впало на 30%.
  • Проблеми з мета-тегами: відсутні або дубльовані title, надто довгі мета-описи, криві H1. Краулер підсвічує всі невідповідності.
  • Проблеми індексації: сторінки без canonical, неправильні hreflang, закриті в robots.txt URL, які мають індексуватися. Наприклад, блокування сторінок фільтрації призводить до втрати 40% трафіку.

Автоматичний краулінг через CLI в 5 разів швидший за ручний запуск GUI та дозволяє інтегрувати аудит у CI/CD. Для сайту в 20 000 URL з JS-рендерингом потрібно 4-8 ГБ RAM, а час простою через невиявлені помилки — в 3-5 разів вищий. Зв'яжіться з нами, щоб оцінити економію на вашому проекті.

Чому автоматичний краулінг — стандарт технічного аудиту?

GUI-версія зручна для разових перевірок, але для регулярного моніторингу потрібен CLI. Порівняння підходів:

Критерій GUI CLI
Запуск Ручний, щоразу Автоматичний за розкладом
Швидкість Залежить від інтерфейсу В 5 разів швидше
Інтеграція Немає У CI/CD, cron, сповіщення
Ресурси Фіксований heap Налаштовуваний -Xmx
Повторюваність Різний щоразу Ідентичний конфіг

Також варто врахувати типові помилки конфігурації:

Помилка Наслідок Рішення
Не задано User-Agent Блокування краулера Встановити відповідний --user-agent
Завелика глибина Тривале сканування Обмежити --max-crawl-depth до 5-10
Не включено рендеринг JS Пропущені посилання Використовувати --use-rendered
Відсутність виключень Зациклення Налаштувати --exclude для параметрів

Розгорнутий приклад конфігурації для cron:

0 3 * * 1 /usr/bin/screamingfrogseospider --crawl https://example.com --headless --config /etc/screamingfrog/standard-audit.seospiderconfig --output-folder /var/reports/$(date +\%Y\%m\%d) --export-tabs "Internal:All,Response Codes:All,Page Titles:All,Meta Description:All,H1:All,Canonical:All,Directives:All,Hreflang:All,Structured Data:All,Links:All,Sitemaps:All" --timestamped-output

Налаштування автоматичного краулінгу

Встановлення та ліцензія

Screaming Frog — Java-додаток. Безкоштовна версія обмежена 500 URL, платна ліцензія для комерційних проектів.

# Ubuntu/Debian
wget https://download.screamingfrog.co.uk/products/seo-spider/screamingfrogseospider_21.0_all.deb
sudo dpkg -i screamingfrogseospider_21.0_all.deb

Запуск через CLI

Ключове — режим --headless. Параметри: --crawl, --save-crawl, --export-tabs, --output-folder.

screamingfrogseospider \
  --crawl https://example.com \
  --headless \
  --save-crawl \
  --export-tabs "Internal:All,Response Codes:All,Page Titles:All,Meta Description:All,H1:All,Canonical:All,Directives:All,Hreflang:All,Structured Data:All,Links:All,Sitemaps:All" \
  --output-folder /var/reports/example-com/$(date +%Y%m%d) \
  --timestamped-output

Конфігурація та рендеринг

Для стандартизації збережіть конфіг у GUI та передавайте через --config. Для JavaScript-сайтів увімкніть рендеринг через вбудований Chromium (--use-rendered). Час краулінгу з JS збільшується в 3–5 разів, тому застосовуйте лише де критично.

Аутентифікація

# Cookie
screamingfrogseospider --crawl https://example.com/admin/ --headless --set-cookies "PHPSESSID=abc123; laravel_session=xyz789" --output-folder /var/reports/

# HTTP Basic
screamingfrogseospider --crawl https://example.com --headless --auth-details "user:password" --output-folder /var/reports/

Як налаштувати CLI для автоматичного запуску?

У cron-задачі використовуйте повний шлях до бінарника та параметри вище. Переконайтеся, що Java heap достатній: для сайту 50 000 URL з JS-рендерингом потрібно 4-8 ГБ RAM (-Xmx). Для моніторингу додайте сповіщення в Telegram або email при появі 4xx- та 5xx-помилок.

Коли потрібен рендеринг JavaScript?

Для сайтів на React, Vue або Angular, де контент підвантажується динамічно. Без рендерингу краулер побачить лише порожній шаблон — ви пропустите до 80% посилань. Рекомендуємо вмикати --use-rendered для SPA-додатків.

Чому рендеринг JavaScript критичний для SPA?

У SPA відсутні статичні HTML-сторінки. Краулер без рендерингу не знайде внутрішні посилання, мета-теги, структуровані дані. Як вказує офіційна документація Screaming Frog, для повного аудиту SPA необхідний headless Chrome. Це єдиний спосіб виявити всі технічні проблеми.

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

  1. Аналітика: визначаємо цілі аудиту, список URL, robots, карту сайту.
  2. Проектування: створюємо конфігурацію краулера (User-Agent, глибину, виключення).
  3. Реалізація: налаштовуємо CLI-запуск, експорт даних, скрипти обробки.
  4. Тестування: перевіряємо на тестовому піддомені, верифікуємо результати.
  5. Деплой: розміщуємо на сервері, налаштовуємо cron, сповіщення в Telegram/email.

Що входить у результат

  • Конфігурація краулера: standard-audit.seospiderconfig.
  • Bash-скрипт автоматичного запуску з логуванням.
  • Python-скрипт аналізу основних метрик (коди відповідей, дублі title/H1, биті посилання).
  • Налаштування сповіщень (Telegram/email) при аномаліях.
  • Інструкція з оновлення та підтримки.

Обробка результатів

Screaming Frog експортує CSV для кожної вкладки. Ми підготували Python-скрипти для завантаження та зведення.

import pandas as pd
from pathlib import Path

def load_crawl_results(output_dir: str) -> dict[str, pd.DataFrame]:
    results = {}
    for csv_file in Path(output_dir).glob('*.csv'):
        name = csv_file.stem.lower().replace(' ', '_')
        try:
            df = pd.read_csv(csv_file, encoding='utf-8-sig', low_memory=False)
            results[name] = df
        except Exception as e:
            print(f'Could not load {csv_file}: {e}')
    return results

def audit_summary(results: dict) -> dict:
    summary = {}
    if 'internal_all' in results:
        internal = results['internal_all']
        summary['total_urls'] = len(internal)
        summary['indexable'] = len(internal[internal.get('Indexability', '') == 'Indexable'])
    if 'response_codes_all' in results:
        codes = results['response_codes_all']
        for code, prefix in [('2xx','2'),('3xx','3'),('4xx','4'),('5xx','5')]:
            summary[code] = len(codes[codes['Status Code'].astype(str).str.startswith(prefix)])
    if 'page_titles_all' in results:
        titles = results['page_titles_all']
        summary['missing_title'] = titles['Title 1'].isna().sum() + (titles['Title 1']=='').sum()
        summary['duplicate_title'] = titles['Title 1'].duplicated().sum()
    if 'h1_all' in results:
        h1 = results['h1_all']
        summary['missing_h1'] = h1['H1-1'].isna().sum() + (h1['H1-1']=='').sum()
        if 'H1-1 Count' in h1:
            summary['multiple_h1'] = (h1['H1-1 Count'] > 1).sum()
    return summary

Зведення дозволяє одразу виявити критичні проблеми та оцінити масштаб робіт. Наприклад, більше 5% 4xx-помилок — привід для термінового редизайну структури. Автоматизація краулінгу дозволяє скоротити витрати на технічний аудит на 70–90% порівняно з ручним тестуванням (економія до 15 000 грн на місяць). Отримайте консультацію та приклад конфігурації під ваш сайт — зв'яжіться з нами для попередньої оцінки.

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