- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Зачем быть уникальным в мире, где все можно скопировать
Почему так важна уникальность текста и как она влияет на SEO
Ingate Organic
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Работаю с Яндекс маркетом еще с того момента, когда они "пешком по стол ходили". Они конечно всегда держали марку и заставляли магазины строго следовать их условиям, но сейчас, похоже, они решили что они настолько большие, что могут себе позволить вообще не думать о адекватности своих условий и блокировать магазины, не разбираясь в реальной ситуации.
Но обо всем по порядку.
Первое - это проблема с кешем странички магазина, сделанного на Битриксе по технологии "Композитный сайт". Тут все выглядит так: если страницу товара не посещал ни один пользователь - то робот Яндекс маркета, заходя на страничку с целью проверки цены может увидеть старую цену из кеша. Неважно, что обновив страницу, будет уже все корректно. и неважно что это только для страничек на который никто не заходил после обновлении цены. Все равно это ошибка.
и формально Яндекс Маркет прав и ему накакать на Битрикс, который по этому поводу тоже не особо беспокоится.
Второе - уже интереснее.
Концепция Яндекс маркета - цены всегда должны быть актуальны.
Если ассортимент обновляется рандомно, в течении дня, в зависимости от продаж, то обновления файла выгрузки мы не можем производить рандомно.
Пример
ассортимент магазина изменился в течении часа на 1,2 5 8 12 15 35 36 39 и 51-й минуте, Когда должно происходить обновление файла? Не торопитесь с ответом, нужно посмотреть на продолжительность обработки файла. Это может занимать около 5-10 минут. То есть если например файл был обновлен сразу после первого изменения, то он не сможет быть запущен после второго изменения, потому что он УЖЕ ЗАПУЩЕН. А ведь робот может обратиться в магазин и увидеть расхождение в файле и на сайте.
То есть, поймать на несоответствии товара в наличии лишь вопрос времени и частоты проверки магазина.:dont:
Если честно, вообще не понимаю, что здесь можно поделать, учитывая еще то, обновление файла это хорошая нагрузка на сервер и если это запускать с регулярностью 1 минута, то сложно сказать какой конфиг сервера это может выдержить.
А ведь Яндекс Маркет, как крутыш, мог давно предложить обновления лайт, то есть основные данные товара загружаются всего один раз, а обновления - это всего лишь цена и есть/нет в наличии. Если присутствует новый товар, то он загружается полностью.
Про обновление xml файла я вам отвечу. Это лень программистов, им пофигу на него. По сути в большой обработке, если поменялась только цена, то производиться должна обычная замена в файле. Но это надо писать отдельный блок, поэтому стандартно выгрузка только полная.
Поэтому для вас писать отдельный модуль, который при изменении цены будет менять его в файле. Яндекса ваши технические проблемы не волнуют.
Про обновление xml файла я вам отвечу. Это лень программистов, им пофигу на него. По сути в большой обработке, если поменялась только цена, то производиться должна обычная замена в файле.
Именно. Еще немного добавлю - меняем цену и заменяем время генерации выгрузки в файле, чтобы маркет воспринимал выгрузку как новый файл, иначе ошибки будут. Задача простая, заниматься перегенерацией всей выгрузки каждый раз - дичь
Начинают нашибать, все хотят денег.
Яндекса ваши технические проблемы не волнуют.
вот именно этот подход - это плохо
По сути в большой обработке, если поменялась только цена, то производиться должна обычная замена в файле. Но это надо писать отдельный блок, поэтому стандартно выгрузка только полная.
Поэтому для вас писать отдельный модуль, который при изменении цены будет менять его в файле. .
Вы наверно предполагаете что у товара есть карточка на ЯМ, а у моих товаров их нет.
вот именно этот подход - это плохо
Он у всех и везде этот подход.
Вы наверно предполагаете что у товара есть карточка на ЯМ, а у моих товаров их нет.
Карточки здесь причем? Вам нужно провести небольшую техническую работу, которая будет заключаться в том, что после изменений не будет перегенерации всего фида, просто в самом фиде поменяется то, что у вас изменилось + в выгрузке меняете время генерации в фиде, чтобы маркет его воспринимал как новый
Коллеги, всем добрый день!
На Маркете есть возможность для ускоренного обновления цен и других данных: https://yandex.ru/support/partnermarket/efficiency/data-update.html .
При проверках робот Маркета сначала переходит с опубликованного предложения на страницу товара на сайте магазина и сравнивает цены. Если цена совпала - все отлично. Если не совпала, робот пока не ставит ошибку, а отмечает это предложение, чтобы позже вернуться к нему еще раз. Через некоторое время робот запрашивает у магазина актуальный прайс-лист, находит в нем цену на это товарное предложение и сравнивает с ценой, которая была замечена на сайте. Если эти цены совпадают - все хорошо, ошибки нет. Когда актуальных прайс-лист будет опубликован на Маркете цены снова совпадут. Ошибка ставится только в том случае, если при скачивании актуального прайс-листа цены опять отличаются.
Карточки здесь причем? Вам нужно провести небольшую техническую работу, которая будет заключаться в том, что после изменений не будет перегенерации всего фида, просто в самом фиде поменяется то, что у вас изменилось + в выгрузке меняете время генерации в фиде, чтобы маркет его воспринимал как новый
Как-то я вас не очень понимаю, есть два способа выгрузки - либо яндекс забирает XML файл либо Яндекс обращается к моему скрипту и генерит этот файл на лету. У меня сейчас именно второй вариант.
Можно генерить заранее XML и яндекс будет его забирать, но уже давно проверено, что это еще больше занимает времени и робот яндекса просто отрубается по таймауту.
Написать можем все что угодно, вопрос не лени. Если я напишу просто файл в котором будут изменены цены без свойств товара, то получу ругань на загрузке - либо не хватает свойств товара, либо яндекс вообще его не распознает. Он не хранит мои предложения в кеше, для того чтобы я мог выгружать только наличие и цену.
На Маркете есть возможность для ускоренного обновления цен и других данных: https://yandex.ru/support/partnermarket/efficiency/data-update.html .
При проверках робот Маркета сначала переходит с опубликованного предложения на страницу товара на сайте магазина и сравнивает цены. Если цена совпала - все отлично. Если не совпала, робот пока не ставит ошибку, а отмечает это предложение, чтобы позже вернуться к нему еще раз. Через некоторое время робот запрашивает у магазина актуальный прайс-лист, находит в нем цену на это товарное предложение и сравнивает с ценой, которая была замечена на сайте. Если эти цены совпадают - все хорошо, ошибки нет. Когда актуальных прайс-лист будет опубликован на Маркете цены снова совпадут. Ошибка ставится только в том случае, если при скачивании актуального прайс-листа цены опять отличаются.
В целом предлагается при изменениях на сайте сразу триггером "руками" вносить изменения в файл.
Утверждение касательно того что это будет быстро, очень спорное. Работа с файлом 10-20МБ еще то "удовольствие".
При этом особо не важно, будем мы с ним работать как с честным XML или с помощью регулярок.
А теперь еще на это наложите групповую обработку свойств, применение скидок по изготовителям и т.д.
Т.е. любое телодвижение будет дергать целый ряд изменений в разных местах файла.