Кейс із цифрами: як технічний аудит повернув інтернет-магазин у видачу
Технічний аудит сайту рідко замовляють із цікавості. Зазвичай до нього доходять так, як герой цього кейсу: органічний трафік інтернет-магазину просів на [X %] за [період], категорії почали зникати з видачі Google, а підрядник розводив руками – «ми нічого не чіпали».
Знайома розмова?
Далі – розбір реального проєкту: що показувала Search Console на старті, як шукали причини, що знайшли, у якому порядку лагодили і скільки тижнів минуло до повернення у видачу. Без назви клієнта – з механікою і цифрами. І з головним висновком, який ламає звичну логіку: питання не «скільки помилок на сайті», а «які з них справді тримають сайт поза індексом».
Що таке технічний аудит сайту. Це діагностика того, як пошукова система сканує, індексує та інтерпретує сайт: robots.txt, редиректи, canonical, hreflang, метадані, індексне покриття. Результат аудиту – не перелік помилок, а пріоритезований план: що саме блокує видимість, у якому порядку це лагодити і якого ефекту чекати.
Сайт зник з видачі: з чого починався кейс
Вихідні дані проєкту: інтернет-магазин у ніші [ніша – узагальнено], [N тис.] товарних позицій, вік домену [років]. Симптом класичний. Покази в GSC просіли з [X] до [Y] за [період], кліки – за ними, [частина] категорійних сторінок зникла зі звіту «Сторінки» як проіндексовані.
Для керівника e-commerce це виглядає ще простіше: канал, що приносив [частку] замовлень, почав танути – а ROAS платних кампаній роздувається, бо органіку доводиться компенсувати бюджетом. Ціна невидимості рахується легко навіть без внутрішніх даних. З нашої практики аудитів: на одному з проєктів дві комерційні сторінки зібрали 685 907 показів за 16 місяців – і лише 44 кліки, бо висіли на позиціях 44–58. Попит був. Видимості не було. Власнику меншого сайту та сама математика болить інакше: кожен тиждень поза індексом – це заявки, які пішли конкуренту з сусіднього SERP-рядка.
Перше, що ми зробили, – не «прогнали сайт через сканер». Перше – зафіксували точку «до»: вивантаження GSC по сторінках і запитах, зріз індексного покриття, серверні логи за [період]. Без цієї точки неможливо ані виміряти ефект аудиту, ані довести його.
Чому «трафік упав» – це скарга, а не діагноз
Скарга описує наслідок. Діагноз називає причину, яку можна виправити й перевірити. Між ними – методика.
Наша діагностика стоїть на двох принципах. Перший: дані беруться з незалежних джерел – Search Console, серверні логи, повний краул сайту, Serpstat – і кожна вагома знахідка має підтвердитися щонайменше у двох із них. Логи кажуть, куди реально ходить Googlebot; краул каже, що він там бачить; GSC каже, що з цього потрапило в індекс. Розбіжності між джерелами – це не шум, це і є найцікавіші місця аудиту.
Другий принцип: кожна знахідка отримує пріоритет за впливом на видачу – Critical, High, Medium, Low – залежно від того, що саме вона робить: блокує індексацію, обмежує зростання чи деградує сигнал. Схожу логіку «спершу критичне – потім можливості» радить і методика аудиту Ahrefs: починати з індексації і технічних розривів, а не з косметики.
Точка.
Без пріоритезації аудит перетворюється на звіт про 500 помилок, де довгий Title на сторінці «Контакти» стоїть поруч із noindex на половині каталогу – і команда розробки місяць лагодить не те.
Інсайт. У випадінні з видачі найчастіше винен не «алгоритм» і не санкції. Більшість сайтів, які «зникли з Google», пошукова система не карала – вона слухняно виконала те, що сайт сам їй наказав: не сканувати, не індексувати або вважати сторінку переадресацією.
Що знайшов аудит: три блокери, які тримали магазин поза видачею
Повний список знахідок проєкту містив [N] пунктів. Але поза видачею сайт тримали три – і всі три належать до класу блокерів: помилок, які напряму зупиняють сканування або індексацію.
Блокер 1 – [заборона сканування: robots.txt – підтвердити фактом проєкту]. [Опис знахідки: які розділи закриті, з якого моменту – від оператора.] Механіка тут задокументована Google: robots.txt керує скануванням, а не індексацією – але заблокований розділ каталогу означає, що краулер не бачить ні контенту, ні оновлень, ні внутрішніх посилань. Класика жанру – правило Disallow, що переїхало зі staging у продакшн разом із релізом…
Блокер 2 – [випадковий noindex у шаблоні – підтвердити фактом проєкту]. [Опис: у якому шаблоні, скільки URL зачепило – від оператора.] Тут є нюанс, який пропускають навіть досвідчені команди: noindex спрацьовує лише тоді, коли сторінка доступна для сканування. Якщо той самий розділ одночасно закритий у robots.txt – краулер просто не побачить директиву, і сторінка може висіти в індексі порожньою заглушкою. Дві помилки в сумі поводяться не так, як кожна окремо. Саме тому знахідки перевіряються зв’язками, а не поштучно.
Блокер 3 – [зламані редиректи на комерційних URL – підтвердити фактом проєкту]. [Опис: ланцюги / редирект «усе на головну» / міжмовні 301 – від оператора.] Редирект – це canonical-сигнал: 301 каже Google, що канонічною має стати цільова адреса. Ланцюг розмиває цей сигнал, а масовий редирект сотень сторінок на головну пошук трактує як soft 404 – сторінки просто зникають з індексу. З нашої практики: на одному аудиті ми знайшли 37 міжмовних редиректів, де україномовні адреси віддавали 301 на іншу мовну версію, а 6 % усього краул-бюджету йшло на обробку переадресацій. Як правильно будувати карту редиректів – окремо розбирали в матеріалі про міграцію сайту без втрати трафіку.
Кожен із трьох блокерів окремо – рядок у чек-листі. Разом вони складалися в системну картину: краулер не бачить частину каталогу, з видимої частини половина заборонена до індексації, а те, що лишилося, розсипає сигнал по редиректних ланцюгах.
Блокери проти обмежувачів: чому одні фікси працюють тижні, а інші – місяці
Це центральна рамка всього кейсу – і головне, чого бракує типовим чек-листам аудиту.
Блокери зупиняють сканування чи індексацію напряму: закритий robots.txt, noindex, зламані редиректи, soft 404. Їх виправлення повертає сторінки у придатний до індексації стан – і ефект видно у вікні тижнів, від наступного переобходу. Обмежувачі не зупиняють нічого: тонкий контент, слабка перелінковка, недиверсифікована лінкова маса, переспамлені метадані. Вони тримають стелю позицій – і лікуються місяцями системної роботи.
Топ-10 причин, які ми знаходимо в аудитах найчастіше (виміри з реальних проєктів нашої практики):
# | Причина | Клас | Що бачили на практиці |
1 | robots.txt закриває обхід | Блокер | заборона зі staging у продакшні |
2 | Redirect-ланцюги і міжмовні 301 | Блокер | 37 міжмовних редиректів, 6 % обходу – переадресації |
3 | Soft 404 | Блокер | неіснуючі URL віддають 200 з контентом головної |
4 | Застарілі sitemap | Блокер/деградація | оголошено 796 URL при 608 в індексі, lastmod трирічної давнини |
5 | Тонкі комерційні сторінки | Обмежувач | 632 слова на сторінці з 491 тис. показів → позиція 54 |
6 | Конфліктна schema-розмітка | Обмежувач | Article і Service одночасно на сторінці послуги |
7 | Недиверсифікована лінкова маса | Обмежувач | 97 % посилань – sitewide-футери з 5 доменів |
8 | Перекошена внутрішня перелінковка | Обмежувач | жодної комерційної сторінки в топ-10 за вагою |
9 | «Просканована, але не проіндексована» | Якісна оцінка | 335 URL поза індексом, 78 % – з достатнім обсягом тексту |
10 | Метадані на масштабі | Обмежувач | 500 задовгих Title, 292 сторінки без H1 |
Зверніть увагу на рядок 9. Він – головне чесне застереження цього кейсу: якщо сторінки «просканані, але не проіндексовані», це якісна оцінка Google, і жоден швидкий фікс її не змінить. Це правило працює у більшості аудитів, які ми бачили. Але не в усіх: буває, що «якісна» причина виявляється замаскованим блокером – і навпаки. Саме тому діагностика передує плану, а не підганяється під нього.
Порядок фіксів повторює порядок обробки пошуку
Черговість робіт у кейсі визначало не «що простіше», а конвеєр пошуку: спершу сканування, потім індексація, потім сигнали ранжування. Лагодити метадані на сторінках, які краулер не бачить, – робота в порожнечу.
Послідовність виглядала так: [відкрили сканування розділів у robots.txt] → [зняли noindex із шаблону, N URL] → [розібрали карту редиректів: прямі 301 без ланцюгів, повернули 200 на цільових сторінках] → перегенерували sitemap під живі URL → подали ключові сторінки на переобхід через «Перевірку URL» у GSC. Технічну частину – шаблони, серверні правила, X-Robots-Tag – закривав Dev-Unit: частина фіксів у таких кейсах живе не в SEO-налаштуваннях, а в коді CMS, і без команди розробки вони не виконуються.
Зняли. Подали. Далі – найважча частина: чекати переобходу і не смикати сайт щотижневими «покращеннями», які змащують картину вимірювання.
Для самодіагностики – матриця, за якою можна звірити власний магазин:
Симптом | Ймовірна причина | Де перевірити | 🚩 Червоні прапорці |
Категорії зникають зі звіту «Сторінки» | noindex / robots.txt | GSC → Індексування, перевірка URL | «Заборонено тегом noindex» на грошових URL |
Покази падають розділом, не сайтом | Закритий каталог у robots.txt | GSC → Налаштування → robots.txt | Disallow на розділ із трафіком |
«Сторінка з переадресацією» росте | Ланцюги, редиректи на головну | краул + вибіркова перевірка 301 | комерційний URL веде на головну або іншу мову |
Сторінки є, трафіку немає | «Просканована, не проіндексована» | GSC → Індексування → причини | сотні URL з достатнім контентом поза індексом |
Покази є, кліків немає | Метадані, позиції 30+ | GSC → Ефективність | CTR нижче 0,1 % при тисячах показів |
Результат: [T] тижнів до повернення у видачу
Вікно вимірювання ми зафіксували заздалегідь – проти точки «до», знятої на старті аудиту. Динаміка по контрольних метриках: індексне покриття [було → стало], покази [X → Y], кліки [X → Y], позиції категорійних запитів [діапазон → діапазон] у вікні [T тижнів].
[Опційно, від оператора: графік або 2–3 контрольні точки динаміки.]
Критерій «сайт повернувся» ми формулювали не як «трафік виріс», а вимірювано: категорії з топ-списку точки «до» знову в індексі, покази по них відновилися до [частки] стартового рівня, у звіті індексування немає грошових URL зі статусом блокера. Скільки це триває? Строків переіндексації Google не документує – на цьому проєкті від фіксів до стабілізації минуло [T тижнів], і чесна відповідь для будь-якого сайту звучить як діапазон, а не дата.
І визнання, без якого кейс був би рекламою, а не кейсом: швидке повернення спрацювало, бо причини були в блокерах. Якби аудит показав, що каталог «просканований, але не проіндексований» через якість, – розмова була б про місяці контентної роботи. Аудит не прискорює Google. Він лише гарантує, що ви лагодите справжню причину.
5 симптомів, що вашому магазину потрібен технічний аудит
Аудит до падіння коштує в рази дешевше, ніж після. Ось симптоми, з якими до нас приходять найчастіше – і з якими краще приходити раніше:
- Покази або кліки в GSC просіли понад 20–30 % без сезонного пояснення.
- У звіті «Сторінки» росте будь-яка з причин: «Просканована, але не проіндексована», «Сторінка з переадресацією», «Заборонено тегом noindex».
- Після релізу, редизайну чи переїзду на нову CMS трафік «чомусь» не відновився – особливо якщо платформу міняли разом зі структурою URL, як це буває при розробці інтернет-магазину під ключ.
- Нові сторінки тижнями не з’являються в індексі.
- Категорії з попитом висять на позиціях 20–50 – покази є, кліків немає.
Окремий пласт – специфіка e-commerce: фасетна навігація, фільтри, пагінація і мовні версії генерують тисячі URL, і саме там блокери люблять ховатися. Системно ми розбираємо це в гайді з SEO-просування інтернет-магазину.
І чек-лист питань до підрядника, якщо аудит вам уже роблять: покажіть точку «до» і джерела даних; який пріоритет у кожної знахідки і чому; які з помилок – блокери; що зміниться у видачі та коли перевіряємо. Підрядник, який відповідає на ці чотири питання, продає не звіт. Він продає результат.
Як ми проводимо технічний аудит в ADS Group
Ми в ADS Group працюємо з 2011 року, і аудит у нас – це не PDF на сто сторінок «на полицю». Звіт на 500 помилок без пріоритетів – як роздруківка всіх аналізів без діагнозу: формально повна, практично марна. Тому кожна знахідка в нашому аудиті має доказ із двох незалежних джерел, клас впливу і місце в черзі фіксів – а сам технічний SEO-аудит сайту веде та сама зв’язка SEO-Unit + Dev-Unit, яка потім реалізує виправлення. Діагност і хірург в одній команді: між «знайшли» і «полагодили» не губиться ані відповідальність, ані час.
Звіт про помилки чи план повернення трафіку: чесне порівняння
Критерій | Аудит-звіт «про все» | Пріоритезований аудит |
Формат результату | 100+ сторінок помилок | план: блокери → обмежувачі → черга фіксів |
Пріоритезація | немає або «критичність сканера» | клас впливу + масштаб + гроші сторінки |
Доказовість | один інструмент | GSC + логи + краул, дві верифікації на знахідку |
Прогноз ефекту | відсутній | вікно ефекту по кожному класу знахідок |
Що з ним робити | розбиратися самим | віддати в роботу як є |
Короткий висновок: цінність аудиту вимірюється не товщиною звіту, а швидкістю, з якою після нього починають лагодити правильні речі.
Що зробити просто зараз
Якщо ваш магазин втрачає видимість – не чекайте, поки видача «сама відновиться»: кожен тиждень із блокером в індексації коштує грошей, які вже не повернуться. Почніть із матриці симптомів вище і звіту «Індексування сторінок» у GSC. А якщо хочете діагноз замість здогадок – зробимо експрес-діагностику вашого сайту за 48 годин: перевіримо robots.txt, noindex, редиректи та індексне покриття і скажемо прямо, чи є у вас блокери і що лагодити першим.
Часті питання
Що входить у технічний аудит сайту?
Діагностика сканування та індексації: robots.txt, редиректи, canonical, hreflang, sitemap, метадані, індексне покриття в GSC, серверні логи, краул сайту. На виході – пріоритезований спи
Чому сайт не індексується в Google?
Найчастіші причини – блокери: заборона в robots.txt, noindex у шаблоні, зламані редиректи або soft 404. Окремий клас – «просканована, але не проіндексована»: Google бачить сторінку, але вважає її недостатньо цінною. Перший клас лагодиться швидко, другий потребує роботи з контентом і сигналами.
Скільки триває технічний аудит і коли буде ефект?
Сам аудит для магазину – зазвичай 5–10 робочих днів залежно від розміру. Ефект від виправлення блокерів видно у вікні кількох тижнів після переобходу; точних строків переіндексації Google не документує. Обмежувачі працюють на горизонті місяців.
Яку звітність я отримаю?
Не перелік помилок, а план: кожна знахідка з доказом із двох джерел, класом впливу, пріоритетом і виконавцем (SEO чи розробка). Плюс зафіксована точка «до» – щоб ефект фіксів можна було виміряти, а не оцінювати на око.
Що як причина виявиться не технічною?
Це теж результат аудиту – і він економить найбільше. Тоді план зміщується на контент, внутрішню перелінковку та зовнішні сигнали, з тими самими пріоритетами й контрольними точками. Гірший сценарій – місяцями лагодити «технічку», коли справа в якості сторінок.
Чи можна провести аудит самостійно за чек-листом?
Базову перевірку – так: звіт «Індексування сторінок» у GSC, robots.txt, вибіркова перевірка редиректів закривають найгрубіші блокери. Межа самодіагностики – зв’язки між помилками і пріоритезація: без логів і краулу легко полагодити помітне замість важливого.
