Оптимізація зображень для SEO: alt, розміри та вага під Core Web Vitals

Оптимізація зображень для SEO — це три прості речі: осмислений alt (для пошуку за картинками та доступності), задані width та height (щоб сторінка не «стрибала» при завантаженні та не провалювала CLS) і легка вага в сучасному форматі (WebP або AVIF). Усе це впливає і на ранжування, і на Core Web Vitals, і коштує недорого — якщо знати, що робити.

Картинки майже завжди найважча частина сторінки, і при цьому про них забувають насамперед. На аудитах інтернет-магазинів ми регулярно бачимо одне й те саме: сотні товарних фото разом без alt і без розмірів. Google таку сторінку індексує, але недобирає контексту, а користувач бачить, як верстка смикається, поки вантажаться зображення. Розберу по черзі, що перевіряє аудит і як це лагодити.

Навіщо потрібен alt і як його писати

Атрибут alt — це текстовий опис картинки, і працює він одразу на кількох фронтах. Google читає alt, щоб зрозуміти, що на зображенні, і підтягує ваші фото в пошук за картинками, звідки йде живий трафік. Скрінрідер незрячого користувача зачитує alt вголос — без нього картинка для такої людини просто зникає. А якщо зображення не завантажилося, замість нього покажеться текст опису. Масштаб проблеми при цьому величезний — Микола у подкасті про alt наводить цифри, від яких стає ніяково:

«Понад 53% головних сторінок у світі мають критичні проблеми з відсутністю або некоректним alt. І найсмішніше — 45% картинок без alt одночасно є клікабельними посиланнями: для незрячої людини таке посилання звучить як набір літер, і вона не розуміє, куди воно веде».

— Микола Шмичков, подкаст SEOquick про alt-теги

А ось кут, який у 2026-му важливіший за колишній. Alt придумали для незрячих людей — але тепер у нього з'явився другий сліпий читач:

«Alt-теги робилися для незрячих. Але незрячими сьогодні є ще й нейромережі: коли штучний інтелект бачить картинку, він намагається вгадати, що це, за ім'ям файлу або за alt — саму картинку він рендерить рідко, економить ресурси. Тому нейромережі — це другі сліпі в цьому світі, і запитів від них до вашого сайту куди більше, ніж від живих незрячих людей».

Тобто порожній alt — це не лише бар'єр для людини зі скрінрідером, а й мовчання для ChatGPT, Perplexity та Google AI, які намагаються зрозуміти, про що ваша сторінка. Як це пов'язано з потраплянням в AI-відповіді, ми розбирали в гайді з GEO-оптимізації під GPT.

Хороший alt описує, що на картинці, конкретно і без води. Формула у Миколи проста:

«Ідеальний alt відповідає на просте запитання: як би я описав цю картинку другу телефоном, щоб передати її суть? Не "фотографія чашки кави на столі", а "чашка кави на дерев'яному столі, від якої йде пара, поруч із відкритим блокнотом" — ви навіть це вже візуалізували в голові».

Не «зображення», не «фото1234.jpg», не простирадло з десяти ключів. Порівняйте:

Ще кілька правил із подкасту, які варто тримати в голові. Вкладіться приблизно у 125 символів — більшість скрінрідерів обривають читання на цій позначці. Не починайте з «зображення», «картинка» або «фото»: робот і так знає, що перед ним картинка, одразу давайте суть. Якщо зображення працює кнопкою — іконка кошика, лупа пошуку, — описуйте її функцію, а не зовнішній вигляд: не «іконка збільшувального скла», а «пошук по сайту». А для графіка передайте головний висновок, а не перелічуйте всі цифри: «графік зростання продажів, +25% у третьому кварталі» скаже і людині, і роботу більше, ніж сухий список чисел. І застереження про суто декоративні картинки (фонові візерунки, роздільники, іконки без сенсу): у них alt залишають порожнім — alt="" — це сигнал скрінрідеру «пропусти, тут нічого важливого». Тому порожній alt — не завжди помилка; аудит якраз підсвічує місця, де опис реально потрібен, але його немає.

Чому width та height прибирають стрибки верстки

