Інтеграція SEMrush API для SEO-аналітики сайту

Інтеграція SEMrush API для SEO-аналітики сайту

Уявіть: ви ведете SEO для 10 доменів. Щотижня вручну відкриваєте SEMrush, експортуєте звіти, склеюєте CSV в Excel. На це йде півдня, а в даних то й справа закрадаються помилки. Для інтернет-магазину з 100 000 товарів ручний збір позицій усіх категорій практично нереальний — дані застарівають швидше, ніж ви їх збираєте. SEMrush API вирішує цю проблему раз і назавжди: програмно забираєте позиції, органіку, беклінки та метрики конкурентів, складаєте у свою базу і будуєте дашборд. Автоматизація через API у 24 рази швидша за ручний збір — економія 90% часу. Ми реалізували такі інтеграції для 8 проєктів, включаючи моніторинг 50+ доменів щодня. Наш стек: Python 3.11, PostgreSQL 16, Docker, Grafana. Код передаємо у вигляді репозиторію з документацією.

Чому варто автоматизувати збір даних?

Ручний збір із SEMrush — це години рутини та ризик помилок при копіюванні. API дає доступ до тисяч ключових слів за один запит, автоматичне оновлення метрик за розкладом і можливість порівнювати 20+ доменів в єдиному дашборді. SEMrush API vs ручний парсинг:

Економія на ручному зборі даних може сягати 400 000 рублів на рік для команди з 3 осіб — за рахунок вивільнення часу на стратегічний аналіз.

Як управляти витратами API units?

Витрата units безпосередньо залежить від обсягу запитів. Оптимізація: для щоденного моніторингу достатньо запитувати тільки ключові метрики (позиції топ-200, трафік, рейтинг домену). Повний backlink-аудит запускайте раз на тиждень. При тарифі Business (10 000 units/міс) можна вести 5 доменів щодня. Використовуйте кешування — не запитуйте одні й ті самі дані повторно протягом дня.

Що робити при помилках інтеграції?

API може повертати помилки при перевищенні ліміту, невірному ключі або тимчасових збоях. Код клієнта повинен обробляти їх: при статусі ERROR проводити повторну спробу з експоненційною затримкою. Налаштуйте сповіщення в Telegram або Slack при збої збору даних. Це гарантує, що пропусків метрик не буде.

Як налаштувати клієнт для SEMrush API?

SEMrush використовує API-ключ як query-параметр. Відповідь за замовчуванням у CSV, але для деяких ендпоінтів доступний JSON. Базова реалізація клієнта на Python виглядає так:

import requests
import csv
import io
from typing import Literal

class SemrushClient:
    BASE_URL = 'https://api.semrush.com'
    ANALYTICS_URL = 'https://api.semrush.com/analytics/v1'

    def __init__(self, api_key: str):
        self.api_key = api_key
        self.session = requests.Session()

    def _request(self, params: dict) -> list[dict]:
        params['key'] = self.api_key
        resp = self.session.get(self.BASE_URL, params=params, timeout=30)
        resp.raise_for_status()

        if resp.text.startswith('ERROR'):
            raise ValueError(f'SEMrush API error: {resp.text}')

        reader = csv.DictReader(io.StringIO(resp.text), delimiter=';')
        return list(reader)

Основні ендпоінти API

Для збору органіки, конкурентів та беклінків використовуємо наступні методи. Зведення по витратах API units:

Приклад отримання органічних ключових слів домену:

def get_organic_keywords(self, domain: str, database: str = 'ru', limit: int = 1000) -> list[dict]:
    params = {
        'type': 'domain_organic',
        'domain': domain,
        'database': database,
        'display_limit': limit,
        'display_sort': 'tr_desc',
        'export_columns': 'Ph,Po,Pp,Nq,Tr,Ur',
    }
    return self._request(params)

Відповідь містить ключові поля: Ph — ключове слово, Po — позиція, Nq — місячний обсяг пошуку, Tr — розрахунковий трафік, Ur — URL сторінки.

Для backlink-аудиту використовуємо:

def get_backlinks(self, target: str, limit: int = 1000) -> list[dict]:
    params = {
        'type': 'backlinks',
        'target': target,
        'target_type': 'root_domain',
        'display_limit': limit,
        'display_sort': 'page_ascore_desc',
        'export_columns': 'source_url,target_url,anchor,page_ascore,domain_ascore,nofollow,first_seen',
    }
    return self._request(params)

Щоденний збір даних та зберігання

Організовуємо пайплайн: за розкладом (наприклад, cron) запускається скрипт, який збирає метрики домену, топ-200 ключових слів, і зберігає все в PostgreSQL. Приклад схеми:

CREATE TABLE semrush_domain_metrics (
    id SERIAL PRIMARY KEY,
    domain TEXT NOT NULL,
    snapshot_date DATE NOT NULL,
    organic_keywords INTEGER,
    organic_traffic INTEGER,
    semrush_rank INTEGER,
    UNIQUE(domain, snapshot_date)
);

CREATE TABLE semrush_keyword_positions (
    id SERIAL PRIMARY KEY,
    domain TEXT NOT NULL,
    keyword TEXT NOT NULL,
    position INTEGER,
    search_volume INTEGER,
    url TEXT,
    snapshot_date DATE NOT NULL,
    UNIQUE(domain, keyword, snapshot_date)
);

Покрокова настройка інтеграції

Щоб автоматизувати збір даних, виконайте наступні кроки:

1. Отримайте API-ключ у панелі SEMrush (розділ API).
2. Встановіть залежності: pip install requests psycopg2-binary.
3. Реалізуйте клас SemrushClient як показано вище.
4. Створіть таблиці в PostgreSQL за наведеною схемою.
5. Налаштуйте cron-задачу для щоденного запуску скрипта.
6. Інтегруйте метрики в Grafana для візуалізації.

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

Наша інтеграція включає:

• Код клієнта на Python з обробкою помилок та пагінацією.
• Скрипти для збору даних за розкладом.
• Схему PostgreSQL для зберігання метрик.
• Документацію по запуску та налаштуванню.
• Налаштування дашборду в Grafana (опціонально).
• Підтримку після впровадження при виявленні помилок.

Розрахунок API units

Для щоденного моніторингу 5 доменів (метрики + 200 ключових слів) витрата приблизно 500–700 units на день. При тарифі Business (10 000 units/міс) це вкладається в ліміт. Оптимізація: не запитувати повні списки беклінків щодня, тільки ключові метрики. Повний backlink-аудит — раз на тиждень.

Строки та вартість

Базова інтеграція з щоденним збором метрик одного домену та топ-200 ключових слів — 2–3 робочі дні. Розширена версія з конкурентним аналізом, backlink-аудитом та дашбордом у Grafana — 5–7 днів. Вартість розраховуємо індивідуально після аудиту ваших завдань. Отримайте консультацію — зв'яжіться з нами, щоб оцінити проєкт. Замовте інтеграцію сьогодні і почніть економити час та ресурси.

Ми гарантуємо якість: код покритий тестами, налаштовані сповіщення при помилках збору, надаємо підтримку після впровадження. Наш досвід — 5+ років у веб-розробці та SEO-інтеграціях, реалізовано 8 проєктів з сумарним моніторингом 50+ доменів.

SEMrush API Documentation

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