Більшість чек-лістів для магазинів написані так, ніби сайт уже здоровий і йому лишилося дотягнути пару тегів. Наприкінці липня — на початку серпня 2026 ми знімали технічні заміри з понад тридцяти живих сайтів свого портфоліо, більшість із них — магазини. Майже на кожному знайшлося щось із нульового рівня: карта сайту, яка віддає HTTP 200 і нуль байт; товар, доступний за чотирма адресами; лічильник аналітики, який Google вимкнув три роки тому.
Такі речі ламаються тихо. Сайт відкривається, замовлення йдуть, власник не бачить причин лізти у вихідний код — а сторінки тим часом або не доходять до індексу, або конкурують самі з собою.
Нижче — перевірки в тому порядку, в якому їх має сенс робити. Кожну можна зробити самому, без доступу до сервера і без платних сервісів.
Рівень нуль: чи існують ваші сторінки для пошуку
Ланцюжок грошей з органіки починається не з позицій. Сторінку має знайти бот, просканувати, проіндексувати — і тільки після цього вона взагалі здатна ранжуватись, отримати клік і замовлення. Карта сайту — це прямий список адрес, які ви просите обійти. На каталозі в десятки тисяч позицій без неї частина сторінок може роками не потрапляти боту, бо на них бракує внутрішніх посилань.
Чесна межа: карта не піднімає позиції і не гарантує індексацію — Google пише це прямо у своїй документації. Сторінка товару без опису й без попиту може бути проіндексована і не отримати жодного візиту. На сайті з десяти сторінок карта не дає майже нічого.
Що ми бачили на реальних магазинах
Оптовий магазин нижньої білизни (наш вимір, 31.07.2026): у карті 13 590 URL — 13 428 товарних сторінок і 161 категорія, з них рівно один дублікат. Це еталонна чистота. І при цьому /sitemap.xml віддає 200 з порожнім тілом, а /sitemap_index.xml повертає рядок «HuntBee SEO XML Sitemap Generator PRO is disabled». Робоча карта лежить на нестандартній адресі й врятована лише тим, що прописана в robots.txt. Дві стандартні адреси, куди першими йдуть краулери й аудит-тули, віддають сміття.
Магазин опалювального обладнання і магазин здорового харчування (наш вимір, 31.07.2026): /sitemap.xml — HTTP 200 з тілом на 0 байт. Карти немає взагалі, хоча формально файл «є».
B2B-каталог запчастин до швейних машин (наш вимір, 31.07.2026): 1 992 URL без жодного дубліката, карта повна і робоча — але в robots.txt немає директиви Sitemap. Бот має здогадатися сам.
Як перевірити в себе
- Відкрийте
ваш-домен/robots.txtі знайдіть рядокSitemap:. Якщо його немає або він закоментований — це дефолт коробки, який ніхто не чіпав. - Відкрийте адресу карти. Порожня сторінка, нуль байт, XML-помилка або текст про вимкнений модуль — усе це зламана карта.
- Порахуйте адреси: збережіть файл і виконайте
grep -o '<loc>' sitemap.xml | wc -l. Порівняйте з кількістю товарів в адмінці. Розбіжність у рази означає, що половини каталогу пошук не бачить. - У Search Console розділ «Sitemaps» покаже, чи Google узагалі зміг цей файл прочитати.
Дублі: скільки в карті унікальних адрес
Коли один товар доступний за кількома адресами — через різні шляхи категорій, параметри фільтра, мовні префікси — пошуковик витрачає обмежений ресурс сканування на повторний обхід того самого. Гірший ефект другий: сигнали діляться між дублями, і замість однієї сильної сторінки виходить три слабкі, які ще й конкурують між собою за той самий запит.
Магазин професійного інструменту (наш вимір, 31.07.2026): у карті 25 537 записів <loc>, але унікальних URL лише 6 857. Кожен товар присутній у середньому 3,9 раза під різними шляхами категорій. Сама карта генерується 34,2 секунди.
Роздрібний магазин нижньої білизни (наш вимір, 01.08.2026): каталог 115 456 товарних позицій, у карті 112 646 унікальних товарних URL. Ми взяли вибірку зі 150 випадкових адрес — 50 з них, тобто третина, віддають 301. І всі 50 ведуть на іншу позицію: 70B на 70A, L на XL, білий на чорний. У масштабі каталогу це десятки тисяч адрес, за якими людина з пошуку потрапляє не на той розмір.
Чесна межа: прибирання дублів не додає трафіку — воно перестає його розпорошувати. На короткій дистанції кількість сторінок в індексі після чистки може падати, і це нормальний хід подій. Якщо не попередити про це заздалегідь, виглядає як погіршення.
Як перевірити
curl -s https://ваш-домен/sitemap.xml > s.xml
grep -o '<loc>[^<]*' s.xml | wc -l # усього записів
grep -o '<loc>[^<]*' s.xml | sort -u | wc -l # унікальних
Різниця між двома числами — ваші дублі. Далі візьміть навмання два-три десятки адрес і прогоніть через curl -o /dev/null -s -w "%{http_code} %{redirect_url}\n". Кожен 301 усередині карти сайту — це адреса, яку ви самі просите обійти й самі ж перенаправляєте.
Швидкість: TTFB окремо від усього іншого
Між кліком і появою контенту людина не бачить нічого. Чим довша пауза, тим більша частка закриває вкладку — особливо на мобільному, де до затримки сервера додається затримка мережі. Той, хто пішов до першого екрана, не побачив ні товару, ні ціни, ні кнопки. Швидкість не продає; вона визначає, скільком людям пропозицію взагалі покажуть.
Розмір каталогу тут ні до чого. Магазин тактичного спорядження (наш вимір, 31.07.2026): TTFB 413,8 мс і повне завантаження HTML 511,1 мс — на каталозі в 54 302 товари і 635 категорій. Той самий вимір на роздрібному магазині білизни: TTFB головної 1 544,6 мс, а картки товару — 391,4 мс. Каталог віддається нормально, повільна саме головна, і віддається вона з no-store — без кешу сторінки. На тій же головній 118 тегів <img>, з них нуль з loading="lazy" і нуль у WebP.
Пороги Core Web Vitals беруться з документації web.dev, а не з чиїхось обіцянок: LCP до 2,5 с, INP до 200 мс (замінив FID у березні 2024), CLS до 0,1.
Як виміряти самому
for i in $(seq 1 5); do
curl -o /dev/null -s -w "TTFB %{time_starttransfer} total %{time_total}\n" \
https://ваш-домен/
done
Беріть медіану з п'яти-семи замірів, а не один. Міряйте окремо головну, сторінку категорії і картку товару — вони часто поводяться по-різному, і саме розбіжність між ними показує, де проблема: у кеші сторінки, у запитах до бази чи у вазі HTML. У PageSpeed Insights дивіться передусім блок польових даних CrUX: лабораторний результат — це один запуск на емульованому пристрої, а поле показує ваших реальних відвідувачів.
Структуровані дані: розмічати те, що справді є
Google читає сторінку як текст і не зобов'язаний угадати, де тут ціна, де наявність, а де хлібні крихти. JSON-LD повідомляє це машинним форматом. Коректна розмітка робить сторінку придатною для розширеного вигляду у видачі — ціна й наявність під заголовком, хлібні крихти замість голого URL, вікно пошуку по сайту. Розширений сніпет займає більше площі екрана при тій самій позиції.
Чесна межа тут жорстка. Розмітка не піднімає позиції і не змушує Google показати розширений сніпет — він вирішує сам і може передумати. А розмітка того, чого на сторінці немає, — це привід під ручні санкції.
Показую на власному прикладі, бо він у нас є. У нашому SaaS-проєкті для рерайту описів товарів JSON-LD віддає aggregateRating зі значенням 4.8 і п'ятдесятьма оцінками, а на сторінці нуль згадок слова «відгук». Ми знайшли це під час того ж липневого обходу і фіксуємо відкрито: розмітка декларує оцінки, яких на сторінці не існує. Google окремо забороняє self-serving відгуки для типів Organization і LocalBusiness — тобто оцінки самому собі.
Тому базовий блок для картки товару виглядає так — без рейтингів, поки на сторінці не з'являться справжні відгуки:
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Назва товару",
"image": "https://example.com/photo.jpg",
"description": "Опис товару",
"sku": "SKU123",
"brand": { "@type": "Brand", "name": "Бренд" },
"offers": {
"@type": "Offer",
"url": "https://example.com/product",
"price": "1999",
"priceCurrency": "UAH",
"availability": "https://schema.org/InStock"
}
}
Наскільки це поширена проблема: у B2B-каталозі запчастин на 1 848 позицій ми зафіксували нуль блоків JSON-LD і нуль microdata. У магазині стоматологічних матеріалів — теж нуль. У магазині опалювального обладнання — жодної згадки schema.org на головній. Для контрасту, у магазині тактичного спорядження на головній дев'ять типів розмітки, а в картці товару роздрібного магазину білизни — 21 тип, включно з MerchantReturnPolicy і OfferShippingDetails.
Перевіряється це за хвилину: Rich Results Test від Google плюс Ctrl+U і пошук по application/ld+json. Якщо збираєте розмітку руками, прогоніть готовий блок через валідатор schema.org — він хоча б не пропустить синтаксично невалідний JSON-LD.
Структура каталогу, фасети й пагінація
ЧПУ-адреси дають другий шар до індексації: адреса з назвою товару читається людиною у видачі й у месенджері, параметризована — ні.
Погано: /product?id=123&cat=5
Добре: /catalog/nasosy/hunter-msbn-50q
З фільтрами працює просте правило: індексується те, під що є реальний попит у пошуку. Комбінація «бренд + категорія» зазвичай має попит, комбінація з чотирьох параметрів і сортуванням — ні. Сортування закривається завжди.
| Ситуація | Рішення |
|---|---|
| Один осмислений фільтр із попитом | Індексувати, дати унікальний title і текст |
| Комбінації трьох і більше фільтрів | noindex, follow |
| Сортування, кількість на сторінці, вигляд сітки | noindex або параметр без посилань |
| Пагінація | Унікальні URL, самопосилальний canonical на кожній |
Про пагінацію окремо: rel="next" і rel="prev" Google перестав використовувати для індексації ще у 2019 році й повідомив про це публічно. Ставити canonical з другої сторінки на першу теж не варто — так ви просите не індексувати товари, які лежать далі за першим екраном.
Мови: hreflang ламається частіше, ніж здається
Магазин професійного інструменту (наш вимір, 31.07.2026): 100% адрес у карті сайту — російськомовні /ru/, при тому що сайт за замовчуванням віддає /uk. Жодного українського URL у карті немає.
Роздрібний магазин білизни: hreflang заведено двічі двома різними механізмами, і вони суперечать один одному — один набір веде на кореневі адреси, другий на /ua/. За посиланням uk-ua віддається російський контент. Плюс <html lang="ua"> замість валідного uk, а на польській версії взагалі lang="code" dir="direction" — у шаблон не підставилися змінні.
Перевірка: Ctrl+U, пошук по hreflang, і далі руками відкрити кожне посилання. Дивіться, чи мова сторінки збігається з оголошеною, чи є самопосилальний тег і чи є x-default.
HTTPS і редиректи з кореня
Chrome позначає сторінки без HTTPS як «Не захищено», і найпомітніше — на формах вводу. У момент, коли людина набирає телефон, браузер показує їй попередження.
Магазин професійного інструменту (наш вимір, 31.07.2026): сертифікат Let's Encrypt валідний до вересня 2026, внутрішні адреси по HTTPS працюють нормально — але https://домен/ віддає 301 на http://домен/uk. Кожен, хто заходить на голий домен, потрапляє на незахищений HTTP. Зламаний саме мовний редирект з кореня, і зовні це непомітно.
Другий сюжет: сертифікат виписано на голий домен єдиним SAN, а DNS-запис www існує і веде на той самий сервер. Відвідувач із www отримує попередження браузера про небезпечне з'єднання.
Чесна межа: сертифікат шифрує канал, і все. Він не робить безпечною CMS і не компенсує застарілий PHP — у кількох магазинах ми зафіксували PHP 7.3.33, який без підтримки з грудня 2021 року.
curl -sIL http://ваш-домен/ | grep -Ei 'HTTP/|location'
curl -sIL https://ваш-домен/ | grep -Ei 'HTTP/|location'
curl -sIL https://www.ваш-домен/ | grep -Ei 'HTTP/|location'
Усі три ланцюжки мають закінчуватися на HTTPS і на одній канонічній версії домену.
Аналітика: без неї попередні пункти неможливо перевірити
Кожен пункт вище має сенс лише тоді, коли ви бачите результат. Без даних рішення ухвалюються за відчуттями: щось змінили, здалося, що стало краще.
B2B-каталог запчастин до швейних машин (наш вимір, 31.07.2026): у HTML досі підключений gtag('config','UA-133384797-1') — Universal Analytics, який Google остаточно вимкнув 1 липня 2023 року. Властивості GA4 немає взагалі. Аналітика мертва три роки, і формально «лічильник стоїть».
Магазин стоматологічних матеріалів, магазин здорового харчування, магазин систем поливу і наш власний SaaS-лендинг: нуль згадок GTM, gtag, google-analytics і fbq. Конверсії не міряються ніяк.
Чесна межа: лічильник сам по собі нічого не покращує — він дає можливість побачити. Дані ще треба читати, і це окрема робота. Плюс блокувальники, режим згоди і обмеження браузерів на cookie: GA4 показує тенденцію, а не бухгалтерську істину, і зводити його з касою треба свідомо.
Перевірка на 30 секунд: Ctrl+U, пошук по G-, GTM- і UA-. Якщо знаходиться тільки UA- — у вас немає аналітики.
Внутрішній пошук по каталогу
Людина, яка відкрила поле пошуку, — найгарячіший сегмент на сайті: вона не роздивляється, вона шукає конкретне. Порожня видача означає, що цей відвідувач іде з максимально сформованим наміром.
Побічна вигода зазвичай недооцінена: запити з внутрішнього пошуку — найточніший список того, чого від вас хочуть і чого у вас немає. Готова семантика для реклами й підказка для закупівлі. Наші власні виміри каталогів робилися саме штатним пошуком CMS: у магазині тактичного спорядження це 546 сторінок по 100 позицій, і розбіжність із картою сайту вийшла 0,4%.
Чесна межа: пошук допомагає тому, хто вже знає назву або артикул. Тому, хто ще обирає, він не дає нічого — там працюють категорії й фільтри.
Дрібниці, які видно тільки очима
Автоматичні аудити цього не ловлять, а виглядає воно погано.
Дефолтні заглушки коробки на бойовому сайті: <title> з голою назвою домену, meta description «Мій магазин», у футері «Категорія 1 / 2 / 3 / 4», сторінка послуг із текстом «Тут буде інфо». Ми знайшли рівно такий набір на працюючому магазині систем поливу 01.08.2026.
Приховані посилання автора шаблону перед </body> зі стилем display:none;visibility:hidden;opacity:0 — на тому ж сайті їх чотири штуки. Це вшиті бекліни, і формально це cloaking-ризик.
Назви товарів, що починаються з російського «Купить» на україномовному сайті — і воно тягнеться в <title> та <h1>. Друкарська помилка в слагу, яка потрапила у 19 адрес, у заголовки й у JSON-LD, поки решта шістнадцять тисяч написані правильно.
Головна без жодного <h1>. Meta description на 46 символів.
Порядок дій
Спершу — існування:
- robots.txt містить робочу директиву Sitemap
- карта сайту відкривається і не порожня
- кількість
<loc>збігається з каталогом в адмінці - унікальних адрес у карті приблизно стільки ж, скільки записів
- усередині карти немає 301 і 404
Потім — доступність:
-
http,httpsіwwwзводяться до однієї версії домену по HTTPS - TTFB заміряний окремо для головної, категорії й картки
- canonical самопосилальний на всіх типах сторінок
- hreflang не суперечить сам собі,
langвалідний
Далі — подача у видачі:
- JSON-LD Product з ціною і наявністю на картках
- BreadcrumbList на категоріях і картках
- у розмітці немає рейтингів і відгуків, яких немає на сторінці
- унікальні title і h1, meta description осмисленої довжини
- alt у зображень,
loading="lazy"нижче першого екрана
І базово — вимірюваність:
- GA4 працює,
UA-прибрано - події чекауту доходять у GA4 і в Google Ads
- Search Console підключено, карта в ній прийнята
- звіт внутрішнього пошуку збирається
Чим це перевіряти
З безкоштовного вистачає Search Console, PageSpeed Insights і Rich Results Test — усе від Google. Решта перевірок із цього чек-ліста робиться curl у терміналі: жодного платного сервісу для них не потрібно.
Чого цей чек-лист не дасть
Жоден пункт вище не обіцяє позицій. Чиста карта сайту не піднімає сторінку у видачі — вона робить сторінку існуючою для пошуку. Прибирання дублів не додає трафіку — воно перестає його ділити навпіл. Розмітка не змушує Google показати розширений сніпет. Швидкий сервер не продає замість оффера й ціни.
Наскільки все це вплине саме на ваш магазин, залежить від ніші, попиту в пошуку і від того, скільки з переліченого у вас зараз зламано. Там, де карта віддає нуль байт і половина каталогу поза індексом, різниця буде помітна. Там, де весь список уже зроблено, наступний крок лежить у контенті й асортименті, а не в технічці.
Якщо хочете, щоб такі самі заміри зняли з вашого сайту й показали конкретні знайдені дефекти — напишіть нам.
