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

Порядок, який економить тижні

Технічні проблеми утворюють ієрархію: помилка верхнього рівня знецінює всі правки нижніх. Немає сенсу переписувати title, якщо сторінка віддає 404 для робота, і немає сенсу боротися за десяті долі секунди в LCP, якщо половина каталогу склеєна канонікалом у головну.

1. 1

   Рівень 1 — чи бачить робот сайт узагалі

   robots.txt, метатег robots, HTTP-заголовок X-Robots-Tag, коди відповіді, доступність з різних IP. Одна зайва директива тут коштує дорожче за всі інші знахідки разом.

2. 2

   Рівень 2 — чи не розмножилися сторінки

   Канонікали, параметри фільтрів, версії з www і без, слеш у кінці, пагінація, мультимовність. Дублі не «зменшують позиції» — вони змушують Google обирати за вас, і він обирає не ту сторінку.

3. 3

   Рівень 3 — чи веде структура кудись

   Ланцюжки редиректів, биті внутрішні посилання, сирітські сторінки, глибина вкладеності, sitemap проти реального стану сайту.

4. 4

   Рівень 4 — чи все з рендерингом і швидкістю

   JavaScript-рендеринг, лінива підвантажка контенту, Core Web Vitals, мобільна версія. Це важливо, але виправляти це до рівнів 1–3 — марна витрата бюджету.

Індексація: де сайт зникає найтихіше

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

# Типова помилка: спроба «сховати» сторінки від індексу через robots.txt
User-agent: *
Disallow: /catalog/

# Насправді це лише забороняє сканування. Сторінки, на які є посилання,
# залишаться в індексі без опису — і Google не побачить noindex,
# бо не має права завантажити сторінку.

# Правильно: дозволити сканування і поставити noindex у метатезі
User-agent: *
Allow: /
Sitemap: https://example.com/sitemap.xml

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

Дублі, канонікали й мультимовність

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

• Канонікал — це підказка, а не команда. Якщо контент сторінок відчутно різний, Google проігнорує вказівку й проіндексує обидві. Якщо він однаковий, канонікал спрацює.
• Hreflang має бути взаємним: сторінка A вказує на B, а B зобов’язана вказувати назад на A. Односторонні теги ігноруються повністю — це найчастіша помилка на мультимовних сайтах.
• Канонікал і hreflang не суперечать одне одному: канонікал вказує всередині мовної версії, hreflang — між версіями. Канонікал з української сторінки на англійську ламає обидва механізми.
• UTM-мітки не створюють дублів, якщо на сторінці стоїть самореферентний канонікал. Це п’ять рядків у шаблоні, які закривають цілий клас проблем.

Редиректи та структура URL

Ланцюжки редиректів накопичуються роками: був переїзд на HTTPS, потім зміна структури каталогу, потім прибрали слеш. У результаті одне посилання ззовні проходить чотири стрибки, а робот на третьому втрачає інтерес.

1. 1Знайдіть усі ланцюжки довші за один стрибок і перепишіть правила так, щоб старий URL вів одразу на фінальний. Одне правило замість трьох — і мінус приблизно 300–600 мс до першого байта.
2. 2Перевірте, що 301 не перетворився на 302. Тимчасовий редирект, який стоїть рік, — це втрачені сигнали посилань, бо Google не переносить вагу так само надійно.
3. 3Приберіть внутрішні посилання на редиректи. Якщо всередині сайту ви посилаєтесь на старі URL, ви щодня витрачаєте краулінговий бюджет на непотріб.
4. 4Зафіксуйте одну форму URL: нижній регістр, без слеша в кінці або зі слешем — але однаково всюди, включно з sitemap, канонікалами й внутрішніми посиланнями.

Рендеринг JavaScript і швидкість

Google рендерить JavaScript, але робить це другою чергою й не гарантує строків. На сайті з клієнтським рендерингом типова затримка між скануванням і появою контенту в індексі — від кількох днів до кількох тижнів. Для новинного проєкту це вирок, для корпоративного сайту — терпимо. Як читати конкретні статуси індексації та що робити з кожним, розібрано в матеріалі про проблеми індексації.

• Перевіряйте не браузером, а інструментом перевірки URL у Search Console: він показує саме той HTML, який побачив рендерер. Розбіжність із тим, що ви бачите у вкладці, — і є діагноз.
• Контент, який підвантажується після кліку або скролу, для пошуку не існує. Табуляція з описом товару має бути в HTML, навіть якщо візуально прихована.
• Внутрішні посилання мають бути справжніми <a href>. Навігація на onClick без href для робота — це глухий кут: він не переходить далі.
• Серверний рендеринг або статична генерація закривають цю категорію проблем повністю. Це аргумент на користь стеку, а не мікрооптимізацій — деталі порівняння є в матеріалі про швидкість завантаження сайту.

Швидкість перевіряється в останню чергу, і не тому, що вона не важлива, а тому, що це єдина категорія, де правки дають вимірюваний, але поступовий приріст. Порогові значення й порядок оптимізації розібрані окремо в гайді по Core Web Vitals, а повний перелік того, що має бути закрито перед запуском, — у чеклісті SEO на 2026 рік.

Часті питання про технічний аудит

Коротко

• Перевіряйте зверху вниз: індексація, дублі, структура, рендеринг. Правки нижнього рівня не працюють, поки зламаний верхній.
• Disallow у robots.txt забороняє сканування, а не індексацію. Щоб прибрати сторінку з пошуку, потрібен noindex і дозволене сканування.
• Hreflang працює лише взаємно. Односторонні теги ігноруються, і мовні версії конкурують між собою.
• Ланцюжки редиректів і внутрішні посилання на старі URL щодня витрачають краулінговий бюджет — це виправляється за годину.
• Хороший аудит закінчується списком з десяти завдань із пріоритетом, а не вивантаженням з краулера.