Зображення товарів у Merchant Center: як перевірити image_link, фото та варіанти
У картці магазину червона чашка, а в Merchant Center — синя. Або фото відкривається у вашому браузері, проте товар має помилку зображення. Заміна всіх фотографій навмання приховує причину: неправильний файл, недоступна адреса й затримка обробки потребують різних дій.
Почніть з одного ID. Пройдіть шлях «рядок даних → фактичний файл → конкретний варіант → оновлене джерело → діагностика». Мета перевірки — мати доказ кожного переходу, а не лише красиве фото у папці комп’ютера.
1. Зафіксуйте один проблемний товар
Випишіть ID, колір, URL картки, поточний image_link і точне повідомлення Merchant Center. Якщо зображень декілька, окремо позначте головне та додаткові. Збережіть час перевірки: пізніше він допоможе відрізнити старі дані від нового результату.
Знайдіть цей ID саме у джерелі, яке передаєте Google. Запис у робочій таблиці й фактично опублікований XML можуть відрізнятися. Якщо в таблиці вже правильна адреса, а у вивантаженні досі стара, спершу треба простежити підготовку джерела. Повторне редагування фотографії цього не пояснить.
2. Відкрийте адресу файлу, а не сторінку товару
За специфікацією Google для image_link, поле містить HTTP(S)-адресу головного зображення; розширення має відповідати формату файлу. Для отримання фото потрібен доступ Googlebot і Googlebot-image.
Скопіюйте адресу безпосередньо з перевіреного рядка. Відкрийте її у приватному вікні без входу в магазин. Не підміняйте її адресою з галереї, яку знайшли окремо: зараз перевіряється саме значення, передане у фіді.
| Що фактично відкривається | Що записати | Наступна дія |
|---|---|---|
| Окреме фото потрібної чашки | Адресу та зображений колір | Перейти до звірки варіанта |
| HTML-сторінка з меню або переглядачем | Посилання веде на сторінку | Знайти пряму адресу файлу, потім перевірити її повторно |
| Помилка 403 або сторінка перевірки доступу | Точний URL, час, відповідь | Передати адміністратору цей конкретний випадок для діагностики |
Успішне відкриття у браузері не доводить доступу робота. Якщо є розбіжність із Merchant Center, адміністратору потрібні точний заблокований URL і повідомлення Google, щоб перевірити відповідне правило та журнали доступу. Пароль від кабінету не потрібен для відкриття публічного фото. Не вимикайте захист усього сайту заради одного зображення. Типи збоїв із HTML та доступом розглянуто в інструкції Google з перевірки зображень.
3. Розберіть пару MUG-RED і MUG-BLUE
Візьмемо два навчальні записи однієї моделі чашки. example.com — зарезервований домен для прикладів; ці адреси не призначені для робочого каталогу.
| ID та колір | image_link до перевірки | Висновок після перегляду файлу |
|---|---|---|
| MUG-RED, червоний | https://example.com/images/mug-blue-front.jpg | На фото синя чашка: рядок не відповідає варіанту |
| MUG-BLUE, синій | https://example.com/images/mug-blue-front.jpg | Колір відповідає; доступ перевіряється окремо |
Причина тут не просто в повторенні URL. У цьому навчальному сценарії файл показує синю чашку. Для MUG-RED підготуйте фото червоної чашки, опублікуйте його за перевіреною адресою mug-red-front-v2.jpg і змініть відповідне поле цього запису. MUG-BLUE не треба редагувати лише тому, що сусідній рядок був помилковим.
Потім відкрийте картку саме червоного варіанта. Зіставте чашку на файлі, вибраний колір на сторінці й рядок даних. Google рекомендує окреме зображення, яке передає відмінності конкретного варіанта. Детальні правила групування є в гайді про id та item_group_id.
4. Перевірте виправлене поле в XML
Ось фрагмент одного item після заміни головного фото. Це не повний фід; інші дані товару тут не описано.
<item xmlns:g="http://base.google.com/ns/1.0">
<g:id>MUG-RED</g:id>
<g:title>Червона керамічна чашка</g:title>
<g:color>Червоний</g:color>
<g:link>https://example.com/mugs/classic?color=red</g:link>
<g:image_link>https://example.com/images/mug-red-front-v2.jpg</g:image_link>
<g:additional_image_link>https://example.com/images/mug-red-handle.jpg</g:additional_image_link>
</item>Після оновлення перечитайте фактичний XML і знайдіть MUG-RED ще раз. Скопіюйте з нього нову адресу та відкрийте файл. Так ви перевірите результат підготовки даних, а не лише намір щось змінити. Окремо переконайтеся, що рядок MUG-BLUE залишився пов’язаним із синьою чашкою.
Замість коментаря «фото виправлено» залиште короткий журнал: ID, стара адреса, нова адреса, колір фактично відкритого зображення та час повторного формування джерела. Для нашого MUG-RED результат має читатися однозначно: «було синє головне фото, стало червоне; нова адреса вже є у переданому XML». Це допоможе повернутися до перевірки без повторного пошуку помилкового рядка.
Для контрольної пари запишіть і другий результат: «MUG-BLUE — синє фото, адреса залишилася попередньою». Так видно межу зміни. Якщо після підготовки джерела обидва записи раптом отримали червоний файл, зупиніться на виправленні джерела: перевірка однієї фотографії була успішною, але відповідність двох рядків втрачена.
Додатковий ракурс передається через additional_image_link; у XML атрибут можна повторити, загалом до десяти додаткових зображень. Він доповнює головне фото, а не виправляє неправильний image_link. Це випливає з окремої специфікації додаткових зображень Google.
5. Перегляньте сам кадр і розміри
Для головного фото чашки оберіть кадр, на якому зрозуміло, що саме продається. Google забороняє рекламні накладки, водяні знаки й додані поверх фото логотипи; фізичний логотип на самому товарі — інша ситуація.
Не плутайте майбутню вимогу з чинною датою. Google оголосив мінімум 500×500 пікселів для всіх товарів із 31 січня 2027 року. У жовтні 2026 року це ще майбутня дата. 1500×1500 або більше подано як рекомендацію, а не гарантію схвалення.
Якщо використовуєте зображення, створене генеративним AI, Google вимагає метадані про таке походження, наприклад IPTC DigitalSourceType, та збереження вбудованих позначок. Перевіряйте файл після обробки, а не покладайтеся на назву інструмента.
6. Зіставте нове джерело з діагностикою
У Merchant Center відкрийте Products → Needs attention, а потім конкретний товар. За інструкцією Google з діагностики зображень, у деталях можна перевірити отриману мініатюру, час останнього сканування та активні попередження. Зміна файлу або URL не означає миттєвої повторної обробки.
Якщо мініатюра ще синя, порівняйте час перевірки з часом оновлення джерела. Якщо новий рядок уже передано, але останнє сканування старіше, це інша ситуація, ніж нове сканування тієї самої неправильної адреси. Не починайте наступну заміну, поки не з’ясували, яку версію даних зараз бачите.
Перед завершенням поставте шість позначок:
- потрібний ID знайдено у фактичному джерелі;
- його головний URL відкриває файл;
- файл показує правильний варіант;
- картка відкривається з відповідним вибором;
- повторно підготовлене джерело містить виправлену адресу;
- актуальний стан товару перевірено в Merchant Center.
Для перевірки структури повного джерела скористайтеся гайдом про XML-фід. Якщо готуєте власний інтернет-магазин, ознайомтеся з Shopcore та перейдіть до реєстрації. Відповідність фотографій і результат їхньої обробки перевіряйте на конкретних товарах.