Цільова сторінка не працює в Merchant Center: що перевірити
Попередження Landing page not working легко сприйняти як помилку: товар відкривається, ціна є, кнопка покупки працює. Але перевірка у власному браузері відповідає лише на частину запитань. Щоб розібратися з відхиленням, потрібні точна адреса, умови перевірки та фактична відповідь сервера. Нижче — порядок роботи для власника магазину й технічного спеціаліста, без обіцянки автоматичного схвалення.
Почніть із конкретного URL
Відкрийте проблему в Merchant Center і випишіть адресу саме відхиленого товару. Порівняйте її з посиланням у джерелі даних: домен, шлях, параметри, протокол. Якщо передбачена окрема мобільна адреса, запишіть і її. Не замінюйте цей запис посиланням на головну сторінку: вона не відтворює шлях покупця до конкретного товару.
Перевірте, куди ведуть перенаправлення. У рекомендаціях Merchant Center Google радить перевіряти кінцеву адресу, помилки 4xx/5xx, доступність покупки, різні пристрої, браузери та місця доступу. Повільне завантаження й серверні обмеження також можуть завадити автоматичній перевірці.
Для початку візьміть кілька відхилених товарів із різних категорій. Окремо позначте, чи однаковий результат на телефоні та комп’ютері. Це робоча вибірка для пошуку закономірності, а не доказ справності всього каталогу.
Записуйте результат, а не враження
Невелика таблиця допоможе не змішувати різні перевірки. Заповнюйте тільки те, що справді спостерігали; недоступні дані залишайте невідомими.
| Що зафіксувати | Приклад запису | Для чого це потрібно |
|---|---|---|
| Адреса товару | Повний URL із джерела даних | Повторити той самий запит |
| Час та умови | Дата, часовий пояс, desktop або mobile | Зіставити перевірку з журналом |
| Перенаправлення | Початковий і кінцевий URL | Виявити іншу сторінку призначення |
| Відповідь | Код HTTP або повідомлення про збій | Відрізнити доступ від зовнішнього вигляду |
| Джерело доказу | Браузер, GSC, серверний журнал | Не прирівняти різні спостереження |
Зберігайте таку нотатку до внесення змін. Потім можна буде порівняти однакову адресу за подібних умов, а не пригадувати, чи відкривалася вона вчора. Один успішний запит не пояснює попередній збій, а один невдалий — ще не показує його масштаб.
Чому успіх у Search Console не закриває питання
Документація URL Inspection пояснює: успішний live test підтверджує доступ Google-InspectionTool для перевірки індексації. Тимчасова серверна помилка може проявитися під час обходу, хоча поточний тест успішний, або навпаки. Крім того, тест переходить за перенаправленнями, не показуючи кінцевої адреси.
У довіднику Google crawler Google-InspectionTool і Storebot-Google описані окремо. Storebot має desktop і mobile варіанти; правила для нього впливають на поверхні Google Shopping. Звичайні роботи Google дотримуються robots.txt під час автоматичного обходу.
Практичний висновок із цієї різниці: успішний тест GSC сам по собі не доводить доступ Storebot і не гарантує схвалення в Merchant Center. Так само сторонній тест із відповіддю 403 не доводить, що Google отримав саме її. Обидва результати варто зберегти як окремі факти, не перетворюючи жоден на готовий діагноз.
Що передати технічному спеціалісту
Попросіть перевірити правила robots.txt для потрібних адрес і агентів, а також зіставити доступні серверні та WAF-журнали з часом перевірки. Корисне питання: «Яке конкретне правило або відповідь пояснює збій цього запиту?» Формулювання «Google заблокований» без відповідного доказу надто широке.
Не копіюйте універсальний Allow: / і не вимикайте захист усього магазину навмання. Такий рецепт може не відповідати фактичній причині. Зафіксуйте запропоновану зміну, її підставу й очікуваний результат; після виконання повторіть ту саму перевірку. Якщо журналів немає, чесно вкажіть це обмеження в зверненні.
Довідник Google також попереджає, що User-Agent можна підробити. Тому рядок Storebot-Google у журналі сам по собі не засвідчує справжнього відвідування Google. Перевірку походження запиту доручіть спеціалісту, який має відповідні дані та доступ.
Умовний приклад: три результати замість одного діагнозу
Уявімо магазин, де сторінка відкрилася на ноутбуці, зовнішній сервіс отримав 403, а GSC live test завершився успішно. Правильний запис — три результати з часом і адресою. Причина поки невідома. Наступний крок — зіставити їх із доступними журналами та правилами доступу. Висновок «треба відкрити все» або «Merchant Center помилився» випереджав би докази. Це навчальний сценарій, а не встановлена проблема конкретного магазину.
Коли виправляти, а коли запитувати review
Якщо причину знайдено, спочатку застосуйте відповідне виправлення й перевірте результат. Google описує запит review після технічних виправлень; для незгоди з рішенням передбачене оскарження, яке може вимагати додаткового обґрунтування. Дотримуйтеся доступного сценарію в Merchant Center та його обмежень. Повторні запити без нових даних не замінюють діагностику; результат перевірки не гарантований.
Для звернення підготуйте коротку хронологію: що відхилено, які адреси перевірено, що встановлено та що змінено. Відокремте підтверджену причину від припущень. Не публікуйте приватні журнали, токени чи дані покупців.
Загальний порядок підготовки магазину є в гайді про Google Merchant Center. Якщо плануєте окремий магазин, можете зареєструватися в Shopcore. Для діагностики відхилення спирайтеся на зібрані факти й результати перевірки конкретної сторінки.