Кейс із цифрами: як технічний аудит повернув інтернет-магазин у видачу
Технічний аудит сайту рідко замовляють із цікавості. Зазвичай до нього доходять так, як герой цього кейсу: органічний трафік інтернет-магазину просів на [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, вибіркова перевірка редиректів закривають найгрубіші блокери. Межа самодіагностики - зв’язки між помилками і пріоритезація: без логів і краулу легко полагодити помітне замість важливого.
