# Оптимізація зображень для SEO: alt, формати, швидкість

> Оптимізація зображень для SEO у 2026 році: alt текст, назви файлів, WebP/AVIF, стиснення, srcset, lazy loading, карта сайту для зображень і перевірка сайту.

URL: https://seorecheck.com/ua/blog/image-seo-best-practices · Опубліковано: 2026-11-04 · [English](https://seorecheck.com/blog/image-seo-best-practices.md), [Español](https://seorecheck.com/es/blog/image-seo-best-practices.md)

Оптимізація зображень для SEO зводиться до двох завдань. Перше — допомогти Google знайти й зрозуміти ваші картинки: використовуйте справжні елементи `<img>`, описовий alt текст і назви файлів, розміщуйте зображення поруч із релевантним текстом. Друге — зробити їх швидкими: сучасні формати, правильний розмір, зарезервоване місце і жодного lazy loading для головного зображення на першому екрані.

Зображення важливі з двох причин. Вони можуть приводити власний трафік через Google Картинки та візуальні результати пошуку. А ще вони часто найважчий елемент сторінки, тож саме від них залежить, чи проходять ваші сторінки [Core Web Vitals](https://seorecheck.com/ua/blog/core-web-vitals-guide). У цьому посібнику розглянуто обидва аспекти — у тому порядку, в якому більшості сайтів варто їх виправляти.

## Як Google знаходить і розуміє зображення?

Google знаходить зображення через атрибут `src` HTML-елементів `<img>`, а розуміє їх за текстом навколо: alt текстом, назвою файлу, підписами, найближчими заголовками та самою сторінкою. Зображення, додані лише як CSS-фон, не індексуються, тому кожна картинка, яка має ранжуватися, повинна бути справжнім тегом `<img>`.

У [рекомендаціях Google щодо SEO для зображень](https://developers.google.com/search/docs/appearance/google-images) про це сказано прямо: Google може знаходити зображення в атрибуті `src` елемента `<img>`, але не індексує CSS-зображення. На цьому спотикається чимало сайтів. Банери на першому екрані, фото товарів у слайдерах і фото команди часто задають через `background-image`, бо так їх легше стилізувати. Відвідувачі бачать їх нормально, а для Google Картинок вони невидимі.

Там же радять розміщувати зображення біля релевантного тексту та на сторінках, що відповідають темі зображення. Фото обіднього столу з горіха на сторінці цього товару, під заголовком і поруч з описом, має достатньо контексту. Те саме фото на загальній сторінці «Галерея» без тексту майже не має контексту.

Ще два правила, які варто знати:

- **Одна URL-адреса для одного зображення.** Google просить завжди посилатися на зображення через ту саму URL-адресу, щоб він міг кешувати й повторно використовувати файл, а не завантажувати його багато разів. Параметри для скидання кешу, що змінюються з кожним деплоєм, цьому заважають.
- **Не ховайте зображення за JavaScript, який Google не може виконати.** Якщо галерея додає картинки лише після кліку або через скрипт, який не рендериться, Google може їх так і не побачити. У нашому посібнику про [проблеми рендерингу JavaScript](https://seorecheck.com/ua/blog/javascript-seo-rendering-problems) показано, як перевірити, що насправді рендерить Googlebot.

## Як писати alt текст для зображень?

Хороший alt текст простими словами описує, що зображено на картинці, з урахуванням контексту сторінки. Орієнтуйтеся на коротку фразу чи речення, яке було б зрозуміле людині, що не бачить зображення, якщо прочитати його вголос. Використовуйте ключове слово лише тоді, коли воно справді описує картинку, і ніколи не напихайте в атрибут перелік ключових слів.

У рекомендаціях Google є наочний приклад: «Dalmatian puppy playing fetch» (цуценя далматинця грається з паличкою) — хороший alt текст, а порожній атрибут, одне слово на кшталт «цуценя» чи набір ключових слів про собак — ні. Alt текст виконує дві функції одночасно. Це головний текстовий сигнал, за яким Google розуміє зображення, і саме його озвучують програми зчитування з екрана, тож текст для людей працює й на пошук.

Практичні правила:

- **Описуйте, а не позначайте.** «Дубовий обідній стіл на шість персон із чорними металевими ніжками» краще, ніж «стіл» чи «зображення товару 3».
- **Пишіть коротко.** Зазвичай вистачає одного речення; довгі абзаци — для підпису чи основного тексту.
- **Не пишіть «зображення…» чи «фото…».** Програми зчитування з екрана й так повідомляють, що це зображення.
- **Залишайте порожнім alt декоративних зображень.** Роздільники, відступи й фонові візерунки мають отримати `alt=""`, щоб їх пропускали, а не вигадані описи.
- **Не дублюйте підпис слово в слово.** Підпис — для додаткового контексту, alt — для того, що видно на картинці.
- **Для зображень-посилань описуйте ціль посилання.** Якщо зображення — єдиний вміст посилання, його alt текст працює як анкор.

## Чи важливі назви файлів і формати зображень?

Так, важливі й ті, й інші, але по-різному. Описова назва файлу — невеликий сигнал релевантності; формат здебільшого впливає на швидкість сторінки. Перейменовуйте файли з камери до завантаження та віддавайте зображення в сучасному форматі на кшталт WebP чи AVIF з розумним запасним варіантом.

Google рекомендує описові назви файлів, наприклад `my-new-black-kitten.jpg` замість `IMG00023.JPG`. Використовуйте слова в нижньому регістрі, розділені дефісами, опишіть об'єкт — і досить. Для українськомовних сайтів зазвичай використовують латиницю (англійські слова чи транслітерацію). Саме перейменування позицій не підніме, але під час завантаження воно нічого не коштує. Міняти назви тисяч уже наявних зображень рідко має сенс, якщо ви не мігруєте сайт, бо кожну перейменовану URL-адресу доведеться заново сканувати.

Щодо форматів, Google Пошук [підтримує](https://developers.google.com/search/docs/appearance/google-images) BMP, GIF, JPEG, PNG, WebP, SVG і AVIF. Що обрати:

| Формат | Найкраще для | Примітки |
|---|---|---|
| AVIF | Фото, великі зображення на першому екрані | Зазвичай найменші файли; перевірте підтримку у вашій CMS/CDN |
| WebP | Фото та графіка на більшості сайтів | Широка підтримка, хороший варіант за замовчуванням |
| JPEG | Запасний варіант для фото | Використовуйте прогресивне кодування та якість ~75–85 |
| PNG | Скриншоти, зображення з прозорістю й чіткими краями | Для фото часто завеликий |
| SVG | Логотипи, іконки, прості ілюстрації | Масштабується без втрати якості; крихітні файли |
| GIF | Уникайте | Для анімацій використовуйте відео (MP4/WebM) |

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

## Як зображення впливають на швидкість сторінки та Core Web Vitals?

На багатьох сторінках найбільший видимий елемент — зображення, тож саме воно часто визначає Largest Contentful Paint (хороший показник — 2,5 секунди або менше). Зображення без зарезервованого місця також спричиняють зсуви макета, що погіршують CLS (хороший показник — 0,1 або менше). Завеликі, непріоритизовані чи неправильно ліниво завантажені зображення — найпоширеніша причина обох проблем.

Виправляйте в такому порядку:

1. **Віддавайте правильний розмір.** Не надсилайте фото на 4000 пікселів у блок шириною 600 пікселів. Змінюйте розмір під час завантаження або використовуйте CDN для зображень і пропонуйте кілька ширин через `srcset` і `sizes`.
2. **Завжди вказуйте `width` і `height`.** [Посібник web.dev з lazy loading](https://web.dev/articles/browser-level-image-lazy-loading) радить додавати атрибути `width` і `height` до всіх тегів `<img>`, щоб браузер міг зарезервувати місце й уникнути зсувів макета. CSS усе одно може зробити зображення адаптивним.
3. **Ніколи не застосовуйте lazy loading до LCP-зображення.** У тому ж посібнику сказано не робити ліниве завантаження для зображень, які, імовірно, будуть в області перегляду під час завантаження сторінки, особливо LCP-зображень, бо браузер не може почати їх завантажувати, доки не знає, де вони розташовані на сторінці.
4. **Лениво завантажуйте все нижче першого екрана** через нативний атрибут `loading="lazy"`, а не через важкий скрипт.
5. **Пріоритизуйте головне зображення.** [Стаття web.dev про Fetch Priority](https://web.dev/articles/fetch-priority) пояснює, що зображення зазвичай стартують з низьким пріоритетом, а позначка `fetchpriority="high"` для важливого зображення дає змогу одразу завантажувати його з високим пріоритетом; у прикладі з Google Flights це скоротило LCP з 2,6 с до 1,9 с. Сприймайте це як підказку для одного-двох критичних зображень, а не для всіх.

Головне зображення, що відповідає всім п'яти правилам, виглядає так:

```html
<img
  src="/img/oak-dining-table-800.webp"
  srcset="/img/oak-dining-table-400.webp 400w,
          /img/oak-dining-table-800.webp 800w,
          /img/oak-dining-table-1600.webp 1600w"
  sizes="(max-width: 600px) 100vw, 800px"
  width="800" height="533"
  alt="Дубовий обідній стіл на шість персон із чорними металевими ніжками"
  fetchpriority="high">
```

Зверніть увагу на запасний `src`. Рекомендації Google вимагають завжди вказувати запасну URL-адресу в `src`, коли ви використовуєте `srcset` або `<picture>`, щоб будь-який сканер і браузер міг щось завантажити.

Тут найважливіша мобільна версія, бо Google індексує саме мобільну версію ваших сторінок. Якщо мобільний шаблон підміняє або приховує зображення, перегляньте наш [чекліст mobile-first індексації](https://seorecheck.com/ua/blog/mobile-first-indexing-best-practices).

## Чи потрібна карта сайту для зображень?

Карта сайту для зображень необов'язкова. Вона допомагає, коли Google може не знайти зображення звичайним скануванням, наприклад якщо вони завантажуються через JavaScript або розміщені на домені CDN. Для більшості сайтів зі звичайними тегами `<img>` у HTML вистачає стандартного XML-sitemap і сторінок, доступних для сканування.

Якщо все ж використовуєте її, тримайте її простою. [Документація Google про карти сайту для зображень](https://developers.google.com/search/docs/crawling-indexing/sitemaps/image-sitemaps) тепер підтримує лише два теги: `<image:image>` і `<image:loc>`. Старі теги `<image:caption>`, `<image:title>`, `<image:geo_location>` і `<image:license>` застаріли, тож їх додавання нічого не дає. Зображення можуть розміщуватися на іншому домені, наприклад на CDN, якщо обидва домени підтверджено в Search Console.

Записи про зображення можна додати до наявного sitemap сторінок, а не створювати окремий файл. Що ще має бути в карті сайту, розповідаємо в нашому [посібнику з XML-sitemap](https://seorecheck.com/ua/blog/xml-sitemap-seo-guide).

## Які структуровані дані та метатеги допомагають зображенням?

Структуровані дані й теги Open Graph підказують Google, яке зображення найкраще представляє сторінку. Потім воно може з'явитися в розширених результатах, Discover і в превʼю при поширенні в соцмережах. Для сторінок товарів, рецептів і статей властивість `image` часто обов'язкова для функцій розширених результатів, тож її відсутність може коштувати вам видимості.

У рекомендаціях Google щодо зображень згадано властивість schema.org `primaryImageOfPage` і метатег `og:image` як способи вказати бажане зображення, а також зазначено, що атрибут `image` — обов'язкове поле для значків розширених результатів. На практиці:

- **Розмітка Product, Article, Recipe:** додавайте `image` з повними URL-адресами, доступними для сканування, бажано в кількох співвідношеннях сторін.
- **`og:image`:** вказуйте на кожній важливій сторінці; його використовують соцмережі, і він може впливати на вибір мініатюри в Google.
- **Discover:** [документація Google про Discover](https://developers.google.com/search/docs/appearance/google-discover) рекомендує великі зображення шириною щонайменше 1200 px і загальною кількістю пікселів понад 300 000, увімкнені налаштуванням robots `max-image-preview:large` (або через AMP). Без цього налаштування ваші статті можуть отримувати лише маленьку мініатюру.

Перевірте, чи метатег robots на ваших сторінках випадково не обмежує превʼю зображень. `max-image-preview:none` або `noimageindex`, що лишилися зі staging-шаблону, тихо приберуть ваші зображення з результатів. Також переконайтеся, що robots.txt не блокує папку із зображеннями чи CDN; як це перевірити, показано в нашому [посібнику з robots.txt](https://seorecheck.com/ua/blog/robots-txt-seo-guide).

## Як знайти проблеми із зображеннями на сайті?

Поєднайте сканер із Lighthouse і Search Console. Сканер знаходить відсутні alt тексти, биті URL-адреси зображень, зображення лише в CSS і завеликі файли на всіх сторінках. Lighthouse показує, яке зображення є LCP-елементом і чи воно ліниво завантажується або завелике. Search Console показує трафік з пошуку картинок і Core Web Vitals за групами сторінок.

Швидкий порядок перевірки:

1. **Search Console → Ефективність → Тип пошуку: Зображення.** Подивіться, які сторінки вже отримують кліки з картинок, а які важливі сторінки — жодного.
2. **Проскануйте сайт** і вивантажте зображення з порожнім чи відсутнім `alt`, дуже великими файлами, битими (4xx/5xx) URL-адресами та без `width`/`height`.
3. **Запустіть Lighthouse на ключових шаблонах** (головна, категорія, товар, стаття). Шукайте попередження «Largest Contentful Paint image was lazily loaded», «Properly size images» і «Serve images in next-gen formats».
4. **Перевірте відрендерений HTML** на шаблонах із великою кількістю JavaScript, щоб переконатися, що після рендерингу зображення є елементами `<img>`.
5. **Перевірте структуровані дані** на сторінках товарів і статей: чи є `image` і чи завантажується його URL-адреса.

Якщо не хочеться зводити ці інструменти докупи, [безкоштовний SEO-аудит від SEORecheck](https://seorecheck.com/ua/request) сканує ваші сторінки, позначає відсутні alt тексти й биті зображення та за допомогою Lighthouse у реальному браузері показує, які зображення сповільнюють LCP, — з прикладами URL-адрес вашого власного сайту. Як це виглядає, можна подивитися у [прикладі звіту](https://seorecheck.com/ua/sample).

## Що виправляти насамперед?

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

| Пріоритет | Проблема | Чому |
|---|---|---|
| Високий | LCP-зображення з lazy loading або завелике на ключових шаблонах | Напряму погіршує LCP на кожній сторінці з цим шаблоном |
| Високий | Важливі зображення лише в CSS або додаються через JS | Не індексуються в Google Картинках |
| Високий | Зображення заблоковані в robots.txt або через `noimageindex` | Повністю зникають з результатів пошуку зображень |
| Середній | Немає `width`/`height` | Зсуви макета, гірший CLS |
| Середній | Немає alt тексту в змістових зображеннях | Втрата релевантності та доступності |
| Середній | Немає `image` у розмітці Product/Article | Втрата права на розширені результати |
| Низький | Назви файлів «з камери» в старих зображеннях | Слабкий сигнал; виправляйте для нових файлів |

Ширший метод ранжування виправлень за впливом і зусиллями описано в статті [як пріоритизувати SEO-виправлення](https://seorecheck.com/ua/blog/how-to-prioritize-seo-fixes).

## Головне

- Використовуйте справжні елементи `<img>`; Google не індексує фонові CSS-зображення.
- Пишіть короткий описовий alt текст насамперед для людей; для декоративних зображень — `alt=""`.
- Давайте файлам описові назви під час завантаження й надавайте перевагу WebP чи AVIF, із запасним `src` для `srcset`.
- Вказуйте `width` і `height` для кожного зображення, застосовуйте lazy loading нижче першого екрана і ніколи — для LCP-зображення.
- У карті сайту для зображень потрібен лише `<image:loc>`; теги caption, title, [geo](https://seorecheck.com/ua/blog/generative-engine-optimization-geo) і license застаріли.
- Додавайте `image` у структуровані дані та `og:image`, дозвольте `max-image-preview:large` для Discover.
- Починайте з шаблонів, що приносять дохід, а не з перейменування старих файлів.

---

## Хочете знати, що виправити на своєму сайті?

Отримайте безкоштовне превʼю SEO-аудиту: оцінку й реальні проблеми з доказами з ваших сторінок.

- [Отримати безкоштовне превʼю аудиту](https://seorecheck.com/ua/request)
- [Переглянути приклад звіту](https://seorecheck.com/ua/sample)