SEO для зображень: чотири виправлення, які допомагають Google легше знаходити ваші зображення
Корисний результат, але не готова формула
Один SEO-практик розповів, що сам лише SEO для зображень приніс йому понад 9 200 відвідувачів. Його чотири зміни були простими: перейменувати файли, додати ключові слова до alt-тексту, стиснути зображення та додати схему ImageObject.
Це хороший привід уважніше подивитися на пошук за зображеннями. Але це не доказ того, що чотири зміни принесуть 9 200 відвідувачів іншому сайту.
Трафік із зображень залежить від того, що шукають люди, чи є ваше зображення сильною відповіддю на цей запит, як Google може його сканувати та чи дає цільова сторінка корисний контекст. Фото товару, схема-інструкція, оригінальний графік, туристичне фото й загальне стокове зображення не змагаються в однакових умовах.
Утім, ці чотири виправлення вказують у правильному напрямку. Вони допомагають по-різному:
| Виправлення | Що воно може покращити | Чого воно не гарантує |
|---|---|---|
| Описова назва файлу | Невеликий, але зрозумілий сигнал релевантності та простіше керування активами | Ранжування за конкурентним запитом |
| Точний alt-текст | Доступність і текстовий опис значущого зображення | Видимість за ключовими словами, не пов'язаними із зображенням |
| Розумне стиснення та розміри | Швидше завантаження, кращий досвід і менші витрати на передавання | Кращу якість після надмірного стиснення |
| ImageObject або розмітка зображення на рівні сторінки | Чіткіший зв'язок між зображенням і сутністю сторінки | Розширений результат або пряме зростання позицій |
Мета не в тому, щоб втиснути ключове слово в кожне поле зображення. Мета - публікувати зображення, які Google може знайти, зрозуміти та пов'язати зі сторінкою, що відповідає на запит користувача.
Перша проблема зазвичай у виявленні, а не в метаданих
Перш ніж змінювати назву файлу чи додавати JSON-LD, перевірте, чи може Google взагалі знайти зображення.
Документація Google щодо зображень чітко вказує на пункт, який часто губиться під час редизайну: використовуйте справжній HTML-елемент <img> або <picture>. Google може знаходити зображення за атрибутом src цих елементів. Фонові зображення CSS значно менш корисні для пошуку за зображеннями, бо Google не індексує CSS-зображення так само.
Це поширений сценарій збою на маркетингових сайтах. Гарне hero-зображення додають як background-image у CSS-класі, потім команда пише ідеальний alt-текст десь в іншому місці та дивується, чому зображення ніколи не з'являється. У фонового зображення CSS немає alt-тексту, а саме зображення може взагалі не бути частиною моделі вмісту, доступної для сканування.
Почніть із короткого аудиту:
| Перевірка | Як виглядає хороший стан | Тривожний сигнал |
|---|---|---|
| Елемент зображення | Значуще зображення є в | Зображення існує лише як CSS-фон |
| URL джерела | URL зображення повертає | Правила CDN, robots або автентифікація блокують файл |
| Доступ до сторінки | Сторінка публічна та індексується | Зображення з'являється лише після входу чи взаємодії, яку Google не може завершити |
| Відкладене завантаження | Зображення має URL джерела, який можна сканувати, а не лише JavaScript-заглушку | Справжній URL з'являється лише після прокручування або події на клієнті |
| Контекст сторінки | Текст поруч пояснює, що показує зображення та чому це важливо | Галерея активів без підписів і тематичного контексту |
Якщо ви використовуєте CDN, переконайтеся, що його хост доступний і відстежується. Sitemap для зображень також може допомогти Google виявити зображення, які складно знайти під час звичайного сканування сторінки, зокрема зображення, показані JavaScript. Це допомога для виявлення, а не важіль ранжування.
Зображенню, яке можна виявити, потрібні HTML для сканування, публічний URL джерела, індексована сторінка та релевантний контекст навколо нього.
Виправлення 1: називайте файли за тим, що вони показують, а не за логікою CMS
IMG_1048.jpg, final-v7.png і hero-new.webp ускладнюють роботу всім. Вони не пояснюють редакторам, який це актив, і витрачають невелику частину описового контексту.
Використовуйте коротку назву, зрозумілу людині, яка описує те, що зображення справді показує. Слова в нижньому регістрі, розділені дефісами, легко підтримувати та зручно використовувати в усій бібліотеці.
| Слабка назва файлу | Краща назва файлу | Чому вона краща |
|---|---|---|
|
|
| Називає видимий товар і відмінну деталь |
|
|
| Називає показник, вимір і період |
|
|
| Відповідає темі, яку пояснює візуал |
Не перетворюйте назву файлу на звалище пошукових запитів. best-cheap-water-bottle-water-bottles-buy-online.jpg не допомагає ні людині, ні системі зрозуміти зображення. Це лише виглядає недбало.
Є ще одне практичне обмеження: перейменування наявного зображення змінює його URL у багатьох CMS. Якщо це зображення вже має видимість або зворотні посилання, перенаправте старий URL файлу, коли ваш стек це підтримує, оновіть посилання й не ламайте сторінки заради незначного покращення назви. Спочатку застосовуйте правило іменування до нових активів, а потім виправляйте цінні старі зображення під час звичайної підтримки контенту.
Виправлення 2: пишіть alt-текст як опис, а не як поле для ключового слова
Alt-текст має дві функції. Він дає користувачам екранних читачів корисний опис і забезпечує текстовий контекст, якщо зображення не можна відобразити. Коли зображення важливе для сторінки, точний опис також допомагає пошуковим системам зрозуміти його вміст.
Найпростіша помилка - повторювати цільове ключове слово сторінки. Це створює погану доступність і слабку редакційну роботу.
| Роль зображення | Слабкий alt-текст | Кращий alt-текст |
|---|---|---|
| Деталь товару |
|
|
| Графік даних |
|
|
| Скриншот інструкції |
|
|
| Декоративний роздільник |
| Порожній alt-текст: |
Хороший alt-текст не мусить описувати кожен піксель. Він має передавати інформацію, яку зображення додає до сусіднього тексту. Якщо абзац поруч уже каже точно те саме, зробіть alt-текст коротким. Якщо зображення містить графік, схему чи інструкції, опишіть висновок, а не намагайтеся переписати кожен підпис.
Фраза «додайте ключове слово до alt-тексту» безпечна лише тоді, коли ключове слово природно входить до точного опису. Ключове слово має бути наслідком гарного опису зображення, а не самим завданням.
Виправлення 3: зменшуйте байти, не погіршуючи зображення
Стиснення зображень важливе, бо важкі зображення сповільнюють сторінки, особливо на мобільних з'єднаннях. Воно не перетворює нерелевантне зображення на корисний результат пошуку. Але сторінка, що швидко завантажується, дає людям більше шансів побачити, використати та не залишити знайдений контент.
Використовуйте найменші корисні розміри. Завантаження фотографії завширшки 4 000 пікселів для контентного слота завширшки 700 пікселів витрачає пропускну здатність. Віддавайте адаптивні варіанти через srcset або <picture>, коли платформа їх підтримує, і використовуйте сучасні формати на кшталт WebP або AVIF, якщо візуальна якість залишається прийнятною.
Компроміс реальний. Розмитий крупний план товару або нечитабельний графік шкодять сторінці, навіть якщо важать менше. Перевіряйте зображення у фактичному розмірі відображення на телефоні й настільному екрані. Для схем із дрібним текстом SVG або ретельно експортований PNG можуть бути кращими за агресивно стиснутий фотографічний формат.
Перевірте це перед публікацією:
- Відобразіть зображення в запланованій ширині контейнера.
- Порівняйте його зі звичайної відстані перегляду, а не лише за масштабу 200 відсотків.
- Переконайтеся, що підписи, числа та лінії залишаються читабельними.
- Перевірте сторінку інструментом продуктивності й визначте найбільші запити зображень.
- Спочатку виправте найбільші та найпомітніші зображення.
Такий порядок запобігає знайомій помилці Image SEO: оптимізувати десятки малих мініатюр, коли одне надто велике hero-зображення завдає основної шкоди.
Виправлення 4: використовуйте розмітку ImageObject для зв'язку, а не як магію
Схема ImageObject може зробити зв'язок між зображенням і сторінкою явнішим. На сторінці статті документація Google показує, що сторінка може визначити головне зображення через primaryImageOfPage або прикріпити зображення до головної сутності сторінки, наприклад BlogPosting.
Це корисний структурований контекст. Це не обіцянка, що Google Images ранжуватиме актив, покаже особливе оформлення чи надішле фіксований обсяг трафіку.
Для допису в блозі часто чистіше використовувати властивість image у наявній розмітці BlogPosting, ніж додавати відокремлений блок ImageObject для кожного вбудованого візуалу. Ось мінімальний приклад:
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"headline": "How to audit images for Google Images",
"mainEntityOfPage": "https://example.com/blog/image-seo-audit",
"image": {
"@type": "ImageObject",
"contentUrl": "https://example.com/images/image-seo-audit-checklist.webp",
"url": "https://example.com/images/image-seo-audit-checklist.webp",
"caption": "A five-step image SEO audit checklist",
"width": 1600,
"height": 900
}
}
Використовуйте URL, які відкриваються, описують реальний актив і відповідають тому, що користувачі бачать на сторінці. Не заявляйте підпис, автора, ліцензію чи розміри, якщо це неправда. Якщо ліцензування важливе для вашого бізнесу, Google також підтримує метадані ліцензії зображення через структуровані дані або вбудовані IPTC-метадані. Це окремий випадок використання від звичайного Image SEO.
Після додавання розмітки перевірте її тестом структурованих даних, а потім перегляньте вихідний код відрендереної сторінки. Schema, яка існує лише у staging-збірці або перезаписується плагіном, нічого не робить на живій сторінці.
Що пропускає допис із чотирма пунктами
Найсильніше поле зображення у світі не врятує слабку цільову сторінку. Google також треба зрозуміти сторінку навколо зображення.
Для кожного зображення, яке ви очікуєте зробити виявлюваним, перевірте ці питання:
- Чи відповідає зображення на головну тему сторінки або пояснює її?
- Чи розміщене воно поруч із релевантним текстом, описовим заголовком або корисним підписом?
- Чи воно оригінальне, чи це загальний стоковий актив, що з'являється на сотнях сторінок?
- Чи отримує людина, яка переходить із Google Images, корисну відповідь без пошуку по сторінці?
- Чи працює зображення на мобільному пристрої та залишається доступним, коли JavaScript повільний або недоступний?
Ось чому оригінальні діаграми, анотовані фото товарів, приклади до і після та графіки даних можуть працювати добре. Вони несуть інформацію, яку шукач справді може хотіти. Декоративний градієнт не стає можливістю для пошуку зображень лише тому, що має schema.
30-денний тест Image SEO, який дає докази
Не перейменовуйте всі файли медіатеки у п'ятницю після обіду. Запустіть контрольований тест на сторінках, де намір візуального пошуку є правдоподібним.
Тиждень 1: оберіть кандидатів
Оберіть від 10 до 20 сторінок із корисними оригінальними візуалами: сторінки категорій або товарів ecommerce, інструкції, візуальні пояснення, локальні сторінки, сторінки порівняння чи кейси. Запишіть поточні URL зображень і сторінок, покази й кліки зображень, якщо вони доступні, трафік сторінок і наявні метадані зображень.
Тиждень 2: виправте основи
Замініть непрозорі назви у нових активах або тих, які можна безпечно змінити. Додайте точний alt-текст. Переконайтеся, що важливі зображення використовують HTML для сканування, мають публічні URL джерела й не є без потреби надто великими. Додайте або виправте схему зображення на рівні сторінки, коли вона справді описує вміст.
Тиждень 3: покращте цільову сторінку
Додайте пряме пояснення біля зображення, чіткий заголовок і підпис, коли це допомагає читачеві. Для графіка поясніть значення тенденції. Для фото товару поясніть матеріал, розмір, сценарій використання або властивість, яку доводить фото.
Тиждень 4: виміряйте перед масштабуванням
Використовуйте звіти Search Console за типами пошуку, коли вони доступні, разом з аналітикою сторінки та вибірковою перевіркою у Google Images. Шукайте зміни в показах, кліках, темах запитів зображень, взаємодії з цільовою сторінкою та якості конверсій. Ведіть журнал змін. Якщо зображення отримує більше кліків, але відвідувачі одразу йдуть, цільова сторінка може не відповідати візуальній обіцянці.
Мета - повторюваний шаблон, а не драматичний скриншот. Одного корисного результату достатньо, щоб вирішити, чи заслуговує Image SEO на більший процес роботи з контентом та активами.
Кожне виправлення має іншу роботу. Виміряйте їхню комбінацію перед масштабуванням роботи на всю медіатеку.
Нехай ШІ робить інвентаризацію, а не вигадує
Image SEO стає виснажливим на великому сайті, бо докази розкидані між медіатекою, HTML, полями CMS, звітами продуктивності, sitemap і Search Console. ШІ може допомогти зібрати роботу: перелічити зображення без alt-тексту, позначити загальні назви файлів, порівняти розміри відображення й джерела, згрупувати сторінки за візуальним наміром і скласти чергу аудиту для людської перевірки.
Він не повинен вигадувати описи для зображень, яких не бачить, або додавати ту саму цільову фразу до сотень атрибутів alt. Саме так аудит перетворюється на масове переспамлення ключовими словами.
SEO-інструменти Auspia можуть допомогти командам почати з перевірки на рівні сайту, а потім перетворити висновки на сфокусований backlog Image SEO. Корисний результат - не «усі зображення оптимізовано», а пріоритетний список активів із реальною проблемою: заблоковане виявлення, відсутній контекст, надто велика доставка, слабкі описи або зламані зв'язки зі сторінкою.
Чекліст Image SEO
| Перш ніж назвати зображення оптимізованим | Перевірте |
|---|---|
| Зображення можна виявити | Воно є в HTML для сканування, а URL файлу публічно доступний |
| Назва файлу корисна | Вона описує зображення без накопичення термінів |
| Alt-текст чесний | Він описує значущий вміст; декоративні зображення мають порожній alt |
| Сторінка дає контекст | Релевантні текст, заголовки й підписи пояснюють роль зображення |
| Доставка ефективна | Правильний розмір відображення, адаптивні джерела й прийнятна візуальна якість |
| Розмітка точна | Властивості зображення описують видимий, доступний актив |
| Результат виміряно | Search Console і метрики сторінки порівнюються до та після змін |
Поширені запитання
Чи покращує зміна назви файлу зображення позиції в Google Images?
Описова назва файлу - розумний допоміжний сигнал і спосіб підтримувати порядок у медіатеці. Вона рідко є причиною, чому зображення ранжується саме по собі. Не ламайте усталені URL зображень лише заради перейменування низькоцінних активів.
Чи повинне кожне зображення мати ключове слово в alt-тексті?
Ні. Alt-текст має точно описувати значущі зображення. Використовуйте цільову фразу лише тоді, коли вона природно входить до опису. Декоративні зображення зазвичай мають використовувати alt="", щоб екранні читачі могли їх пропускати.
Чи ранжує schema ImageObject зображення?
Ні. ImageObject і пов'язана розмітка сторінки допомагають чіткіше показати зв'язок зображення та сторінки. Вони не гарантують розміщення в Google Images, розширений результат чи трафік.
Чи потрібен мені sitemap для зображень?
Не завжди. Google може знайти багато зображень під час нормального сканування HTML. Sitemap для зображень корисний, коли їх складно виявити, зокрема в деяких реалізаціях JavaScript, або коли потрібна повніша карта виявлення.
Які зображення варто оптимізувати першими?
Починайте із зображень на сторінках, які вже мають попит і чіткий сценарій візуального пошуку. Оригінальні фото товарів, діаграми, графіки, інструкції та приклади до і після зазвичай кращі кандидати, ніж загальна декоративна графіка.
Висновок
Урок із чотирьох пунктів від цього практика варто застосувати, але з однією поправкою: Image SEO - це не форма з чотирма полями. Назви файлів, alt-текст, стиснення та розмітка ImageObject допомагають, коли підтримують доступне для сканування, корисне та багате на контекст зображення на сторінці, яку люди справді хочуть відвідати.
Почніть із невеликого набору сильних візуальних активів, виправте очевидні технічні та редакційні прогалини, а потім виміряйте результат цільової сторінки. Так ви отримаєте кращу бібліотеку зображень, кращий досвід сторінки та обґрунтовану причину інвестувати більше в Google Images.
Автор: Julian Mercer, технічний SEO-практик із 14-річним досвідом в Auspia. Julian пише про crawlability, schema, рендеринг, архітектуру сайту та технічні основи контенту, який може читати ШІ.
