В данном случае скорее всего больше не срабатывает буст накрутки запросов, а по другим метрикам сайт не вывозит, вот он и падает туда где он и должен быть.
Сейчас эта ситуация характерно для большинства сайтов, которые заныривали в топ с помощью накрутки.
Кардинально не пересмотрят. Скорее всего ослабят роль кликовых факторов c серой зоны мобильных айпишников.
Отнесутся как к странице с большим объёмом информации. Думайте о том, насколько удобно такую информацию воспринимать пользователям.
Это больше типично для товарного листинга.
Зачем комментарии выводить на Главную? Что за сайт? Какой формат? Какая тема? Информационный или коммерческий сайт?
Какая конкретно задача? За сайтами есть реальный бизнес или это псевдосайты? Вы хотите снова "поднять" сетку?
Сейчас взялся за сайт. Там жестко крутили. Сайт улетел за 50 места.
Недавно был один из лидеров в топе. Пометки нет.
Пишите в Яндекс. Фильтр должен быть подтвержден (не в том смысле, что вам кто-то должен, а как опорная точка для дальнейшей работы).
Пометка действительно может появится существенно позже (нередко она появляется после обращения в тех. поддержку).
Обычно срок 6-8 месяцев.
+++
Уже совсем неинтересно, какая-то демагогия. Причём тут время и деньги? И кому какая разница про деньги, если обсуждается доступность выбранного решения? Сколько определит программист времени на решение этой задачи столько и займёт +- персональная оперативность/нерасторопность. Про деньги - вообще дело десятоe.
Всё, дальше точно не хочу обсуждать банальные вещи. Ты бы ещё написал, что страницы вывода формируются правилами движка и спросил - знаю ли я что такое движок, а я спрошу у тебя - знаешь ли ты что такое ранжирование и будем вокруг да около ходить, жонглируя подходами и понятиями, отдаляясь от заданной темы. Пустой разговор - ей богу.
Нужная логика определяется на уровне ТЗ и отправляется программисту в рабочий тикет для реализации. Далее программист затачивает движок под нужные правила формирования ЧПУ. Все, какие строгие правила будут определены рабочей задачей, такие URL-ы движок формировать и будет (конечно при условии, что программист всё правильно сделает). Умелым программером движок настраиваться и затачивается под любые нужды и нечего тут тень на плетень наводить, всё это решаемо и решалось на практике неединожды.
Давай я попробую ещё раз.
Если в адресах не используется ID (реальный ID), то перенос контента не взывает никаких дополнительных проблем/работ.
Если это они есть, то в случае пересвоения ID (что происходит в подавляющем большинстве движков) придётся писать немало костылей - начиная от смены правил ЧПУ, переходя от реального ID к искусственному. В ином случае - писать кучу 301. Но это может быть вообще невозможно. И дело не в объёме, а.. догадаешься почему или объяснить? ;)
Ну, вот и давай на конкретном примере, чтобы мы говорили об одном и том же. А то ты описываешь ситуацию со своего угла зрения, как будто в этой абсолютно расхожей задаче есть какая-то особенная сложность.
Есть входные данные www.site.ru/krovati/krovat-anjelika-id1486
Товар "Кровать Анжелика", ID-1486, категория - Кровати.
Категория вводится структурно, вложенность товара в категорию - понятно.
Далее, если себе гипотетически представить, что исходных ID в БД нет, а есть просто запись целевого рабочего url-а, то очевидно URL последовательность разбирается в логике до id - название товара, транслитом, где "-" замена пробела, а цифровая последовательность после id без пробела - номер ID. Фактическое соответствие по факту заданной строки между товаром и ID последовательностью есть - это связка заносится в БД.
Далее точно также, на новом сайте восстановить данный адрес не составляет труда (при условии совпадающей транслитерации) без всяких там 301-х редиректов. Новые ID сгенерированные CMS-ой в URL-е не выводить, а выводить те, что мы спарсили из исходной строчки (тогда это уже даже не ID, а просто параметр в строке URL-а). Так чего ж там такого особенного-то?
Если мы говорим о каком-то начинающем вебмастере, который приглядел новый движок и хочет c одной CMS платформы перевести свой товарный саттелит на другую - здесь у него могут возникнут вполне конкретные проблемы, которые он может и не решить без посторонней помощи. Но если это живой бизнес и нанятый опытный программист, то эта задача из разряда начального уровня - спарсить, разобрать, занести нужные данные в таблицы БД, сформировать новые URL-ы и далее для контроля - сравнить перечень URL-ов старого сайта с новым. При точном построчном совпадении задача выполнена.
:) Поэтому я и сказал, что Гугл.Ньюс нам не нужен, у нас другой случай. Изначально вообще речь была про необходимость сокращения URL-а, на что в первых же комментариях я дал ответ.
Сейчас там нет таких проблем, да и SEF компонентов великое множество.
Ok. Я бы сказал - доп. задачей. Любые направленные рабочие действия - это и есть набор задач. Но каких-то отличительных проблем здесь я действительно не вижу.
Проблемой может быть и то, что программист может внезапно заболеть и не уложиться в дедлайн.
Так там не про ранжирование, там про датировку материалов в учете Гугл.Новостей.
