Когда есть необходимость, время и самое главное бюджеты на должную детализированную проработку - здесь нет ничего особенного (кроме усердного труда).
При серьёзной раскачке одна полноценная статья может поднимать несколько сотен низко и микрочастотников.
Спустя достаточное кол-во времени обилие вариаций микрочастотных запросов может быть и больше.
Чаще всего для решения региональных коммерческих задач. Больше релевантных предложений, удобнее сравнивать цены и изучать потребительские отклики.
Смотря какую преследовать цель. Если набирать/разбавлять ссылочную массу, то имеет смысл.
Если вам нужно в ближайшем времени улучшить ранжировать по ключевым запросам, то я бы не стал эти мероприятия рассматривать как приоритетную задачу.
Без рабочей конкретики никто не будет конструировать умозрительные конструкции для редиректов из "неизвестно откуда" в "неизвестно куда" - это пустое и неблагодарное занятие.
Наймите толкового программиста, который фактически увидит ваш рабочие реалии и выполнит редиректы (если это можно сделать автоматически по рабочим соответствиям), либо сделает вам в CMS рабочую область, где вы будете формировать редиректы вручную.
Никто другой вам в настоящий момент помочь не сможет, это будут бесконечные разговоры вокруг да около.
Вариант 3.
Все будет зависеть от структурного соответствия, здесь надо смотреть в какой логике формировались URL адреса старого сайта и в какой логике (и иерархии вывода, если она заложена) страницы выводятся сейчас.
Если по отдельным групповым маскам редиректы реализовать не получится, то придётся формировать точечные редиректы: старый адрес -> новый. Так как страниц может быть множество сотни / тысячи / десятки тысяч, то подобные наборные редиректы организуются через функционал CMS силами контент-менеджеров (выше вам дали правильный ориентир для альтернативного редиректа).
Нередко в таких ситуациях приходится разделять товарный группы и сами товары по приоритетам - то, что даёт основной трафик - покрывается редиректами в первую очередь и далее по мере уменьшения важности страниц для трафика.
На конце слэш можно убрать т.е.
Либо вы что-то путаете, либо ерунду пишут, - в авторитетных источниках такого написано быть не может.
Смысл в том, что на всех страницах с целевым содержанием вы указываете каноническую страницу, соот-но, как минимум и как максимум на оригинальной странице с указанным адресом будет эта запись.
Механика здесь следующая, каждый целевой странице прописывается свой canonical, соот-но, при этом все производные дубли (с get параметрами или страницы печатной версии) - всё будет указывать на тот адрес, который и рекомендуется поисковой системе как основной. Так что не сомневайтесь, указывайте.
Вы правы, как правило целевые страницы должны иметь чёткий ЧПУ URL, get параметры образуют листинги, условия сортировок и т.д., хотя конечно на форумах, например, страницы с профилями пользователей могут быть с get параметрами.
Должен выплюнуть, но процесс может затягиваться, поэтому наряду с закрытием индексации рекомендуется также вручную отправить заявку на исключение из индекса через Яндекс.Вебмастер.
У Яндекса много странностей (например, массовая индексация страниц с UTM метками) и казалось бы - Яндекса отчётливо понимает назначение этих страниц, но всё-равно может индексировать, если нет запрета на их индексацию через того же clear-param.
В общем, запрещайте через robots, ставьте canonical-ы (они вообще должны быть), отправляйте заявки на удаление ненужных страниц в индексе и ближайшую рабочую перспективу этого вполне достаточно.
Я тоже не вижу явных причин для ухудшения ранжирования, если робот будет иметь для переобхода дополнительный круг из числа бесполезных для индекса страниц перечня.
Если это не мешает общей функциональности сайта, то да, вполне можно реализовать. Но тут нужно аккуратней, чтобы правило редиректа не перекрывала другие get параметры, которые могут использоваться.
А общий признак URL-а действительно можно постараться закрыть через Clean-param (правда, только для Яндекса), Гугл будет игнорировать.
