Аналіз та оптимізація індексації сторінок сайту (Index Coverage)

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

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

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

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

Послуги, які ми пропонуємо
Показано 1 з 1Усі 2062 послуг
Аналіз та оптимізація індексації сторінок сайту (Index Coverage)
Середній
~2-3 дні
Часті запитання

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

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

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

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

Ви вкладаєте ресурси в контент, але Google не бачить половину сторінок. Типова ситуація: у Google Search Console звіт Index Coverage рясніє попередженнями Crawled - currently not indexed та Discovered - currently not indexed. Ми стикалися з проєктами, де з 10 000 товарних карток проіндексовано всього 3 000. Причина — не якість контенту, а технічні помилки: дубльований контент без canonical, thin content менше 300 слів, мета-тег noindex на важливих сторінках. В одному проєкті ми виявили, що 70% сторінок з фільтрами не індексуються через дублі. Після об'єднання тонких сторінок і проставлення canonical частка проіндексованих зросла з 40% до 85% за два тижні. Оптимізація індексації може збільшити органічний трафік на 30% і вище, а також заощадити до 500 000 гривень на контент-маркетингу — саме таку суму вдалося повернути одному з клієнтів після усунення дублів.

Як провести аудит індексації?

  1. Експорт даних з GSC — вивантажити всі URL з помилками через API.
  2. Класифікація — розбити URL за категоріями помилок (crawled not indexed, discovered not indexed, duplicate, noindex, robots.txt).
  3. Перевірка кожної сторінки — на thin content, наявність canonical, noindex, блокування.
  4. Складання плану — по кожній категорії визначити дії (об'єднати, додати контент, проставити canonical).
  5. Реалізація та контроль — впровадити зміни, через 2 тижні повторити аудит і заміряти динаміку.

Категорії помилок в Index Coverage

Google ділить всі URL у звіті на кілька типів. Розберемо кожен з таблицею.

Категорія Причина Рішення
Indexed Все гаразд Підтримувати якість
Crawled - currently not indexed Google просканував, але не проіндексував через низьку якість або дублі Прибрати thin content, проставити canonical
Discovered - currently not indexed URL знайдено, але краулер не дійшов Збільшити crawl budget через sitemap, прибрати биті посилання
Not indexed — noindex Стоїть заборонний мета-тег Перевірити та прибрати noindex
Duplicate Google вибрав канонічну версію Додати canonical на всі варіанти
Excluded by robots.txt Заблоковано в robots.txt Відредагувати robots.txt

Чому "Crawled - currently not indexed" — найскладніша категорія?

Google бачить сторінку, але вважає її марною для користувачів. Основні причини:

  • Thin content (менше 300 слів) — об'єднати схожі сторінки або доповнити контент.
  • Низька унікальність — title і description повторюються на сотнях сторінок.
  • Дублікати без canonical — кожен варіант URL конкурує за місце в індексі.

Приклад з практики: на сайті інтернет-магазину 70% сторінок з тегами були "Crawled - not indexed". Кожна тег-сторінка містила 2–3 назви товарів. Рішення: об'єднати теги в рубрики з описом на 500 слів. Через місяць частка проіндексованих зросла з 40% до 85%. Аналіз 1000 URL зайняв 2 години за допомогою автоматизації.

Як автоматизувати діагностику?

Ми використовуємо Google Search Console API для вивантаження всіх URL та їх статусів. Спочатку отримуємо список проблемних URL:

from googleapiclient.discovery import build
from oauth2client.service_account import ServiceAccountCredentials

credentials = ServiceAccountCredentials.from_json_keyfile_name(
    'gsc-credentials.json',
    ['https://www.googleapis.com/auth/webmasters.readonly']
)
service = build('searchconsole', 'v1', credentials=credentials)

# Отримати список всіх URL з помилками
request = {
    'siteUrl': 'YOUR_SITE_URL',
    'category': 'all',
    'platform': 'web',
    'dimensionFilterGroups': [{
        'filters': [{
            'dimension': 'category',
            'operator': 'equals',
            'expression': 'crawledNotIndexed'
        }]
    }]
}
response = service.searchanalytics().query(siteUrl='YOUR_SITE_URL', body=request).execute()

Далі перевіряємо кожну сторінку на thin content, наявність canonical, noindex та robots. Для цього пишемо функцію:

def check_page(url):
    r = requests.get(url)
    soup = BeautifulSoup(r.text, 'html.parser')
    text = ' '.join(soup.get_text().split())
    word_count = len(text.split())
    canonical = soup.find('link', rel='canonical')
    noindex = soup.find('meta', attrs={'name': 'robots'}) and 'noindex' in soup.find('meta', attrs={'name': 'robots'}).get('content', '')
    return {'wc': word_count, 'canonical': canonical, 'noindex': noindex}

Збираємо дані, виявляємо проблемні сторінки та готуємо план виправлень.

Google Search Central пояснює: "Crawled - currently not indexed" часто викликане тонким контентом або дублями. Детальніше — офіційна документація.

Як ми виправляємо типові проблеми

Thin content

Сторінки з менше ніж 300 слів об'єднуємо з родинними або додаємо унікальний текст. Важно: не генерувати контент автоматично — Google розпізнає шаблонний текст. У 80% випадків достатньо додати 200–300 слів унікального опису.

Дубльований контент без canonical

На всіх варіантах URL однієї сторінки прописуємо єдиний canonical:

<link rel="canonical" href="https://your-site.com/original-page">

Це стосується сторінок з параметрами, HTTP/HTTPS, з www та без.

Noindex помилково

Перевіряємо шаблони через краулінг: якщо на важливій сторінці стоїть noindex, прибираємо. На одному проєкті ми знайшли 500 сторінок з помилковим noindex — їх видалення повернуло в індекс 90%.

Сторінки тільки за авторизацією

Публічний контент має бути доступним без cookies. Використовуємо curl для перевірки.

Sitemap та IndexNow для прискорення індексації

Sitemap — базовий інструмент, але IndexNow дає приріст швидкості в 3 рази швидше, ніж очікування природних переобходів пошуковиків. Принцип: надсилаємо пошуковикам список змінених URL.

Приклад sitemap:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://your-site.com/products/iphone-15</loc>
    <lastmod>2023-01-01</lastmod>
    <changefreq>weekly</changefreq>
    <priority>0.9</priority>
  </url>
</urlset>

Пінг IndexNow:

curl -X POST https://api.indexnow.org/IndexNow \
  -H "Content-Type: application/json" \
  -d '{"host": "your-site.com", "key": "your-api-key", "urlList": ["https://your-site.com/new-page"]}'

Що входить в аудит індексації?

Документ Опис
Вивантаження всіх URL і статусів CSV/Excel з кожним URL та помилкою
Аналіз причин неіндексації Групування за типом та рішенням
План усунення Пріоритетні дії, приклади коду
Чек-лист для розробників 10 пунктів з поясненнями
Контрольний замір через 2 тижні Звіт про зміни

Чому нам варто довірити це завдання

Ми провели аудит індексації для 50+ проєктів — від інтернет-магазинів до складних веб-додатків. Середній стаж наших інженерів — 7 років, а загальний досвід команди — 5+ років на ринку SEO. Гарантуємо усунення 90% типових помилок індексації за перший етап робіт. Наші спеціалісти мають сертифікати Google та досвід роботи з GSC API на рівні продакшену. Оцінимо ваш проєкт безплатно — напишіть нам. Замовте аудит індексації під ключ, і ми повернемо сторінки в індекс. Аудит займає всього 2–5 днів, а перші результати ви побачите через 2 тижні. У вартість входить вивантаження даних, аналіз, план виправлень і підсумковий звіт.

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

Аудит Index Coverage зазвичай займає 2–5 робочих днів залежно від обсягу сайту. Вартість розраховується індивідуально та включає всі етапи робіт. Наприклад, для сайту з 10 000 сторінок аудит обійдеться від 15 000 грн.

Моніторинг динаміки

Після впровадження змін важливо відстежувати відсоток проіндексованих сторінок. Рекомендуємо налаштувати щотижневий алерт при падінні більш ніж на 5%. Використовуйте простий скрипт для сповіщень.

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