На этом форуме довольно часто всплывает эта тема, и при желании, можно найти почитать все мнения и технические реализации.
Там приставка не затерялась ))
Так в даной ситуации клиенту не нужен бэкап как таковой.
В данной ситуации, бэкап нужен хостеру
Клиенту нужно то, что заявил хостер - передачу данных со своего хостинга. Клиент согласно договора данные разместил.
А вот хостер их не передал, а просто удалил
Соответственно, хостер выполнил условия договора
Ничего не затерялось, все на месте.
Тут верно писали, что дату гугл может подцепить дату вообще не из микроразметки, а какая ему понравится, особенно на ИМ в карточке товара, где в разметке нет даты. У меня на разных сайтах, по разному.
От чего зависит, не разбирался.
да тем же чем и ты :)
При таком варианте, по идеи вес все равно утекает с исходной страницы, но не на конечную страницу, а на прокладку - go.php
Такой метод часто применяют на форумах, но с целью уменьшить спам.
Весьма странное заявление.
А зачем "проходится" еще раз, если они уже увидели новую дату из микроразметки, и соответственно уже прошлись ?
Типа - не может быть, надо еще раз пройтись )
Что касается факторов ранжирования, то если нет своего опыта, наверное лучше прислушаться к авторитетным ресурсам. Где бытует мнение, что при ранжировании учитывается наличие даты в микроразметке, а не ее значение. Как в реальности, знают только программисты алгоритма.
Так о том здесь и писали. Более того, если начать манипулировать этой датой, то он может просто перестать ее рисовать.
Но раз автору известно, что дата влияет на ранжирование, то как говорил Паниковский - "пилите Шура гирю, пилите, она золотая" )
Что-то новое )
То есть чем она выше, тем выше ранжируется статья ? Тогда, ставьте текущую, а лучше на пару месяцев вперед
Schema.org определяет правила разметки, а не цель )
Какая цель у вас при установке не реальной даты статьи ?
Обмануть ПС, обмануть посетителя, либо нечто другое ?