Це той випадок, коли два маленькі атрибути безпосередньо впливають на позиції. Коли у <img> не задані width та height, браузер до завантаження файлу не знає, скільки місця під картинку зарезервувати, і відводить їй нуль пікселів. Текст устигає відмалюватися, а потім картинка «приїжджає», розсуває контент — і все скаче вниз. Користувач тягнеться натиснути кнопку, а під пальцем уже інший елемент. Саме ці стрибки Google міряє метрикою CLS (Cumulative Layout Shift) з набору Core Web Vitals, і хороший показник — менше 0,1.

Лікується одним рядком — задати реальні розміри оригіналу:

<img src="divan-milano.webp" width="1200" height="800" alt="Червоний шкіряний диван Milano">

Браузер за цими числами заздалегідь тримає місце потрібної пропорції, і картинка стає в нього без ривка. У CSS при цьому можна спокійно тягнути ширину на 100% — співвідношення сторін сучасний браузер утримає сам. Аудит відзначає такі зображення кодом img-no-dims, і на сторінках із десятками фото це найчастіше джерело поганого CLS.

Вага та формати: WebP та AVIF замість важкого JPEG

Важкі картинки б'ють по швидкості, а швидкість — прямий фактор ранжування та головний внесок у метрику LCP (завантаження основного контенту). Найдешевший спосіб розвантажити сторінку — змінити формат. За великим дослідженням Google, WebP важить на 25–34% менше за JPEG при тій самій якості, а AVIF — приблизно на 50% менше за JPEG і ще на 20–30% легше за WebP. Підтримка вже не проблема: WebP розуміють близько 95% браузерів, AVIF — під 94%, включаючи Safari.

Практика проста. Для WebP тримайте якість 75–85, для AVIF вистачає 60–70 — візуально це як JPEG на 85, але файл у рази легший. Якщо хочете віддавати найлегший формат кожному браузеру і не ризикувати сумісністю, використовуйте <picture> із запасним JPEG:

<picture>
  <source srcset="foto.avif" type="image/avif">
  <source srcset="foto.webp" type="image/webp">
  <img src="foto.jpg" width="1200" height="800" alt="...">
</picture>

Браузер сам візьме перший формат, який вміє: нові отримають AVIF, старі акуратно відкотяться на JPEG.

Ледаче завантаження: корисно, але не для першого екрана

Атрибут loading="lazy" відкладає завантаження картинок, поки користувач до них не догортає, — і для фото нижче першого екрана це чиста користь: сторінка стартує швидше, а Google таке відкладене завантаження прямо підтримує. Але є одна пастка, яка коштує позицій. Не можна вішати lazy на головну картинку першого екрана — ту, що формує LCP. За замірами web.dev, помилкове ледаче завантаження LCP-зображення піднімає LCP на 75-му перцентилі приблизно з 2,9 до 3,5 секунди, а це вже провал Core Web Vitals. Правило коротке: все, що видно одразу при відкритті, вантажимо звичайним способом (а LCP-картинці можна додати fetchpriority="high"), і тільки фото нижче — lazy.

Часті питання

Чи впливає alt на позиції у звичайному пошуку?
Безпосередньо за текстом alt сайт у вебі майже не ранжується, але саме він відкриває трафік із пошуку за картинками та допомагає Google та AI-системам зрозуміти контекст сторінки. Плюс це вимога доступності, яку Google враховує опосередковано.

Чи обов'язково задавати width та height, якщо розміри вже прописані в CSS?
Так. CSS застосовується пізніше, ніж браузер починає малювати сторінку, тому від стрибка верстки рятують саме атрибути в самому тегу <img>. CSS при цьому нікуди не дівається — він керує відображенням, а атрибути резервують місце.

Що вибрати — WebP чи AVIF?
AVIF легший і його варто ставити першим у <picture>, а WebP залишити як більш сумісний запасний варіант перед JPEG. На більшості сайтів достатньо перевести все у WebP — це вже мінус третина ваги без зайвого клопоту.

Хочете побачити, у скількох ваших сторінок картинки без alt та без розмірів, — проженіть сайт через безкоштовний аудит SEOquick: він підсвітить коди alt, img-alt-long та img-no-dims посторінково. А як прискорити сайт цілком, розбирали в гайді про швидкість сайту.