Технічний SEO-аудит сайту: Core Web Vitals, мета-теги, звіт

Витрачається бюджет на контекстну рекламу, а органіка не зростає? Після масштабування каталогу або зміни CMS часто виявляються технічні помилки: биті посилання, дублі сторінок, неоптимізовані Core Web Vitals. Наш SEO-аудит виявляє та пріоритизує такі проблеми, заощаджуючи до 30% бюджету на виправленнях.

Ми провели аудит для більш ніж 200 проєктів — від корпоративних порталів до маркетплейсів із мільйонами товарів. Типовий кейс: у інтернет-магазину з 50 000 позицій знайшли 1 200 дубльованих title — після їх виправлення CTR зріс на 15%. Аудит окупається за рахунок збільшення органічного трафіку вже через 3–6 місяців.

Які технічні проблеми виявляє SEO-аудит?

Кроулінг сайту — перший крок. Ми проганяємо сайт краулером (Screaming Frog, Sitebulb або власним на Python) і збираємо всі URL, перевіряючи статус-коди, дублі, помилкові редиректи та orphan pages.

# Быстрая проверка через sitemap
import requests
from xml.etree import ElementTree

resp = requests.get('https://mysite.ru/sitemap.xml')
tree = ElementTree.fromstring(resp.content)
ns = {'sm': 'http://www.sitemaps.org/schemas/sitemap/0.9'}

urls = [loc.text for loc in tree.findall('.//sm:loc', ns)]
print(f'URLs в sitemap: {len(urls)}')

# Проверка статус-кодов
errors = []
for url in urls[:200]:  # первые 200 для демо
    r = requests.head(url, allow_redirects=True, timeout=5)
    if r.status_code not in (200, 301, 302):
        errors.append({'url': url, 'status': r.status_code})

print(f'Ошибочных URL: {len(errors)}')

Перевірювані технічні параметри:

Як налаштувати robots.txt для уникнення помилок індексації

1. Перевірте, що sitemap вказаний у robots.txt: Sitemap: https://mysite.ru/sitemap.xml.
2. Переконайтеся, що службові розділи (admin, cgi-bin) закриті від індексації.
3. Для AJAX-сайтів додайте директиву Disallow: /ajax/, якщо це не потрібно для пошуку.
4. Використовуйте правило Allow: / після Disallow для часткового дозволу.

# Проверить доступность robots.txt
curl -s https://mysite.ru/robots.txt

Sitemap повинен містити лише 200-і сторінки, без noindex і з коректними <lastmod>. Розмір — до 50 000 URL або 50 MB на файл.

Перевірка мета-тегів і заголовків

On-page аналіз включає перевірку title і meta description:

# Массовая проверка title/description
from bs4 import BeautifulSoup

issues = []
for url in urls:
    soup = BeautifulSoup(requests.get(url).text, 'html.parser')
    title = soup.find('title')
    desc = soup.find('meta', {'name': 'description'})

    t_len = len(title.text) if title else 0
    d_len = len(desc['content']) if desc and desc.get('content') else 0

    if t_len == 0: issues.append((url, 'no_title'))
    elif t_len > 70: issues.append((url, f'title_too_long:{t_len}'))
    if d_len == 0: issues.append((url, 'no_description'))
    elif d_len > 160: issues.append((url, f'desc_too_long:{d_len}'))

Норми: title 50–70 символів, description 120–160. Шаблонні описи — проблема дублів. Заголовки H1–H6: один H1 з ключовим запитом, H2–H3 структурують контент без пропусків порядку. Контент: перевіряємо thin content (<300 слів), дублі з фідів постачальника, сторінки пагінації з rel="next"/"prev" або canonical на першу.

Внутрішня перелінковка та структуровані дані

Хороша внутрішня посилальна структура розподіляє вагу сторінок і допомагає краулерам. Проблеми:

• Orphan pages — сторінки без вхідних внутрішніх посилань (їх краулер не знайде)
• Глибина кліку > 3 для важливих сторінок
• Broken internal links — посилання на видалені/редиректні сторінки

-- Для CMS на SQL: найти страницы без входящих ссылок
SELECT p.url
FROM pages p
LEFT JOIN internal_links il ON il.target_url = p.url
WHERE il.id IS NULL AND p.status = 'published'

Структуровані дані: перевіряємо валідність schema.org за допомогою Google Rich Results Test. Підтримуємо типи: Product, Article, BreadcrumbList, FAQPage, Review, LocalBusiness, Event.

Що входить в аудит?

За підсумками ви отримуєте:

• Повний дамп даних кроулінгу (CSV/Excel)
• Пріоритизований список проблем із трудозатратами та очікуваним ефектом
• Документацію з технічних доробок для розробників (з кореневою причиною та способом усунення)
• Консультацію інженера за пріоритетними виправленнями
• Гарантію якості: при виявленні нових проблем після виправлень повторний міні-аудит безкоштовно

Як Core Web Vitals впливають на ранжування

Google використовує CrUX-дані (field data) для ранжування. Згідно з рекомендаціями Google Search Central, LCP має бути менше 2.5 секунд. Якщо у конкурента LCP < 2.5s, а у вас > 4s — це серйозний фактор за інших рівних. Перевірка через Search Console показує відсоток URL у Good/Needs improvement/Poor. На аудиті ми даємо конкретні причини: неоптимізовані зображення, важковаговий JavaScript, повільна серверна відповідь.

Додатково: Core Web Vitals (Wikipedia)

Посилальний профіль (базовий рівень)

У рамках технічного аудиту перевіряємо:

• Індекс в Ahrefs/Semrush — виявлення токсичних посилань із заспамлених доменів
• Anchor text distribution — переоптимізація (>60% комерційних анкорів)
• Втрачені посилання на видалені сторінки без 301-редиректу

Структура звіту

Аудит оформлюється як структурована таблиця з пріоритетами:

Додатково ми надаємо:

• Повний дамп даних кроулінгу (CSV/Excel)
• Рекомендації щодо виправлення з пріоритетами (P0–P3)
• Документацію з технічних доробок для розробників
• Гарантія якості: при виявленні нових проблем після виправлень повторний міні-аудит безкоштовно

Терміни аудиту

Технічний кроулінг, аналіз on-page, структуровані дані, CWV, пріоритизований звіт для сайту 1000–5000 URL: 3–4 дні. Великі eCommerce (50 000+ SKU): 5–7 днів. Ми працюємо з проєктами будь-якого масштабу — від лендінгів до маркетплейсів.

Зв'яжіться з нами для попередньої оцінки вашого сайту — надішлемо демо-версію звіту на основі типових проблем вашої ніші. Постійний моніторинг ефективніший за разовий аудит: ми пропонуємо абонентське супроводження з щомісячними перевірками та коригуваннями. Замовте аудит і отримайте консультацію інженера за пріоритетними виправленнями.

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