SEO та аналітика

Технічний чек-ліст інтернет-магазину: 10 перевірок, які можна зробити самому

Карта сайту, дублі, швидкість, розмітка, hreflang, HTTPS, аналітика. Кожна перевірка — з прикладом реального дефекту з наших замірів і командою для терміналу.

1 серпня 2026 р.
12 хв читання

Більшість чек-лістів для магазинів написані так, ніби сайт уже здоровий і йому лишилося дотягнути пару тегів. Наприкінці липня — на початку серпня 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. Бот має здогадатися сам.

Як перевірити в себе

  1. Відкрийте ваш-домен/robots.txt і знайдіть рядок Sitemap:. Якщо його немає або він закоментований — це дефолт коробки, який ніхто не чіпав.
  2. Відкрийте адресу карти. Порожня сторінка, нуль байт, XML-помилка або текст про вимкнений модуль — усе це зламана карта.
  3. Порахуйте адреси: збережіть файл і виконайте grep -o '<loc>' sitemap.xml | wc -l. Порівняйте з кількістю товарів в адмінці. Розбіжність у рази означає, що половини каталогу пошук не бачить.
  4. У 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 показати розширений сніпет. Швидкий сервер не продає замість оффера й ціни.

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

Якщо хочете, щоб такі самі заміри зняли з вашого сайту й показали конкретні знайдені дефекти — напишіть нам.

Теги

SEOE-commerceАналітикаPerformance

🤔Вам сподобалась стаття?

Ваша думка допомагає нам створювати кращий контент

Поділіться з друзями

Знайшли щось корисне? 🚀

Допоможіть іншим дізнатись про це — поділіться статтею в соціальних мережах

https://lionex.com.ua/blog/ecommerce-seo-checklist-2025

💚 Дякуємо, що допомагаєте нам рости

Владислав Чистяков

Владислав Чистяков

Засновник LIONEX

Веду LIONEX із 2015 року. Збираю під задачу команду й відповідаю за результат однією точкою: інтернет-магазини, технічне SEO, інтеграції. Пишу про те, що сам міряв на живих сайтах.

Отримуйте найкращі статті на пошту

Підпишіться на нашу розсилку та отримуйте корисні поради, інсайти та новини про веб-розробку, маркетинг та бізнес.

Ми поважаємо вашу приватність. Відписатись можна в будь-який момент.